范围与边界

Scope & Boundary

也常被叫作：改哪里不改哪里范围限定别乱动

怎么跟 AI 说通常止于「实现」约 2 分钟读完

你可能会这么说

「我只让他改一个小地方，结果他把整个页面都重写了。」

范围与边界 Scope & Boundary

在需求里写清「只改哪里」和「不许动什么」，是防止 AI 顺手重构的唯一有效手段。

先说我们真踩过的一个坑。给家用机器做启动脚本时，边界就一句话：改一行 IP 指向，其余逐行保持。为什么写得这么死？因为上一版家用包沿用了公司环境的启动脚本，首开就弹「示例不可用」——包里根本没带公司才有的演示图。复制脚本时最容易出事的，就是这种继承来的隐含前提：每一行看起来都没错，合起来默认了一个不存在的环境。

往大了说，AI 顺手改坏别处，几乎从不是它恶意，而是你的需求给了它自由。「帮我优化一下这个页面」这句话里，没有任何一处告诉它「不要动配色」「不要动下面的列表」，所以它必须自己决定——而它决定的依据是通用审美，不是你的项目。

所以边界这一句的价值高得离谱：它把「我要什么」补成了「我不要什么」。通用需求里，加上一句「不要改配色和布局」，能挡掉大约八成的意外破坏。更狠一点的写法是同时限定文件范围：「只改 src/app/page.tsx 里的顶部区域」。范围一旦落到具体文件，你验收时也变简单了——问一句「你改了哪些文件」，多出来的就是越界。

边界写不好也有两个典型反面：一种是边界写得像没有，比如「请优化一下体验」「按最佳实践处理」，这种话等于授权它自由发挥；另一种是边界密到任务推不动，每个参数都要你点头，AI 索性只做最小的事然后等指示。好的边界是「告诉它禁区在哪，禁区之外按现有惯例自由发挥」。

还有一条实战经验：边界要写「不许动什么」，不要只写「要改什么」。只写后者时，AI 会默认范围内外都能碰；写了前者，它才会在碰到禁区前停下来问你。两个都写，返工率会明显下降。

长什么样真实可交互，不是截图

✕ 给了自由帮我把这个页面优化一下，做得好看点

✓ 给了边界只改首页顶部区域（page.tsx 的 Hero 部分）；目标是不滚动就能看到价格；不要改配色、字体和下面的列表区；不要新增依赖

右边并没有变得更啰嗦，它只是把你脑子里本来就有的限制说出来了。

拆开看，里面有这几块

1
范围 Scope
改哪个页面、哪个文件、哪一块区域。越具体越好。
2
边界 Boundary
明确不许动什么。这一句是整段需求里性价比最高的。
3
越界处理 Escalation
遇到范围外必须改的东西时，让他先问你，而不是自己决定。

容易搞混？这样区分

范围与边界 ≠ 非目标 Non-goal

边界说的是不许碰哪些东西（配色、布局、其他文件）；非目标说的是这次不做哪些事（不做找回密码、不做第三方登录）。一个限制作用面，一个限制功能面。

看非目标

什么时候用得上

小改动

越小的改动越要写边界。大改动你本来就会盯着，小改动最容易被顺手扩大。

已经满意的页面

先说「现在这几处我很满意，不要动」，再说要改什么。

验收时

问「你一共改了哪些文件」。清单外的每一项都要问原因。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

【范围】只改 [具体文件 / 页面 / 区域]
【目标】[改完要达到的可观察效果]
【边界】以下内容一律不要动：
  - 配色、字体、整体布局
  - [其他页面 / 其他组件]
  - 数据结构和接口
  - 不要新增任何依赖
  - 不要顺手"优化"我没提到的地方
【遇到冲突怎么办】如果你认为必须改动范围外的东西才能达成目标，先停下来告诉我原因，等我确认，不要自己决定。
【交付】列出你实际改动的每一个文件；如果清单里出现了范围外的文件，单独说明原因。

「不要顺手优化我没提到的地方」这一句看起来多余，实际非常有用——它把「善意的自作主张」也明确划到了边界外。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「实现」这层：代码写完了，能读能改，但没被验证过。

要亲眼看到这些，才算数

问「你一共改了哪些文件」，逐个对照你给的范围。多出来的每一个都要问原因。
打开你说过「不要动」的那几处，亲眼确认它们没变（配色、布局、其他页面）。
确认没有新增依赖（问一句「有没有装新包」）。
如果他改了范围外的东西，确认他提前问过你，而不是事后解释。

