企业官网建设流程全解析

1. 从两条Prompt到两条命令：这套工作流到底在解决什么

如果你用Claude Code写过稍微大一点的项目，大概率经历过这种场景：你让它改一个登录模块的校验逻辑，它上来先grep -r "login" .，然后grep -r "auth" .，再grep -r "validate" .，一轮下来上下文里塞满了各种无关文件的片段，真正要改的那个文件反而被挤到了边缘。更糟的是，等你让它动手改代码时，它已经"忘了"你最初的需求，开始自由发挥，改了一堆你没让它碰的地方。

这个问题的根源不在于模型能力，而在于上下文管理策略。Claude Code默认的探索行为是"广撒网"式的——它不确定你的项目结构，所以用Grep去试探。每次Grep的结果都会占用Token预算，而这些Token本可以用来装真正的业务逻辑。当上下文被搜索噪音填满后，模型对"当前任务边界"的感知就会模糊，越界修改、重复劳动、Token浪费就全来了。

我试过很多方案：手动在Prompt里写死文件路径、用.claudeignore排除目录、甚至每次对话前先喂一遍项目结构说明。这些方法有效，但都不够"自动化"——你总得记得做某件事，一旦忘了，Claude Code就又开始乱Grep。

直到我把整个流程压缩成两条Prompt + 两条命令，才算真正找到了一个稳定的平衡点。这套方案的核心思路是：用两条Prompt建立"项目地图"和"任务边界"，用两条命令实现"精准定位"和"上下文注入"。它不依赖任何外部工具，不需要改Claude Code的源码，纯粹靠对话策略和Shell命令的组合，就能让Claude Code在大多数场景下"按你所想埋头苦编，绝不越界"。

适合谁来参考？如果你满足以下任意一条，这套方法应该能帮到你：

• 项目文件数超过50个，Claude Code经常Grep到无关文件；
• 每次对话都要重复解释项目结构，Token消耗快；
• 遇到过Claude Code"改着改着就跑偏"的情况；
• 想让Claude Code在长任务中保持上下文连贯，而不是每轮都重新探索。

下面我会把这套方案拆成四个部分：先讲清楚"项目地图"和"任务边界"这两条Prompt的设计逻辑，再讲两条命令的具体实现和参数含义，然后是实测中遇到的坑和调整方法，最后分享几个进阶用法和边界情况处理。

2. 第一条Prompt：让Claude Code先"看懂地图"再动手

2.1 为什么默认的Grep策略会失控

Claude Code在接到任务时，第一反应是"我需要知道这个项目长什么样"。它的默认策略是：用Grep搜索关键词，根据返回的文件路径和片段来推断项目结构。这个策略在小项目里没问题，但在中大型项目里会迅速失控。

原因有三层。第一层是搜索结果的噪音比。你搜一个"user"，可能返回几十个文件，其中只有三五个是真正相关的。Claude Code会把所有结果都读进上下文，因为它无法提前判断哪个相关。第二层是上下文的挤出效应。Claude Code的上下文窗口是有限的，搜索片段占得越多，真正需要修改的代码和你的需求描述占得就越少。第三层是任务边界的模糊化。当模型看到大量"可能相关"的文件时，它会倾向于"都改一点"，而不是"只改该改的"。

我做过一个粗略统计：在一个约200个文件的项目里，让Claude Code改一个API的返回格式，它平均会执行6到8次Grep，读取约15到20个文件的片段，其中真正需要修改的只有2到3个文件。也就是说，超过80%的搜索Token是浪费的。

2.2 项目地图Prompt的完整写法与逐句拆解

第一条Prompt的目标是：在任务开始前，先让Claude Code建立一份"项目地图"，知道哪些目录是核心、哪些是辅助、哪些是禁区。这份地图一旦建立，后续的Grep就会有的放矢。

我的写法是这样的：

在开始任何任务之前，请先阅读项目根目录下的 PROJECT_MAP.md 文件。 该文件描述了项目的目录结构、核心模块、数据流向和禁区目录。 在后续所有操作中，请遵循以下规则： 1. 只在你确认属于当前任务范围的目录内进行搜索和修改； 2. 如果任务涉及的文件不在 PROJECT_MAP.md 中，先向我确认，不要自行扩大搜索范围； 3. 禁止对 node_modules、dist、build、.git、coverage 等目录执行任何搜索操作； 4. 每次搜索前，先用一句话说明你要搜什么、为什么搜、预期在哪个目录找到。

