跳到主要内容

AI Agent 使用心得

深度使用 AI Coding Agent 数月、完整开发 HippoBuddy 后的经验沉淀

前言​

过去几个月，借助 AI Coding Agent 从零到一完成了 HippoBuddy 的开发。在这个过程中踩了不少坑，也摸索出一套行之有效的工作方式。以下 17 条经验，涵盖了上下文管理、会话分工、规则防御、判断纠偏、工具风险意识五个维度，希望对同样在深度使用 Agent 的你有帮助。

一、上下文管理​

1. 上下文连贯纯净规则​

一个会话只做一个相关性任务。 不要把多个不相关的任务塞进同一个会话里。Agent 的上下文有限，混杂的任务会互相干扰，导致 reasoning 质量下降。

2. 注意上下文膨胀​

上下文太长之后，模型的思考和响应会变得僵化——思路打不开、容易陷入固定模式、反应也变慢。这是上下文膨胀带来的通病，不分 IDE 和模型。另外，每次工具调用都会把整个上下文一起发出去，上下文越大单次调用的 token 消耗就越大，几十轮下来成本差异可观。当感觉对话开始"转不动"了，就该果断开新会话了。

3. 善用会话分叉​

HippoBuddy 每条消息都支持"从此处分叉为新会话"——从这条消息截断，生成一个独立的新会话。之前的上下文不会浪费，模型也不用重新处理。探索不同方案时不用担心上下文丢失。

适合需要分支探索的场景：

  • AI 给了一个方案但拿不准——叉出去试另一条路，当前结果不丢
  • 上下文变重了但前面的关键讨论还想保留——截断到合适位置，轻装上阵
  • 想并行比较不同方向——从同一处反复分叉，对比结果

二、会话分工​

4. 总结进展，开新会话​

当一段工作告一段落时，让 LLM 帮你总结目前的进展和结果，然后把总结复制到新会话的开头作为背景。这样可以轻装上阵，同时保留关键上下文。

5. 一轮对话分工明确​

在一轮对话开始前，想清楚这一轮的目的是探索代码还是执行操作。探索和执行应该分开：

  • 探索阶段：允许 Agent 广泛阅读代码、提出方案
  • 执行阶段：聚焦实施，及时中断 Agent 的过度思考

这样一旦出现问题，回滚和理解 Agent 的意图都更清晰。

三、规则防御​

6. 用 Rules 规范模型行为​

不要指望模型天然就懂你的项目规范。通过 workspace-level 的 rule 文件，提前告诉模型：

  • 禁止做的事：不要引入新框架、不要修改配置文件、不要擅自升级依赖
  • 必须遵守的风格：命名规范、文件拆分原则、注释风格
  • 项目背景知识：当前技术栈、架构约定、历史决策原因

这样模型在执行任务时就有了硬约束，比你每次在 prompt 里反复叮嘱效果好得多。

7. 合理利用 Skill 弥补模型短板​

模型在某些任务上表现很差：

  • 生成复杂文档（Word、PPT、Excel）→ 让模型调用专门的文档库/SDK
  • 高精度 UI 还原 → 让模型参考设计稿或组件库
  • 多步骤数理计算 → 让模型写代码来算，而不是自己算

不要指望模型什么都擅长。 识别模型的弱项，用 skill 或工具链来补齐，效率会大幅提升。

四、判断与纠偏​

8. 警惕模型"钻牛角尖"​

当模型思考内容过长、陷入怀疑和自我否定的循环时，要停下来判断：

  • 是方向本身错了？
  • 还是 LLM 理解有偏差？
  • 还是你输入的 prompt 意图表达不够清晰？

及时终止无意义的循环，和模型重新对齐目标。

9. 模型有惯性思维​

模型倾向于利用当前已有的上下文信息，朝着一个方向死磕。不要一味相信模型的判断，需要人为辨别方向是否正确，及时纠正和止损。

10. 该联网时就联网​

模型倾向于用训练知识来回答问题，但对于一些时效性强、专业领域深入的问题，明确要求它联网搜索效果远比闭门造车好。不要默认模型什么都知道。

一个典型场景是配置环境和写配置文件——模型对这些的记忆往往过时、不准确甚至瞎编，联网搜一下官方文档比让它凭空猜靠谱得多。

11. 结合网页版免费 LLM 进行方案讨论​

对于架构设计、方案对比等需要头脑风暴的场景，可以打开网页版 LLM（如 ChatGPT 免费版、Claude 等）先做一轮讨论。网页版往往回复更快、更灵活，适合前期方案探索。

12. 陈述句让 AI 迎合你，疑问句让 AI 思考你​

向 AI 描述 bug 或问题时，如果用陈述语气下结论（"这里有个 bug""这个是错的"），AI 会触发生成模式——它默认你的前提成立，然后去寻找证据验证它。但你的观察可能有偏差，AI 的理解也可能有偏差，结果就是双方在错误的方向上钻牛角尖。

更好的做法是用疑问句提问（"这段逻辑是不是有问题？""这里的行为符合预期吗？"），这会触发 AI 的校验模式——它先检查前提是否成立，再给出结论。AI 的逻辑校验能力远比它的"猜测用户意图"能力可靠。这是一种表达技巧——把 AI 当作聪明人，像和人讨论问题一样提问。

例外：当你描述的是客观可验证的事实（报错原文、具体现象）时，用陈述句没问题；真正需要避免的，是对原因或结论的提前断言。

13. bug 反复修不好？加日志排查或开新会话​

当一个 bug 经过多轮对话仍未能修复时，强烈建议你主动介入，而不是让 LLM 继续自主尝试。此时 LLM 很可能已经陷入了思维陷阱——它在错误的方向上反复打转，每次的"新方案"只是换一种方式重复同样错误的逻辑。

正确的做法是：叫停 LLM 的自主修复，要求它加上日志去排查。打印关键变量的值、追踪执行路径，让数据说话。日志给出的客观信息远比 LLM 的"猜测式修复"可靠。或者直接新开一个会话，清空上下文，重新从问题本身出发分析。

记住：LLM 反复修不好一个 bug，往往不是 bug 太难，而是它方向已经偏了。方向不对，越努力越糟糕。

五、工具风险意识​

14. bash 容易陷入无限循环​

Agent 在使用 bash 执行命令时，有时会陷入无限循环（比如不断重试、反复检查）。长时间运行的命令推荐手动在终端中执行，不要在聊天框里让 Agent 跑。

15. read / edit / write 同样有无限循环风险​

不要以为只有 bash 会卡住。read、edit、write 这些工具同样可能陷入循环——比如 Agent 反复读同一个文件、反复写入同样的改动。需要人为判断并及时终止。

16. 危险命令有误删风险​

bash、delete 工具操作时要格外小心。重要代码及时备份。不怕一万，只怕万一。

六、写在最后​

17. 对话不仅仅是完成任务​

不要把 Agent 会话当成一次性的工具调用。在对话中多记录、多总结、多更新文档。 任务即会话，会话即文档。充分记录并发挥每一个会话的作用——它们不仅是完成任务的通道，也是你日后回顾、复用的宝贵资产。