企业官网建设流程全解析

1. 这套方案到底在解决什么问题

用AI编程助手写代码，最让人抓狂的场景莫过于：你明明只想让它改一个函数，它却开始满仓库乱翻文件，一会儿grep这个关键词，一会儿读那个目录，最后Token烧了一大半，代码还没开始写。更气人的是，它翻完一圈之后，给出的修改方案跟你想要的完全不是一回事。

这个项目的核心思路非常直接：用两条精心设计的Prompt，配合两条自定义命令，把AI编程助手的行为约束在明确的边界内。说白了，就是给它画一个圈，告诉它“你就在这个圈里干活，别到处乱跑”。

我最初接触这个思路，是因为一个实际项目。当时我在维护一个中型代码库，大概有三百多个源文件。每次让AI助手帮我改一个模块的代码，它都会先花大量时间扫描整个项目结构，然后grep各种关键词，试图“理解上下文”。问题是，它理解出来的上下文往往跟我脑子里的上下文完全对不上。比如我想让它改一个数据校验逻辑，它却跑去翻数据库连接池的配置，理由是“可能有关联”。这种发散式的探索，不仅浪费Token，还经常导致它改错文件。

后来我意识到，问题的根源在于：AI助手默认的行为模式是“尽可能多地收集信息”，而不是“在最小范围内完成任务”。这就像你请了一个装修师傅来修水龙头，他非要把整个房子的水电图都看一遍才肯动手。虽然理论上更“全面”，但实际上完全是浪费时间。

这套方案要做的，就是通过Prompt和命令的组合，把AI助手的行为模式从“发散探索”切换到“聚焦执行”。具体来说，它解决了三个核心痛点：

• Token浪费：每次任务都扫描全仓库，Token消耗是实际需要的几倍甚至十几倍
• 行为越界：AI助手擅自扩大修改范围，改了不该改的文件
• 上下文混乱：AI助手自己“脑补”的上下文跟开发者实际需要的上下文不一致

适合谁来参考这套方案？我认为有三类人最需要：一是经常用AI助手处理大型代码库的开发者，二是对Token消耗比较敏感的个人用户，三是希望AI助手行为可控、可预测的团队。如果你只是写几十行的小脚本，这套方案可能有点“杀鸡用牛刀”，但只要你的项目超过一百个文件，它带来的效率提升会非常明显。

2. 核心设计思路与方案选型

2.1 为什么是“两条Prompt”而不是一条

很多人可能会想，为什么不直接写一条超级详细的Prompt，把所有规则都塞进去？我一开始也是这么想的，但实测下来发现，一条超长Prompt的效果远不如两条分工明确的Prompt。

原因在于，AI助手处理长Prompt时，注意力会被稀释。你把二十条规则塞进一段话里，它可能只记住前五条，后面的全忘了。但如果你把规则拆成两条Prompt，每条只负责一个维度，它的执行准确率会高很多。

这两条Prompt的分工是这样的：

• 第一条Prompt：定义“工作边界”。它告诉AI助手，当前任务的修改范围是什么，哪些文件可以动，哪些文件绝对不能碰。这条Prompt的核心是“约束”。
• 第二条Prompt：定义“工作方式”。它告诉AI助手，在边界内应该怎么干活——先读哪个文件，再改哪个函数，遇到不确定的情况怎么处理。这条Prompt的核心是“流程”。

打个比方，第一条Prompt是给AI助手画了一个圈，第二条Prompt是告诉它在圈里怎么走路。两者配合，才能既不放任它乱跑，又不让它站在原地发呆。

2.2 为什么是“两条命令”而不是手动输入

Prompt再好，如果每次都要手动复制粘贴，那也太麻烦了。所以这套方案的另一半，是把这两条Prompt封装成两条自定义命令。

自定义命令的好处有三个：

• 一键调用：不用每次翻聊天记录找Prompt，直接输入命令就行
• 参数化：可以把当前任务的具体信息（比如要改哪个文件、要实现什么功能）作为参数传进去
• 可版本管理：命令文件可以放进Git仓库，团队共享，随时更新

