我把 142 条笔记喂给了 AI，它帮我发现了 3 个我自己都没注意到的知识盲区
一只阿木木约 11 分钟上一篇终篇发出后，后台收到最多的私信不是关于 PARA，不是关于 Capture 规则，而是关于最后那一段——AI × 知识管理。
"阿木木，你说用 AI 辅助 Capture 可以从 15 分钟缩短到 5 分钟，具体怎么做的？"
"能不能用 GPT 直接帮我做 Distill？我最懒的就是写总结。"
"有没有办法让 AI 直接搜索我的 Obsidian 笔记库？"
说实话，终篇里关于 AI 的部分我只写了几百字，因为当时我还在实验阶段，没把握写成完整的方法论。
但过去两周我做了大量的测试——用 GPT-4、Claude、Cursor、Kimi 在 CODE 的每一步里做了 7 个实验，记录了详细的数据。
结果比我预想的要复杂：
有 4 个场景 AI 真的大幅提升了效率。
有 2 个场景 AI 看似有用但实际"偷走"了最关键的东西。
有 1 个场景 AI 彻底改变了我的工作流。
今天这篇番外，我把这 7 个实验全部摊开——哪些值得做、哪些是陷阱、具体怎么操作——一次讲清楚。
这不是一篇"AI 工具推荐"文章。这是一篇"AI 在知识管理中的真实边界测试报告"。
先说结论：AI 在 CODE 四步中的定位
测试完 7 个场景后，我画了一张"AI 参与度"地图：
text
CODE 四步中 AI 的最佳参与方式
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Capture Organize Distill Express
│ │ │ │
▼ ▼ ▼ ▼
AI 做苦力 人自己做 AI 做初稿 AI 做骨架
人做判断 AI 只建议 人做终审 人做血肉
│ │ │ │
┌──┴──┐ ┌──┴──┐ ┌──┴──┐ ┌──┴──┐
│⭐⭐⭐⭐│ │⭐⭐ │ │⭐⭐⭐ │ │⭐⭐⭐⭐│
│ 强推荐 │ │ 谨慎用│ │ 推荐 │ │ 强推荐 │
└─────┘ └─────┘ └─────┘ └─────┘
AI 参与度（推荐）：
Capture: 70%（AI 做提取，人做过滤判断）
Organize: 20%（AI 只做建议，人做最终决策）
Distill: 50%（AI 生成初稿，人改写为自己的理解）
Express: 60%（AI 搭框架和初稿，人补充经验和温度）
核心原则：AI 做"信息处理"，人做"价值判断"。
两者的边界在哪里？往下看。
实验 1：AI 辅助 Capture —— 10 分钟读完一篇万字长文 ⭐⭐⭐⭐⭐
这是 7 个实验中效果最好的。
痛点
程序员的技术文章动辄五千到一万字。深度好文值得读，但全文精读太花时间。尤其当你一天刷到 3-5 篇"好像跟我有关"的文章时，全部读完要 2-3 小时。
以前我的做法：
要么全读（太慢） 要么只看标题和开头（遗漏关键信息） 要么收藏"以后再看"（永远不会再看）
AI 工作流
现在我的做法是：先让 AI 帮我做"预处理"，我再根据 AI 的输出决定要不要深入读。
text
Step 1：把文章全文复制（或用链接），喂给 AI
Step 2：使用以下 Prompt（我固定使用的模板）：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
请帮我分析这篇文章，按以下结构输出：
## 一句话总结
（用一句话概括文章的核心观点）
## 核心论点（3-5 条）
（每条用一句话概括，不要超过 30 字）
## 关键数据/案例
（如果文章中有具体的数据、对比、案例，提取出来）
## 与我可能相关的行动建议
（基于文章内容，给出 2-3 条可操作的建议）
## 文章质量评估
- 信息密度：高/中/低
- 论据充分度：强/中/弱
- 时效性：强/中/弱
- 原创度：高/中/低
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Step 3：我花 1-2 分钟读 AI 的输出
Step 4：根据输出做判断（12 秒共鸣测试的升级版）：
→ 核心论点跟我的项目/领域强相关？→ 深入读原文关键段落
→ 有我之前不知道的数据/案例？→ 提取那部分进 Obsidian
→ 信息密度低 / 跟我无关？→ 跳过，不收藏
Step 5：如果决定保留，在 Obsidian 里创建笔记时，
把 AI 的摘要作为 Layer 0 的起点，
然后用自己的话改写/补充，形成 Layer 1
真实案例
上周我看到一篇《从 0 到 1 搭建实时数据仓库：某电商公司的实践》，全文约 8000 字。
以前的方式： 精读 25 分钟 → 写笔记 10 分钟 → 总计 35 分钟
现在的方式：
text
Step 1：全文复制喂给 Claude 耗时：30 秒
Step 2：AI 返回结构化摘要 耗时：15 秒（AI处理）
Step 3：我读 AI 输出 耗时：2 分钟
Step 4：判断——有一条关键信息： 耗时：12 秒
"他们用 Flink CDC 替代了传统 ETL，
延迟从 T+1 降到了秒级"
→ 这跟我的数据中台项目直接相关！
Step 5：跳到原文那一段深入读 耗时：5 分钟
Step 6：在 Obsidian 写笔记 耗时：3 分钟
（AI 摘要 + 我自己的批注和思考）
总计：约 11 分钟
从 35 分钟缩短到 11 分钟。效率提升约 70%。
而且关键信息一条都没漏——因为 AI 帮我做了"全文扫描"，我只需要对 AI 标注的关键点做"人工复审"。
我写进 Obsidian 的笔记长这样
Markdown
# Flink CDC 替代传统 ETL 的实践案例
> 来源：《从0到1搭建实时数据仓库》https://xxxxx
> 日期：2024-06-15
> 关联：[[P-数据中台二期]] [[A-数据与增长]]
> AI辅助：Claude 提取摘要，我改写了总结和思考
## 📝 我的总结
某电商公司用 Flink CDC 替代了传统的 DataX 离线同步：
- 延迟从 T+1（隔天）降到秒级
- 不需要全量同步，只同步变更数据（binlog）
- 减少了对源库的查询压力
对我们的启发：
我们一期用的 DataX 就是 T+1 同步，运营总抱怨数据不实时。
二期可以考虑引入 Flink CDC。但要评估：
1. 团队有没有 Flink 运维能力（目前没有）
2. 需要多少资源搭 Flink 集群
3. 是否所有表都需要实时，还是只对核心表做实时
→ 参考 [[架构决策原则：渐进式引入]]：先对 3 张核心表做 CDC，其余保持 T+1
## AI 原始摘要（供查阅）
（折叠，需要时展开看 AI 的原始输出）
注意笔记结构：
📝 我的总结是我自己写的（Layer 2），这是核心AI 原始摘要折叠在下面作为参考（Layer 0）AI 的输出永远不直接作为"我的知识"——它只是原材料
为什么不直接用 AI 的摘要？
因为 AI 不知道"我的项目是什么"、"我的团队有什么能力"、"我之前踩过什么坑"。这些"上下文"只有我自己知道。
AI 帮我省掉了"阅读和提取"的时间，但"判断和思考"必须是我自己做的。
实验 2：AI 辅助 Distill —— 把 Layer 0 升级为 Layer 2 ⭐⭐⭐⭐
痛点
Distill 是我在 CODE 四步中做得最差的一步（第 7 篇承认过）。因为"用自己的话写总结"需要深度思考，而深度思考需要时间和专注力——这两样东西我经常不够。
结果就是：大量笔记停留在 Layer 0（原始状态），只有少数笔记被提炼到 Layer 2。
AI 工作流
我现在的做法：让 AI 先生成一版"总结初稿"，然后我在它的基础上修改。
text
Step 1：把一条 Layer 0 的笔记内容喂给 AI
Step 2：使用以下 Prompt：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
请帮我为这条笔记生成一段"个人总结"。要求：
1. 用第一人称"我"来写
2. 用通俗的口语化表达，不要学术腔
3. 结构：
- 一句话概括核心观点
- 2-3 条要点（每条不超过 2 句话）
- 一条"这对我意味着什么"的个人思考
4. 总长度控制在 150 字以内
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Step 3：我读 AI 的输出，做三件事：
① 删掉"不像我会说的话"（AI 经常写得太正式）
② 补充"只有我知道的上下文"（项目背景、踩坑经验）
③ 加上"我的判断和决策"（AI 不会替我做决策）
Step 4：把修改后的版本写入笔记顶部作为 Layer 2
真实案例
原始笔记（Layer 0）：
Markdown
# K8s 亲和性调度
Kubernetes 的亲和性调度（Affinity）分为：
- Node Affinity：让 Pod 调度到特定标签的节点上
- Pod Affinity：让 Pod 调度到跟某些 Pod 同一节点/区域
- Pod Anti-Affinity：让 Pod 避开某些 Pod
Node Affinity 支持 required（硬亲和）和 preferred（软亲和）。
硬亲和找不到匹配节点就不调度，软亲和会尽量满足但不保证。
使用场景：
- GPU 任务调度到 GPU 节点
- 高 IO 任务调度到 SSD 节点
- 让同一服务的多个 Pod 分散到不同节点（Anti-Affinity，高可用）
AI 生成的初稿：
text
K8s 亲和性调度的核心是"让 Pod 去该去的地方"。
三种类型：Node Affinity 选节点，Pod Affinity 选邻居，
Pod Anti-Affinity 避开邻居。最常用的是 Node Affinity
的软硬两种模式——硬的是"必须满足"，软的是"尽量满足"。
对我来说，最实用的场景是用 Anti-Affinity 做高可用部署。
我修改后的 Layer 2（最终版）：
Markdown
## 📝 我的总结
K8s 亲和性说白了就是"告诉调度器把 Pod 往哪放"。
三种用法我最常用的是：
1. Node Affinity：GPU 任务必须调度到有 GPU 的节点（用硬亲和 required）
2. Pod Anti-Affinity：同一个服务的 3 个 Pod 必须分散在不同节点，
防止一个节点挂了全军覆没
上次订单服务重构时没有配 Anti-Affinity，
结果 3 个 Pod 全落在同一个节点，节点宕机直接 P0 事故。
→ 以后所有核心服务的 Deployment 都必须配 Anti-Affinity。
写进 [[A-后端技术/K8s部署规范]]。
AI 的初稿帮我节省了什么？ 省掉了"从零开始组织语言"的过程。但关键的个人经验（那次 P0 事故）和行动决策（写进部署规范）是 AI 无论如何写不出来的。
⚠️ 重要警告：Distill 中 AI 的陷阱
在测试中我发现了一个危险的现象：
text
当 AI 的总结写得"太好"时，
我会不自觉地直接采用，不做修改。
这样做的问题：
→ 那段总结用的是 AI 的理解方式，不是"我的"理解方式
→ 三个月后我读到它，感觉像在读陌生人的笔记
→ 完全丧失了"用自己的话写总结"带来的深度理解效果
这就是 AI 在 Distill 阶段最大的风险：
它帮你省掉了"思考"的苦力，
但"思考"本身就是 Distill 最重要的价值。
我的应对规则：
text
规则："AI 初稿必须改 30% 以上"
如果我发现自己在 AI 的输出上改动不到 30% → 说明我偷懒了
→ 强制自己至少：
① 补充一条 AI 不知道的个人经验
② 修改至少一个表述为"我平时说话的方式"
③ 加一条"这对我的项目意味着什么"的判断
如果改动超过 70% → 说明 AI 这次帮助不大，下次类似笔记不需要用 AI
实验 3：AI 辅助 Express —— 用 GPT 搭文章骨架 ⭐⭐⭐⭐
痛点
在第 8 篇里我讲过，Express 的核心流程是"搜索 → 调用 → 组装 → 成稿"。其中"组装"阶段需要我把 8-12 条笔记排出逻辑顺序、写衔接段落、确定每个章节的重点——这是最耗脑力的环节。
AI 工作流
text
Step 1：把我的文章主题 + 要引用的笔记标题列表喂给 AI
Step 2：使用以下 Prompt：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
我要写一篇公众号文章，主题是：________
以下是我已有的笔记素材（标题列表）：
1.
2.
3.
...
请帮我：
1. 把这些素材按照逻辑顺序排列，给出推荐的文章大纲
2. 每个章节建议用哪些素材，为什么
3. 指出素材之间的"逻辑缺口"——哪些地方需要补充衔接
4. 建议一个吸引人的开头方式（给 2-3 个选项）
注意：
- 目标读者是程序员/产品经理
- 风格要真诚、具体、口语化
- 不要写正文，只给大纲和建议
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Step 3：我根据 AI 的大纲建议，调整自己的文章结构
Step 4：正式写作时，我自己完成所有正文内容
AI 的输出只用来"参考结构"，不用来"生成内容"
真实案例
写第 9 篇（技术调研案例）时，我把 19 条笔记的标题喂给了 Claude，让它帮我排序。
Claude 给出的建议中有一条让我眼前一亮：
"建议在正式讲 CODE 流程之前，增加一个'盘点已有认知'的环节。因为你的笔记列表中有 7 条是'之前就有的旧笔记'——这说明你不是从零开始的。先展示这个'起点'，能让读者更清楚地看到知识库的复利效应。"
这个建议直接影响了第 9 篇的结构——我加了"盘点已有认知"这个环节作为第二步，这成了那篇文章最有记忆点的部分之一。
但 AI 给的其他建议有一半我没采纳——因为它不了解我的读者、不了解我的写作风格、不了解前面 8 篇文章已经讲了什么。
AI 在 Express 中的最佳角色：结构顾问，不是代笔人。
实验 4：AI 做"知识库体检" —— 发现知识盲区 ⭐⭐⭐⭐⭐
这是让我最惊喜的一个实验。
玩法
text
Step 1：把 Obsidian 里所有 Areas 的笔记标题导出成一个列表
Step 2：使用以下 Prompt：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
我是一名后端程序员，以下是我的个人知识库中
"长期积累"领域的所有笔记标题：
【A-后端技术】
- 分布式系统原则
- MySQL调优清单
- Redis使用规范
- 代码Review要点
- K8s亲和性调度
- CQRS架构模式
- DDD核心概念
- 线上排障手册
- 架构决策原则：渐进式引入
- MySQL死锁排查手册
...
【A-产品思维】
- 需求分析框架
- 用户故事写法
- 竞品分析模板
...
【A-数据与增长】
- RFM模型笔记
- 漏斗分析框架
- AB测试规范
...
请帮我分析：
1. 我的知识结构有哪些明显的"盲区"或"薄弱环节"？
2. 作为一名 3-5 年经验的后端程序员，
哪些重要技能/知识在我的列表中缺失了？
3. 给出 5 条"建议补充"的知识方向，按优先级排序
4. 我的知识结构有什么特点或偏向性？
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AI 给出的分析（节选）
text
你的知识结构分析：
✅ 优势领域：
- 数据库和缓存（MySQL + Redis）积累扎实
- 有架构思维（CQRS、DDD、分布式原则）
- 有跨领域意识（产品思维、数据分析）
⚠️ 明显盲区：
1. 安全相关（0 条）：没有任何关于 Web 安全、认证鉴权、
数据加密的笔记。这对后端工程师来说是重要的能力缺口。
2. 可观测性（0 条）：没有关于日志规范、监控体系、
链路追踪（Tracing）的积累。你有"线上排障手册"，
但缺少"如何建设可观测性体系"的系统知识。
3. 测试（0 条）：没有关于单元测试、集成测试、
测试策略的笔记。
4. 网络基础（0 条）：没有关于 TCP/HTTP/gRPC
等网络协议的笔记。
5. 软技能相关偏少：只有"需求分析"和"竞品分析"，
缺少"技术方案评审技巧""跨部门沟通"
"向上管理"等软技能积累。
建议补充优先级：
1. 可观测性（与你的线上排障能力直接互补）
2. 安全基础（后端必备，面试高频）
3. 测试策略（提升代码质量和重构信心）
4. 向上管理/沟通技巧（职业发展瓶颈突破）
5. 网络基础（补齐底层知识）
看到这个分析时我愣了一下。
AI 说得没错——我确实没有任何关于"安全"和"可观测性"的笔记。这两个领域我不是不懂，但我从来没有系统地积累过。
这就像做代码扫描一样——你自己看代码觉得"还行"，但扫描工具一跑，哗啦啦出来一堆你从没注意过的问题。
AI 在这里扮演的角色：知识库的"代码扫描工具"。
它不能帮你写代码（学知识），但它能告诉你"哪里有漏洞"。
我的后续行动
根据 AI 的建议，我在 Areas 里新增了两个领域：
text
A-可观测性/
├── 日志规范（待填充）
├── 监控告警设计（待填充）
└── 链路追踪入门（待填充）
A-安全基础/
├── Web安全常见漏洞（待填充）
├── 认证鉴权方案（待填充）
└── 数据加密基础（待填充）
先建文件夹，标记"待填充"。以后在工作中遇到相关内容时，有地方可以放了。
这就是 AI × 知识管理最优雅的用法之一：不是帮你"学知识"，而是帮你"看到自己不知道什么"。