Appearance
如何打造项目特有的知识库
打造项目特有的知识库，关键不在于积累多少文档，而在于能否围绕真实工作场景，把知识组织成一套可定位、可判断、可实施的结构。它服务的不是“记录发生过什么”，而是帮助后续分析者在面对问题时，快速回答几个核心问题：这是什么场景、属于哪一类问题、应该去哪里查、修改时需要遵守什么边界。
一、先聚焦场景，而不是先堆积信息
下面我以一个日常的bug和小型需求的快速处理定位的场景来分析.
项目知识库建设的起点，不应是“我们有哪些资料可以写”，而应是“后续分析工作中最常出现哪些场景”。真正有价值的知识积累，首先要面向高频分析场景：当系统表现异常、行为不一致、链路不清晰、修改风险难以判断时，分析者需要借助知识库快速完成理解、定位和决策。
因此，知识库的建设重点不是扩大内容覆盖面，而是围绕场景建立稳定的认知路径。只有当知识能够直接支持场景分析时，它才不是静态存档，而是可复用的工作基础设施。
二、从场景中提炼关键因素，而不是复述一次次过程
知识库不应该沉淀零散的讨论过程，也不应该停留在对单次问题的回放。真正值得保留下来的，是不同场景背后反复出现的关键因素。这些因素通常包括：
- 业务语义如何映射到系统概念
- 问题通常以什么模式出现
- 相关行为由哪些关键入口和主链路共同决定
- 实施时有哪些稳定约束、风险边界和验证要求
这些内容比“某次具体怎么处理”更重要，因为它们决定了知识能否跨场景复用。如果知识库只记录一次次处理过程，它最终只会变成难以检索的流水账；而如果能够从场景中抽象出稳定模式，它就能逐步形成项目特有的分析框架。
换句话说，知识库沉淀的重点不应是事件，而应是模式；不应是过程复述，而应是结构化认知。
三、知识库的核心，是建立清晰的分层结构
当场景和关键因素被抽象出来之后，下一步就是把它们放入清晰、稳定的分层中。分层的目的，不是为了形式上的整齐，而是为了让不同类型的知识各归其位，避免业务语义、问题模式、代码结构和实施约束彼此混杂。
分享下我自己的分层思路：
1. domain：沉淀业务语义与概念映射
这一层负责把用户语言、产品语义和系统内部概念连接起来。它不展开具体实现细节，而是回答：某类场景在系统中对应什么概念、应该从什么方向理解。
它的价值在于建立统一术语和认知入口，让后续分析者能够从自然语言描述快速进入正确的分析路径，而不是在不同表述之间反复猜测。
而且聚焦的角色是开发者，那么这一层其实比较薄，基于关注点分离的思想，domain层其实本身很复杂，但是到了实现和设计层面，只需要简短的描述和映射就够了.
2. issues：沉淀问题模式与分析路径
这一层负责总结问题的典型表现形式、常见成因和分析思路。它关注的不是单个问题本身，而是：某类问题通常如何出现、如何判断、如何缩小范围。
issues 的核心价值，是把零散经验提升为可复用的问题模式。当分析者遇到新的现象时，可以先判断它更接近哪种模式，再沿着已有的分析路径继续深入，而不必每次都从零开始。
3. structure：沉淀结构入口与主链路
这一层负责描述系统中真正影响场景行为的关键入口、主调用链路和职责分工。它回答的是：相关逻辑由哪些结构共同组成、分析时应从哪里切入、哪些路径属于主链路。
它帮助分析者快速建立“系统是如何运转的”这一结构视图，从而减少在源码中盲目搜索和局部理解带来的偏差。
4. implementation：沉淀实施约束与修改原则
这一层不重复业务规则，也不替代代码设计文档，而是明确实施过程中必须遵守的约束条件、风险边界和验证要求。它主要回答：修改应该遵循什么原则、哪些方式应当避免、变更后需要验证什么。
这一层的价值，在于把实施层面的经验显式的积累起来。
四、好的知识库，不是增加文档，而是优先补强已有体系
项目知识库建设还有一个很重要的原则：优先把新增知识纳入既有结构，而不是不断生成边界不清的新文档。如果每次讨论都生成独立记录，知识会越来越多，但导航能力会越来越弱；最终结果往往是“内容存在”，却“无法使用”。
真正有效的做法，是把新认知有意识地归入现有分层中：
- 语义层面的新认识，补充到 domain
- 模式层面的新判断，归纳到 issues
- 结构层面的新入口、新链路，沉淀到 structure
- 实施层面的新约束、新验证要求，补充到 implementation
这样做的意义在于，知识库不是随着时间不断膨胀，而是随着迭代不断增强其结构稳定性和检索效率。它的价值不只是保存信息，更是持续强化“如何找到正确知识”的能力。