知乎「海外案例拆解 + 软植入」成稿器

这个 skill 干什么

一句话：给产品名 + 官网 + 知乎问题，产出一篇可直接发的知乎回答，并附上改到能发所需的全部东西。

它自动完成八件用户不用操心的事：

1. 找案例：用户给参考网址就用它；没给就去检索（默认 Starter Story 频道，可扩展到其他来源）
2. 卡时效：只用近 12 个月内发布的案例（越新越好），检索时带时间过滤；近一年实在没有贴合素材才放宽，并明确告知用户
3. 抓案例素材（收入、MRR、低谷、试错、渠道、定价、原话）
4. 从变体池组装骨架写成回答（钩子 → 人物 → 过程复盘 → 回扣题主 → 收尾），每次换组合
5. 把产品植入到"本来就该出现的位置"，全文品牌名不超过 2 次
6. 卡重复度：与既有范文的最长连续重合 ≤15 字、重合率 <2%，避免"换词复刻"
7. 文首标注案例来源原始网址（优先 YouTube 视频链接）与发布时间，初稿、终稿都保留，用户随时能点回去截图做配图
8. 产出两个文件：_初稿.md（正文 + 「发布前核对与调试」块：核对清单 + 优化建议 + 已把建议写进去的调试 prompt）+ _终稿.md（元信息块 + 粘贴位骨架）。用户跑一轮 prompt → 把结果贴进终稿 → 直接发布

输入

若缺必填项，用 AskUserQuestion 一次性补齐，不要分多轮问。

时效默认值：不特别说明时，一律按"近 12 个月内发布、越新越好"选案例（详见 case-selection.md 第 3 节）。近一年确实找不到能同时满足"植入产品 + 回答问题"的案例，才放宽，且必须告知用户。

人设规则（重要）

默认：无人设。 未指定人设时：

• 全文不透露任何身份信息：不写"我入行 N 年""做了 N 年独立开发""前大厂""某大厂程序员""我的团队"这类背景句
• "我"只作为观察者视角存在（"我见过""我踩过这个坑"），不交代我是谁
• 开头不做人物自我介绍，直接进案例
• 若某段强依赖身份（如"我在大厂时…"），改写为泛化观察（"在大厂待过的人都知道…"）或改用"很多人"

指定了人设（用户给文字或截图）：按其内容使用，可交代背景；但仍遵守：人设只用于背书与口吻，举例/痛点要匹配题主的目标读者，不拿人设经历硬当读者经历。

人设解析要点（用户提供时）

教育/职业经历、现在身份、城市、语言习惯、来答题的动机。未明确的字段保持模糊，不要编造无法核实的大事。

输出（两个文件，互不覆盖）

每次都产出两个 md 文件，同目录、同前缀：

铁律：初稿文件写完即冻结。 之后任何改动（用户把优化后的正文贴回来、或让我按 prompt 改）一律写进 _终稿.md，绝不回写、覆盖 _初稿.md。用户可以随时对比两版。

交付时 _终稿.md 先落一个可直接粘贴的骨架：元信息块（原样）+ 标题 + 醒目的粘贴位注释 + 一句"把调试 prompt 跑出来的正文粘到这里"+ 发布前最后一眼清单。

两个文件共用的文首元信息块（五行，粗体内联）：

**问题**：<知乎问题原文>
**案例来源**：<人物/产品> 《<标题>》 —— <来源类型：YouTube / 播客 / 博客>
**发布时间**：<YYYY-MM>          ← 必须在近 12 个月内（越新越好）
**原始链接**：<优先 YouTube 视频链接 https://www.youtube.com/watch?v=ID>   ← 用户点进去暂停截图
**植入产品**：<品牌名（植入位）>

两条文首硬性要求（初稿、终稿都保留）：

