企业官网建设流程全解析

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

本指南围绕 system-prompt-reporting-outcomes.md（ccVersion 2.1.251）展开，逐条拆解 Claude Code 对代理（Agent）结果报告行为的硬性要求：如何区分"实际发生的结果"与"本应发生的意图"、何时必须在报告第一句置顶失败信息、以及如何避免夸大未经验证的完成声明。读完本文，你将掌握这套结果报告准则的全部条款、底层设计动机、与其配套提示词的协作关系，以及在真实任务（Web 抓取、代码评审、后台任务）中的落地写法。

一、这份提示词在仓库中的定位

Reporting outcomes（结果报告）是 Claude Code 系统提示词集合中的一份独立行为准则。该集合由大量面向不同场景的提示词文件构成，本文件通过文件头元数据声明了自己的身份：

• name: "System Prompt: Reporting outcomes"
• description: "Requires reports to distinguish observed outcomes from intentions, lead with failures or incomplete work, and avoid overstating unverified completion"（要求报告区分已观察结果与意图、以失败或不完整工作开头、避免夸大未经验证的完成）
• ccVersion: "2.1.251"，随每个 Claude Code 版本更新

它与同目录下的多份提示词构成一个"结果报告"行为体系，其中关系最密切的三份是：

• system-prompt-action-safety-and-truthful-reporting.md（2.1.271）：负责任地报告结果的姊妹规则，明确要求"如果测试失败，就带着输出说出来；如果某一步被跳过，就说出来；当某事完成且已验证时，就直说，不要闪烁其词"；
• system-prompt-outcome-first-communication-style.md（2.1.235）：沟通风格规则，要求"以结果开头（Lead with the outcome）"，第一句回答'发生了什么/你发现了什么'；
• system-prompt-executing-actions-with-care.md（2.1.200）：执行前审慎评估可逆性与影响范围的规则。

如果把这三份提示词放在一起看：executing-actions-with-care管"怎么做之前先想清楚"，action-safety-and-truthful-reporting管"做完了怎么如实汇报"，outcome-first-communication-style管"汇报时怎么组织语言"，而reporting-outcomes则是这套体系里对"证据与声明的关系"规定得最严格的一份——它回答的是：你凭什么说一件事做完了？

二、核心准则一：报告实际发生的，而不是你意图发生的

提示词开篇第一句就是最核心的约束：

Report what actually happened, not what you intended. （报告实际发生的事，而不是你打算做的事。）

这看起来简单，却直指 LLM 代理最常见的报告缺陷：模型在生成文本时，很容易把"我调用了工具、应该产生了某个效果"当作"效果确实发生了"来陈述。报告必须是本会话中观察到的结果，而不是"这一步按理说应该产出什么"的推断。

准则原文对"结果"给出了三个明确的观察来源：

1. 工具输出（tool output）——工具调用返回的内容本身；
2. 文件当前读取到的内容（the file as it now reads）——不是写入时以为的内容，而是现在重新读取文件看到的内容；
3. 页面当前加载的状态（the page as it now loads）——不是请求发出后假设的状态，而是页面此刻实际呈现的状态。

换言之，"done、sent、saved、fixed、verified"这类完成性动词，每一个都必须挂靠在一条可被观察的证据上。这正是 system-prompt-action-safety-and-truthful-reporting.md 中"如实报告结果"（Report outcomes faithfully）的延伸：if tests fail, say so with the output——带着输出说失败；if a step was skipped, say that——说跳过；when something is done and verified, state it plainly without hedging——完成且验证过，就直说。

反例与正例对照

三、核心准则二：未检查，就直说"未检查"

If you did not check, say you did not check. （如果你没有检查，就说你没有检查。）

这条规则堵住了一个隐蔽的滑坡：代理确实执行了某个动作，但由于省略了验证步骤，它转而用"预期结果"填补报告。准则的态度很明确——没有观察就没有声明权，而"未检查"本身就是一个合法的、必须如实披露的状态。

它在 system-prompt-action-safety-and-truthful-reporting.md 中同样有呼应："if a step was skipped, say that"。结合两文，可以归纳出一个实用的分级声明模式：

• 已验证：有工具输出 / 文件回读 / 页面状态为证 → 直说"已确认"；
• 已执行未验证：动作做了，但没回读结果 → 说"已执行，但未验证"；
• 未执行：步骤被跳过或被拒绝 → 说"未执行/被跳过"。

agent-prompt-web-reading-specialist.md 给出了这个分级声明在真实场景中的完整样板：

If a page does not contain what was asked for, or a fetch failed or was denied, say so plainly — name the URL and the HTTP status or error — rather than guessing, so the caller can fetch a denied URL itself. Do not fill gaps from memory.

即：页面抓取失败或被拒绝时，要直说并点明 URL 和 HTTP 状态码或错误，而不是靠记忆补全内容。这正是"未检查就直说"的工程化实践——把失败信息结构化（URL + 状态码），让调用方可以自行重试。

四、核心准则三：失败、跳过、异常结果必须置顶于报告第一句

这是本提示词最具操作性的条款：

If any step failed, was skipped, or came back different from what you expected, say so in the first sentence of your report, before anything else, even when the rest of the work succeeded.

三个触发条件：某一步失败、某一步被跳过、结果与预期不符。只要命中其一，就必须在报告第一句、在任何其他内容之前说出来——即使其余部分全部成功。

这背后的动机是可见性（visibility）与可恢复性（recoverability）：失败信息放在报告的中间或末尾，很容易被用户略过，用户基于不完整的图景做出错误判断；而放在第一句，则无论后面写了什么，用户第一眼就能看见风险。这与 system-prompt-outcome-first-communication-style.md 的"第一句回答发生了什么"形成了机制上的衔接——第一句不仅要给结论，还要优先给"坏结论"。

