功能特性	社区版	企业版
私有化形态	❌	✅
内网通讯	❌	✅
企业统一身份认证	❌	✅
自定义节点接入	❌	✅
AI 自定义模型	❌	✅
TAPD VPC 版集成	❌	✅
TAPD SaaS 版集成	✅	❌
自助运维	❌	✅
安全防护 / 其他功能	✅	✅

💰 价格

社区版 — 免费额度 + 超额按量计费，不限人数和功能
企业版 — License 费用 + 基础设施费用，支持按月（10,000 元/月）或按年（102,400 元/年）

📎 计费详情：社区版 | 企业版

⬆️ 返回目录

3-3. CNB 快速总结一下优势或者特性

⚡ 速度快 — 百 G 大仓，克隆在 20s 左右
🚀 CI 构建加速 — 国内外源默认加速，缓存秒级准备
🖥️ 远程开发 — 告别本地环境配置，统一开发环境
💰 计费灵活 — 免费额度以外按量计费，不限制人数和功能
🏢 多形态 — SaaS 和云内私有化，按需选择
✨ 新范式 — 声明式语法、基础设施代码化（IaC）等

⬆️ 返回目录

3-4. 代码会不会拿去做模型训练

不会的。

⬆️ 返回目录

3-5. CNB 为嘛没有出口IP

为什么没有固定出口 IP？

安全性 — 社区版为公开平台，固定 IP 无法实现安全加固
抗攻击 — 动态 IP 可降低针对性攻击风险，遭攻击时可自动切换
责任边界 — 出口 IP 变更可能导致业务中断，易产生责任纠纷

替代方案

场景	推荐方案	参考
容器版本更新	通过云 API 操作	示例
非容器直连 CVM	使用内网通道	文档
企业级内网互通	部署企业版	了解更多

⬆️ 返回目录

3-6. 如何理解组织和继承的概念

组织 — 映射企业架构或业务线的命名空间，管理成员和资产（代码、制品、任务集等）
继承 — 组织之间的层级关系，上级组织成员自动继承对子组织的权限


根组织（Root）  
├─ 组织A（用户拥有A1权限）  
│   ├─ 子组织A1（继承A1权限）  
│   │   ├─ 子组织A1-1（继承A1权限）  
│   │   └─ 子组织A1-2（继承A1权限）  
│   └─ 子组织A2（继承A1权限）  
├─ 组织B（无权限）  
│   ├─ 子组织B1（无权限，与B2隔离）  
│   └─ 子组织B2（无权限，与B1隔离）  
└─ 组织C（用户拥有C1权限）  
    └─ 子组织C1（继承C1权限）  
        └─ 子组织C1-1（继承C1权限）

📌 向下继承：父组织成员自动拥有子组织权限
📌 横向隔离：同级组织之间互不可见（如：前端组 ↔ 后端组）

⬆️ 返回目录

3-7. 代码仓库仅支持HTTPS？

是的，CNB 仅支持 HTTPS 协议，不支持 SSH。

HTTPS vs SSH

对比项	HTTPS	SSH
公开仓库访问	✅ 支持匿名	❌ 必须配私钥
统一认证	✅ Git / Docker / NPM / OpenAPI	❌ 仅 Git
传输安全	✅ CA 机制，防中间人更强	⚠️ 略低
网络加速	✅ 7 层，易代理加速	❌ TCP 4 层，难加速

如何配置认证？

使用**认证令牌（Token）**替代 SSH 密钥：页面右上角 → 个人设置 → 认证令牌

💡 Token 可统一用于 Git 克隆、Docker / Maven / NPM 等制品推拉、OpenAPI 调用，一个令牌搞定所有认证。

⬆️ 返回目录

3-8. CNB 中如何修改昵称和头像？

辨识度高的昵称和头像能帮助同事快速识别你，提升协同效率。

Step 1 — 点击页面右上角头像 → 个人设置 → 个人资料

Step 2 — 退出账号，重新登录时在微信侧选择或新建一个身份（昵称 + 头像）

微信身份选择

Step 3 — 完成修改后，取消勾选「登录时自动更新昵称与头像」

⚠️ 否则下次登录会被新的微信身份信息覆盖！

取消自动更新

💡 建议使用真实姓名或易识别的昵称，头像选择清晰有辨识度的图片。

