内容 → 微信公众号完整工作流

把任意来源的内容变成一篇可发布的微信公众号文章。支持 YouTube 视频、网页文章、本地文档（PDF / Markdown / TXT）。整套流程对访谈、演讲、播客录像、深度报道效果最好。

---

规则文件分工

这套 skill 有两类规则，执行时不要混用：

规则文件	负责什么	什么时候看
references/translation-quality.md	英译中、术语、本地化、翻译腔排查、上下文标记、指代还原、术语边界、回译自检、英文示例中英对照	生成 bilingual-transcript.md、整理 transcript.md、复查英文来源文章时
references/wechat-writing-rules.md	微信公众号成文规则：结构、开头、来源交代、叙事视角、标点、AI 腔、引号、加粗、标题、结尾，以及可选的高阶手法（两件事合流、跨领域 reframing、自嘲切换器）	写 article.md 和最终重写时

简单说：translation-quality.md 保证「原文没有走样，中文不像翻译」；wechat-writing-rules.md 保证「文章像中文作者写给公众号读者看的文章」。

---

总体流程

1. 获取并整理内容，生成原始转录和工作底稿
2. 调查人物或作者背景
3. 从主播/作者视角和读者视角分析内容
4. 写微信公众号初稿
5. 对照原文检查遗漏的高价值内容
6. 用读者视角、编辑视角、事实视角评估
7. 根据评估重写，直到通过
8. 拟标题、按需加章节标题、准备封面图

---

Step 1：获取并整理内容

1.0 判断内容来源类型

在开始之前，先确认来源类型，选择对应路径：

来源类型	判断条件	执行路径
YouTube 视频	URL 包含 youtube.com 或 youtu.be	→ 路径 A
网页文章	其他网页 URL（博客、新闻、论文页面等）	→ 路径 B
本地文件	文件路径（.pdf / .md / .txt / .docx 转存版）	→ 路径 C

---

路径 A：YouTube 视频

A.1 下载字幕

方法一：yt-dlp（最快，优先尝试）

# 优先下载中文字幕（zh-Hans）
yt-dlp --write-auto-sub --sub-lang zh-Hans --skip-download \
  --cookies-from-browser chrome \
  -o "%(title)s" \
  "VIDEO_URL"

# 如果没有中文字幕，下载英文字幕
yt-dlp --write-auto-sub --sub-lang en --skip-download \
  --cookies-from-browser chrome \
  -o "%(title)s" \
  "VIDEO_URL"

常见错误：如果报 "Sign in to confirm you're not a bot"，加 --cookies-from-browser chrome 参数（需本地已登录 Chrome）。

方法二：tactiq.io 网页转录（yt-dlp 被 SABR 或 PO Token 拦住时的首选）

yt-dlp 报 Requested format is not available、PO Token was not provided 或 Some web client https formats have been skipped 等错误时，说明 YouTube 的流量限制绕不过去，但字幕本身可能还在。优先切到 tactiq.io：

1. 用 Chrome DevTools MCP 打开 https://tactiq.io/tools/run/youtube_transcript?yt={URL_ENCODED_YOUTUBE_URL}
2. 等 3-5 秒让 tactiq 后台拉字幕
3. evaluate_script 取 document.querySelector('#transcript').innerText
4. 拿到的是「时间戳 + 文本」每两行一对的格式，直接保存为 full_transcript_en.txt 或 _zh.txt

这条路 90% 情况下几秒内就能搞定。完整脚本和失败处理见 references/youtube-transcript-fallback.md。

方法三：Chrome DevTools MCP fetch 拦截器（tactiq 也失败但视频确实有字幕时用）

如果 tactiq 的 #transcript 为空而 YouTube 播放器显示字幕可用，走 Chrome DevTools MCP 在页面上注入 fetch 拦截器、再点击 Show transcript 的路径。步骤和脚本见同一份 fallback 文档。

视频真的没有字幕的处理：如果 YouTube 播放器直接显示 "Subtitles/closed captions unavailable"，所有免费路径都会失效（tactiq、youtubetranscript、downsub 全部依赖 YouTube 原生字幕）。此时用 AskUserQuestion 让用户选：基于二手媒体报道成文、等 24-48 小时 YouTube 自动生成字幕、用户自备转录文件、换视频。不要静默降级。处理细则见 fallback 文档最后一节。

