Issue 没人回、PR 没人审？让腾讯云 CNB NPC 来接手

摘要：

开源项目或繁忙团队里，Issue 堆积无人回复、PR 长时间没人评审是常见困境。腾讯云 CNB 的 NPC（AI 角色）可自动监听并回复 Issue/PR 评论、进入工作模式编写代码提交 PR。本文介绍如何用 NPC 接手这些无人响应的协作任务。

一、没人回的 Issue，正在拖慢你的项目

一个项目是否健康，往往看它的 Issue 和 PR 响应速度。用户提了个问题，几天甚至几周没人搭理；开发者兴冲冲提交了 PR，却迟迟等不到评审——这些"没人回"的瞬间，会迅速消耗贡献者的热情，也让项目背上"维护不力"的印象。

对开源项目维护者尤其艰难：他们大多是兼职维护，本职工作之外还要抽空答疑、审代码。当 Issue 和 PR 攒到几十上百条，一个人根本看不过来。对商业团队也一样，研发节奏快，评审资源永远紧张，总有些请求被排到很后面。

问题的本质是：这些重复性、基础性的响应工作，占用了有限的人力。而其中相当一部分——比如常见问题答疑、格式规范的评审意见、简单的代码修改——其实很适合交给自动化来处理。

腾讯云云原生构建（Cloud Native Build，简称 CNB）提供的 NPC（Non-Player Character）AI 角色，正是用来接手这类任务的。NPC 是 CNB 中的自动化角色，相当于虚拟智能助手，可执行评论回复、代码协作等自动化任务，把团队从"必须人工响应每一条"的压力中解放出来。

二、NPC 能做什么：自动回复与工作模式

NPC 的能力主要分两层。

第一层是自动回复。在 Issue 或 PR 评论中 @ 提及 NPC 时，会触发相应的自动化流水线，NPC 自动执行预设任务并回复。它可以在评论区回答问题、生成代码审查意见，回复的提交者会显示为 NPC 角色名。对常见问题，NPC 可以基于项目文档和知识库给出相对精准的回答，维护者只需在必要时介入即可。

第二层是工作模式。在评论区勾选"替我上班"即可开启（需仓库开发者及以上权限）。开启后 NPC 拥有更高权限，可自主编写代码、推送代码、创建分支、创建合并请求，协助解决 Issue。这意味着 NPC 不只是"动嘴"回复，还能"动手"把问题解决掉——比如根据 Issue 描述修复一个 bug 并提交 PR 等待人工确认。

此外，NPC 还支持自定义行为和知识库驱动。用户可以为 NPC 设定角色定位、回复风格，让它基于项目文档提供更贴合上下文的回答。这些能力让 NPC 不只是通用问答机器人，而是懂这个项目的专属助手。

三、两类 NPC：系统内置与自定义角色

CNB 提供两类 NPC。

系统 NPC：平台内置，目前有 CodeBuddy。使用方式很简单，在评论中直接提及：

@CodeBuddy 帮我回答下这个 issue。

自定义 NPC：用户可以在自己的仓库中定义 NPC 角色。使用方式：

@cnb/feedback(专家) 帮我回答下这个 issue。

其中 @ 后跟 NPC 所属仓库路径（如 cnb/feedback），括号里填角色名（如 专家）。在编辑器中输入 @ 会弹出 NPC 选择器，展示默认 NPC、当前用户自定义的 NPC 以及已关注仓库中的 NPC，方便直接选用。

对于开源项目，自定义 NPC 的价值尤其明显——可以定义一个"项目专属答疑助手"，把项目的常见问题、贡献指南、代码规范都教给它，让新来的贡献者第一时间就能得到符合项目语境的回答。

四、定义一个自定义 NPC：角色与行为

定义一个自定义 NPC，主要涉及两部分配置。

第一部分是定义角色，在 NPC 所属仓库的 .cnb/settings.yml 中配置角色名、口号和 prompt。例如定义一个"评审专家"角色：