1. **原始链接** = 本次实际使用的案例来源地址，优先 YouTube 视频链接（youtube.com/watch?v=ID）——方便用户把进度条拖到某帧暂停截图做配图。素材即使是从镜像字幕页读到的，也只把镜像页放在 **案例来源** 行括号里备注，不写进 **原始链接**。若案例本身不是视频（纯博客/文章），则放原文地址，并让 **案例来源** 标注来源类型。
2. **发布时间** = 该案例的发布/上传时间（YYYY-MM），用于自证时效。

这两行属元信息，不计入"正文外链 = 0" 的约束，发布到知乎时整块删掉即可。

写完用 present_files 一次呈现两个文件。

工作流程（按顺序，不跳步）

第 1 步：产品画像（缓存优先，省一次抓取）

先匹配 references/product-presets.json（按产品名 / 域名 / aliases 不区分大小写）。
命中 → 直接用缓存画像。未命中 → WebFetch 官网，提炼：一句话定位 / 核心功能（≤3 条）/ 目标用户 / 差异点 / 可验证量化信息。
官网信息不足补 1 次 WebSearch，仍不足才回问用户。

第 2 步：判定题型 → 决定回扣段形态

题型先于产品。

• A 类「收入/感受/前景」题 → 回扣段用收入分布（R1/R2/R3 三选一），收尾从 E1-E5 里选。
• B 类「方法论/为什么/怎么做」题 → 回扣段用方法论（M1/M2/M3 三选一），收尾从 E1-E5 里选。

> 范文（sample1/4 对应 A 类，sample2/3 对应 B 类）只用来理解功能位，具体用哪套变体见 dedup-rules.md 的变体池——每篇换组合。

植入模式（由产品属性定，不由题型定）：

第 3 步：获取案例（来源不限，先卡时效）

详见 references/case-selection.md。优先级：

0. 时效先过滤：只要近 12 个月内发布的案例，越新越好。检索一律带时间过滤——WebSearch 用 freshness=y1，关键词补 2026 / 2025。每个候选记下发布时间；先筛时间，再比内容。只有近一年内确实没有"能植入产品 + 能回答问题"的素材，才放宽到一年外，且必须在文末核对块里告知用户。
1. 用户指定了参考网址 → 先用它（但也要看发布时间，超一年同样提示用户）。按链接类型分流：
   - youtube.com/watch?v=ID → YouTube 直连被墙，不要 curl/fetch 它；用 WebSearch 搜视频标题或 ID 找镜像字幕页；兜底读 youtube-transcript-fallback skill
   - 第三方字幕页 / 播客页 / 博客案例文章 → 直接 WebFetch
2. 用户没指定 → 检索。默认优先 Starter Story（素材密度高、与爆款结构最匹配），用 WebSearch（带 freshness=y1）：
   - Starter Story <主题词> $K/month MRR 2026
   - site:youtube.com Starter Story <主题词>
   - 效果不佳或主题不匹配 → 扩展到其他来源：Indie Hackers、My First Million、SaaS 播客、独立开发者的博客案例拆解等
3. 候选多时按 case-selection.md 的打分表选（时效维度权重最高，先过 ≤12 个月门槛）；平手取更新或播放更高。
4. 先看 case-selection.md 的案例索引——已收录高频优质案例，能命中就省一轮检索（但用前先确认发布在近一年内）。

无论来源是"用户指定"还是"自动检索"，都要记下本次实际使用的原始 URL 和发布时间，第 6 步写进文首 **原始链接**（优先 YouTube 视频链接）与 **发布时间**。选片过程中看过的其他候选链接不要写进文首，只放真正用的那一个。

第 4 步：取素材

• WebFetch 目标页，要：标题 + 发布日期 + 原始视频链接 + 创始人背景 + 收入数字 + 低谷/试错/转折 + 增长渠道 + 定价 + 技术栈 + 可引用原话。
• 拿不到时读 youtube-transcript-fallback skill（第三方字幕站兜底）。
• 人名/公司名交叉核对：机器转写常错（实例：同一联创被写成 Joe / Jock）。WebSearch 二次确认再落正文。
• 核对发布时间确实在近 12 个月内；拿不到准确日期就换更可靠的候选。
• 同时标记时效性信息（价格、用户数、MRR、功能、政策、排名）——第 7 步要用。

