项目知识库为什么要绑定版本和需求

同一项目里可能同时有三版PRD、两份接口文档和一张过期原型。只有目录，没有对象关系，员工与AI都容易引用错。知识库绑定版本和需求，是为了说明资料服务什么、当前是否有效、变更会影响哪些用例和发布结论。落地时每个结论都要回到版本、需求、用例、缺陷或知识库证据，AI只负责分析、解释和提醒。

项目里有一个“文档”入口，不等于有项目知识库。文件夹只能说明资料放在哪里，不能说明它服务哪个版本、支持哪条需求、是否已经过期。

当团队只有三五份文件时，人能靠记忆判断；项目跨过几个月后，PRD、原型、接口说明、测试报告和发布材料会出现多个版本。AI搜索速度越快，引用错误资料的风险反而越高。

搜到的“最新文档”，可能恰好不是这个版本的依据

测试人员在知识库搜“文件外发限制”，打开了上周刚修改的《云盘权限说明_v3》。但当前发布版本实际按 v2 方案开发，v3 属于下个版本。如果只按“最后修改时间”判断有效性，测试会把尚未实现的规则当成缺陷，AI 也会用错误版本回答。

知识库解决的是资料存放和查找，项目绑定解决的是“这份资料在哪个版本、哪条需求、哪个阶段是有效依据”。两者不是同一个功能。

绑定关系回答“这份资料为什么存在”

项目级资料包括背景、路线图和公共规范；版本级资料包括目标、范围、发布说明和回退方案；需求级资料包括PRD、原型与接口；测试级资料包括测试数据、执行证据和报告；发布级资料包括检查清单和上线记录。

同一份资料可以关联多个对象，但要有主要归属、负责人、有效状态和更新时间。打开需求时能看到相关资料，打开文件时也能看到它被哪些需求和用例引用。

“有效”比“最新修改”更重要

最后更新时间最新的文件未必是正式版本。有人可能刚给旧文档补了一条备注。知识库需要显式状态：待确认、有效、已过期，并记录谁确认了有效性。

替换资料时，旧版不必删除，但应从默认AI检索和项目入口中降级。历史审计仍能打开，日常工作只使用已确认版本。

绑定让测试和发布检查有依据

AI拆测试用例时，应优先读取当前版本目标、范围内需求、验收标准以及与它们绑定的有效资料。发布检查则验证测试结论、发布说明和回退方案是否存在。

如果资料只是上传到云盘，系统不知道它属于哪个版本，AI也无法判断是否应使用。绑定关系让文件从“附件”变成工作流数据。

文档变化要显式影响下游

接口文档更新后，关联需求、用例和评审结论应收到提示。测试负责人决定哪些用例需要更新，版本负责人判断是否影响发布时间。系统不应自动假设所有影响都已处理。

这也是项目知识库区别于普通企业知识库的地方：它不仅用于搜索和问答，还参与状态流转和发布决策。

嘟哩项目的具体页面

在现有“文档”之外增加“知识库”板块。列表显示资料名称、类型、绑定对象、所属版本、有效状态、负责人、更新时间和是否允许AI引用。支持从云盘选择，不必重复上传。

AI回答项目问题时显示来源；资料过期或用户无权查看时，只提示缺口，不能把内容当成确定依据。权限继续由原云盘和项目空间控制。

绑定一份文档时，不能只选“所属项目”

字段	用途	示例
所属对象	明确资料支持什么	项目、版本、需求、缺陷或发布
资料类型	决定在哪个阶段检查	需求原型、技术方案、接口文档、测试报告、回退方案
有效范围	防止新文档误用于旧版本	从 V8.6 起有效，V8.5.2 仍使用 v2
状态	区分草稿和可执行依据	草稿、评审中、已生效、已作废
责任人	文档冲突或过期时找到确认人	产品负责人或技术方案负责人
变更影响	文档修改后提醒下游	影响 3 条用例、1 条开发任务和发布检查

在嘟哩项目中新增“知识库”板块时，页面不应只展示一排文件。应按需求、设计、技术、测试、发布等类型展示当前有效资料，并能切换查看项目级和版本级知识。AI 回答时优先使用已生效且与当前对象绑定的版本。

