在 Issue 里 @ 一下，AI 就帮你写代码？CNB 的 NPC 到底能干什么

摘要：

在 Issue 或 PR 评论里 @ 提及 NPC，它就能自动答疑、进入工作模式帮你写代码并提交 PR。本文讲清 CNB 这个 Git 工作流内置 AI 角色的能力范围与使用边界，帮你判断它适合接哪些协作任务。

一、NPC 是什么

NPC 全称 Non-Player Character，是 CNB 平台内置的 AI 角色功能。和独立的 AI 编程插件不同，NPC 直接长在 Git 工作流里，通过 Issue 和 PR 评论就能触发，不需要切换到额外工具。

它的定位是让 AI 成为一个可以对话、可以干活的协作者。团队成员在 Issue 里提出问题、在 PR 里请求评审，NPC 能自动响应；需要它动手时，还能进入工作模式编写代码、提交 PR。整个交互都发生在仓库的讨论线程中，对熟悉 GitHub 工作流的团队来说上手成本很低。

NPC 的能力建立在 CNB 的 AI 代码助手体系之上，消耗 AI Credits。社区版每月免费 500 credits，用尽后 NPC 等 AI 能力将不可用，直到额度恢复或绑定预算提升上限。这一点在规划 NPC 使用时需要先纳入考量。

二、自动回复 Issue 和 PR 评论

NPC 最基础的能力是自动回复。它可以自动监听并回复 Issue 和 PR 评论，解答常见问题。当有人在 Issue 里描述了一个重复过多次的问题，NPC 可以基于项目文档和知识库给出标准答案，把维护者从重复答疑中解放出来。

在 PR 评审场景，NPC 可以针对评论做自动应答，帮助解释代码改动、补充上下文。这类能力适合沉淀了完善文档的项目，因为 NPC 的回答质量直接取决于它能获取到的知识是否充分。

为了让回复更精准，NPC 支持知识库驱动。它可以基于项目文档和知识库提供更贴合项目实际的回答，而不是给出泛泛的通用答复。这意味着项目文档维护得越好，NPC 自动回复的价值越高。

三、进入工作模式自主编写代码

自动回复只是起点，NPC 更强的能力是工作模式。在工作模式下，NPC 可以根据指令自主编写代码、提交 PR。也就是说，它不再只是「回答问题」，而是能「动手完成任务」。

典型用法是：在 Issue 或 PR 评论里用 @npc 唤起它，给出明确指令，NPC 就会理解需求、编写代码，并把成果以 PR 的形式提交回来供人工评审。若要让它自主写代码、推送代码、创建分支和 PR，需要在评论区勾选「替我上班」开启工作模式（需仓库开发者及以上权限）。这把 AI 编码能力直接嵌入了团队的协作流程，开发者可以在讨论线程里把一个小需求或一个 bug 修复派给 NPC。

需要注意的是，NPC 提交的代码仍然要走标准的 PR 评审流程，由人工把关。自主编写代码不等于无人审核，它更像是给开发者多了一个能产出初稿的协作伙伴，最终合入决策权仍在团队手里。

四、自定义行为与事件配置

NPC 的行为不是写死的，用户可通过配置自定义它的行为逻辑和响应方式。配合 CNB 的声明式 .cnb.yml 配置，可以为不同仓库、不同事件设定 NPC 的触发条件和处理方式，让它的行为贴合团队自己的规范。

从触发机制看，NPC 事件属于 CNB 触发规则的一部分。当 Issue 或 PR 发生评论时，可以触发 issue.comment、pull_request.comment 以及 @npc 事件，进而驱动 NPC 相关的流水线执行。这也是 NPC 能够「监听评论、自动响应」的底层原理。

五、使用边界：评论数、事件数、触发位置与额度

能力再实用也有边界，NPC 的边界主要体现在以下几处。

第一是评论数限制。当 Issue 或 PR 的评论数超过 100 条时，对应的 issue.comment、pull_request.comment 及 @npc 事件均不再触发流水线。讨论热烈的长线程里，这个上限意味着 NPC 不会在每一条评论后都介入，避免过度打扰和资源浪费。

第二是事件并发限制。一次最多支持触发 10 个 NPC 事件。短时间内大量 @npc 调用会被限制在这一上限之内。

第三是触发位置限制。并非所有 @npc 提及都会生效：写在引用（blockquote）、代码块、折叠块、有序或无序列表、表格以及部分 HTML 标签里的 @ 提及不会被识别为触发指令，也就不会触发 NPC 事件。要在正文普通评论里 @ 才作数。

第四是 AI Credits 额度。NPC 消耗 AI Credits，额度用尽后 NPC 等 AI 能力不可用（免费额度与计费规则详见计费说明）。对于把 NPC 纳入日常协作的团队，需要关注月度额度消耗，必要时通过绑定预算提升上限，避免月中 NPC 突然停摆。

这几条边界组合起来，界定了 NPC 当前的适用强度：它适合处理中等频率的答疑和任务派发，而不是在超大讨论帖里逐条响应的高频场景。

六、哪些场景适合用 NPC

结合能力和边界，NPC 适合承担几类任务。

一是常见问题的自动答疑。文档完善的项目里，把高频问题交给 NPC 自动回复，能明显减轻维护者负担。

二是小型代码任务的初稿产出。bug 修复、小功能、文档更新这类边界清晰的任务，可以通过 @npc 派给 NPC 生成初稿，再由人工评审合入。

三是 PR 评审中的上下文补充。NPC 可以辅助解释改动、回应评审意见，让评审沟通更顺畅。

不太适合的场景是评论数超过 100 条的超长讨论线程，以及需要高频并发响应的情况，这些会触及 NPC 的评论数和事件数边界。

NPC 是 CNB 把 AI 能力原生融入 Git 工作流的一次实践，自动回复、自主编码、知识库驱动这些能力让 AI 真正参与到日常协作里。如果你的团队已经在用 CNB 管理代码，不妨在一个文档较全的仓库上先试用 NPC，看看它能接下哪些重复性工作；想开通体验，可以前往腾讯云 CNB 在仓库里 @ 提及 NPC，开启第一次智能协作。