我试过用别名（alias）来实现类似效果，但别名只能处理简单的文本替换，没法做条件判断和参数拼接。自定义命令则灵活得多，可以根据不同的任务类型，动态生成不同的Prompt内容。

2.3 整体架构与数据流

这套方案的完整工作流是这样的：

1. 开发者确定当前任务的范围（比如“只改用户模块的校验逻辑”）
2. 调用第一条命令，生成“边界Prompt”，告诉AI助手修改范围
3. 调用第二条命令，生成“流程Prompt”，告诉AI助手具体怎么改
4. AI助手在边界内执行任务，不再扫描全仓库
5. 任务完成后，开发者检查修改结果，确认没有越界

整个过程中，最关键的是第一步——开发者必须自己先想清楚任务范围。这套方案不会帮你做决策，它只是把你的决策准确地传达给AI助手。如果你自己都不知道要改哪些文件，那AI助手更不可能知道。

注意：这套方案的前提是“你知道自己要做什么”。如果你还在探索阶段，不确定要改哪里，那还是让AI助手先帮你分析一下比较好。边界约束适合“执行阶段”，不适合“探索阶段”。

3. 核心细节解析与实操要点

3.1 第一条Prompt的写法拆解

第一条Prompt的目标是定义边界。它需要包含以下几个关键信息：

• 任务描述：一句话说清楚要做什么
• 允许修改的文件列表：明确列出可以动的文件
• 禁止修改的文件列表：明确列出不能动的文件
• 边界判断规则：遇到不确定的情况时，AI助手应该怎么做

我常用的模板是这样的：

当前任务：{任务描述} 允许修改的文件： {文件列表} 禁止修改的文件： {文件列表} 边界规则： 1. 只允许修改上述“允许修改的文件”中列出的文件 2. 如果需要修改的文件不在允许列表中，立即停止并告知我 3. 不要主动扫描其他目录或文件 4. 不要grep任何关键词，除非我明确要求 5. 如果任务无法在允许范围内完成，直接告诉我，不要自行扩大范围

这个模板的核心是最后一条规则：如果任务无法在允许范围内完成，直接告诉我。这一条极其重要，因为它给了AI助手一个“安全出口”。没有这条规则，AI助手遇到困难时就会自行扩大范围；有了这条规则，它会先停下来问你。

3.2 第二条Prompt的写法拆解

第二条Prompt的目标是定义流程。它需要告诉AI助手，在边界内应该按照什么顺序干活。我常用的模板是这样的：

工作流程： 1. 先读取{核心文件}，理解当前实现 2. 然后读取{参考文件}，了解相关逻辑 3. 在{目标文件}中进行修改 4. 修改完成后，只输出修改后的代码片段，不要输出完整文件 5. 不要解释你的修改思路，除非我明确要求 输出格式： - 只输出修改后的代码 - 如果需要多个文件配合修改，按依赖顺序输出 - 不要添加额外的注释或说明

这里有几个细节值得展开说：

第一，为什么要指定读取顺序？因为AI助手读取文件的顺序会影响它对代码的理解。先读核心文件，再读参考文件，它的理解会更聚焦。反过来，如果先读了一堆无关文件，它的注意力就被分散了。

第二，为什么要限制输出格式？因为AI助手默认会输出一大堆解释性文字，什么“我做了以下修改”、“这个修改的目的是”之类的。这些文字不仅浪费Token，还干扰你阅读代码。直接让它只输出代码，干净利落。

第三，为什么不要它解释思路？因为大多数时候你不需要它的解释。你只需要看代码改得对不对。如果改错了，你再问它为什么这么改也不迟。提前让它解释，反而容易让它“为了解释而修改”，本末倒置。

3.3 两条命令的实现方式

把Prompt封装成命令，具体实现方式取决于你用的工具。但核心思路是一样的：命令接收参数，拼接成完整的Prompt，然后发送给AI助手。

