← 返回全部文章

AI Coding时代，软件开发者如何自我进步？

[ Thinking ]
[ AI ]
Switch to English

“计算机语言不只是让计算机执行操作的方式，而是表达方法论思想的形式媒介”

—— Structure and Interpretation of Computer Programs

我们希望 AI 能加快生产力，解放我们的双手。但另一方面，AI/LLM 在现阶段仍无法可靠完成所有编码需求。

例如 Defects4C 研究用真实 C/C++ bug 和漏洞评估 24 个主流 LLM 的自动修复能力，结论是当前 LLM-based APR 方法仍有明显局限。1

你依然可以看到AI在对编译器，Runtime internals，OS Kernel，驱动开发，嵌入式，数据库/存储系统表现得有多糟糕。

Live-kBench（2026年2月）的评估显示在使用mini-SWE-agent的情况下，采用Claude Opus 4.5时内核崩溃解决率达到了74.16%，但等效补丁率仅为19.85%。

从长期来看，我们对 AI 的依赖可能会消磨编码能力，最终削弱对 codebase 的审查能力、调试能力，以及从零启动整个项目的能力。

有人建议所有 programmer 都应该转为 product manager，也有人说未来不会再有“程序员”这个工种。

如果 AI 最终能处理全部代码，那么现在提升编码能力是否是一种自娱自乐？

这是一个合理的担忧。

那些验证成本低、反馈环路快、错误后果可低成本修正的编码技能，比如样板代码、CRUD、有完善测试覆盖的应用层逻辑，市场价值会持续下降，甚至可能趋近于零。

而验证成本高、反馈环路慢、错误后果不可逆或代价巨大的编码技能，比如系统级、安全关键、无法用单元测试穷举验证的架构决策，市场价值不会因为 AI 生成能力提升而同比例下降。相反，它可能因为“谁来为 AI 生成的高风险代码负最终责任”这个问题永远需要人类，而保持甚至提高单位价值。

LLM 对编码能力的负面效果研究

Anthropic 的 RCT 研究让 52 名初级工程师学习 Trio，一个 Python 异步库，并把参与者分为 AI 辅助组和手写组。2

工程师需要完成多个编码任务，随后接受测试。AI 组测验平均分比手写组低 17%，AI 让任务完成速度略快，但没有达到统计显著。2

差距最大的地方是调试题，也就是识别代码为什么错、错在哪的能力。2 高分组的共同点是主动问概念性问题、用 AI 验证自己的理解，而不是直接要答案；低分组要么全盘外包，要么把 AI 当调试拐杖。

下面括号中的数字是对应互动模式的测试通过率。

低分互动组：

  • AI Delegation（39%）：该组参与者完全依赖 AI 编写代码并完成任务。
  • Progressive AI Reliance（24%）：该组参与者一开始会提出一两个问题，但最终将所有代码编写都委托给 AI 助手。
  • Iterative AI Debugging（24%）：该组参与者依赖 AI 来调试或验证自己的代码。他们提出了更多问题，但依赖 AI 助手来解决问题。

高分互动组：

  • Generation-then-Comprehension（86%）：该组参与者首先生成代码，然后手动将代码复制或粘贴到自己的工作中。代码生成后，他们会向 AI 助手提出后续问题，以加深理解。
  • 代码—解释混合型（68%）：该组参与者会提出混合型问题，即同时要求生成代码并解释所生成的代码。阅读和理解他们要求提供的解释花费了更多时间，但有助于他们的理解。
  • 概念探究型（65%）：该组参与者只提出概念性问题，并依靠自己提升后的理解来完成任务。尽管该组遇到了许多错误，但他们也独立解决了这些错误。2

Anthropic 另一项观察性研究基于 Claude.ai 真实会话估计任务耗时，认为 AI 对部分任务可带来约 80% 的时间节省；但研究也明确承认，它无法计算用户在对话之外继续验证、修改、整合输出所花的时间。3 因此，它测到的是“已经会做相关任务的人，在真实使用中可能节省多少时间”，不是“初学者是否能借 AI 更好地学习新技能”。

METR 在 2025 年针对资深开源开发者做过一项 RCT：16 名开发者在自己熟悉的成熟开源项目中完成 246 个真实任务；允许使用 AI 工具时，开发者完成任务反而慢了 19%。4

