作为工程的 AI Coding

Andrej Karpathy: From Vibe Coding to Agentic Engineering w/ Stephanie Zhan - YouTube Stop Prompting Claude. Use Karpathy’s Method Instead. - YouTube

其实从分析 Karpathy 的使用方法中，我们就能看出来，在 AI 使用中的关键因素仍然是明晰自身的需求。你看它的第一层就说的很明确嘛，对吧？AI 本身，它并不是一个人，它没办法说很好的去理解你的需求，所以它上来第一层就是要求给明确的目标，以及围绕这个目标所构建的规格。在我看来，这个规格甚至不一定是需要你自己去写的，但重点是你需要全程地去 review，同时全程地参与其中，并去检视 AI 给出的这个规格到底有没有符合我想要的需求，有没有走向我想要的目标。这个规格如果不够明确的话，AI 实际上是没办法很好地去帮你实现你想要的那个东西。

而他给出的第二层则是这个规格实现的细节。比如说，好的提示词是什么？好的提示词是明确的、清晰的告诉他，让他做什么，而不是说，哎呀，你帮我把这个变得更好。可什么叫做好？AI 事实上没办法理解你想要的好到底是什么样的好。因此，把自己的需求明确且清晰地传达给 AI，才是让它实现我想要那个效果的最好办法。

换言之，就这两项而言，最顶尖企业中的 AI 负责人的使用方法和我日常中探索出来的使用方法是大体上一致的。但我不是给自己贴金的，而是因为这至少证明了我对 AI 的理解和使用是走在正确方向的。因为主要是这也是我自己的痛点，我总是发现说，你给我变得更好一点，你给我往那个方向上去走。然后我的需求越是模糊，我越是难以清晰地阐述我的个人需要，它对我的实现就越是让我红温，越是让我绷不住。而我说的越清晰，我说的方向越明确，越是条理，用分门别类的方式列出来，它就实现得越好。

这里显然不只是模型本身有多强，另一方面还是在于，你看人与人之间的理解都很难，更别说 AI 了，它就算再强，它也不可能知道，对于我个人来讲，我心中那个对好的定义到底是什么。它可能会按照它统计模型里面最大的那个去实现，但是那根本可能不是我想要的效果。

就像那个经典的洗车提示词一样，就算是 Opus 4.7，你问他我要走还是开车去，他会回答我说要走过去，因为距离太近了。我觉得这本质上来讲是 AI 并没有真正意义上的洞察到，或者说推断出我没有告诉他的潜在情景：我要去洗车，但我的车并没有预先的停在洗车处。他会默认我已经把车送过去了，总之他不认为我应该在这么近的距离之下，还开车过去并不是良好建议。其实当用户说到我要开车去还是走过去的时候，就已经暗示了车并没有停在停车场，但是显然这种模糊的潜台词，没办法触发它的推理。但我能说模型本身很笨，或者说不聪明吗？那倒不至于，比这逻辑上复杂不知道多少倍的嵌套代码，它都能捋清楚——显然这里的问题在于模糊和不清晰的表述，让Agent 没办法顺利地推断出我真正意义上的已有情况，自然没办法正确的根据我的已有情况，安排我后续要做的事情。

但是，这种对潜台词和潜在情况的推断会随着模型的越来越进步而得到完善。像现在 的4.8，他虽然一开始还是会给你说，你最好走路过去，但是也在回答中给出了很明确的条件限定：就是如果你要洗的是你的车，那么就不能把车留在家里，肯定得开车去，因为车就是要洗的对象；但如果只是想去问问价格，或者说是单纯的咨询一下，那么最好是走路过去，因为这个距离没必要开车。所以最新的模型给出的效果的确是最好的。虽然他首先抛出的答案是让我走路过去，但显然是假定了我要问的是第二种情况，同时也说的很明确了，如果我的车没有开过去，为了洗车，还是开车去最好。新的模型更加清楚自己回答的边界条件，而不像旧模型一样，就直接给一个结果，没有说什么情况之下应该怎样。

最后一层则是一个有效的工作空间，能够让 Agent 发挥最大效果的上下文环境，比如说像是标准的 MD 文件、足够的参考资料、项目的背景、过去的过程，这些都是在上下文意义上对它的相关约束。其实某种意义上也是 Harness 要试图去实现的约束，只是这里的话是指上下文的约束，特指的是工作环境——再好的 Harness，你没有给它一个良好的工作环境，它也做不好事情。

这里还特别提到了知识库，但是在我看来知识库最本质上来讲也是一个上下文环境中的一份，只是一个良好的知识库会让查找也好、管理也好，都进行得更加便利。但是以最轻量化的角度来讲，标准的 MD 层级知识库就已经够用了，除非整个项目的规模真的非常大，以及相关的知识真的非常散建在各种巨量的文件之内，那这种情况下可能真的需要专门的知识库管理工具。

