<< All versions
Skill v1.0.0
currentAutomated scan100/100xingtu1996/xingtu-skills/conference-archive
──Details
PublishedSeptember 28, 2026 at 03:47 PM
Content Hashsha256:6cc421d431e40b6f...
Git SHA
──Files
Files (1 file, 11.2 KB)
SKILL.md11.2 KBactive
SKILL.md · 242 lines · 11.2 KB
version: "1.0.0" name: conference-archive description: 会议/论坛/行业大会素材归档与蒸馏。当用户参加完线下会议、行业论坛、技术大会后,要求"整理一下""归档""沉淀素材""把录音和拍图整理成文章素材库"时使用。输入:录音 record_id、现场拍图、口述观点、官方议程 PDF、系统纪要。输出:结构化素材库(金句库/观点库/资产库/选题/嘉宾档案/信息图),含校准流程确保零失真。触发词:会议归档/大会素材/论坛沉淀/整理开会内容/PEC同款/会后总结/会议素材库。
会议素材归档与蒸馏(Conference Archive)
定位:把一场线下会议(现场拍图 + 录音 + 口述观点)沉淀成可直接写文章/写书的结构化素材库。来源:PEC2026 AI 创新者大会实战沉淀(2026-09-12),经双会话合并 + 对抗式校准验证。原则:不失真|嘉宾原话与我的观点分库|三级可信度|原创判断标星|待确认不编。
触发条件
以下任一触发:
- 用户说:整理会议/归档大会/沉淀论坛素材/把开会内容入库/PEC 同款流程
- 会后批量发图、录音 record_id、议程 PDF 时
- 多个会话各收半场,需要合并成一份完整素材库
素材库目录结构(标准模板)
{会议名}/├── 00-总览.md ← 全局入口:来源体系/场次地图/主线/统计/待补├── 01-会议过程纪要.md ← 时间线├── 02-金句素材库.md ← 下午场/分论坛金句├── 03-资产库.md ← 硬数据/框架/方法论/可复用清单├── 04-逐字稿-{录音设备}.md ← 完整逐字稿(最长最细)├── 05-纪要-{录音设备}.md ← 系统纪要摘要(非逐字稿要标注)├── 06-纪要-{录音设备}.md ← 多段录音按设备分文件├── 07-可复选题与文章素材.md ← 每个选题给钩子句 + 素材编号├── 08-官方报告综合.md ← 有 PDF/白皮书时├── 09-boss口述观点库.md ← 下午场口述观点(★原创判断单独标)├── 10-现场图片素材索引.md ← 68 张图按场次-主题命名├── 11-分享人分析档案.md ← 谁讲的/什么路数/对行途有什么用├── 12-哇塞观点专题.md ← 认知刷新点:"我原来怎么想→现场怎么刷新"├── 13-{另一会话增量}.md ← 跨会话补充,不重复已有内容├── 14-boss上午场观点库.md ← 打字输入的观点(和口述分文件)├── 15-官方议程与嘉宾名录.md ← 议程 OCR + 官方头衔├── 16-关键报告现场页精读.md ← 大屏报告逐页拆├── 17-可复用提示词模板.md ← 本次流程固化,下次直接套├── 18-对话流水.md ← 过程留档(一般不用读)├── 19-导出报告.md ← 导出统计├── 20-增量金句与纠错表.md ← 系统纪要二次提取 + 转写错误纠正├── 21-问题复盘与处理记录.md ← 踩坑根因,防重踩├── 22-本地素材库导览与自检清单.md ← 打开即用的导览 + 数量自检命令├── 结构图-{主题}.html ← 精修版结构图(适合截图入文)├── html信息图/ ← 现场生成的示意图(语义命名)│ └── 00-图目录.md ← 每张图关联到现场来源/观点/文档└── PEC-images/ ← 现场拍图(场次-主题命名 webp/jpg)
编号规则:
00-22= 本次会议现场沉淀15b-类后缀 = 主文件的补充版S1-S2-前缀 = 非本次会议现场的素材(后续看的视频/文章),和会议内容用前缀区分- 多会话合并时,后续会话编号接续,不覆盖已有文件
阶段一:生产(现场 → 会后 → 落档)
Step 1:现场实时归位(开会中发图时)
你是我的会议素材搭档。我在【会议名】现场,会持续拍大屏照片发给你。1. 每张图先 OCR 读大屏原文,区分【金句原文】【议程/标题】【数据页】【无信息照片】2. 金句按"环节→嘉宾→原句"登记,给一句≤80字归位:属于我哪条内容主线3. 我穿插打的语音/文字是我自己的观点,单独标★,不和嘉宾观点混4. 复杂页面画结构图,文字归位即可5. 每条金句标注可信度:大屏 OCR=逐字可信,看不清=待确认,不许编造输出:一张图一回应,先原文后归位,保持简短。
Step 2:会后单会话落档
会议结束,把本会话全部内容沉淀到【目录名】:1. 大屏金句全录(按环节/时间排序,含嘉宾官方头衔)2. 我的现场观点库(保留原话,按主题分组,原创判断标★)3. 哇塞点专题("我原来怎么想→现场怎么刷新")4. 资产库:硬数据/框架/方法论/可复用清单5. 可写选题:每个选题给钩子句 + 支撑素材编号6. 全部标注来源(OCR/转写/我的口述/网络核查),推测内容单独标"待确认"7. 文件用"编号-主题.md"命名,另存总览 00
Step 3:跨会话合并(多个会话各收半场时)
我有【N】个会话分别记录同一场会的不同半场。现在做补充合并:第一步 盘点:读其他会话的落档总览,列"已覆盖什么"第二步 划界:只补增量,明确不重复劳动第三步 增量落档:编号接续,每个文件开头写清"与既有文件的关系"第四步 跨场呼应:做"上半场观点 ↔ 下半场验证"对照表,标出我先想到、后被验证的判断(书稿署名用)第五步 更新总览:补来源表、数据统计、待补项第六步 重新打全包 zip,列最终文件树硬约束:找不到的附件先告诉我缺什么,不许用印象代替读取。
Step 4:录音二次蒸馏(拿到系统纪要后)
这是【主题】录音的系统纪要(附全文)。请:1. 先判断它是"逐字稿"还是"摘要"——摘要要明确标注,不要假装是原话2. 蒸馏成:核心论点树 / 可引用金句(标注讲者)/ 硬数据 / 与我书稿主线的映射3. 把"我"在录音里的插话单独抽出,和我的现场观点库合并4. 标出系统摘要里语焉不详、需要回看录像的点,列入待补5. 输出可直接并入素材库的 markdown,不要写成新闻稿
Step 5:长图/议程图处理
我发了一张超长图(议程/逐字稿/报告长图)。先用工具确认尺寸,超过 4000px 高就按每段约 2300px 切片,逐段 OCR,最后合并成结构化文字(保留标题层级、嘉宾头衔、时间),说明这张图到底是什么,不要猜。
阶段二:校准(落档完后必跑)
生产完不等于可用。以下 6 步按顺序跑,确保素材库打开即用。
Step C1:全量盘点与编号冲突
对本目录所有 md 做对抗式盘点:1. 列全部文件名,标出编号重复/跳跃/前缀混乱2. 检查文件内容和文件名是否不符3. 标出所有"待确认/待补/TODO",按"需回看录像/需查名片/纯落档遗漏"分类4. 输出:必须修的 / 建议修的 / 合理保留的只做诊断,不重写内容。
Step C2:跨文件事实一致性
检查所有 md 的事实是否自洽:1. 人名/公司名/头衔:同一人在不同文件里称呼是否统一2. 时间/时段:讲者出场时间是否和议程表一致3. 数字:金句数/图片数/观点条数在总览和明细里是否对得上4. 转写错误:列出疑似转写错误的词(音近字、行业术语误识别)发现不一致,给出"以哪个文件为准"的建议,不要直接改。
Step C3:可信度标注校准
逐篇检查引用内容标注是否合规:1. 大屏文字 → 标【原句OCR】2. 录音原话 → 标【原句·转写】3. AI 提炼概括 → 标【提炼】4. 推测性内容 → 标【推断性重建】5. boss 现场口述 → 标【语音观点】漏标补上,标错纠正。推测内容不得当逐字原文引用。
Step C4:金句/观点去重
对比所有金句库和观点库:1. 多个金句文件之间有无重复句子2. 多个观点库之间有无重复观点3. boss 原创观点和嘉宾观点有无混淆(必须分库)4. 同一条金句在不同文件里措辞不一致的,以 OCR 原文为准输出去重清单:"保留哪份、另一份删还是合并"。
Step C5:文件命名与可读性
检查所有文件名和文件内标题:1. 编号连续、无冲突2. 非本次会议现场的素材用 S 前缀区分3. 文件名一眼能看出内容4. 文件开头有来源、定位、可信度三级标注给出重命名建议,不要直接执行。
Step C6:素材库健康度终检
对本素材库做交付前终检:1. 按预期清单逐项数文件,报差异2. 所有图片都有索引文件对应3. 所有"已完成"项实际完成(不看标记,看文件内容)4. 无空文件/占位文件/截断文件5. 备份文件(.bak)位置明确输出 PASS/FAIL 清单,FAIL 项给修复建议。
可信度标注体系(铁律,不可省略)
| 标注 | 含义 | 能不能直接引用 | |
|---|---|---|---|
| 【原句OCR】 | PPT 画面文字经 OCR 直接确认 | ✅ 逐字可信 | |
| 【原句·转写】 | 录音逐字稿中的演讲者原话 | ✅ 可信,但注意转写误差 | |
| 【提炼】 | AI 从原句/原意中提炼的概括 | ⚠️ 不是原话,需改写 | |
| 【推断性重建】 | 图片读取失败时基于上下文推演 | ❌ 不可当原文引用 | |
| 【语音观点】 | boss 现场口述的判断 | ✅ 原创归属,标★ |
红线:推测内容永远不能写成定论。看不清就写"待确认",不许补全成完美句子。
原创观点识别(书稿级资产)
以下情况必须单独标★★,并在总览里登记:
- boss 先提出判断,现场嘉宾/报告后验证(第一性推导在先,产业论据在后)
- 跨多个场次/多个讲者被反复印证的判断
- 和主流观点相反但逻辑自洽的判断
这些是书稿《AI 工程师》的核心弹药,别人抄不走。
铁律
- 嘉宾原话与我的观点永远分库——02/13 是嘉宾金句,09/14 是 boss 观点,绝不混
- 三级可信度——OCR/转写/推测,推测单独标注
- 原创判断单独标★——先想到后验证的,书稿署名用
- 待确认就写待确认——不补全成定论
- 本地文件不删——合并时同名文件先备份
.bak-时间戳 - 中文文件名原样保留——禁止转码/拼音化/改名
- 跨会话合并不重复劳动——只补增量,先读对方总览再动手
- 生产完必跑校准——6 步校准是交付门槛,不是可选优化
版本历史
| 日期 | 变更 | |
|---|---|---|
| 2026-09-13 | V1.0:基于 PEC2026 AI 创新者大会实战沉淀封装,含生产 5 步 + 校准 6 步 + 可信度标注体系 |
<!-- public-sync: 2026-09-27 | 脱敏版本 | 源 .agents/skills/conference-archive -->