我用的是Shell脚本加别名的组合。比如，我定义了一个命令叫scope，用来生成边界Prompt：

#!/bin/bash # scope.sh - 生成边界Prompt TASK="$1" ALLOWED="$2" FORBIDDEN="$3" cat <<EOF 当前任务：$TASK 允许修改的文件： $ALLOWED 禁止修改的文件： $FORBIDDEN 边界规则： 1. 只允许修改上述“允许修改的文件”中列出的文件 2. 如果需要修改的文件不在允许列表中，立即停止并告知我 3. 不要主动扫描其他目录或文件 4. 不要grep任何关键词，除非我明确要求 5. 如果任务无法在允许范围内完成，直接告诉我，不要自行扩大范围 EOF

然后在使用时，直接调用：

scope "修改用户校验逻辑" "src/user/validator.js" "src/db/*, src/config/*"

这样就会生成完整的边界Prompt，复制粘贴给AI助手即可。

第二条命令类似，叫flow，用来生成流程Prompt。两条命令配合使用，基本可以覆盖大部分日常开发场景。

3.4 参数选择与边界定义的经验

定义边界时，最容易犯的错误是“边界太宽”或“边界太窄”。

边界太宽：比如你把整个src目录都列为允许修改，那AI助手还是会到处乱改。边界的粒度应该尽量细，最好精确到具体文件。

边界太窄：比如你只允许修改一个文件，但实际任务需要改三个文件。那AI助手就会频繁触发“停止并告知”的规则，反而降低效率。

我的经验是：边界的粒度应该比你以为需要的稍微宽一点，但比AI助手自己会选择的窄很多。比如你觉得要改两个文件，那就列三个；但绝对不要把整个模块都列进去。

另外，禁止修改的文件列表也很重要。有些文件是“高压线”，比如配置文件、数据库迁移文件、CI脚本等。这些文件一旦被AI助手误改，后果可能很严重。把它们明确列在禁止列表中，可以避免很多麻烦。

4. 实操过程与核心环节实现

4.1 环境准备与命令配置

这套方案不依赖特定的AI编程助手，只要你的工具支持自定义命令或快捷输入就行。我用的是终端环境，所以配置方式以Shell为主。

首先，创建一个目录存放命令脚本：

mkdir -p ~/.ai-commands

然后把前面提到的scope.sh和flow.sh放进去，赋予执行权限：

chmod +x ~/.ai-commands/scope.sh chmod +x ~/.ai-commands/flow.sh

接着在Shell配置文件中添加别名：

# 在 ~/.bashrc 或 ~/.zshrc 中添加 alias scope='~/.ai-commands/scope.sh' alias flow='~/.ai-commands/flow.sh'

重新加载配置：

source ~/.bashrc

这样你就可以在任何目录下直接使用scope和flow命令了。

4.2 一个完整的任务执行示例

假设我要修改一个用户注册模块的校验逻辑。当前项目结构如下：

project/ ├── src/ │ ├── user/ │ │ ├── validator.js │ │ ├── register.js │ │ └── profile.js │ ├── db/ │ │ └── connection.js │ └── config/ │ └── settings.js └── tests/ └── user.test.js

第一步：确定边界

我要改的是validator.js中的邮箱校验逻辑，可能还需要同步更新register.js中的调用方式。其他文件一律不动。

第二步：生成边界Prompt

scope "修改邮箱校验逻辑，支持国际化域名" "src/user/validator.js, src/user/register.js" "src/db/*, src/config/*, src/user/profile.js"

生成的Prompt会明确告诉AI助手：只能改validator.js和register.js，其他文件碰都不能碰。

第三步：生成流程Prompt

flow "先读src/user/validator.js，再读src/user/register.js，在validator.js中修改校验函数，在register.js中更新调用方式"

第四步：发送给AI助手

把两条Prompt依次粘贴给AI助手。它会先读取指定的两个文件，然后在边界内进行修改。

