从一篇英文技术博客，到一篇能发公众号的原创：我用 Obsidian + AI 的全流程实录

副标题：不是机翻拼凑，而是一套可复制的「技术输出工作流」

我是一只阿木木，一个写后端、也常写 Bug 的普通人。

以前我也跟大多数技术人一样：

• • 收藏了一堆英文技术博客和 GitHub 仓库
• • 看到好文章只会点个 Star，心想「以后要好好读」
• • 真要写点东西，就忍不住想：

  要不把这篇英文文章翻译一下发出去？

问题是：

• • 机翻 + 修修补补，自己都觉得别扭，更别提叫「原创」
• • 纯翻译还容易踩版权红线
• • 最终的结果是：既没读懂，也没输出

这两年我开始刻意用 产品思维 + Obsidian + AI 搭自己的第二大脑，
顺手也把「从英文输入到中文原创输出」这件事，整理成了一条可复用的工作流。

现在我写技术文章时，基本都会走这条路：

找到一篇优质英文技术博客 →
在 Obsidian 里拆成知识卡片 →
用 AI 帮我提炼结构和盲区 →
再结合自己的经验，写成一篇真正属于我、能发公众号的中文原创。

这篇文章，我就用实录的方式，把整个流程拆开给你看：

• • 我的 Obsidian 里是怎么组织这类输入的
• • 我让 AI 做哪些事，让哪些事必须自己做
• • 如何避免变成「翻译号」，而是写出有自己视角的内容
• • 全程用到的 Prompt 模板 & 笔记模板，我会一股脑给你

你可以把这套流程，直接改造成「你的技术输出流水线」。

一、先说清楚：我们不是在「翻译」，是在做「再创作」

这套工作流有个底层原则：

英文博客只是“原材料”，不是成品。
你的文章，是在这个原材料上，
加上你的理解、你的场景、你的踩坑经验。

所以我给这条流程下了三个约束：

1. 1. 不照搬原文结构：大纲要按「中文读者 + 我的经历」重新设计
2. 2. 不逐段翻译：AI 只帮我「讲明白」，不帮我「直译」
3. 3. 必须加入自己的东西：

• • 相关的 Bug / 线上事故
• • 在国内环境下的差异（技术栈 / 团队习惯）
• • 自己项目里的具体例子

只有这样，最后那篇文章才能问心无愧地说：
它是“基于 XXX 博客的延伸创作”，而不是「翻译 + 改写」。

二、全流程先给你看：从英文博客到中文原创

先给你看一下这条流水线的总览：

下面我按顺序走一遍，你可以边看边对照自己的场景。

三、Step 0：选一篇「值得写」的英文技术博客

0.1 我怎么选文章？

我一般从这些地方找：

• • 技术社区周刊（如各语言 Weekly、Awesome 列表里的「文章」）
• • 大厂工程博客（Netflix / Uber / Meta / Cloudflare / 阿里云国际站 等）
• • 知名个人博客（在圈内有 GitHub Star 或 Hacker News 讨论的那类）

选的时候我会看三点：

1. 1. 主题是「持续有需求」的

• • 如：幂等性、分布式锁、可观测性、API 设计、性能优化套路

• • 你能勉强读完大意，但细节有点吃力，这样最适合「借力输出」

• • 你搜一搜发现：要么就是机翻，要么就是很浅的介绍

0.2 用 AI 快速判断「值不值得写」

看到一篇文章，我不会立刻从头啃，而是先：

1. 1. 复制文章链接，丢给 AI：

text

请帮我快速评估这篇英文技术博客「{标题或链接}」：
1. 用 5–8 句话中文概括文章的大意
2. 列出这篇文章的核心观点或关键技术点（3–7 条）
3. 从一个中国后端工程师/技术人的视角，这篇文章有什么：
   - 值得借鉴的地方？
   - 明显不适合照搬中国环境的地方？
4. 你觉得把这篇文章作为灵感，延展成一篇中文原创技术文章，有哪些可能的切入角度？

1. 2. 看 AI 的总结和角度建议，判断：

• • 这个主题我是否真有话可说
• • 适不适合我当前公众号的定位（普通技术人、后端视角、实战导向）

如果感觉只是「看完觉得挺好、但自己说不出更多」，我就放弃这篇，换下一篇。

四、Step 1：在 Obsidian 里「吃透原文」

确定要写之后，才进入正式的「阅读 + 拆解」阶段。

1.1 在 Obsidian 里新建一条「源文档笔记」

我会在 Obsidian 里为这篇文章新建一条笔记，比如：

