汇报分析器

要解决的问题

一份合格的工作汇报，听众读完后应当清楚：发生了什么、结果如何、还有什么问题、接下来做什么、需要谁配合。但实际写汇报时，人们经常漏掉这些关键信息——可能写了一大段「进展顺利」，却没有一个可验证的数据；或者提了一堆问题，却没有对应的下一步计划。读的人要反复追问，写的人要反复补充，来回几轮汇报才成型。

这个技能把「检查汇报是否合格」变成一次确定性的解析过程，而不是依赖模型自由发挥的泛泛点评。

核心工作方式

把汇报当作一次函数调用。 输入文本被视为对 REPORT() 的调用尝试，技能将其映射到 8 个结构化参数：

• 背景目标、当前进展、下一步计划：必需，缺失即报错
• 数据证据：建议提供，缺失时提示
• 问题风险、需要支持、汇报受众、时间范围：可选

状态只有两档。 每个参数要么 命中（原文可见或能合理推断），要么 缺失（原文完全没涉及）。没有中间态，诊断结果不会含糊。

校验分两级。 必需参数缺失或内容自相矛盾触发错误码（如 #缺下一步!、#前后矛盾!）；证据不足、问题未闭环、诉求模糊、受众不匹配触发提示（如 ⚠证据不足）。错误码优先解决。

限量输出，逐轮收敛。 每轮最多只呈现前 3 条问题，按「必需缺失 > 前后矛盾 > 提示类」排序。用户改完重新提交时，技能对全文做一次完整重新解析，而不是在旧诊断上打补丁——新信息可能让原本 缺失 的项变成 命中，也可能暴露新的矛盾。

推断汇报的真实目标。 没有错误码触发时，技能不再提修改建议，转而输出模拟汇报效果，并根据内容推断 Return 类型（告知进展、请求决策、争取资源、寻求批准等）；目标模糊则指出这是最大缺失之一，给出几个可能的目标选项。

适用边界

• 它是诊断器不是写作器：输出结构化诊断和改进建议，不重写汇报稿。
• 每轮 3 条的上限意味着问题会分轮暴露，想一次性改完需要多轮交互。
• 命中 允许合理推断，但依据必须来自原文，不会凭空补全没说的信息。
• 受众匹配和 Return 类型都是推测，上下文太少时可能误判。