技术 · 深入
同一个 bug，为什么修三遍还在原地？
不是你改得不对，是你在错的那一层改
AI 写代码的返工，多数不是「它写得烂」，而是「你在错误的层级上修」—— 一个其实是接口边界没定清的问题，被当成一段逻辑 bug 反复打补丁，于是每次都在同一个地方重新破。这一页给的是一套按海拔分工的做法：把一次建造拆成系统、子系统、单元三个高度，每个高度只回答自己那一层的问题、用自己那份提示角色；产出按固定顺序过三关（结构 → 缺陷与运维 → 对抗测试），而对抗关里发现的结构性问题不许就地补，必须退回它该在的那个海拔重来。关键动作只有一个：先判断「这个错属于哪一层」，再决定在哪一层动手。
方法 · 一图看懂
1
三个海拔，三种问法 — 系统层问边界与数据怎么流，子系统层问接口与状态归谁，单元层只问输入、输出与错误；问错层，答案必然是把别层的问题硬塞进来
2
三关顺序固定，不许调换 — 结构 → 缺陷与运维 → 对抗测试；先跑对抗再跑结构，等于把「设计错了」当成「实现错了」修
3
对抗关的产出是「退回」，不是「补丁」 — 对抗测试暴露出的结构问题，动作是重启这一轮并路由回对应海拔，⛔ 不在当前层加判断绕过去
4
每层留一份交接单 — 角色提示、路由说明、交接文档三样齐；没有交接单，下一层只能靠猜上一层的意图
为什么「在顶上补」必然反复
因为在系统层补一个单元级的漏洞，补的是症状的出口而不是症状的来源：每补一次就多一条特例分支，分支之间互相不知道对方存在，下一次同类输入换个形状进来，照样漏。判据：同一个位置上出现的第三次修补，几乎一定是层级错配——第一次可能是疏漏，第二次可能是运气，第三次就是「这一层本来管不了这件事」。
三关各自能不能跳
结构关不能跳——它判的是「要建的东西边界对不对、谁依赖谁」，这一关不过，后面两关的通过率没有意义。缺陷与运维关可以压缩——常规回归可以只跑与改动相邻的几条，但日志、超时、失败重试这三样必须过，它们是「上线之后才会痛」的部分。对抗关不能省，但可以只挑一处——一次只挑最危险的那个假设去攻击（比如「输入一定非空」「调用一定成功」），攻破就退回，不追求穷举。
原理 · 为什么有效
返工成本随「修复位置的海拔」上升得极快：在单元层改一行是分钟级，在子系统层改接口是小时级，在系统层改边界是「重来一遍」的级别。而 AI 的默认倾向恰好相反 —— 它会在你最后一次说话的粒度上动手，也就是最省事的那一层。分海拔的全部意义，是把「在哪一层动手」从默认动作变成一个显式判断：先认出这个错属于哪一层，再回到那一层改，改完按固定顺序重新过三关。这也解释了为什么「多开几个 agent 并行」经常让情况变糟 —— 并行的每一路都在自己那一层打补丁，合并时才发现彼此的前提不一样（这一类复合错误、成本放大与合并冲突，业内的做法说明里明确写着属常态而非边缘情形）。
适用场景
适合：多文件、跨模块、要连续改几轮的活（新功能、重构、把一段手工流程改成自动）；以及你已经在用多个 agent 并行、但合并时总打架的场景。不适合：单文件小改、一次性脚本、需求本身还没定清（那种情况先定需求，拆海拔只会把不确定放大三倍）。也不适合「只有一个 agent 一把梭」的轻量用法 —— 那没有交接，三关会退化成三次自问自答。
自测 · 4 问
你能说出这次动的东西属于哪一层吗？说不出，先别动手
同一个位置你已经改到第三次了吗？是，就退回上一层重看边界
三关是按顺序过的，还是「想到哪关跑哪关」？
有没有一份交接单，让下一个人（或下一个 agent）不用问你就能接着做？
怎么上手 · 验证步骤
上手四步：① 先用一句话写清系统层的边界—— 这个系统负责什么、不负责什么、外部只通过哪几个入口进来；② 把要建的东西按层列成清单，每一层配一句角色提示（系统层问边界、子系统层问接口、单元层问输入输出）；③ 让 AI 只在当前层动手，跨层的改动一律写成「待上一层决定」挂在交接单上；④ 每层做完按结构 → 缺陷与运维 → 对抗的顺序过一遍，对抗关攻破就退回上一层，⛔ 不就地打补丁。
自检动作：拿你最近一次返工，回答三个问题 —— ① 那次修改发生在哪一层？② 问题真正属于哪一层？③ 两者不一致的话，是谁先越的界（你让它改的，还是它自己顺手改的）？三个答案写完，你就知道下一次该在哪一层停住。