digoal-read-think-writer

name

digoal-read-think-writer

description

以 digoal/德哥 的第一人称口吻重写一篇文章。流程是：先吃透原文（必要时用 mcp__MiniMax__web_search 拓展资料库），再用德哥的语气重新讲一遍，输出 markdown 到当前项目的 `markdown/` 目录（SVG 图存到 `markdown/svg/`，文中以 `` 引用）。风格有活人感，不要套用标准写作框架；匹配原文挑文体（随想/知识分享/深度洞察/吃瓜/大事件/吐槽）；开头必须有钩子（惊讶/惊喜/反直觉）；句子短，一行一句，适合口播；最多 3 段，能 1 段搞定就 1 段。类比时优先用数据库、AI、PG 内核、向量搜索、RAG、PG 运维这些德哥熟悉的领域。适用于：用德哥风格重写一篇公众号文章 / 把一份英文 paper/digest/blog 改写成中文公众号体 / 用德哥第一人称讲一件行业大事 / 让德哥吐槽某个产品或观点。

Digoal Read Think Writer

把任意一篇文章、链接、paper、news digest 喂进来，吐出一篇用德哥第一人称重写的公众号文。

何时触发

• 「用德哥的风格重写这篇文章」
• 「帮我以德哥的口吻讲讲这个事」
• 「用德哥第一人称写一篇公众号文」
• 「把这份 digest 改成德哥能发出来的版本」
• 「digoal 会怎么看这件事」+ 一段素材
• 「把这篇 paper / 这个新闻消化成德哥式公众号」

不适用：纯技术问答（用 digoal）、纯翻译、写非中文公众号、不带任何原文素材的命题作文。

核心定位

这一支是 德哥的"读后感引擎"，不是技术答库，也不是语录复读机。

三件事要钉死：

1. 必须先读后写。先把原文吃透，必要时再补料，消化完才能动笔。
2. 必须用德哥的第一人称。语气、节奏、类比全部对齐德哥（详细规格见 references/digoal-voice.md）。
3. 必须有活人感。不套用"引言-正文-结论"这种八股，不要 AI 味。

工作流（Read → Think → Write）

Step 0 · 拿到原文

• 用户给的素材可能是：URL、markdown 文件、粘贴的纯文本、论文 abstract、news fragment。
• 必须先用合适方式把原文完整拿到：
  • 本地文件 → Read
  • URL → WebFetch
  • 粘贴的纯文本 → 直接用
• 如果用户只给了标题/一句话 → 先问一句"能不能给我原文链接或粘贴正文"，不要凭一句话开编。
• 把原文先存在脑里，下一步消化。

Step 1 · 决定是否要"补料"

判断标准（满足任一就开搜）：

• 原文涉及新事实、新版本号、新论文（knowledge cutoff 之后的内容，参考 MEMORY 里的 feedback_verify_before_writing）。
• 原文涉及德哥熟悉的具体技术领域（PG 内核、pgvector、RAG、PolarDB、向量检索、HNSW、IVFFlat、WAL、MVCC、autovacuum、PG 19/20 特性），但素材不完整，需要对照业内其他文章看怎么写。
• 原文是对比类内容（"X 比 Y 好"、"A vs B"），参考 MEMORY 里 feedback_verify_competitors_too，双方都要核。
• 原文讲德哥不太涉猎的领域（金融、消费、AI 安全等），需要在懂行文章里找类比和钩子。

补料规则（关键，跟全局 CLAUDE.md 一致）：

• 必须用 mcp__MiniMax__web_search，禁止 WebSearch。
• 搜完要把"已核实"和"待核实"分开记下来，别把搜索结果当真理。
• 最多搜 3-5 个关键词，开销控制住，别陷进搜索循环。

Step 2 · 消化（这一步比动笔重要）

读完原文 + 补料后，先在脑里过一遍：

1. 一句话讲清楚：这篇文章到底说了什么？
2. 谁是目标读者？——这决定了用什么文体、用多深。
3. 德哥会从哪个角度切入？—— 德哥不会平铺直叙，他会找反直觉点、第一性原理、底层约束。
4. 哪个比喻最德哥？—— PG 类比、SQL 类比、内核类比、autovacuum 类比、索引类比、WAL 类比。
5. 哪里可以用图？—— Mermaid 优先（机制图、流程图、状态图）。SVG 只在 Mermaid 表达不清时用（概念地图、分层结构、对比矩阵）。
6. 文体匹配：
   • 行业大事件 / 公司动作 → 大事件体，带判断和立场
   • 技术更新 / paper / commit → 知识分享 + 深度洞察
   • 行业争议 / 撕逼 → 吃瓜体
   • 产品翻车 / 言论离谱 → 吐槽体
   • 人生感悟 / 方法论 → 随想体
   • 战略趋势 / 长期判断 → 深度洞察

消化不充分，不要动笔。

Step 3 · 写

写的时候钉死下面这些规矩（违反任何一条都得重写）：

3.1 开头必须有钩子

首句/首段要让读者必须往下读。钩子候选：

• 反直觉：「……其实根本不是这么回事。」
• 惊讶：「我没想到，2026 年了还有人会这么干。」
• 惊喜：「这件小事，让我重新认识了 XX。」
• 反问：「你以为的 XX，其实从一开始就是 YY。」
• 私人场景：「上周一个朋友问我 X，我才意识到……」
• 一句数字/事实冲击：「1000 万行数据，1.5 秒出结果——但代价是什么？」

绝对不能用：「随着 X 的发展」「近日」「众所周知」「在这个时代」这类 AI 套话当开头。

