AI写代码，让你付出的代价是什么？|agent|代码|工作流|知名企业|编程|谷歌

越来越多的程序员可能都变成了这样：IDE 还开着，手却越来越少敲键盘；PR 还在提，真正从零开始推敲设计的时刻却越来越少。效率曲线一路向上，发布节奏越来越快，团队里关于 AI 的讨论也从“要不要用”变成了“为什么你用得不够多”。一切看起来都在进步。

但有时候，在深夜合上电脑之后，会冒出一个不那么 KPI 的问题：我们到底是在变强，还是在变依赖？

下面这篇文章没有站在反 AI 的立场，也不是技术布道。它更像是一种自我审视——当 AI 深入到编码、评审、架构甚至决策层面，我们究竟获得了什么，又可能在不知不觉中失去了什么。

原文链接：https://tomwojcik.com/posts/2026-02-15/finding-the-right-amount-of-ai/

作者 | Tom Wojcik 责编 | 苏宓

出品 | CSDN（ID：CSDNnews）

我认识的每一个开发者，现在都在用 AI 写代码。效率提升确实很明显，但代价往往不会出现在任何仪表盘上。

不妨想象一条光谱。最左边，是人类自己敲键盘，在 IDE 里逐行阅读和编写代码。最右边，是 AGI，它能够独立完成一切，成本极低、几乎零失误、能力超过任何人类，而且不需要人类监督。

在这两个极端之间的某个位置，就是今天正在使用 AI 的你。这个分界线每周都在向右移动：模型更强了，工具更成熟了，工作流也在不断优化。

最近我在 HN 上看到了一个名为 daxfohl 网友写的一条评论，写得非常精彩：

“用 AI 过多，和用 AI 过少，哪种风险更高？”

这句话让我重新思考 LLM 在编程中的角色。尤其是在读到其他开发者分享各自团队引入 AI 的经验之后，我意识到问题并不只是“要不要用”。两个方向都可能走偏。但随着模型不断进化，在工作中“合适”的 AI 使用比例，是不是也在悄悄变化？

我们是怎么走到这一步的？

不久前，第一批 AI 编程工具开始出现，比如 2022 年的 Copilot 和 2023 年的 Cursor。它们可以通过 RAG 快速索引整个代码库，因此掌握了本地上下文。同时，它们背后的大模型本身就带着对互联网的“外部知识”。从那以后，普通用户不再需要频繁使用 Google、刷 StackOverflow。

Cursor 甚至直接提供了一套定制 IDE，把 AI 自动补全、内置聊天等能力整合进去，让整个体验变得连贯，而不是零散地拼插件。

接着，“智能体”的概念应运而生。

MCP、自动化工作流、可以通宵运行的 Agent，层出不穷。这是与 Cursor 等 AI 应用方式完全不同的用法。它不再是“AI 辅助人类写代码”，而是变成了“人类辅助 AI 写代码”。

很多开发者试过，然后踩了坑。Agent 会犯大量细碎的小错误。所谓 AI-first 的流程，要求你从根本上改变对编程的理解方式，否则很难产出好结果。更麻烦的是，Agent 经常陷入循环，凭空“幻想”出不存在的依赖，或者生成“看起来差不多对了”的代码——可惜就是不对。你得学习一整套新技术，而这种技术又被因害怕错过机会的心理所驱动。而且，这套闪闪发光的新工具，几乎从来不会第一次就给出 100% 正确的结果。

软件原本是确定性的。你用 if/else 分支控制逻辑，用明确状态机管理流程，一切都清清楚楚。现在却变成用 Prompt、系统指令、CLAUDE.md 文件去“引导”模型，然后祈祷它输出你想要的结果。

后来，Claude Opus 4.5 发布了。

那些之前只存在于讨论中的工作流，开始真正“开箱即用”地跑起来——当然也不是每次都成功，但成功的次数明显多了。工程师的角色也在变化，越来越像“前线部署工程师”，负责的事情远不止写代码。有时甚至不再亲手写代码。

