从读一篇文章到上线一个功能：我的知识系统和产品开发流程完整链路
一只阿木木约 19 分钟从读一篇文章到上线一个功能：知识→产品完整链路
2026 年 2 月 23 日，我在 RSS 订阅里读到了一篇文章。
8 天后，3 月 3 日，基于这篇文章的洞察，一个新功能上线。
不是因为我开了挂，不是因为我组建了团队。
而是因为我的知识系统和产品开发流程，完全打通了。
这篇文章记录的，是这么一件事。
在开始之前
我需要说清楚这篇文章的性质。
这不是教程，不是方法论，不是"你应该这样做"。
这是一份完整的实况记录——从第一次看到那篇文章，到功能上线，中间发生的每一步，我都记录了下来。
时间线是真实的，数据是真实的，决策是真实的，踩的坑也是真实的。
我想让你看到的是：
当一个知识系统真正运转起来，它不只是帮你"管理笔记"，它会成为你产品创新的源头。
Day 1：一篇文章，2 月 23 日，下午 3:47
那天下午我在通勤路上，刷 RSS 订阅。
看到一篇 Simon Willison 的博客：《LLM 的会话状态应该像 Git 一样有版本管理》。
标题让我停了一下——这个类比有点意思。
我点进去读。
文章不长，核心观点是：
text
现在所有的 AI 对话工具，会话历史都是线性的。
你说一句，AI 回一句，按时间顺序往下排。但很多时候，对话不是线性的：
- 你可能想「撤销」前面某个错误的指令，但不是删除整条对话
- 你可能想在对话的某个节点「开分支」，试试不同的方向
- 你可能想把两个分支「合并」，综合两个方向的结果
这些操作，在代码开发里用 Git 做得很好。
为什么在 AI 对话里，还是石器时代的「撤销/重做」？
我读完，第一反应是：这个想法很有价值，但也许已经有人在做了。
然后我在文章末尾看到作者自己的判断：
「我搜了一圈，没找到有哪个主流 AI 工具实现了这个想法。如果你知道有，请告诉我。」
这句话让我决定把这篇文章剪藏进知识库。
操作记录：
text
时间：15:53
动作：Obsidian Web Clipper → 剪藏文章
目标：00-Inbox/web-clips/
文件名：simon-willison-llm-conversation-git.md
耗时：约 20 秒
剪藏的时候，我做了一件习惯性的动作：在文章开头加了一条批注。
Markdown
[批注 2026.02.23]
这个想法的价值在于「撤销」和「分支」的心智模型很直观。
但我不确定「合并」在 AI 对话场景下有多大意义——
和代码不同，对话的「合并冲突」怎么解决？值得编译进 Wiki 时思考：
- 这个想法是否和我已有的「AI 对话管理」词条有关联？
- 是否触及了某个未被解决的用户痛点？
加完批注，我关掉了手机，继续通勤。
在我的意识里，这件事已经结束了——读了一篇有趣的文章，存进了知识库，今天的输入任务完成。
但实际上，这件事才刚刚开始。
Day 1：晚上 10:02，我已经睡了
Codex Automation 准时启动。
它扫描了今天进入 00-Inbox/ 的所有内容，包括那篇 Simon Willison 的文章。
编译日志（部分）：
text
[22:02:15] 读取文件：simon-willison-llm-conversation-git.md
[22:02:17] 检测到人工批注，进入 annotation-guided 模式
[22:02:18] 读取 Schema：50-Schema/wiki-entry-schema.md
[22:02:19] 扫描相关现有词条...[22:02:23] 发现相关词条：
- 10-Wiki/concepts/ai-conversation-management.md
- 10-Wiki/tools/chatgpt-conversation-features.md
- 10-Wiki/debates/ai-ux-pain-points.md
[22:02:30] 创建新词条：
10-Wiki/concepts/conversation-branching.md
[22:02:45] 更新词条：ai-conversation-management.md
新增段落：「基于 Git 模型的会话管理」
来源：Simon Willison 2026.02
[22:03:02] 更新词条：ai-ux-pain-points.md
补充到「未解决的用户痛点」列表：
「对话撤销/分支的需求」
关联到新建词条 [[conversation-branching]]
[22:03:15] 检查交叉引用...
[22:03:28] ⚠ 发现潜在关联：
词条「AI Agent 会话状态管理」中有一段：
「当前主流方案是线性会话历史存储，
用户无法在对话中途回溯并开启新方向」
这段内容和本次新建的「conversation-branching」
词条高度相关，建议建立交叉引用。
→ 已自动建立 [[wikilink]]
[22:03:45] 标记待人工确认：
ID: D-2026-0223-001
内容：新词条「conversation-branching」是否应该
新建为独立词条，还是并入已有的
「ai-conversation-management」主词条？
等待确认。
[22:03:46] 编译完成。
这个编译过程，在我睡觉的时候发生。
第二天早上，我会花五分钟看这份报告，做最后的确认。
但有一件事，是在这个晚上 10:03 就已经发生的：
「conversation-branching」这个概念，被自动关联到了「AI Agent 会话状态管理」词条。
这个关联，是我在阅读那篇文章的时候，完全没有意识到的。
Day 2：早上 8:15，我看到了那个关联
text
通勤路上，打开手机，查看昨晚的编译报告。看到待确认项：
「conversation-branching 是否应该独立成词条？」
我的决定：独立。
理由：这个概念足够独立，而且有清晰的边界——
它是一种具体的交互模式，不只是「对话管理」的一个维度。
确认完毕。
然后我继续往下翻报告。
看到了「自动建立的交叉引用」部分。
看到了这一条：
text
[[conversation-branching]] ←→ [[ai-agent-session-state]]
我愣了一下。
打开「AI Agent 会话状态管理」词条。
看到了这段：
Markdown
## 当前主流方案的局限所有主流 AI 对话工具（ChatGPT、Claude、Gemini）
都使用线性会话历史存储。
用户无法在对话中途「回溯并开启新方向」——
如果你在第 10 轮对话时发现第 5 轮的某个回答不对，
你只能：
A. 重新开一个对话（丢失 6-10 轮的所有上下文）
B. 继续错下去（后面的所有对话都建立在错误前提上）
没有第三条路。
这是一个已知但未被解决的用户痛点。
（来源：多篇用户调研，详见 [[ai-ux-pain-points]]）
[2026.02.23 更新]
Simon Willison 提出的「Git 式会话管理」可能是
这个痛点的一个解法方向。详见 [[conversation-branching]]
看到这段的时候，我脑子里突然出现了一个画面。
Day 2：早上 8:23，一个想法涌现
我在做的一个产品——一个基于 Claude Code 的 Obsidian 知识库编译助手——正好涉及「和 AI 的长对话」。
用户在使用这个工具的时候，经常会遇到一个场景：
text
用户让 AI 编译了 10 个词条。
第 7 个词条，AI 的分类判断错了。
用户发现之后，想让 AI「回到第 6 个词条之后，重新处理第 7 个」。但现在的实现方式，用户只能：
A. 手动修复第 7 个词条（失去了 AI 辅助）
B. 重启整个对话，重新处理 1-10（浪费时间）
我一直知道这是一个用户痛点，但我不知道怎么优雅地解决它。
直到看到「Git 式会话管理」这个概念。
这就是知识网络的价值所在。
我读 Simon Willison 的文章时，完全没有想到它和我正在做的产品有关。
但知识库里的自动编译，发现了这个关联：
text
「conversation-branching」
↓ （自动关联）
「AI Agent 会话状态管理」
↓ （已有关联）
「我的产品当前遇到的用户痛点」
这条关联链，在我阅读的时候不存在。
是编译系统，在我睡觉的时候，帮我建立了它。
操作记录：
text
时间：08:26
动作：在「conversation-branching」词条下，
新增一个字段：「potential-application」
内容：我的 Obsidian 编译助手，会话回溯场景
标记：product-idea
然后我给自己发了一条备忘录：
「今晚花 1 小时，认真想想这个功能怎么实现。」
Day 2：晚上 8:30，开始认真思考
我打开 Obsidian，进入 20-Products/obsidian-compiler-assistant/ 目录。
这是我这个产品的知识库分区。
创建了一个新文件：feature-conversation-branching.md
开始写 PRD。
PRD 的诞生过程（真实记录）
这个 PRD 不是我从零写的。
我用了 product-spec-writer Skill。
具体操作：
Bash
claude-code run product-spec-writer \
--idea "实现 Git 式的会话分支管理" \
--related-concepts "[[conversation-branching]], [[ai-agent-session-state]]" \
--target-pain-point "用户在长对话中发现中途某步错误，无法优雅回溯"
Skill 执行过程：
text
[20:32:15] 读取相关概念词条...
[20:32:18] 扫描产品当前的用户痛点记录...
[20:32:25] 生成 PRD 草稿...
[20:32:58] PRD 初稿完成，等待人工审核
生成的 PRD 草稿（部分）：
Markdown
# 功能规划：会话分支管理## 问题定义
用户在使用编译助手处理批量词条时，对话可能持续 10-20 轮。
当用户在第 N 轮发现之前某一轮（第 M 轮，M < N）的 AI 判断有误，
当前没有好的解决方案。
重启对话 = 浪费已完成的工作
继续错误 = 后续所有操作建立在错误前提上
手动修复 = 失去 AI 辅助的价值
## 解决方案
引入 Git 式的会话分支模型：
1. 会话节点化
每一轮对话是一个「节点」，而不是线性追加的条目
2. 回溯能力
用户可以「回退」到任意历史节点
3. 分支能力
从任意节点可以「开启新分支」，探索不同路径
4. 分支可见性
用户可以看到当前对话的「分支树」，
就像 Git 的 commit tree
## 核心用户故事
作为 用户
当我 在第 12 轮对话时发现第 7 轮的分类判断有误
我希望 能回到第 6 轮之后，开启一个新分支，重新处理第 7 轮
这样 后续 8-11 轮的有效工作不会丢失，
我可以在修正后的分支上继续，
或者对比两个分支的结果
## 技术可行性（待确认）
- Codex 的会话 API 是否支持非线性历史？
- 分支存储的数据结构？
- UI 如何展示分支树？
我花了 20 分钟审核这份草稿。
修改了两处：
把「分支可见性」的优先级调低——第一版先实现功能，UI 展示可以后续优化 补充了一个约束条件：分支深度不超过 3 层，避免用户陷入分支迷宫
最终版 PRD 确认完毕。
耗时：从想法到 PRD 完成，约 45 分钟。
Day 3：验证技术可行性
PRD 写好了，但我不确定技术上是否真的可行。
核心疑问：
text
Codex 的 API，对话历史是否支持「插入历史节点后重新生成」？如果不支持，这个功能就是空中楼阁。
我需要验证。
操作记录：
text
时间：09:15
动作：在知识库里搜索「Codex API 会话管理」
结果：找到一个相关词条
打开词条：10-Wiki/tools/codex-api-conversation.md
看到了这段：
Markdown
## API 的会话模型Codex API 的对话请求是无状态的。
每次请求需要显式传入完整的 messages 数组。
这意味着：
- 服务端不存储会话历史
- 客户端可以任意构造 messages 数组
- 可以在数组中间插入、删除、修改消息
典型用法：
messages = [
{"role": "system", "content": "..."},
{"role": "user", "content": "..."},
{"role": "assistant", "content": "..."},
{"role": "user", "content": "..."} ← 可以任意修改这个数组
]
这种无状态设计，天然支持非线性会话操作。
看到这段，我松了一口气。
技术上可行。
Codex 的 API 设计，恰好天然支持「回退到某个节点，重新构造后续对话」这个操作——因为它根本不关心你的 messages 数组是怎么来的，只要是合法的数组就行。
这段知识，是我三个月前读 Codex 文档时编译进知识库的。
那时候我完全没想到它会在这个场景下派上用场。
这是知识复利的第二次体现。
第一次：编译系统发现了「conversation-branching」和我产品痛点的关联。
第二次：已有的 Codex API 知识，直接回答了技术可行性的问题。
如果没有知识库，我需要：重新去翻 Codex 文档，或者写一个 demo 测试，或者去论坛问别人。
现在，答案已经在知识库里等着我了。
Day 3-4：拆分 User Stories
PRD 确认，技术可行性验证，下一步是把功能拆解成可执行的任务。
我用了 Codex 来做这件事。
操作记录：
Bash
claude-code run product-spec-writer \
--task "user-story-breakdown" \
--prd "20-Products/obsidian-compiler-assistant/feature-conversation-branching.md"
生成的 User Stories：
Markdown
## User Story 1：会话节点化存储作为 系统
当 用户和 AI 完成一轮对话
系统需要 把这轮对话存储为一个「节点」，
而不是追加到数组末尾
这样 后续可以基于任意节点构建新分支
估算工时：4 小时
依赖：无
---
## User Story 2：回退到历史节点
作为 用户
当 我想撤销最近几轮对话
我可以 点击「回退到第 N 轮」
系统 将对话状态恢复到第 N 轮之后，
后续的 N+1, N+2... 轮不可见（但不删除）
估算工时：3 小时
依赖：US-1
---
## User Story 3：从历史节点开启新分支
作为 用户
当 我回退到第 N 轮后
我可以 输入新的内容，开启一个新分支
系统 在节点树上创建一个分支节点
新的对话在这个分支上继续
估算工时：5 小时
依赖：US-1, US-2
---
## User Story 4：分支切换
作为 用户
当 我在某个分支上工作
我可以 切换到另一个分支
系统 显示那个分支的对话历史
估算工时：2 小时
依赖：US-3
---
## User Story 5：分支对比（可选，v2 功能）
作为 用户
当 我在两个分支上都探索了不同方向
我希望 能并排查看两个分支的结果
这样 我可以决定哪个方向更好
估算工时：6 小时
依赖：US-3, US-4
优先级：低
我审核了这份拆解。
决定：
US-1 到 US-4 进入 v1 版本 US-5 延后到 v2
确认完毕后，我把这 4 个 User Stories 保存为独立文件，放进 user-stories/ 目录。
Day 4：Codex 开始并行构建
这是整个流程里最「魔法」的部分。
我不是一个 User Story 一个 User Story 串行开发的。
我把 4 个 User Stories 同时交给了 Codex。
操作记录：
Bash
# 为每个 User Story 创建一个 Codex 任务
for story in user-stories/*.md; do
claude-code create-task \
--from-user-story "$story" \
--branch "feature/conversation-branching-$(basename $story .md)" \
--agents-config "20-Products/obsidian-compiler-assistant/AGENTS.md"
done# 启动并行执行
claude-code run-parallel --max-agents 3
Codex 启动了 3 个并行 Agent，每个 Agent 在独立的 Git 分支上工作。
text
[10:23:05] Agent-1 → 处理 US-1（会话节点化）
[10:23:06] Agent-2 → 处理 US-2（回退功能）
[10:23:07] Agent-3 → 处理 US-4（分支切换）
US-3 因为依赖 US-1 和 US-2，被自动排入队列，等待依赖完成。
我的工作是：审核每个 Agent 的代码，决定是否合并。
从 Day 4 到 Day 6，我的实际工作时间分布：
text
Day 4：
09:00-10:30 设置 Codex 任务，启动并行执行
18:00-19:30 审核 Agent-1 完成的 US-1 代码，批准合并Day 5：
08:00-09:00 审核 Agent-2 完成的 US-2 代码，发现一处问题，
要求修改后重新提交
19:00-20:00 审核 Agent-2 的第二版，批准合并
审核 Agent-3 完成的 US-4 代码，批准合并
20:15-21:30 US-3 自动启动（依赖已满足），
我审核中间过程，批准继续
Day 6：
08:30-09:30 审核 US-3 最终代码，批准合并
10:00-11:00 整合测试，发现两处小 bug，手动修复
总计人类净工作时间：约 8.5 小时
但日历时间：3 天
因为 Codex 在我不工作的时候，仍在运行。
Day 7：写文档和测试
代码合并完成，功能基本可用。
但一个功能不只是代码，还需要：
用户文档（怎么使用这个功能） 更新日志（这个版本改了什么） 内部文档（技术实现的设计决策记录）
这三份文档，我用了不同的方式生成。
用户文档： 我自己写，因为我需要用真正好懂的语言解释这个功能，AI 写的文档往往「准确但不好懂」。
更新日志： Codex 自动生成，基于所有 commit 信息，质量可以接受。
技术实现记录： 我让 Codex 生成初稿，我审核后补充关键的设计决策和 trade-off。
这三份文档，总计花了约 3 小时完成。
测试：
我找了两个朋友（都是这个工具的用户）帮我内测。
给他们发了开发版，让他们试用「会话分支」功能。
收到的反馈：
text
用户 A：
"这个功能解决了我一个真实的痛苦——我之前经常要重开对话，
现在可以回退了，舒服多了。 但有个问题：分支切换的按钮位置有点难找，
我第一次用的时候找了两分钟。"
用户 B：
"很好用。但我有个疑问：
如果我开了三个分支，我怎么知道每个分支现在到哪一步了？
能不能在分支列表里显示每个分支的最后一条消息？"
两条反馈都很有价值。
我当天晚上花了 1.5 小时，做了两个小优化：
调整了分支切换按钮的位置（采纳用户 A 的建议） 在分支列表里显示每个分支的最后一条消息预览（采纳用户 B 的建议）
Day 8：上线
2026 年 3 月 3 日，早上 9:00。
我把新版本推送到 GitHub，更新了 Release Notes，发了一条推文：
text
我们刚上线了一个新功能：会话分支管理。灵感来自 @simonw 的一篇博客——
他说 LLM 对话应该像 Git 一样有版本控制。
我们把这个想法实现了。
现在你可以：
- 回退到对话的任意节点
- 从任意节点开启新分支
- 在不同分支间切换
8 天，从读到一篇文章，到功能上线。
知识库 → 产品的完整链路，跑通了。
回头看：这条链路是怎么跑通的
从 Day 1 的那篇文章，到 Day 8 的功能上线，中间有六个关键节点。
让我逐一拆解：
节点一：文章被编译进了知识网络，而不是收藏夹
如果我只是把那篇文章「收藏」了，它会躺在某个文件夹里，三个月后我不会记得它的存在。
但因为它被编译进了知识库：
新建了一个「conversation-branching」词条 自动关联到了「AI Agent 会话状态管理」词条 被补充进了「未解决的用户痛点」列表
这些关联，不依赖于我的记忆力，不依赖于我偶然想起来。
编译系统把这篇文章放进了它应该待的网络位置。
节点二：自动发现的关联，触发了产品洞察
我读那篇文章的时候，完全没想到它和我的产品有关。
是编译系统发现了关联链：
text
conversation-branching
→ AI Agent 会话状态管理
→ 我产品的用户痛点
如果没有这个自动关联，我可能永远不会把「Git 式会话管理」和「我的产品」联系在一起。
这是知识网络最核心的价值：它能发现你自己看不到的连接。
节点三：已有知识直接回答了技术可行性
当我需要验证技术可行性时，答案已经在知识库里等着我——那是三个月前积累的 Codex API 知识。
这节省了我至少 2-3 小时的查资料时间。
更重要的是：它让我在产生想法的 24 小时内，就确认了可行性。
如果这个验证需要几天时间，这个想法可能会在我的待办列表里被其他事情淹没，最终不了了之。
节点四：从 Wiki 到 PRD 的自动生成
product-spec-writer Skill 不是凭空生成 PRD，它读取的是：
相关的 Wiki 词条（问题定义、技术背景） 产品已有的用户痛点记录 类似功能的设计决策历史
这些都在知识库里。
PRD 的初稿质量之所以高，是因为它站在了已有知识的肩膀上。
节点五：User Stories 到并行开发的自动化
这一步展示的不是「AI 能写多好的代码」，而是「系统化的流程能压缩多少时间」。
4 个 User Stories，如果我串行开发，保守估计需要 14 小时人类工作时间 + 3 天日历时间。
Codex 并行执行后，人类工作时间变成了 8.5 小时（主要是 code review），日历时间变成了 3 天，但大部分时间我在做其他事情。
这不是「AI 替我写代码」，这是「AI 替我执行我已经设计好的任务」。
设计是人类的，执行是 AI 的。
节点六：从上线到知识反哺
功能上线之后，我做了一件事：
把这次开发过程中的核心设计决策，编译回知识库。
具体来说，我新建了一个词条：10-Wiki/patterns/git-style-conversation-ui.md
这个词条记录了：
Git 式会话管理在 AI 对话场景下的适用性 技术实现的核心方案（无状态 API + 客户端节点树） 遇到的问题和解法（分支深度限制、UI 可见性设计） 用户反馈（两条关键的 UX 改进建议）
这个词条，是这次产品实践的沉淀。
三个月后，当我或者其他人再次遇到「AI 对话的 UX 设计」这个话题，这个词条会被关联到，提供一手的实践经验。
知识不只是流向产品，产品经验也会反哺知识。
这才是真正的闭环。
数据总结
让我用数据说话。
text
┌──────────────────────────────────────────────────┐
│ │
│ 从阅读到上线：完整数据账单 │
│ │
├──────────────────────────────────────────────────┤
│ │
│ Day 1：阅读 + 剪藏 │
│ 人类时间：约 15 分钟（阅读）+ 1 分钟（剪藏） │
│ AI 时间： 约 2 分钟（编译） │
│ │
│ Day 2：想法涌现 + PRD │
│ 人类时间：约 15 分钟（查看报告 + 决策） │
│ 约 45 分钟（审核和修改 PRD） │
│ AI 时间： 约 30 秒（生成 PRD 初稿） │
│ │
│ Day 3：技术验证 │
│ 人类时间：约 10 分钟（查知识库 + 确认） │
│ AI 时间： 0（知识已在库中） │
│ │
│ Day 3-4：User Stories 拆分 │
│ 人类时间：约 30 分钟（审核和调整） │
│ AI 时间： 约 2 分钟（生成） │
│ │
│ Day 4-6：并行开发 │
│ 人类时间：约 8.5 小时（Code Review + 整合测试） │
│ AI 时间： 约 72 小时日历时间（并行执行） │
│ │
│ Day 7：文档 + 测试 │
│ 人类时间：约 4.5 小时（写文档 + 处理反馈） │
│ AI 时间： 约 20 分钟（生成文档初稿） │
│ │
│ Day 8：上线 + 知识反哺 │
│ 人类时间：约 1 小时（发布 + 编译实践经验回库） │
│ │
├──────────────────────────────────────────────────┤
│ │
│ 总计： │
│ 人类净工作时间：约 15.5 小时 │
│ 日历时间： 8 天 │
│ │
│ 如果用传统方式（无知识库 + 无 AI 并行）： │
│ 估算人类工作时间：约 40-50 小时 │
│ 估算日历时间： 14-21 天 │
│ │
└──────────────────────────────────────────────────┘
三个让我自己都意外的发现
复盘这 8 天，有三件事是我在开始之前没有预料到的。
发现一：最有价值的时间，是「编译运行的那 2 分钟」
Day 1 晚上，Codex 编译那篇文章只用了 2 分钟。
但就是这 2 分钟，它建立了一个我自己永远不会想到的关联：conversation-branching → ai-agent-session-state → 我的产品痛点
后面所有的事情，都从这 2 分钟开始。
这是我第一次真正体会到：「编译」不只是整理，是发现。
发现二：知识库不只是回答「是什么」，也回答「能不能做」
Day 3 验证技术可行性的时候，我打开知识库，找到了三个月前的 Codex API 知识。
那条知识里有一句话：「无状态 API 设计，天然支持非线性会话操作。」
这句话直接回答了我的问题：能做。
知识库里积累的不只是概念定义，还有技术约束、可行性边界、实践经验。
这些「隐性知识」，在传统笔记系统里很难被有效留存，因为它们太零散了。
但在编译型系统里，它们会被自动聚合到相关词条下，等待被调用。
发现三：最难的不是「写代码」，是「想清楚要做什么」
8.5 小时的 Code Review，和 40-50 小时的传统开发——差的不只是 AI 写代码的速度。
差的是：在传统开发里，「想清楚要做什么」这件事，和「写代码」这件事是混在一起的。
你边写边想，写到一半发现思路不对，推翻重来，再写再想。
但在这个流程里，「想清楚要做什么」这件事，在 PRD 和 User Stories 阶段就完成了。
到了代码阶段，AI 只是把已经想清楚的事情执行出来。
执行的速度可以很快，因为方向已经明确了。
这让我意识到：AI 时代，产品经理的价值不是「管理开发进度」，而是「把问题定义清楚」。
定义清楚了，执行可以很快。定义不清楚，再快的执行也是浪费。
如果没有知识库，这件事会发生吗
我认真想过这个问题。
答案是：不会。
不是因为我没有能力开发这个功能。
而是因为：
第一，我不会产生这个想法。
我读 Simon Willison 的文章时，如果它只是被收藏在某个文件夹里，我不会把它和我的产品联系起来——那篇文章谈的是「LLM 对话」，我的产品是「Obsidian 编译助手」，表面上没有关联。
是知识库的自动编译，发现了深层关联。
第二，即使我产生了想法，我会在验证可行性的阶段卡住。
我需要重新去查 Codex API 文档，或者写一个 demo 测试。这至少需要半天时间。
半天时间，足够让一个想法从「我现在就想做」变成「等有空再说」。
而「等有空再说」的事情，90% 最终不会发生。
第三，即使我验证了可行性，我会在「不知道从哪里开始」的时候放弃。
从一个想法到一个 PRD，从 PRD 到 User Stories，从 User Stories 到实际代码——每一步都需要决策。
如果没有系统化的流程，我需要每一步都手动推进，摩擦力极大。
摩擦力大到一定程度，我会觉得「这个功能也许没那么重要」，然后不做了。
但有了知识库 + 自动化流程，摩擦力几乎消失了。
想法自动涌现（因为知识网络帮我发现了关联）。
可行性自动验证（因为知识已经在库里）。
PRD 自动生成初稿（我只需要审核和调整）。
代码并行执行（我只需要 Code Review）。
每一步的摩擦力都被压到了最低，想法从诞生到实现的路径，变得非常顺滑。
这才是这套系统最大的价值：它不只是让你「做得更快」，它让你「真的会去做」。
最后想说的话
这篇文章记录的，是一次真实的经历。
但我更希望你看到的，不是这个功能本身，而是背后的模式：
你的阅读，不应该是消费，应该是播种。
你今天读到的一篇文章，也许和你当下的工作没有任何关系。
但当它被编译进你的知识网络，它会在那里等待。
也许三个月后，也许半年后，当你遇到某个问题，你的知识网络会告诉你：
「你三个月前读过的那篇文章，和你现在遇到的这个问题，有关联。」
这个关联，可能是一个产品洞察，可能是一个技术方案，可能是一个被你遗忘但恰好有用的知识片段。
我在这 8 天里最深刻的体会是：
知识的价值，不在于你「知道多少」，而在于「你知道的东西之间，有多少连接」。
一个孤立的知识点，价值是 1。
十个孤立的知识点，价值是 10。
但十个相互连接的知识点，价值可能是 100——因为它们之间的组合，会产生新的洞察。
编译型知识系统做的事情，就是最大化这些连接的密度。
从 2 月 23 日读一篇文章，到 3 月 3 日上线一个功能。
8 天。
15.5 小时人类净工作时间。
这不是神话，不是个例。
这是当知识系统真正运转起来之后，会自然发生的事情。
你的知识库里积累得越多，这种事情发生的频率就越高。
这就是复利。
如果你从第一篇读到现在，你已经完整走过了这条认知升级的路径。
剩下的，就是开始动手。
///
最后一个问题：
你有没有过这样的经历——某个很久以前看过的东西，突然在某个时刻帮到了你？
那是什么？发生在什么场景下？
评论区见。我想知道，在你的经历里，知识的「复利时刻」长什么样。
扫码加入行动营👇获取更多Obsidian + AI数字大脑实践
关注【一只阿木木】。
我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统
去做，才是真的学。🌊