A.2 解析 VTT 字幕文件

使用 scripts/parse_vtt.py 解析字幕：

python scripts/parse_vtt.py "字幕文件目录路径"

输出：full_transcript_zh.txt（去重后的纯文本转录）。

A.3 生成双语对照转录（英文视频必做）

英文来源的 YouTube 视频必须生成 bilingual-transcript.md。当用户明确说「忠实翻译」「保留英文」「逐句对照」「要英文原文」时，更不可省略。

transcript.md 是主题提炼版，服务于写稿；bilingual-transcript.md 是逐段核查版，服务于翻译校验。两者目的不同，不能互相代替。

格式：

[时间戳] 英文原文（逐字保留，不改动）

中文忠实译文

---

[时间戳] 下一段英文原文

下一段中文译文

---

文件开头加视频元信息（标题、链接、频道、演讲者），正文按时间戳顺序覆盖全部片段，一个不漏。

翻译时执行 references/translation-quality.md 的「忠实翻译层」：翻译前先标记上下文、代词、泛指词和前文回指；翻译时保持原意，不压缩实质内容；翻译后对关键句做回译自检，确认主语、逻辑、术语和程度没有走样。

---

路径 B：网页文章

B.1 抓取页面内容

用 WebFetch 工具读取页面，prompt 设为「提取文章全文，保留段落结构和小节标题，不要摘要，不要省略」。

如果文章有分页或 WebFetch 截断，分页多次调用，拼接成完整文本后保存为 full_transcript_zh.txt。

抓取后记录文章的标题、作者、发布日期、来源网站，这些信息后续写来源注记时需要用到。

官方文档/指南类页面的抓取要求

如果 WebFetch 返回的是摘要或明显不完整的内容（缺少代码块、缺少示例、段落比原页面少），切换到 Chrome DevTools MCP：

1. navigate_page 打开目标 URL
2. evaluate_script 提取完整正文：document.body.innerText.substring(start, end)（每次 8000 字符，分段直到取完）

这对官方 API 文档、产品指南、技术规范尤其重要。原文的代码块和示例 prompt 是核心内容，WebFetch 摘要会丢掉它们。一旦这一步被压缩，下游的转录和写作都无法补救。

---

路径 C：本地文件

C.1 读取文件

用 Read 工具直接读取文件路径。PDF 较长时分段读取（每次不超过 20 页），将所有内容拼接后保存为 full_transcript_zh.txt。

---

通用：生成工作底稿 transcript.md

三条路径都走完后，将内容整理为带主题分节的 Markdown 文件（transcript.md），标注：

• 作者 / 主播 / 嘉宾名字
• 每个话题段的主要论点
• 重要引语（保留原话）
• 关键数字、案例、时间线、产品名、术语

如果原始内容是英文，整理 transcript.md 时同步完成本地化处理，不要留到写稿时再改。术语格式、缩写处理、俚语意译、英文句式改写、翻译腔排查都按 references/translation-quality.md 执行；同时处理未还原的代词和泛指词、主语切换、成熟术语中文译法和长句拆分。完成后对照「真实案例回归表」做一次 case 级检查。

内容类型决定压缩程度：

• 访谈 / 播客 / 演讲：提炼核心论点，保留重要原话、案例细节、人物背景线索
• 官方文档 / 产品指南 / 技术规范 / 操作手册：完整翻译每一段，不删减；原文有几条建议就翻几条，原文有示例就保留并翻译

英文 prompt 示例、代码块或官方模板必须中英文对照，放在同一个代码块里。英文在上，空行分隔，中文在下。

---

Step 2：人物背景调查

适用范围：访谈、演讲、播客等有具体说话人的内容，调查主播和嘉宾。如果来源是署名文章或报告，调查作者。如果是匿名文档或机构报告（没有具体说话人），跳过此步，直接进入 Step 3。

