从个人知识库到开源产品的蜕变，揭秘认知资产如何转化为可交付的AI工具。作者将沉淀半年的知识操作系统打包成GitHub项目，直面自用与产品化的三大鸿沟：用户画像缺失、个人印记剥离、产品说明重构。本文深度解析项目开源背后的产品思维跃迁，以及AI时代产品人最珍贵的判断力如何在这套知识引擎中淬炼成型。

终于来到了我个人知识库AI实践的最终章。

第一篇聊认知——为什么个人知识库的本体不是知识集合，而是认知资产。第二篇聊实操——3 个脚本、4 个 Skill、3 层防线是怎么一步步长出来的。今天这篇聊交付。我把这套自己用了大半年的系统，最终打包成了一个开源项目，发布到了 GitHub 上。

从分享方法，到分享实践，再到最后交出一个别人能直接上手用的产品——这个递进过程本身，是我这半年最大的收获，也是我真正想分享出来的心路历程（和终极干货）。这篇文章就是聊聊这个“从自用到开源”的产品化过程里，我遇到哪些新的挑战，获得哪些新的感悟，作为自己这个主题系列的片尾曲。

（但是曲终人不散：文末有 GitHub 链接，感兴趣的朋友可以直接 clone 下来试用看看）

为什么想开源：不全是分享欲

前两篇文章发出去后，收到了一些同行的反馈。有人说照着搭了一套类似可深度讨论的机制跑起来了，有人说“终于看到一个产品人怎么搭知识库的完整过程，而仅仅是方法论”。

这些反馈给了我一个信号：这套东西也许真的不只是对我一个人有用，或许大家真的想用到、会用到。于是我这个周末闭关在家，一通CC模型切换（主要是为了省钱）搞出来一个可交付的版本。

但说实话，驱动我开源的核心动力不单纯是分享欲，也掺杂着一种好奇心。我自己每天在这套知识操作系统里，130 多张知识卡片、7 个主题域，已经形成了稳定的日常工作节奏。但“自己用得好”和“别人想用&能用”，中间到底差多远？这个问题不亲自试一下，永远不知道答案。

另外一个私心：这是我的第一个 GitHub 项目。做了多年 to B 产品，一直是给所谓的业务目标做东西，从来没有以个人身份发布过一个基于自己设想的开源产品。也想借着这个契机试试——从一个使用者变成一个交付者，体验到底会有什么不一样。

个人项目和终端产品之间，到底差什么

决定开源之后，我花了不少时间审视自己的项目，发现“我的工具”和“别人能用的产品”之间，至少有三道坎。

第一道坎：它得服务一个我不认识的人。

个人项目不需要用户画像，我自己就是用户。但要做成产品，必须想清楚它优先帮到谁。我最后的判断是：知识工作者——那些想把外部信息沉淀成带有个人理解和印记的知识资产的人。产品经理、咨询顾问、研究者、内容创作者，都可能在这个范围内。获得开箱即用的产品体验。

第二道坎：得把“我”从项目里拿掉。

这是工作量最大的部分。我的知识库主题是围绕自己信贷领域业务背景，结合自己浸淫多年产品工作沉淀下来的理念和方法论，去理解和学习AI领域的相关知识。基于这个场景，搭建过程中，整个体系难免带有我的个人印记：卡片模板带着我的职业偏好，主题领域分类完全聚焦在AI领域上，Skill 的输出格式也是按我的产品设计习惯来的，等等。这些确实属于我原创的痕迹，但如果原封不动连同我的知识库全盘托出，用户拿到的不是“一个知识库框架”，而是“别人的知识库副本”。

第三道坎：得让人三分钟看懂这是什么。

一个开源项目不只是一堆文件。它需要架构说明、安装指南、使用示例、配置说明。用户打开仓库的那一刻，就应该能回答三个问题：这是什么、和我有什么关系、我第一步该做什么。这在我的个人项目里是不需要的，我是创建者，同时也是使用者，天然知道这个项目的全貌。

三道坎没有一道是技术难题，但每一道都需要从用户视角重新审视。用能力和把能力封装打包进行产品化，是完全不同的两种能力。而后者是我这次实践，需要重新切换视角审视产品的认知转变。

最让我头疼的三个具体问题

三道坎里，第二道“把‘我’拿掉”展开说来，变成了三个具体的产品设计问题。

问题一：框架和内容怎么拆？

我的 7 个主题域、130 张卡片，全是围绕我自己的背景积累的。直接给用户看，他们看到的不是框架，是别人的东西。

我的做法是把项目拆成两层。通用能力层——Skill、脚本、工作流框架、治理规则——这些不管谁用都一样，负责的是“知识怎么进来、怎么处理、怎么沉淀、怎么治理”。个性化配置层通过 CLAUDE.md 和 ke-config.yaml 来实现——用户在这里定义自己的身份、关注领域、希望知识库演进的方向。

通用能力放大效率，个性化配置让知识库带上你自己的印记。两层解耦之后，框架是通用的，内容是用户自己的。

问题二：用户怎么定制而不改源码？

CLAUDE.md 管“AI 应该怎么工作”，但知识库运行中还有更细粒度的配置需求。全塞进 CLAUDE.md 会让它膨胀得不可维护。

所以我加了一个独立的配置文件 ke-config.yaml。主题域定义、卡片类型、跨域关系、API 设置——这些“这个知识库应该怎么表现”的配置，都放在这里。CLAUDE.md 和 ke-config.yaml 各司其职，用户不需要改任何源代码就能完成定制。

