夜雨聆风我用AI写了一年代码，才发现90%的人都用错了方式
"
一位资深 Agentic 工程师的 6 条血泪经验，帮你从"AI工具使用者"进阶到"AI指挥官"。
你有没有过这种经历：
每天打开 Claude / ChatGPT / Cursor/Vscode，满怀期待地输入需求，结果它要么给你一堆废话，要么写的代码跑都跑不通。
然后你去刷社交媒体，看到有人晒出"我用 AI 一天搭建了一个完整系统"、“AI 帮我写了 5000 行代码零 bug”，心里五味杂陈——同样是 AI，为什么差距这么大？
你以为问题出在你的提示词不够好？于是你去学 Prompt Engineering，把 CLAUDE.md 写到了 26000 行，装了一堆插件和框架，追着每一个新出的 AI 工具跑……
但情况并没有好转。
今天这篇文章，我想和你分享一个可能颠覆你认知的观点：
"
你不是缺更好的工具，你是缺一套正确的"使用哲学"。
先说结论：少，即是多
我接触 AI 辅助编程已经很久了——从 AI 还只能写 Hello World 的时代就开始了。我试过所有的框架、所有的插件、所有的范式。我甚至用 AI 构建过在生产环境实际运行的 agentic 工厂。
而经过这一切之后，我现在用的配置几乎是最简的：就是官方的 Claude Code / Codex CLI，加上几个核心原则。
效果呢？反而比我折腾一百个工具的时候好得多。
为什么？因为有一个大多数人忽略的事实：
"
OpenAI 和 Anthropic 的员工，才是 AI 工具最重度的用户。他们有无限的 token 预算、最新的模型。如果某个第三方工具真的解决了核心痛点，他们会怎么做？
直接整合进自己的产品。
你看 Skills、Memory、Subagents 这些功能——最初都是社区里的第三方方案，现在全部成了官方标配。
所以我的第一条建议：别追新工具了。保持极简，定期更新你的 CLI，读一下更新日志就够了。
6 条核心原则，每一条都是踩坑换来的
① 上下文就是一切
想象一下这个场景：
"
你让 AI：“帮我写一个 Python 猜词游戏。”
AI 打开你的工作区，看到了 26 个 session 之前的一条笔记"关于内存管理的思考"，又看到了 71 个 session 之前因为 spawn 太多子进程导致系统卡死的记录……
它的脑子里塞满了这些跟猜词游戏八竿子打不着的信息。
这就是 Context Bloat（上下文膨胀）——AI 被无关信息淹没了。
正确做法：给 AI 恰好够的信息，不多不少。就像你给一个极其聪明但容易分心的同事布置任务——只告诉他做这件事需要知道的事，其他免谈。
② 把"研究"和"实现"分开
这是我认为对普通人提升最大的一条。
❌ 错误做法：
你："帮我去搭一个认证系统"AI：（开始研究什么是认证？JWT？OAuth？Session？各有啥优缺点？） （上下文被各种方案填满） （最后选了一个不合适的方案，实现时还混进了别的方案的细节）✅ 正确做法：
第一步（研究 Session）：你："调研一下用户认证的主流方案，给我对比分析"第二步（决策）：你看了分析后决定："用 JWT + bcrypt-12 + 刷新 token 轮换"第三步（全新 Session 实现）：你："实现 JWT 认证，bcrypt-12 哈希，token 7天过期轮换"AI：（上下文干净，专注执行，质量大幅提升）核心逻辑：让研究阶段自由探索，让实现阶段从零开始、心无旁骛。
③ AI 会"讨好"你——利用这一点
这是整篇文章最有意思也最实用的发现。
AI 产品天然的设计倾向是：取悦用户。你说什么，它就想方设法满足你。
这带来一个问题：
"
你说：“帮我找找代码里的 bug” AI：（内心）主人要找 bug → 必须找到！找不到就编一个！
这不是 AI 在撒谎，这是它的设计使然。
那怎么应对？作者给出了一个堪称天才的三角色对抗模式：
┌─────────────────────────────────────────────────────┐│ 三角色对抗模式 │├─────────────────────────────────────────────────────┤│ ││ 🔍 Bug Finder ⚔️ Adversarial 🎯 Referee ││ （找茬专员） （杠精专员） （裁判员） ││ ││ "找到越多bug "成功反驳一个 "判断谁说得 ││ 分越高" bug 得分，判错 对就得分" ││ 扣双倍分" ││ ↓ ↓ ↓ ││ 所有可疑点 过滤误报 最终真相 ││ （超集） （子集） （真集） ││ │└─────────────────────────────────────────────────────┘为什么有效？
• Bug Finder 为了得分会过度积极（连不是 bug 的也报上来） • Adversarial 为了得分会过度反驳（连真实 bug 也想反驳掉） • Referee 在双方极限拉扯中给出最接近真相的判断
这不只是找 bug 的技巧，这是一种通用的思维方式——当你需要 AI 给你高质量输出时，引入"反对意见"会让结果靠谱得多。
④ AI 压缩后会变"蠢"
如果你用过 Claude Code 或类似工具足够久，你可能注意到了：
有时候 AI 聪明得吓人，有时候蠢得离谱。
区别在哪？看它是否需要"脑补"信息。
当对话太长触发压缩（Compaction）后，AI 会丢失大量上下文细节。此时它不得不"填补空白"——而这恰恰是它最弱的能力。
解决方案很简单但极重要：
"
每次压缩发生后，让 AI 重新读取任务计划和关键文件，再继续工作。
这条规则值得写进你的 CLAUDE.md 第一行。
⑤ 告诉 AI 什么时候算"做完"
人类天生知道任务什么时候完成。AI 不知道。
这导致一个常见现象：AI 写了个函数骨架（stub），跑了下没报错，就觉得任务完成了。
解决方法：定义明确的验收标准。
TASK_CONTRACT.md（任务契约）:✅ 必须通过的测试：至少 10 个单元测试✅ 代码规范检查：ESLint 零警告✅ 截图验证：UI 与设计稿一致✅ 文档要求：README 已更新使用说明配合 stophook 使用：不满足契约条件，不允许结束任务。
这个思路可以延伸到任何场景——不只是写代码，写周报、做方案、写文章都可以定义"完成契约"。
⑥ 你必须掌控最终结果
"
No agent today is perfect.
你可以把设计和实现委托给 AI，但你必须对最终结果负责。
把它当成一个极度聪明但偶尔犯蠢的实习生——你需要 review 它的工作，而不是盲目信任。
CLAUDE.md 应该怎么写？答案出乎意料
很多人把 CLAUDE.md 写成了规则百科全书——几千行，涵盖所有编码规范、偏好、禁忌。
这是错的。
CLAUDE.md 正确定位应该是：一个路由目录。
CLAUDE.md（精简版）:# 工作规则索引## 编码相关- 写代码前 → 阅读 coding-rules.md- 写测试前 → 阅读 test-rules.md- 测试失败 → 阅读 debug-rules.md## 文档相关- 生成周报 → 阅读 weekly-report-generator/SKILL.md- 写技术方案 → 阅读 tech-design-template.md## 通用规则- 任务开始前 → 重新阅读 TASK_PLAN.md- Compaction 后 → 重新阅读本文件 + 关键源文件看到规律了吗？只有 IF-ELSE，没有具体规则内容。
规则内容放在各自的文件里，按需加载。这样 AI 的上下文永远干净。
Rules vs Skills：两种武器，不同用法
| 本质 | ||
| 类比 | ||
| 例子 | ||
| 何时加 |
还有一个关键机制：定期清理。
随着 Rules 和 Skills 越加越多，它们会互相矛盾，Context 又开始膨胀。所以每隔一段时间，让 AI 做一次"大扫除"——整合矛盾规则，向你确认更新后的偏好。
作者管这个叫 Spa Day（ spa 日）。很形象。
最后的话
回顾全文，核心其实就一句话：
"
不要试图用更多工具来弥补方法论上的缺失。
AI 工具在飞速进化，每周都有新东西出来。但你真正需要掌握的是那些不变的底层原则——上下文控制、精确指令、验收标准、结果负责。
掌握了这些，无论 AI 怎么进化，你都能站在浪潮之上。
而不是被浪打翻。
如果这篇文章对你有帮助，欢迎点赞、在看、转发给你的技术伙伴们 🙏
我是小冀，一个在 AI 工程实践中持续踩坑和总结的人。关注我，一起成为真正的 Agentic 工程师 💪