text

📁 02_Projects
    📁 Write_技术输出
        📝 2024-英文博客-幂等性实践（源文档）
        📝 2024-幂等性：从线上事故到落地方案（中文输出稿）

「源文档」笔记模板大致是这样：

Markdown

# {英文文章标题}｜源文档拆解
## 1. 原文信息
- 链接：
- 作者：
- 发布时间：
- 所属领域：
- 我为什么选这篇？（1–3 句话）
---
## 2. 结构概览（AI 总结）
> 用 AI 帮我列出文章结构 & 要点（Step 1 的输出粘贴在这里）
---
## 3. 逐段要点 & 疑问
### Part 1：{小节标题或内容大意}
- 要点：
- 我不太明白的地方：
- 和我经验的差异：
### Part 2：...
---
## 4. 个人初步想法
- 这篇文章哪部分最戳我？
- 哪些观点我赞同 / 存疑？
- 和我项目里的真实场景有什么对应/出入？
---
## 5. 可以延展成中文文章的几个角度
- 角度 1：
- 角度 2：
- 角度 3：

1.2 用 AI 帮你啃原文（而不是替你读）

我一般会让 AI 做三件事：

1. 1. 列结构 + 要点

text

请帮我以「结构大纲」+「每部分 3–5 条要点」的方式，拆解这篇文章：
{粘贴文章全文或主要内容}
输出格式示例：
# 文章总体主题是什么？
# 部分一：{小节标题}
- 要点 1：
- 要点 2：
# 部分二：...

1. 2. 解释我看不懂的段落

对于某段看不太懂的英文，我直接复制给 AI：

text

这是原文的一段内容：
{粘贴原文段落}
请你帮我：
1. 用中文解释这段话在说什么，限制在 200 字内
2. 如果里面有专业术语，请单独列出来并解释
3. 尽量举一个简单的例子，让我能“脑补”出画面

1. 3. 整理我的疑问清单

读完后，我会让 AI 帮我归纳：

text

基于上面的拆解和我的疑问，请你列出这篇文章可能让读者困惑的 3–7 个关键问题。
这些问题，后面会成为我写中文文章时要重点讲清楚的部分。

这一步完成后，我在 Obsidian 里就有了一条「源文档拆解笔记」。

五、Step 2：用产品思维给中文文章「重新定位」

这一节非常关键。

我们不是要「复刻」原文，而是要重新回答三个问题：

1. 1. 我这篇中文文章要帮谁？（目标读者画像）
2. 2. 他现在的具体痛点是什么？
3. 3. 我能给出什么承诺？（看完会获得什么）

2.1 在 Obsidian 里建一条「文章规划」笔记

比如：2024-幂等性：从线上事故到落地方案（规划）

模板可以这样：

Markdown

# 文章规划｜{暂定标题}
## 1. 目标读者是谁？
- 职业/阶段：
- 已有基础：
- 真实场景：
## 2. 这篇文章要帮他解决的核心问题？
- 问题 1：
- 问题 2：
- 问题 3：
## 3. 我的视角/差异点是什么？
- 和原文有什么不同？
- 和市面上中文文章有什么不同？
- 我能提供哪些真实案例/踩坑？
## 4. 初步标题 & 副标题备选
- 标题 1：
- 标题 2：
## 5. 初步大纲（后续会迭代）
- 一、...
- 二、...

2.2 用 AI 做一轮「定位头脑风暴」

我会把「源文档笔记」里的要点，和上述规划模板，丢给 AI：

text

这是我对一篇英文技术博客的拆解和初步想法：
{粘贴「源文档笔记」的精简版要点 + 个人想法}
请你假设你是一个中文技术公众号的编辑，帮我做三件事：
1. 定义这篇中文文章的「目标读者画像」：
   - 他们是什么背景？
   - 在什么场景下会来搜这篇文章？
2. 帮我列出 3–5 条「可以帮助他们的承诺」，形式类似：
   - 看完你可以...
   - 你会知道如何...
3. 给出 3 个不同风格的中文标题 + 副标题组合，每个都要尽量具体，避免空洞话。

我会从里面挑一个读者画像 + 2–3 条承诺，填回 Obsidian。

这一步做完之后，这篇文章在我脑子里，就已经从「翻译作业」变成了一个「小产品」。

六、Step 3：在 Obsidian 里搭「大纲 + 知识卡片」

3.1 大纲的基本结构

结合原文结构 + 读者痛点，我会在「文章规划」笔记里写出一个自己的大纲，例如：

