AI 使用心得

这是个人配置，不是规范。 这里记录的是我自己的取舍，你完全可以不同意。 客观的参数说明请看 Omnigate 的 Claude Code 进阶 文档。

• 解决什么问题：用了一段时间后觉得「好像可以更好用」，但不知道该调什么。
• 适合：已经跑通基本流程、每天都在用 AI 写代码的人。
• 不适合：刚接入还没发出第一个请求的人——先去看快速开始，这篇现在读不进去。

都是自己踩过之后总结的，不一定对所有人适用，但至少省了我不少时间和钱。

写完代码后怎么用「Claude 生成 + Codex 挑刺」双模型过一遍，见我的 AI 编程工作流。

一、上下文是唯一真正的资源

用久了会发现，决定 AI 编程质量的不是模型有多聪明，而是你给它的上下文有多准。同一个模型，在信息充分的项目里像资深工程师，在信息缺失的项目里像刚入职第一天。

所以优先级应该是：写好 CLAUDE.md > 挑更贵的模型 > 装更多插件。前者的效果立竿见影且持续有效，后两者边际收益递减得很快。

具体一点：让它改 bug 之前，先把复现步骤、报错全文、相关文件路径给它。这三样东西你花三十秒整理，能省掉它五轮试探性的搜索——那五轮的 token 加起来比你想象的多。

二、/clear 用少一点，/compact 用多一点

这条反直觉，但很重要。

很多人觉得对话越长越贵，所以频繁 /clear 重开。实际上恰恰相反：长对话里的历史部分是命中缓存的，缓存输入的价格通常只有正常输入的一个很低的折扣。而 /clear 之后，它要重新读一遍项目结构、重新理解你在干什么，这些全都是全价的新输入。

真正该 /clear 的时候只有一个：切换到一件完全无关的任务。这时候旧上下文纯属干扰，留着既费钱又降低质量。

同一件任务内上下文太长了，用 /compact——它保留要点、丢掉过程，比推倒重来划算得多。

配合状态栏看上下文百分比，到 70% 左右压缩一次是个不错的节奏。

三、模型分级用

别所有事都上最贵的模型。我的分法：

• 改一两行、写测试、格式化、写 commit message、翻译文档 → 小模型（Haiku 一类）。这些任务的正确率主要取决于任务本身有多明确，不取决于模型多强。
• 日常开发的主力 → 中档模型（Sonnet 一类）。绝大多数编码任务在这一档就够，性价比最高。
• 架构决策、复杂重构、诡异的 bug、性能问题 → 最强的模型。这些场景下便宜模型的返工成本远超差价。

判断标准：如果这个任务你自己一眼能看出对错，用便宜的；如果你需要仔细审才知道对不对，用贵的。 因为前一种情况下模型犯错的代价很低，后一种情况下你可能审不出来。

另外别忘了设 ANTHROPIC_DEFAULT_HAIKU_MODEL。Claude Code 自己会用小模型干很多杂活（生成会话标题、做摘要），这部分默认走什么模型就影响了一笔看不见的开销。

四、一次只让它做一件事

「顺便把这个也改一下」是质量杀手。

同时塞三个需求进去，它会做完第一个、马马虎虎做第二个、忘掉第三个，或者更糟——为了同时满足三个而写出一个别扭的折中方案。而你在 review 时也很难分辨哪个改动属于哪个需求。

拆开做，每个做完验证一次。总时间不会更长，因为你省掉了「这一大坨改动到底哪里不对」的排查时间。

五、让它自己验证

只让它写代码，不让它跑验证，是在给自己制造返工。

至少要保证它能跑测试和类型检查。把命令写进 CLAUDE.md，把权限加进 settings.json 的 allow 列表，然后明确要求「改完跑一遍 xxx，有错继续修到通过」。

有了这个闭环之后，它交回来的东西质量会有一个台阶式的提升——因为它自己看到了失败输出，并且有机会修。没这个闭环时，它交给你的是「我觉得应该能跑」。

自动格式化这类必须每次执行的事，做成 hook，别指望提示。

六、计划模式的正确用法

改动超过三个文件，先 plan。

原因不是它容易做错，而是你和它对「该怎么改」的理解经常不一致，而这个不一致在看方案的时候花一分钟就能发现，在看 diff 的时候要花二十分钟。

我的习惯是：plan 模式下它给出方案，我不满意的地方直接说「第二步不要这样做，改成……」，来回一两轮方案定型，然后放它去实施。实施阶段基本不需要再干预。

七、把重复的东西固化下来

你每天输入的 prompt 里，有相当一部分是重复的。做成自定义命令。

这件事的收益不止是省打字。当一段 prompt 变成文件之后，你会开始打磨它——加上边界条件、加上输出格式要求、加上「不要做什么」。而临时输入的 prompt 永远停留在能用就行的水平。

我用得最多的几个命令：审查当前 diff、把失败的测试修到通过、给这个模块补测试、解释这段代码为什么这么写。

八、别装太多东西

MCP 服务、插件、agent 集合，装得越多不代表越强。

三个原因：一是每个 MCP 服务的工具定义都占上下文，挂十个就是几千 token 的固定开销；二是选项变多之后它挑工具的准确率反而下降；三是第三方的 hook 和脚本会在你的机器上以你的权限运行，这是真实的安全风险——最近就有伪装成热门配置仓库的恶意克隆在传播。

我的实际配置：context7（查文档，防止它凭记忆写过时 API）、playwright 或 chrome-devtools（只在做前端时开）。就这些。

第三方 agent 集合，建议只挑单个文件看懂了再复制过来，不要整套装。

九、它擅长什么，不擅长什么

擅长：写样板代码、补测试、跨文件的机械性重构、读陌生代码库并解释、把报错翻译成人话、写一次性脚本。

不擅长：判断一个业务决策该怎么做、在信息不足时承认自己不知道（它会编）、涉及大量隐含约定的老系统改造、性能问题的根因定位（除非你给它 profile 数据）。

最需要警惕的一类：它写出来的代码看起来非常合理，但基于一个错误的前提。 比如它假设某个函数是幂等的，而实际不是。这种错误 review 时最难发现，因为代码本身没有任何异常。防御方法只有一个——对涉及正确性的关键路径，自己看懂，别只看它的解释。

十、成本这件事

真正的成本大头不是单次请求贵，而是：

• 反复返工（上下文给得不够，它做错，你让它重做）
• 无效的长对话（同一个上下文里干了五件无关的事）
• 该用小模型的地方用了大模型
• 没设 max_tokens 上限，让它写了两千行你根本不会看的解释

这几项加起来通常占浪费的绝大部分。优化它们比在模型单价上抠划算得多。

定期去 Omnigate 用量日志翻一下。看看哪些请求的 token 数异常大，通常都能发现一两个「原来这里在反复重传整个文件」之类的问题。

最后

工具在快速变化，上面这些结论里有一部分半年后可能就不成立了。但有一条应该会一直成立：AI 放大你的判断力，而不是替代它。 你说得清楚要什么，它就能帮你很多；你自己都没想明白，它只会帮你更快地写出错的东西。

有问题欢迎联系我。

本文原载于 Omnigate。