第 5 步：读参考文件（强制，不可跳）

• references/writing-spec.md —— 骨架功能位 + 各段变体池（按变体池组装，不照搬范文）
• references/dedup-rules.md —— 禁用原句清单 + 结构变体池 + 量化验收标准（必读，决定成稿会不会撞车）
• references/placement-and-safety.md —— 植入写法 + 敏感风控口径
• references/samples/ 里与题型对应的 1-2 篇范文 —— 只用来理解"每段该干什么活"，禁止复用其中任何句子、数据和结构顺序

第 6 步：写稿（从变体池组装）

严格按 writing-spec.md 写，1800-2200 汉字。骨架是 5 个功能位，顺序可调：

① 钩子        —— 第 1 段直接用冲突感数据/暴论交代案例核心成果（1-2 句，≤60 字），
                 从 H1-H5 里选 1 定风格，与上一篇不同
② 人物落点    —— 一句话介绍案例人物/产品是谁（≤30 字），说完立刻进主题
                 （开头三段合计 ≤120 字，不许铺垫）
③ 过程复盘    —— 从 S1-S5 叙事弧里选 1；节数 2-4 节
④ 回扣题主    —— A 类选 R1/R2/R3；B 类选 M1/M2/M3
⑤ 收尾        —— 从 E1-E5 里选 1，不固定三段式
   植入段       —— 跟着"痛点段落"走，位置不固定

正文之前先写文首元信息块（五行，粗体内联）：**问题** / **案例来源** / **发布时间**（近 12 个月内）/ **原始链接**（优先 YouTube 视频链接）/ **植入产品**。这一块是用户的截图导航 + 核对底稿，不属于正文，不计外链，终稿也保留。

去重硬要求（详见 dedup-rules.md）：

• 禁用原句清单里的句子，一处都不许出现（月入$X。裸开场、他的技术栈都是现成的、视频我看了N遍、这不是一条增长曲线，这是一条锯齿、他的 $X，不是靠代码写出来的……）
• 收入分布段禁止沿用范文的档位边界与措辞（$500 / $3,000 / $10,000、六成 / 两成多 / 不到一成）
• 大家以为……其实…… 全文最多 1 次，且不要写成这个固定句式
• 至少 90% 的具体信息（数字、产品名、界面细节、渠道、失败细节）必须来自本次抓取的案例

写作铁律（去 AI 味）：一段 1-3 句、大量单句成段；加粗约 20 处只给金句和数字；保留 $；MRR/ARR/SEO/MVP/ASO/ROAS/captions 等不做中英解释；禁止"值得注意的是/此外/综上所述/希望对你有所帮助"；结尾禁止"努力/坚持/相信/加油/终会"。

问句配额（硬要求）：全文 3-5 个问句——向读者发问 / 自问自答 / 案例视角反问，三种轮着用，分布在过程复盘和回扣段，不连续堆叠。问句要带判断带情绪，不写空问。

口语质感（硬要求）：像人说话，不像文章朗读。允许口语连接词（说白了 / 讲真 / 你猜怎么着）和一点不完美感（破句、口头补充）；方言词全文 1-3 处，只从非儿化方言词里挑（得亏 / 压根 / 搁 / 整 / 折腾 / 拧巴 / 利索 / 麻利 / 抠）；禁止翻译腔书面腔（因此 / 然而 / 与此同时），排比最多连用 2 句。

