AI 时代，我们需要怎样的编程能力

裘渝琛 · · 约 17 分钟

目录

AI 改变了编程的范式，极大地降低了编程的门槛，尤其是在 2025 年 12 月 agent 能力提升之后，底层模型编码能力的提升，加上拆分执行任务的能力，普通人很多时候可以仅仅通过一两次对话得到自己定制的软件功能。但是作为一个有一点编程基础的普通人，最近 vibe coding 的经验让我感觉，如果要处理有一定体量的项目，至少到目前为止，一定的编程能力可能仍然是需要的，只不过我们可能需要对编程能力重新定义。

搜索资料的过程中 Claude 的这篇报告How AI assistance impacts the formation of coding skills 证实了一个我一直以来隐隐约约的感受，也就是使用 AI 的方式也许决定了未来我们是否还能"掌握"技能。vibe coding 的畅快感是一种无法抵御的诱惑，AI 可以让一个对编程一无所知的人在几分钟之内就产出一个原本可能需要几个月甚至几年学习时间和几天的编程时间才能完成的功能，但在这个过程中往往为了追求更快的速度和效率，我们将越来越多原本对形成技能必要的认知过程让渡给 AI。人本身对自我学习效果的评估就充满偏差（认知科学中称为 fluency illusion），真正学习的效果的自我感知往往是反直觉的，AI 的出现则进一步加剧了这个幻觉。而认知科学中反复验证的规律则是：学得越轻松往往学得越快，忘得也越快，学得感觉有点难，才有可能真正学会（即 Bjork 提出的 desirable difficulties），这恰恰也是报告中提到的点，在编程中"不恰当"使用 AI 导致掌握程度出现显著的下降，相反，仅仅用 AI 生成概念理解，而仍然手工编写代码可以保证较高的掌握程度，尽管这样的速度可能更慢。假设我们用技能的成熟度和使用 AI 的方式分成四类人，可以预见的是如果我们不在效率洪流中主动选择在发展技能过程中使用 AI 的方式，大多数人就会滑向技能退化和虚假的繁荣，无法成功发展出熟练的技能。

辅助理解全局代劳
技能成熟度：初阶加快理解技能退化
技能成熟度：高阶继续精通能力放大/手感退化

“People who go all in on AI agents now are guaranteeing their obsolescence. If you outsource all your thinking to computers, you stop upskilling, learning, and becoming more competent.” – Jeremy Howard, creator of fast.ai

人类对"轻松"有天然的渴求，而 AI 就像一颗蜜糖，好吃，但是也暗藏代价。

以下是相对技术的观察和思考，作为一个业余爱好者尽可能贴近实际的叙述，补上 vibe coding 过程中欠下的认知债务：

认识 Agent 的工作方式（怪癖与边界） #

  • Agent 写代码的速度很快，执行力也很强，但无法自行选择"正确"方向，或者说不知道什么时候应该停下。如果在长程任务中没有合适的监管，就会在错误的路上一路狂奔。当我问它当前代码有什么改进方向的时候，它总能提出一些改进方向，而很多方向其实是over engineering ，完全没有必要，而如果对它提出了当前代码有什么问题，它也总是能提出一个解决方案而不会思考我提出的问题本身是不是正确。因此比起让 Agent 做更多，更重要的其实是知道什么不需要 Agent 修改，或者说什么时候应该喊停。人编程的速度有极限，所以我们会深思熟虑每一行代码，但 Agent 可以持续流畅地生成，所以避免错误就是在节省时间。

  • Agent 一定会犯错，并且以一种无法预测或者说我们的直觉还不够熟悉的方式犯错。在 vibe coding 的过程中，Agent 初期连续达成目标会极大地增加我们对其的信心，从而在之后的编程过程中给予更大的权限和更多的任务。但是如果我们没有识别错误的能力，我们最后就会获得一堆有着奇怪错误的无法维护的代码。而且 Agent 还可能会作弊，直接修改设置好的测试，因此并不能让 Agent 无监管地持续运行。

    Kent’s mental model of AI agents: an “unpredictable genie” that grants your “wishes” — but oftentimes in unexpected (and illogical) ways!

  • Agent 对于计划的执行并不可靠，可能自己制定了 3 步的计划，但是因为没有明确计划要实现的目标和修改，所以最后实际的结果可能与计划并不符合，甚至忘记了计划中的一些点。指令的遵守并不是 100%，最后实际的修改才是真正的标准。

  • Agent 的上下文是有限的 ，随着上下文中的内容增加表现会明显下降，而上下文填充的速度和衰减的速度往往比我们想象中快。如果一个对话里什么都往里塞 就很容易影响模型的表现，尽可能在上下文中仅仅维持与当前任务有关的内容，问自己要完成这个任务需要知道哪些必要信息。失败的纠正，错误的执行信息都会污染模型的上下文。