在正式分析内容之前，先对核心人物做背景调查。这一步的目的不是写简介，而是理解他们的世界观是怎么来的。只有知道一个人经历了什么，才能理解他为什么说这些话、这些话对他意味着什么。

用 WebSearch 搜索以下维度，每个人物各做一次：

传记与职业轨迹

• 成长背景、教育经历（什么时期、在哪里、受谁影响）
• 职业关键节点：第一份重要工作、重大转型、成名作或成名事件
• 现在在做什么、为什么做这个

思想形成与演变

• 他最重要的几个观点是什么，这些观点是怎么形成的？
• 思想有没有发生过明显转变？什么事件或经历触发了转变？
• 他在哪些问题上改变了主意，为什么？

个人得失与教训

• 他公开谈过的失败或低谷是什么？他从中学到了什么？
• 他最引以为傲的成就背后有哪些不为人知的代价或取舍？
• 有没有他反复提到、对他影响深远的某段经历或某个人？

价值观与立场

• 他在乎什么？他反对什么？他选边站的地方在哪里？
• 他的观点在同行中处于什么位置（主流/异见/边缘）？

调查完成后，为每位主要人物写一份「人物小传」，通常 1000-2500 字，根据资料丰富程度决定。小传不是简历罗列，而是叙述性文字：这个人是怎么一步步走到今天的，哪些经历是真正的转折点，他的核心观点是从什么土壤里长出来的。

---

Step 3：内容分析与提炼

分三步执行，顺序不能颠倒。

提炼的目标是洞察和分析，不是压缩。 保留具体的数据、案例、故事和原话，它们是观点成立的血肉。一段带着具体细节的内容，比十条提炼出来的要点更有价值。

叙事视角只用于内部分析。 主播视角和观众视角不是正文写法。写文章时，你才是文章作者。先理解演讲者或原作者的观点，再用自己的判断、场景和解释转达给读者。

3.1 主播 / 作者视角：他想传递什么？

站在主播、嘉宾或作者的立场，理解他主动选择说这些话的意图：

• 核心论点是什么？整期内容想让观众记住的一件事是什么？
• 他用了哪些案例、数据、故事来支撑这个论点？
• 他刻意强调或反复提到的观点有哪些？
• 他对行业/未来的判断是什么，对接下来 12-18 个月有没有明确预测？
• 他给出了哪些可操作的建议？
• 结合 Step 2 的人物背景，这些观点和他的经历或立场有哪些关联？

3.2 读者视角：什么真正有价值？

切换到目标读者（创业者 / AI 从业者 / 产品经理）的视角，独立判断哪些内容值得带走：

• 最反直觉、最容易被忽视的发现是什么？
• 哪些观点会让读者停下来想「啊，原来是这样」？
• 哪些方法论可以直接指导行动？
• 有没有描述了但没有命名的新角色、新工作方式、新产品范式？
• 哪些金句信息密度高、有画面感、可以脱离上下文独立理解？
• 嘉宾说这句话的底气来自哪里？人物背景会不会改变读者对观点的理解？

3.3 对照原文查漏

两个视角总结完后，回到转录原文逐段遍历：

• 有没有重要论点在两个视角里都没有出现？
• 有没有具体的数字、时间线、案例细节被遗漏？
• 有没有嘉宾对未来的判断没有被捕捉到？

把补充发现合并进 3.1 或 3.2 对应的位置，再进入 Step 4。

---

Step 4：写微信公众号初稿

4.1 文章长度

文章字数不设固定上限，根据访谈时长和信息密度动态决定：

• 30 分钟以内的短访谈，内容集中，1000-1500 字足够
• 1 小时左右的标准播客，覆盖多个话题，1500-2500 字合理
• 超过 1.5 小时的长对谈，或信息密度极高的专业访谈，2500 字以上不必克制

判断标准只有一个：内容说清楚了没有。还有重要的观点、案例、数据没有放进去，就不是写完了。

4.2 成文方式

写 article.md 时按 references/wechat-writing-rules.md 执行，尤其注意这几件事：

