zxremail AI 工作成果说明（抽检过审框架）
帮助用户填写公司 AI 使用成果报告，降低抽检不通过与信用分扣减风险。
默认工作流（用户给飞书链接时 — 必须遵守）
用户后续典型输入：一份或多份飞书文档链接 + 要求生成可直接复制粘贴的成果说明。
禁止未读文档就凭记忆撰写；禁止编造文档中不存在的表格、数据、截图或结论。
用户给出飞书 URL
→ 读 lark-doc + lark-shared SKILL
→ lark-cli docs +fetch（大文档分页）
→ 提炼证据（数量、数据、章节）
→ 按 template + checklist 写四段
→ 输出纯文本（无 Markdown 表）供复制
飞书 CLI 读取（必做）
- 先 Read：
lark-doc与lark-shared的 SKILL.md（路径见用户~/.agents/skills/lark-doc/、lark-shared/；认证、权限）。 - 拉取正文（每条用户链接各执行一次）：
lark-cli docs +fetch --doc "<飞书 URL 或 docx token>" --as user --format pretty
/docx/、/wiki/URL 均可；wiki 若类型不明，按 lark-doc 先wiki spaces get_node再 fetch。- 输出过大时：
--offset/--limit分页读完，或读命令写入的 agent-tools 文件。 - 画板
<whiteboard token="..."/>、图片<image token="..."/>：正文可能只有占位；在「输出成果」中按文档已载明的表/数据/截图章节计数，勿虚构画板内容。
- 可选：用户另给计划完成标准、驳回说明（如 fail.txt）、ROI 档位要求 → 一并纳入，对齐 anti-patterns.md。
交付给用户的形式（固定）
只输出一段纯文本（与 template.md 四节标题一致），方便整段或分节粘贴进表单：
成果说明
1. 使用场景
…
2. 如何使用
…
3. 输出成果
…
4. 成果证明链接
…
- 不用复杂 Markdown 表格；列表用「步骤1：…」「- …」或自然段。
- 第 4 节必须包含用户提供的原始飞书链接；若有多份文档，主报告写前并注明「审核优先点开哪条」。
- 写完后在回复末尾附 checklist 自检结果（3～5 条 bullet，说明已对齐计划标准/数量/链接），不必把 checklist 放进粘贴正文。
其它触发场景
无飞书链接、仅有本地 md/驳回记录时：先读用户文件，再按下方通用流程；若缺证明链接，提醒用户补飞书文档后再填第 4 节。
撰写前按需 Read：
- template.md
- checklist.md
- anti-patterns.md
- examples.md
官方硬性要求（摘要）
| 字段 | 必须做到 | 禁止 |
|---|---|---|
| 使用场景 | 业务背景 + 要解决的问题 + 为何用 AI；对齐计划完成标准 | 一句话、与动作重复、只写「搭环境/写方案」 |
| 如何使用 / 采取的动作 | 分步骤写清做了什么 + 用什么工具 + 对应哪份产出 | 「已完成」「已优化」；与场景同句复述 |
| 输出成果 | 形态 + 数量（如 2 份飞书文档、3 张对比表、1 段脚本）+ 执行结果/数据/结论 | 只有过程没有结果；只有方案没有实测 |
| 成果证明链接 | 组织内可访问，点开即见证据 | 仅本地文件无链接；链接内容与描述不符 |
| ROI 自评 | 节省时间 / 采纳 / 影响范围与实际交付规模相称 | 夸大档位引发人工追问 |
本地/HTML/IDE 截图无公网链接时：新建飞书云文档，按 背景 → 方法 → 结果 贴关键截图与说明，用该链接作证明。
工作流（推荐顺序）
1. 对齐计划标准 → 2. 执行并留痕 → 3. 沉淀飞书证明 → 4. 按模板写四段 → 5. checklist 自检 → 5. 用户提交
Step 1：对齐计划完成标准
从用户任务/计划中摘录完成标准（动词：验证、分析、交付、上线等）。后续四段内容必须能回答：「标准里的每一项，证据在哪？」
常见偏差（见 anti-patterns.md）：
- 标准是「验证过程」→ 不能只写环境搭建、方案设计
- 标准是「分析报告」→ 不能只写收集了数据没有结论
Step 2：执行时留痕（便于写「如何使用」）
执行过程中主动记录（可让用户补充）：
- 工具名：Cursor、飞书、CLI、脚本名、SSH 目标等
- 每步产出物：文件名、章节号、表/图数量
- 可量化结果：指标数值、通过/失败、对比前后
Step 3：成果证明（飞书优先）
- 主文档结构：背景 → 方法 → 结果（方法含步骤与命令/工具；结果含表、图、截图、结论）
- 权限：组织内可见或获得链接可阅读；提交前用无权限账号点开自检
- 主报告放完整证据；若需第二份，可为概要/索引页
- 证明链接字段：优先填内容最全的一条；多条链接分行列出并注明各自可见证据
Step 4：生成四段正文
使用 template.md 结构输出：
- 使用场景
- 如何使用（= 采取的动作；建议「步骤N + 工具 + 产出」）
- 输出成果（先清单数量，再关键数据/结论）
- 成果证明链接
同时提供：
- 可直接粘贴的纯文本版（无复杂 Markdown 表，方便表单）
- 若用户需要，单独给出 ROI 自评理由 一段（与档位匹配）
Step 5：提交前自检
逐项执行 checklist.md。未通过项必须改文案或补飞书内容后再交付用户。
写作规则
- 数量具体化：用「N 份 / N 张 / N 组」替代「若干」「多个」
- 动作可核对：每一步能在证明链接中找到对应章节、截图或附件
- 结果可验证：含至少 1～3 条关键数据或明确判定（通过/不通过/根因）
- 场景与动作不重复：场景讲 Why；动作讲 How + What delivered
- 中文简体；用户若提供计划原文中的标准表述，原样保留关键短语
ROI 自评参考（须与交付相称）
| 档位 | 适用情形（示例） |
|---|---|
| 节省时间 <2h | 单篇短文、少量表格、无多轮实测 |
| 2～8h | 中等文档 + 部分自动化 |
| 8h 以上 | 多轮执行、长文档、大量数据整理/脚本/多份证明 |
| 结果采纳「作为参考」 | 供评审/决策，非直接合入发布物 |
| 影响范围「小组」 | 组内技术验证、方案讨论 |
在建议档位时附 1～2 句理由，避免与交付清单明显矛盾。
输出格式约定
默认向用户交付：
成果说明
1. 使用场景
（正文）
2. 如何使用
（正文）
3. 输出成果
（正文）
4. 成果证明链接
（URL，每条说明可见证据）
可选附录：ROI 自评建议（若用户未在表单中单独填写）。
与其它 Skill 协作
| 场景 | Skill |
|---|---|
| 读取/更新飞书证明文档 | lark-doc |
| Markdown 转飞书 | markdown-to-feishu-doc |
| 导出本地 md 存档 | markdown-export |
示例触发语
- 「这是飞书文档链接，用飞书 CLI 读完后给我可复制粘贴的成果说明」→ 走默认工作流
- 「根据这份飞书文档填成果说明四段」
- 「我上次被驳回了，帮我按官方要求重写」→ 必读 anti-patterns.md