AI Coding 正在淘汰的,不是程序员,是只会写代码的人

“

Claude Code、Cursor、Copilot 已经从代码补全走向 Agent。真正变化的不是程序员马上消失，而是代码执行变便宜，问题定义、上下文、验证和责任正在变贵。

有人在 V2EX^[1] 上写了一段很真实的 Claude Code 体验：

“

“我一行代码没写，但是提示词写了不少，调试也花了很多功夫。”

这句话比很多 AI 编程报告都更接近现场。

不是“一键生成一个产品”。也不是“程序员马上没饭吃”。

更像是：代码确实被 AI 写了很多，但需求、上下文、调试、判断、验收，还是一个都没少。

这才是 AI Coding 对程序员真正的冲击。

它不是简单把程序员替换掉，而是在重新定价程序员的能力。

过去，一个程序员的显性价值很大一部分来自“我能把需求翻译成代码”。现在，Claude Code、Cursor、GitHub Copilot agent mode 这类工具，正在把“写出代码”这件事变得越来越便宜。

但便宜的从来不是软件本身。

代码正在变便宜，判断正在变贵。

AI Coding 已经不是自动补全了

很多人对 AI 编程的印象还停在 Copilot 早期：你写半行，它补半行；你写一个函数名，它猜一段实现。

那是 autocomplete 时代。

现在的工具已经变成另一种形态。

Claude Code 官方文档^[2]把它描述成一个能理解整个代码库、跨文件工作、编辑文件、运行命令、完成开发任务的 coding assistant。GitHub 在 2025 年发布 Copilot agent mode^[3] 时，也强调它可以迭代自己的输出、识别错误、建议终端命令，并把任务拆成更多子任务去完成。

这不是“补全一行代码”。

这是一个能读项目、能改文件、能跑命令、能看错误、能继续修的执行者。

对开发者来说，最大的变化不是“少敲几行”。而是你的工作姿势变了。

以前你亲手写代码，AI 站在旁边补句子。

现在你更像在给一个 Agent 派活：

• 先告诉它目标是什么；
• 再告诉它项目约束在哪里；
• 接着让它探索代码库；
• 要求它给计划；
• 放它执行；
• 最后你看 diff、跑测试、决定能不能合并。

这套流程里，敲键盘的动作少了，但程序员的责任没有少。

甚至更重。

因为一旦 Agent 做错，它不会替你背锅。线上故障、脏数据、安全漏洞、错误架构，最后还是落回人身上。

为什么“大家都在用”，却还是不太信它？

Stack Overflow 2025 开发者调查^[4]里，有一个很有意思的冲突：84% 的受访者正在使用或计划使用 AI 工具，专业开发者里 51% 每天使用 AI 工具；但同一份调查也显示，46% 的开发者不信任 AI 工具输出的准确性，只有 33% 表示信任。

这组数字放在一起，才是 AI Coding 的真实温度。

大家都在用。

但大家也都知道，它不稳。

这不是矛盾，这是成熟开发者的正常反应。工具有用，不代表工具可靠；能生成代码，不代表能交付软件；能跑通 demo，不代表能进生产。

METR 在 2025 年做过一个更反直觉的研究^[5]。他们找了 16 位经验丰富的开源开发者，让他们在真实开源仓库里处理 246 个 issue。结果在这个实验设置下，允许使用 AI 工具的任务反而慢了 19%。

这个结论不能粗暴理解成“AI Coding 没用”。METR 自己也提醒，不能把它外推成所有开发者、所有任务都会变慢。

它真正提醒的是另一件事：

AI 的成本，不在生成代码，而在理解、纠错、集成和验证。

如果任务边界很清楚、代码库不复杂、验收标准明确，AI 可能非常快。

但如果项目上下文很重，需求含糊，测试不完整，历史包袱多，AI 生成得越快，你后面越可能花时间追它留下的坑。

这也是为什么很多人用 AI coding 时，会有一种奇怪的错觉：感觉自己很忙，感觉工具一直在输出，感觉进度飞快，但真正算完从需求到可合并的时间，未必省了多少。

你省掉的是打字时间。

你新增的是监督时间。

Simon Willison 说对了一件事

Simon Willison^[6] 有一句话很适合放在这个问题上：

“LLMs amplify existing expertise.”

LLM 放大已有专业能力。

这句话不吓人，但很锋利。

它的意思不是“高手会更高，普通人都会死”。它说的是：AI 并不会凭空给你工程判断。你本来知道怎么拆任务、怎么写测试、怎么判断方案、怎么读 diff、怎么查安全风险，AI 会把这些能力放大。

反过来，如果你本来就不懂项目边界，不会验证结果，看不出生成代码里的隐患，只会把“能跑”当“能上线”，AI 也会放大这个问题。

它会让你更快地得到一堆你解释不清的代码。

Simon 在另一篇关于 vibe coding 的文章^[7]里，把边界说得更清楚：不是所有 AI 辅助编程都是 vibe coding。真正的生产级 AI-assisted programming，不能只靠“Accept All”。他给自己的规则是：不会提交任何自己无法向别人解释清楚的代码。

这句话应该成为程序员使用 AI Coding 的底线。

不会验证的人，只是在更快地制造风险。

“只会写代码”的护城河正在变薄