最近，Spotify 联合 CEO Gustav Söderström 提到：

“一名 Spotify 的工程师，在早晨通勤路上，通过手机上的 Slack，就可以让 Claude 修一个 bug，或者给 iOS 应用加个新功能。等 Claude 完成后，新版本会直接通过 Slack 推送到他的手机上。他甚至还没到办公室，就可以把改动合并到生产环境。”

当然，我希望他们至少在合并前会审一下代码。

下一阶段，是（几乎）完全自动化。这正是许多高管所追求的目标：一个永不睡觉、不会疲倦、随时待命、生产力无限的“员工”。听上去像是资本主义的终极幻想。

可历史提醒我们，时间表往往比愿景慢得多。2016 年，Geoffrey Hinton 预测，五年内深度学习将在医学影像分析上超越放射科医生。Anthropic 的 CEO 也曾预测，到 2025 年 3 月之后的 3-6 个月内，AI 将编写 90% 的代码。

这些都没有按原计划发生。

趋势是真的。但时间线，总是在往后推。

AI 如何影响你的大脑？

2012 年，神经科学家 Manfred Spitzer 出版了《Digital Dementia》一书。他在书中提出，当我们把原本需要自己完成的心智任务外包给数字设备时，负责这些任务的大脑通路会逐渐退化。用进废退。虽然书中的部分观点仍存在争议，但神经可塑性研究确实表明：经常使用的神经通路会被强化，而长期不用的会变弱。书的核心观点很简单——你停止练习的认知能力，会慢慢下降。

软件工程研究者 Margaret-Anne Storey 最近给这种现象起了一个更精确的名字：认知债务（cognitive debt）。技术债务存在于代码里，认知债务存在于开发者的大脑中。它指的是那种在高速构建系统、却没有真正理解所构建内容时逐渐积累的理解流失。

她的观点建立在 Peter Naur 1985 年提出的理论之上：程序本质上是一种存在于开发者心中的“理论”，它包含程序做什么、设计意图如何映射到实现，以及未来如何演化。当这种“理论”在开发者头脑中碎裂时，系统就会变成一个黑箱。

把这一点直接套用到完全 Agent 化的编程模式上。如果你停止写代码，只负责审查 AI 的输出，你推理代码的能力就会开始退化。这个过程缓慢、隐蔽，但不可避免。你无法真正深入审查那些你已经无法深入理解的内容。

这不仅仅是纸上谈兵。2026 年，Shen 和 Tamkin 做了一项随机对照研究：他们让 52 名专业开发者学习一个新的异步库，并分成使用 AI 辅助和不使用 AI 两组。结果显示，AI 组在概念理解、调试能力和代码阅读方面的得分低了 17%。差距最大的是调试能力——恰恰是发现 AI 错误所最需要的技能。仅仅一小时被动依赖 AI 辅助工作，就已经可以测量到技能衰退。

更隐蔽的部分在于：你几乎察觉不到这种下降，因为工具在替你弥补。你感觉自己很高效。PR 在持续合并。心理学家 Mihaly Csikszentmihalyi 关于“心流”的研究指出，心流状态依赖于挑战与技能之间的平衡。大脑需要被恰到好处地拉伸。真正的心流会带来成长。

研究者 Rachel Thomas 则把 AI 辅助工作带来的状态称为“黑暗心流”（dark flow）。这个词源自赌博研究，用来描述老虎机刻意制造的那种恍惚沉浸状态。你感到投入，但挑战与技能之间的平衡已经消失，因为 AI 承担了挑战部分。它看起来像深度工作的心流状态，但反馈循环已经断裂。你并没有变得更强，而是在变得依赖。

没有写代码，只有审查

