AI研发知识检索要解决的是“问得到、答得准、查得回”三个问题：需求变更、设计决策、接口约定、故障复盘这些知识散落在不同工具和文档里，直接让AI回答容易给出过期或没有依据的结论。本文给出一套可执行的落地路径：先划定知识范围与条目字段，再建立入库与更新责任，然后设计带出处的检索回答规则，最后用抽样问题集验证是否可上线。文中会说明各步骤的输入、动作与产出，并自然衔接ONES在研发工作项与文档知识关联上的承载方式。
要点总览（TL;DR）
- 先划定第一批知识范围：优先纳入会被反复引用且已定稿的内容，按需求、设计、接口、测试、故障、评审六类来源梳理，并统一到含标题、责任人、生效时间、版本、原文链接的条目字段。
- 把入库挂在已有研发节点上：需求评审通过、设计定稿、缺陷关闭、故障复盘、版本发布五个时点分别触发入库，由知识责任人、评审人、维护人分工完成写、审、维护。
- 回答规则要求每条关键结论附原文出处与生效版本；无法定位来源时明确说明，多版本冲突按生效时间与适用范围判定，关键结论仍由责任人确认。
- 上线前用抽样问题集验证，分别统计回答正确率与可追溯率；条目无责任人、回答无出处、多版本冲突未处理三项作为阻断项。
- ONES Assistant 可基于指定 Wiki 页面组回答问题并附引用来源，结合项目、工作项、迭代与 Wiki 上下文作答，问答与任务执行基于 ONES 权限体系，输出过程可追踪。
先定范围：哪些研发知识值得进入检索
第一批入库对象宜少而稳。判断标准有两条：这条知识会被反复提问或引用，且内容已经定稿、有明确责任人。两条同时满足的优先纳入；临时讨论、未评审的方案、个人笔记先不入库，等定稿后再补。这样能避免AI把半成品当成结论回答。
按研发阶段梳理知识来源，可以快速列出候选清单：
- 需求与变更：需求说明、变更记录、验收口径。
- 设计决策：架构方案、技术选型理由、被否决方案的取舍原因。
- 接口约定：接口定义、字段含义、兼容性约定、调用方与提供方责任。
- 测试用例与缺陷：关键用例设计思路、典型缺陷的根因与修复方式。
- 故障复盘：故障现象、定位过程、根因、改进项及完成状态。
- 评审结论：评审中形成的决议、遗留问题与后续动作。
每条知识整理成结构化条目，而不是整篇文档直接丢进去。字段表如下，必填字段保证条目可定位、可判断时效，选填字段用于补充上下文。
| 字段 | 填写要求 | 必填/选填 |
|---|---|---|
| 标题 | 用一句话说明这条知识回答什么问题，避免“会议纪要”这类泛称 | 必填 |
| 所属项目或产品 | 对应到具体项目、模块或产品线 | 必填 |
| 阶段 | 需求、设计、开发、测试、发布、运维之一 | 必填 |
| 责任人 | 对该条知识内容负责、可被追问的人 | 必填 |
| 生效时间 | 该结论开始适用的日期 | 必填 |
| 版本 | 对应需求版本、接口版本或系统版本 | 必填 |
| 原文链接 | 指向原始文档、工作项或评审记录 | 必填 |
| 适用范围 | 说明适用于哪些模块、环境或客户场景 | 选填 |
| 关联工作项 | 关联需求、缺陷或任务编号，便于追溯 | 选填 |
| 失效条件 | 写明什么情况下该条目作废或被替代 | 选填 |
完成标志：产出一份知识范围清单，列出第一批入库的知识类型与对应来源系统，并确认字段表在团队内达成一致。这份清单是后续入库动作的依据，范围之外的内容暂不进入检索。
建入库与更新机制：谁在什么时点把知识写进去
知识入库应挂在已有研发节点上，而不是另起一套流程。触发点与现有动作对齐后，责任人只需在节点完成时顺手整理条目，增量维护的成本才可控。
| 触发时点 | 入库动作 | 产出 |
|---|---|---|
| 需求评审通过 | 整理需求要点、验收口径与变更影响 | 需求类知识条目 |
| 设计定稿 | 记录方案结论、选型理由与被否决方案原因 | 设计决策条目 |
| 缺陷关闭 | 提炼根因、修复方式与回归范围 | 缺陷类条目 |
| 故障复盘完成 | 整理现象、定位路径、根因与改进项 | 复盘条目 |
| 版本发布 | 更新受影响条目的版本与生效时间，标记被替代内容 | 更新后的条目与失效标记 |
角色分工按“写、审、维护”三层设置。知识责任人由产出该知识的角色担任，负责按字段整理条目并保证原文链接有效；评审人由同领域资深成员或模块负责人担任，确认结论准确、适用范围写清楚；维护人通常由项目助理或知识管理员担任，负责登记生效时间、处理版本更新与失效标记，并定期检查条目是否缺字段。
更新与失效规则要提前写清楚，避免旧结论继续被引用：
- 版本变更时，维护人更新受影响条目的版本与生效时间，旧版本保留但标注“已被替代”。
- 方案废弃时，责任人在条目中写明废弃原因与替代条目链接，维护人将其移出默认检索范围。
- 责任人离岗时，由模块负责人指定接手人，维护人在一周内完成责任人字段变更。
增量维护的最小动作是：节点完成时只更新受影响的条目，不做全量重写；每月由维护人抽查一批条目，检查原文链接是否失效、生效时间是否缺失。完成标志是触发点清单与角色职责表在团队内确认，且第一个版本发布周期内按此执行过一次。
设计检索与回答规则：让答案带出处、可复核
检索入口要能让提问者先缩小范围再提问。建议支持按项目或产品、研发阶段、知识类型三个维度过滤，提问时带上这些条件，例如“查支付模块近两个版本的接口约定变更”。范围越明确，AI越容易定位到具体条目，回答的出处也越具体。
回答规则的核心是每条结论都附原文出处与生效版本。规则可以写成三条：
- 回答中每个关键结论标注来源条目及其原文链接、版本与生效时间。
- 无法定位到具体来源时，明确说明“未找到可引用条目”，并给出可能的查询方向，不凭推测作答。
- 同一问题存在多个版本结论时，先按生效时间取最新，再核对适用范围是否覆盖提问场景；两者冲突时列出各版本结论及适用条件，交由提问者判断。
回答结果的使用边界需要在使用规范中写明：AI回答作为线索和初稿，用于快速定位资料、起草说明或整理变更影响；涉及对外承诺、发布决策、故障定级等关键结论，仍由对应责任人确认后再使用。这样既保留检索效率，也把责任落在明确的人身上。
在工具承载上，ONES Assistant 可基于指定的 Wiki 页面组回答问题并附上引用来源，也能结合项目、工作项、迭代和 Wiki 页面等上下文作答，适合把知识条目与研发工作项放在同一平台管理的团队。知识问答与任务执行基于ONES权限体系进行，输出过程可追踪，便于在复核时回看依据。具体引用呈现形式与索引更新时效，建议在选型核验时向厂商确认。
角色与交付物：一张表看清谁负责什么
把各角色的输入、动作与输出汇总到一张表，便于在项目启动时直接分工，也便于交接时核对。
| 角色 | 输入 | 主要动作 | 输出 |
|---|---|---|---|
| 知识责任人 | 需求文档、设计稿、缺陷记录、复盘材料 | 按字段整理条目，填写原文链接与适用范围 | 结构化知识条目 |
| 评审人 | 责任人提交的条目 | 核对结论准确性、适用范围与版本对应关系 | 评审通过记录或修改意见 |
| 维护人 | 评审通过的条目、版本发布信息 | 登记生效时间，处理版本更新、失效标记与责任人变更 | 条目状态记录与月度抽查结果 |
| 提问使用者 | 具体研发问题与查询条件 | 按项目、阶段、类型缩小范围提问，核对出处后使用 | 带出处的回答记录与复核结论 |
交接与评审节点的确认方式建议统一：条目提交后在对应工作项或文档上留一条评审记录，写明评审人与结论；版本发布时的更新由维护人在发布检查项中勾选确认；责任人变更通过工作项指派完成，接手人确认后生效。这些记录本身就是后续追溯的依据。
示例：一次需求变更知识从入库到被问答引用
以下为演示情景，用于说明流程如何串联，不代表真实客户案例。
情景设定。某订单模块的对外接口需要新增一个必填字段，原字段含义保持不变，旧版本接口在过渡期内继续可用。变更涉及调用方改造与测试回归。
入库动作。需求评审通过后，知识责任人整理条目：标题为“订单查询接口新增必填字段及过渡期约定”，所属项目填订单模块，阶段为设计，版本填接口 v2.3，生效时间填发布日，原文链接指向接口文档与评审记录，适用范围写明“过渡期内新旧版本并存，旧版本停止支持时间另行通知”。评审人核对字段含义与兼容性约定后确认通过，维护人登记生效时间，并将旧接口条目标注“已被 v2.3 替代”。
提问与回答。测试同学提问：“订单查询接口新增字段后，旧版本调用方需要什么时候完成改造？”检索时限定订单模块、设计阶段、接口约定类型，AI基于该条目回答，并附上条目出处、接口版本与生效时间，同时引用过渡期约定的原文段落。
复核。测试同学将回答中的过渡期时间与接口文档原文比对，确认一致后用于编写回归计划；对过渡期截止时间存在疑问时，直接找条目责任人确认，责任人确认后再更新条目中的适用范围字段。整个过程留下提问记录、出处链接与确认结论，后续同类问题可直接复用。
完成检查：上线前逐项确认的清单
上线前用一张清单逐项核对，每项给出通过标准，避免体系“看起来建好了但跑不起来”。
| 检查项 | 通过标准 |
|---|---|
| 范围与字段覆盖 | 第一批知识来源均有对应条目，必填字段完整率达标，抽查条目原文链接可打开 |
| 入库触发点对齐 | 五个触发点均对应到现有研发节点，最近一个版本周期内按触发点实际入库过 |
| 回答可追溯 | 抽样提问的回答均能定位到原文与生效版本，无法定位时明确说明而非推测 |
| 抽样问题集验证 | 准备覆盖各知识类型的抽样问题，分别统计回答正确率与可追溯率，两项均达到团队设定阈值 |
| 多版本冲突处理 | 构造同一问题的多版本场景，确认回答能按生效时间与适用范围给出判定或并列说明 |
设置三个阻断项，任一项不满足则暂不上线：条目无责任人、回答无出处、多版本冲突未处理。这三项直接决定回答是否可信，补齐后再进入试用。试用期建议按周收集提问记录与复核结论，把高频未命中问题补入知识范围，逐步扩大入库对象。
常见问题
第一批入库的知识条目应该放多少、怎么控制范围？
建议以“能跑通一轮维护”为上限，先覆盖一到两个项目或模块，把六类知识来源中各挑一两条典型内容做成条目。判断标准是这条知识会被反复提问或引用，且内容已经定稿、有明确责任人。范围过大时，字段填写和评审都会变成负担，反而难以持续。等第一个版本发布周期按触发点执行过一次，再按高频未命中问题逐步扩大。
知识条目和原始文档是什么关系，需要把文档内容复制进条目吗？
条目是索引和判断依据，原文仍是事实来源。条目里写清这条知识回答什么问题、责任人是谁、适用哪个版本和范围，并用原文链接指回文档、工作项或评审记录。回答时引用条目并给出原文出处，提问者可以回到原文核对。这样文档更新时只需同步条目中的版本、生效时间与失效标记，不必整篇重写。
责任人离岗或模块调整时，旧条目怎么处理？
由模块负责人指定接手人，维护人在一周内完成责任人字段变更，并通过工作项指派留下交接记录。若该模块的方案同时被废弃，责任人需在条目中写明废弃原因与替代条目链接，维护人将其移出默认检索范围，旧条目保留但标注“已被替代”，避免历史提问仍指向失效结论。
AI回答和责任人确认之间怎么衔接，哪些结论必须复核？
把回答定位为线索和初稿：用于快速找到资料、起草变更说明、整理影响范围时可直接使用；涉及对外承诺、发布决策、故障定级等关键结论，由条目责任人或模块负责人确认后再对外使用。复核时核对回答中的出处链接、版本与生效时间是否与原文一致，确认结论记录在提问记录或对应工作项中，便于后续同类问题复用。
用ONES承载这套机制时，知识问答的权限和追溯怎么理解？
ONES Assistant 可基于指定的 Wiki 页面组回答问题并附上引用来源，也能结合项目、工作项、迭代和 Wiki 页面等上下文作答。知识问答与任务执行基于 ONES 权限体系进行，输出过程可追踪、结果可审计，便于复核时回看依据。引用来源的具体呈现形式与索引更新时效，建议在选型核验时向厂商确认。
