1. 为什么“开源节流”在 AI 编程里是个真问题很多人第一次用 Codex 或者 Claude 这类 AI 编程助手心态都是“可劲儿造”——反正按量付费能自动补全就自动补全能让它读整个仓库就读整个仓库能开新会话就开新会话。结果月底一看账单或者发现响应越来越慢、上下文越来越乱才意识到这东西跟水电一样是有成本的。我自己的经历挺典型。刚开始用 Claude Code 做一个小型重构任务图省事直接把整个项目目录丢给它让它“自己看着办”。它确实看着办了但每次对话都要重新吞一遍几万行的上下文token 消耗肉眼可见地涨而且它经常被无关文件带偏改出来的东西还得我手动回滚。后来我换了个思路把“开源”和“节流”当成两个独立的优化维度来对待——开源是让每一次调用都产出最大价值节流是让每一次调用都别浪费。这两件事做对了AI 编程才真正从“玩具”变成“工具”。这篇笔记就是把我这段时间在 Codex 和 Claude 上踩过的坑、试出来的配置、以及一些不太出现在官方文档里的经验整理出来。不管你是刚装好 Codex 想试试水还是已经在用 Claude Code 做日常开发这里面的思路应该都能直接拿去用。核心就一句话AI 编程的效率和成本很大程度上不取决于模型本身而取决于你怎么喂它、怎么管它、怎么在它犯错之前拦住它。2. 上下文管理别让 AI 读它不需要读的东西2.1 全量投喂为什么是最大的浪费先说一个反直觉的结论给 AI 更多上下文不一定让它更聪明很多时候反而让它更蠢。这跟人有点像——你让一个新同事去改一个函数结果把公司十年的会议纪要全塞给他他大概率会懵。Codex 和 Claude 在处理长上下文时都有一个共同特点注意力会被稀释。当上下文里塞了大量与当前任务无关的代码、注释、配置文件时模型在生成建议时会倾向于“参考”那些无关内容导致改错文件、引入不存在的依赖、或者把别的模块的命名风格带进来。更直接的成本是 token每一次对话都要为这些无关内容付费而且很多工具的计费是按输入 token 算的你读得越多花得越快。我做过一个粗略的对比。同一个重构任务全量投喂项目目录约 4 万行代码和只投喂相关三个文件约 800 行完成质量差不多但前者的 token 消耗是后者的 20 倍以上而且前者平均需要 3 到 4 轮才能改对后者基本一轮就能给出可用结果。这个差距在长期使用中会非常明显。2.2 用“任务边界”代替“项目边界”来圈定上下文正确的做法是不要按项目结构来圈上下文要按任务边界来圈。什么意思假设你要改一个用户登录的校验逻辑这个逻辑可能涉及三个文件路由处理、校验函数、以及一个工具类。那你的上下文就应该是这三个文件而不是整个src目录。具体操作上Codex 和 Claude Code 都支持你手动指定文件或者用某种方式限定范围。我的习惯是在开始一个任务之前先花两分钟想清楚这个改动会碰到哪些文件哪些文件是“必须让 AI 看到的”哪些是“最好让它看到但非必须的”然后只把必须的那部分喂进去。提示如果你不确定某个文件是否相关可以先不喂。等 AI 给出第一版建议后如果它明显缺少某个上下文你再补进去。这比一开始就全量投喂要省得多。2.3 会话隔离一个任务一个会话别混着用另一个容易被忽略的点是会话管理。很多人习惯在一个会话里连续做多个不相关的任务觉得这样“省事”。但实际上混用会话是上下文污染的主要来源之一。比如你先让 AI 帮你写了一个数据库查询然后紧接着让它改一个前端组件的样式。这时候会话里还残留着数据库相关的表名、字段名、查询逻辑AI 在改样式时可能会莫名其妙地引用这些内容或者在你没要求的情况下“顺手”改掉一些数据库相关的代码。这不仅浪费 token还增加了 review 的负担。我的做法是一个独立任务开一个新会话。任务完成后如果还要做别的事直接关掉重开。虽然看起来多了一步但省下来的 token 和避免的混乱绝对值回这点操作成本。Claude Code 里可以用/clear或者直接退出重进Codex 里也有类似的会话重置方式养成习惯就好。2.4 上下文压缩什么时候该压什么时候不该压有些工具提供了“上下文压缩”功能就是把历史对话总结成一段简短描述减少后续 token 消耗。这个功能用好了是神器用不好是灾难。我的经验是压缩适合“长对话但任务单一”的场景不适合“多任务混杂”的场景。比如你和一个 AI 连续讨论了某个算法的三种实现方式对话很长但主题集中这时候压缩一下保留核心结论后续继续讨论时既省 token 又不丢关键信息。但如果你在一个会话里已经做了三件不相关的事压缩只会把这三件事搅在一起越压越乱。另外压缩之后一定要检查一下AI 有没有把关键约束条件压没了比如你之前明确说过“不要用某个库”压缩后这个约束可能就丢了后续它又会用上。所以压缩后最好再补一句关键约束确保它还记得。3. 提示词不是越长越好精准指令的写法3.1 长提示词的陷阱AI 也会“抓不住重点”很多人写 AI 编程提示词时喜欢写一大段背景介绍、需求描述、注意事项觉得越详细越好。但实际用下来过长的提示词反而会让 AI 抓不住重点。这跟开会一样你说了十分钟对方可能只记住了最后一句。我见过一个典型的反面例子有人让 AI 改一个函数提示词写了 500 多字包括项目背景、业务逻辑、历史原因、个人偏好最后才说“把这个函数里的循环改成递归”。结果 AI 花了很多篇幅去回应前面的背景真正要改的地方反而一笔带过甚至改错了。3.2 用“动词 对象 约束”的结构写指令我的建议是提示词尽量控制在三句话以内结构是“动词 对象 约束”。比如“把validateUser函数里的同步校验改成异步不要改变函数签名。”“在LoginForm组件里加一个 loading 状态用现有的useState风格不要引入新依赖。”“重构parseConfig函数把嵌套的 if-else 改成早返回保持原有错误信息不变。”这种写法有几个好处AI 一眼就知道要做什么、对什么做、有什么限制你 review 的时候也容易判断它有没有做对而且 token 消耗低因为废话少。3.3 约束条件要具体不要抽象约束条件最怕抽象。比如你说“代码要优雅”AI 不知道什么叫优雅你说“性能要好”它也不知道好到什么程度。但如果你说“不要用嵌套超过两层的循环”“不要引入新的 npm 包”“保持现有的错误处理风格”它就很容易执行。我一般会把约束分成三类技术约束用什么、不用什么、风格约束命名、格式、注释、边界约束不要改什么、不要碰什么。每次写提示词时至少把技术约束和边界约束写清楚风格约束如果项目有统一规范也可以带上。3.4 示例比描述更有效有时候你描述半天不如给一个例子。比如你想让 AI 按照某种格式写测试直接给它一个现有测试文件的片段说“按照这个风格写”比你说“用 describe-it 结构断言用 expectmock 用 jest.fn”要有效得多。Codex 和 Claude 都支持你在提示词里引用文件内容或者粘贴代码片段。我的习惯是如果任务涉及某种特定风格我会先贴一段“参考实现”然后说“按照这个风格改另一个函数”。这样 AI 的产出会稳定很多返工率明显下降。4. 模型选择与调用策略不是所有任务都值得用最强模型4.1 任务分级什么任务用什么模型Codex 和 Claude 都有不同能力层级的模型可选。很多人图省事所有任务都用最强的那一档结果就是成本高、速度慢而且很多简单任务根本用不上那么强的能力。我的做法是把任务分成三档任务类型典型场景推荐模型档位理由轻量任务改命名、加注释、格式化、简单补全轻量/快速档这些任务对推理能力要求低快速档足够且响应快、成本低中等任务写单元测试、重构小函数、修简单 bug标准档需要一定推理能力但不需要最强模型复杂任务架构设计、跨模块重构、复杂算法实现最强档需要深度推理和全局理解值得用最强模型这个分级不是绝对的但思路是把最强模型留给真正需要它的任务。你让最强模型去改一个变量名它也能改但就像用卡车送快递——能送但没必要。4.2 批量任务合并减少调用次数另一个节流技巧是把能合并的任务合并成一次调用。比如你有五个小函数要加注释不要一个一个让 AI 做而是一次性把五个函数贴进去说“给这五个函数各加一段注释风格统一”。这样一次调用就搞定比五次调用省得多。但要注意合并的任务最好是同类型的。如果你把“加注释”和“重构逻辑”混在一起AI 可能会顾此失彼。同类型任务合并不同类型任务分开这个原则比较稳。4.3 缓存与复用别重复问同样的问题如果你发现自己经常问 AI 类似的问题比如“这个项目的错误处理规范是什么”“这个组件的 props 类型怎么定义”那说明你应该把这些信息固化下来而不是每次都问。我的做法是维护一个“项目约定”文件里面写清楚命名规范、错误处理方式、常用工具函数、目录结构约定等。每次开新会话时如果任务涉及这些内容就把这个文件贴进去而不是让 AI 自己去猜或者去读整个项目。这样既省 token又保证一致性。5. 实测中那些官方文档不会告诉你的坑5.1 安装与配置阶段的常见问题Codex 和 Claude Code 在安装配置阶段就有不少坑。比如在 Windows 上Claude 的某些功能需要虚拟机平台支持如果没开会直接报错。Codex 的认证 token 有时会失效需要重新登录。这些问题的解决方式通常不在官方快速上手文档里而是在社区讨论或者 issue 里。我的经验是安装阶段遇到报错先看错误信息里的关键词然后直接搜那个关键词大概率有人遇到过。不要自己瞎试浪费时间。另外配置环境变量时注意区分“全局配置”和“项目配置”有些工具两者会冲突导致行为不一致。5.2 网络与代理相关的报错处理Codex 和 Claude 在某些网络环境下会出现连接问题报错信息可能比较模糊比如“proxy failed while handling endpoint”之类的。这类问题通常跟本地网络配置有关不是工具本身的 bug。处理这类问题的思路是先确认基础网络是否正常再检查工具本身的代理配置是否正确最后看是否有防火墙或安全软件拦截。如果是在公司网络环境下可能还需要确认是否有额外的网络策略限制。这些排查步骤听起来简单但实际遇到时很容易慌按顺序来就行。5.3 上下文窗口的“隐形天花板”虽然官方会标称一个很大的上下文窗口但实际使用中当上下文接近窗口上限时模型的表现会明显下降。它可能开始“忘记”前面的内容或者把不同部分的信息混淆。这不是 bug而是长上下文模型的通病。我的应对方式是不要让上下文接近上限。如果发现对话已经很长了主动开新会话把关键结论带过去而不是硬撑着继续。一般来说用到窗口的 60% 到 70% 时就该考虑清理了。5.4 模型“自信地犯错”怎么防AI 编程最危险的不是它说“我不知道”而是它自信地给出错误答案。比如它可能引用一个不存在的函数、用一个没安装的库、或者改错一个边界条件但语气非常肯定。防这个的办法有几个一是要求它给出依据比如“你引用的这个函数在哪个文件里定义的”它如果答不上来说明可能是编的二是小步验证不要让它一次改太多改一点就测一点三是保持怀疑尤其是它改动了你没让它改的地方时一定要问清楚为什么。6. 把“开源节流”变成日常习惯6.1 建立自己的检查清单我后来给自己列了一个简单的检查清单每次用 AI 编程前过一遍这个任务真的需要 AI 吗还是我自己写更快我需要喂哪些文件能不能再少一点提示词有没有废话约束条件写清楚了吗这个任务值得用最强模型吗会话是不是该新开一个这几句话花不了半分钟但能省下不少 token 和返工时间。6.2 记录每次“翻车”的原因我还有一个习惯每次 AI 改错了我会简单记一下原因。是上下文不够是提示词有歧义是模型选错了还是任务本身太复杂记多了之后我发现大部分翻车都集中在几个固定原因上针对性地改掉之后成功率明显提升。比如我发现自己经常因为“没写清楚不要改什么”而导致 AI 顺手改了无关代码后来我每次都会加一句“只改这个函数不要动其他文件”这个问题就基本消失了。6.3 定期回顾 token 消耗如果你用的是按量付费的方案建议定期看一下 token 消耗情况。不是为了省钱而省钱而是通过消耗分布来判断哪些任务花得多花得值不值有没有可以优化的地方我自己的观察是token 消耗的大头往往不是复杂任务而是那些“随手问一下”的碎片化调用。这些调用单次消耗不大但频率高累积起来很可观。后来我把这些碎片化问题集中起来攒到一定数量再一次性问消耗就降下来了。6.4 工具是死的用法是活的Codex 和 Claude 都在快速迭代功能会变计费方式也可能变。但“开源节流”这个思路不会过时让每一次调用都有明确目的让每一份上下文都有存在理由让每一个任务都用合适的模型。这三点做到了不管工具怎么变你都能用得比较舒服。我现在的状态是AI 编程已经成了日常开发的一部分但我不再像刚开始那样“可劲儿造”了。该用的时候用该省的时候省该自己写的时候自己写。这种节奏感可能比任何具体技巧都重要。