【行业动态】深入解析 Chromium 的 AI Coding 开发体系

Chromium 是全球最大的开源 C++ 项目之一，代码量超过 3500 万行。面对如此庞大的代码库，Chromium 团队在源码仓库中构建了一整套 AI Agent 基础设施——不只是"用 AI 写代码"，而是建立了一套完整的提示词管理、技能系统、知识库、评估体系和大规模自动化项目。

AI Coding 相关内容集中在 agents/目录下：

Chromium 同时支持 Gemini CLI、Claude Code、GitHub Copilot 三种 AI 工具，核心的 Prompts 和 Skills 设计为跨工具复用。AI 使用政策（ai_policy.md）的核心原则是：AI 是辅助工具，人类开发者始终是最终责任人。如果某位开发者违反了原则，则可能被剥夺提交代码的权限。

下面逐一介绍各核心机制：AI Policy（AI 使用政策）、Prompts（提示词系统）、Skills（技能系统）、Knowledge Base（知识库）、Eval（评估测试） 和Projects（大规模项目）。

agents/ai_policy.md是整个 AI Coding 体系的底层约束，定义了人与 AI 的责任边界。核心规则如下：

此外，Policy 还给出了推荐做法：在 CL 描述中说明 AI 工具的使用方式（如附上 prompt）；如果是通过设计文档 + prompt 驱动 AI 生成的代码，可以将设计文档一并提交到代码库。

一句话概括：AI 是工具，不是作者——人类开发者对每一行代码负全责。

Prompts 是整个 AI Coding 体系的基石。Chromium 没有使用一个巨大的单体提示词，而是设计了一套四层分层组合的架构，开发者按需组合。

3.1 四层架构

开发者通过创建本地 GEMINI.md文件，用 @引用组合不同层级的 prompt：

🛠 AI 协作与代码提交规范

Chromium 会使用脚本解析引用的 prompt，最终形成一个完整的 system instruction 注入 AI：

3.2 第一层：common.minimal.md — 核心指令

这是所有开发者共享的最底层指令，定义了 AI 在 Chromium 中工作的基本规范：

3.3 第二层：common.md — 8 步标准工作流

这是 Chromium AI Coding 的核心工作流定义，所有代码编辑任务都必须遵循。以下是完整的 8 步流程（摘自源文件）：

其中 Step 1 的设计尤为关键——它强制 AI 在写任何代码之前，必须先完整阅读所有相关文件并向开发者确认理解。使用过 AI 写代码的同学应该深有体会，充分的上下文理解是保证代码质量的关键，也有助于减少幻觉问题。

3.4 第三层：Templates — 平台模板

平台模板为不同平台的开发者提供特定的上下文和构建指令。Chromium 提供了 desktop、android、ios 三套模板，每套都精确定义了该平台的文件命名规范、构建目标、测试运行方式，确保 AI 不会在平台特定的细节上犯错。

以桌面平台（desktop.md）为例，这是与 Windows/Mac/Linux 开发最相关的模板：

模板的关键设计在于：强制 AI 在动手之前先阅读平台架构文档。这确保了 AI 理解 Views 框架的 Widget/View 层级、Browser/Profile 的所有权模型等桌面平台核心概念，而不是凭猜测写代码。

3.5 第四层：Task Prompts — 自定义命令

Chromium 在 .gemini/commands/中预定义了一系列可直接调用的任务提示词。每个命令本质上是一段预写好的 prompt，封装了特定环节的完整操作步骤

3.6 Prompt 的维护机制

Chromium 使用了一套模板 + 注释的维护机制：

源文件是.tmpl.md（如 common.tmpl.md），包含 HTML 注释形式的设计意图说明

通过 process_prompts.py脚本自动去除注释，生成最终的 .md文件

PRESUBMIT 检查确保 .md文件与 .tmpl.md保持同步

这意味着每条 prompt 规则背后都有为什么这样写的记录，方便团队迭代优化。

Skills 是 Chromium AI Coding 体系中的专家模块。与 Prompts（始终加载的通用指令）不同，Skills 是按需激活的——只有当用户的请求与某个 Skill 相关时，AI Agent 才会自动加载对应的 SKILL.md文件。

目前 Chromium 已有 18+ 个 Skill，覆盖开发中的各种专业场景：

5.1 设计理念

Chromium 的知识库不是传统的向量数据库检索，而是一套Agentic RAG——通过 prompt 指令让 AI 自主判断应该去读哪些文档。其核心原则写在 knowledge_base.md的开头：

强制 AI 不依赖自身的通用知识，而是在回答前先去读源码中的权威文档。

5.2 三层知识增强架构

知识增强同样采用多层架构：

5.3 第一层：knowledge_base.md — 静态路由表

这是最核心的机制。knowledge_base.md被引用在 common.md的末尾，成为 AI 上下文的一部分。它本质上是一个任务→文档的 if-then 规则引擎：

核心编程模式路由：

功能开发路由：

