决定让 AI 做到哪一步

“帮我看看这个问题”和“把这个问题修好”，不是同一份授权。前者应交付原因与证据，后者还包括范围内的修改和验证。先选清楚工作终点，能减少两类返工：该执行时只给建议，不该动手时却改了代码。

按产物决定工作方式

它可以自主决定先搜哪个文件，不代表可以自主决定上线一个新功能。操作方法与业务授权应分开。

例子：同一个反馈，分两次交任务

用户反馈：“笔记页和工具页看起来不统一。”

这时还有一个产品问题：你是只想对齐，还是想重做版式？可以先限定调查：

先只读分析 /knowledge 和 /tools 的差异。
按容器边界、标题层级、侧栏和卡片四项比较，
指出哪些由代码证实，哪些需要浏览器确认。
不要改文件。目标是保留现有风格，只找不一致。

看过结果，确认只处理容器后，再授权：

只修复全站容器的水平边界。
首页、笔记、工具、Header、Footer 使用同一规则。
保留页面内容、卡片结构和字号，不重新设计。
在桌面和手机上验证，也检查从首页点击导航后的状态。

不必把每个小任务都拆成两轮。纯文案替换且范围明确时，直接修改即可；共享布局影响多个页面时，先确认“统一”的含义更值得。

有些问题应自行查，有些必须由人选

“当前页面用了哪个容器？”能从代码查，不需要反问用户。

“是否继续保留实践这个栏目？”是内容定位，不能用当前实现替用户决定。

遇到选择时，好的提问应带具体后果。例如：“只修改 Header 会保留宽正文；统一全站容器则会影响工具卡片可用空间。你希望以哪一组边界为准？”比笼统问“你想怎么改”更容易判断。

执行中何时应该停

下面三个信号值得停下来重新确认范围：

• 原定本地修改需要访问生产数据，或向第三方上传材料。
• 新事实推翻了验收条件，例如新文字无法在目标宽度下保持一行。
• 目标区域存在来源不明的未提交改动，当前操作可能覆盖它。

可自行调查、可逆的实现细节不需要反复审批。真正需要暂停的是权限扩大、业务取舍或数据损失风险，而不是任务稍微变复杂了。

Codex 权限文档与Claude Code 权限文档提供了实际约束机制。自然语言说明负责表达你的意图，不能代替这些限制。

把“做完”改成明确的终点

“完成这个功能”太宽时，可以把终点写成：

结束条件：
目标页面行为满足下面三条验收；
现有相关测试未回归；
交付本地 diff 和验证结果。
本次不提交、不推送、不发布。
如果必要验证做不了，说明原因与补验方式。

这不是要求你遥控每一步，而是让执行者知道何时可以继续，何时已经越过任务边界。