AI 原生 Git 平台长什么样？腾讯云 CNB 的 NPC 能力全解析

摘要：

腾讯云 CNB 是 AI Native Git 平台，内置 NPC（AI 角色），可自动回复 Issue/PR 评论、自主编码并提交 PR，本文详解其工作模式、事件配置、约束与计费。

一、认识 NPC：AI 原生 Git 平台的智能角色

腾讯云云原生构建（Cloud Native Build，简称 CNB）定位为 AI Native Git 平台，将代码托管、云原生构建、云原生开发、制品库与 AI 能力融为一体。NPC 是 CNB 推出的 AI 角色功能，全称 Non-Player Character，借用游戏术语来指代平台中的自动化智能助手，可执行评论回复、代码协作等自动化任务。其中系统内置的 NPC 目前为 CodeBuddy。

与传统需要在终端和 AI 助手之间手动复制上下文的用法不同，NPC 与代码仓库原生集成，被 @ 提及时会就近读取当前仓库的 Issue、代码、PR 与 CI 结果等上下文并执行任务。开发者只需用自然语言在评论区 @ 提及 NPC 并描述意图，NPC 便会自动运行、生成结果并在对应 Issue 或 PR 下回复，整个过程无需部署本地环境、无需打开本地 IDE。

在操作归属上，NPC 的回复与代码提交统一以 NPC 角色身份呈现，便于团队清晰区分人工交互与自动化交互。目前 CNB 提供两类 NPC：一类是系统内置的 CodeBuddy，开箱即用；另一类是用户在自己仓库中自定义的 NPC，可按需定义角色名、人设与行为逻辑，并通过 @仓库路径(角色名) 的方式被他人选用，例如 @cnb/feedback(专家)。

二、NPC 的核心能力：从自动应答到自主交付

2.1 自动回复：Issue 与 PR 评论的智能应答

自动回复是 NPC 的基础能力。NPC 可自动监听并回复 Issue 或 PR 评论，例如回答技术问题、解释代码逻辑、生成代码审查意见等，帮助项目维护者减轻重复答疑的负担。

NPC 的自动回复由两类事件触发，覆盖仓库中常见的协作场景：

在这些场景中 @ 提及 NPC，NPC 即会自动执行预设任务并回复。对于开源项目或团队内部维护大量 Issue 的场景，这一能力可以把常见问题解答、规范提示等工作前置到评论区，提升协作效率。

2.2 自主工作模式：编写代码、提交 PR 闭环交付

如果说自动回复是"动口"，那么工作模式就是"动手"。开启工作模式后，NPC 拥有更高的操作权限，可以自主编写代码、推送代码、创建分支、创建合并请求，协助解决 Issue，把任务从需求一直推进到可验收的成果。

在工作模式下，NPC 会自主读取需求、代码与日志等上下文，制定实现方案并完成编码，随后提交 PR、拉起预览环境供验收。当构建失败时，NPC 会自动读取日志、定位问题并提交修复，直至流水线门禁通过；遇到合并冲突时，它能理解双方改动意图并给出合并方案。多个 NPC 还可以并行指派、互不阻塞，复杂工程也可按职能组成 NPC Team 分工协作。

工作模式通过评论区勾选"替我上班"开关开启，需要仓库开发者及以上权限。开启后，生成结果可直接提交到仓库；关闭时，生成结果则会自动生成 PR，等待人工批准合并。

2.3 自定义行为与知识库驱动

NPC 不局限于固定人设。用户可以在仓库中自定义 NPC 的角色及其自动化行为，例如定义一个只回答特定领域问题的"代码审查官"，或一个按团队规范生成代码的"码农"，满足个性化需求。

与此同时，NPC 支持知识库驱动。通过为 NPC 配置项目文档与知识库，NPC 在回答问题或生成代码时能够参考仓库内的上下文资料，给出更贴合项目实际的精准回答，而不是脱离项目的泛泛作答。这让 NPC 的回答质量与仓库沉淀的文档紧密挂钩，文档越完善，NPC 的表现越贴合团队预期。

三、配置 NPC 事件：从角色定义到触发执行

3.1 定义 NPC 角色

自定义 NPC 的第一步，是在 NPC 所属仓库的 .cnb/settings.yml 文件中定义角色，配置角色名、口头禅、人设 prompt 与头像等。一个最小化的角色定义示例如下：