更离谱的是感知偏差：任务前他们预测 AI 会让自己快 24%；做完之后，哪怕实际更慢，仍然认为 AI 让自己快了约 20%。4 这说明“我感觉 AI 帮了我”这个自我报告本身就不可靠，也削弱了某些高幅度提速数据的说服力。

不过，这条 METR 结果必须带限定条件使用：METR 在 2026 年更新中说明，早 2025 结果是历史快照；随着工具和使用习惯变化，新实验受选择偏差影响，已经很难用原设计估计当前 AI 工具的真实提速幅度。5

Peng 等人的对照实验发现，使用 GitHub Copilot 完成 JavaScript HTTP server 任务的开发者比对照组快 55.8%，且低经验开发者受益更大。6 这和 METR 的结论表面冲突。 差异大概率来自任务类型和开发者经验水平：小型自包含任务、清晰规格、低上下文负担，更容易被 Copilot 加速；真实百万行代码库里的维护任务，则要求大量上下文、审查和集成判断。

2024 年 Maribor 大学针对 32 名学习 React 的本科生做过 10 周实验，发现用 LLM 做代码生成和调试与期末成绩显著负相关，而用 LLM 做解释类用途没有显著负面影响。7 这个模式和 Anthropic 的结果几乎一致：两个独立团队、不同语言/框架，观察到同一个方向。

因此，“用 AI 求解释 = 相对安全；用 AI 求答案 = 侵蚀技能”这个框架不是事后凑出来的解释，而是能在不同研究场景中重复出现的模式。

一些群体对AI辅助编程的看法

Programming is understanding. If you don’t understand what you are doing, you are not programming. You are generating text.

Godot Foundation 在 2026 年 6 月说，AI-generated contributions 让 PR 变多，因为提交成本下降，但 review 工作和 reviewer 数量没有同步下降，并禁止完全由AI辅助的代码。

Linus 式观点不是“AI 不会改变编程”，而是“AI 会改变编程的操作层，但不改变编程的责任结构”。

Stack Overflow 2025 调查显示，84% 的受访者正在使用或计划使用 AI 工具，但 46% 的开发者不信任 AI 输出准确性，高于信任者比例；66% 的开发者最大挫败感是 AI 方案“几乎对，但不完全对”

Redis 作者 antirez 把 AI 辅助写软件称为 “Automatic Programming”，并说它在合适场景、合适人手里能大幅加速开发。

Drew DeVault在《AI crap》里说，机器学习泡沫会留下来，但世界大概率会变得更差；他认为 Copilot 会被平庸程序员用来写 trivial code 和 boilerplate

SQLite 在 2026 年的 AGENTS.md commit 中把 “SQLite does not currently accept agentic code” 强化为 “SQLite does not accept agentic code”。

Thorsten Ball 在 2024 年文章《They all use it》中说，他理解有人认为 AI 过度炒作、不能推理、会生成垃圾，但不理解程序员对被称为会改变编程未来的技术毫无好奇。

未来是否还需要编码能力

先挑战这个论证结构本身，再回答实质问题。

这个论证有个自我吞噬的漏洞。[INFERRED, HIGH]

如果 AI 最终能处理全部代码，那么现在提升编码能力是自娱自乐。

这个逻辑如果成立，可以套用到几乎任何技能：如果 AI 最终能写全部小说，写作训练是自娱自乐；如果 AI 最终能做全部诊断，学医是自娱自乐；如果 AI 最终能做决策，学管理是自娱自乐。

这是个证明过头的论证，proves too much。问题不在于它的结论一定错，而在于它没有指出编程有什么特殊性，让它比其他领域更应该被这套逻辑击穿。我们需要问的不是“AI 最终会不会取代编程”，而是“编程这项技能相对其他技能，自动化后剩余价值会不会归零”。

前提本身的置信度有多高？

“AI 最终有能力处理全部代码，无论底层 OS 还是应用层”——这是一个未解决的预测。

[GUESS/INFERRED, LOW-MED] reward signal 结构和硬件依赖的反馈环路，可能是系统级代码自动化的天然摩擦点。RL 训练需要可验证、密集、快速的反馈信号。应用层 CRUD 代码如果有测试、有明确规格，比较符合这个条件；但底层系统代码的正确性反馈往往需要跑真实硬件、观察时序、复现竞态条件。这个反馈环路目前无法像编译错误那样在毫秒级给出。