npc:
  roles:
    - name: 评审专家
      slogan: 专业评审，高效协助
      prompt: |
        你以"评审专家"自称，致力于提供专业、准确的代码评审意见。
        回复时保持简洁专业，重点关注代码质量、潜在缺陷和规范符合度。
        无论是日常对话还是代码审查，你都会保持以上风格

只完成这一步，NPC 就可以直接使用了——系统会提供默认的运行环境和行为。

第二部分是自定义行为（可选），在 NPC 所属仓库的 .cnb.yml 中配置 NPC 事件流水线。如果只想自定义 Issue 评论时的行为，可以这样写：

$:
  issue.comment@npc:
    - docker:
        image: cnbcool/default-npc:latest
      stages:
        - name: npc go
          type: npc:go

系统通过 include 机制自动合并默认配置和 NPC 仓库的配置：NPC 仓库里已定义的事件覆盖默认，未定义的事件保留默认行为。建议同时配置 issue.comment@npc 和 pull_request.comment@npc 两个事件，否则只配了 Issue 事件时，PR 评论仍走默认。

如果需要让 NPC 用自定义镜像运行（比如预装特定的 CLI 工具或 Skills），可以通过 docker.image 指定自行构建推送的镜像；不指定时默认使用 cnbcool/default-npc:latest。

五、让 NPC 接手无人响应的 Issue

针对"Issue 没人回"这个场景，可以这样落地：

1. 在维护者自己的仓库定义一个答疑 NPC（配置角色 prompt，必要时自定义行为）；
2. 把仓库设为公开，或让需要的人拥有读权限，使他们能通过 @ 提及这个 NPC；
3. 贡献者在 Issue 中 @ 提及 NPC 后，NPC 自动执行流水线并回复，回复提交者显示为 NPC 角色名；
4. 维护者只需关注 NPC 无法处理的复杂问题，简单答疑由 NPC 兜底。

NPC 事件流水线在当前 Issue 或 PR 所属仓库下执行。以评论 Issue 为例，触发 NPC 事件后，当前评论下方会显示被提及的 NPC 角色名及流水线执行状态；如果 NPC 回复了评论，回复的提交者也显示为 NPC 角色名。

需要注意，NPC 事件视作开发场景，消耗的是云原生开发用量。社区版有云原生开发 CPU 免费额度（1600 核时/月），AI 能力还受 AI Credits 免费额度（500 credits/月）约束，额度用尽后 NPC 等 AI 能力将不可用。

六、触发限制与权限边界

使用 NPC 时，有几个限制和边界要记清楚，避免"提了却没反应"或权限不足。

触发限制：

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

权限边界：

• NPC 事件流水线中的 CNB_TOKEN 仅限访问当前仓库；
• CNB_TOKEN 的最大角色取决于触发用户在仓库中的角色：Developer / Master / Owner 触发时最大角色为 Developer，Reporter / Guest 触发时最大角色为 Reporter；
• Reporter / Guest 无法启用工作模式（workMode 强制为 false），也就是说只有具备开发者及以上权限的用户，才能让 NPC 进入"替我上班"模式去改代码。

这些边界保证了 NPC 的自动化在安全可控的范围内运行，不会越权操作。

七、结语

Issue 没人回、PR 没人审，本质是重复性响应工作占用了有限的人力。腾讯云 CNB 的 NPC 把这些基础工作自动化——自动监听并回复 Issue/PR 评论，进入工作模式后还能自主编写代码、提交 PR，让维护者和评审者把精力留给真正需要经验的复杂问题。

NPC 支持系统内置的 CodeBuddy，也支持自定义角色和行为，配置从定义角色到自定义流水线都可以按需渐进。开源项目维护者尤其适合用它给项目配一个"专属答疑助手"，提升社区响应速度。

如果你的项目也正被无人响应的 Issue 和 PR 困扰，可以到 腾讯云 CNB 上定义一个答疑 NPC，在评论区 @ 一下，让它先帮你把那些重复的问题接起来。