⬆️ 返回目录

4-1. 我要怎样迁移？

📦 代码仓库 — 支持主流代码托管厂商 → 迁移工具
📁 制品库 — 支持多平台（CODING / GitHub / GitLab / 阿里 / 华为等），多类型（Docker / Maven 等）批量迁移 → 迁移工具
📋 项目协同事项 — 原 CODING 项目协同事项迁移 → 迁移工具
🧪 测试管理 — 原 CODING 测试管理迁移到 TAPD → 迁移工具

⬆️ 返回目录

4-2. 流水线编写

CNB 采用存储在代码分支中的 .cnb.yml 来管理流水线，使用声明式语法编写流水线逻辑。产品采用事件驱动模式，捕捉 Git 或页面功能的事件，执行 .cnb.yml 中定义的业务逻辑。

3 种入门秘籍：

1. 语法手册 — 阅读流水线语法手册和示例，了解功能语法及详解 → 一键传送

2. 各语言 / 场景完整示例 — 各类语言、部署场景及配套工具 → 一键传送

3. AI 辅助编写 — CNB 提供深度知识喂养的 AI，可根据信息辅助编写流水线：

第一步：产品上方搜索框 → AI

产品任意上方界面搜索框->>AI

第二步：输入代码技术栈信息和需求

输入信息

⬆️ 返回目录

4-3. CNB 和友商对比

以下对比基于各平台官网公开信息整理，旨在帮助用户了解各平台差异，选择适合的工具。

💰 免费额度对比

平台	构建资源	存储空间	人数/功能限制
CNB	1600 核时/月（开发）+ 160 核时/月（构建）+ GPU	100 GiB（仓库）+ 100 GiB（对象）	不限人数、不限功能
阿里云效	3000 核分/月，3 并发	Git 20 GiB + LFS 20 GiB，单库 5 GiB	不限人数（基础版）
GitLab SaaS	400 compute min/月	5 GB（命名空间总量）	私有限 5 人
GitHub	Actions 2000 min/月 + Codespaces 120 核时/月	Packages 500 MB + Codespaces 15 GB	不限
Gitee	单仓 200 min 永久 + 每月 500～1000 min	单仓 500 MB，总量 5 GB	私有仓协作 5 人

🚀 CNB 核心差异化优势

优势领域	具体能力	说明
极速体验	百 GB 大仓秒级克隆	OverlayFS + 分布式存储
	缓存秒级准备，无并发冲突	Copy-on-Write 技术
	云原生开发环境秒级启动	容器预热 + 资源池化
	最高支持 64 核 128G 资源	按需弹性扩展
Everything as Code	流水线配置代码化（`.cnb.yml`）	声明式语法，可编程、易分享
	环境配置与代码同源管理	Git 即唯一真相
	构建/部署/回滚全程版本化	GitOps 工作流
AI 原生能力	🤖 NPC「替你打工」	基于 CodeBuddy SDK 的 Cloud Agent
	自动写代码、回 Issue、提 PR、评审代码	无需部署、无需本地 IDE
	📚 AI 知识库	代码仓库 → 企业/个人知识库，一键构建 RAG 应用
国内优化	国内外依赖源默认加速	腾讯云 CDN + Docker/Maven/NPM 镜像加速
	微信一键登录 + 实名认证	国内合规友好

💡 总结：CNB 早已不是传统 Git 平台，而是以 「代码在哪里，Agent 就在哪里」 为核心的新一代 AI 原生研发平台。通过 NPC 智能 Agent、AI 知识库、Everything as Code 等能力，为追求高效、智能、现代化的研发团队提供革命性的 DevOps 体验。

⬆️ 返回目录

4-4. cnb.cool 网络可达情况

社区版（SaaS 服务，微信扫码登录）网络可达情况一览

网络可达性

请求源	→	目的端	可达性
腾讯云 VPC 内资源（如 TKE）	→	CNB	🟢 内网可达
CNB	→	腾讯云 VPC 内资源（如 TKE）	🔴 禁止
CNB TKE 插件	→	腾讯云 VPC 内 TKE 集群	🟢 内网可达
CNB tcloud-cmd 插件	→	腾讯云 VPC 内 CVM / Lighthouse	🟢 内网可达
中国大陆以外公网客户端	→	CNB	🟢 公网可达
CNB	→	中国大陆以外公网客户端	🟢 公网可达