Markdown

# 大纲 v0.1｜幂等性文章示例
一、为什么幂等性总在“出事之后”才被想起（故事开头）
二、从真实线上 Bug 说起：一次多扣款事故复盘
三、到底什么是幂等性？（用人话讲清楚）
四、实践中常见的 3 种幂等性实现方式（结合原文 + 我们的项目）
五、如何在现有系统中“补上”幂等性（给普通团队的落地建议）
六、总结：写给现在还没出事故的你

你可以看到，这个结构已经和原文不一定一样了，更贴近「中文读者 + 我的项目」。

3.2 为关键知识点建「卡片笔记」

有几个专业概念，我会单拎出来，在 03_Knowledge 里建成卡片，比如：

text

📁 03_Knowledge
    📁 后端/分布式
        📝 幂等性（Idempotency）
        📝 幂等性-Key 设计
        📝 幂等性与幂等接口的区别

每条卡片用一个统一模板（示例）：

Markdown

# 幂等性（Idempotency）
## 1. 概念（用自己的话解释）
## 2. 关键要点（3–5 条）
## 3. 示例 / 代码片段
## 4. 常见误解 / 易混概念
## 5. 我们项目里对应的场景 / 代码链接
## 6. 来自哪篇文章/书？（引用）
- 原始来源：{英文博客链接}
- 其他参考：

这么做有两个好处：

1. 1. 以后写别的文章时，这些卡片可以被反复引用 → 真正「复用认知」
2. 2. 你的公众号文章，也会天然带着「体系感」，而不是一次性的碎片输出

七、Step 4：用 AI 生成「初稿骨架」

到这一步，你已经有了：

• • 源文档拆解
• • 文章定位 & 承诺
• • 初步大纲
• • 若干知识点卡片

现在，才轮到 AI 帮你写「初稿骨架」。

4.1 给 AI 的输入要尽量「结构化」

我会准备这样一个 Prompt：

text

下面是我准备写的一篇中文技术文章的素材，请你帮我生成一版「初稿骨架」。
【1. 源文档拆解】
{粘贴源文档的结构 + 关键要点（适当删减）}
【2. 我的读者 & 文章定位】
{粘贴你在文章规划里写的：目标读者、要解决的问题、承诺}
【3. 我的初步大纲】
{粘贴当前大纲}
【要求】
1. 请严格按照「我的大纲结构」来组织文章，不要直接照搬原文的结构
2. 写作风格：
   - 面向普通后端工程师 / 技术人
   - 多用场景和例子，少讲空洞概念
3. 对于专业概念，优先使用我已有的卡片内容（如果你看到我有解释，就按那个风格）
4. 每个部分先写出小标题和 2–3 段核心内容，不必细致润色
5. 标注出你认为「需要我补充个人案例/项目经历」的地方，用【这里建议补充个人案例】标记

生成的东西通常会比较「正经」且有点「AI 味儿」，但没关系：

这只是骨架，不是成稿。

八、Step 5：注入你的经验，让它变成「你的文章」

现在轮到最关键、也只有你能做的部分了——
把这个骨架，变成一篇有你味道的文章。

我会做几件事：

5.1 替换抽象描述为「我的 Bug / 场景」

例如 AI 初稿里有一句：

「如果没有幂等性，当用户重复提交请求时，就可能导致重复扣款。」

我会在旁边写：

【这里建议补充个人案例】

然后把我真实经历的故事填进去：

• • 某年某月某个支付项目
• • 用户在弱网环境疯狂点按钮
• • 数据库里出现了什么奇怪记录
• • 线下是怎么被投诉 / 被运营追杀
• • 最后是如何用某种幂等方案解决的

这种内容，是任何 AI + 原文都给不了的，它只属于你。

5.2 用自己的语言重写关键解释

如果某个段落你觉得很「翻译腔」，就干脆删掉重写。

我的做法：

1. 1. 先关掉屏幕 / 不看原文
2. 2. 回想这个知识点，然后用说给同事听的方式，口述一遍
3. 3. 把这段口述转成文字（你可以用语音转文字或直接敲）

再不济，你也可以让 AI 帮你把你的长句子「口语化」：

text

这是我刚才写的一段解释：
{你的长段落}
请你在确保技术意思不变的前提下，帮我改写成：
- 更像我在和同事聊天时说的话
- 句子短一些
- 尽量把抽象词换成具体画面

5.3 加入「中国语境」下的差异

很多英文博客的场景是：

