原文 ：只加两行代码，为什么要两天？一文深度理解业务系统的复杂性（腾讯云开发者 · 刘德恩）
本文问题 ：AI 项目为什么总在排期里 delay ？有没有可能「不 delay」------或者说，什么样的 delay 才算正常？
阅读导航：开篇答标题 → §01 背景与曲线 → §02 三类 delay → §03 两行 prompt → §04 EP vs Harness → §05 耦合·腐化·敏捷 → §06 还债与门禁 → §07 五角色 → §08 结论 → 附录 A/B
先直接回答标题
几乎没见过「从不 delay」的 AI 项目 ------和传统软件一样。
但至少要先分清下面 三类「进度」表象（后文 §02）；很多人只盯第一种，忽略第三种最伤人：
| 类型 | 长什么样 | 能不能靠「换更强的模型」解决 |
|---|---|---|
| 日历 delay | 排期到了，功能没可合并、评测没过关 | ❌ 往往不能 |
| 验收 delay | 墙钟时间并不长，但不敢合并------怕牵一发而动全身 | ❌ 更不能；需要 Harness |
| 假准时 | 演示很炫，周报写「已完成」，CI 仍是红的 | ⚠️ 最伤士气；比 delay 更糟 |
所以本文想说的不是「教你零 delay」，而是：把 delay 从玄学变成工程问题------知道慢在哪、慢得是否合理、以及怎样避免「假准时」。
原文摘录（开篇必引）
业务系统复杂性一直是令开发者头痛的问题。复杂的不是增加一个需求需要耗费多少时间，而是在增加一个需求后带来的蝴蝶效应：其它功能会不会受到影响、要如何去找到这些影响，最终如何实现系统正常运行......功能之间隐秘增加的耦合、不可避免的代码腐化在导致业务复杂性增加。
然而，现实可能会给你沉重一击。如果你去问问一线的开发人员，他们可能会告诉你真实的感受是：随着向系统中添加越来越多的功能，实现每个功能会变得越来越困难而不是越来越简单。复用？基本不存在的。
如果没有意识到由 Essential Complexity 引入的耦合，开发者很可能在排期的时候少估算了天数，最后不得不需要用各种「责任感」、「Ownership」这种精神力量通过加班来尽量保证不 delay。
------摘自 《只加两行代码，为什么要两天？》，刘德恩
原文里那句 「少估天数 → 靠加班保不 delay」 ，放到 AI 项目里常常变成：少估轮次 → 靠人肉补测、半夜改 prompt 保演示 。
排期表上没 delay，交付物却不能上线------这就是下文说的 假准时。
01 为什么 AI 项目特别容易「看起来不该 delay，实际天天 delay」
1.0 业务没涨，事却变多：delay 往往从排期之前就开始了
原文 §01 里，Leader 的担忧很多团队都有------人变多不是因为用户或营收变多，而是因为要做的事变多了 。原因并不神秘：业务停滞或下滑时，产品侧要么拓边界 （一个 App 里塞更多功能、交付更多「用户价值」），要么抠体验（排版、交互、停留时长），总之要让指标动起来。
落到开发侧，就是更多需求：一个策略不涨，就上两个；一个实验不及预期，下次就 A/B 一起做。对应到 AI 项目，则是：一个 prompt 版本指标掉了，就再加 tool、再加 RAG、再加一个「智能体」------排期表上的条数涨了，真值并没变简单。
原文追问：需求变多，一定要人头变多吗？ 软件业有个怪答案：建筑修 10 栋一样的楼要 10 遍人力，软件「修一栋、复制九栋」近乎零边际成本------所以大家幻想 functionalities-cost 至少线性，好架构甚至接近对数。
| 理想（原文描述的「绿色线性」） | 一线真实感受 |
|---|---|
| 功能越多，边际开发越便宜 | 每多一个功能，下一个更难 |
| 复用沉淀、架构合理则曲线更平 | 「复用？基本不存在」 |
| 每迭代需求数应 ≥ 上一迭代，否则复盘 | 吞吐率「看起来稳定」，靠加班和假准时撑着 |
过去二十年，敏捷被不少人当作追求这条黑色线性吞吐率 的手段------每个迭代固定完成 N 个需求。敏捷派会说：要维持恒定吞吐，必须持续提炼知识 + 重构 。但现实是很多团队什么都没做，却对稳定吞吐习以为常。
原文抛了一个尖锐问题，AI 版同样适用：
到底是 Harness / 评测 / 重构那一套是画蛇添足，还是靠 996、靠「模型昨晚跑通了」在硬撑不 delay？
下面先分清 delay 类型，再展开原文 §02--§04 里那些「有意思但容易被删掉」的分析。
1.1 管理层常见的三个误判
| 误判 | 潜台词 | 实际后果 |
|---|---|---|
| 「上了 Copilot / Agent，人效应该翻倍」 | 写代码变快了，排期减半 | 验收与联调时间被低估，delay 后置 |
| 「模型更强了，这次能一次做对」 | 减少联调轮次 | 一次「看起来对」的 patch，合并后爆雷 |
| 「先 demo，细节后面补」 | 日历上不 delay | 技术债滚成 验收 delay，越拖越久 |
原文 Leader 的担忧，在 AI 项目里往往换成另一句：
「我们加人、加模型、加 MCP，不是因为用户变多了，是因为每个需求都比表上写的更贵。」
1.2 「功能---成本」曲线上翘 = delay 的指数级来源
软件行业有 几乎零成本的复用 ------所以理想中，功能越多，边际成本至少线性、甚至更低。
一线感受却是：每多一个功能，下一个功能更慢。原文把这条曲线画成指数型；AI 项目可以换成：
- 纵轴：从工单进入到
pytest变绿 的墙钟时间或对话轮数 - 横轴：已接入的 tool 数、prompt 规则条数、已交付 feature 数
现实：delay 越来越长
Feature 1
Feature 2
Feature N
排期 slip / 不敢合并
理想：Agent 越用越快
Feature 1
沉淀 Harness
Feature 2
交付时间 ↓
曲线一旦上翘，再加人、再加算力，都只是在陡峭段堆资源------日历上可能仍写「进行中」，体感已是 perpetual delay。
原文用「指数型 functionalities-cost」解释：不是某次估期粗心，而是软件模型本身的复杂性在作祟------AI 项目若只加模型、不加验收与拆分，曲线同样会上翘，只是纵轴换成「对话轮数 / 评测不过次数」。
1.3 你们项目 delay 的，可能根本不是模型
下面这张表，适合在周会里对一下「这周又 delay 了」到底属于哪一格：
| 表象 | 常被归咎的原因 | 更常见根因（本文后文展开） |
|---|---|---|
| 「就改两行 prompt」排两天 | 模型笨 | 不知道波及面；没有 pytest 真值 |
| 「Agent 昨晚跑了一宿」今早还不能发 | 算力不够 | 无 max_steps / 无门禁，在错误方向上狂奔 |
| 「评测指标掉了」要延期 | 数据不够 | 没有固定 holdout；改 prompt 无回归 |
| 「联调一直不过」 | 接口文档差 | 工具/MCP 隐蔽耦合；H5/有态双轨 |
| 「说做完了」PR 不敢合 | 开发偷懒 | 假准时：缺 Harness，只信模型 stdout |
02 三种进度表象：日历 delay、验收 delay 与假准时
功能未可合并
不敢 / CI 红
CI 绿 + 有审计
是且宣称完成
需求提出
排期 / 里程碑
Agent 写代码 / 调 prompt
日历截止日
日历 delay
敢合并吗?
验收 delay
真完成
仅 demo 可演示?
假准时
- 日历 delay：时间到了，交付物达不到 DoD（Definition of Done）。
- 验收 delay ：日历可能没写 slip，但 merge 队列堆着不敢点------和原文「改两行要两天」同构。
- 假准时 ：最消耗信任；对外「不 delay」，对内 永续验收 delay。
有不 delay 的项目吗？ 若把「不 delay」定义为「日历从不 slip」，传统软件都极少，AI 项目更少。
若把「不 delay」定义为 「说不完成就不完成、完成了就能举证」------这才是 Harness 要换来的那种「准时」。
03 「只加两行」为什么会变成「delay 两天」------原文在 AI 里的复刻
原文标题是《只加两行代码，为什么要两天》；AI 版等价物比比皆是：
| 表面工单 | 排期印象 | 真实消耗（= delay 来源） |
|---|---|---|
| 改一个字段校验 | 0.5 人日 | 要弄清是否影响导出、回调、旧客户端 |
| system prompt 加一句 | 10 分钟 | 与另三条「禁止」冲突，要回归 20 条对话 |
新开一个 read_file tool |
半天 | Deny 路径、JSONL、旧 feature 回归 |
| 「按昨天 demo 合并」 | 立刻 | demo 没跑 pytest；合并后全红 → 返工 delay |
本仓库 examples/minimal-harness 用 5 分钟 把这件事钉死：真值在 pytest，不在「模型说已完成」。
bash
pytest examples/minimal-harness -v # 先红：建立「敢 delay 验收，不敢假准时」
python -m orchestrator run --mock # Harness 驱动修复
pytest examples/minimal-harness -v # 再绿：这才叫可合并你完全可以 日历上不 slip ------若团队约定「绿了才算完」，前两天就是在买 可合并，不是在磨洋工。
04 提效的两条路：EP 缩短不了「不敢合并」的那几天
4.0 降本增效年：你感知到的「增效」可能很少
原文 §02 写过去一年很多公司推降本增效 ，但体感往往是：降本很实在，增效寥寥无几 。开发者被拉进无数「成本归属群」，中台账单下来了，省掉的本又摊回业务方；项目组自己也要精细化云资源、在技术评审里加 ROI 门槛 拦低价值需求------这些都能减少浪费，但很快碰到天花板。
更大的收益在增效 ，而增效很多人第一反应是 工程效能（EP） ：几百 G 大仓秒级、可配置流水线、RPC 框架、可观测平台......口号常是：让程序员专注业务开发 。
可 Brooks 和原文追问的是：在整个软件（或 AI）交付里，业务本身的难 ，和工程上额外制造的难，到底谁占八成？
4.1 Brooks、《凤凰项目》与「太阳系顶配 EP」
原文借 Brooks 区分 Essential / Accidental Complexity（《没有银弹》）：
| 类型 | 含义 | 带来的 delay 形态 |
|---|---|---|
| Essential（本质） | 业务规则本就复杂 | 再强的 EP 也要面对：名片系统、微信 H5 无登录态 |
| Accidental（偶然） | 工程上额外制造的复杂 | 无验收、无审计、工具无界、会话失忆 |
原文追问：若 EP（大仓、CI、观测）已顶配，业务仍变废山，EP 是否在隔靴搔痒？
若 二八法则 成立，Essential 占八成，却十年如一日只在 EP 上发力------是否像在业务复杂性上隔靴搔痒？
原文还借《凤凰项目》的魔法棒思想实验（很值得整段保留）：
假设开发者有一根无所不能的魔法棒，挥一下基础设施就到「太阳系顶级」：几万 PB 大仓毫秒级克隆、业界最强 CI、最强观测与发布------不过然后呢？ 终于可以专注业务了，但业务到底怎么开发？
无数例子表明：业务建模不合理、需求仓促上线、接口设计随意、无谓耦合------建在最牛 EP 上的系统，一段时间仍会成废山：
- 代码看得眩晕，改功能不知改哪
- 不知道影响哪些功能，改动点是否盖全
- 改个小功能要动无数处
然后 functionalities-cost 曲线再次上翘。不管 EP 多优秀，业务层仍可能是废山------所以不能只靠工具提效，必须直面 Essential Complexity。
这种想法「早该有」：真正交付用户价值、发工资奖金的，是业务代码 （AI 项目里则是 业务逻辑 + 评测真值 + 可合并的 artifact ）。业务千千万、随市场变，像开放命题；在业务里归纳 pattern 比做 scope 固定的工具难得多------所以很多同学宁愿做 infra / 平台，不愿做业务，觉得业务是增删改查、没技术含量。
对业务复杂性的低估 ，会加速废山，让曲线更陡------AI 版则是低估「对话能替代设计与测试」，于是 假准时 泛滥、验收 delay 爆炸。
AI 版问法：若 IDE、MCP、模型都已顶配，项目仍天天 delay，瓶颈在哪？
是
否
工单
Agent + Tools
业务代码 / Prompt
只有 EP?
stdout: 任务完成
假准时 → 后期大爆炸 delay
Harness
pytest / eval
JSONL 审计
可举证完成
- EP ：更快写、更快构建、更快看日志------缩短 BUILD 段。
- Harness ：谁能改
passes、什么算绿、出事查哪条 JSONL------缩短 验收 delay 、消灭 假准时。
If you're not the model, you're the harness. ------ 综述
05 delay 的两个加速器：隐蔽耦合 + 不可避免腐化
原文归纳业务复杂的根因；它们不制造「模型变慢」，而制造 「每次估期都偏乐观」。
5.1 隐蔽耦合：排期少估 → 只能靠加班「保不 delay」
原文 §03 开头假设：先抛开人的因素 （人都是理智、有追求的），业务复杂的根因主要是两个------隐秘增加的耦合 、不可避免的腐化。下面按原文案例展开（保留分析链），再映射 AI。
项目初期都很好，为什么后来改不动？
绝大部分项目一开始都有「整洁架构」的心：函数粒度、模块职责、单测与可测性；需求快时一天几千行也不罕见。
即便如此，时间一久仍会 牵一发而动全身 ------改功能 A 却要盯功能 B。原因：耦合 。很多人一提耦合就厌恶，但不合理耦合之外，还有不可避免的耦合：Essential Complexity 下，多模块本来就要集成才有意义，A→B→C→反馈 A，这就是耦合。
高内聚，低耦合 ------不少人只记后三字，忘了前三字：高内聚的边界内，模块本来就是强耦合的；即使用心拆架构，这种耦合也难消掉。
案例一：社区 App 与「名片系统」（原文完整脉络）
某社区类应用，模块大致包括（多由不同小 Team 负责）：
| 模块 | 形态 |
|---|---|
| 资讯 | Feeds 流，左文右图 |
| 社区 | 类似微博的发图文动态 |
| 评论区 | 资讯、动态下评论 |
| ... | 其它独立业务 |
名片系统 需求：用户自定义头像旁展示哪些标签（勋章、会员、认证等），初看只需「配置页 + 各头像位读配置」------排期很容易少估。
深入后（原文重点，不是「查多系统麻烦」，而是新概念被绑在一起）：
- 配置端耦合 ：勋章来自成就系统、VIP 来自会员、黄 V/蓝 V 来自认证------设计之初互不相关的概念，被本需求事后关联 ；需求变长尾（凡身份相关都要想起名片）。
- 签约作者：资讯 PM 做签约体系，除了调推荐，还得去「基本没关系」的名片系统加「签约作者」标签。
- 「也可以不全支持」 ：产品常这么说------但负向体验、舆情处理不及，收益可能不如代价（周五傍晚改需求式 delay）。
- 展示端两难 ：Feed、动态列表、评论、详情页头像样式本不一致；现在要加名片------位置不够放哪些标签？谁定权重？逻辑放名片系统则每增场景改名片 ；放各场景则各场景不能忘了名片------怎么选都强耦合。
- 长尾恐惧 ：即使这次全改完，以后凡动头像 都要考虑名片；新人没参与过名片需求 → 上线后紧急 fix------开发者怕的往往不是功能难，是不知道改这里会波及哪、别处是否也要改。
新需求必须考虑与旧特性如何结合；功能膨胀 → 额外负担累积 → 每个迭代还想恒定吞吐？痴人说梦。
AI 映射：多 MCP、共享 system 片段、跨 feature 的 tool 依赖------同构的长尾与「新人漏改 prompt 规则」。
案例二：分享到微信 / H5 无登录态（原文完整脉络）
App 要裂变，常要把内容分享到微信；微信里只能是 H5 ，而 App 多为原生------同一需求至少做两遍 。更麻烦：H5 打开无登录态，后台要支持无态调用。
| 难点 | 原文分析 | 带来的 delay |
|---|---|---|
| 接口强依赖登录态 | 详情要浏览记录、阅读量+1、未关注则展示关注按钮等 | 无态必须阉割部分能力 |
| 在原接口 if/else | Bad taste，鉴权网关也难维护 | 技术债 + 联调 delay |
| 新开 H5 专用接口 | 更干净，但等于另一个需求 | 双套接口长期维护 |
| 阅读量去重 | 无态无法按用户去重；每次累加怕被灰产刷；不累加对作者不公 | 产品可能要有效阅读量 + 无态阅读量两套指标 → 又一个需求 |
此后凡支持「分享到微信」：客户端一套、H5 一套简化版；后台给 App 一套 API、给 H5 一套定制 API------长尾 + 后续开发者工作量 ×2 。
这是架构写烂了吗？原文：不是 ，是 Essential Complexity 的天然耦合；后期每改一处，常要改 n+1 处。工程上的架构/模式只会把复杂性从一个位置搬到另一个位置，不会消灭------No Silver Bullet。
AI 映射 ：有登录态 tool 链 vs 无登录态/demo tool 链；评测环境 vs 生产环境双轨------合并前一夜才发现 eval 路径不一致，是典型的 验收 delay。
| 原文场景 | AI 项目映射 | 对排期的影响 |
|---|---|---|
| 名片读多系统 | 一 feature 调 5 个 MCP，顺序未文档化 | 联调轮次 ×N |
| 展示端统一 vs 分散 | 名片/标签逻辑放 Orchestrator 还是各 Agent 子图 | 怎么选都耦合 |
| 分享微信 / H5 无态 | 有态/无态两套 tool 或接口 | 后续需求 工作量 ×2 |
| 复杂性不灭，只能搬运 | 加 RAG、加规划器，规则还在，只是换了个堆 | 假「架构升级」不消除 delay |
Harness 消不掉本质复杂，但让耦合可见、可测：
features.json：一条需求一条 pytest nodeid。- 只有 Orchestrator / CI 能写
passes------模型不能改清单自证完成。 sessions/*.jsonl：delay 了能查「卡在第几步、调了谁」。
5.2 腐化：废山代码 → 废山 prompt → 「越赶越 delay」
除了耦合，原文 §3.2 讲 不可避免的代码腐化。很多同学生过这条心路（原文用表格概括，值得保留）：
| 阶段 | 心态（原文） |
|---|---|
| 项目刚开始 | 维护前人废山是无奈；从零开始，要让所有人看到什么叫整洁架构 |
| 开发过程中 | 时间倒排；CR = 企微回个 d；需求扭来扭去；单测失效 →「算了不跟自己过不去」 |
| 后期 | 「废山大家都不想的啦，这次不算，下次一定，我煮碗面给你吃」 |
作者的两段亲身经历（原文）
- 维护巨坑 ：无文档；一个 PHP 文件几万行、一个函数上千行、一个接口多种 JSON response；几十人疯狂 push；改功能心惊胆战------对弱类型栈心有余悸（delay 来自恐惧，不敢动）。
- 从零运营系统 ：按《整洁架构》《重构》《设计模式》《领域驱动》《演进式架构》实践；每天晚饭后 ≥1 小时 Code Review ，争执面红耳赤，抵制 Bad Taste；上线很成功，后因组织变动离开，自以为给接盘方留了「好基础」------一年后同事吐槽：看不懂、风格怪、难扩展，最后重写 。
作者结论：熟读经典、从零、认真 CR，仍挡不住腐化------成了后人口中的废山始作俑者。
代码如何 腐化？原文谦称不比那些书讲得更清楚，故只讲为什么不可避免 ：架构与抽象只能面向当下，最优秀的架构师也无法逾越这种局限。
| 腐化形态 | 表现 | 与 delay 的关系 |
|---|---|---|
| Prompt 堆叠 | 500 行 system，规则互斥 | 每改一句都要全量回归 |
| 会话失忆 | 新会话不知进度 | 重复劳动 = 隐性 delay |
| 假通用 RBAC | 接不住「帮派权限」（见 §5.3） | 重写 = 大 delay |
| Free as Puppy 的「公司统一 Agent」 | 能跑，难改 | 每个需求都在铲屎 |
5.3 瀑布 vs 敏捷：你以为在选流程，其实在选「哪种 delay」
原文在讲「腐化不可避免」时，专门用了一整节对比 瀑布流 与 敏捷 ------这不是跑题，而是在解释：为什么 AI 项目也会越迭代越难准时。下面保留原文脉络，并接到 delay 语境。
瀑布流式开发：用「长周期」换「全局视图」，但日历 delay 爆炸
瀑布流是上世纪常见的模式：甲方提需求 → 调研具象化 → 需求文档签字 → 架构师在看见全部需求的前提下做设计与模块拆分 → 分模块开发 → 集中测试 → 甲方验收 → 交付。前一步没完，下一步不能开始，像瀑布顺流而下。
| 阶段 | 瀑布的「优势」 | 带来的 delay 形态 |
|---|---|---|
| 需求签字 | 范围相对稳定 | 签字前拉扯久，前期日历 delay |
| 架构设计 | 架构师有全局视图 | 设计周期长 |
| 分模块开发 | 并行开发 | 联调前「看起来进度正常」 |
| 集中测试 / 验收 | 一次性集成 | 后期大爆炸 delay：联调痛苦、验收返工 |
原文指出：周期动辄 6 个月～3 年 ，市场变了、预算超了、技术过时了，项目还没做完------这是典型的 日历 delay 。更痛的是末期：「当初要 XXX，你们做的是 YYY」→ 大量返工 → 再次延期。
大家现在一个小需求多方联调都觉得苦，想象所有功能开发完再测------这就是瀑布末期 delay 的来源。
问题堆积
理解不一致
需求调研+签字
架构全局设计
分模块开发
集中测试
甲方验收
交付
后期大爆炸 delay
对 AI 项目的映射 ：少数团队仍用「大 PRD 一次性定稿 → 集中接 Agent 开发 → 最后才跑评测」------本质仍是瀑布：demo 阶段不 delay，合并前一夜全员 delay。
敏捷开发：用「半成品」换「活下来」，但完成品可能更慢
敏捷是对瀑布的修改：不要等所有需求齐活再设计，而是 小步快跑、做一点交一点。原文用造汽车打比方：
- 先做发动机 + 四个轮子 + 驾驶员绑凳子 → 先跑起来
- 再加后视镜；没人关心就不投入
- 市场好再加挡风玻璃、沙发座椅......
这才是敏捷：在迭代里识别什么更重要，快速响应市场。
但原文强调了一个常被误解的点------敏捷 ≠ 更快交「完成品」：
| 维度 | 瀑布 | 敏捷 |
|---|---|---|
| 完成品交付速度 | 若需求不变，一次集成看似「快」 | 往往更慢------半成品要反复改 |
| 日历/market delay | 末期易爆雷 | 先活下来，减少「做出来没人要」 |
| 设计完整性 | 曾有全局视图 | 天然欠考虑，后期改贵 |
| 典型失败 | 做了 3 年市场不需要 | 缝缝补补又一年，废山 |
敏捷的优势不是消灭 delay，而是把 delay 从「致命末期」挪到「可接受的迭代里」------活下来再谈成本和优化。
「中华田园敏捷」：你已经在敏捷里了
原文问：我们团队能不能试敏捷？答：现在不就是吗？
流程上和国外敏捷有差异，可称 「中华田园敏捷」 ：App 先发 MVP，每迭代产品只提有限需求，开发做完就上线，埋点/报表看收益，然后不断堆功能------缝缝补补又一年。
这和许多 AI 团队高度同构：
| 田园敏捷（原文） | AI 项目版 |
|---|---|
| 每迭代几个有限需求 | 每周几个对话能力 / 几个 tool |
| 开发做完就上线 | prompt 调完就发，评测后补 |
| 埋点看收益 | 看板指标 / 人工抽检 |
| 堆功能、缝补 | 堆 MCP、堆 system 规则 |
和腐化的关系：没有全局视图 → 架构只能面向当下 → delay 越估越偏
原文的关键推论（建议整段细读）：
每次做技术方案，能拿到的只是宏大视图中的一小角 ，根本没有全貌，并不能像瀑布里架构师那样看见整体。仅凭这一点信息，再牛的架构师方案也有局限------不是人的问题，是开发方式的问题。
更糟的是：局部需求里，很多人连局部设计都不做 ------controller 解析入参 → service 调 RPC/DB → DAO 查表。原文估计这类情况 80% 以上 。
少量局部设计 + 还不一定合理 + 80% 无设计 + 上千种 Bad Taste → 代码不腐化才怪 → 每个新需求都更 delay。
对 Agent 团队：
- 没有
features.json全貌，只有当前工单的 prompt 片段 → 和田园敏捷同构的短视 - Agent 能「秒出代码」，反而掩盖了 没设计就上线 → 假准时 增多，验收 delay 后置
案例：通用 RBAC 与「帮派权限」------两周后打脸
原文经典例子（说明「通用」在田园敏捷里为何常变成 Puppy）：
后台管理系统按 RBAC 做了权限模块，为多业务复用加了 租户 appid，Role/Access 带 appid------设计「按理说还可以」。
两周后新需求：帮派管理 ------帮主全权；可设副帮主、长老、堂主等管理组；组之间有权重 ，高权重组可管低权重组。表面仍是 RBAC，但 Role 之间要互相感知、有优先级------和「Role 互不知晓、只挂 Access」的原始模型不同。
| 设计时假设 | 两周后现实 | 结果 |
|---|---|---|
| 多租户 RBAC 够通用 | 要 Role 图 + 权重 | 模型不够用 |
| 后台 QPS 低，读 MySQL | 新业务要高 QPS + Redis | 性能路径不同 |
| 为「通用」省了工时 | 复盘：谁能想到要做帮派？ | 另起一套 → 大 delay |
原文追问：若当初多考虑扩展性，工时上去，又怕 过度设计 ------田园敏捷下，架构师永远在 少估 / 过设计 之间两难，最后常表现为 排期不 delay、合并 delay。
AI 映射 ：「公司统一 Agent / 统一 Orchestrator / 统一 Skill 库」若只按当前 1～2 个场景建模，两周后的「帮派型需求」（多 Agent 编排、Role 互管、有状态工作流）仍会打脸------不是模型不行，是 Essential Complexity 和当时的信息不对称。
Free as Beer vs Free as Puppy（原文）
| 说法 | 含义 | 和 delay |
|---|---|---|
| Free as Beer | 拿来就用的真复用（如成熟 ERP/CRM、明确边界的 SaaS） | 边际成本低 |
| Free as Puppy | 免费领回家，铲屎照护归你 | 短期不 delay，长期 越改越 delay |
「通用 XXX 系统」若未经场景边界设计，对用户就是 Puppy------不如 Yet Another ... 再造一套。
原文还有一段做通用之前必问的拓展（建议原话精神保留）：
- 业界/公司是否已有同类产品？你为什么不用？
- 你不愿用的那个，也想做通用------它为什么没做成 Beer？
- 你去做，有自信这次是 Free as Beer 而不是 Puppy 吗？
Free as Beer 的系统往往场景明确 ：ERP、CRM、边界清晰的 SaaS/PaaS，才能在内部充分建模。
腐化更核心的来源常不是「某次代码写得烂」，而是系统架构的腐化 ：田园敏捷下需求零散、目标模糊、无全局视图 → 架构只能适应当下 → 项目发展后架构失效 → 在失效架构上修修补补、魔改，只会更难懂、更 delay。
AI 里：未界定边界的「通用 Agent 壳」同理；本仓库用 最小 Harness （orchestrator + login 示例）刻意避免 Puppy 化。
盲目复用 ：在函数后不断加参数、在 prompt 末尾不断加「例外条款」------原文说可能适得其反，Agent 项目里表现为 context 爆炸与回归不可测。
小结：瀑布、敏捷，都「有不 delay 吗」？
| 模式 | 少哪种 delay | 多哪种 delay / 债 |
|---|---|---|
| 瀑布 | 早期需求摇摆（签字后） | 末期集成、验收大爆炸 |
| 敏捷 / 田园敏捷 | 「做出来没人要」 | 完成品更慢、架构短视、腐化 |
| + Harness | 假准时、验收不敢合并 | 前期写测（日历略长，合并可信） |
所以原文那节不是在讲方法论怀旧，而是在说：别指望换开发模式就不 delay ；敏捷换的是 delay 的类型。AI 项目若只有「田园敏捷 + 大模型」，没有 Harness 真值，只是把瀑布的末期 delay 拆碎撒进每个迭代 ，体感就是 「有不 delay 的 AI 项目吗？」------没有，只有 delay 藏没藏住。
06 怎样让 delay「可预期、可砍价、可还债」
原文 §04 总结 同样精彩，不少团队只抄了「敏捷」，没抄「还债」------下面保留原文分析，并接到 Harness。
6.0 程序员的黑暗森林？不怕难，怕腐化 + 知识蒸发
由于 Essential Complexity，No Silver Bullet。田园敏捷带来几乎不可避免的腐化------难道这就是程序员的黑暗森林？
原文说：程序员并不怕 Essential Complexity ------状态好时日敲千行不在话下。
最怕的是代码腐化 。许多设计决策、「为什么要这么写」是 内隐知识（Tacit Knowledge） ，只存在于最早那批开发者脑子里；人忘、人走，知识就永久丢失 。
文档沉淀内隐知识很重要------道理都懂，谁愿费劲写？
于是出现原文里很扎心、也很真实的人性：
谁愿前人栽树后人乘凉？多堆需求帮业务挣钱、拿五星晋升不香吗------我为什么要防腐、为什么要写文档？
AI 版同构：谁愿维护 features.json、固定 holdout、写 JSONL 规范？多接几个「智能体 demo」汇报不香吗------直到 验收 delay 和 假准时 反噬整个团队。
6.1 EPC、重构、以及和产品 battle 的时间
| 手段 | 原文观点 | 对 delay 的含义 |
|---|---|---|
| 事前 EPC / 规范 | 有用，但只抬高代码质量下限 | 挡不住结构性腐化 |
| 重构 | 结构性问题只能靠它；本质是事后诸葛亮 | 更多信息后回头看局限，该拆就拆、该提公因式就提，再刻意留一点灵活性 |
| 要排期 | 重构收益难量化：吞吐率提升多少？讲不出数怎么和产品 battle、怎么向管理层要时间？ | 很多 refactor 死在「没排期」→ delay 持续恶化 |
Harness 的可量化点 （相对传统重构）：pytest 绿/红、固定 eval 集分数、passes 完成率、每 feature 对话轮数------便于把「还债」写进迭代，而不是纯靠情怀。
6.2 技术债像房贷：窗口期过了，delay 会逼你还
原文用 十年前北上深贷款买房 类比技术债，值得整段保留精神：
- 增长期举债换速度------当时看是压力，回头看可能是红利。
- 任何红利都有窗口期。
- 当 functionalities-cost 陡峭到每迭代加班赶 deadline 、改功能要翻三层历史考古 ------窗口已关，债务在倒逼你。
- 问题不是要不要还，而是：有余力时主动还，还是被系统崩溃逼着还。
- 前者叫 重构 ，后者叫 重写 ；中间差的，往往是整个团队半年的士气。
AI 项目：demo 阶段举债（无测试、无审计）换发布会亮点；一旦要合规合并、要追责 ，若仍无 Harness，往往直接从「假准时」滑向 重写 Agent 栈------日历 delay 最大的一种。
6.3 工程应对：防腐、沉淀，与三类「准时」
原文结尾的应对------代码防腐 + 知识沉淀------方向直接；难点在「嫌麻烦」。下面把原文应对与 Harness 并表。
三种策略对比
| 策略 | 日历 delay | 验收 delay | 假准时 | 适用阶段 |
|---|---|---|---|---|
| 赌模型 | 先压短排期 | 后期爆发 | 高 | 原型/demo |
| 堆人加班 | 表面不保 delay | 人燃尽 | 中 | 不推荐常态化 |
| Harness 真值 | 可能略长（要写测） | 显著缩短 | 低 | 要合并、要审计 |
第三种不是「不 delay」，而是 delay 发生在排期里承认的地方（写测试、拆 feature），而不是发生在 merge 前夜。
6.4 给 Tech Lead 的 delay 预算表（可直接贴进评审）
| 检查项 | 通过标准 | 不过会怎样 |
|---|---|---|
| DoD | 有 pytest/eval nodeid，CI 可跑 | 假准时 |
passes 归属 |
仅 Orchestrator/CI 可写 | 进度造假 |
| 工具面 | 新 MCP 有 Deny + JSONL | 隐蔽耦合，后期 ×2 delay |
| 回归 | 改 prompt 跑固定 holdout | 评测掉了才发现 |
| 成本 | max_steps、token 报表 |
一夜长跑，第二天仍不能发 |
细节见 架构师 Review 指南：不信 stdout「任务完成」，只信 exit code 与 JSONL。
6.5 映射到本仓库：债 vs 投资
| 概念 | Agent 实践 |
|---|---|
| 内隐知识 | 只在某次对话里的「为什么这么改」 |
| 知识沉淀 | features.json + JSONL + 实战手记 |
| 防腐 | pytest 树 hash、harness-ci.yml |
| 主动还债 | 在 CI 仍绿时拆 feature、缩 tool |
| 被迫重写 | 换框架但不换真值------往往更 delay |
Prompt
Context / MCP
Harness Engineering
features.json
orchestrator
GitHub Actions
07 五个角色：各自看到的 delay，以及如何对齐
原文主要从一线开发 / 架构 视角讲复杂性；真实项目里 delay 往往是「角色对完成定义不一致」 ，而不是某一方不努力。AI 项目还多一层：演示成功 ≠ 可上线。下面按五个常见角色拆开------便于你转发给对应同事，也便于开评审时对表。
7.1 一表看清：谁怕哪种 delay
| 角色 | 最常感知的 delay | 容易造成的「假准时」 | 应盯的硬证据 | 与 Harness 的分工 |
|---|---|---|---|---|
| 产品经理 | 策略不上线、指标没跑出来 | demo 通过就当「已交付」排下期 | 需求是否拆成可验收 feature；DoD 是否写清 | 定义 feature 描述/优先级（进 features.json），不写 passes |
| 项目经理 | 里程碑 slip、依赖阻塞 | 用「Agent 已跑完」填进度条 | 里程碑绑 CI/评测 而非人报 % | 看板展示 passes + 阻塞原因（JSONL 链接） |
| 架构师 | 耦合扩散、要重写 | 拍板「统一 Agent 平台」却无边界 | 工具图、权限档、技术债窗口 | 定 Harness 边界、tool 面、 Review 清单 |
| 研发 | 不敢合并、联调、返工 | 模型 stdout「完成」就提 PR | pytest/eval 绿、diff 可审 | 实现业务与 prompt；不 自改 passes |
| 测试 | 测不完、漏场景、回归炸 | 只测 happy path，未测 tool 越权 | 固定 holdout、契约、权限用例 | 共建真值集；CI 红则 一律不算完成 |
仅 O/CI 写 passes
产品经理
价值与范围
features.json
验收标准描述
项目经理
节奏与依赖
里程碑 = CI 绿
架构师
边界与债
Harness 规则
研发
实现
PR / 代码
测试
真值
pytest / eval
Orchestrator
可合并 / 可发布
7.2 产品经理：别用「演示过了」换「可以上线」
典型困惑：「上周 demo 明明对话很顺，为什么本周还说 delay？」
| 现象 | 背后常是 | 建议 |
|---|---|---|
| 名片/分享类需求排期很短 | Essential Complexity 被低估（见 §5.1） | PRD 里写波及模块/场景清单，接受「长尾」 |
| 「也可以不全支持」 | 验收 delay 转成舆情 delay | 明确 MVP 砍 scope，而非砍质量门禁 |
| 指标没动要加功能 | 日历不 delay，学习周期在拉长 | 固定 holdout 评测，再决定加 tool 还是改 prompt |
DoD 建议写进需求（可复制）：
- 每条能力对应
features.json一条 + 自动化验收（pytest nodeid 或 eval 集 ID） - 「完成」= Orchestrator/CI 把
passes置 true，不是聊天记录截图
产品不必懂 Harness 实现，但要认：没有真值的需求，默认会假准时。
7.3 项目经理：管日历，更要管「三种完成」
典型困惑：「开发说做完了，测试说没法测，到底 delay 谁？」
先 classify（见 §02）：
| 报工说法 | 实际状态 | 看板建议 |
|---|---|---|
| 「Agent 跑通了」 | 可能是 BUILD 完成 | 状态：开发中，直到 CI 触发 |
| 「PR 提了」 | 验收 delay | 状态：待门禁，绑 PR/check 链接 |
| 「CI 绿了」 | 真完成（仍可等发布窗口） | 状态：可发布 |
排期技巧（来自原文「少估 → 加班」的教训）：
- 对「只加两行 prompt」类工单，预留 回归与波及 缓冲，或强制拆 feature
- 里程碑里单独列 「还债迭代」（重构/补测），和产品 battle 时用 §6.1 的可度量指标，而非空讲「质量」
- 依赖别只标「等后端接口」------AI 项目多加 「等评测集 / 等 Harness 规则」
7.4 架构师：防的是半年后的大 delay
典型困惑：「模型、MCP、CI 都上了，为什么曲线还在上翘？」
原文 + 本文的架构师结论：
| 决策 | 短期 | 长期 delay 风险 |
|---|---|---|
| 无边界「公司统一 Agent」 | 接入快 | Free as Puppy，帮派需求一来就重写 |
| tool 无限开放 | demo 炫 | 隐蔽耦合、越权、审计缺失 |
无 passes 归属 |
进度好看 | 假准时，合并前夜全员 delay |
| 只在 EP 上投资 | 写得更快 | 废山依旧（魔法棒悖论，§4.1） |
架构师应拍板的 Harness 最小集 （与 架构师 Review 指南 一致）：
- 真值：pytest / 契约 / eval，退出码为准
- 权限：Auto / Approval / Deny
- 状态：
features.json+ 会话 JSONL - 治理：谁可写
passes、token/max_steps上限
技术债窗口（§6.2）：架构师要在「还能绿」时推动拆 feature、缩 tool------别等被迫重写才讲「当初应该」。
7.5 研发：最怕的不是写得慢，是不敢合
原文「改两行要两天」主要是研发体感 ；AI 时代叠加 模型过度自信。
| 研发心声（原文/本文） | 工程解 |
|---|---|
| 不知道改这里会波及哪 | feature 粒度 + pytest 红绿划定范围 |
CR 只能回 d |
倒排时仍保留最小门禁；Harness 自动挡明显烂 patch |
| 单测修了又坏 | tests 树 hash 进 CI；改测要同 PR 说明 |
| 知识在人脑里 | 关键决策进 PR 描述 / JSONL，别只留对话里 |
边界 ：研发可以驱动 Agent 改代码，但 passes 只由 Orchestrator/CI 写 ------避免「模型改 JSON 自证完成」。本仓库 orchestrator 即此职责分离的参考实现。
7.6 测试：从「测不完」到「定义完成」
AI 项目里测试常被夹在中间：产品要快、研发说模型测过了、没有固定真值就永远测不完。
| 测试痛点 | 根因 | 对策 |
|---|---|---|
| 「不知道测什么算过」 | DoD 是「体验好用」 | 与产品共建 holdout + 阈值（可写在 feature 旁） |
| 回归爆炸 | prompt/tool 任意改 | CI 必跑固定集；改 prompt 必须带 eval diff |
| 安全/越权漏了 | 只测功能不测 Harness | Deny 用例、JSONL 抽检、工具白名单 |
| 被甩锅「测试 delay 发布」 | 实际是验收 delay | 站会明确：CI 红 = 未完成，与研发同源真值 |
测试在 AI 项目里的地位应升级：不是最后一道坎，而是「完成」的定义者之一 ------与架构师、研发一起维护 tests/ 与 eval，而不是接无穷无尽的「帮看下 demo」。
7.7 站会 / 评审：五句话对齐（避免扯皮式 delay）
| 顺序 | 问题 | 谁回答 |
|---|---|---|
| 1 | 这条需求对应的 feature / nodeid 是什么？ | 产品 + 研发 |
| 2 | CI / eval 现在红还是绿？ | 研发 / 测试 |
| 3 | 若红，阻塞在 BUILD 还是验收？ | 全员 |
| 4 | 新 tool / MCP 是否更新 权限与 JSONL？ | 架构 + 研发 |
| 5 | 本周是 交付 feature 还是 还债迭代？ | 项目经理 + 架构 |
五方对齐后，「有不 delay 吗」会变成可讨论的具体问题：是日历 slip、验收不敢合，还是有人在假准时------而不是互相觉得对方在磨洋工。
08 再回答一次标题：有不 delay 的 AI 项目吗？
原文收束：Essential Complexity 不灭；田园敏捷带来几乎不可避免的腐化------这不是悲观，而是换一副眼镜看「为什么总在 delay」。
如果「不 delay」= 日历从不 slip： 几乎没有，也不该作为唯一 KPI------Essential Complexity 和短视架构决定估期总会偏乐观（原文、Brooks 皆然）。敏捷追求的那条「黑色线性吞吐」，要靠持续重构与知识沉淀才能维持；什么都不做却指望稳定吞吐，才是许多 AI 项目 delay 的温床。
如果「不 delay」= 从不假准时、合并前有真值、delay 可解释可复盘： 可以做到，而且这正是 Harness Engineering 的目标------不是消灭等待，而是消灭 「以为完成了」 的那种等待；并在窗口期关闭前，用可度量的方式做主动重构 ，而不是等废山逼你 重写 + 赔上半年士气。
| 问题 | 只堆 EP / 只换大模型 | + Harness |
|---|---|---|
| 改两行要两天 | 模型自信加速踩雷 | pytest 划定波及面 |
| 排期总偏乐观 | 靠加班「保不 delay」 | 耦合写进 feature + 测 |
| 废山 | prompt 堆到没人敢改 | passes 机器真值 |
| 人走了 | 知识没了，越修越 delay | JSONL + 可跑文档 |
没有银弹，没有零 delay 的 AI 项目；但有「不骗自己人」的 AI 项目------那一种，反而更少深夜返工，长期日历也更可信。
附录 A：原文与本文概念对照
| 原文术语 | 本文 / delay 语境 |
|---|---|
| 少估天数 → 加班保不 delay | 少估轮次 → 假准时 → 更大返工 delay |
| functionalities-cost 曲线上翘 | 每个 feature 变绿越来越慢 |
| Essential / Accidental | 业务难 vs 缺 Harness 的偶然债 |
| 名片 / 微信分享 | MCP 耦合、双轨 tool |
| 瀑布流 | 大 PRD 定稿 → 集中开发/评测 → 末期大爆炸 delay |
| 敏捷 / 中华田园敏捷 | MVP + 每迭代有限需求；完成品更慢、架构短视 |
| 造汽车 / RBAC vs 帮派 | 半成品迭代；「通用」权限/Agent 两周后打脸 |
| Free as Beer / Puppy | 真复用 vs 免费领养的长期 delay |
| 高内聚 / 低耦合 | 边界内强耦合不可避免；AI 里 tool 图同理 |
| 降本增效 / 成本归属群 | 降本易增效难；EP 不等于少 delay |
| 《凤凰项目》魔法棒 | 顶配 EP 后业务仍可能废山 |
| 业务 vs infra 偏好 | 低估业务复杂 → 废山 + 假准时 |
| 心路路程三阶段 | 整洁架构 → 倒排 CR 敷衍 → 废山 |
| Tacit Knowledge | 内隐知识随人流失 → JSONL / features |
| EPC vs 重构 | 事前规范只抬下限；结构性靠重构 |
| 重构 vs 产品 battle | 吞吐率/评测要有数才能排期还债 |
| 技术债窗口期 / 房贷类比 | CI 还绿时投资 Harness；否则被迫重写 |
| 主动重构 vs 被迫重写 | 拆 feature vs 换框架但不换真值 + 士气 |
| 程序员黑暗森林 | 不怕难，怕腐化；文档懂但不愿写 |
| 五角色 delay 矩阵 | §7.1：产品/项目/架构/研发/测试各怕哪种 delay |
| 站会五句话 | §7.7：用 CI/真值对齐，减少扯皮式 delay |
致谢 ：论证框架与案例来自刘德恩 《只加两行代码，为什么要两天？》。
延伸阅读 ：The Anatomy of an Agent Harness