夜雨聆风经过一段时间的集体思考和讨论，团队决定从以下几个方面重新设计知识库的结构：拆分出持续更新的“活文档”与临时性的“快照”、分离业务规则与系统需求、与内部需求管理平台打通。以下是设计的整体思路和核心构想。
Part1：问题本质——从“静态文档”到“活的知识资产”
先说说团队的痛点。三层结构确实能帮助团队快速输出需求，但问题在于，当需求进入到开发及后续环节时，文档的内容就被冻结了，不能修改。随着产品迭代，“过时”的需求越来越多：
有些需求曾经被实现过，但后来随着版本更新，相关代码已经没有了，这些“过时”的需求还留在知识库里，成了干扰
需求文档的数量在不断膨胀，历史版本只增不减，知识库变得越来越臃肿
说到底，团队遇到的是静态文档体系与动态软件系统之间日益增长的鸿沟。当AI辅助开发成为常态，这个问题会越来越突出。
要解决这个问题，需要一次结构性的知识库重构——从“静态文档集”转变为“活的知识资产”。
Part2：三个改进方向
基于以上分析，团队设计了三个核心的改进方向：
方向一：建立“活文档”与“快照”的双轨制
这是解决“文档过时”和“无限膨胀”最直接的手段。核心思想是区分“持续演进的真理”与“历史时刻的记录”：
活文档（Living Documentation）——知识库的核心与真相，只保留当前系统“是什么”和“为什么”的准确描述：
产品愿景、核心业务规则、系统架构原则、不变的用户价值承诺
持续、动态更新，当业务规则或系统核心能力发生变化时，这里的文档必须同步修改
由产品负责人或产品架构师负责维护
版本快照（Version Snapshot）——每个发布版本或迭代的“历史标本”：
特定版本的用户故事地图、需求方案、故事卡、验收标准等
只读，永不修改，当版本发布后，这份文档就被“冻结”归档
由交付团队共同负责，在版本发布时创建
价值在于，为“这个版本我们做了什么”提供不可篡改的记录，是审计、复盘和问题追溯的可靠依据
方向二：分离“业务规则”与“系统需求”
从“记录功能”到“管理知识”，关键在于把“业务规则”和“系统需求”拆分开来：
业务规则（Business Rules）——回答“为什么”和“应该是什么”：
独立于技术实现，是产品的灵魂和核心价值
应被纳入“活文档”体系，由产品经理和业务方共同维护
例如：“订单金额满100元包邮”
系统需求（System Requirements）——回答“做什么”和“怎么做”：
为了实现业务规则而定义的具体功能、流程和技术约束
存在于“用户故事地图 → 需求方案 → 故事卡”三层结构中
既可以是“活文档”（当前正在进行的迭代），也可以是“版本快照”（已发布的版本）
方向三：与“IT研效通”平台深度整合
让知识库从“孤岛”变成研发流程的“连接器”：
双向绑定与自动化提醒：在需求/任务中一键关联知识库的“需求方案”或“故事卡”。当需求状态变更时，系统自动向文档负责人推送提醒，从机制上保证文档同步更新。
实现“文档即代码”：推动需求文档也纳入版本控制系统，每一次修改都有清晰的变更记录和审核流程。
建立自动化门禁：在CI/CD流水线中增加检查点，验证当前迭代的“故事卡”是否与平台中的任务状态相匹配。
Part3：过期文档清理机制的三层构想
针对“过期文档清理”这个核心痛点，团队设计了三个相互咬合的构想，形成一个完整的闭环：
构想一：增加“开发中”状态，冻住内容
进入迭代开发中的需求，状态为“开发中”，内容被冻结，不允许修改
这确保了开发和测试有明确的基线，防止需求在执行过程中被“偷换概念”
如果开发中发现问题（技术实现受阻、业务临时变更），引入“变更提案”机制——需求正文冻结，但允许挂载“变更补充说明”子文档
构想二：关联产物缺失 => 自动清理
每个需求都与其他内容有明确关联：关联代码模块/源文件、关联技术设计、关联测试用例等
在对需求进行扫描清理时，如果发现这些关联内容已经不存在了，就能简洁地证明该需求可以做清理
这相当于给需求文档引入了“引用计数”机制，是程序内存回收机制在知识管理上的绝佳映射
构想三：交付后驱动“活文档”更新
当需求文档已经交付（开发完成），这些需求内容可以作为更新和驱动“活文档”的输入
让临时的“快照”喂养永恒的“活文档”，实现知识的提炼与升华
Part4：知识库新架构蓝图
基于以上三个方向的改进，知识库可以演进为四层结构：
| 核心资产层（活文档） | |||
| 当前交付层（活文档） | |||
| 历史归档层（版本快照） | 只读存档 | ||
| 支撑与连接层 |
Part5：AI工程化视角的增强建议
既然身处AI时代，这套机制可以插上AI的翅膀，变得更加“无感”和智能：
AI辅助关联关系建立
不再依赖人工填写“关联代码文件”，在CI/CD流水线中利用AI分析Git提交记录
当开发人员提交代码时，AI自动解析Commit Message，提取需求ID，并自动分析此次修改涉及的核心类/方法名，建立“需求-代码实体”的动态映射，并随着代码演变自动更新映射关系
AI驱动的“活文档”自动更新器
当需求交付后，AI读取“开发中”状态的需求方案和故事卡，对比上一版本的活文档，执行“差异化摘要”
核心提示语逻辑：现有业务规则库为A，本次交付的需求包含以下验收标准，请用精炼的语言提取新增或变更的业务规则，并建议插入活文档的哪个章节。若仅为UI调整或性能优化，且不改变业务语义，则忽略，不更新活文档
基于向量检索的“冲突预警”
在准备将“业务规则”写入活文档时，利用向量数据库检索历史活文档
如果新写入的规则与过去某条“已归档清理”的规则高度相似但逻辑相反，AI会发出“规则冲突/轮回警告”，提示产品经理确认这是业务回滚还是新旧替代
这次知识库重构，本质上是在做一件很“工程”的事：为知识资产建立“垃圾回收”机制。
当代码有了版本控制、有了垃圾回收，软件系统才能保持健康。同样，当知识库有了“活文档”与“快照”的分离、有了过期清理的自动判定、有了AI辅助的连接与提炼，它才能真正成为组织的核心资产，而不是越堆越大的包袱。
这套机制如果落地，知识库将不再是一个需要耗费心力维护的“古董仓库”，而是一个拥有自我净化能力、会呼吸的智慧体。期待后续的实践效果，到时候再来分享。