• • AWS / GCP / Serverless
• • 国外支付体系 / 法规要求
• • 不同的团队协作方式

你可以专门开一小节：「在我们这边，这件事会有什么不一样」，比如：

• • 我们常用的是阿里云 / 腾讯云，对应服务有哪些差异
• • 团队里常见的错误认识（比如领导只关心功能，不关心幂等）
• • 某些方案在国内双十一场景下会直接爆炸

这会让你的文章立刻和一堆翻译稿拉开距离。

九、Step 6：检查逻辑、风格和「安全性」

最后一公里，别着急点「发布」，还有几件小事要做。

6.1 自查：三连问

我会自己问自己三个问题：

1. 1. 如果把原文删掉，我还能把这篇文章讲完整吗？
2. 2. 文章里有没有至少 2–3 个「只有我能写」的内容？（项目细节 / Bug 复盘）
3. 3. 读完之后，读者能学到的是「一种思路」，还是「一篇案例」？

如果三个问题的答案都还不错，我才会进入下一步。

6.2 让 AI 帮你做一轮「技术性 & 表达」校对

text

请你作为一个有经验的后端工程师，帮我审阅下面这篇中文技术文章：
{粘贴全文}
请你：
1. 标出可能存在技术性错误或容易引起误解的表述，并给出修改建议
2. 标出逻辑跳跃比较大的地方，建议我在哪里补一两句话承接
3. 对整体结构给一个简短评价：对目标读者来说，哪里可以删减或合并？

你不一定要照单全收，但有时能发现一些自己看不到的小问题。

6.3 如有顾虑，可做「相似度自检」（可选）

如果你真的很担心「太像原文」，可以把原文结构 + 自己文章结构一起丢给 AI：

text

请你对比下面两份内容的结构和表述：
【原文结构和部分原文】
{原文的目录 + 每节的开头几段}
【我的中文文章】
{你的中文文章全文}
请你判断：
1. 我的文章在结构和段落安排上，与原文是否有高度相似？
2. 有哪些部分可能会被读者认为「翻译自这篇英文文章」？
3. 如果我希望更明显地体现「二次创作」，请给出 3–5 条结构或内容上的修改建议。

AI 的判断不是法律意义上的，但能帮你发现「太像原文」的地方。

十、全流程总结 & 模板打包

最后把这条流水线再收一收，你可以直接照抄：

10.1 从英文博客到中文原创的 6 步

1. 1. 选文章：用 AI 快速评估一篇英文博客是否「值得写」
2. 2. 吃透原文：在 Obsidian 里建「源文档笔记」，用 AI 拆结构、补理解
3. 3. 重新定位：用产品思维定义你的中文文章读者 & 问题 & 承诺
4. 4. 搭大纲 & 卡片：在 Obsidian 里写大纲，把关键概念抽成知识卡片
5. 5. AI 出骨架：用 AI 生成一版初稿骨架
6. 6. 你来注魂：用自己的 Bug、项目、语气，重写和补充，最后再校对

10.2 可以直接带走的几个模板

• • Obsidian「源文档拆解」模板
• • Obsidian「文章规划 & 大纲」模板
• • 概念卡片模板（可以反复复用在不同文章里）
• • 4 个关键 Prompt：
• • 评估文章是否值得写
• • 拆解原文结构
• • 定位中文文章
• • 生成初稿骨架

（如果你愿意，我可以在后续单独出一篇「模板合集」文章，把这些做成可以直接导入 Obsidian 的示例库。）

十一、你可以今天就试一次的小练习

读完这篇文章，如果你愿意试着给自己搭一条技术输出流水线，可以做两件事：

1. 1. 在你的收藏夹里，找出一篇你真心觉得写得好，但一直没啃完的英文技术博客
2. 2. 按上面 Step 0 ~ Step 2 的流程，

• • 先在 Obsidian 里建一条「源文档拆解」笔记
• • 用文中的 Prompt 跑完「评估 → 拆解 → 定位」这三步

不要急着一口气写完整篇中文文章，
先完成这三步，你就已经比绝大多数「只会收藏不输出」的技术人，往前走了一大截。

接下来，我会继续把这套「技术人输出系统」拆下去：

• • 我每天是怎么用 Obsidian 管理选题库
• • 如何让 AI 参与选题、排期和内容再利用
• • 写 Bug 的人，怎么把事故复盘写成能帮别人的文章

如果你已经用这套流程写出第一篇文章，非常欢迎你把标题和链接发给我，
我也会当成我第二大脑里的「真实使用案例」，一起继续打磨这套工作流。