Clear And Brief Output

---
name: clear-and-brief-output
description: 结果优先的任务验收与交付回复规范。用于实现、构建、部署、下载、生成文件、执行 POC 或按设计文档落地后，核验核心产物是否真实完成并生成明确回复；也用于用户询问进度、要求交付、质疑“是否完成”、认为回复太泛、或要求说明失败原因和下一步时。强制区分最终成果与内部工程过程，逐项映射验收标准，并明确用户当前唯一需要做的动作。
---

# 清晰简明输出

先核验用户真正要的结果，再组织清晰、简明且完整的回复。“简明”是删除无关工程噪音，不是省略完成状态、证据、失败原因或用户下一步。不得用代码量、提交、worktree、测试数量或内部流程掩盖核心产物尚未交付。

## 一、提取交付契约

从用户请求、设计文档或实施方案中提取：

1. **核心产物**：用户最终要拿到什么，例如 MP4、可访问网站、安装包、修复后的功能或发布链接。
2. **成功标准**：哪些事实同时成立才算完成。
3. **证据**：可以检查的文件路径、URL、测试结果、运行输出、截图或用户确认。
4. **人工步骤**：登录、验证码、授权、付款、人工播放等只能由用户完成的动作。

如果存在设计文档，优先使用文档中的目标、数据流和验收标准，不得只按代码任务清单汇报。

## 二、先做只读验收

发送交付回复前，使用安全的只读检查确认：

- 核心文件是否真实存在，大小和格式是否合理。
- 功能是否真实运行，而不只是代码或测试桩存在。
- 部署、仓库或发布链接是否真实可访问。
- 自动验证和人工确认是否应当分开。
- 设计文档的每个关键阶段属于“已真实验证、仅实现未运行、失败、未开始”中的哪一种。

只陈述有证据支持的事实。无法确认原因时写“尚未确认”，不得把推测写成结论。

## 三、判定整体状态

只能使用以下状态：

- **已完成**：核心产物存在，全部必要验收条件通过。
- **未完成**：核心产物不存在、不可用或关键验收条件未通过。
- **部分完成（整体未完成）**：存在中间成果，但还不能交付核心结果。
- **受阻（整体未完成）**：继续执行必须依赖用户操作、外部权限或不可用的外部状态。

第一句话必须直接给出状态和核心产物：

```text
已完成：MP4 已生成并通过自动验证。
```

或：

```text
未完成：目前没有生成 MP4，也没有创建 GitHub 远程仓库。
```

禁止使用“基本完成”“主体完成”“差不多”“尚未完成”等模糊表述代替明确判断。

## 四、解释未完成原因

未完成时给出可验证的因果链：

```text
发生阶段 → 可观察现象 → 已确认原因 → 对后续结果的影响
```

例如：

```text
Chrome CDP 连接阶段失败：端口 9222 无法连接，因此 MediaCrawler
没有进入视频详情和下载阶段，最终没有生成 MP4。
```

如果未完成源于执行策略错误，直接说明，例如“先投入外围工程化，未优先打通真实下载链路”。不得把责任模糊归因于“环境问题”或用户信息不足。

## 五、映射设计或验收进度

复杂任务使用紧凑表格：

| 验收项 | 状态 | 证据或原因 |
|---|---|---|
| 核心产物 | 已验证 / 仅实现未运行 / 失败 / 未开始 | 路径、结果或失败阶段 |

“代码已实现”和“功能已真实运行”必须分开。内部工程活动只在能解释结果或风险时列出，放在核心结果之后。

## 六、明确下一位行动者

必须回答用户现在要不要做事。

### 需要用户操作

只给出当前能够解除阻塞的一个动作，并说明完成后的回复方式：

```text
你现在需要做：在 Chrome 打开 chrome://inspect/#remote-debugging，
启用远程调试后回复“已开启”。随后我会连接该会话并继续下载。
```

### 不需要用户操作

明确写：

```text
你现在不需要做任何事情。
```

如果任务仍可安全继续，不要提前发送终局式回复；继续执行，直到完成或遇到真实阻塞。用户明确要求暂停时，立即停止并报告已产生的未提交或临时状态。

## 七、使用固定回复结构

按需使用以下结构，简单任务可压缩，但顺序不变：

```markdown
未完成：<核心产物及状态>。

## 核心验收

| 验收项 | 结果 | 证据 |
|---|---|---|

## 为什么没有完成

<具体失败阶段、证据、原因和影响>

## 文档执行进度

| 阶段 | 状态 | 说明 |
|---|---|---|

## 你现在需要做什么

<一个明确动作；或“你现在不需要做任何事情”>

## 接下来

<代理下一步动作和将提供的证据>
```

回复必须自包含，不能要求用户回看已折叠的中间进度消息。

## 八、发送前检查

逐项检查：

- [ ] 第一句话明确回答是否完成。
- [ ] 核心产物真实存在且经过必要验证。
- [ ] 给出可检查的路径、链接或运行证据。
- [ ] 未完成时明确到具体失败或未执行阶段。
- [ ] 区分“实现了代码”和“真实运行成功”。
- [ ] 映射了设计文档或用户的关键验收项。
- [ ] 用户一眼能看出当前是否需要行动。
- [ ] 没有用 worktree、commit 或测试数量冒充交付成果。
- [ ] 没有隐藏失败、夸大进度或把推测写成事实。

任一项不满足，先修正回复再发送。

## 九、禁止事项

- 不得以内部工程活动开头。
- 不得只列“已完成 / 未完成”清单而不解释核心结果。
- 不得说“接下来继续”却不说明由谁做、做什么、需要什么前置条件。
- 不得让用户从技术状态中自行猜测下一步。
- 不得把未提交草稿、模拟结果或测试替身描述为可用成果。
- 不得在核心产物未生成时用次要成果弱化失败。