第五步：检查结果

AI助手输出修改后的代码片段。我检查一下，确认只改了这两个文件，没有越界。如果改得不对，我再针对性地调整Prompt。

4.3 参数计算与边界粒度选择

边界粒度怎么定？我总结了一个简单的判断方法：

超过8个文件的任务，建议拆分成多个子任务，每个子任务单独定义边界。因为边界太宽，AI助手还是容易乱跑。

另外，Token消耗的估算也很重要。假设一个文件平均500行，每行10个Token，那读一个文件就是5000 Token。如果AI助手读了20个文件，那就是10万Token。而如果只读2个文件，就是1万Token。差距是10倍。这就是边界约束带来的直接收益。

4.4 实操现场记录：一次典型的边界失控与修复

有一次我让AI助手改一个日期格式化函数。我定义的边界是src/utils/date.js。结果它读完这个文件后，说“为了确保兼容性，我需要检查一下调用这个函数的地方”。然后它就开始grepformatDate，找到了十几个调用点，然后逐个读取那些文件。

这就是典型的边界失控。虽然它没有直接修改那些文件，但读取它们同样消耗Token。而且它读完之后，可能会说“我发现有三个调用点需要同步修改”，然后试图扩大修改范围。

修复方法很简单：在边界Prompt中加一条规则——“不要主动查找调用点，除非我明确要求”。加上这条规则后，它就老老实实只改date.js了。

这个经历让我意识到，边界约束不仅要限制“修改范围”，还要限制“读取范围”。读取范围失控，同样会导致Token浪费和行为发散。

5. 常见问题与排查技巧实录

5.1 AI助手不遵守边界怎么办

这是最常见的问题。你明明说了“只改A文件”，它还是去改了B文件。原因通常有三个：

原因一：Prompt中的边界描述不够明确。比如你写“主要修改A文件”，那“主要”这个词就给了它模糊空间。应该写“只允许修改A文件”。

原因二：AI助手认为“不改B文件就无法完成任务”。这时候它会自行判断“为了完成任务，必须突破边界”。解决方法是在边界Prompt中明确写“如果任务无法在允许范围内完成，直接告诉我，不要自行扩大范围”。

原因三：工具本身的限制。有些AI编程助手会自动扫描项目结构，这个行为不受Prompt控制。如果是这种情况，你需要在工具设置中关闭“自动扫描”功能，或者选择支持手动指定上下文的工具。

5.2 Token消耗还是很高怎么办

如果用了边界约束，Token消耗还是很高，那可能是以下几个环节出了问题：

• 边界定义太宽：检查一下允许修改的文件列表，是不是列了太多文件
• 流程Prompt太啰嗦：流程Prompt应该简洁明了，不要写太多解释性文字
• AI助手输出了太多解释：在流程Prompt中明确要求“只输出代码，不要解释”
• 任务本身太复杂：如果一个任务需要改十几个文件，那Token消耗天然就高。这时候应该拆任务，而不是怪边界约束没用

我实测下来，用了这套方案后，单个任务的Token消耗平均降低了60%到70%。如果没降到这个程度，那说明还有优化空间。

5.3 常见问题速查表

5.4 几个容易被忽略的避坑技巧

技巧一：把“禁止修改”列表写得更具体。不要只写“不要改配置文件”，要写“不要改src/config/settings.js和src/config/database.js”。越具体，AI助手越不容易钻空子。

技巧二：在流程Prompt中指定“读取顺序”。先读哪个文件，后读哪个文件，这个顺序会影响AI助手的理解。把最重要的文件放在最前面读。

技巧三：任务完成后，让AI助手输出“修改摘要”。不是让它解释思路，而是让它列出“改了哪些文件、每个文件改了什么”。这样你可以快速检查有没有越界。

技巧四：定期更新命令脚本。随着项目结构变化，边界定义的方式也需要调整。我一般每个月回顾一次命令脚本，看看有没有需要优化的地方。

