企业官网建设流程全解析

• 文档
• 提示工程
• 人工智能

导读

本文基于 Claude Code 系统提示词仓库中的 System Reminder: Auto mode clarification bias（ccVersion 2.1.200，约 338 tokens）展开，剖析 Auto 模式（连续自主执行）下"默认继续、按需提问"的决策机制：哪些情况下 Agent 应当直接做出合理判断并继续执行，哪些信号表明用户期望它停下来澄清，以及任何情况下都不可跨越的安全底线（丢弃未提交工作与敏感信息泄露）。读完本文，你将理解 Auto 模式提问策略的完整边界，以及它与 AskUserQuestion 工具、执行谨慎原则、consent 流程之间的配合关系。

一、背景：Auto 模式与"少打断"的总体原则

该 Reminder 是 Auto 模式提示词体系中的一员。其基座文档 System Prompt: Auto mode（ccVersion 2.1.139）定义了连续自主执行的六条总体原则：

1. 立即执行（Execute immediately）——马上开始实施，对低风险工作做出合理假设并继续；
2. 减少打断（Minimize interruptions）——对常规决策优先做合理假设而非提问；
3. 行动优先于规划（Prefer action over planning）——除非用户明确要求，不进入 plan 模式，拿不准就开写代码；
4. 期待纠正（Expect course corrections）——用户随时可能给出建议或纠正，将其视为正常输入；
5. 不做过度破坏性动作（Do not take overly destructive actions）——删除数据、修改共享/生产系统的动作仍需显式确认；
6. 避免数据外泄（Avoid data exfiltration）——除非用户明确指示，不得向聊天平台或工单发布消息，未经授权不得分享机密。

Auto mode clarification bias 这份 Reminder 正是对第 2 条"减少打断"的展开与边界化：它不是一个无条件"闷头干"的指令，而是一套"默认继续、例外提问、安全兜底"的三段式决策规则。

二、核心规则一：默认偏向"不提问，继续干"

Reminder 的正文给出第一层规则（原文要点）：

Bias toward working without stopping for clarifying questions — when you'd normally pause to check, make the reasonable call and keep going; they'll redirect you if needed.

翻译并展开即：

• 默认状态是继续工作，而不是停下来确认；
• 在"过去通常会暂停核对"的场景下，改为做出合理判断并持续推进；
• 背后的信任模型是：用户既然选择了 Auto 模式，就预期 Agent 会带着合理假设前进，若方向不对，用户会主动纠正（对应 Auto 模式第 4 条"期待纠正"）。

这一偏置的实践意义在于：Auto 模式被设计为"类后台 Agent"的连续执行体验（见 System Prompt: Auto mode 描述 "Continuous task execution, akin to a background agent"），频繁的确认提问会打断执行节奏、消耗用户注意力。把常规决策的确认成本转移到"事后纠正"上，是刻意设计的交互经济学选择。

三、核心规则二：这些信号出现时，应当提问

紧接着，Reminder 划出第一类例外（原文要点）：

If the user, a skill, or the shape of the task suggests they want you to ask (with ${ASK_USER_QUESTION_TOOL_NAME} or otherwise), do so.

即以下三类信号出现时，应主动提问，而不是默认继续：

1. 用户信号：用户本人表达过希望被询问（例如明确说"遇到 A/B 选择时先问我"）；
2. Skill 信号：被调用的 skill 内嵌了提问要求。仓库中有大量先例，例如 skill-init-claude-md-and-skill-setup-new-version.md 明确要求 "Use AskUserQuestion to find out what the user wants"，以及 skill-update-claude-code-config.md 中的 "CRITICAL: Use AskUserQuestion for Ambiguity" 章节；
3. 任务形态信号：任务本身的结构暗示需要澄清（如需求严重歧义、存在多个互斥方案且影响面大）。

提问的载体默认是${ASK_USER_QUESTION_TOOL_NAME}（即 AskUserQuestion 工具，"or otherwise" 说明也可视情况用其他方式）。该工具本身的门槛在 Tool Description: AskUserQuestion 中界定得很清楚：

Use this tool only when you are blocked on a decision that is genuinely the user's to make: one you cannot resolve from the request, the code, or sensible defaults.

也就是说，AskUserQuestion 只用于"无法从请求、代码或合理默认值中自行消解、且决定权确实属于用户"的决策——这与澄清偏置是同一枚硬币的两面：能自行消解的就继续，不能的才提问。工具的使用细节还包括：用户始终可点 "Other" 自定义输入、multiSelect: true支持多选、推荐项应置于首位并加 "(Recommended)" 标注。

四、核心规则三：真正被阻塞时，停下来完全正当

Reminder 的最后一句给出第二类例外（原文要点）：

And even absent that signal, it's still fine to stop when you're genuinely blocked — unclear direction, missing input, a decision only they can make.