落地时可以形成这样一个第一句模板：

本次任务完成，但注意：git push返回了错误（非快速前进，被拒绝），其余步骤（构建、测试）均已通过并验证。

五、核心准则四：绝不悄悄绕过失败

Never quietly work around a failure in a way that makes it look resolved; a problem the user can see is recoverable, one your summary hides is not.

这条准则道破了整套规则的最终目的：可见的问题是可恢复的，被隐藏的问题则不可恢复。如果代理遇到失败后，通过一个"看起来像解决了问题"的变通手段悄悄绕过去（例如：测试失败就跳过该测试、文件写入失败就改用临时文件、推送被拒就改写历史），那么：

• 用户看到真实失败 → 可以介入、回滚、调整方案 →可恢复；
• 总结里隐瞒失败 → 用户以为一切正常，问题留在暗处继续发酵 →不可恢复。

因此，"绕过"与"报告"的边界是：绕过之后，用户是否仍能看到原始问题。看不到，就构成隐瞒。这与 system-prompt-executing-actions-with-care.md 中"遇到障碍时，不要用破坏性动作作为捷径把它抹掉"（如用--no-verify跳过安全检查）是同一设计哲学的两面：执行侧不许用变通掩盖风险，报告侧不许用措辞掩盖失败。

六、核心准则五：提前停止时，第一行就要说明并点名遗留事项

When you stop before the task is complete, your first line says so plainly and names what is left.

当代理在任务完成前停止时（无论是主动收手、资源受限、还是等待用户输入），报告的第一行必须直说任务未完成，并点名剩余工作。两个动作缺一不可：

1. 明确状态：第一行即声明"任务未完成"，而不是用"已完成大部分工作"这类含混表述；
2. 点名遗留：具体列出还剩什么——哪个文件没改、哪条命令没跑、哪个验证没做，让用户可以立即接手。

这条规则与仓库中 agent-prompt-general-task-agent.md 对代理的总体要求（"完整地完成任务——不要镀金，但也不要留一半"）互为表里：完整完成是理想状态，而一旦无法完整完成，如实交代"缺什么"就是最低限度的诚实。

七、核心准则六：摘要的确定性不得超过证据

Do not describe partial work as done, and do not let a summary read as more certain than the evidence behind it.

最后一条是对全文的收束，包含两个禁令：

• 不要把部分工作描述成已完成：改了一半的文件、跑了一半的验证、传了一半的数据，都不能用完成时态表述；
• 不要让摘要读起来比证据更确定：摘要使用的确定性程度（"确认""已修复""成功"）必须与证据强度严格匹配。证据只有"执行过命令"，摘要就只能说"已执行"；证据有"回读确认"，摘要才配说"已确认"。

这条准则实际上是前五条的总校验器：第一句置顶失败（准则三）、不隐瞒绕过（准则四）、未完成即点名（准则五），最终都是为了保证摘要所呈现的确定性不超过证据所支撑的确定性。

八、在仓库中的配套与落地证据

除了前述直接关联的提示词，仓库中还有多处实现了"结果报告"精神的具体场景提示词，可作为理解本准则如何落地的参考：

• agent-prompt-code-review-minimal-mode.md：要求在工具调用后在自己的最终回复里复述 findings（每条一行file:line — summary），使结论在不渲染工具输出的会话中依然可见——这正是不允许"声明悬空于证据之外"的工程化处理；
• agent-prompt-background-job-agent-instructions.md：后台任务代理必须用自己的话复述结果（State results in your own text even if a tool already printed them），因为状态提取器看不到工具输出——与"声明必须能被观察者核验"的准则一脉相承；
• system-prompt-outcome-first-communication-style.md：要求"Lead with the outcome"，并以"给离开了一会儿的队友看"的标准组织报告——与本文件"第一句置顶坏消息"配合，构成完整的报告输出规范。

九、实操自查清单

将本文件浓缩为一组可执行的自查问题，供你在编写代理报告（或设计代理提示词）时逐条核对：

1. 证据挂靠：我每个 "done / sent / saved / fixed / verified" 是否都对应一条本会话观察到的结果（工具输出、文件回读、页面状态）？
2. 未检查声明：我有没有跳过验证却说"已验证"？没有检查的地方，是否明确写了"未检查"？
3. 坏消息置顶：本次是否有失败、跳过或异常结果？如果有，是否已在第一句、在其他内容之前说明？
4. 无隐瞒绕过：我是否用变通手段让某个失败"看起来已解决"，而用户其实看不到原始问题？
5. 提前停止声明：如果任务未完成，第一行是否直说了"未完成"并点名遗留事项？
6. 确定性匹配：摘要的措辞强度（确认/已修复 vs 已执行/待验证）是否与证据强度严格一致？

结语

Reporting outcomes全文虽然只有一段，却是一条高度自洽、可直接执行的行为准则：以"观察结果"定义证据（准则一、二），以"第一句置顶"保证可见性（准则三），以"禁止隐瞒绕过"保证可恢复性（准则四），以"未完成即点名"保证交接可续（准则五），以"确定性不超证据"保证整体可信（准则六）。它回答的终极问题是：一个代理凭什么获得用户的信任？——凭它说的每一句"做完了"，都站得住。结合 system-prompt-action-safety-and-truthful-reporting.md、system-prompt-outcome-first-communication-style.md 与 system-prompt-executing-actions-with-care.md 一起阅读，可以还原 Claude Code 在"执行—汇报"全链路上完整的行为约束体系。

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