网络速度

请求源 → 目的端	可达性	网速
中国大陆公网 → CNB 仓库/制品	🟢 公网	16 Mbps
中国大陆以外公网 → CNB 仓库/制品	🟢 公网	16 Mbps
腾讯云 VPC → CNB 仓库/制品	🟢 内网	160 Mbps
CNB TKE 插件 → TKE 集群	🟢 内网	56 Mbps
CNB tcloud-cmd → CVM / Lighthouse	🟢 内网	56 Mbps
CNB 构建节点 → CNB 仓库	🟢 内网	400 Mbps
CNB 构建节点 → 腾讯云 VPC 资源	🔴 禁止	-
CNB 构建节点 → 腾讯云 COS	🟢 公网	56 Mbps
CNB 构建节点 → 公网 CLB/域名	🟢 公网	56 Mbps

⬆️ 返回目录

5-1. NPC替我上班介绍及实践

NPC 是 CNB 平台推出的 AI 角色功能，基于 CodeBuddy SDK 实现的 Cloud Agent 角色服务。

✍️ 写代码 — 根据需求自动编写代码
🔧 修复 CI — 自动修复 CI 报错
💬 回 Issue — 智能回复用户问题
🚀 提 PR — 自动提交代码变更
👀 评审代码 — 自动进行 Code Review
⏳ 更多能力 — 持续更新中

无需部署，无需打开本地 IDE，真正实现 「替我上班」！

🎯 核心理念

CNB NPC 核心理念

🛠️ Harness Engineering：AI 工程新范式

NPC 是 Harness Engineering（驾驭工程）理念的最佳实践——让人类工程师从「亲自编码」转变为「驾驭 AI Agent」，通过定义角色、规则和工作流，让 AI Agent 自主完成研发任务。

AI 工程范式的四次演进

通过配置 settings.yml 定义 AI 角色的能力边界和行为规范，实现「人定规则，Agent 执行」的高效协作模式。

🤖 热门 NPC 示例

更多 NPC 请探索：CNB Explore

NPC	说明	链接
CodeBuddy Code	平台内置 CodeBuddy，全局可用	CodeBuddy
洋牛马（Claude Code）	基于 Claude Code CLI 的 AI Bot，在 Issue/PR 中 @即可	npc/claude-code
妲己	王者荣耀主题 NPC，108 位英雄角色可选	npc/hok
安琪拉（SuperNPC）	111 位 NPC 角色的超级 Bot	XMZZUZHI/SuperNPC
🎨 落魄设计师在线P图	具有图片编辑能力的 NPC	npc/image
貂蝉	王者荣耀角色 NPC，@即可角色扮演式协助开发	npc/hok
...	更多 NPC 持续上新中	探索更多 →

📚 了解更多

⬆️ 返回目录

5-2. CODING 迁移 & 备份指引

本指引帮助 CODING 用户将数据迁移到 CNB 或进行备份，涵盖团队成员、代码仓库、制品仓库、项目协同、测试管理等核心模块。

📊 迁移模块总览

模块	迁移工具	Open API	手动导出
👥 团队成员	-	✅	✅
📦 代码仓库	✅	✅	✅
📁 制品仓库	✅	✅	✅
📋 项目协同	✅	✅	✅
🧪 测试管理	✅	✅	✅
🔬 测试协同	-	-	✅
⚙️ 持续集成	-	✅	✅
📝 文档管理	-	-	✅

💡 优先使用迁移工具进行自动化迁移，效率更高、更安全。

⚠️ 基础设施、应用、洞察模块为 CODING 平台特有功能，暂不支持迁移。

👥 团队成员

在 CODING 团队成员管理页面手动导出，或通过 Open API 查询。

团队成员导出

📦 代码仓库

推荐使用 CNB 代码导入工具，也可手动备份：


# 裸克隆原仓库
git clone --bare https://xxxxx.git

# 进入仓库目录，推送到新地址
cd xxxxx.git
git push --mirror https://新地址.git

📁 制品仓库

推荐使用 CNB 制品迁移工具，也可通过 Open API 获取制品地址后手动迁移（以 Docker 为例）：


# 拉取镜像
docker pull your-team-xxx.pkg.coding.net/project/repo/image:tag

