Anthropic 在系统提示里写了什么，工程师们为什么不满
Claude Opus 4.7 的系统提示新增了 acting_vs_clarifying 章节，要求模型「先行动不问问题」——但这个设计默认值和工程师的实际需求之间存在深层冲突
Anthropic 在系统提示里写了什么，工程师们为什么不满
Anthropic 是主流 AI 公司里唯一公开发布用户端系统提示的——每次模型更新，他们会更新 system prompts 文档。Simon Willison 分析了 Opus 4.6 → 4.7 的 diff，这次变化中有一条引发了 HN 222 点讨论、300+ 评论：新增了 acting_vs_clarifying 章节。
核心内容是：
“When a request leaves minor details unspecified, the person typically wants Claude to make a reasonable attempt now, not to be interviewed first. Claude only asks upfront when the request is genuinely unanswerable without the missing information.”
翻译成白话：遇到模糊请求，先做，别问。
这个方向本身有合理的出发点。产品对话里最常见的摩擦之一是模型过度澄清——用户说”帮我写个邮件”，模型回：“请问要写什么主题的邮件？目标受众是谁？希望语气是什么？字数要求？“——这种体验糟透了。
Anthropic 的逻辑是：对于细节不明确但意图清晰的请求，模型应该做出合理推断并直接执行。这在消费者产品场景（claude.ai）里通常是正确的。
但问题在于这条规则被写入了所有使用 Claude 的场景——包括通过 API 构建的 agentic 工作流。
工程师们的反应很能说明问题。HN 评论里点赞最高的几条：
“Dammit, that’s why I could never get it to not try to one-shot answers—it’s in the god damn system prompt. And it explains why no amount of user-level prompting could fix this behavior.”
“Having to ‘unprompt’ behaviour I want that Anthropic thinks I don’t want is getting out of hand. My system prompts always try to get Claude to clarify more.”
“Sometimes we are just wondering: are we the dumb ones since the demo shows everything just works?”
这几条评论揭示了一个结构性问题：Anthropic 的系统提示默认值是为产品 demo 场景优化的，不是为真实工程场景优化的。
在 agentic 工作流里，模糊请求不应该被”合理推断后执行”——应该被中断并返回问题。一个在后台自主运行的 agent，悄悄做了”合理推断”然后产出一个你根本没预期的副作用，远比一个反复追问的 agent 危险得多。
这个矛盾有更深的根源。
Anthropic 在 Model Spec 里定义了三层用户：Anthropic（政策制定者） → Operator（API 调用者）→ User（终端用户）。系统提示是 Anthropic 直接写给 Claude 的”政策层”，operator 可以通过自己的 system prompt 覆盖部分行为，但有些层面无法覆盖。
acting_vs_clarifying 被写在政策层，意味着operator 要付出额外的 prompt engineering 成本去”反作用”这个默认值——而且这个反作用本身还不稳定，因为政策层的优先级高于 user system prompt。
“I even have a specific, non-negotiable phase in the process where model MUST interview me. Otherwise, the intent gets lost somewhere in the chat transcript.”
这位开发者描述的场景——创建一个”强制提问阶段”——其实说的是一个在 2025-2026 年越来越普遍的工程模式：用明确的 agent phase 管理来对抗模型的默认行为。
但这件事还有另一面。
这次系统提示更新里有一条值得关注的变化：新增了 tool_search 调用指令——在 Claude 宣称”我没有 X 能力”之前，它必须先调用 tool_search 确认是否有对应工具存在。
“Before concluding Claude lacks a capability, Claude calls tool_search to check whether a relevant tool is available but deferred.”
这是一个很务实的工程改进。Claude 过去经常说”我无法访问你的日历”——即使 operator 明明配置了日历工具。现在的方向是先主动探查，再告知能力边界。
同一批 diff 里还有：
- Claude in Excel、Claude in PowerPoint 现在被列为 Claude 的工具列表。完整的 Office 套件正在成为 Claude Cowork 的 agent 工具集
- 新增了更严格的儿童安全章节，一旦拒绝相关请求，整个会话后续都必须”极度谨慎”
- 删除了限制 Claude 使用
*actions*的约束——这意味着 Opus 4.7 不再有这个行为问题，而不需要靠 prompt 来限制
从这次系统提示 diff 里可以读出一个趋势：Claude 正在从一个聊天助手向一个 Cowork 平台的 agent 核心演化。Office 工具、浏览器操控、主动工具探查——这些改变的方向都是让 Claude 在一个更大的 workflow 里更自主地运作。
但这正是让工程师们担心的地方：自主性增强意味着默认行为的影响范围也在扩大。一个会”主动推断并执行”的 agent，在消费端体验更好；但在生产 workflow 里，需要开发者付出更多精力来约束它的主动性。
这不是 Claude 的特有问题——这是所有把”省力体验”写入模型默认值的厂商都会遇到的问题。问题的本质是：一个行为默认值不可能同时对消费端用户和企业 API 用户都是最优的。
或许下一步需要的，是一个针对 agentic operator 场景的”专业模式”系统提示——类似于 Claude for Business vs Claude for Consumers 的分叉。