1. 文章正文不要用 Markdown 标题、列表、表格；article.md 第一行的 # 标题 是唯一例外
2. 开头三段按固定节奏写。第一段直接给具体场景、数字或判断，不写人物简历；第二段再交代人是谁、公司背景、可信度锚点；第三段锁定文章要回答的问题。不要第一句就介绍人物。
3. 视频或原文是素材来源，不是正文主角；不要频繁用「他说」「他提到」「这期视频里」推动段落，也不要加「X 对这件事评价挺复杂」这类只承担转场功能的空句
4. 每段尽量有具体的人、事、数字、场景或原话，避免空洞断言。能量化的地方就量化，不用「大幅提升」「显著下降」这种模糊词
5. 主动筛掉对读者零价值的转录细节：讲者「念不准某个词」「笑了出声」「让观众举手」这类现场花絮、主持流程元评论（「时间关系跳过」）、未展开的人名引用、反复的自我修正。判断标准：这一句抽掉，文章的信息量和论点会不会打折？不会就删。详见 wechat-writing-rules.md「筛掉对读者无信息量的转录细节」
6. 如果讲者说到「这张图」「这根箭头」「这段代码在屏幕上」「这个方框」等 deixis 指示语，或者讲架构 / 流程 / 对比表 / 数据曲线 / 产品 UI 这些光靠文字无法还原的内容，必须在文章对应段落插入原视频截图。写初稿时先用 [图:MM:SS - 描述] 占位不打断节奏，初稿写完统一用 Chrome DevTools MCP 打开 YouTube 视频对应时间点截图，再替换占位符。完整截图流程和插图规范见 references/visual-capture.md
7. 如果文章超过 2000 字，适当使用 **完整短句** 形式的章节标题分段；不要用冷名词作章节标题
8. 如果引入新概念，首次出现时用「」锚一次定义，后面裸写不再加引号；定义用"名词 + 破题动作"一句话讲清楚
9. 如果材料能对应具体的实操场景，在结尾附近自然做一次桥接，把判断落到具体团队 / 岗位 / 决策上，不硬凑。不要做「国内 vs 海外」的地域二分，经验是否只适用于某地域要经得起反问；大多数工程判断本身就是通用的，别给它强加地域标签
10. 正文里的英文术语按 wechat-writing-rules.md 第七节 的大小写规则处理。术语词组每个单词首字母大写（Agent、Semantic Search、Context Window），缩写全大写（RAG、LLM、ESQL），代码标识符反引号原样（@tool、top K、jina-grep）
11. 看一眼素材手头有没有能用 第十章的高阶手法 的条件。两件事合流适合有双线索的材料，跨领域 reframing 适合很容易被读者当"又一条新闻"的事件，自嘲切换器适合典故或理论密度偏高的段落之间。不强求，合适的时候用一两条，能让文章明显跳出同质化的 AI 生成稿。

如果演讲或访谈围绕一个技术产品、协议或框架展开（比如 MCP、某个平台、某个工具），在介绍人物的同时顺手给它一句定义。不需要教科书式解释，一句能让非熟悉读者继续读下去即可。

4.3 指南类内容的写法

如果来源是官方文档或操作指南，文章里的例子应该直接用原文给出的示例，而不是自己重新发明一个。

引用方式：用一句话自然引出，然后直接展示，展示之后再做分析。英文示例仍按 references/translation-quality.md 的规则放中英文对照。

---

Step 5：检查遗漏的高价值内容

写完初稿后，回到转录原文做一次漏网检查：

• 有没有反常识的数字或数据？
• 有没有嘉宾描述的具体失败案例细节？
• 有没有对未来 18 个月的明确判断？
• 有没有提到但没有展开的新角色或新工作方式？
• 有没有值得记住的金句还没引用？
• 人物背景里有没有某个经历或转折，和文章里的某个观点特别契合，但还没有用上？

如果有遗漏，判断是否足够重要到加入正文。

---

Step 6：用三层评估

评估报告本身是内部工作文档，可以使用标准 Markdown 标题、列表、表格和加粗。它不受微信公众号正文规则限制。

6.1 读者视角

• 标题能不能让目标读者停下来点进来？
• 开头 3 段能不能让人继续读？
• 每个 Take-away 有没有让人「啊对」的感觉？
• 结尾有没有留下值得思考的东西？

6.2 编辑视角