像是专门的和我们自身工作有关的 Skills，而不是一直去用一些通用的 Skills，因为这个东西本质上就是一个通用的工作流，没办法用在自己的工作流上嘛。我的这里是非常独特的一些小细节、操作、团队风格，通用的肯定不能做到最好，那需要的就是我自己去构建一个对我来讲最有效的 Skills，对吧。因此有自己的克制化的 Skills 是非常重要的，而且构建这个本身也没有特别难，对吧？我先把，如果我把我过去的工作流程都已经落实成一个文档了，那我就可以让它基于我过去的工作流程，帮我直接出一个 Skills 出来，这就是为什么记录中间过程是非常重要的。一旦这些中间过程最终形成了上下文的环境，它就可以把隐性知识显性化，最终再把这些显性化的隐性知识总整理成可以通用使用的 Skills。记录下自己的使用过程是很重要的，能提高 AI 效能的好办法。

以及最后一个，明确 AI 的边界，哪些东西是能做的，哪些东西是不能做的，必须非常清晰地告诉他，这可以是一个清单，就是我可以在使用过程中慢慢的发现，哎呀它这里不行，那里不行，我去给它一点点去增补，这其实仍然是上下文管理中的一部分，只是这里特别指的是 Rules，一个独特的上下文文档，当然，如果量没有那么多的话，把它写进 Agents.MD 里面也没啥不行，但最重要的是得有这么一个明确的边界限制。

但是如果是那些最硬的约束，比如说我就不允许你读某个文档，任何情况下都不允许，我就不允许你用某些命令，任何情况下都不允许。那这个时候就得用 Hooks 了，你得用一个钩子直接把它强制拦截，而不是要去信任 AI 的自己的操作。因为有些情况之下，哪怕你说了不要去做某个事，它还是会去做，不要去看某个文档，里面有敏感文件，它还是会去看，不要去删，它还是会去删。甚至反而可能因为你说了这些，让这个进入到了它的上下文里，它搞不好还比平常更容易去做这些事情。

所以说最好的办法就是用一个强制性的程序化的钩子直接拦截，让它根本就不可能执行，这本身意义上来讲是权限管理的一部分。比起信任 AI 觉得它有了我说的约束之后，就不会去做，不如直接用硬性的权限管理让它做不了，这是更加安全的做法。Karpathy 有一句话是说的最深刻：You can outstore your thinking, but you can’t outstore your understanding.

而这也恰恰是我自己的理念，那就是有些东西是绝对不能够外包的。一旦我自己的理解和我自己的思考（尽管字面意义上来讲，他这里把 thinking 也纳入在内，但是我个人把这个更多理解为是一种程序化的过程，不能代表我对方向性的思考，更像是对具体的实现的思考）也被外包出去，那么最终会退化并被取代的人就会是我——核心点始终是人在与 AI 交互的过程中，或者说人机交互过程中，确保人的首要性地位。

借助工具来提升自己的能力，向来是我们人类的人类相较于其他动物的优势所在，所以说没有必要去拒绝工具。但是确保工具是为我所用，而不是反过来，在我看来是使用工具过程中最重要的东西。尽管人和工具本身是会相互影响的，我怎样去使用工具并让工具适合我，同时反过来工具也在影响我。AI 时代需要有 AI 时代的新的人才培育体系和思考模式，但它永远不会取代思考和理解本身。你必须要明确地清楚并理解自己的目标，才能够让 AI 来更好地服务于自己；你必须清楚地并理解 AI 到底在做什么，才能够保证自己系统的稳健性。一名优秀的工程师必须要知道自己的边界，这样才能构建出优秀的系统。天下当然没有绝对稳健的系统，但是却能够做到搭建一个边界足够清晰的系统，这就够了。

而以上内容恰恰是 Agentic engineering 相较于 Vibe Coding 之所以被称之为 engineering 的原因，他要做的就是一个工程意义上的优化，也因此才被称之为工程。经典的 Vibe Coding 就只是许愿机我只要把东西给它，期待它能够自动产出一个足够优秀的结果。但是如今并不能这样去做，而你想构建一个生产环境下良好运行的系统，仅仅靠 Vibe Coding 是不够的，我就需要用各种各样的工程手段去保证 AI 能够很顺畅地去运作，从而逐渐去实现我的需求。

因此我们可以很自然地说，如今的 Agentic 工程师，他们就是在做一个工程，而不是说像一些人嘲讽的那样，哎呀，你只朝 AI 许愿。真正用过 AI 的人都能够理解到说，仅仅停留在 Vibe Coding 这个级别，你是构建不出一个很好的生产级系统的。一些大厂的顶尖公司里面的人真正在用的，实际上是逐渐转向的就是在 一个 Engineering 的框架下去进行一个又一个的工程优化。