技巧五：不要完全依赖AI助手的自我约束。这套方案的核心是“约束”，但约束不是100%可靠的。最终检查还是要靠你自己。AI助手改完代码后，用git diff看一下改了哪些文件，确认没有越界。

6. 进阶用法与场景扩展

6.1 多任务并行时的边界管理

当你同时处理多个任务时，边界管理会变得更复杂。比如你一边让AI助手改用户模块，一边让它改订单模块。如果两个任务的边界没有明确区分，AI助手可能会把两个任务的修改混在一起。

我的做法是：每个任务单独定义边界，单独执行，不要并行。虽然理论上可以并行，但实测下来，串行执行的准确率更高。一个任务改完，确认无误后，再开始下一个任务。

如果确实需要并行，那就在边界Prompt中明确写“当前任务只涉及用户模块，不要触碰订单模块的任何文件”。把“禁止修改”列表写得更详细一些。

6.2 在团队协作中共享命令配置

这套方案在团队协作中特别有价值。因为团队成员的Prompt写法可能各不相同，导致AI助手的行为不一致。如果把命令脚本放进Git仓库，团队共享，那所有人的AI助手行为就统一了。

具体做法是：在项目根目录创建一个.ai-commands目录，把scope.sh和flow.sh放进去，然后在项目的README中说明如何使用。新成员加入时，只需要把这两个脚本加到自己的Shell配置中即可。

这样做还有一个好处：命令脚本可以随着项目演进不断优化。比如项目结构调整了，边界定义的方式也需要调整。把脚本放在项目仓库里，调整起来更方便。

6.3 与其他效率工具的配合

这套方案可以和其他效率工具配合使用，效果更好。比如：

• 与Git配合：每次AI助手改完代码后，用git diff检查修改范围。如果发现越界，直接git checkout回滚。
• 与代码检查工具配合：AI助手改完代码后，自动运行lint和测试。如果检查不通过，说明修改有问题。
• 与任务管理工具配合：每个任务对应一个边界定义，任务完成后归档边界定义，方便后续追溯。

我自己的习惯是：每次让AI助手改代码之前，先创建一个Git分支。改完之后，如果没问题就合并，有问题就直接删分支。这样即使AI助手改错了，也不会影响主分支。

6.4 适用场景与不适用场景

这套方案最适合的场景是：你已经知道要改什么，只是需要AI助手帮你执行。比如修改一个函数的实现、调整一个组件的样式、更新一个API的调用方式。

不太适合的场景是：你还在探索阶段，不确定要改哪里。比如你刚接手一个项目，还不了解代码结构，想让AI助手帮你分析一下。这时候边界约束反而会限制它的分析能力。

我的建议是：探索阶段用默认模式，执行阶段用边界约束。先让AI助手自由分析，等你确定了修改范围，再切换到边界约束模式。这样既能保证分析阶段的灵活性，又能保证执行阶段的准确性。

7. 我个人的实操体会

这套方案我用了大概半年，最大的感受是：它把AI助手从一个“不可预测的助手”变成了一个“可预测的工具”。以前我用AI助手改代码，每次都要提心吊胆，不知道它会改出什么幺蛾子。现在用了边界约束，它的行为基本在我的预期范围内，改错了也能快速定位。

另一个感受是：写Prompt的时间，远比省下来的Token值钱。一开始我觉得每次都要写两条Prompt很麻烦，但后来算了一笔账：写Prompt大概花2分钟，但省下来的Token和排查时间至少值10分钟。这笔账怎么算都划算。

最后分享一个小技巧：把常用的边界定义保存成模板。比如“只改单个文件”、“改两个关联文件”、“新增功能”这几种场景，各保存一个模板。下次遇到类似任务，直接套模板，改几个参数就行，不用从头写。

这套方案不是什么高深的技术，核心就是“约束”两个字。但就是这两个字，能让你的AI编程体验提升一个档次。如果你也在为AI助手乱跑、Token浪费而烦恼，不妨试试这个思路。