Office Collaboration Radar (Chinese)

从群聊记录、会议纪要等协作材料中提取稳定格式的协作状态卡片。 用户提到"协作状态""项目进展""待办提取""风险阻断""Owner/DDL""跨部门依赖""需确认项" 或粘贴协作文本时使用；输出协作状态卡片、行动项、风险依赖、证据片段、优先级排序、 雷达图与 JSON 结构化结果，并自动脱敏 PII、强制证据留痕、标记冲突。

Office Collaboration Radar

将近期协作材料转换为一张稳定格式的"协作状态卡片"。本 Skill 是状态提取器，不是周报生成器、催办助手或项目管理系统写入工具。

英文版：Office Collaboration Radar (English)

v0.4.3 核心变化（证据约束 + 双语发布）：

• Owner / DDL 逐字证据约束：process.py enforce 会检查草稿中的负责人和截止时间是否逐字出现在原始材料中；缺少原文支持时统一重置为“未提供”、降为 P2，并加入需人工确认项。
• 空冲突字段修复：空字符串不再被误判为 P0；只有实际存在的冲突标记才进入 P0。
• 双语版本互链：保留独立中英文包，避免混合语言触发和输出，同时明确对应版本入口。

v0.4.2 核心变化（雷达图 + 智能优先级 + 执行摘要）：

• 雷达图可视化 scripts/radar_chart.py：从 7 模块卡片计算项目健康度的 7 个维度（进展透明度/决策确定度/待办健康度/风险可控度/协作畅通度/证据完整度/确认负担），生成 SVG 蜘蛛网图，PM 可一键查看项目协作健康全貌。纯 Python 标准库，零依赖。
• 智能优先级排序：enforce() 中自动为每条行动项标注 P0（有冲突）/ P1（Owner+DDL 齐全）/ P2（信息不完整），并按 P0＞P1＞P2 重排。冲突项自动置顶，PM 不用在海量待办里找紧急项。
• 执行摘要 synthesis：process.py 新增 synthesize()，将 7 模块卡片合成 2–3 句可直接复制的摘要（阶段→待办风险规模→行动建议），PM 可一键贴到项目群。

v0.3.1 核心变化（CSV 公式注入防护）：

• 导出 CSV 公式注入修复（评审安全项）：scripts/export_card.py 在写入 CSV 前对全部用户来源字段做公式前缀（= + - @）转义（前置单引号），避免 task/owner/department/ddl 等以公式前缀开头时在表格软件中触发公式执行。新增 E4 自测覆盖上述前缀。

v0.3.0 核心变化（多工具协同落地）：

