AI 写代码越来越强，为什么交付依然靠运气？

过去一年我一直在观察一个反差：模型能力在肉眼可见地翻倍——刷题、演示、benchmark，一个比一个唬人。但“让 AI 把一件事从头到尾交付完”的体感提升，慢得多。

不是慢一点。是你把任务从“写个函数”升级到“交付一个完整产品”的那一刻，前面几十步的顺利，和一次翻车之间，隔着的不是模型强弱——是一整套工序。

四个翻车现场

先看四个真实的坑（来自我自己的运行记录）。

① 幽灵数据库。 后端本地全绿，部署后数据怎么都写不进去。排查两小时：代码用了相对路径 ./data/db.sqlite。工作目录一变，它连上了一个全新创建的空库——建表语句根本没执行过。最阴的是全程零报错，SQLite 欣然接受你建了一个新库。更气人的是这个问题在代码审查里根本看不出来：逻辑没错，错的是运行环境——而 AI 不会主动告诉你“我这里假设了工作目录”。

② 改了一晚上没生效的 CSS。 让 AI 调首页视觉，改完刷新——没变化。再改——还没变化。三个来回才发现：项目里有两个样式文件，同名选择器后加载的静默覆盖了前者。改的那份，从来没被浏览器采用过。

③ 重启删库。 一个跑了两周的小工具，服务器重启后数据全没。翻启动脚本，角落里藏着 rm -f *.db——最早搭建时为了“干净启动”写的一行，后来忘了删。数据是用户两周的积累，没有备份。

④ 上下文断崖。 管线跑到第 8 个环节，上游产出累计超过 15KB 全塞给下一个模型。不报错，但产出质量断崖式下跌：漏字段、编接口名、开始说“这里应该没问题”。你说不清它错在哪，它只是“变糊了”。同一个任务，只给 3KB 上下文和给 15KB 上下文，产出质量是两回事。

看出问题了吗——没有一个失败是“模型不会写代码”。全是软件工程里被讲烂的老话题：路径管理、构建产物、生命周期、上下文预算。

更强的模型，解决不了这个问题

有人说：等模型再强一点、上下文窗口再大一点，这些不都自然消失了？

我的结论：不会。原因很简单——上面四个现场里，没有一个是“智力问题”：

• 幽灵库是工程状态问题（路径），不是知识问题；
• CSS 覆盖是构建产物问题，不是审美问题；
• 删库是生命周期问题，不是代码问题；
• 上下文断崖是信息管理问题，不是理解力问题。

模型变强，提高的是“平均产出质量”的基线；但交付的成败，卡在分布的长尾和静默性上——一百步里错一步，且那一步不报错。工序解决的不是“平均水平”，是“边界”：保证最差的情况也被拦在门外。

上下文窗口从 128K 涨到 1M，也不会自动解决这件事——把更多信息塞进去，只是让“变糊”来得晚一点。制度的问题，只能靠制度解决。

团队为什么能交付？不是因为更聪明

一个成熟工程团队接到需求：需求评审 → 方案设计 → 开发 → 测试 → 代码审查 → 上线检查 → 事故复盘。每个环节都有交接物和放行标准。

团队交付稳定的原因，从来不是“人类工程师更聪明”——人类工程师每天都在犯上面那四种错。稳定来自制度：让错误在离开工位之前就被拦截，让“不知道怎么就挂了”变成“是哪道门禁拦下了它”。

而大多数人用 AI 的方式，是把制度全部抽掉：一个全能大脑，从需求直接干到上线，中间一道门都没有。

模型是脑，你缺的是骨。

把工程团队的 14 个角色和工序，编进一条管线

这就是我一直在做的事（最近把它开源了，叫 OneMaker Pipeline）：14 个角色——需求分析、产品设计、视觉创意、后端、前端、测试+安全、运维、AI 集成、CTO 审查、集成验证，加上按需激活的运营推广、全局审计、文案——串成一条有状态的交付管线：需求从第一个角色进，MVP 从最后一个角色出。

重点不是“角色多”，而是每个交接点上的四道机制：

① 不通过，不路由。 每个产出必须过三道闸门：声称的文件真实存在且非空、Bash 验证必须带 EXIT:0 指纹（Agent 可以编话，编不了退出码）、面向客户的产出过脱敏检查。任何一道不过，产出不放行下游。这个指纹协议还有个副作用：它逼着每个角色“留下证据”——你没法再说“我验证过了”，因为验证必须留下痕迹。

② 定向回环，不是原地重跑。 审查发现问题时，按问题类型回退：代码 Bug 回开发、架构问题回产品设计、安全问题回安全角色。而不是整条管线再来一遍——你不知道全量重跑会不会把已经验证过的部分改坏。