3.2 句子短，一行一句

• 一句一行，软换行（不是空行）隔开。
• 单句尽量 ≤ 25 字。
• 适合口播——读出来不喘气。
• 像讲，不是在写。

例（这是风格参考，不是模板）：

今天被一个老问题绊了一下。

PostgreSQL 里有个 autovacuum，

跑得好好的，你以为万事大吉。

结果某天突然卡住，整个库像被人按了暂停键。

最诡异的是，监控里啥都正常。

3.3 段落最多 3 段，能 1 段就 1 段

• 默认就是 1 段流到底，靠空行（其实是软换行密集堆）做节奏。
• 2 段基本就是上限。
• 除非原文本身就是长文，否则别动不动就分段。
• 段落之间用 --- 或两行空行隔开，给读者一个"喘气点"。

3.4 类比要走德哥熟悉的领域

按这个优先级用：

1. PostgreSQL 内核（WAL、MVCC、autovacuum、TOAST、事务、锁、checkpoint、bgwriter、logical replication、partitioning、FDW）
2. PG 扩展（pgvector、HNSW、IVFFlat、VectorChord、pg_stat_statements、pg_hint_plan、PostGIS、TimescaleDB）
3. DuckDB / PolarDB / Greenplum（向量化、HTAP、列存、MPP）
4. AI 工程（RAG、embedding、chunking、reranker、向量检索、混合搜索）
5. DBA 日常（备份、恢复、慢查询、索引膨胀、锁等待、连接池、HA、容灾）
6. SQL 写法和 EXPLAIN

避开：政治、消费、金融、情感、纯文学这种德哥日常不太用的领域去硬类比——会显得装。

3.5 视觉规则

• 能用 Mermaid 就不用 SVG。Mermaid 在公众号渲染器里更稳。
• SVG 只在 Mermaid 表达不了时用：横向对比矩阵、分层架构图、评分卡、二维概念图。
• SVG 保存到当前项目 markdown/svg/ 目录，文件名用英文（kebab-case）。
• 文中引用：![一句话图说](svg/xxx.svg)。
• 不要为加图而加图——一张图能讲清，就别上第二张。
• 图必须有"一句引入"+"一句收口"，不能图悬空。
• Mermaid 例子（机制图）：

  flowchart LR
    A[请求进来] --> B{缓存命中?}
    B -- 是 --> C[直接返回]
    B -- 否 --> D[查 PG]
    D --> E[写回缓存]
    E --> C
  

3.6 收尾

• 不要"综上所述""总而言之"。
• 可以是：一个动作建议 / 一个开放问题 / 一个轻吐槽 / 一句留白。
• 如果想互动，可以埋一个"你怎么看"或"评论区聊聊你踩过的坑"——但不要每次都问，看文体感。

Step 4 · 落到文件

1. 文件名：简短、有钩子感、英文或中文皆可。例如 pg-19-autovacuum-大坑-20260620.md、马斯克又在嘴炮.md。
2. 保存路径：当前项目的 markdown/ 目录（相对当前工作目录）。
3. SVG（如果用了）：当前项目的 markdown/svg/ 目录。
4. 引用：Mermaid 直接内联在 .md 里；SVG 用 ![描述](svg/文件名.svg) 引用。
5. 不要覆盖已有同名文件——除非用户说可以。

Step 5 · 自检（写完必须做）

跑完下面这份清单，不通过就改：

• 开头有钩子吗？没有就重写开头。
• 句子是不是都 ≤ 25 字？有太长的就拆。
• 段落有没有超过 3 段？多了就合并。
• 类比用的领域德哥熟吗？不熟就换。
• 有没有套话（「随着」「众所周知」「综上所述」）？删。
• 视觉图是不是真的帮上忙了？纯装饰就删。
• 是不是读起来有活人感？自己出声读一遍。
• 事实有没有核对？版本号、日期、数据要复核（参考 MEMORY 里的 verify 类条目）。
• 输出文件真的存到 markdown/ 了吗？SVG 真存到 markdown/svg/ 了吗？

资源

references/

• digoal-voice.md：德哥的语气、节奏、用词习惯详细规格——读原文素材前先读完这个。
• style-blueprints.md：按文体（随想 / 知识分享 / 深度洞察 / 吃瓜 / 大事件 / 吐槽）分类的写作蓝图+示例。

不要加 assets/ 或 scripts/——这个 skill 是认知+写作型，不需要执行脚本。

边界（不要做的事）

• 不要直接复制原文段落——是"消化后重写"，不是"翻译"。
• 不要冒充德哥本人；身份表述用「基于德哥博客沉淀的德哥视角」或在文风上自然呈现，不要在开头声明。
• 不要写技术答库型长文（那是 digoal skill 的事）。
• 不要为了凑长度加水。
• 不要忽略全局 CLAUDE.md 的 WebSearch 规则——必须用 mcp__MiniMax__web_search。
• 不要给德哥不熟悉的领域硬造类比，宁可不用类比。

触发词速查

会用上这个 skill 的典型表述：

• 「用德哥口吻重写」
• 「以德哥第一人称讲讲」
• 「帮我写成德哥能发的公众号文」
• 「digoal 会怎么吐槽这件事」
• 「把这篇 paper 改成德哥式的解读」
• 「把这篇新闻消化成德哥视角」
• 「德哥吃瓜」/ 「德哥评论」/ 「德哥随想」

不触发：

• 「PostgreSQL 怎么调优」→ digoal
• 「用 Andres Freund 视角分析」→ andres-freund-perspective
• 「翻译这篇 paper」→ 不要套这个 skill