禁止突兀儿化音：不写"这儿""那儿""哪儿""一会儿""点儿""事儿""玩儿""味儿""劲儿""活儿"这类口语儿化（引用的原话除外）。"儿"只能出现在"女儿 / 婴儿 / 儿童 / 幼儿园"等同义实词里。宁可写"这里""这段时间""一点""事情"。注意方言词不许借机写儿化音。写完全篇搜一遍"儿"字逐个确认。

第 7 步：写「发布前核对与调试」块（只放进初稿文件）

详见 references/postcheck-and-iterate.md。必须产出三样：

1. 时效性信息核对清单：把文中所有可能过期的信息列出来（价格、订阅费、用户数、MRR/ARR、产品功能与套餐、平台规则、榜单排名、链接可用性、人名拼写），每条注明"文中写的值 + 建议核实渠道"
2. 结构与内容优化建议：1-3 条，指出还可加强的地方（如钩子不够狠、植入略生硬、某节缺数字、有儿化音）
3. 【可复制】下一轮调试 prompt：一段自包含的 prompt，用户连同全文发给任意 AI 即可做终检改稿

关键约束（本次新增）：第 2 部分写的每一条优化建议，都必须同时以"具体指令"的形式出现在第 3 部分的 prompt 里（prompt 里要有一段"按下面这几条改"，逐条列出，而不是只给通用要求）。写完自检一遍：用户把初稿 + 这个 prompt 交给 AI 跑一轮，能不能直接得到可发布的终稿——不能就说明建议没转写完整或漏了要求，补齐。

这个块只出现在 _初稿.md。终稿文件里不放调试块，只保留元信息块 + 正文 + 一段"发布前最后一眼"清单。

第 8 步：自检 → 产出 → 呈现

两个脚本都要跑（--no-persona 在判定为无人设时加上）：

# 1) 合规自检
python "<skill目录>/scripts/check_answer.py" "<成稿路径>" <品牌名> [--no-persona]

# 2) 与范文的重复度自检（去重验收）
python "<skill目录>/scripts/check_similarity.py" "<成稿路径>"

任一硬性项不达标 → 换表达重写对应段落（不是改几个字），然后重跑，不要带问题交付。

交付前人工扫一眼两点：
- 文首：**原始链接** 是不是本次真正用的那个 YouTube 视频链接、能不能打开；**发布时间** 是不是在近 12 个月内。
- 全文搜一遍"儿"字，确认没有突兀儿化音（脚本也会报）。

通过后写两个文件并一次呈现：

1. outputs/zhihu_<关键词>_初稿.md = 元信息块 + 正文 + 「发布前核对与调试」块
2. outputs/zhihu_<关键词>_终稿.md = 元信息块（原样）+ 标题 + 粘贴位骨架（注释标记 + 一句说明）+ 发布前最后一眼清单

present_files 把两个文件一起呈现。若目录里已有同名初稿（用户在同一选题上重跑），先确认是要覆盖初稿还是另起编号——默认不覆盖，加 -2 后缀。

硬约束（不可违反）