# 重新打标签并推送
docker tag your-team-xxx.pkg.coding.net/project/repo/image:tag new-registry.example.com/project/image:tag
docker push new-registry.example.com/project/image:tag

📋 项目协同

推荐使用 CODING 项目协同迁移工具，也可在页面手动导出或通过 Open API 查询。

项目协同导出

🧪 测试管理

推荐使用 CODING 测试管理迁移工具（迁移到 TAPD），也可通过 Open API 查询或在用例管理页面选中用例手动导出。

测试管理导出

🔬 测试协同

在测试协同页面手动导出数据。

测试协同导出

⚙️ 持续集成

进入构建计划，手动复制 Jenkinsfile 内容另存为文件，或通过 Open API 批量导出。

⚠️ 注意 JenkinsFileFromType 字段：static 表示内容在接口返回中，scm 表示存储在代码仓库中需从仓库拉取。

📝 文档管理

在文档管理页面手动导出。

文档管理导出

🔑 Open API 鉴权

使用上述 Open API 接口前，需获取个人令牌鉴权：CODING 个人设置 → 访问令牌 → 新建令牌，详见 Open API 鉴权指引

⬆️ 返回目录

6-1. 秒级克隆：125G 代码，10 秒内准备完成

背景

团队基于 AOSP（Android 14）源码定制 ROM，源码规模 124.44GB，超过 1400 个仓库。面临的挑战：

⏱️ 代码拉取需接近 20 分钟
💾 每台开发机占用 125GB 空间
🐢 代码准备 20 min + 编译 50 min，出包超 1 小时
⚠️ 并发构建会造成缓存冲突和污染

传统优化方案（shallow clone / sparse clone / partial clone）均存在局限，核心矛盾是：clone 速度太慢 + 高并发下无法复用缓存。

解法：CNB 读秒克隆

将 repo 管理的多仓迁移为单仓 monorepo → push 到 CNB → 用声明式配置描述流水线：


build_config: &aosp_build_config
  runner:
    cpus: 64
  docker:
    build: .ide/Dockerfile
    volumes:
      - out:copy-on-write
  stages:
    - name: build
      env:
        BUILD_HOSTNAME: cnb-build
        shell: |
          source build/envsetup.sh
          lunch aosp_arm-eng
          make -j64
      script: bash -e -c "${shell}"

# 并发 6 流水线测试
main:
  push:
    - *aosp_build_config
    - *aosp_build_config
    - *aosp_build_config
    - *aosp_build_config
    - *aosp_build_config
    - *aosp_build_config

📦 代码仓库：https://cnb.cool/aosp/monorepo

📊 性能对比

对比项	代码准备	编译
未使用 CNB	16m 52s	46m 4s
使用 CNB + 缓存加速	3.8s	1m 30s

CNB 并发 6 条流水线耗时截图

🔧 秒级克隆原理：git-clone-yyds

开源地址：https://cnb.cool/cnb/cool/git-clone-yyds

1）缓存加速 — 代码首次 clone 后持久化缓存到构建母机，后续只需增量更新（125GB → 3 秒）。

2）Copy-on-Write 机制 — 基于 OverlayFS 联合文件系统，多条流水线共享底层缓存、各自写入独立 upper dir，互不冲突：

OverlayFS 运作原理

文件	状态	说明
file1	未修改	从 lowerdir 透明呈现
file2	被修改	读取 upperdir 中的修改版本
file3	被删除	upperdir 中标记为 Whiteout
file4	新增	直接存在于 upperdir

3）完整工作流

git-clone-yyds 工作流程

缓存初始化 — 首次 git init + fetch，已存在则直接 fetch 更新
workspace 准备 — OverlayFS 将 .git 缓存挂载到 lowerdir，建立空 upperdir
构建操作 — 写操作 copy-on-write 写入 upperdir，读操作直接从 lowerdir 读取
构建结束 — 删除副本

文件系统挂载示意图

并发场景：母机上只存在一份代码缓存，不同流水线通过 pipeline id 隔离，底层共享同一份缓存。

并发构建场景缓存架构

⚡ 性能总结：时间 O(1)，空间 O(1) — 无视仓库大小，并发安全

📈 全局数据

从系统全局监控来看，git clone 时间稳定在 10s 以下，大部分项目 3～6s 准备好工作区。

