夜雨聆风摘要：AI 会写代码之后，程序员真正值钱的能力反而更清楚了：拆任务、审代码、控风险。
上篇写 Claude Code 提效，有朋友问：
“是不是以后程序员最重要的能力，就是会写提示词？”
我觉得不是。
提示词当然要会，但它只是工具使用说明。真正决定一个程序员还能不能稳住饭碗的，不是“会不会让 AI 写代码”，而是你能不能判断这段代码该不该写、能不能上、出了问题怎么兜底。
尤其是背着房贷的中年程序员，别把安全感押在“我比别人更会用某个 AI 工具”上。
工具会变。
今天是 Claude Code，明天是 Codex，后天可能又是别的 Agent。
真正能穿过工具周期的能力，还是那几件老东西：拆任务、看风险、做验证、能交付。
01 会用 AI，不等于会交付
现在很多 AI 编程演示都很刺激。
一句话生成页面。一句话修复 bug。一句话补测试。
看起来很爽。
但公司里真正麻烦的需求，很少是“一句话”能说清楚的。
真实需求通常长这样：
产品说用户反馈偶现失败。测试说复现不稳定。后端说可能是前端参数问题。前端说接口返回不一致。运维说日志里看不到明显异常。老板说这个问题今天必须解决。
这时候你让 AI 直接“帮我修一下”，大概率只会得到一个看似合理的补丁。
但补丁是不是修到了根因？有没有影响老用户？有没有破坏兼容性？有没有新增监控？有没有回滚方案？
这些东西，AI 可以帮忙做，但它不会天然替你负责。
交付这件事，最后还是人负责。
02 中年程序员的优势，不是手速
我以前也很在意编码速度。
谁写得快，谁懂的框架多，谁能熬夜把需求赶出来，好像谁就更强。
但到了有房贷、有家庭、有健康账单的阶段，会慢慢发现：纯拼手速是最不划算的。
年轻人可以熬夜补一个大版本。
AI 可以一分钟生成几百行代码。
你靠什么赢？——必须是靠判断。
知道需求里哪句话有坑。知道一个字段改名会影响哪些老接口。知道某个“临时方案”半年后会变成生产事故。知道什么时候该写测试，什么时候该先加日志。知道什么时候该拒绝一个看起来很简单的需求。
AI 时代，中年程序员最不该丢的，就是这种工程判断力。
它不性感，但很值钱。
因为公司真正愿意为你付钱的，不是你敲键盘的动作，而是你减少事故、缩短排障时间、提高交付确定性的能力。
03 第一件事：把需求拆成 AI 能执行的小任务
很多人用 AI 效果不好，不是模型不行，是任务太糊。
比如：
帮我优化这个系统。
这句话人都难办，AI 更难办。
更好的问法是：
先阅读订单模块，不要改代码。请找出下单流程的入口、核心 service、数据库写入点和外部接口调用。输出调用链和可能的性能瓶颈。
再进一步：
只针对库存校验这一步做优化。要求：1. 不改变接口返回结构2. 不引入新依赖3. 保留现有日志4. 修改后运行订单模块测试
这就是拆任务。
不是把一个大问题丢给 AI，而是把问题拆到它能稳定执行、你也能稳定验收的大小。
以后程序员的一个核心能力，就是当“任务拆解员”。
谁能把模糊需求拆成清楚的小闭环，谁就更容易把 AI 变成生产力。
04 第二件事：练代码审查，而不是只练生成
AI 写代码越快，代码审查越重要。
以前一个人一天写几百行，你还能慢慢看。
以后一个 Agent 半小时改 20 个文件，你不练 review，就只能被 diff 淹没。
我现在看 AI 生成的代码，重点不看它“写得像不像人”，而看五个问题：
第一，改动是不是最小。第二，有没有改到无关文件。第三，异常和空值有没有兜住。第四，测试有没有覆盖关键路径。第五，失败后有没有办法回滚。
可以直接让 AI 先自查一遍：
请 review 当前 git diff。只找风险，不要表扬。重点看：1. 是否有兼容性问题2. 是否缺测试3. 是否有无关重构4. 是否有权限、并发、数据一致性风险5. 是否可以用更小改动完成
但最后你还得自己看。
这不是形式主义。
这是职业护城河。
会生成代码的人会越来越多，会审 AI 代码、敢为上线负责的人，反而更稀缺。
05 第三件事：把验证做成习惯
以前我们说“写完跑一下测试”，很多人觉得是流程要求。
现在不一样了。
AI 时代，验证不是流程，是刹车。
没有验证的 AI 代码，就像没有刹车的车，看起来跑得快，出事也快。
一个靠谱的工作流应该是：
先复现问题。再写最小测试。然后修改代码。最后跑测试和必要的构建命令。
如果没有现成测试，至少让 AI 留一个最小自检：
这个项目没有完整测试。请为本次修改补一个最小可运行检查。不要引入新框架。只要能证明核心逻辑没坏。
别嫌麻烦。
真正麻烦的是线上出问题后，半夜起来查日志。
背房贷的人，最怕的不是多花十分钟跑测试，而是一次事故把信用打没。
06 不要把提示词当成救命稻草
提示词当然有用。
但提示词不是护城河。
网上很快会有一堆模板：
让 AI 写代码的模板。让 AI 做 review 的模板。让 AI 生成测试的模板。
这些都能学，但别神化。
模板解决的是表达问题，不解决判断问题。
同样一个 prompt，放在不同项目里，结果可能完全不同。
你得知道什么时候该用，什么时候不该用，什么时候 AI 给出的方案看起来漂亮但不能上生产。
这才是经验的价值。
07 我给自己的 AI 编程原则
第一，复杂需求先读代码，不直接改。第二，能小改就小改，不顺手重构。第三，AI 改完必须看 diff。第四，关键逻辑必须有验证。第五，权限、支付、数据删除、迁移脚本，永远人工重点审。
这几条不高级，但能保命。
工具越强，越要有边界。
没有边界的提效，很容易变成加速踩坑。
08 最后
AI 编程工具会越来越强。
这件事不用怀疑。
但它越强，越说明程序员需要从“代码劳动力”往“交付负责人”升级。
别只问自己：
我会不会用 Claude Code？我会不会写 prompt？
更应该问：
我能不能把需求拆清楚？我能不能看懂 AI 改了什么？我能不能判断这段代码能不能上？我能不能在出问题时快速定位、回滚、止损？
中年程序员的安全感，不该来自“我还能比 AI 写得快”。
那条路迟早很累。
更稳的路是：让 AI 去写得快，你来负责写得对、改得小、验得住、上得稳。
这才是背着房贷也能慢慢站稳的能力。
背房贷的程序员，需要能落地的 AI 工作流。
这里不神化工具，只把提效、交付、风险和现金流讲清楚。
