夜雨聆风有一种感觉越来越强烈：程序员们正在使用一套旧地图穿越一片已经完全改变的地形。
他们熟悉的那些路标——Code Review、需求评审、排期 估点、设计模式——还在那里。但地形已经变了。峡谷消失了，山丘出现了。旧路仍然走得通，只是目的地已经不在那个方向了。
这篇文章要回答的不是"AI 如何让你写代码更快"——那是一个太小的问题，就像蒸汽机发明之后问"如何让马不那么累"一样。真正值得问的是：这场变革和历史上的每一次变革有什么本质不同？它会把软件工程带向哪里？以及，如果你现在仍然在用旧地图，意味着什么？
一、软件工程是一种反常的工程
要理解这次变革，先要搞清楚软件工程为什么是一种奇怪的工程。
工程通常意味着：给定材料，在物理定律的约束下，用已知方法把事情做成。造桥的工程师不需要"想清楚"重力是什么，他只需要精确执行。土木工程的难，在于执行的精度；软件工程的难，从来不在这里。
这个区别比看起来更深。物理工程的"设计"阶段大约占整个项目的 10%，"施工"阶段占 90%——你画好图纸，剩下的是严格按图纸执行的过程。软件工程恰好相反，"设计"（弄清楚该做什么、如何组织）占 90%，"施工"（把确定的方案敲成代码）只占 10%。大量的会议、文档、讨论，都在解决"要做什么"的问题，不是在解决"怎么做"的问题。
Fred Brooks 在 1986 年写了一篇名为《没有银弹》的文章，他在里面区分了两种复杂性。一种叫偶然复杂性（Accidental Complexity）——因为工具不好造成的麻烦，比如你要用汇编手写内存管理；另一种叫本质复杂性（Essential Complexity）——问题本身就是复杂的，不管你用什么工具都无法消除。
Brooks 的判断是：软件工程的主要困难来自本质复杂性，因为软件的原材料是纯逻辑——它没有物理约束，可以无限变形，但也因此没有任何外部力量帮你锚定"什么是对的"。"什么是对的"本身就是需要被构建出来的东西。这句话值得停下来想一想。桥梁的"对不对"有物理定律兜底，不会因为甲方说"我觉得承重可以少一点"就真的改变了。但软件的"对不对"完全是人为构建的——它可以在任何时候被重新定义，因为它本来就是为了服务于人的意图，而人的意图永远在变。
这是软件工程和其他所有工程的根本区别。物理工程的难在于"精确实施已知方案"，软件工程的难在于"把未知的问题变成结构化的表达"。前者是执行问题，后者是认知问题。
这个区别决定了一件事：所有试图用"物理工程的方法"来管理软件工程的尝试，注定都会碰壁。
过去五十年，那些碰壁的尝试一直在重复。
二、五十年的失败，都失败在同一个地方
软件工程有一段奇特的历史：它是工程学里唯一一门一边"做成功了无数东西"，一边"系统性方法论几乎全部失败"的学科。
1968 年北约软件工程会议召开，那时候人们意识到软件开发已经陷入"危机"——项目经常超期、超预算、质量低劣。于是一批聪明人开始尝试用工程方法论来驯服这头野兽：CMMI 能力成熟度模型、UML 统一建模语言、瀑布开发流程、各种设计模式……
这些方法论有没有用？有用。但它们的共同逻辑是：试图约束人的行为，使其更接近机器的精确性。写文档、画流程图、遵守规范——本质上都是在把人当成一种不稳定的执行器，通过外部约束来补偿人的不可预测性。
这条路走了五十年，结论是清楚的：你约束不了创造性活动。那些遵守最严格规范的团队，不一定做出最好的软件；那些灵活的、快速迭代的小团队，反而往往出产更好的产品。敏捷的崛起和各种重量级方法论的边缘化，是这个结论的注脚。
但是，失败的方法论依然存在，而且在大公司里以"流程"和"规范"的名义继续生存着。Java 社区的设计模式滥用至今没有消亡——一个概念上很简单的功能，被包裹在五层抽象和三个工厂类里，代码能跑，但没有人真正理解为什么要这么写。CMM/CMMI 认证项目在一些组织里仍然有市场，尽管没有证据显示它真正改善了软件质量。人们不是不知道这些东西没用，而是不知道用什么替代它。
为什么失败？信息论给出了比大多数软件工程教材更好的解释。
软件需求是一个本质上不确定的信源——用户在说"我要这个"的时候，他自己往往也不完全确定他要什么。他脑子里有 100 MB 的隐性期望、未说出口的假设和随时可能变化的优先级，但他只能通过语言把其中 10 KB 传达给工程师。从用户到产品经理，从产品经理到架构师，从架构师到开发者，每经过一次人与人之间的传递，信息都在有损压缩。这不是沟通技巧问题，这是信道带宽的物理限制。
你无法"标准化"一个信源本身就不确定的系统——就像你无法在地图上精确标出一片随时在移动的沼泽的边界。物理工程之所以能标准化，是因为它有一个完全确定的信源：物理定律。重力是 9.8 m/s²，这不会在周三的迭代会议上被产品经理修改。
软件工程没有这个锚点。所以它的标准化尝试，每一次都在对着空气用力。每次失败之后，人们会修改方法论，再试一次，再失败，再修改——五十年的循环，方向从来没有从根本上改变过。
三、历史上的每次变革，都在做同一件事
不过软件工程并不是没有进步。它有进步，只是进步的方式不是"变得更标准化"，而是抽象层次的跃迁——把上一代人必须手动处理的事情，变成下一代人完全不需要思考的基础设施。
1950 年代的工程师必须手写机器码——每一条指令都是 01 序列，直接对应 CPU 的物理操作。你要在内存的某个地址存储一个数值，你需要知道那个地址的十六进制编码，需要手动计算偏移量，需要在脑子里维护整个内存布局的地图。汇编语言出现之后，这一层消失了，变成了汇编器的工作。高级语言出现之后，汇编也消失了，你可以用 a = b + c 这样的表达式代替一串寄存器操作指令。面向对象和设计模式出现之后，很多重复的结构问题消失了。DevOps 和云原生出现之后，部署和运维的大量手动操作消失了——你不再需要 SSH 到服务器上手动重启进程，也不再需要在凌晨三点因为磁盘满了而起床。
每一次变革都遵循同样的模式：
上一层的"实现细节"变成下一层的"透明基础设施" 工程师的注意力被解放出来，可以在更高的层次思考 准入门槛降低，从业者数量扩大 新的瓶颈出现在更高的抽象层
汇编语言让更多人能写程序，但暴露了"程序架构"的问题；高级语言让更多人能构建系统，但暴露了"需求理解"的问题；互联网让更多人能发布软件，但暴露了"大规模协作"的问题；云计算让部署变成弹性资源，但暴露了"分布式系统设计"的问题……
每次跃迁之后，软件工程变得更"容易"，但程序员面对的问题也变得更复杂——因为更复杂的问题被解放出来了。这不是进步的悖论，这是进步的本质。
这条线有一个值得注意的规律：每一次抽象跃迁之后，"谁能参与"这件事都扩大了一圈。机器码时代，只有极少数受过专业训练的人能编程；高级语言之后，工程师数量扩大了十倍；互联网和开源生态之后，又扩大了十倍。每次扩大，带来的不是"程序员变得不值钱"，而是"软件的总产出暴增，整个行业随之扩张"。
那么 AI Coding 是这个序列中的下一次跃迁吗？是，但它和所有前辈有一个关键区别。
四、这次变革突破了 Brooks 的假设
历史上的每一次变革，都在消灭偶然复杂性——编译器消灭了"手写机器码"这个偶然复杂性，面向对象消灭了"管理全局状态"这个偶然复杂性，云原生消灭了"手动运维服务器"这个偶然复杂性。但 Brooks 在 1986 年已经预判了：这条路终会到头，因为本质复杂性是无法消灭的。
Brooks 的逻辑是完整的：本质复杂性来自需求的模糊性和业务逻辑的内在复杂性，而这两者不会因为工具的进步而减少。所以"没有银弹"——没有任何单一技术能让软件开发的困难在数量级上减少。这个预判在过去四十年里基本正确。每一波"这次不同"的技术浪潮——从面向对象到组件化，从低代码到领域特定语言——最终都没有改变软件工程的根本困难，只是把困难推到了更高的抽象层。
但 AI Coding 正在改变它的前提假设。
Brooks 的假设是：处理本质复杂性的成本是固定的。在这个假设下，本质复杂性无法被消灭，所以软件开发的难度有一个底线。
但如果处理本质复杂性的成本趋近于零呢？
当 AI 能在几秒内生成一个满足需求描述的实现，当修改一个架构决策的成本从"重写三周代码"变成"重新生成三十秒代码"——本质复杂性本身并没有消失，但应对它的策略彻底改变了。
以前，因为实现成本高，你必须在动工之前想清楚。你必须花大量时间在需求分析上，必须在白板上画架构图，必须开无数评审会——因为"想错了再改"太贵了。这不是因为预先想清楚更好，而是因为你别无选择。就像早期电影拍摄非常谨慎，每一个镜头都要精确排练，不是因为导演偏好这种工作方式，而是因为胶卷和冲洗成本昂贵，NG 五十次是不可接受的。数字摄影之后，一条戏 NG 五十次反而变成了常见的工作方式——因为代价几乎为零了。
当实现成本趋近于零，预先想清楚就不再是唯一选项。你可以先做三个完全不同的实现，跑起来比较，选最好的那个，再继续迭代。这种工作方式在以前是奢侈的，现在变成了最合理的。这等于把软件工程从"一次性决策+昂贵执行"的模式，变成了"廉价原型+自然选择"的模式。Brooks 的"没有银弹"成立的前提之一，正在被打穿。Brooks 在 1986 年是对的——但他的预测是基于"实现成本永远是有意义的"这个隐含假设，而这个假设正在失效。
五、热力学第一课：损耗最大的变革，影响最深远
在说"这次变革会带来什么"之前，有必要先处理一个最常见的反对意见：AI 生成的代码质量太差，需要大量人工干预，效率提升有限。
这个观察本身是事实。但从这个事实得出"AI Coding 影响有限"的结论，犯了一个经典的认知错误。
蒸汽机的热效率在早期只有 3-5%。也就是说，燃烧的煤里有 95% 以上的能量都以废热的形式散失掉了，只有不到 5% 真正转化为机械功。按效率标准衡量，蒸汽机是人类历史上最浪费的技术之一。瓦特的蒸汽机比纽科门的稍微好一些，热效率提升到了大约 4%——在 18 世纪的物理学家看来，这种改进离"实用"还很遥远。
但蒸汽机开启了工业革命。
内燃机也是如此。汽油内燃机的热效率大约在 25-30%，远不如今天的电动机（90%以上）。但内燃机统治了交通领域超过一百年，造就了现代城市的形态、全球化的供应链、二战的机动作战方式——不是因为它高效，而是因为它打开了"随时随地移动能量"这个此前不可能的事情。
原因在于：评判一项变革技术的指标不是单次转化效率，而是它打开的可能性空间的边界。蒸汽机的意义不是"让马不那么累"，而是"第一次让人类把热能转化为机械能"——这件事在蒸汽机之前根本不可能，效率多高都没用。
AI Coding 也是如此。如果你用"错误率"或"Review 成本"来评判它，你得到的数字可能不好看。但你问错了问题。正确的问题是：它打开了什么以前不可能的东西？
答案是：它第一次让实现软件的边际成本趋近于零。
当边际成本趋近于零，行业的结构会改变。印刷术让"复制文字"的边际成本趋近于零，结果不是"抄书僧变得更快"，而是教会对知识的垄断被打破，文艺复兴和宗教改革的土壤出现了。互联网让"传播信息"的边际成本趋近于零，结果不是"报社变得更高效"，而是媒体行业的结构被整体颠覆——不是最快的报社胜出，而是报社这个中间环节的必要性消失了。
这里有一个容易被忽视的规律：每一次边际成本趋近于零的革命，摧毁的都不是"执行者"，而是"垄断者"。印刷术没有让所有人都识字，但它打碎了教士阶层对文字的垄断。互联网没有让所有人都成为记者，但它打碎了媒体机构对话语权的垄断。
AI Coding 让"实现软件"的边际成本趋近于零，结果会是什么？不是"程序员写代码更快"，而是程序员对软件实现的垄断将被打破。
一个懂医疗的医生用 AI 工具，可能比一个不懂医疗的程序员用 AI 工具做出更好的医疗软件——因为领域理解才是瓶颈，而不再是编程能力。一个懂法律的律师可以用 AI 直接构建合规审查系统，而不需要先雇一个程序员把他的逻辑翻译成代码。这是真正的结构性变化，不是工具升级。
六、"人必须 Review AI 代码"是一种思维定势
现在大多数团队在使用 AI Coding 时都遵循一个隐含的原则：AI 生成，人 Review，确认没问题再合并。这看起来很合理——AI 会犯错，所以要人把关。
但这个推理依赖几个从未被检验的假设。
假设一：人能有效发现 AI 的错误。
工业界有数据：认真的 Code Review 对缺陷的发现率大约在 25-60% 之间。这意味着即使最认真的 Reviewer，也有 40-75% 的 bug 会被放过。而 AI 犯的错，往往是"表面完美但逻辑微妙错误"的类型——恰好是人类 Review 最弱的类型。AI 生成的代码在语法上是正确的，命名是清晰的，注释是完整的，格式是漂亮的——所有表面信号都在说"这段代码没问题"，但逻辑可能在某个边界条件上出了问题，或者某个并发场景没有处理，或者某个隐式假设不成立。用人类审查自然语言的经验去审查一个从概率分布中采样出来的产物，本身就是工具和对象的错配。
假设二：读代码是验证正确性的最佳方式。
验证代码行为有两条路：一是读代码，在脑子里模拟执行，判断是否正确；二是定义预期行为，让代码实际运行，对比结果。第一条路要求人类能"在脑子里模拟任意代码的执行"——认知科学告诉我们，人的工作记忆只能同时处理 7±2 个信息块，这件事人类极其不擅长。你读一段 200 行的函数，里面有三个循环、两个递归调用、一个状态机——你能在脑子里模拟它在所有可能输入下的行为吗？不能，你只能覆盖你想到的那几个典型情况，而 bug 往往就藏在你没想到的那个情况里。
第二条路只要求人能描述"什么是对的"——这是人类最擅长的事。"给定用户 ID，返回该用户过去 30 天的订单列表，按时间倒序排列，不包含已取消的订单。"把这个描述翻译成测试，让代码跑，看结果是否符合预期——这个过程既清晰又可靠。
我们选了最蠢的方式来保证质量。
假设三：AI 产出量在人可以 Review 的范围内。
一个熟练使用 AI 的开发者，一天可以产出 1000-3000 行有效代码。人类认真 Review 代码的速度是 200-400 行/小时。你自己算：要 Review 完自己 AI 产出的代码，需要多少小时？答案是 3-15 个小时——还没有算上理解业务背景、思考边界情况、查阅相关文档的时间。这已经超出了一个正常工作日的时长。
这三个假设一起崩塌，"人必须 Review AI 代码"的整个逻辑链就断了。坚持这个原则的团队，实际上在做的是：要么限制 AI 的产出速度以匹配人的 Review 速度（把法拉利开成自行车），要么走马观花 Review（假装有把关）。两条路都不是认真在解决问题。
正确的方向不是"更好地 Review"，而是换掉 Review 这件事本身。
控制论提供了一个更好的框架。维纳在 1948 年的《控制论》里提出了"负反馈回路"的概念：一个高质量的系统，靠的不是"每次都做对"，而是"检测到偏差后快速纠正"。恒温器不理解"温度"这个概念，它只做一件事：检测当前温度和目标温度的差，然后开暖气或者关暖气。心脏不需要每次跳动都精确到毫秒，但任何偏差都会在极短时间内被检测到并修正。系统的稳定性来自反馈频率，不来自单次精确性。
传统软件开发的反馈周期是周或月级别的——写代码，部署，等用户反馈，需求变更，重写。AI Coding 可以把这个周期压缩到秒级：生成代码，自动测试失败，AI 自动修改，重新测试通过。
这不是效率的提升，这是反馈频率的数量级变化。反馈越频繁，系统的偏差就越小——不是因为每次更精确，而是因为每次犯错的代价更低，纠正更快。你不需要 AI 写得比人好，你只需要 AI 的写-测-改周期比人快一百倍。最终质量会更高，尽管每次生成的质量可能更低。
这不是直觉上容易接受的结论。人类天然倾向于"做事要认真"、"质量要有保证"——这些价值观在稀缺时代是合理的，在边际成本趋近于零的时代需要被重新审视。
七、"代码垃圾"是一个旧范式的概念
"AI 产生了大量代码垃圾"——这是现在讨论 AI Coding 时最常听到的抱怨之一。
这个说法背后有一个隐含的价值判断：代码是一种"成品"，不好的代码是"资源的浪费"。
用进化生物学的视角看，这个价值判断本身就是错的。
一棵橡树每年产生几十万颗橡子，最终长成树的可能只有一两颗。一条大马哈鱼每次产卵数千颗，能活到成年的可能不超过百分之一。按工程标准，这是惊人的浪费，99.99% 的产出都是"垃圾"。但橡树采用这种策略已经存活了数千万年，大马哈鱼在地球上的历史远长于人类工程师的历史。这种策略之所以有效，不是因为效率高，而是因为它能在不可预测的环境中保持种群的生存——当你无法提前预知哪颗种子会落在好的土壤上时，撒出大量种子是唯一合理的策略。
对 AI 代码的翻译是：当你无法提前预知哪个实现方案是最好的时，生成大量候选，然后快速筛选，是比"精心设计一个"更有效的策略。前提是：单次生成的边际成本趋近于零，并且你有有效的筛选机制。
"AI 产生垃圾"的问题，本质上是在说"我没有一套自动筛选机制"。如果你有——运行测试，筛掉不通过的，保留通过的——那 AI 生成的"垃圾代码"不是垃圾，是被自然淘汰的候选，它帮你缩小了解空间。如果你没有——只能靠人肉从一百个候选里挑——那确实是灾难，但问题在筛选机制的缺失，不在于 AI 产生了太多候选。
科学家不会说"失败的实验是垃圾"。每个失败的实验排除了一种可能性，让下一个实验的搜索空间更小。爱迪生在寻找灯泡灯丝材料时据说尝试了超过一千种材料，每次失败都被他记录下来——因为它提供了信息。AI 生成的"错误代码"也是同样的逻辑——每次失败的测试都告诉你某个方向走不通，AI 的下一次生成应该往其他方向去。
如果你没有自动化验证体系，那你面对的不是"AI 质量问题"，而是验证基础设施的欠债。这是两个完全不同的问题，解法也完全不同。前者的答案是"换 AI 模型"或者"改 prompt 技巧"，后者的答案是"补测试、建 CI/CD、搭监控"。很多团队在"AI 产生垃圾"这个问题上花了大量时间讨论模型能力和 prompt 工程，但真正的问题从来不是 AI 产生了多少垃圾，而是他们没有把垃圾自动过滤掉的机制。
八、当前的困境：工具已经跑到了组织前面
理解这次变革，不能只看技术，还要看人和组织——因为这一次变革的阻力，不是来自技术，而是来自习惯。
一个工程师正在用 AI 完成以前需要三天才能完成的工作。他一天完成了，然后打开 需求平台，发现 排期 里有 10 天的估点——不是因为他低估了，是因为这个估点系统是为"人写代码"校准的，不是为"AI 写代码"校准的。他不知道现在应该做什么，于是他花了两天重构代码（因为有时间），然后写了一大堆文档（因为 排期 还没结束），然后在第九天假装刚刚完成任务，提交 PR。
这个场景是真实的。技术的变化速度远快于组织的变化速度，而这个差距带来了意想不到的扭曲。
当 AI 把编码速度提升了 5 倍，但 Code Review 流程、需求评审流程、排期 计划流程还是为"人每天写 50 行代码"设计的时候，AI 带来的速度优势会在流程的摩擦中大量消耗掉。就像在一个限速 60 公里的环形道路上开法拉利，你的车比别人快，但你兜了同样的圈数，到达目的地的时间差不多。
更深的问题是信息丢失。当 AI 完成了大量代码，但这些代码的"设计决策"没有任何痕迹时，新人上手 会非常痛苦——代码在那里，但为什么这样写、考虑过哪些方案、放弃了什么——这些都消失了。人写代码时，这些思考过程部分保留在注释里、在提交信息里、在设计文档里，甚至在团队的集体记忆里。AI 写代码时，如果没有专门的机制去记录决策过程，这部分信息会消失得更彻底。
还有一个更微妙的问题：所有权稀释。当一段代码是 AI 生成的，开发者心理上和这段代码的关系会变得松散——"那是 AI 写的"，不是"那是我写的"。代码出了问题时，这种心理脱钩会导致责任感的稀释。这不是道德问题，是人类心理的自然反应：我们对自己参与构建的东西有更强的归属感和责任感。
你可以把它类比为生物学里的"免疫识别"——一个健康的免疫系统能区分"自己的"和"外来的"。当开发者从零开始写代码时，他对代码有完整的免疫识别：哪段是我写的、逻辑是什么、可能在什么地方出问题。AI 生成的代码对开发者来说是"移植器官"——功能上 work，但免疫系统不认识它。一旦出问题，debug 的过程比 debug 自己写的代码痛苦得多，因为你没有内部的认知地图来导航。
这些问题不是 AI 的问题，是过渡期特有的问题——两套范式的摩擦带来的。它们会随着组织的适应而逐渐消解。但在消解之前，它们是真实存在的阻力，也是很多团队"用了 AI 但没觉得有什么变化"的真正原因。---
九、软件工程的未来不是标准化，是进化化
回到那个五十年悬而未决的问题：软件工程能不能标准化？
过去的所有尝试都试图用同一条路：制定规范，约束人的行为，使其可预测。这条路失败了，原因前面已经说清楚了——创造性活动无法被约束到精确执行的程度，而且你越约束，往往越扼杀了真正带来价值的那部分。
AI 正在走的是另一条路：不约束人，约束 AI 的输出。约束 AI 比约束人容易一千倍——AI 天然是可配置的，你可以给它固定的代码规范、测试要求、安全检查清单，它会始终遵守，不会在周五下午因为赶 deadline 而偷懒，不会因为"这个规范我不认同"而偷偷绕过去。约束人需要制度、激励、文化，需要年复一年地维持；约束 AI 只需要写进 prompt 或者配置文件，一次设定，永久生效。
这就是 AI 时代"标准化"可能成立的方向：不是人遵循规范，而是 AI 的输出天然是规范的。就像自动驾驶天然就是标准化驾驶行为——不是通过约束司机，而是通过替换司机。自动驾驶的"驾驶规范"不需要司机背诵交规，因为规范已经内化在算法里。
但这只是近期的演化方向。更深的变化在更远处。
如果你接受"实现成本趋近于零"这个前提，软件工程的最终形态不是标准化，而是进化化——你不再"设计"软件，而是"定义选择压力，让软件进化出来"。
你描述一组约束条件：支持十万 QPS、错误率低于千分之一、用户满意度高于 4.5 分、代码可以在现有基础设施上运行、安全审计通过。AI 通过大量变异和测试，进化出一个满足这些约束的系统。最终产出的代码可能人类完全看不懂——但它可验证地满足所有条件。这听起来像科幻，但蛋白质折叠的 AlphaFold 已经做了类似的事：人类无法手动设计蛋白质结构，但 AI 通过搜索解空间的方式，找到了人类几十年都没能找到的答案。AlphaFold 的输出——蛋白质的三维结构——在形式上就是"代码进化"的先驱：你输入约束（氨基酸序列），它输出满足物理约束的三维结构，中间过程是一个人类无法追踪的搜索过程。
这不是智能设计，这是定向进化。区别在于：智能设计要求设计者预先知道正确答案；定向进化只要求设计者知道什么是好的。前者是软件工程师长期以来被要求做的事，后者是人类真正擅长的事——我们非常善于判断"这个感觉好"、"那个感觉不对"，即使我们无法精确描述为什么。
到那个阶段，程序员的角色将是"环境设计师"——你设计的是选择环境（测试套件、验收标准、用户反馈机制），而不是系统本身。这才是人类在这套分工里最无法被替代的位置：判断什么是好的，而不是执行怎么做到。
有些人会问：如果一个系统人类完全看不懂，它安全吗？可靠吗？这恰恰是验证基础设施的重要性所在。你不需要理解代码来保证安全，你需要的是一套足够强的验证体系。就像你不需要理解编译器输出的机器码来保证程序正确——你只需要编译器的行为是可验证的、可信任的。当你有充分的测试覆盖、形式化验证、监控告警、灰度发布、自动回滚——你不理解代码本身不是问题，问题是你的验证体系够不够强。
十、此刻站在哪里
写这些不是为了让你感到焦虑。是为了让你看清楚现在的位置。
正在经历的这个阶段，是从"人写代码，AI 辅助"到"人定义任务，AI 执行"的过渡期。这个过渡期里，最常见的错误是把过渡状态当成终点——用"AI 辅助提效 30%"来衡量这场变革，就像用"打字速度"来衡量 Word 对写作的影响。格局太小，遮住了真正重要的东西。
更大的错误是用旧范式抵抗新范式——坚持让人 Review 每一行 AI 生成的代码，坚持把"写对"当成质量的保证，坚持把代码当"作品"而不是"候选"。这些做法不会让你更安全，只会让你在维护一种虚假安全感的同时，被迭代速度更快的竞争者甩开。
还有一个很多人没意识到的错误：把 AI 当人来协作。你给 AI 分配任务的方式像给一个初级工程师分配任务——事无巨细地指挥、一步一步地说明——这反而比自己写还慢。AI 不是需要管理的人，是需要正确输入的函数。它最高效的工作模式是：你一次给完整的上下文和明确的目标，它一次给出结果。中间不需要反复确认、不需要进展汇报、不需要"你先做一半我看看"。
但最大的误判可能还是对"谁会被替代"的判断。很多人以为 AI 会替代初级程序员，留下资深程序员——因为资深程序员有架构能力和判断力。但这个判断可能恰好反了。初级程序员做的是"翻译"——把明确的需求翻译成代码，这部分正是 AI 最擅长的事。资深程序员做的是"判断"——在模糊的条件下做出取舍。这看起来是 AI 做不了的事，但如果你把"判断"拆开来看：一部分判断是基于经验和直觉的（AI 做不了），另一部分判断是基于数据和分析的（AI 做得比人好）。当 AI 能快速生成多个方案并给出各自的数据分析时，基于数据的判断就被 AI 接管了，人只保留基于直觉和价值观的判断。
所以真正被替代的可能不是初级程序员，而是那些主要依靠"经验模板"做判断的资深程序员——他们的"经验"恰好是 AI 最容易学习的部分。留下来的，是那些真正有品味、有直觉、有领域深度的人——无论他们写不写代码。
进化论的核心洞察不是"最优的物种存活"，而是"迭代速度最快的物种存活"。一个每周迭代十次的团队，长期会进化出比每周迭代一次的团队更好的系统——即使前者每次的"质量"更低。在 AI 时代，速度等于试错次数，试错次数等于进化速度。
那些现在最不舒服的工程师，往往是那些把整个职业价值都押注在"知道怎么写代码"上的人。这部分价值正在贬值，不是因为他们不好，而是因为这件事本身变便宜了。
那些最有价值的问题——该做什么，为什么做，什么是好的，哪个方向值得投入——这些问题从来没有变便宜过，而且在实现成本趋近于零之后，它们将成为唯一真正稀缺的东西。
软件工程这门学科，在未来可能会被吸收进产品设计和系统验证，以我们现在熟悉的形态消失。但思考清楚"要做什么"和"什么是好的"的能力，无论它被叫做什么，都会比代码本身更持久。
那不是工程能力，那是判断力。而判断力，从来都是学不会的——只能在一次次具体的决策中，慢慢磨出来。
这篇文章的主要思路来自与 AI 的一次持续对话，我整理并改写了我认同的部分，剔除了我不认同的。如果你发现某个论点有漏洞，它很可能确实有——欢迎指出来。
