今天标志着我的代码行数达到了100万。

公平地说，大约30万行代码是”硬核”代码，但这仍然是我在Google 3.5年（大约15万行代码）写的两倍。

我想列出一些有趣的事实：

  • 我 删除/拒绝 的AI代码比我接受的要多。
  • 我花在 思考 上的时间比写代码多。
  • 我像其他vibe coder一样喜欢emoji，但当它变得混乱时就不那么喜欢了。
  • 大多数代码是Python和Dart，出于对flutter的热爱。
  • 这实际上比旧时代的编码 更紧张。
  • 一半的代码是使用Claude Sonnet 3.5写的，但最近我发现自己 更喜欢Gemini 2.5（见 这篇文章），甚至超过Claude 4 & Claude Code。我仍然更喜欢Cursor而不是Gemini CLI，但我可以看到通向完全代理编码的趋势，这可能是Codex / Claude Code / Gemini CLI的一种形式。
  • AI 最擅长前端、数据库操作、样板代码，这可能会让你提升10倍。
  • 谨慎 对待代码结构，避免过度设计，快速失败以避免静默失败，并 避免代码重复。
  • 在 > 10(20) 轮对话后开始一个新的会话。在 > 1000 行代码后重构。不要写长的util / helper文件。
  • 清晰表达 (Articulation) 是编排AI的最重要技能。

Vibe Coding 的争论

有些人仍然对 “vibe coding” 持怀疑态度，我想分享一些想法。

首先，vibe coding 是容易还是难？

老实说，这实际上 比没有AI写代码更紧张。你没有时间”休息”，通常写样板代码是你放松大脑的时候。你需要立即跳到下一个任务，因为AI会在几秒钟内完成事情。这会让你觉得你在比赛，你需要跟上节奏，因为很明显你是瓶颈。此外，你需要解决连AI都无法解决的问题（这现在变成了一种赞美）。

其次，AI到底擅长什么？

关于vibe coding的争论有时是关于他们所做的工作，人们在谈论vibe coding时并不一定在谈论同一件事。那么AI到底擅长什么？

  • 前端：10倍。 无论是typescript还是javascript，或者flutter，AI可以在几秒钟内做你想做的任何事。
  • 数据库：10倍。 大多数时候，你只需要花时间思考schema（或与AI头脑风暴），AI会做剩下的。
  • 样板代码：10倍。 每当你需要阅读一些工程文档时，让AI实现或帮助你阅读文档总是更好的。
  • 后端：1.3倍 - 2倍。 2倍是对我而言，有些人可能会说更低。这部分实际上是差异很大的地方。一些基础工作可能会发现AI根本没有帮助，但这实际上很少见。人们惊讶地发现AI可以相当好地写Mojo（Modular AI的高性能语言）甚至Lean4（形式证明语言）代码，这两者都是最先进且相对较新的。

那么AI实际上 不擅长 什么？

这实际上不是一个好问题，因为它毕竟是一个工具（目前），用户需要意识到工具的局限性，而不是抱怨工具不是全知的。所以这实际上是一个”谨慎”列表。

  • 过度设计 对我来说是最令人沮丧的问题。我通常只是 强行停止 生成并重写我的提示。即使是用不同的方式说”不要过度设计”或”不要过度思考”，AI有时仍然会生成大量冗余代码。对此要格外小心。简单是终极的复杂。
  • 错误处理。AI倾向于隐藏错误以避免异常、崩溃等。这是”静默失败”的大问题，这是最糟糕的失败，因为你甚至不知道它正在发生。这基本上是 “快速失败”工程原则，以引起对关键失败的注意。我也讨厌AI将导入包装在try-catch块中，这没有意义（虽然我知道这背后的真正原因，这是一个很长的故事）。
  • 没有足够的上下文 和 重新发明轮子，通过重新创建一个新的辅助函数/文件。这经常发生在我身上，仅仅是因为AI并不总是意识到上下文。
  • 避免长文件（软限制500，硬限制1000）。理想情况下少于500行。当 > 1000行时，通常是重构的好主意。上下文长度仍然不是一个已解决的问题，并且可能会继续是一个问题。
  • 避免长的util / helper文件。将它们拆分成更小的文件通常是个好主意。实际上，首先避免util文件，只给函数和文件起直观的名字。
  • 经常重构，就像你在旧时代做的那样。有了AI，重构变得更快更容易，你可以直接把错误信息粘贴给AI，它就会搞定。
  • 少即是多。这就是Andrew Ng所说的 懒惰提示 (Lazy Prompting) (链接)。
  • 有一些非常明显的bug我可以发现，比如字符串不匹配，AI竟然搞不定。当我指出时，AI会说”你一针见血”，然后修复它。我仍然不知道为什么会发生这种情况，但这确实经常发生。