CNB 全局克隆性能监控

📎 原文：125G 代码，10 秒内准备完成

⬆️ 返回目录

6-2. CoW 缓存：46 分钟 → 1 分钟刷新构建效率

背景

通过 git-clone-yyds 已将 125GB 代码克隆从 20 分钟降至 10 秒内，但全量编译 AOSP 仍需约 46 分钟。常规缓存方案受限于单机并行和管理复杂度。

CNB volumes 挂载缓存

CNB 基于 Docker 生态，通过 volumes 缓存编译产物，配合 Copy-on-Write 模式实现高效并发缓存。只需修改 docker.volumes 字段：


build_config: &aosp_build_config
  runner:
    cpus: 64
  docker:
    build: .ide/Dockerfile
    volumes:
      - out:copy-on-write   # 声明为 CoW 模式
  stages:
    - name: build
      env:
        BUILD_HOSTNAME: cnb-build
        shell: |
          source build/envsetup.sh
          lunch aosp_arm-eng
          make -j64
      script: bash -e -c "${shell}"

6 条并行流水线均实现 100% 增量编译，编译用时从 46 分 40 秒 降至 1 分 30 秒！

CNB CoW 并发编译耗时

🔧 缓存原理

CNB 使用 Docker Volume 实现缓存，支持多种策略：

read-write — 读写，并发写冲突需自行处理，适用于串行构建
read-only — 只读，写操作抛出异常
copy-on-write — 读写，变更在构建成功后合并，适用于并发构建
copy-on-write-read-only — 只读，变更在构建结束后丢弃
data — 临时数据卷，流水线结束时自动清理

Docker Volumes 原理示意图

从文件系统挂载角度：CNB 在 /data/cache 下创建缓存文件夹，声明 CoW 类型后在 /data/copy-on-write 下建立 upper/work/merged dir，通过 mount -t overlay 挂载。多条流水线共享 lower dir + 代码目录，各自拥有独立 CoW 文件夹，互不冲突。

CoW 并发缓存架构

🎯 更多玩法——远程开发

CNB 远程开发同样受益于以上技术：

⚡ 秒级启动 — git-clone-yyds 实现代码秒级克隆
🚀 快速增量编译 — volumes 编译缓存，即改即见
👥 并发工作区 — 多人同时远程开发，共用缓存互不干扰

📎 原文：46 分钟 → 1 分钟：CoW 缓存刷新 AOSP 构建效率

⬆️ 返回目录

6-3. 远程开发和 CI 一回事

核心观点

想象这样一个场景：你打开 CI 流水线的命令行，用 vim 修改了几行代码，然后提交——你无法区分这是在开发还是在构建。把 vim 换成 VSCode？恭喜你，发明了远程开发！

维度	远程开发	CI
代码管理	Git clone 到远程环境	Git clone 到构建环境
环境配置	配置环境、安装依赖	相同的环境配置和依赖安装
编译/测试	编码完成后编译测试	自动化编译测试

CNB 的 git-clone-yyds「秒级克隆」在远程开发上同样适用：

125G AOSP 项目打开远程开发速度

本地编译 AOSP 需 46 分钟，CNB 的 Volume 缓存在远程开发中同样适用——多人并发命中缓存，1 分钟内完成增量编译。

CNB 远程开发增量编译 AOSP 耗时：1 分 19 秒

CNB 远程开发特性

支持 Web 和 VSCode 客户端远程连接：

📝 声明式 — 基于 Dockerfile 生态，配置与代码同源管理
⚡ 快速启动 — 超大仓库也能数秒准备好代码和工作区
💾 Volumes 缓存 — 多人同时开发也能命中缓存
🔄 配置漫游 — 用户的 VSCode 配置可漫游
📦 按需使用 — 分支即环境，按需获取开发资源，闲时快速回收

CNB 远程开发入口


# .cnb.yml
$:
  vscode:
    - runner:
        cpus: 64
      docker:
        build: .ide/Dockerfile
      services:
        - vscode
        - docker
      stages:
        - name: ls
          script: ls -al

⚡ 为什么启动这么快？

代码准备同样使用 git-clone-yyds，通过 CoW 缓存代码并挂载到远程开发容器和流水线容器。CoW 确保修改不影响底层缓存，支持并发使用。