③ 三层记忆。 一条管线要跑几个小时、跨天、跨会话。记忆分三层：轻量索引（每次启动只读 4KB）、项目全记忆（选中才加载）、归档流水。每层有硬上限，超限自动裁剪、裁剪前先快照——记忆是资产，不是日志。

④ 上下文预算。 上游产出超 12KB，下游自动降级为“摘要优先、按需深读”；超 20KB 只给摘要。专门防上面第④种断崖。（这两个阈值不是拍脑袋定的：12KB 是实测中“质量开始漂移”的边界，20KB 是“基本只能靠摘要”的边界。）

四个设计决策，和为什么

决策一：角色说“我做完了”一文不值。 管线里所有自评都视为不可信输入。产出算不算数只有一个标准：外部验证过没有。最初我让模型自评完成度——95%。打开目录：文件是空的。自评是幻觉最好的藏身处。

决策二：回环要“定向”，因为失败的代价不对称。 全量重跑的成本不只是时间——它把已通过验证的七个环节再赌一次。定向回环的原则：只让出错的那一环重做，修复影响面可控。

决策三：给 AI 设上限，而不是打鸡血。 记忆有 4KB/8KB/10KB 硬上限；管线有 5 轮迭代上限，到达上限强制进入归因，而不是无限重试。同一处连续失败超过 5 次，说明这已经不是“再试一次”能解决的。没有上限的自动重试，是另一种躺平。

决策四：计划先行，记忆有门槛。 任何项目先写计划（目标、验收标准、场景类型），“想清楚”本身就是一次质量门禁。记忆写入前还有四问自检：下次恢复用得到吗？能从已有信息推导出来吗？是不是已经写过了？会不会超限？——写入的是“下次需要知道的”，不是“发生了什么”。

它真的跑出过东西

不是 PPT。这条管线完成过多类真实交付，公开产出之一是 AgentGate——给多 Agent 管线装可靠性闸门（127 个自动化测试、CI 全绿）。

有一组数据我印象很深：某次用较弱模型跑完整管线，“代码生成”环节连续 5 次产出不达标——每次都被门禁拦下，没有一次侥幸通过。第 5 次后自动触发诊断，定位为模型方差问题。修复流程后，首次完整跑通 8 个环节（其中 3 次定向回环）。

如果没有门禁，这 5 次失败里至少有 2 次会伪装成成功，把炸弹埋进下游。

这条管线自己的版本迭代到 v4.x——每个版本号背后，都是一次翻车后的机制补丁：4.2 加了指纹协议，4.3 加了上下文预算和全局审计，4.4 加了定向回环和记忆防膨胀。机制的列表，就是事故的名单。

你可能会问

Q：这套东西适合什么场景？ A：单人工程、小团队、需要“交付质量稳定”的场景：对外产品、企业交付、开源项目。纯一次性的小脚本不用上，杀鸡不用牛刀。

Q：为什么不做成一个框架或者 SDK？ A：因为它本质上是一套协议与制度（角色定义 + 门禁 + 记忆规则），不是运行时。它可以架在 Claude Code 和各种模型之上——我自己就是把它当“工作系统”在用。框架会过时，制度不会。

Q：为什么选择开源？ A：因为这套制度的价值不在藏，而在用。前面说了，机制列表就是事故名单——把它开源，相当于把“我踩过的坑”一起交出去，让后来者至少少踩几个。

诚实局限

• 它是为单人工程与小团队场景设计的（一个人的算力和注意力边界内），不是分布式多机编排；
• 记忆是文件式的——简单、可审计、能 git diff，但不是数据库，不适合高并发；
• 管线会主动变慢：拦截、审计、回环都要花时间。习惯“能跑就行”的场景，会觉得它烦；
• 它替代不了你的判断力。它保证的是“产出到你手里时是经过验证的”，不保证方向一定对。

如果你也想补上“制度”

不必从 14 个角色起步。建议的路径：

1. 先加三道闸门：文件存在性、EXIT_CODE 指纹、交付物脱敏。就这三个，能拦住大部分“静默失败”；
2. 写出你的“放行标准”：什么算完成？写成机器能检查的一句话。“功能完成”不算，curl /health 返回 200 才算；
3. 给它记忆和上限：跨会话的进度要有地方落，重试要有天花板。

最后说句实话：这套东西本质上不是技术，是纪律。技术部分——文件检查、退出码、快照——半天就能学会；难的是坚持让每一个产出都过门，包括你自己赶时间的时候。管线的价值恰恰在于：它替你把“赶时间时想抄的近路”提前堵死了。

项目已开源（MIT），仓库里有三个零依赖演示，5 分钟跑完：

git clone https://github.com/zw-onemaker-ai/onemaker-pipeline
cd onemaker-pipeline && python3 examples/01_quality_gate/demo.py

架构图、完整规章、14 个角色定义都在仓库里。欢迎来提 issue 拍砖。