有一种流传很广的工程判断，把风险指向另一个位置。团队不再理解自己的系统，没人说得清某个模块为什么存在、当初排除了哪些方案、一次改动会牵动谁。生成变快以后，维护成本只是被搬到未来，而接它的人还没有出现。
这个判断有争议。支持者常说 AI 写的代码大概在平均水平，改进低于平均的代码库够用，替代不了理解。反对者举数据工程师的例子，这类岗位入职第一天就要懂产品和业务，AI 消掉的只是摩擦。两句话都成立，差别在代码归谁维护。
被搬到后面的成本有哪些
意图最先丢。架构决策的理由不在代码里，评审只能看出对错，看不出取舍。三个月后接手的人面前只剩一份能跑的实现。
知识断层跟着来。有说法把断层归因于公司不再招初级工程师，可持这个说法的人自己留了余地，事情没那么简单。新人缺的是积累领域知识的位置，这个位置不会因为工具变强自动长出来。
还有一种成本藏在评审里。AI 一次能给出几百行看着完整的改动，评审的人要么全看，要么都不看。全看时间不够，不看等于把把关的动作外包给生成时的运气。
还有人转述某公司新岗位的状况，规格、代码、测试、需求文档全由 AI 生成，各层级员工只写提示词，每天干 12 到 13 小时，不读任何内容就交付。这是单方面说法，规模和真实性都无法核实，但它回答了一个问题，当没有人读代码，谁来定义什么叫写完。
能落地的做法
- 把决策写成架构决策记录，一条决策一段上下文，写清当时排除了什么。记录不必长，能回答为什么不用另一个方案就够。
- 给模块定责任人，责任人要能讲清边界和取舍，讲不清说明所有权是假的。
- 评审时多问为什么这么做，而不是只问能不能跑、测试过没有。
- 新人从改小缺陷进真实系统，让他们在有上下文的地方练。
- 关键路径上的代码，负责人亲手写一遍或手改一遍，手过一遍才知道哪里脆。
不同角色的着力点
写代码的人守住一件事，自己写的模块自己能讲清为什么这么写。带团队的人守住两件事，决策记录还在，模块责任人还在。新入行的人优先争取有上下文的活，别在只写提示词的岗位上练判断。
边界在哪
这类判断属于观点，没有数据支撑。维护是不是最终的那笔账，生成越快要养的系统越多，说法本身来自经验，不是测量结果。招初级工程师能不能补上断层，持这个说法的人也没给肯定答案。
把它当提醒读可以，当结论读会过头。能复用的只有后半截，哪些成本会被搬到后面，以及哪些动作能把它们拉回当下。
常见问题
AI 写的代码质量到底行不行。改动范围小、上下文充分的局部确实够用。放到跨模块、跨团队的改动上，缺的是意图和边界，不是语法。
工具选型能解决吗。不能。工具决定生成速度，所有权、评审和文档决定这套系统三年后还能不能改。前者是投入，后者是欠账。
中小团队要全套流程吗。不必。先做两件事，决策记录和模块责任人，成本低，遇到人员流动立刻见差别。
要不要禁用 AI 写代码。多数团队付不起这个成本。把它限制在改动范围小、边界清楚的局部，同时守住决策记录和模块责任人，比一刀切更现实。