从会议纪要快速撰写微信公众号文章

概述

将海报、飞书/ Lark 会议纪要（Minutes）、会议录音文字稿以及粗略笔记等事件材料，转化为可发布的微信公众号文章；并可选地创建飞书文档，同时验证内容是否真实落地。

复用已有的飞书和网页能力作为基础模块。本技能定义了端到端的编辑工作流、事实核查规范、文档交接机制及验证框架。

所需技能与工具

• 使用 lark-minutes 获取 Minutes 元数据；使用 lark-vc/vc +notes 获取录音文字稿及 AI 生成的辅助产物。
• 在创建、更新或检查飞书文档时，使用 lark-doc。
• 使用 web-access 或可用的网页搜索进行公开事实核查。优先采用官网、第一方页面等权威信源。
• 对海报类图像，结合图像查看与 OCR 判断能力进行识别；依据海报原文及公开信源，主动修正 ASR/OCR 错误。

调用任一被引用技能前，请先阅读其 SKILL.md 及所要求的参考文档。

成功标准

• 从海报与 Minutes 中准确提取事件事实：标题、时间、地点、主办方、承办方、议程、演讲人姓名/职务、核心活动流程。
• 主要观点须源自原始录音文字稿或海报内容；AI 生成的摘要/章节仅作辅助参考，不可直接作为发布依据。
• 凡影响最终发布文本的组织名、人名、项目名、公司名，均需通过公开信源交叉核验。
• ASR/OCR 错误须明确修正，例如当海报或公开信源支持时，将 宜高 修正为 颐高。
• 成文应具备微信公众号文章的人工编辑质感，而非会议纪要的简单堆砌。
• 若用户要求创建飞书文档，则须在 fetch/readback 校验确认正文内容已真实写入后，返回最终文档 URL。

工作流

1. 明确输入与验收条件

识别可用材料：

• 海报或图像路径。
• 飞书/Lark Minutes URL 或 minute_token。
• 用户指定的发布渠道、语调、篇幅、标题风格或其它发布约束。
• 用户仅需草稿文本，还是同时需要飞书文档。

若请求存在模糊但属安全可推定情形，按默认微信公众号文章处理：

• 1 个主标题。
• 正文长度为 800–1400 字（除非材料本身明显需要更长篇幅）。
• 结构顺序为：导语 → 事件事实 → 平台/背景介绍 → 演讲亮点 → 资源对接/交流匹配 → 结尾收束。
• 仅当对用户审阅有实质帮助时，文末附简短“核验说明”；若用户明确要求“干净稿”，则终稿中省略此项。

2. 构建证据支撑体系

对于 Minutes URL，从 URL 最终路径段提取 token：

lark-cli minutes minutes get --as user --params '{"minute_token":"TOKEN"}'
lark-cli vc +notes --as user --minute-tokens TOKEN --overwrite

使用 vc +notes 导出的文字稿路径。通过窄范围命令快速检视：

wc -l path/to/transcript.txt
sed -n '1,220p' path/to/transcript.txt
rg -n "主题|主办|承办|协办|嘉宾|AI|OPC|创业|资源|对接|交流" path/to/transcript.txt

将录音文字稿视为“发言内容”的首要信源；将海报文字视为“活动事实”的首要信源；将 AI 生成的摘要/章节仅视为导航地图，而非可直接发布的信源。

3. 公开事实交叉核验

对最终文章中出现的每个单位、人物、项目或公司：

• 若信息具有时效性或对外可见性，须检索公开信源。
• 优先采用官网、高校页面、政府网站、企业官网或原始公告。
• 仅在无官方信源时，方可使用权威媒体，并需注明可信度较低。
• 不得仅凭录音文字稿自行添加称谓、排名、头衔或机构隶属关系。
• 若某姓名/头衔无法核实，应严格沿用海报表述，或添加审阅备注，如“建议发布前由主办方确认”。