对照 references/wechat-writing-rules.md 检查：

• 正文有没有 Markdown 标题、列表、表格？
• 有没有冒号、破折号、双引号等禁用标点？
• 有没有 AI 腔词语和公式化句式（包括「不是 A 而是 B」及其变体）？
• 直接引语、概念名词、加粗是否符合规范？加粗总量（含章节标题）是否不超过 5 处？
• 开头第一段是直接给判断 / 场景 / 数字，还是先写人物简历了？
• 章节标题（如果有）是不是完整短句带动词，不是冷名词？
• 能量化的支撑点有没有留下模糊形容词（「大幅」「显著」「很多」）？
• 标题是否包含具体主体（不是纯抽象概念）？问题句标题文章里有没有真的给出答案？
• 来源交代是否自然？有没有「X 评价挺复杂」这类空转场句？全文读起来是在分享观点，还是替原视频做广告？
• 有没有告诉而不是展示：空洞断言多，具体细节少？
• 有没有残留对读者零价值的转录细节（讲者念不准、现场举手、时间关系跳过、未展开的人名）？抽掉这些句子文章是否更干净？
• 涉及「这张图」「这根箭头」「这段代码」「屏幕上」等 deixis 指示语的段落，是否都截图插入了？有没有 [图:MM:SS - 描述] 占位符没替换？
• 如果材料能对应实操场景，是否做了一次桥接把判断落到具体团队 / 岗位上？桥接里有没有「国内团队」「海外做法」这类地域二分？抽掉地域限定词后经验是否还成立？成立就不要保留地域词
• 英文术语是否按大小写规则处理：词组每个单词首字母大写，缩写全大写，代码标识符反引号原样？

6.3 本地化与事实视角

对照 references/translation-quality.md 和原始转录检查：

• 专有名词、缩写是否按首次标注规则处理？
• 有没有英文句式结构、被动句、名词堆砌、倒装句、代词过密等翻译腔？
• 主语和谓语是否清楚？有没有因为省略主语导致说话人、公司、产品或系统混淆？
• 代词、泛指词和前文回指是否已按上下文还原？
• 有成熟中文译法的术语是否没有偷懒保留英文？
• 关键事实、因果关系、技术术语和直接引语是否做过回译抽查？
• 是否对照「真实案例回归表」排查了 10 个典型错译模式？
• 嘉宾金句的中文表达意思有没有跑偏？如有歧义，可在括号内附原话
• 数字、时间线、人名、产品名是否准确？
• 有没有把嘉宾的「可能」「我们在尝试」写成已经发生的事实？
• 有没有把两件不同的事合并成一件？
• 如果来源是官方文档或指南，文章里引用的示例是否来自原文？英文示例是否都有中文对照放在同一代码块内？

区分两类内容：

• 延伸解读：作者从原话推导出的判断、补充背景、类比。允许，但语气上要与嘉宾原话区分开
• 无中生有：原文没有提及、但文章中当作事实陈述的内容。必须删除或改为明确标注是作者推测

如果评估发现问题，列出具体修改清单，进入 Step 7。

---

Step 7：根据评估重写

重写原则：

如果是结构问题：把文章内容打散，用连续段落重新组织，删掉正文里的标题和列表。

如果是语气问题：重读最难改的段落，把第一句改成一个口语化的事实陈述或场景描述。

如果是 AI 腔问题：找到每一个触发词，用更具体的说法替换，或者把这句话删掉。大多数 AI 腔句子删掉后文章反而更好。

如果是翻译腔问题：回到 references/translation-quality.md，按触发特征逐条修正，不要只替换词语。

重写完成后再做一次 Step 6 评估，直到三层视角都通过为止。

---

Step 8：发布准备

文章定稿后，在正式发布前完成三项准备工作。

8.1 拟标题

为文章拟 3-5 个备选标题，覆盖不同风格：

风格	核心角度
观点型	说话人的核心判断，适合有强观点的演讲或访谈
信息型	文章带来的关键事实或结论，适合有具体数据的内容
反常识型	文章里最让人意外的发现，读前和读后判断不同
场景型	用一个具体细节切入，让读者想知道接下来发生了什么
读者价值型	读完这篇文章能带走什么，直接说明

