agentleFS
chengkj99chengkj99/kj-skills/skills/transcript-critical-analysis/SKILL.md

transcript-critical-analysis

Skill14 starsChanged 5 months agoMITView on GitHub

把分享会、演讲、课程、访谈、会议、播客的录音稿读成可信的判断和自己的成长:分层隔离原文与可核实事实、按论证而非时间重排结构、给每个数字建立断言台账与置信度、用反例检索/基础比率/替代解释/可证伪性四项压力测试审问框架,最后产出自检问题、待验清单和沉淀路径。用户提到分析录音稿/逐字稿/转写稿、整理分享会或演讲内容、判断哪些是事实哪些是观点、这些数字能不能引用、材料里有没有矛盾、读透一份材料、把录音变成能理解和复用的知识时都应使用本 Skill,即使用户没有明确说「分析」或「事实核查」。本 Skill 侧重可信度评估与个人成长转化;若用户只要挖内容选题和行动实验,改用 extract-conversation-insights;若只需把音视频转成文字,改用 local-stt-transcription。

The file

Files
SKILL.md

录音稿批判性分析

把一份录音稿读成两样东西:我能信的判断,和我明天要改的动作。

为什么需要固定流程

读录音稿最常见的失败不是读得不细,而是把不同性质的内容写在了同一层。结果是:讲者的口述数字被当成行业数据引用出去,漂亮的金句被当成方法论,而真正该改的动作一条也没落下来。

所以这个流程的全部设计意图就一句话:让「谁说的」「能不能信」「我怎么用」始终可区分。

先划定边界

  1. 读取目标仓库的 AGENTS.md、CLAUDE.md 或其他写入规则;用户指定的路径优先于本 Skill 的默认建议。
  2. 确认输入是音视频、原始转写、整理稿还是已有纪要。只有音视频时先调用 local-stt-transcription 或其他可用 STT,本 Skill 不重复实现转写。
  3. 原始转写永不覆盖。 需要可读版本时新建整理稿,原文保持原样。
  4. 私人对话默认 privacy: private;公开复用前匿名化,移除身份、职业、收入、家庭等可识别细节。
  5. 用户只要求分析时就不写文件;要求沉淀时才落盘,并完成索引与只追加日志。

核心原则:五层不可混

一份分析里必须能在版式上区分出这五层。任何一层塌进另一层,结论就不可信了。

层内容判断标准混层的后果
L1 保真原话、原数字、谁在什么场合说的一字不改整理稿覆盖原文,永久失去回查依据
L2 事实可被独立核实的断言有口径、有来源、可查口述数字被当行业数据引用出去
L3 框架讲者提供的透镜、模型、因果解释是否可证伪、边界在哪框架被当定律,什么都能解释
L4 判断我的评估:可信度、内部张力、替代解释必须标明是我的推断我的推断被误读成讲者原意
L5 行动我要改的动作、要去验的事可执行、有时间点分析变成消费,不产生行为改变

执行纪律:L1 单独成文件;L2 用断言台账承载;L3 与 L4 在版式上必须可区分(引用块、或显式写「我的判断」);L5 单列清单。


选择工作深度

过度加工是这类任务最大的隐性成本。先花几分钟通读定级,别对每份材料都跑全流程。

级别触发条件产物大致投入
轻读单人、篇幅短、议题少于 3 个只做 L5:3 条自检问题 + 待验清单少量
标准满足「≥2 位发言人」「篇幅长(约 1 万字以上)」「≥3 个独立议题」任一条L1 归档 + 按论证重排 + 断言台账中等
深读同时满足「≥2 位发言人」和「篇幅长」,或材料将用于对外内容、重要决策标准级 + 全套压力测试 + 观点矩阵 + 沉淀高

定级的真正依据是:这份材料会不会影响我的决策,或者被我引用出去。 只影响见识的做轻读;要引用的一律深读——引用错一个数字的代价远高于多花一小时。

用户没指定时按标准级做,并说明为什么选这个级别。


流程

Step 0 保真归档

原文原样存档,记录来源路径、归档日期、隐私级别、保真标记(如 fidelity: original-transcript)。只修断句和明显识别错误的版本另建整理稿,链回原文。

在归档完成前不要开始分析。 一旦先写了整理稿,后面就会不自觉地拿整理稿当原文思考,而整理稿已经丢掉了口气、迟疑和原始措辞——那些恰恰是判断可信度的线索。

