知识库

AIOps 知识治理解决的核心问题是：让 AI coding agent 在开发过程中有可靠的、持续更新的项目知识可以查询。

这是一套从初始化到日常维护的完整工作机制。下面介绍它的设计思路、三个使用场景，以及背后的治理模型。

先理解几个关键设计

开始之前，了解几个贯穿整个方案的核心概念会很有帮助。

治理以项目为单位

传统文档的问题在于管理粒度太细——每篇文章是独立的，互不关联。AIOps 以项目为治理单位，并在项目下细分产品和微服务。项目级文档描述迭代和共同约束，产品级文档描述产品版本和能力边界，微服务级文档描述单个代码服务的接口、模型、流程和验证入口。

这个三级结构的维护锚点是：

项目迭代 -> 产品版本 -> 微服务主分支

这组绑定写在 .aiops/projects/<project>/iteration-bindings.yaml。Agent 维护文档前必须先读取它，确认本次文档属于哪个项目迭代。

两份文档，两类读者

Agent 和人读文档的方式完全不同。Agent 需要的是结构稳定、路径固定、事实直接；人需要的是连续叙事和背景解释。所以每个项目有两层文档：

  • Canonical 层（权威知识层）：prd/、architecture/、specs/、adr/、workflows/。这是事实来源，agent 从这里召回信息。
  • Reading 层（阅读层）：guides/。从 canonical 层关联生成，给人看。

两层不互相替代。canonical 层不需要"好读"，但必须准确、可召回。reading 层不需要穷尽所有细节，但必须让人理解项目现状。

Hook 做记录，Agent 做判断

代码变更时，平台 Hook（Claude Code / Codex）自动在 .aiops/diff-records/pending.md 里追加记录。Hook 不做决策——它只负责记录发生了什么。判断影响面、决定更新哪些文档、实际修改内容，这些由 agent 在执行维护技能时完成。这样的分工让 Hook 保持简单可靠，判断逻辑集中在 agent 端。

三个场景

AIOps 知识治理覆盖项目知识从创建到维护的完整生命周期，按输入来源分成三个场景：

历史项目入库

适用于已经有大量代码但文档缺失或陈旧的项目。从源码、配置、测试、构建脚本出发，逆向提炼项目边界、模块职责、业务链路和关键决策。重点是区分"能证明的事实"和"看起来很合理的推测"。

日常文档维护

适用于在持续开发中的项目。Hook 记录每次代码变更，agent 定期根据 pending 记录做跨文档一致性更新。治理等级决定了自动化程度——从"只记录不提交"到"自动维护并提交"。

新项目初始化

适用于刚启动或早期的项目。在代码还没变复杂之前就建立知识骨架：项目边界、产品和微服务边界、迭代绑定、平台 Hook 配置。初始化是幂等的，可以反复执行来补全结构。

进一步阅读

最近更新:
Contributors: Makia9879, Makia98