夜雨聆风先说个可能不太讨喜的判断：AI 编程最先淘汰的，可能不是程序员，而是一堆糊弄了很多年的开发流程。
这两年聊 AI 编程，大家最爱问的问题还是那一个：程序员会不会失业？
这个问题当然刺激，但我觉得问偏了。
因为你只要真正用 AI 写过一点复杂东西，就会发现：它确实能很快给你一版代码，甚至看起来还挺像那么回事。但软件开发最麻烦的地方，从来不只是「写出第一版」。真正麻烦的是后面那一串：
需求改了怎么办？边界条件谁补？异常场景谁想？测试谁写？老系统怎么接？上线以后谁维护？三个月后没人记得当初为什么这么写，谁来背锅？
AI 能把第一版拉得很快，但它不会自动替你解决这些组织问题。
所以我现在越来越觉得，AI 编程真正带来的变化，不是「程序员消失」，而是它会逼团队把工作流重写一遍。
一、不是代码快了，项目就快了
很多团队第一次试 AI 编程，都会有一个兴奋期。
以前半天写不出来的页面，现在几分钟有了。以前懒得写的脚本，现在一句话就生成。以前要查半天文档的接口，现在 AI 直接给你拼好。
这个阶段很爽，也很容易让人误判：既然代码生成变快了，那项目交付是不是也会变快？
不一定。
因为项目慢，很多时候不是慢在敲代码，而是慢在「不知道到底要什么」。
需求里一句「支持批量导入」，后面可能藏着几十个问题：文件格式是什么？字段缺失怎么办？重复数据怎么处理？权限怎么校验？失败后要不要回滚？用户能不能下载错误报告？导入过程要不要异步？数据量大了会不会卡死？
这些问题你不写清楚，人写代码的时候会来问你。AI 不一定会问，它更可能直接给你一个看起来能跑的版本。
人类程序员遇到模糊需求，至少会犹豫；AI 遇到模糊需求，常常会自信地把坑填满。
这就是 AI 编程的第一个反常识：它不是降低了需求表达的要求，而是提高了。
以前需求写得含糊一点，还能靠人和人之间的默契、会议、拍脑袋补上。现在你把一个含糊的需求丢给 AI，它会把含糊变成代码。代码一旦生成，混乱就从文档里搬到了系统里。
二、PRD 不够了，Spec 会变成事实源
过去很多团队的 PRD，说白了更像沟通材料。
给老板看一版，给研发看一版，给测试看一版。里面有目标、有流程、有原型、有描述，但很多细节并没有真的落到可执行的程度。
AI 编程会让这件事变得很尴尬。
因为 AI 不吃「你应该懂我意思」这一套。它需要明确的输入、边界、约束和验收标准。你不给，它就猜。它猜得准，你觉得它聪明；它猜错了，你就开始怀疑模型不行。
但很多时候，不是模型不行，是团队没有把「事实源」定义清楚。
到底谁说了算？
是 PRD？是原型？是口头会议纪要？是代码现状？是测试用例？还是某个人在群里临时补的一句话？
AI 进来以后，这个问题绕不开。
如果团队没有一个稳定的规格说明，AI 生成得越快，后面的返工可能越快。今天按 PRD 写，明天按原型改，后天又按测试口径补，最后代码变成一锅粥。
所以我更愿意把 AI 编程理解成 Spec-driven 的工作流：先把要做什么、不要做什么、怎么验收写清楚，再让 AI 进入实现环节。
这里的 Spec 不一定是多么正式的大文档，它可以是一组用户故事、一组接口约束、一组验收规则、一组测试用例。但它必须足够清楚，清楚到 AI 能执行，人也能检查。
未来会写需求的人，不只是会写漂亮文档，而是能把意图翻译成机器和团队都能执行的规则。
三、测试会变成新的规格语言
以前很多团队把测试放在最后。
代码写完了，提测。测试发现问题，提 bug。研发修一轮，再测一轮。大家都忙，最后赶上线。
AI 编程会让这种模式更吃力。
原因很简单：AI 生成代码太快了。如果没有测试约束，团队很快就会被一堆「看起来能跑」的代码淹没。你不知道它哪里对，哪里错，哪里只是刚好没出事。
这时候测试不再只是质量检查，而会变成一种规格语言。
你说「支持批量导入」，这句话太虚。你写成测试，就具体了：
空文件应该失败。缺少必填字段应该返回明确错误。重复数据应该跳过还是覆盖。单次导入 1 万行时不能阻塞主流程。部分失败时要生成错误明细。
这些测试，其实就是在回答「我们到底要什么」。
AI 可以帮你写测试，但它不能替你决定业务边界。它可以补代码，但它不能替你承担验收责任。
所以以后产品、研发、测试之间的关系会变。产品不能只丢一句需求，研发不能只追求代码生成速度，测试也不能只在最后兜底。三方都要围绕一个问题协作：
这件事怎样才算做对？
这个问题回答得越清楚，AI 越有用。回答不清楚，AI 只是把返工提前包装成效率。
最近一个很有意思的信号是，AI 已经不满足于只当“代码补全工具”了。
它开始往更靠后的环节走：帮你扫漏洞、提修复建议、直接生成 PR，甚至进入安全和运维这些以前默认属于“后链条”的工作里。
这件事的意义不是“AI 更强了”这么简单，而是：一旦 AI 进入的不只是编码，而是整个研发协作链条，团队原来靠口头、靠默契、靠人盯人的那套做法，会更快失效。
四、真正的风险，是没人敢改
AI 编程还有一个经常被忽略的风险：代码生成出来了，但没人真的理解。
短期看，这好像是效率。一个人以前一天写 200 行，现在一天生成 2000 行。报表很好看，演示也很漂亮。
但软件不是写完就结束。它会改，会坏，会接新需求，会被新人维护。
如果一段 AI 生成的代码，团队里没人能解释它为什么这么写，没人敢动它，没人知道改哪里会牵一发动全身，那它就不是资产，而是负债。
AI 生成代码不可怕，可怕的是组织把看不懂的代码当成效率。
这件事对管理者尤其重要。
管理者不应该只问「用了 AI 以后效率提升多少」。还要问：
哪些代码可以让 AI 生成？ 哪些核心逻辑必须人工 review？ 哪些变更必须配测试？ 哪些关键决策要留下记录？ 哪些代码如果没人能解释，就不能合并？
这些问题听起来不酷，但决定了 AI 编程能不能进入生产。
没有这些规则，AI 编程很容易变成个人炫技：某个人很会用工具，短期产出惊人；但一旦换人、换需求、换系统，团队就开始还债。
而且最近还有一个变化，很多人容易忽略：模型本身正在快速商品化。
默认模型在换，价格体系在换，能力边界也在换。今天你觉得某个模型特别顺手，下个月可能另一个更便宜、上下文更长、Agent 能力更强的就顶上来了。
这意味着，团队如果把竞争力押在“谁最会用某个模型”，这件事本身就不稳定。
真正稳定的，不是某个模型，而是你的工作流有没有把需求、规格、测试、Review 和留痕沉淀下来。模型会换，流程资产不会。
五、AI 编程真正改变的是分工
所以回到一开始那个问题：程序员会不会被 AI 取代？
我的判断是，粗暴说「会」或者「不会」都太简单。
更准确的说法是：一些只负责机械实现的人会越来越被动，但能定义问题、拆解任务、设计边界、验证结果的人会越来越重要。
以前团队分工大概是：产品写需求，研发写代码，测试找问题。
AI 进来以后，这条线会被打散。
产品要更懂规格和验收，不能只写愿望。研发要更懂系统设计和可维护性，不能只看代码能不能跑。测试要更早介入，把质量要求变成可执行规则。管理者要更关心责任边界，不能只看生成速度。
换句话说，AI 编程不是把程序员一个岗位拿掉，而是把很多岗位之间原来模糊的边界照亮了。
以前靠默契、靠经验、靠临时沟通补上的东西，现在都要变成清楚的规则、流程和验证。
这对成熟团队是机会，对混乱团队是放大器。
六、最后
我不太相信「一个提示词解决软件开发」这种说法。
真正的软件开发，永远不只是把想法变成代码，而是把一堆不稳定的需求、约束、边界和风险，变成一个可以长期运行、可以被人理解、可以持续演化的系统。
AI 会让写代码这件事变快，但也会让团队过去那些说不清、测不准、没人负责的问题更快暴露。
所以，别再只问 AI 会不会取代程序员了。
更该问的是：
当 AI 已经能写代码，你的团队有没有能力告诉它写什么、怎么写、怎样才算写对？
如果这个问题答不上来，问题就不在 AI。
问题在工作流。
AI 编程不是程序员的终点，而是粗放开发流程的终点。
留个问题，评论区聊聊：你们团队用 AI 写代码之后，第一版之后的活——改需求、补测试、做交接——是变轻松了，还是更乱了？我想听听一线的真实版本。