HN 评论区里有个反复出现的观察：如果 AI 写了所有代码，而你只负责审查，那么审查所需的能力从哪里来？两者不可分割。你不会通过读教科书或 PR 学会辨别好代码。你是通过写出糟糕的代码、被审查者拆得体无完肤、在多年实践中逐渐建立直觉，才学会的。

这形成了我所说的“审查悖论”：AI 写得越多，人类就越不具备审查它的能力。Shen–Tamkin 的研究为此提供了数据支持。完全把任务交给 AI 的开发者完成速度最快，但评估得分最低。最能从 AI 提升效率中受益的新手，恰恰是最需要调试能力来监督 AI 的人，而 AI 又最先侵蚀的正是这种能力。

Storey 提出的解决方案很直接：“在部署前，要求人类理解每一项 AI 生成的改动。”这是正确答案。但在以“速度”为核心指标的环境里，这往往也是第一个被跳过的环节。

资历塌缩

问题不只是个人技能衰退。过去，我们有初级工程师、中级、高级、Staff、架构师。这是一条建立在多年实践之上的成长路径。初级工程师会花很多年写出在代码审查中被拒绝的代码，不是因为不认真，而是因为经验不足。正是这些经历，构建了判断力——区分“能写函数的人”和“能设计系统的人”。你不可能一夜之间成为高级工程师。

除非你用 AI。

现在，一个初级工程师配上 Claude Code（Opus 4.5+），就能提交看起来像高级工程师写的 PR。从整体效率看，这是好事。但这是否意味着高级工程师的“帽子”可以从第一天就戴在每个人头上？帽子在，脑子却没变。那位初级工程师并不知道为什么选择这种架构。以我的经验来看，Claude Code 有时会漏掉本该存在的数据库事务；有时会因为各种原因给本不该加锁的资源加锁。我可以为自己的决策辩护，也乐于在代码被质疑时展开讨论。但一个初级工程师会怎么做？去问 Claude。

这是双向的崩溃。停止亲自写代码、只审查 AI 输出的高级工程师，会失去自身的深度。跳过挣扎阶段的初级工程师，也从未真正建立起这种深度。组织每天花费大量高级工程师的时间在代码审查上，却同时破坏了培养高级工程师的机制。那条通过写糟糕代码、被审查、在失败中建立直觉的成长管道，正在被完全绕开。等这条管道彻底干涸时，会发生什么？几乎没人讨论这个问题。

C-Level 们说对了什么，又说错了什么

看看每周摆在高管桌上的内容：

微软 AI 负责人 Mustafa Suleyman 表示，18 个月内所有白领工作都会被自动化。
Anthropic 的 CEO Dario Amodei 预测，6–12 个月内 AI 就会取代软件工程师，还引用自家工程师的话说，他们已经不写代码了，只是让模型写，然后自己编辑输出。
Sundar Pichai 则透露，2024 年底谷歌新增代码中有 25% 是 AI 生成的。几个月后，Google Research 报告这个数字已经达到 50% 的代码字符。

如果你是一位 CTO，看着这样的曲线走势，当然会推动团队全面拥抱 AI。

问题在于，这些预测往往来自正在销售 AI 的人，或者试图用 AI 概念支撑股价的人。他们有充分动机加速 AI 的普及，却几乎不需要为时间表失准负责。而历史告诉我们，时间表几乎总会失准。更何况，“50% 的代码字符”出自一家从模型、工具链到基础设施全部自研的公司，对你下周一用现成 Agent 能做到什么，参考意义并不大。

AI 的采用不是一个可以一键切换的开关，而是一项需要校准的能力。事情远不止“强制使用某个工具”、“制定 AI-first 政策”、“用 AI 使用量来衡量开发者表现”这么简单（/r/ExperiencedDevs 上有大量类似故事）。很多原本良好的实践——设计模式、完整测试覆盖、合并前的人工测试——正在被跳过，因为它们会拖慢节奏。AI 弄坏的？AI 会修好。需要 review？AI 来做。甚至不需要 Greptile 或 CodeRabbit。直接把 PR 丢给 Claude Code reviewer agent，或者 Gemini，或者 Codex。任选一种“毒药”。

