SDD 里会留下的那一半

"A 的上限取决于 B"这种断言，天然只在 A 的能力落在某个窄区间时才成立。

2022 年这句话是错的。 那时模型连稳定跑通一个函数都困难，你工程素养再高，放大器倍数接近零，什么也放大不出来。

再往后某个时点它会再次变错——不是因为工程素养不重要了，而是因为工程素养里可传授的那部分会被吸收进工具。这不新鲜：编译器成熟之后，手写汇编的技能就是这么贬值的。不是它没价值，是它变成了工具的内脏。

大模型这一轮在写代码上跑得比别的领域快，最根本的原因是代码有裁判——能不能编译、测试红不红、跑起来对不对，机器自己判得清。凡是能被"生成 → 验证 → 打分"这个循环吃掉的能力，早晚都会被吃掉。

按这个判据，工程素养可以拆成三层：

第一层 · 熟练度

语法、API、框架。裁判是编译器和类型检查，又快又准——已经贬值了。

第二层 · 结构性判断

模块边界、接口设计、什么时候该抽象。有裁判，只是慢——一个模块拆得好不好，要等第三次改需求时才见分晓。慢裁判也是裁判，只是收敛得慢一点。正在被吸收。

第三层 · 问题定义

解决谁的什么问题、什么算做完。没有裁判，因为答案不在代码里，在市场、在用户、在你公司今年的战略里。不会被吸收。

原文那句"需求分析、架构设计、模块拆解、质量验证——这些基本功不但没过时，反而更重要了"，把第二层和第三层揉成了一句。 第二层会贬值，第三层不会。揉着说的后果是让人在正在贬值的地方加倍投入。

同一个需求，用 4000 行完成的方案比用 800 行完成的更差。多出来的 3200 行是往后每一次改动都要付的利息。

用投入量当产出量，是个古老的错误，只是 AI 让它变得更诱人了——因为现在生成量可以轻易做到很大。

为了守住"0 手写"这个数字，人会倾向于让 AI 重写整个文件，而不是自己动手改那两行。

这是纯浪费，但在指标上是加分的。任何指标一旦被当成目标，就会开始扭曲被测量的行为——而"0"这种绝对化的指标没有任何缓冲余地，扭曲最严重。

Google 的 DORA《2025 State of AI-assisted Software Development》里有两条并列的结论：AI 采用度与交付吞吐量正相关，同时与交付不稳定性正相关——变更失败更多、返工更多、问题解决周期更长。

两条并存说明"产出量"和"能用于生产"是两个独立变量。原文用前者去证明后者，中间那一步没有支撑。

缺陷密度

每千行的线上缺陷数，和同团队人写的基线比。当时就能测。

事故后的平均定位时间

这条最诚实。人对自己写过的代码有肌肉记忆，对生成的代码没有。凌晨三点报警响的时候，这个差距会以最残酷的方式暴露出来。

六个月后的改动成本

同类需求，改一次要多久。必须等——而"4000 行 0 手写"这个说法出现的时间点，多半还没到能测这条的时候。

我不知道那 4000 行是什么项目——多长周期、什么类型、上没上线、有没有人在维护。正因为不知道，我没法评估它。 而这恰恰说明问题：一个必须补齐这么多背景才能评估的数字，本来就不该被当成论据放在结尾。

针对 SDD 现在最有力的批评大概是这样：SDD、各种 Agent Skills、插件套装，本质是同一条路线，天花板在于它优化的是"人怎么用 AI"，而不是"AI 怎么用环境"；更尖锐的说法是，这等于在 AI 时代重新引入了瀑布模型。

这个批评打中了，但只打中一半。因为 SDD 里其实有两样性质完全不同的东西，被打包成了一个方法论。

它的价值不依赖任何流程，只依赖一个朴素的事实：你脑子里的标准如果不写出来，就没有任何东西能验证它。

模型再强也读不到你没说的话。你以为"当然要考虑并发"，它不知道；你以为"这个字段肯定不能为空"，它不知道。这类隐性假设不写下来，就只能等到它被违反时才发现。

关键在于：这件事的收益随模型变强而上升，不是下降。模型越强，它执行你写下来的东西越准；于是你没写下来的部分，就成了唯一的损耗来源。

真实开发里，一次测试失败可能来自实现、环境、数据、架构假设、需求理解中的任何一层。

