01｜不是让 AI 写代码，而是管理 Agent 的注意力

本篇是《从头重新学 AI 编程》系列第 1 篇。

我想先问你一个问题。

你现在用 AI 写代码的时候，你觉得自己在干嘛？

很多人的回答是，写 prompt。想一个好的指令，让 AI 把代码吐出来，然后看看对不对。

我以前也是这么想的。直到有一天我意识到一件事，让我整个工作方式都变了。

那天我在用 Claude Code 给一个项目加功能，聊了大概二十多轮。前面十轮还挺顺的，越到后面越不对劲，AI 开始重复之前说过的方案，偶尔还会把我已经否掉的思路又拿出来说一遍。

我当时第一反应是，这模型是不是变笨了。

后来我才搞明白，不是它变笨了，是它的上下文窗口已经塞满了。它的「短期记忆」就那么大一块地方，我前面塞了太多东西进去，到后面它已经顾不上我最新说的话了。

这件事给我的触动挺大的。

因为我突然意识到，我跟 AI 协作的时候，真正在管理的不是代码，不是 prompt，而是它的注意力。

你想想看，AI 写代码靠的是什么？是它当前能「看到」的东西。它读了哪些文件，它记得你说了什么，它有没有注意到你强调的那个约束，它知不知道这个改动会影响别处。

这些东西全在抢同一份注意力预算。你塞的东西越多，它能分给每一条信息的注意力就越少。

所以我现在理解 Vibe Coding 的方式很简单，你的工作不再是写代码，而是管理 Agent 脑子里装着什么、还能装多少、装的对不对、什么时候该清零。

说起来好像很抽象，但拆开来看其实就是四件事。

第一件，你得学会定义边界。

以前你自己写代码，逻辑全在你脑子里，你清楚什么该做什么不该做。但 AI 不知道。它不知道你项目里有什么约定，不知道你踩过什么坑，不知道哪些文件不该碰。你不说，它就自由发挥。

自由发挥的结果嘛。。。可能能用，但大概率不是你想要的。引入了你不想要的依赖、改了不该改的文件、用了你不习惯的代码风格。

所以现在你的第一件事不是让 AI 动手，而是告诉它什么能做、什么不能做。

第二件，别再一问一答了，让 Agent 先出计划。

很多人跟 AI 的互动模式还是搜索引擎那一套，问一句，答一句。但 Agent 不只是回答问题的，它可以帮你做事。前提是你给它足够的信息和权限，然后让它先出计划，你确认了再执行，执行完了汇报结果。

这个模式比一问一答靠谱太多了，因为计划阶段你就能拦住错误，不用等它写了一大堆才发现方向不对。

我自己的感受是，刚开始用这种方式会有点不习惯，你会觉得多了一步，有点慢。但跑通几次之后你会发现，省下来的是后面那些改来改去、回滚重来的时间。

第三件，别只看结果，要看 diff。

以前你看 AI 输出，看的是这段代码看起来对不对。但代码「看起来对」跟「真的能跑」是两回事。

现在你应该养成一个习惯，每次 Agent 改完代码，自己去看 diff。它到底改了哪些文件？每个文件改了什么？不要只看它给你的总结，AI 的总结有时候会省略关键改动，有时候会把有问题的改动说得很合理。

然后跑测试。AI 说「应该没问题」不算数，测试跑过了才算数。

再问一句风险，这个改动有没有可能影响别的地方。你不问，它大概率不会主动说。

第四件，一个任务一个会话。

这可能是最反直觉的一点。很多人习惯在一个对话窗口里从头聊到尾，需求、实现、调试、修改全在一个地方。

但会话越长，上下文就越膨胀。AI 的注意力被越来越多的历史对话稀释，输出质量会肉眼可见地下降。就像我开头说的那个经历，聊了二十多轮之后它已经开始忘事了。

正确的做法是，一个任务完成了就开新会话。需要交接的话，让 AI 总结当前状态，在新会话里继续。

这四件事说起来简单，但我想坦率的讲，一开始做的时候你会觉得别扭。