Step 1 定性:判断可信度基线

先分析场景,再分析内容。场景决定后面所有断言的折扣率。四个问题:

  • 讲者的立场与利益:在卖书、卖课、卖方案,还是在复盘失败?有推销动机时,选择性举例和金句密度都会上升。
  • 场合与受众:对内复盘 vs 对外演讲。对外演讲的数字通常取有利上限,且很少标口径。
  • 信息类型:一手经验(他自己做过的)最值钱,二手转述次之,推论最不值钱。这三类必须分开记。
  • 有无追问机制:有人当场追问的对话,质量天然高于无人打断的独白,因为薄弱处会被暴露。

产出一句话定性:这是【谁】在【什么场合】对【谁】讲的,目的是【什么】,因此我对【哪类断言】打折。

Step 2 按论证重排,不按时间

这一步创造的价值最大,不要跳过。

逐字稿是时间顺序的,讲者会跑题、回头、重复。按时间做摘要只能得到流水账;按论证主干重排,矛盾会自己浮出来——因为原本隔了 40 分钟的两句话被放到了一起。这是发现内部矛盾最有效的机制,没有替代手段。

做法:

  1. 写出一句话主干:讲者整场想让你接受的那个判断。
  2. 抽出支撑主干的 5~12 个分论点,把散落各处的例子、数字、金句归集到对应分论点下。
  3. 把「跑题但有价值」的片段单独成节,不要硬塞进主干。

自检:如果重排后没有发现任何内部张力,通常说明读得还不够细,而不是材料完美。

Step 3 断言分层

逐条处理每个实质性断言。不同类型用不同标准评判,混用标准是误判的主要来源。

类型形态评判标准处理
事实型「X 是 N」有无口径、能否核实进断言台账,标置信度
框架型「X 的本质是 Y」是否可证伪、边界在哪记录并压力测试,不当定律
因果型「因为 X 所以 Y」有无替代解释强制列出 ≥2 个备选解释
预测型「X 必然会 Y」有无时间窗口和幅度预测对 ≠ 机制对,分开评
规范型「应该做 X」隐含前提是什么标明前提,判断是否适用于用户

两个最容易被搞混的点,值得专门留意:

预测型要做双重评估。 「某品类必然降价」这类判断,预测正确不代表归因正确——降价可能来自成本下降、产能过剩、竞争格局,而讲者给的机制只是其中一种解释。只有预测和机制都成立,才算这个框架被验证了一次。 不做这个区分,就会把运气当成洞察。

因果型必须做替代解释。 这是成本最低、收益最高的动作。每看到一个「因为所以」,强制自己想两个别的解释。想不出来的,才是真有洞察。

断言台账的字段、A~D 置信度标尺和标注纪律见 references/claim-ledger.md——处理任何含数字的材料前都要读它。

Step 4 压力测试:四把刀

只对框架型和因果型断言使用,事实型走台账即可。

  1. 反例检索(先做,性价比最高) 在同一份材料内部找矛盾。讲者自己举的例子往往就能推翻自己的结论,而这种内部矛盾比外部反驳更有力——因为无法被辩解成「你不了解背景」。 典型形态:讲者一边主张「没有不赚钱的行业,只有不赚钱的模式」,一边描述某个行业「结构性全行业亏损,没人能活着出来」。后者正是前者的反例。
  2. 基础比率(base rate) 讲者给了几个成功案例?分母是多少?只讲赢家就是幸存者偏差。 追问:同样条件下失败的有多少个?如果失败者不可见,这个规律就不成立。
  3. 替代解释 对每个核心因果关系写下两个备选解释,并标注哪个更可能。
  4. 可证伪性 什么证据能推翻这句话? 答不出来的,它是口号不是分析工具。 特别警惕解释力过强的概念:如果一个词能解释资产涨跌、股价波动、艺术品定价的全部情况,它就无法预测任何东西。对这类概念追问:它给出的可观察判据是什么? 有判据的才留下。

深读级再加一把:边界条件——这个框架在什么情况下失效?讲者很少主动说边界,但边界才是真正的使用说明。

Step 5 转化为成长