即即便没有任何"希望提问"的信号，以下三种"真正被阻塞"的情形下停下来依然是允许且正确的：

• 方向不明确（unclear direction）：无法确定该做什么；
• 缺少输入（missing input）：任务依赖用户提供、而 Agent 无法自行获取的信息；
• 只能用户拍板（a decision only they can make）：决定权唯一性地落在用户身上。

这与 AskUserQuestion 工具的门槛语义完全对齐——"genuinely the user's to make"。也印证了 Tool Description: AskUserQuestion decision guidance 的核心判断标准：只有当"用户的答案会改变 Agent 下一步做什么"时才值得提问。

一个实用判断框架（结合上述两份文档归纳）：

五、安全底线：丢弃未提交工作前的强制防护

澄清偏置不是"无法无天"的许可证。Reminder 第二段划出了一条无论何时都不可跨越的红线（原文要点）：

Before any command that could discard uncommitted work —git checkout/restore/reset/clean,rm -rfin the repo, restoring from a snapshot — rungit statusfirst and stash (with-ufor untracked) or commit anything that's there.

可操作的落地流程为：

1. 识别危险命令：git checkout、git restore、git reset、git clean、仓库路径上的rm -rf、从快照恢复——这些命令都可能丢弃未提交的工作；
2. 执行前先跑git status：核对工作区当前状态；
3. 保护现场：对已有的改动git stash（未跟踪文件需加-u参数一并 stash）或git commit，然后再执行危险命令。

这与 Auto 模式第 5 条"不做过度破坏性动作"、以及 System Prompt: Executing actions with care 中的"可逆性/爆炸半径"评估一脉相承——后者进一步列举了需要确认的典型危险操作（删除文件/分支、drop 数据库表、强推、git reset --hard、修改 CI/CD、向外部服务发消息等），并给出"优先可逆操作（移开/重命名/stash）而非删除"的通用建议。

六、防泄密复查：提交与推送前的双重检查

Reminder 第二段的另一条红线针对提交与推送环节（原文要点）：

When staging or committing, review what's included (git statusafter a broadgit add), and if you see anything suspicious that might reveal secrets — even if the filename looks innocuous — double-check the file's contents before pushing.

落地要点：

1. 宽泛git add后必复查：执行了git add ./git add -A这类宽泛暂存后，用git status复查实际纳入范围；
2. 文件名无害 ≠ 内容无害：即使文件名看起来人畜无害（如看似普通的配置文件、测试数据、文档），只要内容可疑、可能泄露密钥/凭据/内部资料，推送前必须打开文件核对内容；
3. 防泄密与 Auto 模式第 6 条"避免数据外泄"呼应——Auto 模式下 Agent 拥有更高执行自由度，因此对"未经授权即外发"的管控反而更严。

这条规则的演进在仓库 CHANGELOG.md 中有迹可循：第 1439 行记录该 Reminder 新增"宽泛git add后复查、推送前对可疑文件（即使文件名无害）进行内容核对"的指导；第 1481 行记录其"强化破坏性工作树防护：优先可逆的移动/重命名/stash 而非删除，并要求在可能丢弃未提交工作的命令前先git status并 stash 或 commit"。

七、与相关机制的协同关系

澄清偏置并非孤立存在，它与仓库中多个提示词构成完整体系：

• 执行谨慎：System Prompt: Executing actions with care 是通用基线——任何模式下危险动作都要确认；澄清偏置是 Auto 模式对"常规动作少确认"的放宽，而危险动作的确认要求并未放宽，二者是"放宽处放宽、收紧处收紧"的关系；
• Consent 流程：System Reminder: Auto mode consent flow 定义了当 Auto 模式被拦截时的处理：优先找不被规则拦截的替代方案（特性分支、合成数据、更窄范围）继续任务，否则把请求挂起并与其余请求批量提交给用户确认，且"绝不静默丢弃任何挂起的请求"——这保证了澄清偏置不会变成"绕过同意机制的借口"；
• Plan 模式分工：在 plan 模式下，澄清的分工更严格——System Reminder: Plan mode approval tool enforcement 规定计划轮次只能以 AskUserQuestion（澄清需求/方案）或 ExitPlanMode（请求批准计划）结束，禁止用文本提问或 AskUserQuestion 询问"计划可以吗"；这从反面印证了 AskUserQuestion 的定位是澄清而非审批。

八、一句话总结

Auto mode clarification bias 的完整心智模型是：常规决策默认继续、信号明确则提问、真正阻塞可停下、危险操作与泄密红线绝不让步。理解这套边界，是正确使用 Claude Code Auto 模式（无论是本地连续执行还是云上调度）的前提——它决定了 Agent 在"自主推进"与"必要确认"之间的精准落点。

• 文档
• 提示工程
• 人工智能