让 AI 交付可靠的软件：我们的六条工程方法

让 AI 写一段能跑的代码，今天已经不难。难的是另一件事：让它持续地、可靠地交付一个完整的软件，并且出了问题能查清楚是哪一步、为什么。

我们用自己的软件产品实践了一套方法。核心思路只有一句：软件工程里已经被验证过的做法——规格、评审、测试、审计——一样都不能少，只是执行者从人换成了一组分工明确的智能体。

一、规格先行

每项任务开始之前，先写清楚验收标准，并写成可以自动运行的验收测试。实现的一方必须让这些测试通过，不能反过来修改测试迁就实现。

这条规矩看似简单，却决定了交付质量的下限：没有事先约定的标准，「做完了」就只是一句自我评价。

二、多智能体分工

规划、实现、评审、测试由不同的智能体承担，不让同一个智能体既当运动员又当裁判。任务的难度不同，分配的模型能力也不同：常规实现用成本更低的模型，关键的规格与评审交给更强的模型。

三、独立评审

验收标准要改动时，先交给一个没有参与实现的智能体独立评审，确认没有为了让实现过关而放宽标准。评审不通过就不改，并写明原因。代码写得好不好，不由写代码的一方自己说了算。

四、自动门禁

发布之前要过自动门禁：回归测试不通过就不发布。同一份构建先在本地预览环境上线，检查通过才推到线上；线上健康检查不通过，自动回滚到上一版。

五、全程留痕

关键决定和发布都有记录：目标和验收标准有编号，提交记录写明为什么这么改，实测结果单独存档。这不只是为了排查问题：软件要上架应用商店、要过合规审查时，这些记录就是交给第三方评估方的证据。

六、人只做决定

需要人判断的事——业务取舍、对外承诺、花钱的事——统一进入一个决策流程，附上选项、建议和依据，由人拍板，并记录在案。能由系统按规则决定的技术问题，不去打扰人。

这套方法的边界

需要说明的是：这套方法解决的是「交付过程可靠、可追溯」，不能替代对业务本身的判断。做什么、为什么做，仍然要人来想清楚。我们的经验是，人的时间越是集中在这些判断上，整体产出越好。

我们自己的软件产品就是用这套方法研发和运营的。为客户交付软件和数字员工时，同样遵循这些规矩：开始前约定验收标准，过程留有记录，涉及业务判断的事项由客户拍板。