当你强制推广 AI 使用时，现实会变成什么样？

一位开发者在 r/ExperiencedDevs 论坛上分享了他们公司开始按人统计 AI 使用量：“我干脆让我的机器人去做一些我根本不在乎的随机任务。有一天我让 Claude 去随便翻目录‘找 bug’，或者回答我早就知道答案的问题。”

结果那个帖子里有很多工程师抱怨，AI 让代码审查“难度无限上升，因为团队负责人长时间脱离实际编码后，用 AI 生成了大量垃圾代码。”

这其实很令人惋惜。熟练使用 AI 工具本应是开发者的福利。它确实能提速，也是管理层想要的东西。那些“刷指标”的人，如果被管理层发现真实情况，很可能会当场被解雇（这也公平）。但他们之所以刷指标，是因为害怕被解雇。

那么，公司里谁该决定 AI 使用的“阈值”？如果你最优秀的工程师拒绝用 AI 怎么办？如果新招的初级工程师全天候用 AI 又怎么办？管理层正在寻找答案，但答案绝不只是“统计 AI 使用量”这么简单。

这正是古德哈特定律（Goodhart’s Law）的现实版：“当一个指标成为目标，它就不再是一个好指标。”

如果你按人追踪 AI 使用率，得到的不会是更好的工程质量，而是合规表演。开发者会对工具产生抵触情绪，而 AI 本可以带来的真实生产力提升，则会被组织层面的失调掩盖。

那些没人谈的成本

经济成本很明显。让 Agent 处理一个非平凡功能，往往需要按小时计费，这些时间并不便宜。

更严重的是人的成本，而这几乎没人讨论。

上文也提到过，写代码能让人进入心流状态。在这种状态下，你会全神贯注、深入思考、创造性地去解决问题，时间仿佛飞逝，最后你会得到一个自己构建的成果，并为此感到自豪。有人在你的 PR 下留言“Good job!”并点了赞表示认可。那种满足感是真实的。

审查 AI 生成的代码不会带来这种体验。它恰恰相反，是一种精神消耗。

开发者需要创造带来的多巴胺刺激。这不是额外福利，而是保持优秀工程师持续投入、持续学习、避免倦怠的关键。很多人成为资深开发者，正是因为热爱编码本身。把创造替换为监督，你得到的不是更快交付，而是更快的倦怠。工程这项创造性工作，被变成了最糟糕版本的 QA。AI 负责创作，人类负责“叠衣服”。

找到属于你的阈值

我每天都在用 AI。工作用，业余项目也用，而且不想回到没有它的时代。我真的很喜欢它。

正因如此，我才担心。我害怕自己已经上瘾，已经依赖。我实现了无数自定义命令、Skill 和 Agent。每天都会看 Claude Code 的更新日志。我知道很多人处在类似状态，我们都在想未来会怎样。我们会被 AI 取代吗？还是会负责清理 AI 生成的“代码残渣”？对我来说，合适的 AI 使用比例到底是多少？

AI 只是工具。极其强大的工具，但终究是工具。你不会强制每个工程师都用同一个 IDE，也不会用“每天写多少行代码”来考核人（希望如此）。你会让他们选择最有效的工具，并衡量真正重要的东西——能否交付。

合适的 AI 使用量，不是零，也不是最大化。

Shen–Tamkin 的研究识别出六种开发者与 AI 的互动模式。其中三种会导致学习效果变差：完全委托、逐步依赖、把调试外包给 AI。另三种则在完全可访问 AI 的情况下仍能保持学习效果：请求解释、提出概念性问题、独立写代码并把 AI 作为澄清工具。区别不在于是否使用 AI，而在于是否保持认知参与。

