模型的效果可以很惊艳，但它周围的业务流程仍然可能没有定义。生产交付要先说清楚 System of Record、人工决策点与失败路径。
本文以“从内部知识生成处理建议，经过审批后更新业务系统”为设计示例。它用于解释工程方法，不是已验证的客户项目，也不包含实测效果承诺。
1. 先画清楚谁拥有状态
知识源负责内容与访问权限，业务系统负责订单、工单等权威状态，AI 负责生成建议。集成层不能因为模型生成了一个字段，就认为业务状态已经改变。
最小系统地图应标出：调用者身份、允许读取的数据源、模型供应商、工具接口、审批者、最终写入系统，以及每一步的审计位置。涉及外部模型时，还要确认哪些字段会离开客户环境。
2. 权限要进入检索链路
页面登录不等于数据权限得到保护。索引、检索过滤、缓存和引用展示都必须保持原始访问边界。人员调岗或权限撤销后，旧缓存不能继续暴露内容。
一个有价值的测试是：让没有文档权限的身份查询该文档中的已知信息。预期结果应是拒绝或无结果，而不是模型因为“记得答案”就返回内容。
提示注入也不应由模型自行判断后放行。检索文档属于不可信输入，不能授权工具调用。应用侧仍要校验工具白名单、参数范围和调用者权限。
3. 审批必须绑定一个确定的动作
审批记录应包含提议内容、目标对象、参数、版本与有效期。审批后若金额、收件人或目标状态发生变化，应重新审批。单独的“同意”标记不能证明执行的是用户批准的那次操作。
在证据不足、权限不明、参数冲突或建议超出范围时，工作流应拒绝或转人工。人工审批的作用是形成可追溯的决策点，不是替代输入校验。
4. 区分回滚、重试与补偿
请求超时只说明客户端没拿到结果，不代表业务系统没有执行。先用操作标识查询结果，再决定是否重试；对于有副作用的写入，目标接口应支持幂等或提供对账手段。
部署回滚可以恢复上一版程序，但不能撤回已发送的邮件，也不能自动撤销已生效的订单。对应的取消、冲正或人工处理属于业务补偿，必须另行定义权限与流程。
5. 把评测变成发布条件
测试集至少覆盖正常结果、无依据回答、越权检索、工具失败、重复请求和人工接管。固定模型、Prompt、工具与数据版本，使两轮评估可以比较。
验收不只看回答是否正确，还应观察任务完成率、拒绝与转人工结果、P95 延迟、单次流程成本和告警可达性。阈值依据业务风险与预算约定，不能用通用的“准确率很高”代替。
6. 移交要能让另一支团队接手
可检查的移交包包括代码与部署说明、接口契约、权限矩阵、Eval 报告、日志字段说明、告警责任人、Runbook，以及停止与恢复演练记录。源码归属、后续维护和支持窗口需要在合作范围中明确。
实际问题不是 AI 能不能回答，而是周围的工作流是否知道下一步该做什么，以及失败时由谁做决定。