这段Prompt的关键在于把"探索"变成"确认"。默认情况下，Claude Code是"先搜了再说"；这段Prompt要求它"先说明再搜"。这个小小的顺序调整，能显著减少无效Grep——因为当模型需要先解释"为什么搜"时，它会更谨慎地选择搜索词和范围。

PROJECT_MAP.md的内容不需要很复杂，我通常用这样的结构：

# 项目地图 ## 核心目录 - src/api/：所有HTTP接口定义，每个文件对应一个业务域 - src/services/：业务逻辑层，与api目录一一对应 - src/models/：数据模型和数据库schema - src/utils/：通用工具函数，修改需谨慎 ## 辅助目录 - tests/：测试文件，命名规则为 *.test.ts - docs/：文档，不参与构建 - scripts/：构建和部署脚本 ## 禁区 - node_modules/、dist/、build/、.git/、coverage/ - src/legacy/：旧版代码，正在逐步废弃，非必要不修改 ## 数据流向 请求 -> api/ -> services/ -> models/ -> 数据库

这份地图我一般花10分钟写一次，之后每次新任务只需要在Prompt里引用它。实测下来，Claude Code的无效Grep次数能减少60%以上。

2.3 地图文件该放什么、不该放什么

这里有个容易踩的坑：很多人会把PROJECT_MAP.md写成一份详细的开发文档，结果文件本身就有几千字，每次读它反而消耗了大量Token。我的经验是，地图文件控制在200行以内，只写"结构"和"边界"，不写"实现细节"。

具体来说，该放的是：目录职责、模块对应关系、禁区列表、命名约定。不该放的是：具体函数的签名、数据库字段说明、业务规则细节。后者应该在你真正需要修改某个模块时，再单独读取对应文件。

另一个坑是地图文件的位置。我试过放在docs/下，结果Claude Code有时候会"忘记"去读。后来改成放在项目根目录，并在Prompt里写死路径，就稳定多了。根目录的文件在Claude Code的默认视野里优先级更高，不容易被忽略。

2.4 实测效果：Grep次数从8次降到2次

在一个约150个文件的项目里，我用同一个任务做了对比测试：任务是"修改用户注册接口的邮箱校验规则，从只检查格式改为同时检查是否已存在"。

不用地图Prompt时，Claude Code的执行路径是：Grep "register" -> Grep "email" -> Grep "validate" -> 读取5个文件片段 -> 开始修改。总共8次Grep，读取了约12个文件。

用了地图Prompt后，执行路径变成：读取PROJECT_MAP.md -> 确认任务涉及src/api/user.ts和src/services/userService.ts-> 只读取这两个文件 -> 开始修改。总共2次文件读取，0次无效Grep。

Token消耗从约45000降到了约12000，而且修改的精准度明显提升——没有出现"顺手改了别的接口"的情况。

3. 第二条Prompt：把"任务边界"钉死在对话里

3.1 任务边界模糊是越界修改的根源

第一条Prompt解决了"项目结构"的问题，但还有一个更隐蔽的问题：任务边界。即使Claude Code知道项目结构，它仍然可能"过度解读"你的需求。比如你说"优化一下这个函数的性能"，它可能不仅优化了函数本身，还顺手改了调用方、调整了数据结构、甚至重构了相关模块。

这不是模型"不听话"，而是它对"优化"这个词的理解比你宽泛。在它看来，任何能提升性能的改动都算"优化"，但在你看来，只有那个函数的改动才算。

第二条Prompt的目标就是：在任务开始时，把"做什么"和"不做什么"都写清楚，并且要求Claude Code在每次修改前确认是否在边界内。

3.2 边界声明Prompt的模板与参数说明

我的写法是这样的：

当前任务边界如下： - 允许修改：src/services/userService.ts 中的 validateEmail 函数 - 允许读取：src/api/user.ts、src/models/user.ts - 禁止修改：任何其他文件，包括测试文件、配置文件、其他service - 禁止操作：安装依赖、修改package.json、执行数据库迁移 - 如果发现必须修改边界外的文件才能完成任务，先停下来向我说明原因，等我确认后再操作 每次修改前，请用一行说明：你要改哪个文件的哪个部分，为什么这个修改在边界内。

这段Prompt的关键参数有三个：

允许修改列表：这是白名单，必须具体到文件甚至函数级别。不要写"user相关的文件"，要写"src/services/userService.ts 中的 validateEmail 函数"。

