企业官网建设流程全解析

写在前面

大多数 AI 编码助手的演示都从一个隐含前提出发：代码就在眼前，Agent 只需要读它、改它。

但在真实的企业研发环境里，这个前提经常不成立。

一个汽车软件公司的研发体系，可能同时维护着这样的代码结构：Android 应用层的每个功能模块一个独立 Git 仓库（设置、空调、导航……数十个）；Android 系统框架层按 AOSP 方式拆成数百个子仓库，靠repo工具和 Manifest 管理；QNX 实时系统有自己的 Manifest；MCU 固件又是完全独立的仓库。

当 AI Agent 收到一条"修复蓝牙连接断开的 Bug"的指令时，它面对的第一个问题不是"怎么改代码"，而是"代码在哪"。这个问题的难度，被严重低估了。

问题的三个递进层次

层次一：仓库发现（Repo Discovery）

最直观的困难：面对几十上百个仓库，Agent 怎么知道该去哪个？

有团队的做法是给每个仓库写一段自然语言描述，告诉 Agent 这个仓库是做什么的。这是合理的起点，但有几个系统性局限：

• 自然语言描述难以被精确匹配，尤其是任务描述和仓库描述用了不同的术语时
• 描述随代码演进容易过时，维护成本持续存在
• 没有结构化元数据，Agent 无法按技术栈、业务域做过滤
• 对 AOSP-style 的大型 Manifest 仓库，"这个 Manifest 管了什么"和"这个功能在哪个子仓库"之间，仍有鸿沟

层次二：跨仓库依赖识别（Cross-Repo Dependency）

真实业务需求往往横跨多个技术栈的多个仓库。一个"空调设置温度"的功能可能是这样的链路：

Android 设置 App（应用层仓库） ↕ IPC / AIDL Android 系统服务（框架层子仓库） ↕ HAL 接口 BSP HAL 实现（BSP 层子仓库） ↕ 底层通信协议 MCU 固件（MCU 仓库）

Agent 如果只找到了应用层仓库，修改了 UI 逻辑，却没有意识到下层接口也需要同步变更，就会产生"本地编译通过、集成测试失败"的不完整修改。

这个问题靠单仓库描述无法解决——需要显式建模仓库间的依赖关系。

层次三：仓库获取与上下文构建（Repo Fetch & Context）

找到仓库之后，Agent 还需要"得到代码"。

对应用层的单仓库，git clone就够了。但对 AOSP-style 的代码库，流程是：

1. 获取 Manifest 仓库
2. 确定这个任务需要哪些子仓库（全量 sync 成本极高，时间、存储、网络都不允许）
3. 执行repo sync -c加上精选的子仓库列表
4. 理解跨子仓库的代码依赖

这对 Agent 的工具能力要求，远超一个git clone。

解法方向一：结构化 Repo Registry

把当前的自由文本描述升级为结构化的Repo Registry，每个仓库条目是一个 YAML 对象：

repo_id:android-app-settingsdisplay_name:设置应用