一篇技术文章，从输入到输出：Obsidian + AI 全流程实录
一只阿木木约 11 分钟一篇技术文章，从输入到输出：Obsidian + AI 全流程实录
副标题：一个写 Bug 的后端，如何把碎片知识变成能发公众号的技术文章
我是一只阿木木，一个写后端代码、也常写 Bug 的普通人。
有段时间，我对「写技术文章」这件事又爱又怕：
• 想写： • 想记录踩坑，省点以后同事和自己的时间 • 想在公众号留点「作品」，别年终只有周报可以回顾 • 又怕： • 选题永远停留在「有空一定要写写 XX」 • 真写的时候，翻十几个标签页、代码仓库、聊天记录 • 花一晚上写完一篇，第二天再看觉得又长又乱
那时候我的状态是：
输入很多，输出很少；
文章不是写不出来，而是代价太高。
这两年我开始刻意用 产品思维 + Obsidian + AI 搭一个自己的「写作工作流」：
• 把日常 Bug、需求、技术方案都沉到 Obsidian 里 • 用 AI 帮我做整理、提炼、查漏和初稿骨架 • 我只在「理解、选择、讲故事」这些地方花精力
现在我写一篇技术文章，大致会走这样的路线：
工作里的一个真实问题 →
Obsidian 里已经有的材料 →
AI 帮我补全和搭结构 →
我补上自己的踩坑和案例 →
一篇能发公众号的文章。
这篇文章，我会用「全流程实录」的方式拆给你看：
1. 我怎么从工作 / 学习中选题 2. 在 Obsidian 里怎么组织这篇文章的素材 3. AI 在哪几步能帮到你，在哪几步一定要你自己来 4. 最后如何把文章重新「回流」到知识库里，成为你第二大脑的一部分
你可以照着这条流水线，改成「你的技术输出工作流」。
一、先看全局：这条写作流水线长什么样？
以我最近写的一篇「接口幂等性实践」文章为例，我的流程大概是：
下面我按顺序走一遍，你可以对照自己的真实场景。
二、Step 0：选题——从「真实问题」开始，而不是从「很酷的概念」开始
我现在几乎不从「想写点什么新技术」出发，而是从三个入口选题：
1. 最近解决的一个 Bug / 线上事故 2. 最近写的一份技术方案 / 设计权衡 3. 最近总被问的一个问题（同事 / 群友 / 评论区）
比如这篇「接口幂等性实践」，就是因为：
• 我们线上遇到过一次重复扣款的 Bug • 我后来给团队做过一次分享 • 发现很多人都听说过「幂等性」，但没真正搞明白怎么设计键、怎么兼顾性能
2.1 在 Obsidian 里建一个选题记录
我会在 02_Projects/Write_Tech 下建一条简单的「选题记录」：
Markdown
# 选题｜接口幂等性实践
## 1. 选题来源
- 来源：最近支付系统一次重复扣款 Bug
- 实际场景：用户在弱网环境疯狂点支付按钮，造成多笔请求
## 2. 这个主题为什么值一篇文章？
- 团队里至少 3 个人问过类似问题
- 我的踩坑经历比较完整：从事故 → 方案 → 落地 → 复盘
- 中文搜索大多是概念解释，实践细节少
## 3. 暂时想到的角度
- 从一次真实事故讲起
- 拆清楚「到底什么叫幂等」，和「幂等接口」的区别
- 几种常用实现方式的利弊2.2 用 AI 快速帮你判断「写不写得动」
有时候你会有一种「这个东西好像挺大，不知道写不写得动」的犹豫，可以让 AI 帮你扫一眼：
text
我想写一篇关于「接口幂等性实践」的技术文章，下面是我目前的想法：
{粘贴上面的选题记录}
请你帮我判断两件事：
1. 以我给出的素材，这个选题是否适合写成一篇面向普通后端工程师的文章？为什么？
2. 请帮我列出 3–5 个可能的文章子标题或切入角度，优先考虑「有真实场景」「能讲案例」的。如果 AI 也能帮你梳理出几个清晰角度，基本可以确定：这篇值得写。
三、Step 1：收集输入，在 Obsidian 里建一条「源材料」笔记
很多人写文章最大的问题不是不会写，而是——
材料到处飞：IDE 里一部分、浏览器收藏夹一部分、脑子里一部分。
我会强制自己，先在 Obsidian 里集中建一个「源材料」页面，把所有东西都扔进去。
比如：2024-接口幂等性实践-源材料.md
模板如下（可直接抄）：
Markdown
# 接口幂等性实践｜源材料
## 1. 真实场景 & Bug 记录
- 事故时间：
- 涉及系统：
- 现象简述：
- 初步原因：
- 后续处理：
（可以直接粘贴事故工单、群聊记录的关键片段）
---
## 2. 相关资料链接
### 外部文章 / 文档
- [某支付平台的幂等性设计文章](url)
- [官方文档 - 幂等性](url)
> 用 AI 帮我做的要点总结：
> - 要点 1
> - 要点 2
### 内部文档 / 代码片段
- 文档：
- 代码路径：
---
## 3. 原始想法小记（未整理）
- 我当时是怎么定位问题的？
- 哪一步最难？
- 现在回头看，会不会有更好的方案？
---
## 4. 可用的图/表/示意
- 流程图草图：
- 请求-响应时序草图：在这个阶段，我会用 AI 做两件「省时间但是靠谱」的事：
1. 帮我把长文档/长博客，压成要点，粘在「相关资料」下面 2. 帮我把聊天记录里关键信息挑出来（比如事故经过）
之后写文章时，我只看这一个「源材料」页面就够了，不用到处切换窗口。
四、Step 2：用产品思维，给这篇文章写一份「迷你 PRD」
写技术文章的时候，我会强迫自己先想清楚 3 个问题：
1. 这篇文章写给谁？（越具体越好） 2. 他在什么场景下会搜到这篇文章？ 3. 我能给他什么具体承诺？
在 Obsidian 里，我会单独建一条「文章规划」笔记，比如：2024-接口幂等性实践-文章规划.md
模板如下：
Markdown
# 文章规划｜接口幂等性实践
## 1. 目标读者是谁？
- 职业/阶段：2–5 年经验的后端工程师
- 当前状态：
- 知道「幂等性」这个词，但概念模糊
- 写过“看起来幂等”的接口，但没遇过大事故
- 典型场景：
- 在做支付/下单类接口设计
- 想避免「重复扣款」「重复创建订单」
## 2. 这篇文章要帮他解决的核心问题
- 懂一句话解释什么是「幂等性」
- 知道常见的 2–3 种实现方式和适用场景
- 能根据自己项目特点，选出一个起步方案
## 3. 我能给出的承诺
- 不只是抄概念，而是从一次真实事故讲起
- 给出可以直接抄的幂等性 Key 设计 checklist
- 文章结尾有一个「给普通团队的落地建议」
## 4. 初步标题备选
- 写 Bug 写出的接口幂等性实践：一次重复扣款事故的复盘
- 普通后端如何给接口加上幂等性保险丝？4.1 用 AI 帮你校正「读者画像」和「承诺」
你可以把这份规划丢给 AI，请它当编辑挑刺：
text
这是我要写的一篇技术文章的规划：
{粘贴上面的文章规划}
请你帮我：
1. 看看目标读者画像是否具体、清晰，如果太模糊，请指出并给建议
2. 判断这篇文章的「承诺」是否过大或过空，如果是，请帮我改成更具体、更可实现的表述
3. 给出 2–3 个你认为更有吸引力的标题备选这样做的好处是：
• 你不会在开局就立一个「教你彻底精通幂等性」这种假大空的 flag • 刚好也顺手踩住「读者心理」： • 不是告诉他「你会变成专家」，而是告诉他「你能少踩几个坑」。
五、Step 3：拆知识点，建成可复用的卡片笔记
这一步，是整个工作流最「第二大脑」的部分。
我会从「源材料」笔记里，挑出几个关键知识点或案例，分别变成独立卡片：
• 概念卡片： • 幂等性（Idempotency） • 幂等性 Key 设计 • 幂等接口 vs 重试机制的区别 • 案例卡片： • 支付重复扣款事故复盘 • 幂等性补救方案的副作用
在 03_Knowledge/后端/幂等性 下，新建类似这样的笔记：
Markdown
# 幂等性（Idempotency）
## 1. 概念（用自己的话解释）
## 2. 关键要点（3–5 条）
## 3. 示例 / 代码片段
## 4. 常见误解
## 5. 来自哪些项目 / 文章？
- 我们项目：xxx
- 参考文章：xxxMarkdown
# 案例｜支付重复扣款事故复盘
## 1. 背景
## 2. 事故经过（时间线）
## 3. 根因分析
## 4. 采取的方案 & 权衡
## 5. 复盘结论未来你再写别的文章（比如「重试机制设计」），
可以直接引用这些卡片，而不是从零开始想。
六、Step 4：用 AI 从卡片和规划里，生成大纲和「初稿骨架」
现在，我们有了：
• 源材料 • 文章规划（读者、场景、承诺） • 若干知识卡片
可以请 AI 帮我们生成「大纲 + 初稿骨架」。
6.1 给 AI 的输入示例
在聊天窗口里，我会这样组织信息：
text
下面是我准备写的一篇技术文章的素材，请你帮我生成一份大纲和初稿骨架。
【1. 文章规划】
{粘贴「文章规划」的内容}
【2. 我的知识卡片】
{粘贴「幂等性」概念卡片和「事故复盘」卡片的内容（适当简化）}
【3. 写作风格要求】
- 面向 2–5 年经验的普通后端程序员
- 尽量用真实场景和例子，不要空讲概念
- 开头希望用「事故故事」引出主题
请你：
1. 先给出一份详细大纲（含一二级标题），用中文
2. 再根据大纲，为每一节写 2–3 段「初稿骨架」，不需要很完整，但要把核心意思讲明白
3. 在你认为适合补充「个人经历/项目细节」的地方，用【这里补充个人案例】标记出来通常第一次的结构会有点教科书气质，但这没关系：
我们接下来要做的是「人改 AI」，而不是「AI 改人」。
七、Step 5：你来写灵魂——把骨架变成有你风格的技术文章
现在你手里有一份「初稿骨架」，接下来的重点是两件事：
1. 用自己的话重写关键解释 2. 在【这里补充个人案例】的位置，认真讲你自己的故事
7.1 把抽象解释，改成「你真的会对同事说的话」
比如 AI 可能写出这样的句子：
「幂等性是指同一个请求被执行多次，其产生的结果与执行一次的结果相同。」
我会自己改写成更口语一点：
「简单说，幂等性就是：同一笔操作，你打我一次和打我十次，最后的结果应该一样。
在接口里就是：这个请求你点一次提交和点十次提交，系统只应该当成一次处理。」
如果你自己写不出「口语版」，可以反过来用 AI 帮你：
text
请把下面这句解释改得更口语、更接地气一些，适合写给普通后端工程师看：
{那句专业/拗口的解释}7.2 认真写好两个地方：事故故事 & 方案权衡
以这篇幂等性为例，我会重点把这两个部分写详细：
1. 事故故事：
• 时间点、谁发现的、用户反馈是什么、当时你在干嘛 • 你们内部是怎么排查的、花了多久、情绪怎样
• 你一开始想到的方案 A、后来选的方案 B • A 和 B 分别有什么坑 • 为什么最后选了现在这个，放弃了另一个
这些内容，是任何英文博客 + AI 都给不了的，
也是这篇文章真正属于你的部分。
八、Step 6：用 AI 做一轮结构和技术性「挑错」
初稿写完后，我会让自己先离开屏幕一会儿，
回头看一遍，再把全文丢给 AI 做审阅。
8.1 结构 & 连贯性检查
text
请你作为一个有经验的后端工程师兼技术编辑，帮我审阅下面这篇文章：
{粘贴全文}
请你：
1. 标出逻辑跳跃比较大的地方，并给出应该如何承接的建议
2. 标出可以删减或合并的小节，让文章更紧凑
3. 简短评价一下整体结构是否对「目标读者」友好，有没有哪一部分过难或过简单8.2 技术性 & 术语使用检查
text
从技术角度，请你检查文中：
1. 关于幂等性的概念和结论，有没有明显错误或容易误导的地方？
2. 代码/伪代码的示例有没有可能引起误解？
3. 如果你是读者，读完之后有没有哪一段会产生「这不太对吧？」的感觉？请直接指出并说明理由。你不一定要全听，但经常能发现一些你自己看不出来的问题。
九、Step 7：发布 & 回流——让文章回到你的第二大脑里
文章发出去之后，这件事还没结束。
我会做两件事情，让这篇文章变成「以后自己也能复用的资产」：
9.1 在 Obsidian 里给文章建一条索引
在 03_Knowledge/输出索引 下建一条：
Markdown
# 文章索引｜接口幂等性实践
## 1. 基本信息
- 标题：
- 链接：
- 发布时间：
## 2. 对应的知识卡片
- [[幂等性（Idempotency）]]
- [[案例｜支付重复扣款事故复盘]]
- [[幂等性 Key 设计]]
## 3. 针对谁？
- 目标读者画像摘要：
## 4. 可以如何二次利用？
- 做一期内部分享
- 拆成 2 条短内容发朋友圈/视频号
- 作为下一篇「重试机制」文章的前置知识以后你再写相关话题，
只要打开「输出索引」，就能一眼看到自己有哪些文章可复用。
9.2 简单记录一下反馈 & 改进点
一周后回顾时，我会在文章索引下面加一段小复盘：
Markdown
## 5. 反馈 & 复盘
- 阅读量/在看/点赞情况（大致写一下）
- 评论里出现频率最高的问题：
- 这篇文章哪里写得最费劲？
- 如果重写一次，会怎么改结构？这一小段，会对你之后每一篇文章的选题和结构，都产生影响。
十、总结：普通技术人也能拥有一条「写作流水线」
把这篇文章压缩成一句话，就是：
用 Obsidian 管「材料」，用 AI 帮「结构和查漏」，
用你自己来「讲故事和做选择」。
再拆成可执行的几个动作，就是：
1. 每篇文章都从一个真实问题开始：
选题来自 Bug、需求、同事问题，而不是空想2. 在 Obsidian 里集中建一条「源材料」和一条「文章规划」：
所有链接、记录、想法都收敛到这两条笔记3. 先拆成知识卡片，再让 AI 生成大纲和骨架：
把「结构化」和「查缺补漏」交给 AI4. 你负责加上自己的踩坑、权衡、语气：
让文章从「可以读」变成「只属于你」5. 发完之后，让文章回到第二大脑中：
建索引、连回卡片，顺便记录一次小复盘
十一、你可以今天就试一次的小练习
如果你也想给自己搭一条技术写作工作流，可以从一件小事开始：
1. 打开你最近写过的一个技术方案 / 处理过的一个 Bug 2. 在 Obsidian 里建两条笔记：
• 一条叫「{主题}｜源材料」 • 一条叫「{主题}｜文章规划」
先别考虑「这篇要不要发」，
先让「从真实问题到一个清晰大纲」这件事，在你的系统里跑通一次。
如果你愿意把第一篇按这个流程写出来的技术文章标题发给我，
我也会很乐意在之后的内容里，拆几篇读者案例，一起打磨这条流水线。