禁止操作列表：这是黑名单，用来堵住常见的"顺手操作"。比如安装依赖、修改配置、执行迁移，这些操作一旦发生，影响范围往往超出你的预期。

越界确认机制：这是最重要的部分。它给了Claude Code一个"合法出口"——如果它真的发现边界外有必须改的东西，它可以提出来，而不是偷偷改掉。实测中，这个机制触发过几次，每次都是合理的（比如发现类型定义不匹配），我确认后它才改。

3.3 为什么"禁止操作"比"允许操作"更重要

很多人写Prompt时只写"你要做什么"，不写"你不能做什么"。但在Claude Code的场景里，禁止列表的优先级应该高于允许列表。

原因是：Claude Code的默认行为是"尽可能完成任务"，它会自动寻找各种可能的手段。如果你不明确禁止，它可能会安装一个新依赖来解决问题，或者修改配置文件来绕过某个限制。这些操作在它看来是"合理的"，但对你来说可能是"灾难性的"——比如它装了一个和你现有依赖冲突的包，或者改了一个影响全局的配置。

我踩过最坑的一次是：让Claude Code改一个日期格式化函数，它觉得现有的日期库不好用，直接npm install了一个新的，然后改了package.json。虽然功能是实现了，但整个项目的依赖树变了，CI直接挂了。

从那以后，我的边界Prompt里一定会写死："禁止安装依赖、禁止修改package.json、禁止执行任何npm/yarn/pnpm命令"。

3.4 边界Prompt在长任务中的复用技巧

如果你的任务比较长，需要多轮对话，边界Prompt不能只写一次。我的做法是：每5到6轮对话后，重新贴一次边界Prompt。因为随着对话进行，早期的边界声明会被挤出上下文窗口，Claude Code会逐渐"忘记"边界。

另一个技巧是：把边界Prompt写成一个文件，比如TASK_BOUNDARY.md，每次新任务时更新这个文件，然后在对话里说"请阅读TASK_BOUNDARY.md并严格遵守"。这样比每次手打Prompt更省事，也更不容易漏掉关键条目。

实测中，用了边界Prompt后，越界修改的概率从约30%降到了5%以下。剩下的5%主要是"边界本身没写清楚"导致的，比如我写了"允许修改userService.ts"，但没写"只允许修改validateEmail函数"，结果它改了同一个文件里的其他函数。所以边界的粒度要尽可能细。

4. 第一条命令：精准定位，替代盲目Grep

4.1 用fd+ripgrep组合实现"带路径约束的搜索"

Prompt解决了"要不要搜"的问题，但"怎么搜"仍然可以优化。Claude Code默认用Grep，而Grep的问题是：它会在整个项目里搜，除非你显式指定路径。虽然Prompt里写了禁区，但Claude Code有时候还是会"忘记"。

我的方案是：用一条Shell命令替代Grep，把搜索范围硬编码在命令里。这样即使Claude Code"忘记"了Prompt里的禁区，命令本身也会限制搜索范围。

命令是这样的：

rg --type ts --type js -l "关键词" src/ --glob '!src/legacy/**' --glob '!**/*.test.ts' | head -20

这条命令做了几件事：

• rg是ripgrep，比grep快得多，而且默认尊重.gitignore；
• --type ts --type js限定只搜TypeScript和JavaScript文件；
• -l只输出文件名，不输出匹配内容，减少Token占用；
• src/限定搜索目录，把禁区直接排除在外；
• --glob '!src/legacy/**'和--glob '!**/*.test.ts'进一步排除旧代码和测试文件；
• head -20限制结果数量，防止一次返回太多文件。

这条命令我一般会写成一个脚本，比如scripts/find.sh，然后在Prompt里告诉Claude Code："需要搜索时，执行bash scripts/find.sh 关键词，不要直接用Grep"。

4.2 命令参数逐项拆解与调优建议

--type ts --type js这个参数需要根据你的项目调整。如果是Python项目，改成--type py；如果是Go项目，改成--type go。ripgrep内置了常见语言的类型定义，用rg --type-list可以查看全部。

-l参数很关键。默认的Grep会输出匹配行的内容，这些内容会占用大量Token。而-l只输出文件名，Claude Code拿到文件名后，可以自己决定读哪个文件。这样Token消耗能减少70%以上。

