按照之前文章《氛围编程实战系列：先规划清楚学习路径》这个规划路径，我们今天来开发第二个功能：合并知识功能。
总结这篇文章的初期阶段，其实让笔者非常的困惑。因为经历了太多思想碰撞。最终认为如果要持续学习一件新事物，还必须要从现实出发，不要为了学习而学习，而要为了解决一个实际问题而学习，哪怕这个问题开始很小，也没关系，不断迭代打磨终会有些价值。
01 | 不沉迷于Demo，想解决一个真问题
笔者是从2014年开始养成了写技术blog的习惯，当时给自己设了一个朴素的原则：把要做的事情想清楚，把想清的事情做出来，把做出的事情写下来。如今十几年过去，很庆幸一直没丢弃这个习惯。
但最近笔者其实也一直在思考一个问题，在当前的生成式AI时代背景下，知识、技术其实非常容易获得，连写一个新的应用程序都开始了Vibe Coding，人类坚持写技术blog的意义还有多大？与瞬间就能生成各类文章的AI相比，人工编写的优势又在哪里？
以笔者目前的认知，思考后的想法是这样的：AI发展到最后，基础模型能力会非常强悍，但它也是公共资源，模型能力可以被我们每个人调用，那么，当大家都使用同一个高能力模型的情况下，每个人的差异就会体现在使用模型的能力，而这个能力，在前期可能还和提示词工程、Agent、workflow编排等工程技术相关，但随着模型能力不断提升，需要人类做工程干预的就会越来越少，而最终的差异，一定还是比拼的真正属于自己的私有数据，这可能会是新时代真正属于每个人的私有不动产。
举个最简单的例子，你想要AI帮你写份年度工作总结，但你自己就没有记录这一年的真实工作记录给到他，那AI再强，写的再天花乱坠，其结果对你、对公司而言，都注定是没有任何价值的。
所以，现在最重要的事情，就是构建起属于自己的私有知识库。知识库可以是多个维度的，比如可以有你的工作记录，也可以有你的日常生活待办事项，还可以把一些验证过的技术知识沉淀下来。
02 | 从最熟悉的技术问题沉淀开始
现在几乎所有人每天都会和AI聊上几句，对于技术从业者，和AI聊很多技术问题，会发现因为LLM幻觉或初始对话时信息提供不够精准等问题，导致最初交付结果跑偏，但是经常可能在反复交谈过程中，在自己的真实环境验证后，不断迭代追问，针对最初的问题就能得到一个经过自己实际验证，可以真正解决自己问题的可信答案。
亦或者你已经有了一个类似龙虾、小马的Agent，可以让Agent去交互，但最终解决问题后，想把解决问题的方案记录沉淀下来。
笔者就想把这个准确的答案，以及我最初的这个问题提炼出来，然后存到属于自己的私有数据库里，作为个人的可信知识。
03 | 可信知识管理模块的设计和开发
可信知识管理：录入、查询、编辑、状态流转、批量合并，以及与待办事项互转。
开始 Vibe Coding ...
① 支持共享录入的待办事项流程
录入的界面最早尝试 Vibe Coding时已经有了，这里笔者让 Codex 帮我做了下微调，让其同时支持知识录入和待办事项录入，比如下面当选择待办事项时，会直接写入待办事项，从而避免那种纯粹的待办事项内容，污染到可信知识内容：
② 支持批量选择与合并能力
对录入知识的合并，场景是当发现录入的有些问题，如果篇幅不长，本质是都同属于一类大问题，可以对其合并，更利于后续对可信知识的利用（比如提升RAG场景下的召回率）：
可以选择想合并的知识，点击"合并所选"就能弹出合并确认界面，支持二次编辑，最终可以"确认合并"也可以后悔"取消"。
③ 支持可信知识与待办事项之间的事务型互转能力
可信知识与待办事项之间，有互相转换的需求。
常见使用场景：
- 可信知识之前录入了一些属于待办事项的，不适合作为知识。
- 待办事项有些是技术问题，做完之后，适合转换为知识，供以后知识库使用。
所以笔者让Codex设计在两个工作区提供人工确认入口，类似这样：
点击"转为待办"，会弹出确认窗口：
同样，反之也支持将某项待办转为可信知识：
同样，点击"转为知识"，也会弹出确认窗口，避免误操作：
至此，可信知识管理：录入、查询、编辑、状态流转、批量合并，以及与待办事项互转已完成。
为后续的 AI 问数和 RAG 场景打好了数据基础。
关注我，大家一起成长~