1. 回答优先：核心是回答题主的问题，不是介绍素材、更不是推产品。
2. 正文不挂外链：产品只写品牌名，不写 URL、不写"点这里"。注：文首元信息行（含 **原始链接**）与第二块（核对与调试块）里的链接不算，但都要在正文的分隔线之外。
3. 品牌名全文 ≤ 2 次，一次实（带价格/具体用途）、一次虚或省略。
4. 无人设时全文不暴露身份（见"人设规则"）。
5. 不写绕过限制的操作细节（网络环境 / IP / 地区 / 账单地址 / 支付通道校验），不写灰产类目。
6. 敏感词零容忍（见 placement-and-safety.md）。
7. 数据必须来自素材/公开资料，不可编造；不确定就模糊化，不四舍五入关键数字。
8. 不写素材来源频道名（"Starter Story 频道"这类）。图注写"<人名>的访谈画面"即可。
9. 时效性信息要在第二块里点名，不要假装它一定正确。
10. 不许复用范文原句、原数据、原顺序：dedup-rules.md 的禁用清单为 0 命中，check_similarity.py 必须通过。范文只提供"每段干什么活"，不提供文字。
11. 文首必须标注案例来源原始网址与发布时间：**原始链接** 优先放 YouTube 视频链接（便于暂停截图配图），**发布时间** 用于自证时效；初稿和终稿都保留。这两行属元信息，不受第 2 条约束。
12. 案例时效：只选近 12 个月内发布的案例，越新越好；检索带时间过滤。近一年确实无合适素材才放宽，且必须在文末核对块里向用户说明用的是哪期、为什么。
13. 禁止突兀儿化音：正文不出现"这儿 / 那儿 / 哪儿 / 一会儿 / 点儿 / 事儿 / 玩儿 / 味儿 / 劲儿 / 活儿"这类口语儿化（引用原话除外）；"儿"只允许出现在"女儿 / 婴儿 / 儿童 / 幼儿园"等实词里。
14. 两个文件、互不覆盖：初稿写 _初稿.md、终稿写 _终稿.md；初稿写完即冻结，任何后续修改只写终稿，绝不回写覆盖初稿。
15. 开头简明干脆：第 1 段直接用冲突感数据/暴论交代案例核心成果（1-2 句、≤60 字），开头三段合计 ≤120 字、三段内进主题，不许铺垫式起手（"今天聊聊 / 最近看到"）。
16. 问句配额：全文 3-5 个问句（向读者发问 / 自问自答 / 案例反问，轮换用），不连续堆叠。
17. 口语质感：允许口语连接词与少量不完美感；方言词 1-3 处且只限非儿化词；禁翻译腔书面腔。

常见问题

• 找不到合适案例：先确认是否被"近 12 个月"卡住——换成非 Starter Story 来源（Indie Hackers / 新播客 / 近期博客）再搜，加上 2026 / freshness=y1。仍无则回问用户是否指定网址。
• 近一年内实在没有能植入产品的案例：才放宽到 12 个月外，必须在文末核对块写明用的是哪一期（附 **发布时间**）、为什么；并给用户"换近期案例"的调试口令。
• 用户给的网址抓不到：先试 WebFetch；失败则 WebSearch 该网址标题/ID 找镜像页；再不行读 youtube-transcript-fallback。
• 官网抓不到：WebSearch "<产品名>" 介绍/评测 补 1 次，再不行回问。
• 问题与产品不搭：不要硬凑植入。宁可少植或不植，先告诉用户判断。
• 素材太长/字幕被截断：只取与主题相关段落，不必通读。
• 成稿和范文太像（check_similarity.py 判失败）：定位到超标片段，换表达重写那一段（改句式、改比喻、改切入角度），不要只改几个字；同时检查是不是无意识套用了范文的段落顺序——把叙事弧换成另一种（S1-S5 里选不同的）。
• 连续写多篇怕撞车：每篇换一组组合（钩子 H / 叙事弧 S / 回扣 R-M / 收尾 E 各换一个），并让具体案例素材完全不同。
• 用户把优化后的正文贴回来了：只写进 _终稿.md，_初稿.md 一个字都不动；顺手扫一遍儿化音与敏感词再落盘，跑一遍两个自检脚本。
• 用户拿着初稿又聊了一轮（改动）：改正文时必须保留文首元信息块（尤其 **原始链接** 与 **发布时间**），别顺手删掉；若换了案例，这两行要同步换成新案例的 YouTube 链接与发布时间。这一轮的结果同样写 _终稿.md。
• 脚本报儿化音：逐个替换成书面表达——这儿→这里、一会儿→一段时间/片刻、点儿→一点、事儿→事情、玩儿→玩、味儿→味道、劲儿→力气、活儿→工作。

相关 skill

• youtube-transcript-fallback：YouTube 直连失败时的字幕兜底
• zhihu-case-breakdown：手动给定视频时的轻量模板