知识审查

aiops-knowledge-review 检查已有知识库的质量——完整性、证据链、术语一致性、agent 可用性。

触发条件

• 其他技能完成后自动执行（历史入库、新项目简报完成时）
• 你说"审查一下知识库"、"检查文档质量"、"看看文档有什么问题"
• 定期质量检查（取决于治理等级和团队习惯）

审查维度

1. 结构完整性

• 项目、产品、微服务三级文档落点存在
• project.yaml 存在，能表达项目稳定身份、产品注册表和文档路径
• iteration-bindings.yaml 存在，能表达项目迭代、产品版本和微服务主分支
• 产品目录下有 product.yaml，服务目录下有 service.yaml
• README.md 只做导航索引
• guides/ 存在且可服务人类阅读
• open-questions.md 存在

2. 证据质量

• 每项事实陈述都有来源路径或标注为假设
• 引用的源码路径、配置路径没有失效
• 文档和代码之间没有明显矛盾
• 不确定的内容在 open-questions.md 里，不在正文里当确定事实

3. 术语一致性

• 同一概念在所有文档里用同一个词
• Project Iteration、Product Version、Service Main Branch、Iteration Binding 的含义一致
• 没有"认证模块"在 PRD 里叫"登录系统"、在 Architecture 里叫"Auth Service"、在 Specs 里叫"identity-provider"这种情况
• 关键术语在首次出现处有定义

4. 分支绑定完整性

• 每个项目迭代都有 docs_branch 和 docs_path
• 每个项目迭代内的产品都有 version 和 docs_path
• 每个服务都有 code_root 和 required_branch
• 文档不引入微服务版本，也不把本地临时源码分支写入版本模型
• 维护总结能追溯到项目迭代、产品版本和微服务主分支

5. Agent 可用性

• agent 能按稳定路径找到需要的信息
• 文档结构清晰，标题直接反映内容
• 关键事实没有被大段叙事淹没
• 交叉引用可以追溯

6. 人类可读性

• guides/ 里的叙事连贯，能让人理解项目现状
• 概述、接入指南、变更流程都已覆盖
• 导航能指引读者在站点内找到所需信息

审查输出

审查结果分三个等级：

审查结果记录在审查报告中，有具体到文档级别的修复建议。

怎么用

审查应该嵌入日常工作流，形成持续的质量反馈：

• 历史项目入库后：第一次审查，确保入库质量
• 新项目初始化后：确认骨架完整、标注正确
• 日常维护中：维护完成后自动跑一次，确认跨文档一致
• 定期：每周或每两周全量审查一次，找到积累的问题

你可以随时对 agent 说"审查一下知识库"，lifecycle 会路由到 knowledge-review。