企业官网建设流程全解析

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

导读

本文聚焦 Claude Code 系统提示库中专门用于**探索性问题（Exploratory Questions）**的一段指令，即 system-prompt-exploratory-questions-analyze-before-implementing.md。它规定了当用户抛出"我们该怎么做 X？""这个方案应该怎么推进？""你怎么看？"这类开放式问题时，Claude 应采用"2-3 句话给出推荐与主要权衡、以可重定向的方式呈现、未经用户同意不落地实现"的响应契约。读完本文，你将理解这套行为约束的完整语义、它在 Claude Code 提示体系中的协同位置，以及如何在自己的 Agent 提示设计中复用它。

一段指令，三个行为约束

该提示的完整正文只有一段话，却同时编码了三个层层递进的行为约束：

For exploratory questions ("what could we do about X?", "how should we approach this?", "what do you think?"), respond in 2-3 sentences with a recommendation and the main tradeoff. Present it as something the user can redirect, not a decided plan. Don't implement until the user agrees.

按 ccVersion（2.1.161）版本元数据来看，它是随 Claude Code 各版本持续维护的行为指令之一。三个约束分别是：

1. 识别问题类型：先判断消息是否是"探索性问题"——文档给出了三个典型问法："what could we do about X?"（我们能为 X 做什么？）、"how should we approach this?"（这事该怎么推进？）、"what do you think?"（你怎么看？）。这类问题的共同特征是：用户没有下达明确的实现指令，而是在征询方向。
2. 约束回复形态：用 2-3 句话回答，且必须同时包含一个推荐方案（recommendation）与一个主要权衡（main tradeoff）。
3. 门控实现动作：把方案呈现成"用户可以重定向的东西"，而非"既定计划"；在用户明确同意之前，不得开始写代码或实施。

其中第三条是本提示与常规"直接干活"型指令最本质的区别：探索性问题的回合终点是"共识"，而不是"产出"。

为什么是"2-3 句话 + 一个主要权衡"

文档刻意把回答压缩到 2-3 句话、只要求"一个"主要权衡，而不是一份完整方案书。这与 Claude Code 其他提示对"输出精简度"的要求是同源的：

• system-prompt-communication-style.md 明确要求"End-of-turn summary: one or two sentences"、"a clear sentence is better than a clear paragraph"，并主张把回复长度与任务复杂度匹配——一个简单问题就该得到直接回答，而不是带标题分节的冗长报告。
• system-prompt-concise-output-style.md 同样强调"Lead with the result"（第一句话就给出答案）与"Short by default"（默认保持简短）。

可见探索性问题提示并非孤立规则，而是 Claude Code"默认精炼、按需展开"整体沟通风格在决策场景的具体落地。限制长度不是为了偷懒，而是为了让权衡点暴露得更清晰：2-3 句话的容量恰好容纳"推荐 + 关键取舍 + 可重定向的措辞"，既给出判断，又不淹没用户的决策权。

"可重定向"的措辞语义

"Present it as something the user can redirect, not a decided plan" 是本提示中最微妙的要求。它规定回复的语用姿态：Claude 提出的推荐是供用户参考、推翻、调整的候选项，而不是已经开始执行且难以撤回的计划。其背后逻辑是：

• 探索性问题阶段的信息不对称最大——用户可能掌握 Claude 看不到的业务背景，因此过早把方案"敲定"会导致方向性返工；
• 与 system-prompt-doing-tasks-ambitious-tasks.md 中"defer to user judgement about whether a task is too large"（把任务规模判断权交给用户）的哲学一致：scope 与方向的最终裁决权始终在用户侧。

在实践中，这意味着回复应多用"可以考虑 A 方案，代价是……；如果更看重 X，也可以走 B"这类开放句式，而非"我将执行 A 方案"的完成式表述。

实现门控：同意之前的红线

"Don't implement until the user agrees" 是一条硬性红线。它的意义在于把"建议者"与"执行者"两种角色在回合层面切分开：

• 在探索性回合，Claude 只输出方向性建议；
• 只有用户显式同意后，后续回合才进入实现阶段（此时才轮到 system-prompt-doing-tasks-no-unnecessary-additions.md 等"干活"类约束接管，如不做超出任务范围的扩展、不搞半成品实现）。

值得注意的是，这条门控与 Auto 模式下"少打断、多自主"的倾向并不冲突。system-reminder-auto-mode-clarification-bias.md 鼓励在方向明确的任务中直接做出合理决策并继续推进；而探索性问题提示管辖的是方向本就不明确的场景——此时用户的意图信号（"你怎么看？"）本身就暗示了需要先讨论，门控实现正是对该信号的正确回应。两者共同划出的边界是：能自主时不要无谓打断，需要共识时不要越界代庖。

适用场景与判定边界

从文档给出的三种问法可以归纳出该提示的适用判定：

判定关键在于用户是否给出了明确、可执行的实现指令。任何以征询口吻、开放结尾出现的消息都应优先按探索性问题处理；即使误判，用户也可以用一句"就按你说的做"快速把回合切换到执行模式——这正是"可重定向"设计的意义。

在提示库中的定位与复用价值

本提示位于 Claude Code 系统提示库的"行为类指令"分组中，与沟通风格、任务执行、Auto 模式等提示共同构成运行时的完整行为基线。从提示库整体结构（system-prompts/目录）可以看到，这类片段通常以 HTML 注释形式携带name、description、ccVersion元数据，随 Claude Code 版本迭代同步更新。

对于想为自定义 Agent 编写提示的开发者，本提示是一个高价值的模板级范式：当你的 Agent 需要参与"方案讨论"而非"纯执行"时，可以把三段式约束（识别探索性问题 → 精简输出推荐与权衡 → 同意前不实现）直接移植，并根据业务补充领域化的权衡维度。它证明了：好的 Agent 行为约束不需要长篇大论，关键是明确触发条件、输出形态与动作门控。

小结

探索性问题提示用一句话为 Claude 定义了"讨论模式"下的完整行为契约：识别开放式征询、用 2-3 句话给出推荐与核心权衡、以可重定向姿态呈现、把实现推迟到用户同意之后。它与 Claude Code 的精炼沟通风格、任务规模裁决权归属、Auto 模式自主边界等提示相互咬合，共同保证了"该讨论时讨论、该执行时执行"的回合纪律——这也是一个可被任何 Agent 提示设计直接复用的最小行为范式。

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