[INFERRED, MED] 这意味着“全部代码”被自动化的时间线，在不同层次上大概率不是同步的，而是从“反馈信号密集且快”的领域，比如前端、脚本、glue code，向“反馈信号稀疏且慢”的领域，比如内核、驱动、编译器后端、分布式系统一致性，逐步推进。后者的自动化时间线目前没有可靠估计。

核心问题：即使 AI 能生成，谁来验证？

这是比“AI 能不能写”更根本的问题。[INFERRED, MED-HIGH] 验证一段代码是否正确、安全、可维护，理论上不必然比生成它更容易，尤其是在没有形式化规格、需要理解系统涌现行为的场景下，例如并发 bug、内存安全、供应链攻击面。

如果人类完全丧失了独立验证能力，那意味着人类对 AI 生成代码的“信任”本质上变成了对 AI 这个黑箱本身的信仰，而不是对具体代码的检验。这或许在安全关键系统里是不可接受的风险敞口。

（但也有可能，我们人类从不需要reliable的代码。）

所以哪怕 AI 能写 99% 的代码，“能读懂并挑出错误”这项技能的边际价值也不会随生成能力提升而线性下降。它反而可能因为生成量暴增、审查压力集中到少数人身上而单位价值上升。

这也是 Anthropic 研究里调试分数差距最大的原因之一：调试是最难被 AI 辅助“偷走”、却又最容易在缺乏刻意练习时退化的技能之一。2

“自娱自乐”这个框架本身值得拆解。

你把“技能提升”和“经济效用”划了等号，隐含前提是：一项技能只有在能转化为不可替代的生产力时才有意义。

这个前提本身是 [FRAME]。它把编程当成纯粹的生产工具，而不是也可以是认知能力、审美判断、agency 的组成部分。

类比：你现在学 C 写文本编辑器、学 Verilog，这些技能即便 AI 最终能写出更好的编辑器和更好的 RTL，你获得的“对系统如何工作有一手直觉”也不会因为“结果可以被 AI 复制”而失去价值。除非你认定“价值”只能来自“不可替代性”，而不能来自“理解本身”。

这是一种安慰，也指出此类问题里夹带了一个未被论证的价值论假设。

如果非要给一个可操作结论：

在自动化时间线不确定的前提下，理性策略不是问“要不要提升编码能力”，而是问“往哪个方向投入”。

把赌注押在自动化时间线最长、反馈环路最慢、验证价值最高的技能上：系统级理解、架构判断、调试底层 bug 的能力。不要把赌注押在自动化时间线最短的技能上：记忆 API 细节、写 CRUD 样板代码。

“编码有没有意义”取决于我们追求市场价值，还是我们对“编码”于自我的价值。

该怎么办

这些建议提供给所有有追求的programmer。

人类的学习过程与模型的训练过程本质是相同的。

都不断经历着同一个循环：

学习->反馈->成长

我们认为，编码能力的核心可拆分为以下 5 钟能力：

  • Writing from a blank file：在没有生成式建议推动的情况下，从空文件开始组织代码结构。
  • Debugging patience：读 stack trace、缩小假设范围、稳定复现 bug。
  • Code review judgment：识别微妙的正确性、安全性、可维护性和集成问题。
  • API and language fluency：记住常用 idiom、约束、失败模式和 tradeoff。
  • Architectural taste：因为 agents 可以生成局部看似合理、全局却混乱的代码。

1. 先自己写设计，再问 AI

开始写代码前，先自己写一小段技术计划：

目标：
输入：
输出：
核心数据结构：
主要函数：
可能的边界情况：
我不确定的地方：

然后把这段发给 AI，让它批评你的设计，不要让它直接开写。

我们可以这样问：

请审查这个设计。指出错误假设、遗漏的边界情况、复杂度问题和更简单的实现方式。不要直接写代码。

这样我们练的是 architectural thinking，而非 prompt engineering。

2. 核心逻辑自己先写 30 分钟

对每个功能，先给自己一个 AI-free 时间段，比如 30 分钟。

这段时间只做三件事：写伪代码、写接口、实现最核心路径。

卡住后再问 AI，问题要具体：

我现在卡在这里。这是我的代码。这是预期行为。这是实际行为。请先解释问题可能在哪里，再给修复方案。

3. 每次接受 AI 代码前，做“三问”

1. 这段代码每个函数的职责是什么？
2. 哪些输入会让它失败？
3. 有没有更简单的实现？

增强我们对Code review的能力

如果答不出来就不要合并。所有不理解的代码进入项目，都会变成未来的技术债