CNB 远程开发原理架构图

并发缓存原理示意图

📝 总结

Git、CI、远程开发密不可分：CI 消费代码变更，远程开发 产生代码变更，二者通过 Git 解耦。远程开发和 CI 本质是一回事，在产品形态上应是一个整体。

📎 原文：远程开发和 CI 一回事

⬆️ 返回目录

6-4. AI Native Git，启动

你一定干过这件事。

打开 IDE，新开聊天窗口，Ctrl+A 全选需求文档，Ctrl+C，切到 AI，Ctrl+V。等回复。发现少了上下文。再切回去复制另一个文件。再贴过去。AI 说"请提供更多上下文"。心态崩了。

这不是段子，这是此时此刻全世界开发者都在干的活——人肉 Copy-Paste 工程师。

更绝的来了。某公司工位上，显示器赫然贴着 A3 纸打印的四个大字——"禁止关机"。不是怕丢数据，是因为 IDE 关了 AI 就断线了，昨晚让它写的代码还没生成完呢。行政小姐姐路过以为是什么安全规定，差点全公司发文。

荒诞吗？荒诞。但更荒诞的是——我们都觉得这挺正常。

AI 是来替我上班的。我应该更自由才对。而不是反过来。

人肉 Copy-Paste 工程师的日常

人类当保姆的日子

Git 是啥？说白了就是让你当翻译官。你想加个按钮，它非要你翻译成 add、commit、push 三步走。你想改个 Bug，它要你先 checkout 一个分支，再 rebase，再 cherry-pick，最后还要 force push ——哦不对，别 force push，上次隔壁组 force push，全组提交记录没了，那天下午茶都没人喝。

二十年了，我们习惯了。甚至觉得这就是开发者的基本功——不会 git rebase 你好意思说自己是高级工程师？

但仔细想想：机器该干的事，凭啥让人类干？

AI 来了，但好像只来了一半

然后 AI 来了。Copilot、Cursor、各种 AI 编程助手百花齐放，代码补全、自动生成、智能重构……爽是真爽，累是真的累。

但用着用着你会发现一个诡异的事：AI 的脑子，每次对话都是空的。

你跟它聊了三小时，它帮你写了个完整的模块。关掉聊天窗口，再开一个，它连你项目叫啥都不知道。你刚才喂给它的上下文、架构决策、代码风格偏好——全没了。像金鱼，七秒记忆。

所以你干了什么？你开始手动给它补记忆。每次新对话，先贴一遍项目结构，再贴一遍技术栈，再贴一遍编码规范……你从"人肉翻译官"进化成了"人肉上下文投喂员"。

恭喜你，升职了。

然后呢？AI 越用越累。你发现自己不是在用 AI 写代码，而是在伺候 AI 写代码。本来说好的替你上班呢？怎么变成你给 AI 打工了？

有人在屏幕上贴"禁止关机"。有人半夜爬起来看 AI 有没有生成完。有人每天花在"给 AI 喂上下文"上的时间，比直接写代码还长。

我们用 AI 是为了更自由。结果 AI 越用越累，这不对吧？

全行业都在找记忆

这个痛点，不是你一个人在扛。整个行业都在疯狂找解决方案。

有人搞了超长上下文窗口——100K、200K、甚至 1M token。结果呢？塞是塞进去了，AI 该忘还是忘，而且账单比你工资条还长。

有人搞了 RAG——检索增强生成。把代码库切块、建索引、做向量化，每次提问先检索再生成。听起来很酷对吧？但你仔细想想：这不就是给 AI 装了个外挂硬盘吗？ 检索逻辑靠余弦相似度，跟 Git 里代码的真实语义关系八竿子打不着。检索出来的"相关代码"经常是过时的、废弃的、甚至已经被删了的。

还有人搞了各种记忆框架——短期记忆、长期记忆、工作记忆、情景记忆……分类学倒是整得挺明白，但本质上就是给 AI 的失忆症贴各种创可贴。每个框架都声称解决了记忆问题，但你换一个项目，记忆又得从头来过。

大家都在往前跑，都在搞更大的上下文、更复杂的检索、更花哨的记忆架构。

但没有人回头看看。

全行业都在找记忆

蓦然回首

代码在哪？在 Git 仓库里。