软件工程从来不只是敲代码。它包括定义问题、真正理解问题、把业务语言转化为产品语言再转化为代码、澄清模糊点、做权衡、理解改动会带来什么连锁反应。在 AGI 到来之前，总要有人做这些事，而 AGI 离那一步还很远（所幸如此）。凌晨三点电话响起，你能在没有 Agent 的情况下排查问题吗？如果不能，你可能已经把 AI 编程用得太过了。如果 AI 使用率变成开发者绩效指标，也许“用得太多”同样应该被约束。不是因为工具不好，而是因为编码能力值得维护。

用得太少的风险（经验观察）

如果在 2026 年你完全不用 AI，那确实是在错失实实在在的收益：

搜索与上下文理解：AI 在浏览陌生代码库、理解遗留系统、寻找相关模式方面，确实比 Google 更高效。这一点本身就足以让它成为工作流的一部分（自 2023 年 Cursor 等工具出现以来）。
样板代码与脚手架：当 Agent 几秒钟就能生成 CRUD 接口、配置文件或测试模板时，你还手写第 100 个类似模块，不是工匠精神，而是固执。直接用 AI。现在的开发者都身兼数职，早已不是单纯的 CRUD 工程师了（尤其在 2025 年 Sonnet 之后）。
工作流本身：调查、规划、实现、测试、验证——配合定制 Agent，这套流程确实让功能交付变快。原本几天的工作缩短为几小时。没有达到宣传中的 10 倍提升，但在成熟代码库上实现 2 倍或 4 倍并不难。当然，你必须真正理解输出，以及 AI 做出的每一个决策（2025 年 Opus 4.5 之后尤为明显）。
探索能力：“这个模块做什么？这个 API 怎么工作？如果我改这里会坏什么？”AI 在这些问题上表现出色。它不会替代阅读代码，但能帮你在正确的时间定位到正确的文件（自 2023 年起）。

出于原则拒绝 AI，与出于炒作盲目拥抱一样不理性。

用得太多的风险（经验与预测）

如果你全面押注自治 AI 编程，尤其在不了解其原理的情况下，风险可能比“效率下降”更糟——它是隐形的退化：

看起来像功能的 Bug：AI 生成的代码通过 CI，类型检查无误，测试全绿。但内部埋着微妙的逻辑错误、幻觉式边界情况、在高负载下会崩溃的模式。在金融或医疗领域，一个不会报错的错误数字，比系统崩溃更糟。（重要性在下降，但依然存在）
没人真正理解的代码库：当 Agent 写下全部代码，人类只做审查，半年后团队里没人能解释系统为什么这样设计。AI 做出了选择，测试通过，于是无人质疑。Storey 曾描述一个学生团队正是因此陷入困境：他们无法做简单改动，因为没人说得清当初的设计决策。她的结论很明确：“没有理解的速度不可持续。”（在我看来，这永远会是问题）
认知退化：前面“数字痴呆”部分提到的一切。停止练习的技能必然下降。（同样会长期存在）
资深工程师培养管道干涸：上文已讨论。这种问题需要多年才会显现，也正因如此没人提前规划。（这是新问题，未来会怎样还很难说）
倦怠：整天审查 AI 输出，却没有创造带来的多巴胺刺激，这种工作描述不可持续。（老问题，但可能来得更快？）

悄然衰退

让我夜不能寐的是这个问题。按照每一个仪表盘上的指标来看，AI 辅助的人类开发和人类辅助的 AI 开发都在进步——PR 交付更多，功能迭代更快，周期时间缩短，图表一片向上向右。

但这些指标捕捉不到下面正在发生的事情：整天审查你自己没写的代码带来的精神疲劳；盯着 Agent 看而不是解决实际问题的无聊感；那些让你最初胜任这份工作的硬技能正在缓慢、悄无声息地退化。你不再在脑中维护架构，因为 Agent 已经处理了；你不再思考边界情况，因为测试都通过了；你不再想深入钻研，因为 prompt 一下就能批准。你的内心不再有火花。