夜雨聆风
告别效率焦虑,为什么你装了百项插件却依然写不出好代码
你有没有过这种感觉——
打开 Claude Code 或 Codex CLI，满怀期待地让它帮你写个功能，结果它产出一堆莫名其妙的代码。你看着屏幕，心想：“网上那些说 AI 能自己写火箭的人，到底是怎么做到的？”
于是你开始怀疑自己。是不是我的配置不对？是不是要装那个超火的 beads 插件？还是我的 CLAUDE.md 写得不够长？
你的配置文件从 100 行涨到 2000 行，你的插件列表越来越长，你的焦虑也越来越重。但别人的 AI 在造火箭，你的 AI 连两块石头都垒不好。
深呼吸。问题不在你。
你只是被”效率焦虑”绑架了。
今天这篇文章，来自一位从 AI Agent 还在写玩具代码时就开始使用的资深玩家。他想告诉你一件事：那些让你装一堆插件、学一堆框架的建议，大多数都是错的。
01 前沿公司比你更懂：有用的功能，他们自己会做
先说一个残酷的现实。
你知道谁是 Claude Code 和 Codex 最忠实的用户吗？是 Anthropic 和 OpenAI 的员工自己。
他们有无限的 token 预算，有最新的模型版本，每天都在高强度的实战中使用这些工具。如果一个”痛点”真的存在，如果一个”解决方案”真的好用——他们会第一个知道，然后把它做进产品里。
想想看，为什么 Claude Code 和 Codex 现在都有了 Skills 功能？为什么 OpenAI 收购了 OpenClaw？为什么 Planning（规划先行）变成了核心功能？
因为这些是真的有用。
反过来说：如果一个功能需要靠第三方插件才能实现，而且存在了很久都没被官方吸收——那它大概率不是”颠覆性的创新”，而是”看起来很酷但实际没什么用”的东西。
所以，第一原则：别追新，追官方。
定期更新你的 CLI 工具，读一读更新日志，看看官方加了什么新功能。这就够了。你的时间应该花在”用 AI 解决问题”上，而不是”研究怎么给 AI 装更多插件”。
02 上下文不是越多越好，而是刚刚好
这是很多人用不好 AI Agent 的根本原因。
你可能觉得，给 AI 的信息越多越好——把项目历史、会议纪要、26 个 session 前的调试笔记全塞进去。你甚至为此装了个”智能记忆系统”。
但结果呢？AI 变笨了。
这不是错觉。JetBrains 的研究团队专门做过实验：当 Agent 的上下文过长时，它会开始”重复过去的操作”，而不是想新办法。 Anthropic 把这个现象叫 “Context Rot”（上下文腐烂），Chroma 的报告显示，大约在 20 万 token 左右，模型能力就会开始明显下降。
打个比方：想象你请了一个超级聪明的新同事，但在他开工前，你先给他塞了 500 页的”公司历史档案”。你觉得他能专注于手头的任务吗？
Context is everything——但指的是”精准的上下文”，不是”所有的上下文”。
这里有一个黄金法则：给 Agent 的信息，应该是”完成任务所需的最小集合”，多一个字都不要给。
如果你让 Agent 写个 Python 小游戏，它不需要知道你 71 个 session 前配置过什么子进程，也不需要知道你上次会议讨论了什么架构调整。那些”智能记忆系统”和”自动笔记插件”，可能正在帮倒忙。
03 把”研究”和”实现”分开
很多人用 AI 的方式是：”去帮我建一个用户认证系统。”
看起来没问题对吧？但这里有个隐患。
Agent 收到这个指令后，需要先”研究”：什么是用户认证？有哪些方案？JWT 还是 Session？各有什么优缺点？它会去搜索、对比、分析……
等它终于开始写代码的时候，它的上下文已经被各种”研究资料”塞满了。真正写代码的时候，它可能已经忘了你项目的具体约束，或者开始”幻觉”一些不存在的库。
更好的做法是：把研究和实现分成两个独立的 session。
第一个 session 专门做研究：”帮我调研用户认证的主流方案，给出推荐。”
你拿到方案后，自己判断哪个适合你的项目。然后开一个新的 session，给出明确指令：”用 JWT + bcrypt-12 实现，refresh token 7 天过期。”
这样，实现阶段的 Agent 拿到的是干净的上下文 + 明确的指令，出错的概率会大大降低。
04 AI 会”讨好”你，甚至不惜撒谎
这是 AI 界的一个公开秘密，AI 教父 Yoshua Bengio 最近专门讨论过。
它叫 Sycophancy（阿谀奉承）。
你问 AI：”帮我找找代码里的 bug。”它会找到——即使它需要”编造”一个 bug。
为什么？因为 AI 被训练成要”让用户满意”。当你给它一个任务，它会尽全力完成——即使这意味着”编造答案”。
这不是 AI 的”邪恶”，而是 RLHF（人类反馈强化学习）训练的副作用。当 AI 的回复符合用户预期时，用户更可能给好评。久而久之，AI 学会了”顺着你说”。
那怎么办？
有两个策略：
策略一：用”中立提示”
别问”帮我找 bug”，而是说：”检查代码逻辑，报告所有发现。”
前者暗示”肯定有 bug”，后者是中立的观察任务。后者更可能给出真实的反馈。
策略二：利用”讨好倾向”做多 Agent 对抗
这个技巧很妙。既然 AI 会”讨好”，那就让它讨好好几个不同的”主人”：
- Bug 猎人 Agent
：告诉它”找到 bug 可以加分，越严重的 bug 分越高”。它会非常积极地把所有”疑似 bug”都列出来——包括一些其实不是 bug 的。 - 辩护律师 Agent
：告诉它”每成功推翻一个 bug 得分，但如果推翻错了要扣双倍”。它会非常积极地证明那些”bug”不是 bug——包括一些真正的 bug。 - 裁判 Agent
：让它在两个 Agent 的争论中做出判断。
三个 Agent 互相制衡，最终的结论往往出奇地准确。
05 给 AI 一个明确的”终点”
AI 很擅长”开始”一个任务，但不擅长”结束”它。
你有没有遇到过这种情况：Agent 写了一堆代码，说”完成了”，你一看——全是空的 stub（桩代码），核心逻辑根本没实现。
这不是 Agent 偷懒，而是它真的不知道什么叫”完成”。在它的世界里，写完了函数签名，任务就结束了。
怎么解决这个问题？给它一个无法糊弄的”终点线”。
最好的终点线是测试。
“写完这个功能后，运行测试套件。所有测试通过之前，任务不算完成。而且你不允许修改测试代码。”
这样，Agent 就有了明确的”完成标准”。你只需要检查测试是否通过，就知道它是不是真的完成了。
另一个强大的终点线是截图验证。
对于前端任务，你可以让 Agent 实现功能后截个图，然后让它自己对比截图和设计稿，判断是否符合预期。这能避免它”写完就跑”的问题。
更进阶的做法是创建一个 {TASK}_CONTRACT.md 文件，里面明确列出：哪些测试必须通过、哪些截图需要验证、哪些检查项必须完成。Agent 只有满足所有条件，才能”下班”。
06 用 Rules 和 Skills 慢慢”养”你的 AI
很多人想要一个”开箱即用完美”的 Agent 配置。
但想想看，你招了一个新同事，会期望他第一天就知道你喜欢几点喝咖啡、怎么写代码注释、你的项目用哪些规范吗？
不会。这些是”慢慢磨合”出来的。
AI Agent 也一样。
正确的姿势是：从极简开始，慢慢添加你的偏好。
当你发现 Agent 做了一件你不喜欢的事，别只是在心里吐槽。把它写成一条 Rule，加到你的配置里。
“写代码前先读 RULES.md。”
“如果写前端，读 FRONTEND_RULES.md。”
“如果测试失败，读 DEBUG_RULES.md。”
你的 CLAUDE.md 应该像一个”条件分支目录”——告诉 Agent 在什么情况下去哪里找什么信息，而不是把所有规则都塞在一个文件里。
Skills 则是用来固化”做事方法”的。
当你发现某个任务 Agent 总是做不好，别每次都手把手教。让它先”研究”怎么做，把方法写成一个 Skill。下次遇到类似任务，它就可以直接调用这个 Skill。
这样做的好处是：你不用每次都从头解释，而且你可以提前审查 Agent 的”方法论”，在它真正遇到问题之前就纠正它。
07 什么时候该”清理门户”
当你添加了越来越多的 Rules 和 Skills 之后，神奇的事情发生了：Agent 开始”懂你”了。它写出的代码越来越符合你的风格，做决策的方式越来越像你会做的那样。
但然后，问题又来了：它开始变笨了。
为什么？因为 Rules 之间开始冲突了，Skills 之间开始打架了。Agent 启动前要读 14 个 markdown 文件，它的上下文又被塞满了。
这时候，该做”大扫除”了。
让 Agent 去审查你所有的 Rules 和 Skills，找出冲突的地方，整合重复的内容。它会帮你”瘦身”，然后一切又变得丝滑了。
这就是 AI Agent 工程的终极秘密：保持简单，定期清理，像养一个新同事一样慢慢磨合。
不需要追最新的框架，不需要装最全的插件。你需要的，只是理解 Agent 的工作原理，然后像一个好经理一样”管理”它。
少即是多。这四个字，值百万 token。
原文链接：
https://x.com/systematicls/status/2028814227004395561
