同一模型为什么交付结果差这么远《工程化决策树》第 6 篇主题AI 工程化——从“生成代码”走向“可验证交付”模型决定能力上限交付系统决定这些能力能否稳定落到项目里。对正式项目来说提示词只是入口上下文、检查证据和职责边界才是交付链路。一、这不是一次严格对照实验我在个人项目里用同一个模型处理过一类相近需求用户注册登录、任务管理、前后端页面和数据库。第一种工作流很直接把目标放进长对话边生成边补充模型说“完成”后我再联调。第二种工作流先固定范围、接口、数据结构和验收条件再把任务拆开每一段都跑静态检查、测试和构建。这段经历没有预先设计样本、随机分组和完整记录所以我不会把它称为可复现的对照实验也不再用一个百分比代表模型的“完成率”。它更像一次工作方法的复盘。我观察到的差异很具体自由对话工作流受约束工作流需求在对话中持续漂移范围和接口有可回看的基线前后端各自补全缺失信息双方围绕同一份契约实现“完成”主要来自模型自述lint、类型、测试、构建提供证据问题常在联调时集中暴露错误更早停在当前任务内这不能证明第二种方法在所有项目里都更快但它解释了一个反复出现的现象同一个模型放进不同交付系统返工方式和结果可预测性会明显不同。二、交付差距来自三处我把这套约束称为 Harness。它不是某个工具也不是一组花哨提示词而是三个相互配合的工程环节上下文契约减少模型需要自行猜测的决策。自动化门禁用可重复检查提供完成证据。职责与上下文隔离让复杂任务保持边界避免一段长对话承载全部决策。三者共同指向“可验证交付”。只写 Spec 而不检查错误仍会进入后续阶段只跑测试而没有清晰验收条件测试可能验证了错误目标拆出多个 Agent 却没有统一契约只会更快地产生不一致。三、上下文契约把猜测变成显式决策下面这类指令适合探索不适合作为交付契约写一个待办事项应用要能注册登录能增删改查任务界面好看一点。“注册登录”可能是邮箱、手机号或第三方身份源“任务”可能包含截止时间、分类和权限“好看”也没有可验收的含义。模型会补全空白但它补出的答案未必符合业务。当任务进入交付阶段我至少会固定这些信息范围做什么、不做什么 接口方法、路径、请求、响应和错误语义 数据核心字段、约束、索引和关联 界面页面、状态、关键交互和对应接口 验收正常路径、边界条件、权限与失败行为 运行版本、启动方式、检查命令和部署环境契约不必很长。它的价值也不在于信息越多越好而在于把会影响实现和验收的选择写清楚。一个注册接口的最小契约POST /api/v1/auth/register 请求email、password、name 成功创建用户并返回访问凭证 冲突邮箱已存在时返回明确错误 校验非法邮箱、过短密码不能进入业务逻辑 存储密码只保存安全哈希 验收覆盖成功、重复邮箱、非法输入和并发重复提交这份契约仍然需要项目负责人确认认证方式、凭证周期和安全策略。模型可以列出选项、分析取舍但不应在缺少业务上下文时替项目做最终决定。四、自动化门禁机器证据不是业务验收模型输出“已经完成”只能说明它停止生成不能说明代码可交付。我通常按由快到慢的顺序放置检查格式与 lint ↓ 类型检查 ↓ 单元与集成测试 ↓ 构建 ↓ 关键场景验收 ↓ 部署后观察前四项适合机器重复执行。失败后可以让 AI 根据明确错误尝试修复但要限制轮次连续失败通常意味着上下文、方案或测试假设有问题需要人重新判断。通过门禁也不等于完成交付lint 只能说明代码符合静态规则。类型通过不能证明业务分支正确。测试通过取决于测试是否覆盖了正确风险。构建成功不代表权限、安全、体验和运营目标达标。部署成功还需要观察日志、指标和真实用户路径。因此我把机器门禁当作必要证据把业务验收、安全审查和发布决策留给负责的人。机器适合回答“已知规则是否满足”人还要回答“规则是否正确、风险是否可接受”。五、职责与上下文隔离先拆任务再考虑多 Agent长对话常见的问题不是“记忆力差”这么简单而是不同职责的材料混在一起需求讨论、架构取舍、界面细节、实现日志和测试结果互相挤占注意力。后续任务很难判断哪些是已批准决策哪些只是探索草稿。更可靠的做法是按产物切开上下文需求与验收条件 ↓ 接口、数据和架构决策 ↓ 前端任务 / 后端任务 ↓ 独立验证与发布记录每个任务只携带完成它需要的材料并通过版本化产物交接。这样即使由同一个人和同一个 AI 顺序执行也能减少上下文污染。多 Agent 只是复杂任务的一种隔离手段不是 Harness 的前提更不等于用虚拟角色替代完整团队。满足以下条件时我才会考虑并行或分角色工作可以按清晰接口拆开各任务不需要频繁共享临时状态产物有统一格式和验收条件有人负责处理冲突、审阅结论和承担发布责任。小任务拆成多个 Agent协调成本可能高于收益。涉及业务取舍、架构风险、安全和用户体验时Agent 可以收集证据、提出方案也可能参与局部决策但责任不会因此转移给工具。六、几个高频失败模式幻觉 API模型可能生成名称合理但并不存在的库方法。类型检查、编译和针对真实依赖的测试能较早暴露问题如果依赖本身缺少类型信息还需要查阅官方文档或运行最小验证。前后决策漂移前端按 JWT 实现后端却在后续对话里改成 Session往往不是某一段代码难而是认证决策没有成为共享基线。将决策写入 Spec并让两端针对同一契约测试比提醒模型“记住前文”可靠。测试看起来存在下面的断言能通过却没有验证注册行为/** * 仅验证常量为真没有覆盖任何注册行为。 */TestDisplayName(注册功能应该可用)voidregisterShouldWork(){assertTrue(true);}测试需要从验收条件和风险出发检查状态变化、返回语义和失败分支。让另一个上下文审阅测试有帮助但仍要由负责人判断测试是否代表业务目标。自动修复反复打转相同错误连续出现时继续重试通常只会放大噪声。我会保留失败日志在少量尝试后停下重新检查版本、契约、依赖和方案。七、一次接手项目的复盘我接手过一个主要靠自由对话生成的项目。对方看到首页能够打开以为剩下只是部署。检查代码库后问题集中在几个地方前后端认证方式不一致部分第三方调用并不存在业务逻辑堆在单个组件里测试、迁移和部署配置缺失。它不是“AI 完全没写”而是可见页面完成了交付链路没有完成。我后来做的工作不是继续补提示词而是先整理功能边界和接口再恢复分层、修正依赖、补迁移与测试最后建立可重复部署方式。这次经历让我调整了判断标准页面能打开、某个测试通过、构建成功都只是阶段证据。只有这些证据共同覆盖当前发布风险并经过业务验收才接近“可以交付”。八、什么时候需要多少约束任务处于什么状态 │ ├── 探索想法或验证技术 │ └── 保持轻量短上下文、快速原型、明确可丢弃 │ ├── 要交给用户或同事使用 │ └── 建立契约范围、接口、验收条件和基础门禁 │ ├── 涉及数据、安全或线上变更 │ └── 增加人工审查、风险测试、回滚方案和发布观察 │ └── 复杂到单个上下文难以承载 └── 按产物隔离任务必要时再使用多个 Agent切换依据不是页面数或 API 数而是失败代价、协作复杂度和预期寿命。一次性原型可以接受手工验证长期运行、多人接手或影响真实数据的系统需要更完整的证据链。九、交付前检查清单环节要回答的问题上下文范围、接口、数据和不做事项是否明确决策哪些由人确认哪些允许 AI 在约束内选择检查lint、类型、测试、构建分别覆盖什么风险隔离当前任务是否携带了不必要或冲突的上下文失败自动修复何时停止失败日志由谁判断验收业务、安全、体验和运维条件由谁确认发布是否有可观察的指标、日志和恢复路径同一模型的结果差距很多时候并不神秘一边靠对话中的临时记忆另一边靠可追溯契约、自动检查和明确责任。Harness 的作用不是替 AI 宣布完成而是让人能够基于证据决定是否交付。下一篇讨论独立开发者如何把有限精力留给判断把高频、可验证的工作交给系统。上一篇能部署不算本事能恢复才算把恢复能力做进发布流程下一篇一个人做项目先减少切换再放大产出《工程化决策树》第 6 篇 · lytao123