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

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

有人在 V2EX 上写了一段很真实的 Claude Code 体验:

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

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

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

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

AI Coding 时代程序员价值正在被重写

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

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

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

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

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

AI Coding 已经不是自动补全了

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

那是 autocomplete 时代。

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

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

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

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

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

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

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

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

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

甚至更重。

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

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

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

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

大家都在用。

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

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

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

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

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

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

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

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

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

你省掉的是打字时间。

你新增的是监督时间。

Simon Willison 说对了一件事

Simon Willison 有一句话很适合放在这个问题上:

“LLMs amplify existing expertise.”

LLM 放大已有专业能力。

Simon Willison(图片来源:Wikimedia Commons, Remy Sharp, CC BY-SA 2.0)

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

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

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

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

Simon 在另一篇关于 vibe coding 的文章里,把边界说得更清楚:不是所有 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 官方最佳实践里提到的几个动作,放到真实项目里都很朴素:给 Claude 验证自己工作的方式;先探索,再计划,再编码;提供具体上下文;写好 CLAUDE.md;尽早纠偏;积极管理上下文。

这些听起来不像黑科技。

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

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

1
帮我优化这个模块。

而应该更接近:

1
2
3
4
5
6
7
8
9
先不要改代码。

请阅读 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 写完之后,你知道哪几行不能信。