head -20的数值需要根据项目大小调整。项目越大，这个值可以越小。我的经验是：文件数在100以内的项目，用head -30；100到500之间的，用head -20；500以上的，用head -10。目的是让Claude Code先看到最相关的几个文件，而不是被大量结果淹没。

--glob '!**/*.test.ts'这个排除规则也值得展开。测试文件通常包含大量和业务逻辑相似的代码，很容易被搜到，但大多数任务不需要修改测试。排除它们能显著减少噪音。同理，如果你有__mocks__、fixtures、stories等目录，也应该排除。

4.3 把命令封装成Claude Code可调用的"工具"

Claude Code支持通过CLAUDE.md文件定义自定义命令。我通常会在项目根目录的CLAUDE.md里写：

## 可用命令 - `bash scripts/find.sh <关键词>`：在src目录下搜索关键词，返回文件名列表，已排除legacy和测试文件。 - `bash scripts/read.sh <文件路径>`：读取指定文件的内容，已排除禁区目录。

然后在对话里，Claude Code就会优先使用这些命令，而不是默认的Grep。实测中，这个习惯能进一步减少无效搜索——因为命令本身已经做了过滤，Claude Code不需要自己判断哪些目录该搜、哪些不该搜。

4.4 实测对比：Token消耗降低70%的完整数据

我在一个约300个文件的项目里做了对比测试，任务是"找到所有处理用户头像上传的地方"。

不用自定义命令时，Claude Code执行了5次Grep，返回了约40个文件的匹配片段，Token消耗约28000。

用了find.sh后，命令返回了8个文件名，Claude Code读取了其中3个，Token消耗约8000。

降低幅度约71%。而且因为返回的文件名更精准，Claude Code的后续修改也更聚焦，没有出现"改错文件"的情况。

5. 第二条命令：上下文注入，让Claude Code"记住"关键信息

5.1 为什么需要主动注入上下文

即使有了项目地图和边界Prompt，Claude Code在长任务中仍然会"遗忘"。比如你让它改一个函数，改了3轮之后，它可能忘记了最初的约束条件，开始引入新的变量或改变函数签名。

这个问题的本质是：上下文窗口是有限的，早期的信息会被后来的信息挤出。虽然Claude Code有某种形式的"记忆"机制，但它并不总是可靠。

我的解决方案是：用一条命令主动把关键上下文"注入"到对话中。具体来说，就是把当前任务相关的文件内容、约束条件、历史决策打包成一个文本，在每轮对话开始时喂给Claude Code。

5.2 上下文打包命令的写法与文件选择策略

命令是这样的：

{ echo "=== 任务边界 ===" cat TASK_BOUNDARY.md echo "" echo "=== 当前修改的文件 ===" cat src/services/userService.ts echo "" echo "=== 相关类型定义 ===" cat src/models/user.ts } > /tmp/context.md && wc -l /tmp/context.md

这条命令把三部分内容打包成一个文件：任务边界、当前修改的文件、相关类型定义。然后在对话里说："请阅读/tmp/context.md，这是当前任务的完整上下文。"

文件选择策略是关键。我的原则是：只打包"当前任务直接涉及"的文件，不打包"可能相关"的文件。具体来说：

• 必须打包：任务边界文件、当前正在修改的文件、该文件直接依赖的类型定义；
• 可选打包：调用当前文件的入口文件（如果任务涉及接口变更）；
• 不打包：测试文件、文档、配置文件、其他无关模块。

这样打包出来的上下文通常在500到1500行之间，Token消耗可控，而且信息密度高。

5.3 注入时机：什么时候该重新打包

注入时机比打包内容更重要。我的经验是：在以下三个时刻重新打包：

1. 任务开始时：建立初始上下文；
2. 每完成一个子任务后：更新上下文，反映最新的代码状态；
3. 当Claude Code开始"跑偏"时：重新注入，把它拉回来。

第三个时刻最容易被忽略。当你发现Claude Code开始修改边界外的文件，或者重复问你已经回答过的问题时，不要试图用对话把它"劝回来"——直接重新打包上下文，然后说"请以这个上下文为准，继续任务"。实测中，这比反复解释有效得多。

5.4 避免上下文过载：只打包"当前任务直接涉及"的文件

这里有个反直觉的结论：上下文不是越多越好。我试过把整个src/目录打包进去，结果Claude Code反而更迷茫了——因为信息太多，它无法判断哪些是重点。

后来我改成只打包3到5个文件，效果反而更好。原因是：有限的上下文迫使Claude Code聚焦在当前任务上，而不是"顺便看看别的"。

