lxd-report

SKILL.md

---
name: lxd-report
description: 分析用户输入的工作汇报/汇报稿内容,识别其中缺失的关键信息,模拟预测汇报效果,并给出下一步改进建议(每次最多3条)。当用户粘贴一段汇报稿、周报、周会发言稿、项目进展汇报、复盘内容,或说"帮我看看这段汇报""这个汇报效果怎么样""帮我完善一下汇报"时,使用此技能。即使用户没有明确要求"分析",只要提供的内容明显是要对上级/团队做的工作汇报草稿,也应主动使用此技能进行诊断。
---

# Report Analyzer(汇报分析器)

把一段汇报内容想象成对函数 `REPORT()` 的一次调用:用户输入的汇报稿,就是这次调用尝试传入的"参数值"。本技能的任务是解析这次调用、找出缺失的关键参数、以表格形式返回诊断结果,并且每次最多给3条改进建议——控制信息量,避免用户一次面对太多问题而产生阅读压力。

用户每补充/修改一次内容,就视为对同一个 `REPORT()` 的重新求值:必须整体重新解析,而不是在旧结果上打补丁,因为新信息可能改变其它参数原本的判断。

---

## REPORT() 函数说明

## Metadata(函数信息)
```
函数名:   REPORT(背景目标, 当前进展, 数据证据, 问题风险, 下一步计划, 需要支持, 汇报受众, 时间范围)
类别:     沟通/管理类
适用场景: 工作汇报、周报/月报、项目进展汇报、复盘、对上汇报稿
求值方式: 每次用户提供新版本内容,视为对同一调用的重新求值,不做增量修补
```

## Description(功能说明)
`REPORT()` 接收一段描述工作进展/结果的自然语言文本,尝试将其解析为下方定义的结构化参数。一次"合格"的调用,应当让听众读完/听完后清楚知道:发生了什么、结果如何、还有什么问题、接下来打算做什么、需要谁配合什么。本技能检查这次"调用"是否具备这些参数——缺失必需参数则报错,存在但质量不足则提示,全部合规则给出汇报效果预测。

## Parameters(参数定义)

| 参数 | 是否必需 | 说明 |
|---|---|---|
| 背景目标 | 必需 | 这次汇报是关于什么任务/目标的,为什么现在要汇报这个 |
| 当前进展 | 必需 | 目前做到什么程度、发生了什么、结果如何 |
| 数据证据 | 建议 | 支撑"进展"的具体数字、指标、事实(而非"进展顺利"这类空话) |
| 问题风险 | 可选 | 遇到的困难、阻碍、风险点 |
| 下一步计划 | 必需 | 接下来打算做什么,最好带时间点 |
| 需要支持 | 可选 | 需要对方做什么决策、提供什么资源 |
| 汇报受众 | 可选 | 汇报对象是谁(老板/团队/客户),决定详略与语气 |
| 时间范围 | 可选 | 汇报覆盖的时间段(本周/本月/本项目周期) |

**状态只分两种**(不设第三档,避免选择困难):
- **命中** — 原文里能直接看到或能合理推断出这个信息
- **缺失** — 原文完全没有涉及

## Validation(参数校验)
- 背景目标缺失 → 报错
- 当前进展缺失 → 报错
- 下一步计划缺失 → 报错
- 当前进展命中但数据证据缺失 → 提示
- 问题风险命中但下一步计划没有呼应这个问题 → 提示
- 内容前后矛盾(如声称"进展顺利"却在问题风险里说被卡住,且未解释)→ 报错
- 需要支持命中但表述模糊(如"希望大家多支持")→ 提示
- 内容详略程度与推测出的汇报受众不符(如对老板汇报却堆满技术实现细节)→ 提示

## Error Codes(错误码,必须优先解决)
- `#缺背景目标!` — 听众不知道为什么要听这次汇报
- `#缺当前进展!` — 没有说清楚具体做了什么、结果如何
- `#缺下一步!` — 汇报没有闭环
- `#前后矛盾!` — 内容自相矛盾
- `#信息不足!` — 内容太少太模糊,无法判断

## Warnings(提示,优先级低于错误码)
- `⚠证据不足` — 有描述但缺可验证的数据支撑
- `⚠问题未闭环` — 提出了问题但没有对应的应对计划
- `⚠诉求模糊` — 提到需要支持,但没说清楚具体要什么
- `⚠受众不匹配` — 详略程度/语气与推测受众不匹配

## Runtime(运行逻辑)
1. **解析**:将输入内容映射到上述 8 个参数,每个参数只标"命中"或"缺失"。
2. **校验**:跑一遍 Validation 规则,得到本轮触发的错误码和提示的完整列表(内部使用,不必全部展示给用户)。
3. **限量输出**:按优先级(必需参数缺失 > 前后矛盾 > 提示类)排序,**最多只取前3条**呈现给用户——包括表格里的备注和"下一步建议"都只围绕这3条展开,其余问题本轮不提。等这3条改完、用户重新提交后再解析,才会暴露后面的问题。
4. **等待用户更新**:用户按建议修改后,回到第1步,对新内容做一次完整重新解析,而不是在旧结果上打补丁——新信息可能让"缺失"变"命中",也可能出现新的矛盾。
5. **无错误时给预测**:当本轮没有任何错误码触发(哪怕还有提示)时,不再输出"修改建议",转而输出"模拟汇报效果"。

## Return（返回值）

REPORT() 的返回值，不是一篇汇报稿，而是一次汇报所期望达成的结果（Expected Outcome）。

技能需要根据用户输入的内容，推断用户真正希望通过这次汇报获得什么。