用“两份都对的文档”测试

准备两份内容不同但各自对应不同版本的权限说明，让测试和 AI 分别在两个版本中查询。如果系统只能给出“最新一份”，说明它管理的还是文件，不是项目知识。

项目知识库要按版本绑定，而不是放一个公共文件夹

上线前研发引用了旧版接口文档，测试用例引用了新版原型，产品验收看的是群里最新截图。三份资料都在知识库，但没有绑定到同一个版本，所以知识库越多，引用越乱。

环节	要记录什么	通过标准
版本资料	目标、范围、发布说明、回退方案	只显示当前有效资料
需求资料	PRD、原型、评审结论、验收标准	每条需求可追溯
技术资料	接口、数据表、配置、依赖	技术风险能定位
测试资料	用例、缺陷、测试结论、复测记录	发布检查可引用

嘟哩新增知识库板块后，要允许资料绑定项目、版本和需求。AI 回答项目问题时优先使用绑定资料，而不是在全局知识库里搜索看起来相似的文档。

怎么验收

用同名文档做测试：一个旧版，一个新版。AI 必须引用当前版本绑定文档，并提示旧版不参与当前结论。

真正落到产品页面时，要看到这些东西

项目经理进入嘟哩项目生命周期页面时，第一眼应该看到一个真实版本的当前状态，而不是一段功能介绍。入口动作也要直接：从新建版本开始补目标、人员、需求、用例和知识库绑定。用户每做一步，系统都要把输入、确认人、状态和产物留下来，后面 AI 才有可靠上下文。

页面区域	业务字段	系统状态	AI 动作
版本资料	目标、范围、发布说明、回退方案	当前状态、责任人、来源链接、更新时间	AI 检查“只显示当前有效资料”，并给出缺口待办
需求资料	PRD、原型、评审结论、验收标准	当前状态、责任人、来源链接、更新时间	AI 检查“每条需求可追溯”，并给出缺口待办
技术资料	接口、数据表、配置、依赖	当前状态、责任人、来源链接、更新时间	AI 检查“技术风险能定位”，并给出缺口待办
测试资料	用例、缺陷、测试结论、复测记录	当前状态、责任人、来源链接、更新时间	AI 检查“发布检查可引用”，并给出缺口待办

一天的真实使用路径可以这样设计：早上先打开看板看今日待确认事项；上午补齐缺失资料或接口数据；下午让 AI 生成分析、脚本、用例、风险或方案；执行前由负责人确认关键动作；晚上把结果、问题和下一步沉淀到同一个项目。这样用户不会觉得自己在“找 AI 聊天”，而是在推进一件有开始、有负责人、有产物、有复盘的工作。

产品里还要保留两个不太讨好、但很重要的状态：一个是“资料不足，不能判断”，另一个是“超出当前范围，建议拆分或延期”。这两句话会让页面看起来没有那么神奇，却能减少错误决策。企业场景里，靠谱比炫技更值钱。

边界说明

产研工作流的前置条件是项目对象要结构化。目标、验收标准、用例、缺陷和发布检查没有补齐时，AI 只能提示缺口，不能替管理者做上线判断。

读者真正会感受到的变化

以前项目经理靠群里追问版本状态；现在从版本目标、需求、用例、缺陷和发布检查里直接看结论。产品知道本版重点，测试知道验收边界，研发知道阻塞是谁，管理者不用再把任务数量当成上线依据。这段体验变化要在试点中被记录下来：用了几个入口、问了几个人、返工发生在哪一步、最终产物是否能被下一次复用。只有这些细节存在，文章里的方案才不是概念说明，而是能被团队带回去照着检查的工作方法。

常见问题

知识库和云盘会不会重复？

不会。云盘负责文件存储、目录和权限，项目知识库负责对象关系、有效状态和使用语境。

每份文件都必须绑定吗？

临时文件不必。影响需求、测试、交付和发布结论的正式资料应绑定。

AI能自动判断文档是否过期吗？

AI可以根据时间和冲突提示风险，正式有效状态仍需资料负责人确认。