具体操作上，我会在打包命令里加一个wc -l，如果行数超过2000，就说明打包太多了，需要精简。精简的方法是：只保留当前修改的函数及其直接依赖，把其他部分用注释省略。

# 精简版打包：只保留关键函数 sed -n '/function validateEmail/,/^}/p' src/services/userService.ts > /tmp/context.md

这样打包出来的上下文可能只有几十行，但包含了最核心的信息。

6. 实测中的坑：这套方案不是万能的

6.1 地图文件过期导致的"幽灵路径"

PROJECT_MAP.md最大的问题是过期。项目结构变了，地图没更新，Claude Code就会按照旧地图去搜索，结果找不到文件，或者找到错误的文件。

我踩过一次坑：把src/utils/重构成了src/shared/，但忘了更新地图。结果Claude Code在src/utils/下搜了半天，最后告诉我"找不到相关文件"。我还以为是它能力问题，后来才发现是地图过期了。

解决方案有两个：一是把地图更新纳入代码审查流程，每次目录变更时同步更新；二是在地图文件里加一个"最后更新时间"字段，如果超过30天，就在Prompt里提醒Claude Code"地图可能过期，请先确认目录结构"。

6.2 边界Prompt被"忽略"的几种情况

边界Prompt不是100%有效的。我遇到过几种它被"忽略"的情况：

情况一：任务描述本身有歧义。比如我说"优化这个函数"，边界里写"只允许修改validateEmail"，但Claude Code认为"优化"需要改调用方，于是它改了调用方。这种情况下，问题不在边界Prompt，而在任务描述。解决方案是把任务描述也写具体："只修改validateEmail函数的内部实现，不改变函数签名，不修改调用方"。

情况二：对话轮次太多。超过10轮对话后，早期的边界Prompt会被挤出上下文。解决方案就是前面说的，每5到6轮重新贴一次。

情况三：Claude Code发现了"必须越界"的理由。比如它发现类型定义不匹配，不改类型定义就无法完成任务。这种情况下，它会触发"越界确认机制"，停下来问我。这是预期行为，不是bug。

6.3 命令封装后的调试方法

把Grep封装成find.sh后，调试变得稍微麻烦了一点——因为你看不到Claude Code到底搜了什么。我的做法是：在find.sh里加一行日志，把搜索关键词和结果数量写到/tmp/find.log。

#!/bin/bash echo "$(date): 搜索关键词=$1" >> /tmp/find.log rg --type ts --type js -l "$1" src/ --glob '!src/legacy/**' --glob '!**/*.test.ts' | head -20 | tee -a /tmp/find.log

这样当Claude Code说"找不到文件"时，我可以查看日志，确认是搜索词不对，还是范围太窄，还是文件真的不存在。

6.4 什么时候该放弃这套方案，直接用默认模式

这套方案不是万能的。在以下场景里，我建议直接用Claude Code的默认模式：

• 项目很小（少于20个文件）：默认Grep足够快，封装反而增加复杂度；
• 探索性任务：比如"帮我看看这个项目里有没有安全隐患"，这种任务需要广泛搜索，边界Prompt反而会限制它；
• 一次性任务：只改一个文件的一行代码，不值得花时间写地图和边界。

我的判断标准是：如果任务预计需要超过3轮对话，或者涉及超过2个文件，就用这套方案；否则直接用默认模式。

7. 进阶：把这套流程固化成团队规范

7.1 把PROJECT_MAP.md纳入代码审查

如果团队里多个人用Claude Code，PROJECT_MAP.md应该像代码一样被审查。具体做法是：在PR模板里加一条检查项："如果本次PR涉及目录结构变更，是否更新了PROJECT_MAP.md？"

这样能保证地图始终是最新的，不会出现"幽灵路径"的问题。

7.2 边界Prompt的团队模板化

每个项目的边界Prompt可能不同，但结构可以统一。我通常会在团队里维护一个TASK_BOUNDARY_TEMPLATE.md，包含以下字段：

## 任务边界模板 - 任务名称： - 允许修改的文件： - 允许读取的文件： - 禁止修改的文件： - 禁止操作： - 越界确认方式：

每次新任务时，复制这个模板，填写具体内容，保存为TASK_BOUNDARY.md。这样既保证了边界声明的完整性，又减少了每次手打的时间。

7.3 命令脚本的版本管理与共享