设计与 Agent 协作的工作流程 #

  • 为避免执行错误的修改，尤其是改动涉及到多个文件，我们需要强制将探索，计划和执行分开 ，而我并没有明确区分，所以也就没法让 Agent 以我预期的方式进行工作。一旦分开，我们就有机会在前期就改正一些明显的错误，修改一些与我们预期不符的计划，甚至让 Agent 快速做一些模拟，而不用等到实际修改以后再返工。在实际执行过程中，我们也要对我们的意图非常明确，任务范围是什么，场景是什么，测试偏好，有什么可以参考的模式等等，做到具体和明确的前提就是我们需要对我们编写的程序有深入的理解。
  • 当目标明确并且可以验证时，Agent 才能发挥最大的作用。因此不仅仅要告诉 Agent 要做什么，还要明确验收标准 。把 bug 的详细报错提供给 Agent 就是最原始的构建反馈回路的方式 。可以进一步探索Test-Driven Development 。在像编程这类相对容易验证的领域，Agent 就可以如鱼得水，而对于很多没有明确标准和反馈的领域，比如写作，我们很难定义一篇好文章的标准是什么，Agent 的发展就相对缓慢。
  • 通过 Git 设定检查点，理解变化的内容，做多轮尝试。实际编程的过程就是在前进和后退两端循环 。即使没空人工审核，也要让不同的 AI 互相审核，避免同一个 AI 对自己写的代码袒护。
  • Agent 通常会有一个包含规则的文件（e.g. CLAUDE.md, AGENTS.md），我们需要通过编写规则和提示来约束 Agent 的行为，让它按照我们期望的方式行事。每当我们发现 Agent 持续犯了同样的错误，就应该花时间设计规则防止类似的情况再次发生 ，但这个前提仍然是我们有判断力，知道什么是正确的行为，什么样的代码是我们想要的。

人不可让渡的角色 #

  • 用 Agent 来辅助理解代码 是为数不多正面收益很大而且基本没有风险的用途，可以用 Agent 来探索一个全新的代码库，也可以让 Agent 为代码填写文档 。
  • 可能我们不用再记住功能的函数名和参数，但是要真正利用好 coding agent，那些写出高质量项目的能力 仍然重要，决定架构，写 spec，定义测试，设计功能等等。AI 可以放大已有的专长，而这些专长又可能因为过度使用 AI 而无法成功发展，这是当下难解的悖论 。
  • The bottom line: Don’t ship code you don’t understand.

学习心态 #

  • 虽然 vibe coding 的结果并没有预先设想的那样轻松，但是在不断与模型交互的过程当中，我们也在培养对 Agent 能力和"怪癖"的直觉。任何有意义的采用新工具的过程一定会经历一段效率降低的过程，就像我学习双拼最开始的几个月我的打字速度比使用全拼下降很多，但是我们需要不断练习直至新技能足够熟练，我们才能最终收获新技能给我们带来的能力边界的扩展。“一件事情变好之前通常会变坏”，也许这句话很好地总结了我们学习新技能的过程。
  • AI 是当下最热门的领域之一，但其实大部分都是 hype，在思考以上这些问题的时候，Anthropic 和 OpenAI 的官网本身就提供了足够多优质的信息和指南，除此之外，关注真正在用编程解决问题的人，而不是以传播信息为生的人。真正有价值的信号是当下最稀缺的资源。

回到开头那个问题：如果编程的定义正在改变，那么我们要主动保留的是什么？我倾向于这样回答——保留与代码之间真正的接触。不是抗拒 AI，而是在效率最诱人的时刻保留一点不舒服：在 Agent 生成完之后多花十分钟读一遍，在它给出方案前先自己画一遍架构，在直觉觉得"对"的时候多问一句"为什么"。这些看似低效的动作，是把"用 AI 写出来的代码"变成"我写的代码"的唯一路径。技术工具更迭总是比我们适应的速度更快，但"对自己产出的东西负责"这件事，从来没变过。

参考资料 #

Anthropic

Mitchell Hashimoto

The Pragmatic Engineer / Kent Beck

关于技能退化与 AI 的批判性视角

外部研究（AI 对认知的影响）

认知科学相关概念

  • Desirable difficulties（合意难度）：Bjork & Bjork 提出，学习时主观感觉"费力"的条件往往带来更好的长期记忆与迁移。

  • Fluency illusion（流畅性错觉）：Koriat & Bjork (2005)，材料读起来流畅时，人会高估自己的掌握度。

最后一次修改于

↑ Back to top