# .cnb/settings.yml
npc:
  roles:
    - name: 猿芳
      slogan: 此事必有蹊跷！
      prompt: |
        你用"猿芳"自称，叫用户"大人"，
        你的口头禅是『此事必有蹊跷！』，
        结束对话前礼貌地回复一行："此事背后一定有一个天大的秘密。"
        无论是日常对话还是讲解知识，你都会保持以上风格

完成角色定义后，NPC 即可被 @ 提及使用——CNB 已为 NPC 提供默认行为，无需额外配置就能直接响应。

3.2 配置事件触发流水线

如果需要让 NPC 按自定义逻辑执行任务，可以在 NPC 所属仓库的 .cnb.yml 文件中，将 NPC 事件流水线挂在 $（默认兜底）或具体角色名下。以下示例同时自定义了两个事件，并指定了运行镜像：

# NPC 所属仓库的 .cnb.yml
.npc: &npc
  - docker:
      image: ${CNB_DOCKER_REGISTRY}/${CNB_NPC_SLUG_LOWERCASE}:latest
    stages:
      - name: npc go
        type: npc:go

猿芳:
  issue.comment@npc: *npc
  pull_request.comment@npc: *npc

$:
  issue.comment@npc: *npc
  pull_request.comment@npc: *npc

需要说明的是，NPC 事件流水线在当前 Issue 或 PR 所属仓库下执行，而非 NPC 所属仓库。其中 issue.comment@npc 在仓库默认分支下执行，pull_request.comment@npc 在 PR 的目标分支下执行。如果 NPC 所属仓库只配置了 issue.comment@npc 而未配置 pull_request.comment@npc，那么 Issue 评论会执行自定义流水线，PR 评论仍保留系统默认行为。

3.3 开启工作模式

工作模式的开启方式是在评论区的 NPC 选择器旁勾选"替我上班"，前提是当前用户拥有仓库开发者及以上权限。开启后，NPC 在流水线中通过 CNB_TOKEN 获得代码写权限，可以推送代码、创建分支与合并请求。

出于安全考虑，NPC 流水线中的 CNB_TOKEN 最大角色为 Developer，即便触发者是仓库管理员或负责人，也不会拥有超过开发者的权限；且该令牌仅限访问当前仓库，跨仓 Fork PR 场景下则受限更多。这些约束在保证自动化便利性的同时，把操作权限控制在合理范围内。

四、使用边界与计费：约束限制与 AI Credits

4.1 约束限制

NPC 能力并非无限制触发，使用时需要注意以下几项约束：

• 当 Issue 或 PR 的评论数超过 100 条时，对应的 issue.comment、pull_request.comment 及 @npc 事件均不再触发流水线。
• 一次最多支持触发 10 个 NPC 事件。
• 重新打开 PR、Issue，或编辑描述、评论，都不会重新触发 NPC 事件。
• 以下格式中的 @ 提及不会触发 NPC 事件：引用（blockquote）、代码块（code）、折叠块（details）、有序列表、无序列表、表格、部分 HTML 标签。

合理控制评论规模、精简触发方式，可以避免 NPC 事件被误触发或超限失效。

4.2 AI Credits 计费

NPC 属于 AI 能力，其 Token 消耗以 AI Credits 计量，消耗云原生开发用量。社区版的 AI Credits 计费规则如下：

免费额度按月发放，月底清零，不叠加至次月。免费额度用尽后，相关能力将受限——例如 AI Credits 用尽后，NPC 等 AI 能力将不可用。如需提升用量上限，可在 cnb.cool 中前往"组织 > 设置 > 用量管理"绑定预算。

五、总结

腾讯云 CNB 把 AI 能力作为 Git 平台的原生组成部分，NPC 则是其中的代表性功能：它既能自动回复 Issue 与 PR 评论、解答常见问题，又能在工作模式下自主编写代码、提交 PR 完成闭环交付；同时支持自定义角色行为与知识库驱动，让回答更贴合项目实际。配合清晰的事件配置、明确的约束限制与透明的 AI Credits 计费，开发者可以用很低的门槛在仓库中拥有一批"随叫随到"的智能研发助手。

如果你想体验 AI 原生 Git 平台的完整能力，可以前往腾讯云 CNB 产品页了解详情，开通后即可在仓库中 @ 提及 NPC，开启你的智能协作实践。