find.sh和read.sh这类脚本应该纳入版本管理，放在scripts/claude/目录下。这样团队成员可以共享同一套命令，避免每个人重复造轮子。

脚本的更新也应该走PR流程。比如你发现某个排除规则需要调整，就提一个PR，说明调整原因和实测效果，然后合并。这样脚本会随着项目演进而不断优化。

7.4 新成员上手：从"抄作业"到"改作业"

新成员加入时，不要让他们从零开始写地图和边界。我的做法是：先让他们用现有的PROJECT_MAP.md和TASK_BOUNDARY_TEMPLATE.md跑一个简单任务，感受一下效果。然后让他们尝试修改地图或边界，看看改动对Claude Code行为的影响。

这个过程通常需要2到3个任务。之后他们就能根据自己的习惯调整这套方案了。关键是先让他们体验到"有边界"和"没边界"的差异，这样他们才会有动力去维护这套规范。

8. 几个容易被忽略的细节

8.1 地图文件的编码和换行符问题

PROJECT_MAP.md如果包含中文，要确保用UTF-8编码。我遇到过因为编码问题导致Claude Code读出来是乱码的情况。另外，Windows和Unix的换行符差异也可能导致解析问题，建议统一用LF。

8.2 命令脚本的权限和路径问题

find.sh和read.sh需要可执行权限。在Unix系统上，记得chmod +x scripts/find.sh。另外，脚本里的路径最好用绝对路径或相对于项目根目录的路径，避免因为工作目录不同而找不到文件。

8.3 上下文打包时的敏感信息过滤

如果你的项目里有敏感信息（比如API密钥、数据库密码），打包上下文时要注意过滤。我通常会在打包命令里加一层grep -v，排除包含password、secret、key等关键词的行。

cat src/config.ts | grep -v -i "password\|secret\|key" >> /tmp/context.md

8.4 多任务并行时的上下文隔离

如果你同时跑多个Claude Code任务，上下文文件要隔离。我通常用任务名作为文件名，比如/tmp/context-task-a.md和/tmp/context-task-b.md，避免互相干扰。

8.5 定期清理临时文件

/tmp/context.md和/tmp/find.log这类文件会越积越多。我通常会在每天结束时清理一次，或者在脚本里加一个自动清理的逻辑。

find /tmp -name "context-*.md" -mtime +1 -delete

9. 最后分享几个实操心得

这套方案我用了大概半年，踩了不少坑，也总结了一些文档里不会写的经验。

第一个心得：地图文件不要追求"完整"，要追求"够用"。我一开始想把每个目录、每个模块都写进去，结果地图文件写了500多行，每次读它反而消耗了大量Token。后来精简到150行左右，只写核心结构和禁区，效果反而更好。Claude Code不需要知道每个文件的细节，它只需要知道"大概在哪找"和"哪里不能碰"。

第二个心得：边界Prompt的粒度要"细到函数"。我试过只写"允许修改userService.ts"，结果Claude Code改了同一个文件里的三个函数。后来改成"只允许修改userService.ts中的validateEmail函数"，越界修改就基本消失了。粒度越细，Claude Code的自由发挥空间越小，行为越可控。

第三个心得：不要指望一次配置就永久有效。项目在变，Claude Code的版本也在更新，这套方案需要定期调整。我通常每个月回顾一次，看看地图是否需要更新、边界模板是否需要调整、命令脚本是否需要优化。把它当成一个"活"的流程，而不是一次性的配置。

第四个心得：Token节省不是唯一目标。这套方案确实能省Token，但更重要的是行为可控。当Claude Code的行为可预测时，你才敢让它处理更复杂的任务。省Token是结果，不是目的。

第五个心得：保留"手动模式"的出口。这套方案再完善，也有覆盖不到的场景。我通常会在Prompt里加一句："如果你认为当前边界不合理，可以提出调整建议，但不要自行修改。"这样既保持了边界的严肃性，又给了Claude Code一个"申诉"的渠道。实测中，它偶尔会提出一些合理的调整建议，比如"这个任务需要读取配置文件才能完成"，我确认后就会更新边界。

这套方案的核心其实就一句话：把"探索"变成"确认"，把"自由发挥"变成"边界内执行"。两条Prompt建立地图和边界，两条命令实现精准搜索和上下文注入。不需要复杂的工具链，不需要改源码，纯粹靠对话策略和Shell命令的组合，就能让Claude Code在大多数场景下"按你所想埋头苦编，绝不越界"。