这一步决定分析是学习还是消费。三个问题加一次改写:

  • 哪一条改变了我的判断? 写下改变前后的对照。没有对照,说明只是「觉得有道理」。
  • 哪一条我要去验? 进待验清单,带时间点和验证方式。
  • 哪一条只能欣赏不能用? 明确标出。承认「这条精彩但我用不上」比勉强套用更有价值。

关键动作:把框架改写成自检问题。 陈述句记不住也用不上,疑问句会在下次工作时自动触发。

框架:「做产品重要的不是完备性而是稀缺性」 → 自检:「我这个方案里,别人难以快速补齐的是哪一点?」

产出 3~8 条自检问题。这是整份分析里复用率最高的部分,值得单独打磨措辞。

Step 6 沉淀落位

用户明确要求沉淀时才写。落点选择、各目录分工和登记动作见 references/sink-routing.md。

原则:原文与整理稿分文件;我的评估与讲者原意分页面或分版式;可复用方法只在用户明确要求形成 SOP 时才写成方法文档。写入后按目标仓库规则更新索引、追加日志、刷新台账。


输出结构

标准级和深读级的分析报告按 assets/analysis-template.md 组织。必须包含:

  1. 来源、定性判断与隐私说明
  2. 一句话主干 + 论证结构
  3. 断言台账(含口径与置信度)
  4. 框架清单(可证伪性、可观察判据、失效边界)
  5. 内部张力与替代解释
  6. 对用户的意义:改变了什么判断、哪些用不上
  7. 自检问题
  8. 待验清单
  9. 实际写入路径或建议去向

轻读级只输出第 1、6、7、8 项。

按材料类型(单人演讲 / 多人对话 / 访谈 / 内部会议 / 播客)调整重点,以及多人对话的观点矩阵格式,见 references/material-types.md。


三个反复出现的陷阱

  1. 金句崇拜——句子越顺口、越对称,越可能是不可证伪的口号。它的功能是传播,不是分析。遇到特别漂亮的句子,先问「什么能推翻它」。
  2. 框架万能化——一个框架解释的现象越多,预测能力越弱。要求它交出可观察判据,否则只当叙事工具。
  3. 数字裸奔——没有口径的数字不是数字。在问清「哪个范围、哪个时间段、怎么统计」之前,不要让它进入任何论证。

还有一个隐蔽陷阱:归因单一化。讲者为了讲清楚,必然把多因素压成单因素——这不是不诚实,是表达的必然代价。所以分析者的责任是把因素加回去,而不是照抄那个干净的因果链。


完成前检查

  • 原文是否原样保存,未被整理稿覆盖?
  • 每个引用的数字是否标了口径和置信度?口述数字是否默认落 C 级?
  • 是否至少找出一处内部张力或矛盾?找不到多半是读得不够细。
  • 每个核心因果关系是否写了 ≥2 个替代解释?
  • 框架是否标注了失效边界?
  • 预测型断言是否把「预测对」和「机制对」分开评了?
  • 讲者原意、我的推断、我的行动在版式上是否可区分?
  • 是否产出了自检问题和带时间点的待验清单?
  • 是否明确写出「哪些精彩但用不上」?
  • 未核实的地方是否如实写「未核实」,而不是补了一个看似合理的来源?

与相邻 Skill 的分工

本 Skill 的重心是可信度评估与成长转化:这些说法哪些能引用、材料里有没有矛盾、我该改什么判断。

  • extract-conversation-insights:重心是内容资产与行动实验——这段录音能出什么选题、什么实验、要跟进谁。两者都做保真和质疑,但产物不同。用户问「能产出什么」时用它;问「能不能信、我学到什么」时用本 Skill。同一份材料可以先跑本 Skill 建立可信度基线,再交给它挖选题。
  • local-stt-transcription:音视频尚未转写时先用它;该 skill 未启用时改用其他可用 STT 能力,不要在本 Skill 内自行实现转写。
  • phenomenon-insight:需要深挖某个现象背后机制时交给它。
  • content-creator / kangjian-skill:已确定选题、要生成成稿时交给它们。
  • wiki-doc-sink:用户明确要求沉淀进个人 Wiki 时配合使用,同时服从目标 Wiki 的本地规范。

本 Skill 不能用「输出了漂亮结构」掩盖证据不足。结构清晰但置信度不明的报告,比没有报告更危险,因为它看起来可以直接引用。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.