好标题不等于博眼球。选题时检查：标题是否准确反映文章核心内容，是否有具体信息量，是否有清晰角度。

警惕「A 变贵了，B 变便宜了」这类对比框架标题。它容易把复杂推理压成口号，让读者以为文章承诺了一个鲜明判断，读完却发现正文不是这么回事。

更好的替代方向：

• 疑问型：直接用行业术语问一个真实存在的问题，例如「AI Coding 到底能不能提升研效？」
• 陈述型：说出文章最核心的一个发现，不加戏剧修饰，例如「AI Coding 提升了什么，没提升什么」

拟好备选标题后，不要自己替用户选择最终标题。先把 3-5 个备选标题展示给用户，并用 AskUserQuestion 让用户选择下一步：

1. 选择其中一个标题作为最终标题
2. 提供补充方向后重新生成一组标题
3. 让 Claude 推荐一个标题但仍需用户确认

如果用户选择某个标题，才把它写入 article.md 第一行：# 标题。

如果用户补充标题方向，例如「更犀利一点」「少一点营销感」「突出人物」「突出方法论」「更适合创业者」，根据补充方向重新生成 3-5 个标题，再次让用户选择或确认。

如果用户让 Claude 推荐标题，先说明推荐理由，再请求用户确认；得到确认前不要覆盖 article.md 第一行。

8.2 章节标题（按需添加）

文章超过 2000 字，且存在 3 个以上主题明显不同的段落群，读者在扫读时可能迷失时，可以加章节标题。如果文章本身叙事流畅、段落衔接自然、不超过 2000 字，不需要加。

格式：在对应段落群的第一段之前，单独一行写加粗短标题，不用 Markdown ## 语法，直接写 **标题**。标题写成完整短句或带动词的短语，长度 5-20 字，参考 wechat-writing-rules.md 的章节标题部分。不要写冷名词式标题，也不要写 AI 式的「探索……」「深入了解……」。

8.3 封面图截取

根据来源类型选择方式，完整操作步骤见 references/cover-art-guide.md。

简要：YouTube 视频优先用 curl -L -o cover.jpg "https://i.ytimg.com/vi/VIDEO_ID/maxresdefault.jpg"，不受 SABR 限制；网页文章抓 og:image；本地文件手动截图。

---

输出文件规范

文件	内容	何时生成
full_transcript_zh.txt	纯文本原始转录（备查）	YouTube 视频必做；其他来源按需保存完整原文
bilingual-transcript.md	双语对照逐段转录，每段英文原文 + 中文忠实译文	英文 YouTube 视频必做；用户要求忠实翻译时更是不可省略
transcript.md	结构化主题提炼版（带分节，服务于写稿）	所有来源必做
article.md	最终微信公众号文章，第一行必须是 # 标题	所有来源必做
<VIDEO_ID>-frame-<MMSS>.jpg	正文需要可视化段落的原视频截图	仅当文章里出现「这张图」「这根箭头」「屏幕上」等 deixis 指示语，或者材料包含架构图、流程图、对比表、UI 截图等光靠文字无法还原的内容时生成。命名用视频 ID + 时间戳，和 article.md 同目录

bilingual-transcript.md 和 transcript.md 不可互相替代。前者供用户核查翻译质量，后者是提炼分析后供写稿用的结构化版本。截图文件生成方式见 references/visual-capture.md。

文件名冲突处理：如果当前目录已存在 article.md 且内容与本次任务无关，使用 <slug>-article.md，其中 slug 取视频/文章标题前 4-6 个汉字或英文关键词（小写连字符，如 mcp-future-article.md）。

文章末尾必须注明来源，格式根据内容类型选用：

# YouTube 访谈 / 播客
内容来源，[频道名称]「[视频标题]」，YouTube 链接 [URL]，嘉宾为 [嘉宾名称]。

# 网页文章
内容来源，[作者]「[文章标题]」，原文链接 [URL]，发布于 [平台/媒体名称]。

# 本地文档
内容来源，[作者 / 机构]「[文档标题]」，[发布日期或版本号]。