调试路由（最精细的规则）：

执行流程示例：

当开发者说"帮我在 Blink 中添加一个 CSS 属性并追踪 UMA 指标"时：

5.4 第二层：chromium-docs Skill — 本地文档检索工具

当第一层的静态路由无法覆盖时（比如用户问了一个不在路由表中的话题），AI 可以激活 chromium-docs skill 进行动态搜索。

这个 Skill 实际上是一个辅助 AI 定位文档的Python 脚本工具（chromium_docs.py）。AI 通过命令行调用它，脚本在本地 JSON 索引中做匹配，返回文档路径列表，然后 AI 自己去读取这些文档。整个流程如下：

索引范围：覆盖 docs/**/*.md、*/README.md、*/docs/*.md等路径下的2000+ 个 markdown 文件，首次构建索引约 30 秒。

本地 JSON 索引的结构：脚本在建索引阶段（--build-index）会扫描源码树中 2000+ 个 .md文件，对每个文件提取元信息，保存为 3 个 JSON 文件：

其中 doc_index.json中每个文档的字段通过 _parse_document方法提取：标题取自 markdown 的 H1/H2 标题，摘要截取前 300 字有意义文本，关键词从内容中提取 Chromium 专有术语（最多 20 个），分类根据文件路径和内容关键词自动判定。

搜索机制：搜索时脚本遍历 doc_index.json中的每条记录，用纯字符串匹配 + 权重打分（非向量语义检索）。标题匹配权重最高（×4.0），其次是路径匹配（×2.5）、关键词匹配（×2.0）、内容匹配（×1.0-1.5），近期修改的文档也会获得小幅加分。

最终，脚本会找到最匹配的文档，返回给 AI。

为什么需要 3 个索引而不是 1 个？

这种三分索引的设计借鉴了搜索引擎的倒排索引 + 正排索引架构，旨在优化不同场景下的查询效率和内存使用：

内存效率考虑：如果只有一个巨大的索引包含所有信息，每次搜索都需要将 2000+ 个文档的完整内容（可能几十MB）加载到内存。而三分方案：

搜索时先通过 keyword_index（很小）快速定位候选文档路径

然后只从 doc_index 中读取候选文档的元信息进行打分

内存使用量减少 90% 以上

这种设计在搜索效率和内存使用之间取得了最佳平衡，特别适合 Chromium 这种文档量大但搜索频率相对较低的场景。

索引的持久化与复用：值得注意的是，并不需要每次搜索都重建索引。脚本采用"一次构建，持久复用"的策略：

脚本在初始化时（__init__ → _load_indexes()）会尝试从磁盘读取已有的 JSON 文件，如果存在就直接使用，不会重新扫描源码树。只有当索引文件不存在时，搜索才会返回提示信息，要求开发者手动运行 --build-index。

不过，脚本目前没有增量更新机制——如果源码树中的文档发生了变化（新增、修改、删除），已有索引不会自动感知，需要手动重新运行 --build-index重建。但考虑到 Chromium 的文档变化频率远低于代码变化频率，偶尔重建一次即可。

5.5 第三层：MCP 扩展 — 外部知识源

对于需要实时外部信息的场景，通过 MCP（Model Context Protocol）扩展获取：

blink-spec：通过 GitHub API 查询 W3C/CSS 规范的 Issue 和讨论

build-information：查询当前构建配置和状态

depot-tools：获取 depot_tools 相关的命令帮助

5.6 与传统 RAG 的对比

Chromium 不仅构建了 AI Coding 的基础设施，还为其建立了一套回归测试体系——agents/prompts/eval/目录。当系统提示词（如 common.md）发生修改时，团队可以用这些评估用例验证 AI Agent 的表现是否退化。

6.1 评估用例概览

eval目录下有 15 个子目录，每个代表一个独立的评估任务，覆盖了日常开发中的典型场景：

6.2 用例结构

每个评估用例由两个核心文件组成：

prompt.md — 模拟用户输入的任务指令。例如 fix_broken_test：

eval.md 或 eval.promptfoo.yaml— 评估标准。eval.md记录预期结果（修改了哪些文件、达成了什么效果），eval.promptfoo.yaml则是基于 promptfoo框架的自动化断言配置，可以精细检查：

6.3 设计理念

eval目录的本质是一套 AI Agent 的"单元测试"：

回归测试：修改提示词后跑一遍所有 eval 用例，确保 AI 行为没有退化

可复现：每个用例绑定特定的 Git-Revision，可在同一代码版本上重复验证

自动化：通过 promptfoo 框架可在 CI 上自动运行，检查文件变更、内容断言、工具调用等

参考模板：这些用例同时也是开发者的任务参考——遇到类似任务时，可以直接参考对应的 prompt.md

6.4 测试框架：agents/testing/

eval/目录存放的是测试用例，而 agents/testing/则是执行这些用例的测试框架—两者的关系类似于 test_*.py 文件与 pytest 框架。

核心组件：

关键设计：

隔离执行：每个测试在独立的 WorkDir 中运行（btrfs 快照或 gclient-new-workdir），测试之间互不干扰

Pass@K 机制：一个用例运行 N 次，只要 K 次通过就算成功，适应 LLM 输出的非确定性

CI 级基础设施：支持 Swarming 分片并行、Docker 沙箱隔离、ResultDB 上报、Skia Perf 性能看板，可在 CI 上自动运行

Telemetry 采集：从 Gemini CLI 的 OpenTelemetry 输出中提取 token 用量和工具调用记录，用于性能追踪和断言验证

agents/projects/目录存放的不是实战案例，而是真正在生产中运行的 AI 驱动的大规模工程项目。与 Skills（解决单个任务）不同，Projects 面向长期的工程治理目标，包含完整的 SKILL.md + 参考文档 + Python 脚本 + 自动化流水线。

下面以一个具体的产品需求——"实现页面的分屏"——来完整推演 Prompts、Skills、Knowledge 如何协同工作。

仅推演，不代表Chromium开发中的真实工作流。

8.1 需求拆解（人类主导）

产品经理提出："在桌面版 Chrome 中，支持同一窗口内左右并排显示两个 Tab"。

人类工程师将其拆解为多个 CL（CL 即 ChangeList，等同于 GitHub 的 Pull Request）

以下 CL 拆解是从实际代码提交记录逆向推演的。实测中，直接将产品需求输入 AI，AI 并不能自主完成这样的拆解。下面的内容记录的是AI如何处理这些CL的。

8.2 CL 1：添加 Feature Flag — Prompts + Skills 协同

开发者告诉 AI：

Prompts 层面：common.md的 8 步工作流启动，AI 先进入 Step 1（深度理解）。

Knowledge 层面：knowledge_base.md中没有直接的 Feature Flag 路由规则，但 eval/feature_flags_add/目录下有预定义的评估用例，AI 可以参考其中的 prompt 模式。

Skills 层面：虽然没有"添加 Feature Flag"的 Skill，但有 feature-flag-removalSkill 可以反向参考。AI 知道最终需要修改的文件包括：

8.3 CL 3：实现分屏控制器 — Knowledge 深度参与

开发者给 AI 技术描述后，三层知识增强机制同时工作：

第一层（knowledge_base.md 静态路由）：

第二层（chromium-docs 本地检索工具）：

如果 AI 需要了解 BrowserView 的布局机制但静态路由没有覆盖，它会调用脚本搜索：

第三层（Prompts 工作流）：

AI 按 8 步工作流执行：

读取 browser_view.h、contents_web_view.h、tab_strip_model.h的完整源码

向开发者陈述理解并确认

编写 split_view_controller.h/.cc

修改 browser_view.h/.cc和 BUILD.gn

构建 → 修复编译错误 → 测试 → 修复测试错误 → 迭代

8.4 CL 5：添加 UMA 指标 — Skills 主导

开发者说："给分屏功能添加 UMA 指标追踪"。

Skills 层面：histogramsSkill 自动激活，指导 AI：

Knowledge 层面：knowledge_base.md检测到 "UMA" 关键词，路由到 docs/metrics/uma/README.md，AI 读取后获得完整的 UMA 规范。

8.5 提交阶段 — Task Prompts 加速

8.6 三大机制的协同关系

Chromium 的 AI Coding 体系建立在一条底线和三大机制的精密协同之上：

AI Policy（使用政策）— 明确人与 AI 的责任边界：人类开发者对每一行代码负全责，AI 是工具而非作者

Prompts（提示词） — 四层分层组合架构，从核心指令到平台模板到任务命令，确保 AI 在任何场景下都有正确的行为规范

Skills（技能）— 18+ 个按需激活的专业模块，将复杂任务（如移除 Feature Flag 的 17 个步骤）编码为可复用的 checklist，确保不遗漏

Knowledge Base（知识库） — 三层 Agentic RAG 架构，从静态路由表到动态文档搜索到外部知识源，确保 AI 基于权威文档而非通用知识工作

此外，完善的 Eval 评估体系（15+ 个评估用例 + 自动化测试框架）确保了整套 AI Coding 基础设施在持续迭代中保持稳定可靠，不会因提示词修改而导致 AI 行为退化。

Chromium 的文档如此详尽，也并非一天两天的事情。查看提交记录可以发现，文档从 2015 年开始积累，跨越 11 年，总计 6445 次提交，逐步沉淀至今。agents/目录于 2025 年 7 月 10 日创建，而 chromium-docs 这个核心 Skill 则是 2026 年 1 月由一位微软工程师提交的。

对于我们团队而言，如何积累出同等深度的文档体系，是落地 AI Coding 的关键挑战。

需要说明的是，本文仅从工程代码层面进行分析，并非 Chromium 真实完整的开发流程。

注：文章来源于作者：QQ浏览器团队，如若涉及侵权，请联系作者自行删除。