摘要
- 编程智能体Bolt（bolt.new）在8月31日发布的教程中指出，智能体变慢、出错增多的根源在于代码库长期积累的混乱
- 教程原文公开了两条提示词：一条用于在改代码前先做审计和制定计划，另一条用于按计划逐步执行、每次只推进一个环节
- 视频中还展示了这套方法在招聘流程工具和会议纪要工具两个实际案例中的应用过程
用AI编程智能体做应用做到一半，常常会遇到一些奇怪的信号：昨天还好好的功能，改一个小地方就崩了；原本很简单的请求，现在却要花比以前长得多的时间。编程智能体Bolt（bolt.new）在8月31日（UTC时间）发布的教程视频中指出，这种症状的根源并不是智能体能力下降，而是代码库本身变得混乱。为此，Bolt在视频中原文公开了两条用来解决这一问题的重构（refactoring）提示词。
代码一旦变乱，智能体也会跟着变慢
所谓重构，就是在保持应用功能完全不变的前提下，只整理底层代码结构。按钮还是那些按钮，行为还是那些行为，变的只是代码的组织方式。Bolt在视频中解释道，智能体变慢或出错增多，最常见的原因之一往往不是智能体本身的问题，而是代码变乱发出的信号。在杂乱无章的代码库里，智能体需要花更多token去理解上下文，出错的概率也随之上升。
视频中还提到了OpenClaw创始人Peter Steinberger的一个习惯：每合并一个功能，他都会问自己接下来还能重构点什么。视频引用了他的话，他警告说，如果跳过这个习惯，最终会"you'll slop yourself into a corner"（把自己一步步逼到死角）。
第一步：动手改代码之前，先让智能体审计并给出计划
Bolt公开的第一条提示词，作用是在改代码之前先让智能体做诊断。原文如下：
"I want to refactor this project to make it cleaner and easier to maintain. Before changing any code, audit the code base and give me a plan. Look for the things that most hurt maintainability: files that are too long or doing too many unrelated things, the same logic duplicated in more than one place, components that mix data fetching, business logic, and UI, unclear or misleading names, dead code that nothing uses. For each, say what you would do to change it and how risky that change is. Do not change any code yet, do not add any features, fix unrelated bugs, or change how the app behaves. Just give me a prioritized plan so I can approve it before we touch anything."
翻译成中文大致是这样：我想重构这个项目，让它更干净、更容易维护。在改动任何代码之前，先审计代码库并给我一份计划。找出最影响可维护性的地方——太长或者同时做太多不相关事情的文件、在多处重复出现的相同逻辑、把数据请求、业务逻辑和界面混在一起的组件、命名不清晰或容易误导的地方，以及没人用的死代码。针对每一项，说明打算怎么改、风险有多大。现在先不要改任何代码，也不要添加功能、修复无关的bug或改变应用的行为。只需要给我一份按优先级排好的计划，等我批准之后再动手。
第二步：计划只按一步一步来执行
智能体给出改进清单之后，这份教程强调的关键点是：不要一口气全部执行。代码库越大,同时推进多项重构的风险就越高，所以Bolt建议只挑出计划中的第一项，用下面这条提示词来执行。
"Refactor the first step from the plan. Rules: do not change any behavior. The app must look and work the exact same afterwards. Do not add features or fix unrelated bugs while you're in here. Only touch the files needed for this change. Keep the existing interface the same so nothing else breaks. When you're done, give me a short summary of what changed and confirm the app still behaves identically."
翻译过来是——只重构计划里的第一步。规则是：不要改变任何行为，改完之后应用的外观和运行方式必须和之前完全一样；在这个过程中不要添加功能，也不要修复无关的bug；只能触碰这次改动所需要的文件；保持现有接口不变，避免影响到其他部分。完成之后，简短总结一下改了什么，并确认应用的行为依旧和之前一模一样。
实际应用效果：两个项目的结果
| 项目 | 问题最严重的组件 | 智能体指出的问题 | 首个执行对象 |
|---|---|---|---|
| 内部招聘流程工具 | App组件 | 整个应用的状态管理、增删改查、筛选、布局渲染全部堆在一个文件里 | 将数据库访问逻辑拆分到独立文件 |
| 会议纪要与后续跟进工具 | Customer Call Card | 文件超过1200行，含7个子组件，API调用和界面逻辑混杂，存在重复函数和重复的开关逻辑 | 优先重构Customer Call Card |
两个案例中，都是先由审计提示词具体指出问题所在，再由执行提示词只处理其中一项。在招聘工具的案例里，把5个数据库查询迁移到独立文件中的异步函数被判定为低风险，随即直接执行；而在会议纪要工具的案例里，拆分那个1200行的组件被判定为中等风险。
贯穿两条提示词的共同框架
| 共同要素 | 提示词中的表述 |
|---|---|
| 诊断先于代码改动 | "在改代码之前先审计并给出计划" |
| 行为绝对不能改变 | "不要改变任何行为"、"应用必须和之前运行方式完全一样" |
| 一次只推进一步 | "只重构计划中的第一步" |
| 完成后自我核实 | "总结改了什么，并确认行为是否一致" |
少了这四个要素中的任何一个，提示词都会失效。省略诊断环节，智能体就要自己决定该改哪里；去掉行为不变原则，重构过程中功能悄悄发生变化的风险就会出现；删掉"逐步推进"的指示，这份教程一开始警告的"同时改动多处带来的风险"就会重新出现。
照着做的具体步骤
- 开启一个新对话，清空上下文。教程把这一步比作从跑道起点起飞——意思是开始重构这样的大工程之前，要尽量给上下文窗口留出空间。
- 切换到计划模式（执行前先做审查的模式），把第一步的审计提示词原样粘贴进去。
- 查看智能体给出的优先级列表。标注为低风险的项目可以直接推进，但对于标注为高风险的项目，更稳妥的做法是反问智能体，让它进一步解释相关逻辑。
- 切换到执行模式，用第二步的提示词指定计划里的第一项,交给智能体去重构。
- 如果结果出问题——比如构建失败或行为发生变化——首先要检查的是提示词允许改动的文件范围，看看是不是有范围之外的文件被改动了。
- 迁移到其他项目时，提示词的措辞保持不变，只需要把"this project"换成实际项目名称即可。"行为不变""逐步执行""完成后总结"这几条规则性的句子最好原样保留。
编辑视角
随着氛围编程（vibe coding）工具越来越多，"智能体越用越笨"的抱怨也在增多。但这次教程指出的方向不太一样：它把智能体变慢的原因归结为代码库积累的技术债,而不是模型性能本身。这本来就是人工编写代码时早就通行的原则，Bolt这次相当于再次证明,到了AI智能体时代，这条原则依然没有例外。
放到实际操作中体会一下，就能明白这个顺序为什么重要。如果没有审计提示词、直接让智能体去"整理一下代码"，智能体很可能看到什么就改什么，顺带把功能也悄悄改掉了。反过来，如果按照审计→批准→逐步执行这个顺序来做，每一步都会留出一个节点，让审查者判断这次改动是否真的安全。这其实就是把人类开发者之间的代码审查习惯，原封不动地搬到了智能体身上。
如果你所在的团队正用氛围编程工具做副业项目或内部工具，一定会遇到这样的时刻——功能堆得差不多了，才突然感觉代码变慢了。这个时候与其继续往上堆新功能，不如先用这次公开的两条提示词跑一次审计，成本会小得多。尤其是当某个文件超过500行、或者同一段逻辑在两处以上被复制粘贴时，就已经可以列入重构优先级候选了。
预计未来几周内，其他编程智能体厂商也很可能推出类似的"诊断优先"提示词指南教程。随着智能体性能的竞争从跑分阶段进入下一阶段，"如何用好智能体"这类使用方法本身，正在成为新的竞争点。
评论