阶段闸口的问题是，它逼你把任何失败都回退到"重新出方案再生码"，于是把那些已经做对的判断一起推倒重来。

我不想把话说绝。在不可逆的地方设人工闸口是完全合理的——数据库迁移、生产环境变更、涉及合规和资金的操作。那不是流程洁癖，是风险控制。 错的是把闸口设在认知环节：需求理解、方案设计这些本来就该反复来回的地方。

它把这两半捆着说了。 于是它最有价值的洞察（外化意图）被最容易被攻击的部分（阶段闸口）连累了。 拆开看，前半会留下，后半会消失。

一个管单次任务的偏航，一个管跨任务的经验损耗。把它们并列而不是混成一锅，说明想清楚了。这是那段文字里我最认同的部分。

自进化记忆的收益模型是复利的——每条记忆都会影响之后所有决策。

而复利对错误同样成立。

看归因链就明白了：

一条正确的记忆被引用 → 结果好 → 但没人会回头去表扬那条记忆。

一条错误的记忆被引用 → 产生一个 bug → 这个 bug 被归因到"这次 AI 没写好" → 没有人回溯到那条记忆。

归因链在这里断了。断了就没有纠错回路，错误只会沉淀、复用、被反复引用，最后因为出现频率高而显得像是共识。

每条记忆带来源和写入时间

没有来源就没法复核，没有时间就不知道它有多老。这条最便宜，先做。

定期复核，优先查引用了具体名字的

凡是提到具体文件名、函数名、配置项、字段名的，是最容易过期的一类——代码改了，记忆不会跟着改。一条说"用 X 函数处理"的记忆，在 X 被删掉之后，会稳定地把人引向死路。

引用后结果的回写

让"这条记忆被用了三次，其中两次导致返工"这样的信息浮上来。最难也最关键——没有这一条，前两条只是卫生习惯，成不了纠错回路。

任何一套记忆机制，只有写入没有淘汰，都会随时间变成负资产。

一、线上出问题的时候，有人能在不重读全部代码的前提下定位吗？ 如果答案是"得先让 AI 把这块解释一遍"，那这套东西还没到生产可用——你只是把理解成本推迟了，没有消除它。

二、这套东西的验收标准写下来了吗？写下来的部分能被自动检验吗？ 这是"会留下的那一半"的实测题。如果验收标准只存在于某个人脑子里，那不管过程多规范，你都没有可控性，只有可控性的感觉。

三、六个月后同类需求的改动成本，比人写的基线高还是低？ 这条必须等，等不了就别下"能用于生产"的结论。它是唯一能证伪前面所有乐观判断的指标。

原文里我最认同的，其实是那句被数据结尾拖累了的话：AI 放大一切——好的工程实践被放大成高效产出，差的工程实践也被放大成更大的混乱。 我只想补一句：放大器本身不判断被放大的是什么。 所以问题从来不是"AI 能不能用于生产"，而是你有没有能力在事后分辨，产出的东西到底属于哪一类。而这个分辨能力，正是第一节里那个没有裁判、也不会被吸收的第三层。

没谈团队规模的影响。 上面所有判断都默认是小团队或个人。几十人协作时，阶段闸口的价值会上升——因为它同时在解决沟通同步问题，不只是正确性问题。我没有大团队的实测依据。

没谈非代码类的 AI 应用。 全篇的推理建立在"代码有裁判"上。这个前提一旦拿掉，第一节的三层拆解就不成立了，别把它套到写文案、做设计上。

没谈成本。 生成 4000 行的算力账、审查它的人力账，都没算。一个方法论在什么成本区间才划算，是个真问题，我没有数据。

1. "A 的上限取决于 B"这种话，天然只在 A 的能力落在某个窄区间时才成立——它现在对，不代表它一直对。
2. 代码量是成本项，不是资产项。用投入量当产出量，是个古老的错误，只是 AI 让它变得更诱人了。
3. 模型越强，它执行你写下来的东西越准；于是你没写下来的部分，就成了唯一的损耗来源。
4. 错误记忆导致的 bug，会被归因成"这次 AI 没写好"，没有人回溯到那条记忆——归因链断了，就没有纠错回路。
5. 任何一套记忆机制，只有写入没有淘汰，都会随时间变成负资产。
6. 放大器本身不判断被放大的是什么。