问题三：一个差点让我翻车的安全隐患。

说出来有点不好意思——我自己用的时候，批量预处理脚本里直接写了 API Key 的明文。跑在本地，也没多想，感觉没啥问题（前提是加了.gitignore）。

但要发布到 GitHub？公开仓库里的 API Key 几分钟就会被爬虫扫到。改造方案本身不难——改成从 .env 文件读取。但这个小坑让我意识到一件事：自用和对外是两个安全量级。自己用时“能跑就行”，对外时任何一处疏忽都可能变成信任问题。

改完之后我回头把整个项目过了一遍，又清除了几处路径硬编码和个人痕迹。最关键的是，我真的切换了角色身份，以一个新用户的视角，体验一把从clone到安装、从配置到知识加工和产出，跑了一遍完整流程。一是当验收，而也是感受下这个项目对外提供的产品力到底怎样。

这半年最意外的收获

回头看，这半年最让我意外的不是系统本身变成了什么样，而是我自己的变化。

半年前面对空白 Obsidian 发呆的时候，我脑子里只有一个模糊的想法——我应该用AI帮我干点什么（受FOMO恐惧驱动）。没有AI产品背景，尝试切换赛道，不知道自己的产品转型之路到底能走多远。今天这个系统能作为产品对外发布，这件事本身就是我”做中学AI”最好的见证人（当然也包括读者们的认可和支持）。

有一个感受越来越明确：AI 让产出速度飞快，一个脚本从需求到代码可能只要半小时。但真正起决定作用的，始终是那些 AI 暂时还未染指的事——该不该做这个功能、为什么选这个路径而不是那个、哪些地方为用户留白、什么时候该停下来不加新东西。

这些判断力，是做了多年产品之后才慢慢磨出来的。以前觉得它是“软技能”，在 AI 时代可能会被技术能力替代。结果恰好相反——快速产出不再稀缺的时候，“做什么”和“为什么做”反而变得更珍贵了。

这也是为什么我始终认为：搭这套知识库最难的部分不是技术实现（没有技术基础完全不是障碍），而是在每个痛点出现时，做出对的产品设计选择。

想试试的话，照着走一遍

项目里自带了一个 starter-vault——空白的起步库，目录结构、模板、配置、6 个 Skill 全都在里面。clone 下来就是一个能跑的环境。（或者直接使用安装脚本，同时修改ke-config配置文件）

git clone https://github.com/Sean-xhz/knowledge-engine.git

cp -r knowledge-engine/starter-vault ~/my-knowledge-vault

用 Obsidian 打开 my-knowledge-vault，接下来要做的就一件事：往里面放文章，然后看着它被一步步加工成知识。

1. 收集几篇文章进 Inbox

装一个 Obsidian Web Clipper 浏览器插件，把你最近觉得有价值的文章剪藏进来。或者直接把你之前攒在各处的 Markdown 文章拖进 00 auto-process/01 Inbox/ 目录。不用多，5-10 篇足够体验全流程。

注意：考虑到后续参与深度讨论的人脑的负荷，预处理脚本会优先处理priority=P1且status=inbox的文章，所以最好是在Web Clipper的模板设置里新增两个frontmatter属性，如果是自己的原始文章，没有frontmatter的话，脚本也会自动补充这两个字段。

2. 启动预处理，看 AI 帮你结构化

在Obsidian 的QuickAdd插件中跑一遍脚本三连（在QuickAdd的配置里选择类型Marco，比如Process，然后点击Add Choice，在Choice的User Scripts配置中选择batch_ai_process脚本，同样方法适用于配置其他两个脚本。为了使用方便，可以对这三个Choices设置快捷键，方便在Obsidian中快速启动）。跑完之后打开 02 Processed/，你会看到原来的文章被结构化成了带摘要、关键知识点、启发的笔记。

3. 挑一篇启动 deep-discuss或直接启动topic-deep-discuss

从 Processed 里选一篇你最有话说的笔记，启动 /deep-discuss。这个 Skill 会陪你做一轮多轮深度讨论——不是简单的总结，而是真正围绕内容展开对话。讨论结束会产出知识卡片和一份讨论沉淀（DI 文档）。

或者你也可以直接让 /topic-deep-discuss 启动主题推荐，它会扫描你的笔记池，帮你挑出一个最适合展开讨论的主题方向。

4. 看看产出了什么

打开 01 knowledge-cards/ 看看生成的卡片——这些不是从文章里摘抄的笔记，而是经过讨论打磨后提炼出来的、带有你自己理解的知识单元。再看看 05 Discussion Insights/ 里的 DI 文档，讨论过程中那些思维碰撞和灵光一闪都被沉淀了下来。

从文章放进去到卡片产出来，这就是一个完整的知识生产循环。跑过一遍，你就知道这套系统能帮你做什么了。

写在最后

三篇文章到这里就结束了。从认知到实操，再到交付，这也是我自己这半年的真实路径。

这个项目对我来说是一个里程碑，也是一扇新的大门。它到底能帮到多少人、会往什么方向演化，我现在也不完全确定。但有一件事是确定的：在 AI 时代，产品人最有价值的资产不是会用多少工具，而是在每个路口做出对的产品判断，不盲目跟风，而是坚守并强化自己的认知，做更有人味的事情。

GitHub 地址：https://github.com/Sean-xhz/knowledge-engine

如果你用了这套框架，不管是跑通了还是踩了坑，都欢迎在评论区或 GitHub Issue 里告诉我。你的反馈是这个产品继续进化的最大动力。