上下文工程 (Context Engineering)

术语 “vibe coding” 很有名也很流行，但这可能不是一个好术语，因为它掩盖了开发者面临的智力挑战。然而，Andrew Karpathy提出的 “上下文工程” 实际上是一个很好的术语，捕捉了构建AI代理问题的本质，并完美地取代了术语 “提示工程 (prompt engineering)”，后者误导性地暗示围绕ChatGPT的”包装器”。

关键思想是LLM有能力做很多事情，但它主要是 无状态的，我们需要让它 有状态，这可以重新表述为挑战在于 记忆工程。到目前为止，记忆工程最有效的方式仍然是通过 纯文本，区别在于这些纯文本是如何生成和组织的。对于编码，尽管有Claude, Devin和Cursor的努力，它仍然是关于代码库理解的前沿和开放问题。老实说，我发现我的手动蓝图（AI的README）仍然是让AI快速获取代码库结构的最佳方式，但这是一项相当战术性的工作，基于我1000小时的vibe coding，并且需要一些试错迭代。

总的来说，上下文工程是设计代理最重要的部分，并将”刚好足够”的上下文放入LLM以做正确的事情。

你需要理解生成的代码吗？

一个需要深思的关键问题：你需要完全理解AI生成的代码吗？

我个人的哲学：

  • 高层： 绝对需要。你必须理解整体设计、流程、架构和数据结构 —— 否则你就是在盲飞。
  • 低层： 放手大部分。你不需要微读每个辅助函数，除非它是 核心算法、代理循环 或 关键性能路径 的一部分。这些部分需要深刻理解。

对我来说，真正的艺术是知道 何时放手，在 深入 和 信任AI 之间做出选择。

我喜欢讨论架构和数据结构设计几个小时 —— 那是大部分思考应该发生的地方。一旦结构清晰，实际实现通常花费的时间要少得多。

所以，我的日常工作流程通常是：

  1. 设计 —— 与ChatGPT / Gemini讨论想法，无论你需要多久。
  2. 代码架构 —— 与Gemini / Claude讨论架构，10-15分钟。
  3. 实现 —— 让AI写代码，通常很快，大概30秒到2分钟。除非有一些意想不到的代码（我通常归咎于我的糟糕指令）。
  4. 调试 —— 尝试先将错误跟踪粘贴到AI中，如果是硬bug，打开网页并与Gemini 2.5一起调试。
  5. 回到1并迭代。

我还能写代码吗（没有AI）？

我曾经担心：在如此严重依赖AI生成代码后，也许我再也无法独立写代码了。

我错了。

我仍然可以写出好代码，质量好且性能好。

证明是，我正在上Stanford cs336，从头构建LLM，这是一门极其密集的编码课程，建议不要使用AI。我在做作业方面做得相当好。

一些我觉得有用的提示（Cursor中的规则）

  • “不要过度设计。倾向于简单的逻辑和通用的行业解决方案。”
  • “帮我头脑风暴，不要写代码”
  • “做最小必要的更改。”
  • “使用最少的注释并避免冗余。”
  • 再次强调，“不要过度设计。”