• 下游导出器 scripts/export_card.py：将 7 模块卡片按 templates/downstream-field-mapping.md 契约导出为 csv / 飞书多维表格 / Notion Database 字段映射 JSON，落实「多工具协同」落地能力；自带 selftest 对抗用例，已并入主 selftest。
• 中文触发提示：agents/*.yaml 的 default_prompt 改为中文，提升 AstronClaw 在中文场景下的自动唤起命中率。

v0.2.3 核心变化（鲁棒性 + 精度夯实）：

• CLI 输入防御：process.py 全入口捕获坏 JSON / 类型不符 / 文件缺失，统一输出友好中文提示 + 非零退出码，绝不甩 Python Traceback；对抗输入用例已固化进 selftest。
• 证据匹配升级：由「字符集合重合度」升级为「子串命中 + 字符二元组 Dice 相似度 + 阈值」，弱相关句不再被硬挂为证据（返回「未提供」）。
• 银行卡 Luhn 校验：16~19 位数字须通过 Luhn 才脱敏，避免误伤时间戳/订单号等普通长数字串。

v0.2 确定性执行层 scripts/process.py（R1–R5 护城河）：

• R1 证据强制留痕：每条结论必须挂载 ≤40 字证据短片段，找不到时标注「未提供」（不编造）。
• R2 脱敏规则库：手机号/邮箱/身份证/银行卡/姓名等 PII 自动遮蔽为 [手机号] 等占位符。
• R3 跨多轮聚合：多段材料先聚合去重再抽取（见 templates/cross-turn-aggregation-schema.md）。
• R4 Schema 稳定：7 模块键顺序与字段固定，由 scripts/validate_output.py 校验。
• R5 冲突检测增强：同一任务出现不同 Owner/DDL/状态时标记「存在冲突，需人工确认」，并写入需人工确认项。

适用场景

• 用户粘贴群聊记录、会议纪要、飞书/企业微信/钉钉协作文档摘录、项目推进记录。
• 用户要求识别项目进展、已确认决策、Owner/DDL 待办、风险阻断、跨部门依赖、需人工确认项。
• 用户需要把非结构化协作文本整理为可复制到周会、项目群、PM 复盘文档中的状态卡片。
• 用户要求输出稳定 Markdown 卡片和 JSON 结构化结果，便于后续系统解析。

不适用场景

• 不生成完整周报、日报、OKR 汇报或绩效评价。
• 不替用户发送催办消息、会议邀请、邮件或 IM。
• 不自动修改 Jira、飞书多维表格、Notion、CRM、日历或其他外部系统。
• 不判断个人绩效，不对协作方作主观评价。
• 不从材料之外补全事实、Owner、DDL、决策结论或部门责任。

输入格式

接受以下输入之一或组合：

• Markdown、纯文本、聊天导出、会议纪要、项目日志。
• 多段材料，建议用标题标明来源，例如"群聊记录""会议纪要""项目日志"。v0.2 支持多段材料：先按 templates/cross-turn-aggregation-schema.md 做跨多轮聚合。
• 可选元信息：项目名、材料时间范围、涉及部门、期望输出语言。
• 可选实体名单（已知成员真名等），用于更准的脱敏，可传入 process.py --entities。

如果用户未提供项目名、时间范围或部门信息，在输出中标注"未提供"，不要自行推断。 默认使用用户输入的主要语言输出；如果用户明确指定输出语言，则按用户指定语言输出。

分析流程

1. 识别材料边界：区分事实、观点、提问、待确认信息、玩笑闲聊和重复内容。
2. 抽取项目状态：总结当前阶段、总体状态、最近进展、下一步焦点。
3. 提取已确认决策：只记录材料中明确达成一致、拍板、确认采用、确认延期或确认上线的事项。
4. 提取 Owner × DDL 待办：优先识别明确责任人、部门、动作、截止时间和交付物。
5. 提取风险、阻断和依赖：区分风险、已发生阻断、跨部门依赖、外部依赖。
6. 建立跨部门协作关系：描述部门之间的请求、交付、等待、确认、审批或联调关系。
7. 标记需人工确认项：将信息缺失、冲突、表达模糊、未明确 Owner/DDL 的事项列出。
8. 附证据片段：每个关键结论尽量附 1 条短证据；证据不超过 40 个中文字符；没有证据时标注"未提供"。
9. 输出固定结构：按"输出格式"中的标题顺序输出，不因信息缺失删除模块。
10. 生成 JSON：字段必须稳定；未知值使用 "未提供"，冲突值使用 "存在冲突，需人工确认"。
11. v0.2.2 强制执行层（必做）：把抽取出的卡片 JSON 与原始材料交给 scripts/process.py 加固——
    • 单段材料：python scripts/process.py enforce --card <草稿.json> --source <原始材料.txt> [--entities 名单.txt]
    • 多段材料：先 aggregate 合并，再 enforce。
    • 该步骤会（a）校验 Owner / DDL 是否有逐字原文支持；（b）脱敏所有 PII（R2）；（c）为每条结论补证据（R1）；（d）标记同任务冲突（R5）；（e）校验 7 模块顺序（R4）；（f）自动标注 P0/P1/P2 优先级并重排；（g）生成执行摘要置于元信息中。
    • 雷达图：python scripts/radar_chart.py generate --card <加固后卡片.json> --out radar.svg
    • 发布前运行 python scripts/process.py selftest 与 python scripts/validate_output.py 确保全绿。

工具链编排

本 Skill 定位为协作信息处理链路中的中枢提取器，两端可与其它工具/插件协同，形成「转写 → 提取 → 落表」的完整闭环：

text

[上游·多模态转文本]                [本 Skill·雷达提取]              [下游·落表/同步]
语音会议/录音 ──ASR──▶                                        ┌─▶ 飞书多维表格（字段映射）
纪要截图/白板 ──OCR──▶  纯文本材料 ──▶ process.py enforce ──▶ ┼─▶ Notion Database
IM 群聊导出   ──────▶  (可多段)       ├ 脱敏/证据/冲突/Schema  └─▶ 周会文档 / PM 复盘
                                       ├ 优先级 P0/P1/P2 排序        │
                                       └ radar_chart.py ──▶ SVG 雷达图

上游（接受任意来源的纯文本）：本 Skill 只消费文本，不绑定采集方式。任何上游工具把语音/图片/文档转成文本后，均可作为 --source 输入：

• 语音会议、录音 → 经 ASR 转写 → 喂入雷达；
• 纪要截图、白板照片 → 经 OCR 识别 → 喂入雷达；
• 飞书/企业微信/钉钉群聊导出 → 直接喂入。 多来源材料先用 process.py aggregate 跨轮聚合去重，再 enforce。

下游（结构化卡片 → 外部系统字段映射）：enforce 产出的 7 模块 JSON 已是稳定 Schema，可映射到主流协作系统。字段映射对照见 templates/downstream-field-mapping.md：

卡片模块	飞书多维表格	Notion Database
action_items[].task/owner/ddl	任务名 / 负责人 / 截止日期	Title / Person / Date
risks_dependencies[]	风险描述 / 类型 / 影响	Text / Select / Text
needs_human_confirmation[]	待确认项 / 建议确认对象	Text / Person
confirmed_decisions[]	决策内容 / 证据	Text / Text

说明：下游写入遵循本 Skill 的只读边界——本 Skill 只产出映射后的结构化数据与字段对照，实际写入由用户在其 PM 系统或对应连接器中完成，Skill 不代为执行外部写操作。

输出格式

固定输出一张 Markdown 协作状态卡片，标题和顺序保持稳定：

markdown

# 协作状态卡片

## 项目状态总览

## 已有进展

## 已确认决策点

## Owner × DDL 待办列表

## 风险 / 阻断 / 依赖

## 跨部门协作关系

## 需人工确认项

## JSON 输出

使用 templates/collaboration-status-card.md 作为卡片结构参考。行动项字段参考 templates/action-items-schema.md，风险依赖字段参考 templates/risk-dependency-schema.md，JSON 字段参考 templates/json-output-schema.md，置信度呈现参考 templates/confidence-schema.md，跨多轮聚合参考 templates/cross-turn-aggregation-schema.md，下游落表字段映射参考 templates/downstream-field-mapping.md。

鲁棒性规则

• 不编造未提供的 Owner、DDL、会议结论、部门归属、风险等级或上线时间。
• 草稿中的 Owner / DDL 必须逐字出现在原始材料中；否则重置为“未提供”，并加入需人工确认项。
• 缺失信息统一标注"未提供"。
• 冲突信息统一标注"存在冲突，需人工确认"，并在证据片段中列出冲突来源。
• 每个关键结论必须附材料中的短证据片段；证据不超过 40 个中文字符，不大段复制原文；无证据标"未提供"（R1）。
• 对异常输入给出可恢复提示，例如"请补充近期协作文本、会议纪要或聊天记录后重试"。
• 输出结构必须稳定，即使某模块没有内容，也保留标题并写"未提供"。
• 不自动发送消息，不生成强制催办，不修改外部系统。
• 对疑似隐私、密钥、token、客户敏感信息只做最小必要引用，输出前由脱敏规则库统一遮蔽（R2）。
• 对闲聊、情绪表达、重复确认和无关背景进行降噪，只保留与项目状态相关的信息。
• Markdown 表格注入防护（v0.4.2）：写入 Markdown 表格单元格的用户来源内容（项目名、待办、风险描述、证据片段等）必须做字符转义——| → \|、\ → \\、换行 → 空格、< > & → XML 实体、[ ] → \[ \]。该清洗由 process.py enforce 的 sanitize_markdown_cell() 递归执行，确保不论 LLM 产出还是确定性加工，最终卡片 JSON 中所有字符串均已通过此规则。

安全合规规则

• 不输出真实 API Key、token、密码、身份证号、手机号、邮箱等敏感信息的完整值；由脱敏规则库（R2）统一遮蔽为 [手机号]/[邮箱]/[身份证号]/[银行卡号]/[姓名]。
• 不将材料中的个人表达转化为绩效判断、责任归咎或人身评价。
• 不把模糊意向写成正式承诺。
• 不替用户作出法律、财务、人事或采购审批结论。
• 不执行任何外部系统写入、消息发送或自动化催办动作（默认只读）。

示例调用

用户可以这样请求：

text

请用 office-collaboration-radar 分析下面这段企业 AI 知识库助手灰度上线群聊和评审纪要，输出协作状态卡片。

text

帮我从这段会议纪要里整理项目状态，不要写周报，只要协作状态卡片和 JSON。

示例材料见：

• examples/scenario-e-enterprise-ai-knowledge-assistant-rollout/
• examples/scenario-b-feishu-ai-meeting-assistant/
• examples/edge-case-conflicts-and-missing-info/
• examples/scenario-v02-enforce-demo/（v0.2.2 演示：草稿经 process.py enforce 加固，展示 R1/R2/R5）

已知限制

• 对强口语化、缺少上下文或跨多天断裂的聊天材料，可能只能输出保守结论。
• 对图片、语音、表格截图，需要先由上游工具（ASR/OCR）转成文本，详见「工具链编排」。
• 无法验证材料外事实的真实性，只能基于用户提供内容提取状态。
• 同名人员消歧（v0.2.2 部分为规划能力）依赖材料提供部门、角色或上下文；已知实体名单可提升脱敏准确率。
• JSON 结构保证稳定，但字段内容粒度受输入材料质量影响。
• 跨多轮聚合为基础版：按（任务, Owner）去重合并，不保证语义级消歧。