如果你用Claude Code写过几天代码大概率经历过这么一幕你让它改一个模块的日志格式它没直接动手而是先Grep全仓库搜“logger”读了一堆无关的配置文件翻了半天又问“我找到了三个日志实现你指的是哪个”。等你回答完上下文窗口里已经被塞了无数文件片段Token预算烧掉几万代码却一行没碰。这个问题在大型仓库里会被无限放大。Claude Code确实能自己“找路”但找路的代价是工具调用次数爆炸、上下文被无关内容挤占、重要信息被截断最后AI开始答非所问甚至擅自改到别的模块。我在实际项目里踩过这个坑之后总结出一套组合打法2条Prompt 2条命令。思路很简单——强制你喂给AI什么它就只看什么禁止它碰什么它就绝不越界。这篇文章把完整配置、背后的原因、以及实测对比全部展开适合那些已经在用Claude Code、但觉得Token消耗太快、任务经常跑偏的开发者参考。1. 项目概述为什么Claude Code总在“烧钱式找路”先说结论Claude Code不是笨而是它默认的策略就是“先探索再回答”。当你提出一个任务它手里没有项目地图唯一的办法就是调用各种工具去猜——Grep搜关键词、读文件、看目录结构、再试错。这套流程在小型demo里没问题但放到一个几千文件的工程里探索成本是灾难级的。1.1 乱Grep的代价Tokens是怎么悄悄烧光的要理解“烧Token”的本质先要看清一次工具调用到底花了多少钱。以Grep为例每次调用AI要生成工具名和参数这是基础开销工具返回匹配结果时每一行命中内容都要进入上下文窗口如果匹配到一个200行的大函数片段这段代码就直接吃掉几百上千Token。AI看了结果后还要“理解”这又是一轮生成。一次看起来不起眼的搜索实际开销经常是几千Token。更可怕的是这种搜索不是一次就结束。AI会先Grep一次确认位置读文件确认内容发现不对再换关键词Grep再读下一个文件。我观察过几次翻车现场一个“改日志格式”的需求AI前前后后做了近20次工具调用消耗的Token足够写好几版代码。这还没算上最隐蔽的损失——早期读进来的关键信息因为上下文满了被系统截断。打个比方这就像你请了个能力很强但完全不认路的实习生。他干活的热情没得说问题是他每次都先把整栋楼翻一遍才肯动手。你烧的是时间在Claude Code这里烧的是Token。所以省钱的核心不是少用AI而是不让它干那些本可以由你一次性交代清楚的事情。1.2 所谓“无限上下文”其实是精准上下文标题里说的“无限上下文”严格来讲不是技术上的无限而是让你把AI的上下文全部用在刀刃上。上下文窗口是有限的但如果你能让AI不用花Token去探索、不用反复试错、不用读无关文件那么有限的窗口对你来说就像无限一样——因为它只装着和当前任务相关的信息。我把它拆成三步形成一个闭环预置地图把项目结构、关键路径、命名规范、禁区说明一次性打包喂给AI。它不用猜不用搜。划定边界明确告诉它能动什么、不能动什么从源头上掐断“随手改别的文件”的冲动。按需注入需要某个模块的细节时再补充绝不一次性把所有代码都塞进去。这套组合下来AI的上下文窗口里全是有效信息而不是搜索过程中产生的“思考垃圾”。它不是知道了更多而是浪费得更少。1.3 两条命令的设计思路加载与清场2条命令解决的是“怎么把上述思路变成肌肉记忆”。如果每次开新任务都要手打一段长Prompt你大概率用两次就放弃了。所以我把最常用的两个动作做成了shell函数。cc-load一键把当前项目的“项目地图”喂给Claude附带你要开工的初始任务。它的作用是“加载”让AI从第一句话开始就处于有地图的状态。cc-reset一键结束当前会话、清掉上下文开启一个干净的新会话。它的作用是“清场”防止上一个任务的残留信息污染下一个任务。为什么一定要有reset因为Claude Code的上下文是连续累积的。连续做三四个任务之后早期对话内容、旧文件内容、中间的一些无关讨论都在窗口里占着位置。你下一个任务可能和它们毫无关系但AI还是会参考这些残留信息导致“跑偏”的概率直线上升。reset就是翻篇一张干净的白纸永远比涂满旧字迹的纸好写。2. 两条Prompt先和AI“约法三章”很多人用Claude Code的时候Prompt写得太随意——“帮我改一下订单逻辑”这种话扔出去AI当然只能靠猜。它猜的过程就是你烧Token的过程。下面这两条Prompt是经过我多轮调整后沉淀下来的版本一个管“认识项目”一个管“干活边界”。2.1 Prompt 1项目宪法——一次性把地图塞进上下文这条Prompt的作用是让AI在动手前就掌握它需要的全部背景信息。我的建议是第一次使用某个项目时把它当成一个模板去填充之后所有会话都复用同一份内容。标准格式如下请把以下内容作为本次工作的【项目地图】所有任务优先基于该地图行动 - 项目根目录/Users/dev/app - 核心模块 - src/core/auth.py 用户认证与登录逻辑 - src/core/payment.py 支付处理允许改动 - src/utils/logger.py 统一日志封装禁止修改 - 命名规范函数使用snake_case常量使用UPPER_SNAKE_CASE - 环境配置本地使用config/dev.yaml禁止读取生产配置 - 禁止区域tests/ 目录只读不修改vendor/ 忽略 如果地图信息与代码实际不符请停下来说明差异不要自行猜测。这里有几个关键设计。第一给绝对路径不给描述性路径。很多AI跑偏是因为它以为自己知道“日志模块”在哪结果是另一个同名文件。你直接告诉它src/utils/logger.py它就不需要Grep了。第二明确“禁止区域”。这一点比告诉它能做什么更重要。AI的默认行为是尽可能完成任务所以它会倾向于改动任何它认为相关的文件。你如果不说“tests/目录只读”它可能在改业务逻辑的同时顺手改坏一个测试文件。这个边界必须写死。第三强制校验机制。我加了一句“如果地图信息与代码实际不符请停下来说明差异”。这一句看着简单实战里能救你很多次。因为项目是演化中的地图可能过期。与其让AI带着错误地图乱来不如让它停下来问你。2.2 Prompt 2任务边界条款——让它埋头苦编不越界如果说Prompt 1解决的是“认路”Prompt 2解决的就是“守规矩”。每次具体任务开工前我都会在项目地图后直接接上任务边界条款。模板如下本次任务范围 1. 只修改 src/core/payment.py 中 create_order 函数 2. 为它补充失败重试逻辑最多重试3次 3. 不得改动其他函数、其他文件 4. 不得引入新的第三方依赖 5. 不执行测试、不改动测试用例只输出代码变更说明 验收标准 - 代码可编译逻辑符合注释中的业务规则 - 输出变更diff摘要不超过200字 边界以外的一切工作请直接拒绝或告知需要额外授权。先说清楚为什么需要一个单独的“任务边界”Prompt省事的人可能会把边界直接写进项目地图但效果并不好。项目地图是长期存在的它描述的是项目“是什么”而任务边界是临时的它定义的是这一次“要干什么、不能干什么”。混在一起会让AI混淆信息的优先级它做事的时候不知道哪些是全局规则、哪些是当前任务的限制。关于越界。我见过三种最常见的翻车方式一是擅自加依赖用到一个功能就pip install一个新库二是顺手重构明明让你改一个函数它“好心”把整个模块的风格统一了三是扩大修改面改A文件的bug时顺手“修正”了B文件类似的问题。对付这三种情况最有效的措辞不是“不要乱改”而是把这些行为一条条列出来点名“不得改动其他文件”“不得引入新依赖”。AI对于明确的禁令执行得很好但对模糊的“注意分寸”执行得很差。验收标准也别省。让AI每轮任务结束输出一段200字以内的diff摘要一方面方便你检查它有没有越界另一方面也能避免它罗里吧嗦地给一堆报告白白烧掉生成Token。2.3 Prompt写作的两条心法讲完模板再说说那些模板背后的通用心法你以后写自己的版本时用得上。心法一写路径不写描述。举个例子与其说“修改用户认证模块”不如直接说“修改src/core/auth.py”。倒不是说Claude Code理解不了“用户认证模块”而是这种描述会触发它的搜索行为——它得先确认哪个文件是认证模块。路径是确定性信息描述是概率性信息。你给路径它零成本开工你给描述它需要烧Token来验证猜测。心法二否定列表比肯定列表更有效。只告诉AI“你可以改payment.py”它仍然可能基于“让代码更好”的逻辑去动其他文件。但如果你同时列出“不要碰tests/、不要碰config/、不要动logger.py”它的行为边界就清晰得多。AI本质上是一个大模型它对“能做什么”有很强的主动性对“不能做什么”的约束反而记得更牢。原因很简单明确的禁止项在语义上更突出相当于经营上的“高压线”而肯定列表只是“允许区”。3. 两条命令把Prompt变成一键执行Prompt写得再好每次手打一遍也不现实。真正的爽点是把它们固化成一键执行的命令。下面这套配置是我在自己环境里跑的你可以直接抄也可以按自己习惯改名。3.1 命令一cc-load——把项目地图喂进新会话我把每个项目的“项目地图”存成一个独立Markdown文件放在~/.cc-maps/目录下文件名和项目根目录同名。这样任何项目都能复用同一套加载逻辑。对应的shell函数长这样# 一键加载当前项目的项目地图并启动新会话 cc-load() { local map_file$HOME/.cc-maps/$(basename $(pwd)).md if [ ! -f $map_file ]; then echo 未找到地图文件$map_file echo 请先创建可参考以下模板 echo - 项目根目录 echo - 核心模块与绝对路径 echo - 命名规范与禁止区域 return 1 fi { echo 【项目地图已加载】 cat $map_file echo echo 请基于以上地图开始工作。 } | claude }这段脚本的逻辑很简单切到项目目录后执行cc-load它会自动去~/.cc-maps/目录下找同名地图文件然后拼接成一段初始Prompt交给claude命令启动新会话。这样你每次开任务第一句话就已经带着完整地图AI不需要从零开始探索。我在实际使用中的两个调整建议。第一个地图文件也要维护。项目结构一变地图文件就得跟着更新。我自己的习惯是每两周花五分钟检查一遍把新增的核心模块标记进去删掉已经废弃的路径。这个维护成本很低但如果放任不管地图过期后AI会被误导反而不如没有地图。第二个如果你用的是已有会话而不是新会话可以改成把内容复制到剪贴板。我再补一个别名遇到“不重启会话、只注入地图”的场景直接用alias cc-load-pastecat $HOME/.cc-maps/$(basename $(pwd)).md | pbcopy echo 地图已复制到剪贴板直接粘贴到会话中即可pbcopy是macOS的命令Linux环境可以换成xclip -selection clipboard。这样即使不走命令行启动也能手动完成注入。3.2 命令二cc-reset——切断上下文防污染cc-reset的设计目标是一键结束当前会话状态回到一个干净的起点。有人可能会问直接退出终端再重开不行吗行但如果做成了命令你就不用每次手动清理一堆临时状态了。# 重置当前会话开启干净的新会话 cc-reset() { echo 当前会话上下文即将清理开始新会话... # 根据你使用的终端工具清掉当前进程并重启 claude }这里有一点要说明不同版本的Claude Code、不同的终端环境具体重置指令会有一点差异。这个函数的核心目的是把你“手动关掉旧会话、再手动开新会话”的两个动作压缩成一个。你只需要保留“新会话启动”这句前面的通知文字可以随意改。为什么要强调reset因为我发现很多人没有这个习惯。如果你连续在同一个会话里做了三四个不相关的小任务AI的上下文里堆满了旧对话记录。这时候你让它做第五个任务它大概率会参考前面几个任务的模式哪怕那些模式完全不适用。重置成本几乎为零但它能从根本上解决“上下文污染”带来的跑偏问题。3.3 CLAUDE.md的配合使用把行为锚点固化成默认值除了两条命令Claude Code还有一个官方支持的记忆机制——CLAUDE.md。这个文件会被自动加载进会话相当于AI的“默认人格”。很多人用CLAUDE.md的方式是把整个项目说明塞进去这是误区。CLAUDE.md应该只放“行为习惯”和“长期约束”比如- 回答时先给结论再给解释 - 所有涉及修改代码的任务必须先检查项目地图文件 - 不允许读取生产环境配置 - 代码注释使用中文代码提交信息使用英文 - 涉及删除操作之前必须列出影响范围并征求确认为什么建议把行为习惯放CLAUDE.md而把项目地图放cc-load里因为两者刷新频率完全不同。CLAUDE.md是全局的、长期稳定的适合放那些“永远成立”的东西项目地图是易变的项目重构一次就要更新一次适合按需加载。如果你把地图塞进CLAUDE.md每次启动会话它都会自动加载哪怕你只是过去写个README这些Token也照烧不误。更合理的方式是让CLAUDE.md只承担“引导AI去找地图”的角色地图本身留给cc-load按需注入。4. 实测效果改造前后的Tokens消耗对比方法讲完必须看点实证。否则你很难相信这两条Prompt和两条命令的组合能在真实项目里带来多大差异。4.1 改造前的经典翻车现场我之前在一个中型后端项目上做过一次记录。任务内容是给订单模块的“创建订单”接口加一个失败重试逻辑最多重试三次。这是一个应该几分钟搞定的活但由于当时项目仓库里文件很多AI不知道订单逻辑的具体位置于是上演了完整的“烧钱式找路”第一轮搜索“create_order”返回了6个文件路径。第二轮逐一读取前两个文件发现只有引用没有实现。第三轮换关键词搜“order”加载了很多无关的订单展示代码。第四轮终于定位到src/core/payment.py但此时上下文里已经混入了无关代码片段。拖到最后AI开始犹豫要不要看下测试文件确认行为是不是还有别的实现按我当时的粗略估算整个定位过程消耗了大约4.5万Token工具调用接近20次。更麻烦的是由于上下文里塞了很多无关文件AI最后的实现方案里出现了一个多余的判断分支——“因为我在order模块里看到一个类似的状态字段”实际上那个字段和本次任务毫无关系。4.2 改造后同样的任务走了另一条路后来我把项目地图维护好用cc-load启动会话然后附带任务边界条款。同一个任务同样的仓库AI的行为路径完全不同。它拿到项目地图后直接定位到src/core/payment.py没有再搜索任何其他文件。因为它知道所有订单相关的逻辑都在这个文件里也知道测试目录是只读的不需要“顺手看看”。整个任务只经历了三次核心动作读取目标文件、修改函数、输出diff摘要。我同样做了记录Token消耗大约1.2万工具调用3到4次。两者的差距不是一点半点。我把这个对比整理成一张表你可以直观感受一下对比维度改造前改造后工具调用次数约18次3至4次定位阶段Token消耗约4.5万约1.2万是否出现无关文件污染是否生成代码的准确性出现多余分支与需求一致平均任务耗时约8分钟约2分钟这个数据不是实验室里造出来的理想值而是我几次项目中截取的典型样本。核心差距就来源一件事AI到底是把Token花在“找路”上还是花在“编码”上。4.3 收益最大的三类场景这套方案在所有场景下都有效但收益最大的是下面三类。你可以评估一下自己的使用场景是否在其中。第一类大型仓库的早期探索。新加入一个项目时你对结构还不熟AI也一样。如果你上来就让它干一个具体任务它只能靠搜索猜路径。提前写好项目地图等于把你摸索的过程一次性固化下来后面所有人都能受益。第二类多文件重构任务。重构的难点在于“影响范围控制”。没有边界条款时AI重构完目标模块还可能顺手把依赖它的几个文件一起改了结果就是diff大得吓人。有了“不得改动其他文件”的约束它就只能规规矩矩干活。第三类批量流水线式的小任务。比如连续修五个小bug这种场景最容易被上下文污染坑。如果你每修一个bug就cc-reset一次每个bug都会在干净上下文里开工不会带上之前bug的残留信息。虽然多了一个写命令的动作但每个任务的Token消耗反而更少。5. 常见问题与排查技巧方案讲了效果也看了。接下来是这几天我被问到最多的问题以及我自己排查时的经验。5.1 Prompt注入了但AI还是乱Grep怎么办这是最让人崩溃的情况地图喂了边界划了AI还是到处搜。遇到这种问题先别急着骂AI按下面三个方向排查。第一检查CLAUDE.md里有没有互相冲突的指令。如果CLAUDE.md写着“遇到不清楚的信息时先去搜索确认”那它当然会触发Grep。全局指令的优先级往往会压过单次Prompt里的建议因为它是长期的“人格设定”。第二确认Prompt有没有被上下文截断。如果项目地图写得太长超过了某个阈值后半段的边界条款可能根本没有被AI看到。所以我在前面强调地图文件只写关键路径不写解释性长文。越精简越不容易被截断。第三检查任务描述是否模糊。如果你在边界条款里写“处理订单模块”AI仍然有权自己决定“处理”到底是什么意思。更合理的写法是“修改src/core/payment.py的create_order函数”路径明确到文件级它就没有搜索的空间了。5.2 项目地图本身太大怎么办几十个模块都写进地图地图文件本身就会变成一大坨加载进去反而烧Token。我的解法是分两级总地图只放目录骨架也就是一级模块名和一句话职责每个核心模块的细节放到单独的子地图文件里等需要动手处理某个模块时再人工粘贴或按需加载。举个例子总地图里写“src/core/payment.py——支付处理负责订单创建与支付回调”这就够了。等真正开始改支付模块的代码时我再把payment.py的内部结构描述通过追加Prompt传进去。这样地图既可用又不会词不达意。5.3 什么时候该用cc-reset我自己的判断标准有三个。一是对话开始出现明显的重复确认AI反复问“你刚才说的是不是这个文件”说明上下文里已经堆了太多旧讨论。二是AI开始引用早期对话中的内容作为当前决策依据比如“根据刚才讨论的日志方案这里也这么做”——如果当前任务和“刚才讨论”已经不是一回事这就是污染信号。三是任务领域发生了切换比如刚改完前端样式马上要写后端接口这时候毫不犹豫reset各干各的。5.4 两条命令的最佳实践组合最后给一套我每天早上开工时的固定流程。到项目目录执行cc-load把地图喂进去第一个任务做完后检查输出、确认diff然后cc-reset第二个任务如果不是同一模块依然是cc-reset后重来。这样一天下来每一个任务都从干净起点开始AI不会把上一个任务的行为模式带进下一个任务Token消耗也更可预测。这套流程跑顺之后我最大的感受是Claude Code不是用不起前提是你得管理它的上下文而不是让它自己乱逛。2条Prompt负责约束行为2条命令负责管理状态搭配起来AI就真的能按你所想埋头苦编绝不越界。 
长河君 · 2026/10/13 18:02:14 · 阅读 1.2k Claude Code烧Token？2条Prompt+2条命令管好上下文
如果你用Claude Code写过几天代码大概率经历过这么一幕你让它改一个模块的日志格式它没直接动手而是先Grep全仓库搜“logger”读了一堆无关的配置文件翻了半天又问“我找到了三个日志实现你指的是哪个”。等你回答完上下文窗口里已经被塞了无数文件片段Token预算烧掉几万代码却一行没碰。这个问题在大型仓库里会被无限放大。Claude Code确实能自己“找路”但找路的代价是工具调用次数爆炸、上下文被无关内容挤占、重要信息被截断最后AI开始答非所问甚至擅自改到别的模块。我在实际项目里踩过这个坑之后总结出一套组合打法2条Prompt 2条命令。思路很简单——强制你喂给AI什么它就只看什么禁止它碰什么它就绝不越界。这篇文章把完整配置、背后的原因、以及实测对比全部展开适合那些已经在用Claude Code、但觉得Token消耗太快、任务经常跑偏的开发者参考。1. 项目概述为什么Claude Code总在“烧钱式找路”先说结论Claude Code不是笨而是它默认的策略就是“先探索再回答”。当你提出一个任务它手里没有项目地图唯一的办法就是调用各种工具去猜——Grep搜关键词、读文件、看目录结构、再试错。这套流程在小型demo里没问题但放到一个几千文件的工程里探索成本是灾难级的。1.1 乱Grep的代价Tokens是怎么悄悄烧光的要理解“烧Token”的本质先要看清一次工具调用到底花了多少钱。以Grep为例每次调用AI要生成工具名和参数这是基础开销工具返回匹配结果时每一行命中内容都要进入上下文窗口如果匹配到一个200行的大函数片段这段代码就直接吃掉几百上千Token。AI看了结果后还要“理解”这又是一轮生成。一次看起来不起眼的搜索实际开销经常是几千Token。更可怕的是这种搜索不是一次就结束。AI会先Grep一次确认位置读文件确认内容发现不对再换关键词Grep再读下一个文件。我观察过几次翻车现场一个“改日志格式”的需求AI前前后后做了近20次工具调用消耗的Token足够写好几版代码。这还没算上最隐蔽的损失——早期读进来的关键信息因为上下文满了被系统截断。打个比方这就像你请了个能力很强但完全不认路的实习生。他干活的热情没得说问题是他每次都先把整栋楼翻一遍才肯动手。你烧的是时间在Claude Code这里烧的是Token。所以省钱的核心不是少用AI而是不让它干那些本可以由你一次性交代清楚的事情。1.2 所谓“无限上下文”其实是精准上下文标题里说的“无限上下文”严格来讲不是技术上的无限而是让你把AI的上下文全部用在刀刃上。上下文窗口是有限的但如果你能让AI不用花Token去探索、不用反复试错、不用读无关文件那么有限的窗口对你来说就像无限一样——因为它只装着和当前任务相关的信息。我把它拆成三步形成一个闭环预置地图把项目结构、关键路径、命名规范、禁区说明一次性打包喂给AI。它不用猜不用搜。划定边界明确告诉它能动什么、不能动什么从源头上掐断“随手改别的文件”的冲动。按需注入需要某个模块的细节时再补充绝不一次性把所有代码都塞进去。这套组合下来AI的上下文窗口里全是有效信息而不是搜索过程中产生的“思考垃圾”。它不是知道了更多而是浪费得更少。1.3 两条命令的设计思路加载与清场2条命令解决的是“怎么把上述思路变成肌肉记忆”。如果每次开新任务都要手打一段长Prompt你大概率用两次就放弃了。所以我把最常用的两个动作做成了shell函数。cc-load一键把当前项目的“项目地图”喂给Claude附带你要开工的初始任务。它的作用是“加载”让AI从第一句话开始就处于有地图的状态。cc-reset一键结束当前会话、清掉上下文开启一个干净的新会话。它的作用是“清场”防止上一个任务的残留信息污染下一个任务。为什么一定要有reset因为Claude Code的上下文是连续累积的。连续做三四个任务之后早期对话内容、旧文件内容、中间的一些无关讨论都在窗口里占着位置。你下一个任务可能和它们毫无关系但AI还是会参考这些残留信息导致“跑偏”的概率直线上升。reset就是翻篇一张干净的白纸永远比涂满旧字迹的纸好写。2. 两条Prompt先和AI“约法三章”很多人用Claude Code的时候Prompt写得太随意——“帮我改一下订单逻辑”这种话扔出去AI当然只能靠猜。它猜的过程就是你烧Token的过程。下面这两条Prompt是经过我多轮调整后沉淀下来的版本一个管“认识项目”一个管“干活边界”。2.1 Prompt 1项目宪法——一次性把地图塞进上下文这条Prompt的作用是让AI在动手前就掌握它需要的全部背景信息。我的建议是第一次使用某个项目时把它当成一个模板去填充之后所有会话都复用同一份内容。标准格式如下请把以下内容作为本次工作的【项目地图】所有任务优先基于该地图行动 - 项目根目录/Users/dev/app - 核心模块 - src/core/auth.py 用户认证与登录逻辑 - src/core/payment.py 支付处理允许改动 - src/utils/logger.py 统一日志封装禁止修改 - 命名规范函数使用snake_case常量使用UPPER_SNAKE_CASE - 环境配置本地使用config/dev.yaml禁止读取生产配置 - 禁止区域tests/ 目录只读不修改vendor/ 忽略 如果地图信息与代码实际不符请停下来说明差异不要自行猜测。这里有几个关键设计。第一给绝对路径不给描述性路径。很多AI跑偏是因为它以为自己知道“日志模块”在哪结果是另一个同名文件。你直接告诉它src/utils/logger.py它就不需要Grep了。第二明确“禁止区域”。这一点比告诉它能做什么更重要。AI的默认行为是尽可能完成任务所以它会倾向于改动任何它认为相关的文件。你如果不说“tests/目录只读”它可能在改业务逻辑的同时顺手改坏一个测试文件。这个边界必须写死。第三强制校验机制。我加了一句“如果地图信息与代码实际不符请停下来说明差异”。这一句看着简单实战里能救你很多次。因为项目是演化中的地图可能过期。与其让AI带着错误地图乱来不如让它停下来问你。2.2 Prompt 2任务边界条款——让它埋头苦编不越界如果说Prompt 1解决的是“认路”Prompt 2解决的就是“守规矩”。每次具体任务开工前我都会在项目地图后直接接上任务边界条款。模板如下本次任务范围 1. 只修改 src/core/payment.py 中 create_order 函数 2. 为它补充失败重试逻辑最多重试3次 3. 不得改动其他函数、其他文件 4. 不得引入新的第三方依赖 5. 不执行测试、不改动测试用例只输出代码变更说明 验收标准 - 代码可编译逻辑符合注释中的业务规则 - 输出变更diff摘要不超过200字 边界以外的一切工作请直接拒绝或告知需要额外授权。先说清楚为什么需要一个单独的“任务边界”Prompt省事的人可能会把边界直接写进项目地图但效果并不好。项目地图是长期存在的它描述的是项目“是什么”而任务边界是临时的它定义的是这一次“要干什么、不能干什么”。混在一起会让AI混淆信息的优先级它做事的时候不知道哪些是全局规则、哪些是当前任务的限制。关于越界。我见过三种最常见的翻车方式一是擅自加依赖用到一个功能就pip install一个新库二是顺手重构明明让你改一个函数它“好心”把整个模块的风格统一了三是扩大修改面改A文件的bug时顺手“修正”了B文件类似的问题。对付这三种情况最有效的措辞不是“不要乱改”而是把这些行为一条条列出来点名“不得改动其他文件”“不得引入新依赖”。AI对于明确的禁令执行得很好但对模糊的“注意分寸”执行得很差。验收标准也别省。让AI每轮任务结束输出一段200字以内的diff摘要一方面方便你检查它有没有越界另一方面也能避免它罗里吧嗦地给一堆报告白白烧掉生成Token。2.3 Prompt写作的两条心法讲完模板再说说那些模板背后的通用心法你以后写自己的版本时用得上。心法一写路径不写描述。举个例子与其说“修改用户认证模块”不如直接说“修改src/core/auth.py”。倒不是说Claude Code理解不了“用户认证模块”而是这种描述会触发它的搜索行为——它得先确认哪个文件是认证模块。路径是确定性信息描述是概率性信息。你给路径它零成本开工你给描述它需要烧Token来验证猜测。心法二否定列表比肯定列表更有效。只告诉AI“你可以改payment.py”它仍然可能基于“让代码更好”的逻辑去动其他文件。但如果你同时列出“不要碰tests/、不要碰config/、不要动logger.py”它的行为边界就清晰得多。AI本质上是一个大模型它对“能做什么”有很强的主动性对“不能做什么”的约束反而记得更牢。原因很简单明确的禁止项在语义上更突出相当于经营上的“高压线”而肯定列表只是“允许区”。3. 两条命令把Prompt变成一键执行Prompt写得再好每次手打一遍也不现实。真正的爽点是把它们固化成一键执行的命令。下面这套配置是我在自己环境里跑的你可以直接抄也可以按自己习惯改名。3.1 命令一cc-load——把项目地图喂进新会话我把每个项目的“项目地图”存成一个独立Markdown文件放在~/.cc-maps/目录下文件名和项目根目录同名。这样任何项目都能复用同一套加载逻辑。对应的shell函数长这样# 一键加载当前项目的项目地图并启动新会话 cc-load() { local map_file$HOME/.cc-maps/$(basename $(pwd)).md if [ ! -f $map_file ]; then echo 未找到地图文件$map_file echo 请先创建可参考以下模板 echo - 项目根目录 echo - 核心模块与绝对路径 echo - 命名规范与禁止区域 return 1 fi { echo 【项目地图已加载】 cat $map_file echo echo 请基于以上地图开始工作。 } | claude }这段脚本的逻辑很简单切到项目目录后执行cc-load它会自动去~/.cc-maps/目录下找同名地图文件然后拼接成一段初始Prompt交给claude命令启动新会话。这样你每次开任务第一句话就已经带着完整地图AI不需要从零开始探索。我在实际使用中的两个调整建议。第一个地图文件也要维护。项目结构一变地图文件就得跟着更新。我自己的习惯是每两周花五分钟检查一遍把新增的核心模块标记进去删掉已经废弃的路径。这个维护成本很低但如果放任不管地图过期后AI会被误导反而不如没有地图。第二个如果你用的是已有会话而不是新会话可以改成把内容复制到剪贴板。我再补一个别名遇到“不重启会话、只注入地图”的场景直接用alias cc-load-pastecat $HOME/.cc-maps/$(basename $(pwd)).md | pbcopy echo 地图已复制到剪贴板直接粘贴到会话中即可pbcopy是macOS的命令Linux环境可以换成xclip -selection clipboard。这样即使不走命令行启动也能手动完成注入。3.2 命令二cc-reset——切断上下文防污染cc-reset的设计目标是一键结束当前会话状态回到一个干净的起点。有人可能会问直接退出终端再重开不行吗行但如果做成了命令你就不用每次手动清理一堆临时状态了。# 重置当前会话开启干净的新会话 cc-reset() { echo 当前会话上下文即将清理开始新会话... # 根据你使用的终端工具清掉当前进程并重启 claude }这里有一点要说明不同版本的Claude Code、不同的终端环境具体重置指令会有一点差异。这个函数的核心目的是把你“手动关掉旧会话、再手动开新会话”的两个动作压缩成一个。你只需要保留“新会话启动”这句前面的通知文字可以随意改。为什么要强调reset因为我发现很多人没有这个习惯。如果你连续在同一个会话里做了三四个不相关的小任务AI的上下文里堆满了旧对话记录。这时候你让它做第五个任务它大概率会参考前面几个任务的模式哪怕那些模式完全不适用。重置成本几乎为零但它能从根本上解决“上下文污染”带来的跑偏问题。3.3 CLAUDE.md的配合使用把行为锚点固化成默认值除了两条命令Claude Code还有一个官方支持的记忆机制——CLAUDE.md。这个文件会被自动加载进会话相当于AI的“默认人格”。很多人用CLAUDE.md的方式是把整个项目说明塞进去这是误区。CLAUDE.md应该只放“行为习惯”和“长期约束”比如- 回答时先给结论再给解释 - 所有涉及修改代码的任务必须先检查项目地图文件 - 不允许读取生产环境配置 - 代码注释使用中文代码提交信息使用英文 - 涉及删除操作之前必须列出影响范围并征求确认为什么建议把行为习惯放CLAUDE.md而把项目地图放cc-load里因为两者刷新频率完全不同。CLAUDE.md是全局的、长期稳定的适合放那些“永远成立”的东西项目地图是易变的项目重构一次就要更新一次适合按需加载。如果你把地图塞进CLAUDE.md每次启动会话它都会自动加载哪怕你只是过去写个README这些Token也照烧不误。更合理的方式是让CLAUDE.md只承担“引导AI去找地图”的角色地图本身留给cc-load按需注入。4. 实测效果改造前后的Tokens消耗对比方法讲完必须看点实证。否则你很难相信这两条Prompt和两条命令的组合能在真实项目里带来多大差异。4.1 改造前的经典翻车现场我之前在一个中型后端项目上做过一次记录。任务内容是给订单模块的“创建订单”接口加一个失败重试逻辑最多重试三次。这是一个应该几分钟搞定的活但由于当时项目仓库里文件很多AI不知道订单逻辑的具体位置于是上演了完整的“烧钱式找路”第一轮搜索“create_order”返回了6个文件路径。第二轮逐一读取前两个文件发现只有引用没有实现。第三轮换关键词搜“order”加载了很多无关的订单展示代码。第四轮终于定位到src/core/payment.py但此时上下文里已经混入了无关代码片段。拖到最后AI开始犹豫要不要看下测试文件确认行为是不是还有别的实现按我当时的粗略估算整个定位过程消耗了大约4.5万Token工具调用接近20次。更麻烦的是由于上下文里塞了很多无关文件AI最后的实现方案里出现了一个多余的判断分支——“因为我在order模块里看到一个类似的状态字段”实际上那个字段和本次任务毫无关系。4.2 改造后同样的任务走了另一条路后来我把项目地图维护好用cc-load启动会话然后附带任务边界条款。同一个任务同样的仓库AI的行为路径完全不同。它拿到项目地图后直接定位到src/core/payment.py没有再搜索任何其他文件。因为它知道所有订单相关的逻辑都在这个文件里也知道测试目录是只读的不需要“顺手看看”。整个任务只经历了三次核心动作读取目标文件、修改函数、输出diff摘要。我同样做了记录Token消耗大约1.2万工具调用3到4次。两者的差距不是一点半点。我把这个对比整理成一张表你可以直观感受一下对比维度改造前改造后工具调用次数约18次3至4次定位阶段Token消耗约4.5万约1.2万是否出现无关文件污染是否生成代码的准确性出现多余分支与需求一致平均任务耗时约8分钟约2分钟这个数据不是实验室里造出来的理想值而是我几次项目中截取的典型样本。核心差距就来源一件事AI到底是把Token花在“找路”上还是花在“编码”上。4.3 收益最大的三类场景这套方案在所有场景下都有效但收益最大的是下面三类。你可以评估一下自己的使用场景是否在其中。第一类大型仓库的早期探索。新加入一个项目时你对结构还不熟AI也一样。如果你上来就让它干一个具体任务它只能靠搜索猜路径。提前写好项目地图等于把你摸索的过程一次性固化下来后面所有人都能受益。第二类多文件重构任务。重构的难点在于“影响范围控制”。没有边界条款时AI重构完目标模块还可能顺手把依赖它的几个文件一起改了结果就是diff大得吓人。有了“不得改动其他文件”的约束它就只能规规矩矩干活。第三类批量流水线式的小任务。比如连续修五个小bug这种场景最容易被上下文污染坑。如果你每修一个bug就cc-reset一次每个bug都会在干净上下文里开工不会带上之前bug的残留信息。虽然多了一个写命令的动作但每个任务的Token消耗反而更少。5. 常见问题与排查技巧方案讲了效果也看了。接下来是这几天我被问到最多的问题以及我自己排查时的经验。5.1 Prompt注入了但AI还是乱Grep怎么办这是最让人崩溃的情况地图喂了边界划了AI还是到处搜。遇到这种问题先别急着骂AI按下面三个方向排查。第一检查CLAUDE.md里有没有互相冲突的指令。如果CLAUDE.md写着“遇到不清楚的信息时先去搜索确认”那它当然会触发Grep。全局指令的优先级往往会压过单次Prompt里的建议因为它是长期的“人格设定”。第二确认Prompt有没有被上下文截断。如果项目地图写得太长超过了某个阈值后半段的边界条款可能根本没有被AI看到。所以我在前面强调地图文件只写关键路径不写解释性长文。越精简越不容易被截断。第三检查任务描述是否模糊。如果你在边界条款里写“处理订单模块”AI仍然有权自己决定“处理”到底是什么意思。更合理的写法是“修改src/core/payment.py的create_order函数”路径明确到文件级它就没有搜索的空间了。5.2 项目地图本身太大怎么办几十个模块都写进地图地图文件本身就会变成一大坨加载进去反而烧Token。我的解法是分两级总地图只放目录骨架也就是一级模块名和一句话职责每个核心模块的细节放到单独的子地图文件里等需要动手处理某个模块时再人工粘贴或按需加载。举个例子总地图里写“src/core/payment.py——支付处理负责订单创建与支付回调”这就够了。等真正开始改支付模块的代码时我再把payment.py的内部结构描述通过追加Prompt传进去。这样地图既可用又不会词不达意。5.3 什么时候该用cc-reset我自己的判断标准有三个。一是对话开始出现明显的重复确认AI反复问“你刚才说的是不是这个文件”说明上下文里已经堆了太多旧讨论。二是AI开始引用早期对话中的内容作为当前决策依据比如“根据刚才讨论的日志方案这里也这么做”——如果当前任务和“刚才讨论”已经不是一回事这就是污染信号。三是任务领域发生了切换比如刚改完前端样式马上要写后端接口这时候毫不犹豫reset各干各的。5.4 两条命令的最佳实践组合最后给一套我每天早上开工时的固定流程。到项目目录执行cc-load把地图喂进去第一个任务做完后检查输出、确认diff然后cc-reset第二个任务如果不是同一模块依然是cc-reset后重来。这样一天下来每一个任务都从干净起点开始AI不会把上一个任务的行为模式带进下一个任务Token消耗也更可预测。这套流程跑顺之后我最大的感受是Claude Code不是用不起前提是你得管理它的上下文而不是让它自己乱逛。2条Prompt负责约束行为2条命令负责管理状态搭配起来AI就真的能按你所想埋头苦编绝不越界。