夜雨聆风
一、那个看起来已经完成的 PR
现在这种场景已经很常见：一个开发者把需求贴给 AI，让它先拉一个分支，自己去改代码、补测试、修 lint、跑构建。二十分钟后，屏幕上就出现了一个看起来相当完整的 PR。改动不少，注释齐全，测试也补了几份。你开始 review。最先浮现出来的，是一种轻微的顺滑感，像是软件开发里最费力的那一段，已经被悄悄抹平了。
很多人会顺势得出一个判断：既然 AI 把实现成本和试错成本都压得这么低，过去那种按阶段拆解复杂性的开发流程，大概会慢慢过时。需求、设计、实现、测试，也许不必再像过去那样切得很开。软件开发可能会变成另一种样子：先快速生成，再不断修正；先得到一个能跑的东西，再在循环里逐步逼近更好的方案。
这个判断有道理，但并不完整。
二、AI 改变的是成本结构
AI 的确在改变软件开发，但它并不只是把"阶段式开发"换成"循环试错"，也不是把软件工程变成一种搜索游戏。它改变的，是开发里最昂贵的部分，也改变了人该把精力放在什么地方。
过去写软件，最稀缺的资源之一是实现能力。一个想法从脑中落到系统里，要经过大量机械而艰难的转译。你得搭结构，补细节，处理语法，照顾边界，手动把一个模糊的意图压成机器能够执行的形式。这件事很慢，也很贵。所以传统流程才会强调前置分析、阶段划分、接口冻结、评审关口。说到底，这更像是一种防御：既然修改代价高，就尽量在动手之前把错误挡住。
现在，候选实现便宜得多了。你不再需要把每个细节都亲手敲出来，只需要描述、约束、修正、再描述。代码生成不再是主要瓶颈，而成了中间一环。很多团队于是会生出一种错觉：既然"做出来"已经不贵，那么开发的核心就成了"不断试"。与其预先设计，不如先让 AI 给几个版本；与其花很多时间想清楚，不如边做边收敛。
问题不在"试"本身，而在于很多人把"生成候选方案的成本下降"，当成了"逼近正确方案的成本下降"。这不是一回事。
三、重心开始转向判定
让 AI 写出一段代码，当然比过去便宜得多。但判断这段代码到底该不该存在，是否在正确的边界里工作，是否只在 happy path 上流畅，是否只是把风险从一个角落移到了另一个角落，这些事并没有一起变便宜。很多时候，它们反而更贵。因为当候选实现大量出现之后，真正稀缺的就不再是写代码的手，而是识别伪解的能力。
开发的重心，正从实现转向判定。
以前，一个资深工程师最稳定的价值之一，是能把复杂想法写成稳定实现。现在这项能力当然还重要，但已经不再占据中心。更重要的是别的能力：能不能把一个含混的需求压成 AI 真能执行的任务；能不能提前指出哪些约束必须写进去，哪些默认前提不能依赖，哪些边界不能模糊；能不能在 AI 交付了一个"看起来完成"的结果之后，很快辨认出哪一部分只是字面上的完整，而不是真正的可靠。
程序员不是从"写代码的人"变成了"只提需求的人"。这种说法太轻，也太省事。更接近事实的说法是：程序员越来越像一个约束的组织者。他要组织的不是人力，而是意图、边界、上下文、评估方式、回滚路径，以及一套尽量让错误尽早暴露出来的验证机制。AI 能替他产出不少中间材料，但不能替他决定这些材料该不该进入系统。
四、老环节并没有消失
传统流程里那些看起来最"保守"的环节，并没有消失。
需求没有消失，只是从厚文档变成了高质量的任务描述。设计没有消失，只是从大而全的蓝图，变成了更强调边界、接口和失败方式的约束设计。测试没有消失，反而更靠近流程中心。Review 也没有消失，只是它不再主要是对同事劳动成果的礼貌复核，而越来越像对一个高速生成系统的审计。
AI 并没有让软件开发摆脱工程纪律。它只是让过去被实现成本遮住的问题，更早暴露出来。
五、难点一直都在现实里
软件开发从来不只是把一个想法变成代码。真正困难的，一直是把一个想法放进现实：让它在真实用户、真实依赖、真实时序、真实数据、真实故障里依然成立。瀑布也好，敏捷也好，持续交付也好，这些流程表面上差别很大，底下其实都在处理同一件事：软件面对的不是纸面问题，而是会反扑的现实。
AI 没有改掉这一点。
它可以更快地产生函数、模块、测试、脚手架，甚至架构草案。但真实系统的阻力还在那里：并发中的时序错位，状态一致性的裂缝，权限边界的泄漏，历史包袱的牵连，团队认知的断层，线上环境中脆弱的依赖。这些东西不会因为代码生成更快，就自动变简单。相反，生成越便宜，系统越容易在"差不多能跑"的幻觉里，悄悄积累更多没有被真正理解的部分。
六、更像受控搜索，而不是自动收敛
所以，AI 带来的，很可能不是"软件开发终于可以不分阶段"，而是另一种更细的结构：小步生成，频繁验证，快速回滚，持续逼近。
关键不在"生成"，也不在"逼近"，而在"验证"和"回滚"。
今天很多人对 AI 编程最大的误认，不是高估了模型，而是误解了"试错"。他们把试错理解成一种廉价的探索自由，仿佛只要生成足够多的版本，最优解就会自己浮现出来。可软件并不是那种存在单一最优解的对象。它同时受正确性、性能、可维护性、安全性、协作成本、未来演化空间的共同约束。一个版本也许更快，另一个更清晰，第三个更容易上线，第四个对未来更危险。这里往往没有"最优"，只有在特定处境下暂时可以接受的取舍。
AI 把软件开发推向的，更接近一种受控搜索。它能扩大搜索空间，让你更快看到多个可能性；但搜索空间一旦变大，人就得更清楚地知道自己到底在找什么，不接受什么，愿意牺牲什么。
七、编程本来就不只是生产
编程从来不只是生产活动，它也是判断活动。
在手写代码的年代，这层判断常常埋在实现劳动内部。你一边写，一边判断；一边设计，一边排除；一边调试，一边修正对问题的理解。现在，AI 从中间拿走了很大一块实现劳动，这部分原来藏住的判断就露了出来。于是人们会更明显地感觉到：软件开发里最难的，未必是"怎么写"，而是"写什么""凭什么这样写""写完之后怎么知道它没有在别处坏掉"。
这一点没有变。软件仍然要求人承担理解不足的后果。
八、责任并没有被带走
工具变了，速度变了，界面变了，劳动分布也变了。但有一件事没变：系统一旦进入现实，最后负责的那个位置，仍然不能靠生成能力自动填上。总得有人对边界负责，对失败负责，对那些没有被 prompt 写出来、却一定会在现实里出现的情形负责。这个位置过去就在，今天还在。只不过它不再伪装成"多写几年代码自然就会有的熟练"，而是更直接地显出本来的样子：判断、约束和责任。
所以，AI 时代编程的"变"不只是效率提升，也不是程序员从此退到幕后。更像是把原来缠在一起的几种能力拆开了：生成是一种能力，理解是一种能力，验证是一种能力，承担后果又是另一种能力。过去这些能力都混在"会写代码"里，现在没有那么容易混过去了。
这未必让编程变轻松。很多时候，只是把真正困难的部分摆到了前面。
九、最危险的是那种完成感
一个人面对 AI 生成的整洁 PR，之所以会有那种轻微的不安，往往不是因为它写得不够好。恰恰相反，常常是因为它写得太顺了。顺到让人误以为问题已经解决，顺到把那些还没来得及被看见的风险，包成一种完成感。可软件里最危险的东西，往往不是明显的错误，而是这种过早出现的完成感。
AI 没有终结软件工程的老问题。它只是换了一种方式，把这些问题重新交回到我们手里。
十、当"写出东西"不再稀缺
现在真正需要被重写的，也许不是某一套流程图，而是我们对"编程"这件事的理解。若代码越来越容易被生成，那么编程到底还剩下什么？这不是在问程序员会不会消失，而是在问：当"写出东西"不再稀缺，什么才配叫理解，什么仍然必须由人来判断，什么责任又不会因为界面更流畅就被自动带走。
问题已经不太是，AI 能不能替我们写代码。
问题是，当代码开始源源不断地出现，谁还知道哪些东西本来就不该被写出来。