它常这么糊弄你

「顺便帮你优化了一下其他地方」——这就是越界，即使改得不错。今天能顺手改好，明天就能顺手改坏。
「为了实现这个功能，必须调整一下结构」——可能是真的，但应该在动手前说，不是完成后通知。
只汇报了主要改动，没提附带改动。所以要问「一共」哪些文件，而不是「主要」改了什么。
文件数量对得上，但某个文件里被大段重写。可以顺手问一句「这个文件你改了几行」。

边界能验到「实现」层：对照文件清单和你标记为不许动的地方，不需要跑起来就能查。

考考你选一个你觉得对的

你想让 AI 调整注册表单的间距。哪种说法最不容易出事？

想再深挖一点靠谱出处

Scope（项目范围管理）Wikipedia ↗

# 范围与边界 (Scope & Boundary)

> 在需求里写清「只改哪里」和「不许动什么」，是防止 AI 顺手重构的唯一有效手段。

**你可能会这么说**：我只让他改一个小地方，结果他把整个页面都重写了。

先说我们真踩过的一个坑。给家用机器做启动脚本时，边界就一句话：改一行 IP 指向，其余逐行保持。为什么写得这么死？因为上一版家用包沿用了公司环境的启动脚本，首开就弹「示例不可用」——包里根本没带公司才有的演示图。复制脚本时最容易出事的，就是这种继承来的隐含前提：每一行看起来都没错，合起来默认了一个不存在的环境。 往大了说，AI 顺手改坏别处，几乎从不是它恶意，而是你的需求给了它自由。「帮我优化一下这个页面」这句话里，没有任何一处告诉它「不要动配色」「不要动下面的列表」，所以它必须自己决定——而它决定的依据是通用审美，不是你的项目。 所以边界这一句的价值高得离谱：它把「我要什么」补成了「我不要什么」。通用需求里，加上一句「不要改配色和布局」，能挡掉大约八成的意外破坏。更狠一点的写法是同时限定文件范围：「只改 src/app/page.tsx 里的顶部区域」。范围一旦落到具体文件，你验收时也变简单了——问一句「你改了哪些文件」，多出来的就是越界。 边界写不好也有两个典型反面：一种是边界写得像没有，比如「请优化一下体验」「按最佳实践处理」，这种话等于授权它自由发挥；另一种是边界密到任务推不动，每个参数都要你点头，AI 索性只做最小的事然后等指示。好的边界是「告诉它禁区在哪，禁区之外按现有惯例自由发挥」。 还有一条实战经验：边界要写「不许动什么」，不要只写「要改什么」。只写后者时，AI 会默认范围内外都能碰；写了前者，它才会在碰到禁区前停下来问你。两个都写，返工率会明显下降。

**也叫**：改哪里不改哪里、范围限定、别乱动

## 你可以这样告诉 AI

```text
【范围】只改 [具体文件 / 页面 / 区域]
【目标】[改完要达到的可观察效果]
【边界】以下内容一律不要动：
  - 配色、字体、整体布局
  - [其他页面 / 其他组件]
  - 数据结构和接口
  - 不要新增任何依赖
  - 不要顺手"优化"我没提到的地方
【遇到冲突怎么办】如果你认为必须改动范围外的东西才能达成目标，先停下来告诉我原因，等我确认，不要自己决定。
【交付】列出你实际改动的每一个文件；如果清单里出现了范围外的文件，单独说明原因。
```

## 怎么验证他真的做到了

通常止于层级：**实现** — 代码写完了，能读能改，但没被验证过

- [ ] 问「你一共改了哪些文件」，逐个对照你给的范围。多出来的每一个都要问原因。
- [ ] 打开你说过「不要动」的那几处，亲眼确认它们没变（配色、布局、其他页面）。
- [ ] 确认没有新增依赖（问一句「有没有装新包」）。
- [ ] 如果他改了范围外的东西，确认他提前问过你，而不是事后解释。

常见糊弄：
- 「顺便帮你优化了一下其他地方」——这就是越界，即使改得不错。今天能顺手改好，明天就能顺手改坏。
- 「为了实现这个功能，必须调整一下结构」——可能是真的，但应该在动手前说，不是完成后通知。
- 只汇报了主要改动，没提附带改动。所以要问「一共」哪些文件，而不是「主要」改了什么。
- 文件数量对得上，但某个文件里被大段重写。可以顺手问一句「这个文件你改了几行」。

来源：https://mickerbook.com/reference/t/scope-boundary/