每一次提交记录是什么？是 AI 最需要的"工作记忆"——谁改了什么、为什么改、改了之后有没有问题。

每一个 Issue 是什么？是需求记忆——要做啥、为什么做、谁提的。

每一个 PR 是什么？是决策记忆——怎么做的、谁 Review 的、改了几版、最终为什么这么定。

每一条 CI 日志是什么？是质量记忆——改了之后跑没跑通、哪些测试挂了、构建耗时多少。

Issue 是入口，PR 是出口，CI 是质检，代码库是记忆。

这四样东西，你本来就有。它们一直在那。从你用 Git 的第一天起，它们就在那了。

行业花了多少力气去造新的记忆载体？向量数据库、知识图谱、记忆框架、超长上下文……但最好、最完整、最天然的外部记忆，就在你身后。

就像那个人在图书馆里翻遍全世界找一本书，最后发现那本书就在自己口袋里。

Git 仓库本身就是最完美的 AI 外部记忆。每一次 commit 都是一次记忆写入，每一次 diff 都是一次记忆检索，每一次 blame 都是一次记忆溯源。它精确到行、精确到人、精确到时间戳。没有幻觉，没有语义漂移，没有向量化丢失。真实、完整、可追溯——这不就是记忆该有的样子吗？

你不需要给 AI 装外挂硬盘，因为 Git 本身就是硬盘。你不需要给 AI 做记忆分块，因为 commit 天然就是分好块的记忆。你不需要给 AI 搞 RAG 检索，因为 git log、git diff、git blame 就是最精准的检索。

蓦然回首，那人却在灯火阑珊处。记忆从未走远，它一直就在你的仓库里。

Git 仓库即 AI 记忆

NPC：让 AI 住进仓库

关掉 IDE 代码并不会消失。

想通了这一点，CNB NPC 的逻辑就水到渠成了。

NPC 不是 IDE 里的插件，不是浏览器里的聊天框，不是你需要手动投喂上下文的外挂工具。NPC 住在仓库里。

它不需要你 Ctrl+C、Ctrl+V，因为它就长在代码库上，每一行代码它都能看见。它不需要你解释项目结构，因为 git log 就是它的长期记忆，每个 commit 都是它经历过的事。它不需要你贴编码规范，因为 .cnb/settings.yml 和 CI 配置就是它的行为准则。

NPC 是怎么诞生的？说来话长，但核心就一句话——先把 CI 做了，发现不够；再把 AI 加上，发现是外挂；最后想通了，得让 AI 原生住进仓库。

最早，CNB 只是个云原生构建平台，CI 流水线做得飞起。代码推送，自动构建，自动测试，自动部署。但开发者很快发现：CI 只解决了"跑起来"的问题，从写代码到合并代码之间那些磨人的协作环节——创建分支、提交 PR、等 Review、处理 CI 失败、再改再提——全靠人肉。

然后 AI 来了，但一开始只是"帮忙写代码"。你在 IDE 里按 Tab，AI 给你补全。但关掉 IDE，AI 就失忆了。它不知道你仓库里有啥，不知道你昨天改了啥，不知道你的代码规范是啥。一个没有记忆的 AI，再聪明也只是个高级打字机。 你还得伺候它，喂它，给它补上下文，帮它回忆——这不是替你上班，这是你替它上班。

2025 年，CNB 团队想通了一件事：AI 不应该是 IDE 的外挂，而应该是仓库的原住民。 代码库是记忆，Issue 是入口，PR 是出口，CI 是质检——AI 应该在这个闭环里原生运转，而不是在外面探头探脑。

于是 NPC 来了。你 @它，它就干活。在 Issue 里说"加个暗色模式"，它自己建分支、写代码、提 PR、跑 CI。CI 挂了？它自己看日志，自己改，自己推，直到通过。Review 要改？它自己迭代。你从头到尾只需要说一句话。

这不是 Copilot。Copilot 是副驾驶，但方向盘还在你手里，路还得你自己看。NPC？你坐后排指路就行，它自己开。

更骚的是，NPC 还能自定义。名字、口头禅、行为风格，甚至运行时环境，都能在配置里定义。你定义的 NPC，别人关注你的仓库就能用——就像分享一个开源库一样自然。这不是一个助手，这是一个可编程的 AI 协作者生态。

NPC 完整工作流