说到这里，很多程序员真正焦虑的点就浮出来了。

如果 AI 能写代码，那程序员还剩什么？

这个问题问得太粗了。

更准确的问题应该是：如果“按描述生成代码”的成本越来越低，哪些程序员的价值会被削弱，哪些程序员的价值会变强？

被削弱的，是只把自己定位成代码执行者的人。

需求来了，拆不清；上下文缺了，不会补；方案错了，看不出来；AI 写完，不敢 review；出了问题，只能继续让 AI 猜。

这种工作方式在过去也危险，只是没那么快暴露。AI 让它暴露得更快。

被增强的，是能把模糊问题变成可执行任务的人。

他知道怎么把需求拆成小步，知道哪些文件该读，知道哪些约束不能碰，知道让 AI 先做计划而不是直接改代码，知道用测试和日志验收结果，也知道什么时候必须把方向盘拿回来。

这类程序员不会因为 AI 写了更多代码而失去价值。

因为他的价值本来就不只是写代码。

传统开发里，很多价值藏在键盘动作后面。你写代码，其实是在做一整串判断：字段怎么设计，接口怎么拆，异常怎么处理，状态怎么流转，哪里要测试，哪里不能动。

AI Coding 把这件事拆开了。

代码输出被单独拿出来，由 Agent 承担更多。

剩下那些原本隐含在“写代码”里的判断，反而变得更显眼。

AI 放大的不是代码量，是你的工程判断。

真正的新岗位，不叫“提示词工程师”

有一段时间，大家很喜欢讲 prompt engineering。

但对程序员来说，真正重要的不是写几句漂亮 prompt，而是建立一套可重复的 AI 开发流程。

比如 Claude Code 官方最佳实践^[8]里提到的几个动作，放到真实项目里都很朴素：给 Claude 验证自己工作的方式；先探索，再计划，再编码；提供具体上下文；写好 CLAUDE.md；尽早纠偏；积极管理上下文。

这些听起来不像黑科技。

但它们才是决定 AI coding 能不能进工程流程的关键。

一个成熟开发者给 Agent 的指令，不应该只是：

帮我优化这个模块。

而应该更接近：

先不要改代码。

请阅读 order-service 里和退款状态流转相关的文件，列出：
1. 当前状态机有哪些状态；
2. refund_pending 到 refunded 的路径在哪里；
3. 哪些接口、消息和测试会受影响；
4. 你建议的修改计划。

只输出分析和计划，等我确认后再改。

这段指令看起来长，但它背后不是“会写提示词”。

它背后是工程经验：知道先读上下文，知道状态机风险高，知道接口和消息会联动，知道测试要提前纳入，知道不能让 Agent 一上来就动手。

未来更值钱的程序员，很可能不是最会手写样板代码的人，而是最会把问题变成可控任务的人。

他像问题定义者。

也像 Agent 调度者。

最后还是质量负责人。

程序员现在该补的，不是焦虑，是三件事

如果你已经是中高级开发者，没必要把 AI Coding 当成玄学，也没必要把它当成洪水猛兽。

它就是一个新工作台。

问题是你要不要学会在这个工作台上继续保持专业性。

第一，给项目建立 AI 使用说明。

不管叫 CLAUDE.md、AGENTS.md，还是团队自己的工程手册，核心都一样：把技术栈、启动命令、测试命令、代码风格、目录结构、禁止改动区域、常见坑写清楚。

不要每次都在聊天窗口里重新解释项目。

也不要指望 Agent 自己永远记得。

第二，把“先计划、再执行、再验证”变成默认流程。

遇到复杂任务，不要直接让 AI 改。

先让它读代码，列影响面，给方案，说明风险。你确认以后，再让它分步执行。执行完以后，让它跑测试、解释 diff、列出仍未覆盖的风险。

这不是保守。

这是把 Agent 从一个乱冲的实习生，变成一个可管理的执行者。

第三，不提交自己解释不清的 AI 代码。

这条最简单，也最难。

简单在于它没有灰度：解释不清，就别合。

难在于 AI 经常会给你一种“看起来差不多”的诱惑。尤其是 deadline 很近、测试又刚好绿的时候，你很容易把不理解包装成信任工具。

但生产系统不认这个。

线上出问题时，没人关心这段代码是你手写的，还是 AI 写的。

责任只看谁合进去的。

最后会留下什么样的程序员？

那句 V2EX 体验里，藏着未来几年程序员工作的新形状。

不是不写代码了。

而是“写代码”这个动作会被拆散，分给人和 Agent 共同完成。

Agent 会承担越来越多执行层工作。生成、改写、补测试、跑命令、修一部分错误，它会越来越熟。

人留下来的部分，会更像软件工程里最难被外包的部分：判断问题是不是真的问题，决定什么方案值得做，知道哪里不能碰，能解释系统为什么这样设计，能在结果出错时找到原因，并承担最后的质量责任。

所以，程序员不会因为 AI Coding 立刻消失。

但“只会写代码”这件事，确实越来越难成为护城河。

你可以不害怕 AI。

但最好开始训练自己成为那个能调度 AI、约束 AI、验证 AI 的人。

因为未来真正值钱的，不是你比 AI 多写几行代码。

而是 AI 写完之后，你知道哪几行不能信。

引用链接