我们也可以问AI：

请像严格的 senior engineer 一样 review 这个 diff。重点看 correctness、edge cases、security、maintainability。不要只提风格问题。

4. 让 AI 反向考你

写完一个功能后，让 AI 根据你的代码出题：

请根据这段代码问我 10 个问题，测试我是否真的理解它。包括控制流、边界情况、复杂度、潜在 bug 和重构方向。不要给答案，等我回答后再评分。

5. 让 AI 解释“为什么”，不要只给“怎么做”

为什么这个方案比替代方案好？
这个方案的缺点是什么？
什么时候不该用这个方案？
有没有更底层的原理？

6. 每周做一个无 AI 小项目

每周至少做一个小任务完全不用 AI。任务可以很小：

写一个 CLI todo app
写一个 JSON parser 子集
写一个 debounce/throttle
写一个 LRU cache
写一个 mini router
写一个文件搜索工具
写一个 markdown-to-html toy converter

目的不是造轮子，而是保留“从空白文件启动”的能力。

一个最佳的AI工作流

Step 1：自己写需求和技术设计
Step 2：让 AI 批评设计
Step 3：自己写核心接口和主流程
Step 4：让 AI 帮你补测试和边界情况
Step 5：自己实现核心逻辑
Step 6：AI 帮你 debug，但先让它解释原因
Step 7：自己 review diff
Step 8：AI 做第二轮 code review
Step 9：你写总结：今天学到了什么，哪里还不稳

如何检验自己

问一下自己：

没有 AI，我能不能从零写出核心版本？
我能不能解释 AI 写的每一段代码？
我能不能发现 AI 代码里的 bug？
我能不能写测试证明它正确？
我能不能重构它而不破坏行为？
我能不能向别人讲清楚这个设计？

让 AI 写得越多，你就要读得越深。

让 AI 帮得越快，你就要复盘得越慢。

任何你不能解释的代码，都不算你真正拥有的代码。

“The purpose of computing is insight, not numbers.” — Richard W. Hamming

参考资料

Footnotes

  1. Jian Wang, Xiaofei Xie, Qiang Hu, Shangqing Liu, Jiongchi Yu, Jiaolong Kong, Yi Li, “Defects4C: Benchmarking Large Language Model Repair Capability with C/C++ Bugs,” arXiv:2510.11059, submitted 2025-10-13, revised 2025-12-02. DOI: https://doi.org/10.48550/arXiv.2510.11059. URL: https://arxiv.org/abs/2510.11059. 访问日期：2026-07-07。 ↩

  2. Judy Hanwen Shen and Alex Tamkin, “How AI Impacts Skill Formation,” Anthropic Research / arXiv:2601.20245, 2026-01-29. URL: https://www.anthropic.com/research/AI-assistance-coding-skills. 访问日期：2026-07-07。 ↩ ↩2 ↩3 ↩4 ↩5

  3. Anthropic, “Estimating AI Productivity Gains from Claude Conversations,” Anthropic Economic Research, 2025-11-25. URL: https://www.anthropic.com/research/estimating-productivity-gains. 访问日期：2026-07-07。 ↩

  4. Joel Becker, Nate Rush, Elizabeth Barnes, David Rein, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” METR / arXiv:2507.09089, 2025-07-10. DOI: https://doi.org/10.48550/arXiv.2507.09089. URL: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/. 访问日期：2026-07-07。 ↩ ↩2

  5. Joel Becker, Nate Rush, Tom Cunningham, David Rein, Khalid Mahamud, “We Are Changing Our Developer Productivity Experiment Design,” METR, 2026-02-24. URL: https://metr.org/blog/2026-02-24-uplift-update/. 访问日期：2026-07-07。 ↩

  6. Sida Peng, Eirini Kalliamvakou, Peter Cihon, Mert Demirer, “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot,” arXiv:2302.06590, 2023-02-13. DOI: https://doi.org/10.48550/arXiv.2302.06590. URL: https://arxiv.org/abs/2302.06590. 访问日期：2026-07-07。 ↩

  7. Gregor Jošt, Viktor Taneski, Sašo Karakatič, “The Impact of Large Language Models on Programming Education and Student Learning Outcomes,” Applied Sciences, 14(10), 4115, 2024. DOI: https://doi.org/10.3390/app14104115. URL: https://www.mdpi.com/2076-3417/14/10/4115. 访问日期：2026-07-07。 ↩