因为这跟大多数人的直觉是反着来的。你直觉上会想，我写一个好 prompt 就行了嘛，为什么还要管这么多。

但你用一段时间就会发现，prompt 写得再好，如果你不管 Agent 的注意力，它最后还是会走偏。好的 prompt 是必要条件，但不是充分条件。

回到这块，我给你看一个具体的例子，感受一下这四件事落地的时候长什么样。

假设你在做我们这个系列的贯穿案例，那个待办事项应用，你想加一个导出功能。

如果你直接跟 AI 说「帮我加一个导出按钮」，它会怎么做？

它不知道导出什么格式，不知道导出哪些数据，不知道按钮放哪，不知道文件名叫什么。所以它只能自己做决定。你可能得到一个导出 JSON 的按钮，放在页面右上角，文件名叫 export.json。能用，但完全不是你想的。

如果你换一种说法，

基于现有待办列表组件，增加 CSV 导出功能。 不改后端接口，不引入新依赖。 导出当前筛选后的数据，文件名包含日期。

这句话做了什么？说了做什么，CSV 导出。说了在哪做，基于现有待办列表组件。说了不做什么，不改后端、不引入新依赖。说了细节，导出当前筛选后的数据、文件名带日期。

AI 收到这个，能自由发挥的空间就很小了。你没有写一行代码，但你把 Agent 的注意力框在了正确的范围内。

这就是定义边界。

不过这里只是让你先感受一下换个说法带来的差异。关于怎么系统地写出好的需求描述，下一篇会专门讲。

顺着上面的再聊聊，很多人以为 Vibe Coding 就是写好 prompt 然后等 AI 输出，其实那只是整个流程的 20%。

剩下 80% 是三件事，审查、引导、修正。

审查很简单，每次 Agent 改完代码，不要只看它的总结。自己看 diff，自己跑测试。「解释得通」不等于「跑得通」，这句话我建议你贴在屏幕上。

引导是什么呢，是在 Agent 动手之前，先让它说清楚它打算怎么做。

我自己用得最多的一个 prompt 模板是这个，

我想做 X。在你动手之前，先告诉我， 1. 你打算怎么做，分几步，改哪些文件 2. 你需要我决定什么，选 A 还是 B 方案 3. 你看到了什么我没看到的问题或边界 case

让 Agent 先说计划再动手。计划错了你能立刻拦住，省下后面半小时乱改的时间。

引导还包括告诉 Agent 不要做什么。这些约束要说在前面，不要等它写完了才说「哦这个不该改」。

修正就更直接了。一旦你感觉方向错了，立刻打断。

新手最容易犯的错就是，看到 Agent 走偏了，但心里想着再让它试试看，说不定能拐回来。然后又过了 5 轮对话，代码越搞越乱，上下文越占越满。

正确的做法是，一旦觉得不对，马上喊停。用 git reset 回退，重新讲清楚再来。继续让一个走错方向的会话跑下去，只会浪费上下文、产生更多需要回滚的代码。

我知道这很难。因为人有沉没成本的心理，觉得已经聊了这么久了不想从头开始。但你越早学会喊停，效率提升越明显。

好，整篇聊下来，其实就一件事。

你以前写代码，管的是字符。现在你用 AI 写代码，管的是 Agent 的注意力。

你的角色从执行者变成了定义边界的人。你的习惯从看结果变成了看 diff、跑测试、问风险。你的策略从一个会话聊到底变成了按任务拆上下文。

这些转变不需要你学任何新工具，从下一次跟 AI 对话开始你就可以试。

给你一个小练习。

把你最近让 AI 做过的一件事，用下面的格式改写一遍，

原始需求（模糊版）， 帮我做 XXX 改写后（带边界版）， 基于 [现有模块/组件]，实现 [具体功能]。[约束条件]。[验收标准]。

不用写得很完美，重点是感受一下，当你把边界说清楚之后，AI 的输出会有多大的不同。

下一篇我们来系统讲这件事，怎么写出 Agent 真正能执行的 Spec。

作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～