FORMWEFT01 业务目标与现状基线
写清谁完成什么任务、现有处理方式与成功标准。记录样本数量、任务难度和人工参与量；不要拿演示中挑选的最佳结果代表全部业务。
五项上线检查
每一项都应对应负责人和可查看的证据。没有证据的“已完成”，仍然是待确认。
02 身份、权限与数据边界
用不同角色测试相同问题和工具。检查检索、缓存、下载、日志与系统写入是否遵守同样边界；测试账号删除或停用后是否仍有访问路径。
03 质量评测与失败分类
固定一组正常、模糊、缺资料、越权和接口失败样本。记录版本、输入、输出、依据与人工判断；把不能答却肯定回答的情况单独列为风险。
04 异常接管与发布回滚
确认超时、重复请求、审批拒绝和依赖服务中断时的行为。安排人工负责人，演练关闭自动执行、回退版本和恢复工作的路径。
05 成本、容量与长期负责人
观察完整任务的调用、延迟和资源成本，而非仅单次模型费用。约定日志与知识维护、告警责任、支持窗口和定期复盘节奏。
将检查结果汇成一份发布记录
一份可用的发布记录要让不在开发群里的人也能理解：为什么上线、上线什么、失败后怎么办。
发布范围
列出版本、用户范围、开放任务、数据与工具，以及明确不支持的能力。记录本次与上次版本的差异。
验收证据
关联评测样本、权限测试、设备或性能记录和未解决问题。已知问题必须说明影响、规避方式和是否阻止上线。
决策与责任
记录业务和技术负责人、确认时间、监控项目、人工接管与回滚负责人，以及下一次复盘条件。
以客服订单查询为例
这是用于解释方法的假设场景，不代表已完成客户项目。
原型阶段
输入订单号后能显示物流摘要，只说明模型与查询链路能够工作。尚未证明不同客户之间的权限隔离、重复请求与异常处理。
生产前补齐
验证用户确实有权查询该订单；物流接口超时不得生成虚假状态；敏感字段最小化返回；关键结果展示取数时间并提供转人工入口。
是否发布
用约定正常与异常样本验证，保留失败记录。只有权限、事实、异常和负责人都明确后，才对确认范围的用户开放，并持续观察。
你的试点卡在哪个上线条件？
说明当前能完成的任务、已经接入的系统和仍然无法验证的问题。