跳到主要内容

4.9 我怎样审查 AI 全栈工程师的证据

AI 全栈工程师完成第一版后告诉我：“全部测试已经通过。”

我没有怀疑它的能力，但也没有接受这句话作为交付结论。

“全部”指哪些情况？“通过”是谁判断？测试使用的资料是否接近真实订单？系统失败时发生了什么？如果这些问题不能展开，一句通过对经营层没有意义。

我先让工程师重新讲一次问题​

审查不是从系统演示开始。

我请工程师用自己的话说明：这项工作原来为什么会造成延期和回款问题，第一版改变谁的哪一步，哪些决定仍然由人负责，哪些内容明确不在范围内。

它如果把“签约前发现承诺差异”讲成“帮助销售自动生成方案”，说明建设过程中目标已经悄悄变化。

目标偏移通常不是故意的。工程团队会自然地优化容易实现和展示的部分。FDE 必须不断把交付拉回经营问题。

我要求证据能够回到具体情境​

工程师准备了一张通过率表。我选择其中一个“客户主体冲突”案例，请它展开：

  • 输入了哪些原始资料；
  • 系统识别出什么差异；
  • 用户当时看到什么；
  • 业务状态有没有变化；
  • 哪些日志被留下；
  • 谁判断结果合格。

如果一项结果只能看到最终截图，无法回到输入和过程，我不会把它当作充分证据。

证据不是越多越好，而是能让另一个人重新判断结论是否成立。

我按五个方面审查​

1. 经营行为​

系统有没有改变任务书里的目标？正常、缺失、冲突和高风险情况是否按约定处理？有没有为了输出完整而把建议写成事实？

这一部分主要由业务人员和 FDE 判断。

2. 权限与责任​

系统实际读取和写入的范围是否与数据权限表一致？AI 用什么身份行动？人工确认和自动动作能否区分？有没有为了开发方便取得多余权限？

数据、风险负责人和工程师共同判断。

3. 失败与恢复​

来源不可用时是否显示未知？人工接管能否拿到上下文？重试是否会重复写入？回滚以后受影响的人是否收到通知？

不能只展示正常结果，必须主动制造失败。

4. 质量、速度与成本​

不同订单类型的表现是否分开观察？最慢和最贵的情况是什么？人工复核时间有没有计入？试点规模扩大后费用会怎样变化？

平均值不能掩盖高风险订单。

5. 未决问题与限制​

哪些资料还拿不到，哪些情境仍然不稳定，哪些动作暂时只能人工完成，限制会影响哪些用户？

一份没有限制的证据包，通常只是把限制藏起来了。

我不读源码，也不假装审查源码​

FDE 不需要通过阅读每一行代码来证明自己负责。

我审查的是可观察的业务行为：系统收到什么事实、作出什么处理、改变什么状态、留下什么证据、失败后怎样继续。

工程师负责代码质量、安全、部署和技术测试，并要把相关结论翻译成我和业务负责人能够判断的证据。

如果某项风险只能通过专业审查确认，我会请安全、数据或架构负责人参加，而不是自己给出没有依据的通过。

每次变更都要说明影响​

试点中，工程师更换了资料整理方式。整体结果变快了，但两个历史情境开始漏掉补充协议。

从那以后，我要求每次重要变更都写清：

  • 为什么改变；
  • 改了哪些行为、规则、数据来源或依赖；
  • 哪些用户和历史结果可能受影响；
  • 重新运行了哪些验收情境；
  • 如果结果变差，怎样退回。

“只是技术调整”不能自动免于业务复核。只要可能改变输出和状态，就要检查。

我让证据包能够被内部团队接手​

交付证据不能只存在工程师的临时环境和聊天记录里。

样本、验收结果、失败记录、权限清单、成本、限制和版本说明都由公司保存，并有明确维护人。以后模型、规则或供应商变化，内部团队可以使用同一组材料重新判断。

这也是为什么交付证据不是项目结束时补写的报告，而是建设过程中持续形成的运行资产。

我怎样作出通过、限制通过或不通过​

审查结果只有三类。

通过，表示当前范围可以进入下一阶段；限制通过，表示只有写清的用户、订单或动作可以试点；不通过，表示存在会破坏经营目标或风险边界的问题。

我不会写“原则上通过，后续持续优化”。这种结论没有告诉任何人现在可以做什么。

每个未通过项都要有负责人、下一步证据和复核时间。

这次评审的结论是“限制通过”​

审查项已有证据仍有限制决定
经营目标YS-24-017、009、028 和基线能回到原始记录还不能证明十二周内改善毛利与回款允许验证过程变化
业务行为十二类正常、边界、失败和高风险用例集团主体冲突第一次失败，修正后需长期保留修正重测后通过
权限独立身份、首批资料只读、越权拒绝有记录未脱敏纪要能否进入第三方服务仍未确认仅使用批准脱敏资料
恢复财务中断、重复提交、人工路径已演练第一阶段不开放正式写入允许只读真实试点
速度与成本不同使用时刻已分开观察完整人工复核与运行成本尚无基线试点期间逐笔记录
经营采用九名首批用户和责任人已指定真实工作压力与双录尚未验证不扩大到全体销售

“限制通过”在这里有明确含义：可以让九名首批用户在获准新订单上使用内部整理、差异检查和提醒；不能写正式系统、对客发送、接受非标准承诺或修改财务事实。

三个未决事项仍在包里：CRM 客户主体标识质量、第三方服务可接触的纪要范围、财务状态接口失败时能返回多少信息。每项都有负责人和下一证据，不能由工程师用默认实现代替决定。

完整审查输入和下一阶段条件见 已填写执行包。下一节不会把“限制通过”解释成全员上线，而是把历史验证、少量真实订单、有限写入候选和内部接手分别安排：我怎样从试点走到日常运行。