如果用户已经明确表达目标，则整理并输出。

如果用户没有表达，或目标模糊，则指出这是本次汇报最大的缺失之一，并提供可参考的目标选项。

### Return 可以有哪些类型

实际上，大部分工作汇报，目的只有几类。

例如：

| 类型        | 返回值           |
| ----------- | ---------------- |
| Inform      | 告知进展         |
| Decision    | 希望领导做决定   |
| Support     | 希望获得资源支持 |
| Approval    | 希望批准方案     |
| Alignment   | 希望统一认知     |
| Escalation  | 希望升级问题     |
| Feedback    | 希望获得反馈     |
| Recognition | 希望展示成果     |

### Return Suggestions（目标建议）

当触发 #缺返回值! 时，AI 不仅需要指出问题，还应根据上下文推测用户可能真正的汇报目标。

如果无法唯一判断，应给出多个最可能的目标供用户参考，并说明不同目标会导致不同的汇报重点。

例如：

"如果你的目的是获得资源支持，
建议重点突出当前阻碍和需要的资源。"

"如果你的目的是让领导做决策，
建议明确列出需要领导拍板的问题。"

"如果你的目的是同步项目进展，
建议突出完成情况和下一步计划。"

## Output(输出格式)

ALWAYS 使用下面的模板:

```
【本轮参数解析】
| 参数 | 状态 | 备注 |
|---|---|---|
| 背景目标 | 缺失/命中 | 我们从原文里理解到的内容,没有则写"未提及" |
| 当前进展 | 缺失/命中 | ... |
| 数据证据 | 缺失/命中 | ... |
| 问题风险 | 缺失/命中 | ... |
| 下一步计划 | 缺失/命中 | ... |
| 需要支持 | 缺失/命中 | ... |
| 汇报受众 | 缺失/命中 | ... |
| 时间范围 | 缺失/命中 | ... |

【本轮建议】(最多3条,按优先级从高到低)
1. [错误/提示标签] 建议内容
2. [错误/提示标签] 建议内容
3. [错误/提示标签] 建议内容

【模拟汇报效果】(仅在本轮没有错误码时给出,与上面的建议二选一展示)
如果现在就这样汇报,听众大概会是什么反应,可能追问什么,还有什么隐患
```

### Examples(示例)

**示例 1:信息单薄**
输入:"这周把用户登录模块的开发做完了。"

输出:
```
【本轮参数解析】
| 参数 | 状态 | 备注 |
|---|---|---|
| 背景目标 | 缺失 | 未说明属于哪个项目/为什么现在汇报 |
| 当前进展 | 命中 | 登录模块开发已完成 |
| 数据证据 | 缺失 | 未提供可验证的数据 |
| 问题风险 | 缺失 | 未提及 |
| 下一步计划 | 缺失 | 未说明后续安排 |
| 需要支持 | 缺失 | 未提及 |
| 汇报受众 | 缺失 | 未说明对象 |
| 时间范围 | 命中 | 本周 |

【本轮建议】
1. [#缺下一步!] 补充下一步计划——开发完成后接下来做什么(比如联调、测试),没有这一句会显得像"交差"而不是"推进项目"
2. [#缺背景目标!] 补充这属于哪个项目/为什么现在汇报,让听众有上下文
3. [⚠证据不足] 补充一个可验证的完成情况,比如自测是否通过
```

**示例 2:用户补充下一步和背景后**
输入(在示例1基础上追加):"这是账号体系项目的一部分。下一步是下周一开始联调,预计周三前完成。"

输出:
```
【本轮参数解析】
| 参数 | 状态 | 备注 |
|---|---|---|
| 背景目标 | 命中 | 账号体系项目的一部分 |
| 当前进展 | 命中 | 登录模块开发已完成 |
| 数据证据 | 缺失 | 未提供可验证的数据 |
| 问题风险 | 缺失 | 未提及 |
| 下一步计划 | 命中 | 周一联调,周三前完成 |
| 需要支持 | 缺失 | 未提及 |
| 汇报受众 | 缺失 | 未说明对象 |
| 时间范围 | 命中 | 本周至下周三 |

【本轮建议】
1. [⚠证据不足] 补充一句验证方式或完成度指标(比如"自测已通过,核心用例覆盖率90%"),让"完成"这个结论更可信
```

**示例 3:较完整版本**
输入:"这周登录模块开发完成并自测通过,核心用例覆盖率90%。中间遇到第三方短信验证码接口偶发超时的问题,已经加了重试机制,暂时缓解但还没根治。下周一开始联调,预计周三前完成,如果周三之前测试组能配合插入这个联调,我们可以按原计划上线。"

输出:
```
【本轮参数解析】
| 参数 | 状态 | 备注 |
|---|---|---|
| 背景目标 | 命中 | 推断为账号体系相关的项目进展汇报 |
| 当前进展 | 命中 | 开发完成,自测通过,覆盖率90% |
| 数据证据 | 命中 | 覆盖率90% |
| 问题风险 | 命中 | 短信验证码接口偶发超时,已缓解未根治 |
| 下一步计划 | 命中 | 周一联调,周三前完成 |
| 需要支持 | 命中 | 需要测试组配合插入联调 |
| 汇报受众 | 命中 | 推断为对上级/项目相关方 |
| 时间范围 | 命中 | 本周至下周三 |

【模拟汇报效果】
这版信息已经比较完整:有结果、有数据、有风险点、有计划、也提出了具体诉求。听众大概率不会追问基础信息,但可能会关心"超时问题不根治,会不会影响上线后的稳定性",可以提前想好这个问题的答案,汇报会更从容。
```