AI 能力三件套:报错分析、变更分析、知识库
平台内置了几个 AI 入口,不用额外配置就能用。这篇讲清楚它们各自解决什么问题。
一、构建报错分析
构建失败了,日志几百行,人就卡在这里。
在构建详情页点 AI 分析,把报错信息交给模型,它会给出原因判断和修复方向。
实际用法上的建议:
- 先自己扫一眼第一个报错,AI 分析也以它为主,别把后面的连带错误一起喂进去
- 报错是"命令找不到"这类环境问题时,AI 帮不上太多——直接用「登录调试」进容器看更快
- AI 给的结论要验证。它看的是日志文本,看不到你的仓库全貌
二、变更分析
在 Commit 或 PR 详情页,一键把变更交给 AI,输出"改了什么、可能影响哪里"。
最适合三个场景:
- 接手别人的仓库,快速看懂某次提交
- 评审时先要一份摘要,再去抠细节
- 写 Release Notes
它替代不了逐行 review,但能把"先理解再判断"的前半段压缩掉。
三、知识库:把仓库变成可检索的
这才是真正能沉淀下来的能力。
原理很简单:把文档切片、分词、向量化,写进知识库,之后可以用自然语言检索,也可以接给 LLM 做 RAG。
3.1 一行配置就能建
.cnb.yml
main:
push:
- stages:
- name: build knowledge base
type: knowledge:update
options:
include: "**/**.md"
推上去就跑,跑完文档就进知识库了。
常用参数:
| 参数 | 默认 | 说明 |
|---|---|---|
include | **/**.md | 要索引的文件,glob,支持数组或逗号分隔 |
exclude | 无 | 排除的目录,比如 node_modules/** |
chunkSize | 1500 | 文本分块大小 |
chunkOverlap | 0 | 相邻分块重叠 token 数 |
embeddingModel | hunyuan | 嵌入模型,目前只支持 hunyuan |
issueSyncEnabled | true | 是否同步 Issue 数据 |
issueState | 全部 | 只同步 open 或 closed |
issueLabels / issueExcludeLabels | 全部 | 按标签筛选,交集时 exclude 优先 |
forceRebuild | false | 删掉重建 |
ignoreProcessFailures | false | 忽略单文件处理失败 |
3.2 让 Issue 也进知识库
Issue 里其实藏着最有价值的一手经验——踩坑记录、排障过程。挂到 $ 下让它增量同步:
.cnb.yml
$:
issue.open:
- stages:
- name: update knowledge base
type: knowledge:update
options:
issueSyncEnabled: true
issue.comment:
- stages:
- name: update knowledge base
type: knowledge:update
options:
issueSyncEnabled: true
这样每次有人开 Issue、评论,知识库就增量更新一次。一年下来就是一个团队自己的排障库。
3.3 RAG 怎么用起来
知识库建好后,一条完整链路是:
- 用户提问
- 用问题去知识库检索,拿到相关文档片段
- 拼 Prompt:
用户提问:{用户问题}
知识库:
{从知识库检索到的内容}
请根据以上知识库,回答用户的问题。
- 送给 LLM 生成回答
知识库的内容可以通过 Open API 检索,也可以直接在仓库页面的 AI 对话里启用。
3.4 知识库配方(比参数更重要)
工具是现成的,效果差别全在内容上。三个经验:
- 别把整个仓库都塞进去。
include只圈文档目录,exclude掉node_modules、dist、构建产物。噪声比缺失更伤检索效果 - 文档要有标题层级。切片是按 token 切的,有清晰
##标题的文档,切出来的块才语义完整 - 把 Issue 当宝藏。开源项目的 Issue 质量往往比文档高,因为它来自真实问题的求解过程
四、CodeBuddy 也在 WebIDE 里
云原生开发环境内置了 CodeBuddy,不用额外安装。写代码时想让它帮忙,直接在 IDE 里用。
和第 17、18 篇的 NPC 是同一个东西的不同入口:评论里 @ 它处理 Issue/PR,IDE 里用它写代码。