我听过一个事。一个团队去年把核心模块交给 Agent 重写，测试全绿，代码评审也没人提出问题，上线一切正常。
三个月后出了个并发才触发的问题。一个开发查了两天，最后说了一句：我说不清这个模块是怎么工作的。
代码不是他写的，也不是他团队里任何人写的。
我想聊的就是这个局面。写代码这件事变便宜之后，什么变贵了？还能在这个行业里待下去的人，判据变成了什么？
判据确实变了。以前问的是"你会不会写代码"。现在更像在问另一件事：这套系统的接口是你定的吗，出了事是不是你去查。都是"你"，跟 AI 没关系。
这个判断我没打算写得很体面，因为我自己也没完全想清楚。最没想清楚的是最后一节的问题：如果初级岗位真的没了，那些本该在里面长成"能说清整个系统的人"，从哪儿来。
先把两件容易写飘的事说准。一个是岗位，一个是培养。
不是岗位消失，是入口收窄
这一节要处理一个说法：AI 会让基础编程岗大量减少。方向没错，但幅度夸大了。
夸大的部分会让整篇文章变得不可信。任何还在招人的技术负责人，都能一句话举出反例。
拆开看是这样。需求规格清晰、能被验证的那部分编码任务，生成成本已经趋近于零。这类岗位和定价最先被压缩，这是事实。
但"基础岗"里混着另一类活。它们需求模糊、依赖具体环境、需要有人背锅。AI 现在吃不下这些，不是能力不够，是这类工作要的上下文不在代码里。
还有一部分成本会回流。验证、集成、运维、责任，这些活不会消失，只是换了岗位名字。
所以我更愿意说"岗位结构重排、初级入口收窄"，而不是"大量岗位消失"。这两个说法决定了你该准备什么，差别不在措辞上。
梯子被抽走之后
软件行业长期有一套培养机制。它不太体面，但极其有效：雇一批初级开发者写生产代码，让生产环境教会他们什么叫工程。
这套机制效率高得离谱，因为它一次给了三样东西：真实的约束、真实的后果，以及一个真正负责的人。
你写的接口被别人的模块调用。你的表结构三个月后被另一个人改。你的设计缺陷在凌晨两点把你叫醒。这些没有教材能替代。
现在它正在被拆掉，原因很朴素。既然 AI 能用更低的成本产出同等甚至更好的代码，为什么还要雇一个需要半年才上手的人来写？
行业里流行一个乐观回答：会有新的教学体系解决。我不接受这个回答。倒不是说它一定错，是它把最难的一环当已知条件跳过去了。
难在哪，我想分清两件事。
第一件：沙盒能训出来的东西，比很多人想的多。一个新手在 playground 里从零手写一套系统，它会出问题。模块耦合了，状态收不住，改一处坏三处。这些后果真实、即时、可复现。
所以"用个人练习替代真实项目"这个方向成立。AI 时代练习的密度能提高几个数量级，构造能力可以练得相当扎实。
第二件：系统思维不是这样长出来的。这里的"系统思维"，指的是能从某段代码往上看到整个项目骨架，知道模块之间靠什么依赖和协议咬合，并能据此指挥 AI 写出可理解的代码。
Playground 的反馈是完整闭环的。只有你和你的程序，出了问题当场就知道。这既是它最强的地方，也是它的天花板。
真实系统里多出来的东西有三样：别人的代码、时间的尺度、协议的约束。系统思维真正生长的地方，是"别人要改我的代码"这一刻。你要让一个不是你写的东西能被你扩展，还必须把边界说清楚。
所以 AI 时代教育重构的关键，我认为只有一件事：把"他人"重新放回反馈回路里，而不是造一个更真实、更复杂的沙盒。
这个结论听起来很虚，落地其实不神秘：去开源项目里做一个被别人的代码约束的上游，做个真有人用的东西，再把自己的设计拿出来被人挑战。
这些老办法之所以还有效，是因为它们都逼你做同一件事：产出解释，而不是产出代码。
顺便说一个我自己在用的方法。用 AI 学习的时候，禁止它直接给答案，只让它反问。李飞飞提过用苏格拉底式对话跟 AI 学习。我觉得这句话比它看起来重：解释和负责是同一种能力。你让人替你想通了，你就没有想通。
绕了一圈，回到开头承认的那个缺口。它短期没有成熟的补法。我猜它会造成一个五到十年的断代：替代先发生，培养体系后到。
把这个窗口说出来，比假装它会自动解决有用。因为它至少能影响一件事：你愿不愿意主动去补那段被抽掉的训练。
需求那边发生了什么
岗位为什么会集约化成现在这样，还要看需求侧。
有一种乐观叙事是 AI 会带来新一轮需求爆发，像互联网和移动互联网那样。我认为这个类比错了，而且错得挺关键。
生产工具从来不是需求的来源。编译器、框架、云、开源生态，这些没有一样是互联网需求的成因。它们是被互联网和移动互联网这两次需求革命带起来的。
先有需求，工具跟着长出来，工具再压低成本、扩大可服务范围。需求不存在的时候，工具再好也长不出来。
那两次革命给岗位扩张供了什么？同构的大需求池。全社会都要上网，所有人都要换手机，于是"做一个产品、服务几亿人"成了一件可行的生意。产能被需求吃掉，岗位就扩张。
AI 这一次没有带来新的同构需求池。它做的是另一件事：把"可服务需求的规模门槛"打下来了。
以前只有能触达百万人的需求才值得做成软件，因为单位服务成本太高。长尾需求根本不进入市场。
现在单位成本降到可承受。大量个性化、小规模、以前根本不划算的需求，第一次被计入。
所以需求曲线确实在上移。但上移的原因是源源不断的小需求第一次变得可服务，不是天上掉下来一个新的巨型需求池。
这个区别决定结构。以前是同构需求配平稳下降的成本，产能先被需求吃掉。现在是长尾需求配断崖式下降的成本，而个性化需求越往后越薄。
这解释了为什么基础开发者密集、需求高度同构的领域最先感到压力。同构需求最容易被标准化工具吃掉。
它也解释了规模化的红利为什么在消退。每个需求都要独立理解、独立设计、独立验证。“一次开发、无限复制"这个软件最大的杠杆，正在贬值。
从"写得出来"到"知道写对了”
代码生成成本趋近于零，约束条件必然转移。原来卡在产能。现在卡在判断。
判断的对象变了。以前问"这段代码能不能写出来"，现在问"我怎么知道它写对了"。
要谈判断得先承认一件事。审查、测试、CI 这些手段没失效，但它们能证明什么，我们其实很少认真讨论。
验证要覆盖两层，这两层的反馈能力差距很大。
实现层问的是：代码有没有忠实实现设计。编译器、类型、测试都能给出答案，AI 自己也能测。这一层它已经比较强。
设计层问的是：设计有没有表达真实意图。这一层几乎全靠业务验收和领域专家，AI 完全不会反驳。
危险就在这里。AI 可以忠实实现一个错误的设计，交付一个高度一致、高度可信的错误系统。可控性拉满，正确性为零。
换个说法：过去的事故是"代码写错了"。现在多了一种事故，是"设计错了，但整条流水线上没有任何环节会顶回来"。
还有一层麻烦。我们只能核对代码是否符合已经写下的预期。预期本身错了，测试会一路绿灯。
而且正确性往往不是上线前就能知道的。真实业务里，验证的难点很少是"我知道标准，只是懒得测"。更多时候是自己不知道标准是什么。
很多异常是数据跑起来之后才显形的。上线的时候你看不出有什么不对。跑了两周才意识到某个转化率不对劲，某个延迟只在特定机型上塌掉。
正确性是个随时间显形的变量，不是发布前能一次性确认的常量。
提示词、harness、loop 这条线在收敛什么
这两年方法上的演进很清楚：提示词工程，harness 工程，loop 工程。
很多人把它理解成"越来越高级的方法"。我觉得驱动力只有一个：反馈信号。
提示词工程是把意图表达清楚，本质是猜一次。harness 工程给模型工具、上下文和检查点，本质是给一次反馈，让它在一次任务内自己发现并修正错误。
loop 工程是跑起来、观测、判断、调整、再跑。本质是不再依赖人的单次判断。
越往后，越依赖一个前提：验收标准能不能被自动判定。
顺着这个前提能划出一条边界，我认为它很实用：没有可观测信号的业务，loop 工程不成立。
如果一件事的"对"无法用指标、契约、测试或可运行规格表达出来，那这个 loop 要么在骗自己，要么退化成人肉评审。体验好坏、产品有没有新意、跨部门利益不一致的时候什么才算正确，都属于这一类。
承认这条边界，“loop 工程"才是工程。不承认，它只是万能论的一个变体。
测试的位置也在这里。它不是在"避免责任”，它是"我理解这段代码"的可执行证据。
但测试必须分层。而且 ground truth 必须由人提供——这个词直译是"地面真值"，在这里指的是"什么算对"这件事的标准答案。
如果测试和实现都由 AI 生成，它们会共享同一个盲区。你测出来的是自洽，不是正确。
从这儿能直接推出一条选型原则。它比任何"如何让 AI 写好代码"的技巧都管用，因为它在回答"不该在哪用"：
验收条件写不出来、ground truth 造不出来的模块，不该交给 Agent。
需求这件事我还留了个尾巴
前面讲需求只讲了一半。这个尾巴我一直没想明白，写在这里。
同构需求配平稳下降的成本，长尾需求配断崖式下降的成本，这个结构清楚了。但还有一种可能。
如果个性化需求的付费意愿普遍很低，那么这条需求曲线会不会几乎不抬？那样的话，“集约化"就不是一个过渡状态，而是新的常态。
这会改变我下面所有结论的分量，所以我不假装它不存在。
FDE：从实施劳动力到价值翻译器
先说这个词。FDE 是 forward deployed engineer，现场部署工程师，指云厂商派到客户现场做接入和交付的工程师。
这两年在讲 FDE 的时候，流行说法是：这种模式创造的价值很难体现出来。这个说法在商业上是反的。
企业软件的钱恰恰是在交付环节收的。实施、集成、定制、咨询，一直是收入大头。
更准确地看，FDE 过去做的是实施劳动：装环境、调参数、写集成胶水、改字段、导数据。
这些活的杠杆极低。不可复用，不可产品化，不出现在任何架构图上。所以价值被埋在工时里，从业者也不被当作工程角色。
AI 改变了这件事的结构。它把"把业务语义翻译成代码"的成本打下来了。于是 FDE 的重心从实现转到理解。
不再是自己写胶水，而是把业务意图固化成可判定的验收信号，然后让编码 Agent 去实现。
这样看，FDE 的真正交付物不是部署好的系统，是一份能让 AI 跑出正确结果的业务规格。
它的价值不是体现不出来，是以前被埋在实施工时里，现在第一次能单独计量。所以我判断这个岗位在 AI 时代不是消失，是升格。
信任 = 可排查性
这一节要处理一个经常被讲错的问题：AI 写的代码，可信度到底低在哪。
有一种自我安慰是"人写的总归更可信”。我认为这句话不成立，而且它掩盖了真正的问题。
反例太好找了。人写的、没人理解的遗留代码，它是黑盒吗？是。它可信吗？不可信。
而且它比 AI 生成的代码更糟。至少 AI 生成的代码，你还能重新生成一遍。
反过来看：AI 写的，但设计由人定、接口和验收条件清楚，可信度比上面那个高得多。
所以可信度不是"生产方式"的性质。它只有一条判据：这个软件出问题的时候，它能不能被排查。
注意，判据不是"有没有 bug"。没有软件没有 bug，用无缺陷当标准等于没有标准。
这里说的可排查性，具体指：出问题的时候，有没有人握着设计，能定位，能推演，能解释它为什么会这样。
顺着这条判据，有个很多人心里嘀咕但没说出口的问题要回答：你自己一行行手写，能增加可信度吗？
不能。一份没人能排查的手写代码，和一份没人能排查的生成代码，在可信度上没有区别。
这一刀是砍向所有人的，包括写了十年代码的人。资历不构成可信度。
这也顺便解决了责任的问题。责任的归属不因为代码是 AI 写的就转移，也从来不因为是人写的就减轻。
真正的变化是：代码是黑盒的时候，责任不会消失，只是没人真正接得住，最后摊到组织头上、摊到事故上。
所以"AI 不能负责"这个论点很弱。强的是另一句：你不能为你控制不了的东西负责，而控制的前提是理解。
熵变贵了
代码变便宜之后，什么变贵了？
我的答案不是"工程师更值钱"这种话。是信任、分发、专有数据，还有熵。
熵在这里指的是混乱的程度，或者更直白地说：一个系统衰减到没人能看懂它的那种趋势。前三个是老话题，代码本身不再是护城河，护城河转到了数据、渠道和领域准入上。被低估的是熵。
代码生成成本趋近于零，意味着系统可以无限膨胀。以前一个团队想加功能得排期、得评估人力，成本天然限制边界扩张。
现在这个刹车松了。Agent 可以不知疲倦地生成模块、适配场景、清理历史遗留。于是技术债、维护成本和认知负载，一起变成新的稀缺约束。
再往前推一步：一个系统膨胀到没人能理解，它同时就失去了可排查性，也就失去了可承担责任的能力。这跟上一节说的其实是同一件事。
设计原则因此要换。以前是"只要它能跑"。现在更像是不让系统超过任何人能够理解的范围。
这句话听着保守。我觉得它是 AI 时代最激进的设计原则，因为它是唯一能同时保住可排查性、概念完整性和责任可承担性的约束。
概念完整性是 Brooks 在《人月神话》里的说法，指的是好系统出自少数一致的头脑。
顺便说清一个常见误读：大模型消解的是沟通开销，不是概念完整性。Brooks 的核心论点不只是沟通成本高。
人月神话不会因为 AI 破灭，它是转移了。编码 Agent 让"把一个人的意图无损翻译成代码"的成本大幅下降。
“把一个人的意图无损传给另一个人"的成本也在下降。但十个 Agent 十种风格、没人能在脑子里装下整个系统，这个风险在上升。
这里必须有个明确的责任归属，否则混乱会失控：概念完整性由人负责。
可以有一堆 Agent 在写，但设计的一致性必须由某一个具体的人决策和守着。
反过来做，纯靠 AI 设计，然后找个人去背这个设计，前面说的那种高度一致、高度可信的错误系统就会长出来。
拿前端举个例子
前面说的都是泛开发者的判断。前端可以当个具体例子。
先纠正一个结论。“前端这个岗位消失了"是错的。“前端的市场需求在下降"是对的。
前端基础开发者密集，需求又高度同构。列表、表单、后台、详情页，形态长期稳定。所以它按前面那条逻辑最先感受到压力。这是结构性的，不是暂时的。
但也要承认，岗位减少不全是 AI 造成的。2021 年前后的过度扩张、外包迁移、全栈化带来的头衔合并，都能解释一部分收缩。把因果关系全归给 AI 是偷懒。
那前端还有系统能力的位置吗？有，而且恰好落在前面那条判据上：这些都是 AI 生成的代码需要有人兜底的地方。
渲染性能是一个。AI 能写组件，但它在特定机型、特定交互下的性能退化，得靠人定位。
状态一致性也是一个。跨路由、跨标签页、跨端的状态同步，最容易出"高度自洽但错误"的事。
跨端一致性本质上是协议和契约设计问题。设计系统治理是依赖治理的典型场景。
可观测性和验证基建更直接：埋点、指标、异常检测、灰度。这是 loop 真正能跑起来的前提，而且是纯系统工程。
再往上还有实验基建：A/B、特性开关、回滚能力。当"正确性随时间显形"成为常态，实验基建是唯一能加速显形的工具。
存量岗位在减少，但对系统能力的要求在上升。这是我想让前端读者拿走的结论。它不算安慰，但至少是个方向。
还能做什么
论证到这里可以落成三个动作。都不是"提升自己"这种话。
第一个动作：把交付物从代码换成定义。
可排查性的源头是接口和验收条件。这本来就是"人写"的含义——人写的不是实现，是设计、接口和验证条件。
所以你的核心产出应该是这几样：这个模块的契约是什么，什么算对，边界在哪，失败时怎么暴露。
写不出验收条件的模块，你也没有真正理解它，那就不该交给 Agent。
第二个动作：主动进 loop，别留在外面。
留在外面的开发者，工作会退化成接收 AI 产出并祈祷。进到里面的，做的是设计收敛条件：定义信号，设定判据，决定什么时候继续跑，什么时候停下来找人。
这个位置稀缺的不是会写提示词的人，是定义什么叫"对"的人。
第三个动作：把设计留在自己手里，并且主动缩小系统边界。
熵变贵了，“能搭得更大"不再是优势。“能让系统保持在可理解范围内"才是。
具体是两个动作：对每一个进入系统的复杂度追问它值不值；不让概念完整性交给 Agent。
我知道这三个动作听起来不像什么新东西。可能因为真正的变化从来不在动作上，在判据上。判据变了，同样的动作就有了完全不同的分量。
回到开头那个查了两天的人。他后来做的事情，其实是把那个模块重新读了一遍，画出依赖，把接口补成文档，然后才改对。
没有人要求他这么做。我觉得 AI 时代留下来的就是这么一批人。不是因为他们会写什么，是因为出了事，他们会去把那件事弄明白。