常见修正方式：

• 比对海报文本与 ASR 输出，识别同音字及识别错误。
• 活动名称、组织名称、议程标题、联系标签等，一律以海报拼写为准，除非公开信源明确反证。
• 避免在文章中嵌入私人电话号码或个人联系方式，除非用户明确要求复现邀请类内容。

4. 撰写文章草稿

采用微信公众号编辑口吻写作：

• 导语聚焦事件本身及其意义，避免空泛口号。
• 结构清晰，段落精炼有力。
• 将发言内容转化为编辑式观点提炼，而非逐段照搬讲话实录。
• 使用具体事实：精确日期、地点、主办方、分论坛名称、演讲人姓名、互动形式等。
• 仅保留演讲者有价值的语言，且限于简明转述或短引语。
• 规避明显 AI 行文痕迹：如高频重复的“不是……而是……”、过度工整的三段式口号、浮夸形容词、空洞过渡句等。
• 不夸大成果表述。倾向使用“围绕……展开交流”“分享了……”“现场设置……”等中性表达；仅当材料明确支持时，才使用“取得圆满成功”等结论性措辞。

推荐结构：

# 标题

导语：时间、地点、活动、主承协办、主题和现场目的。

## 平台/空间介绍
提炼承办方或园区的定位、服务逻辑、场景与资源。

## AI趋势和创业能力
提炼专家关于AI趋势、创业者能力、真实交付的观点。

## OPC社区运营和资源对接
提炼社区如何帮助创业者找到客户、订单、政策、资本和协作网络。

## 现场交流和下一步
写自由交流、展位体验、政企资源对接，以及后续平台承诺。

## 信息核验与发布前确认
仅供审稿时使用。

5. 按需创建飞书文档

首先阅读 lark-doc 文档。务必查阅当前 CLI 帮助，因 lark-cli docs +create 参数可能与旧版技能文档不一致：

lark-cli docs +create --help
lark-cli docs +update --help
lark-cli docs +fetch --help

本工作流优先采用 Markdown 格式，因其天然适配微信公众号分节逻辑，且与当前 CLI 支持良好：

lark-cli docs +create 
  --title "TITLE" 
  --markdown "$(cat article.md)"

切勿轻信 --markdown @article.md 语法——除非 readback 验证确认文件内容已被展开。部分 CLI 版本会将 @file 字面解释为 --markdown 的参数值。若发生此情况，请立即覆盖更新：

lark-cli docs +update 
  --doc "DOC_URL" 
  --mode overwrite 
  --markdown "$(cat article.md)"

采用便于审阅的文档结构：

• H1 主标题。
• 若为可编辑草稿，开头添加引述/提示语。
• 活动事实表格。
• H2 分节对应正文主体。
• 可选“信息核验”节，含信源标注与发布风险提示。

6. 最终回复前完成验证

必须校验文档交接结果：

lark-cli docs +fetch --doc "DOC_URL"

检查项包括：

• 返回标题与预期一致。
• 返回内容长度合理，非极短占位符。
• 关键标题（H2 等）存在。
• 正文未仅包含字面文件名（如 @article.md）。
• 已知 ASR/OCR 修正项均已体现。

若验证失败，须修正文档并再次 fetch，确认无误后方可声明完成。

最终回复应包含：

• 创建飞书文档时，提供其 URL。
• 一句简洁的验证结论句。
• 如有未核实项（如标题、演讲人姓名存疑），需明确列出相关发布风险。

质量规范

• 若用户使用相对时间表述（如“本周五”），且存在歧义风险，一律转换为绝对日期。
• 标题、正文、表格、备注中所有姓名、组织名、头衔、项目名须保持完全一致。
• 不确定性须尽早、直白声明，不得将未经核实的主张藏匿于润色后的行文中。
• 飞书文档验证成功后，及时清理本地临时草稿文件；除非用户明确将其列为交付物。