别新建系统了：用 GitHub Issue 把 AI-Native SDLC 跑起来

上周和一位研发负责人吃饭，他刚读完 Anthropic 那份《AI-Native SDLC Playbook》，兴奋又发愁。兴奋的是「原来代码不再是瓶颈这件事，连 Anthropic 都认了」；发愁的是——

「intent.md、spec.md、plan.md、三层控制、持续 Evals……这套东西我要是从零搭，得搭多久？我团队现在连个像样的需求管理系统都还在和 Jira 打架。」

我说，你可能不用搭。你已经有载体了：你的 GitHub Issue。

这篇文章写给研发团队 Leader，讲的是怎么把 playbook 那套六阶段闭环，落在你 今天就在用 的 GitHub 上——不新建系统、不加预算、不改变团队习惯。需要说明：下面那个贯穿全程的需求是 示意 walkthrough，用来把机制讲透，不是某个团队的真实战报；机制本身（Action 触发、产物链、门禁）都是 claude-code-action 和 GitHub 的原生能力，可直接照搬。

先交代背景。我之前写过 代码不再是瓶颈：Anthropic 的 AI 原生 SDLC 手册，印证了组织摩擦这件事，那篇讲的是 为什么——瓶颈从写代码转移到了规划、评审、部署这些人类速度的环节。这篇是它的实操续篇，讲 怎么做：在你现有的 GitHub 仓库里，把那个闭环真的转起来。

一句话原理：Issue 当壳，产物进仓库，门禁交给 GitHub

playbook 的核心是「产物链」：每个阶段结束提交一个文件进版本库，下一阶段从读它开始——

intent.md → spec.md → plan.md → 代码+测试 → PR+评审 → 事故记录 → 回到 intent.md

很多人卡在这里：「我得搭一套系统来管这些 .md 文件吧？」

不用。拆成三层来看，GitHub 全都现成：

• 状态机：用 Issue + label。一个需求 = 一个 issue，label 标记它走到哪个阶段。
• 产物权威记录：还是进仓库的 .md 文件。issue 只是壳，文件才是真源（这点后面要专门讲，是最容易踩的坑）。
• 门禁：用 GitHub 的 branch protection + required status checks。这一层是 issue 驱动模式 白送的——playbook 三层控制里最难的「确定性层」，GitHub 原生就帮你兜住了一半。

把这三层和 playbook 的六阶段对起来，就是下面这张表。这是我建议每个 Leader 贴在团队 wiki 首页的东西：

三层控制，逐层落到 GitHub 上

playbook 里我认为最值钱的治理设计，是 三层控制——不是所有规则都用同一种强度执行。这三层在 GitHub 上各有落点：

建议层    CLAUDE.md + Skills        告诉 AI 该怎么做，违规变少见
  │       （签入仓库，action checkout 时自动生效）
确定性层  Hooks + branch protection  行动前的门禁，违规几乎不可能
  │       （仓库内 Hook + GitHub 侧分支保护，双保险）
回归层    Evals + CI required check  配置本身也被回归测试
          （改坏 CLAUDE.md/Skills/Hooks 的 PR 进不了 main）

建议层 最轻：把团队规范写进仓库根的 CLAUDE.md，把安全红线、架构约定封装成 .claude/skills/。这些文件签入仓库，Action checkout 时自动加载，不花一分钱基础设施。

确定性层 是 issue 驱动的最大红利。playbook 说「必须永远成立的策略，要在 Skill 背后放一个 Hook」——但在 GitHub 上你还有第二道：branch protection 的 required checks 和 required reviews。就算 agent 被绕过、prompt 被注入，它也推不进 main。 这一层在自建系统里要专门写，在 GitHub 上是勾几个选项。我在 面向 Agent 开发：可测试和可运维第一次真正成为前提条件 里讲过一个判断：系统必须给 Agent 一个「可调用、可验证、可反馈」的闭环。branch protection 恰好就是这个闭环里最硬的那道反馈——它不跟 Agent 商量。

要把这层的边界说清楚，免得被当成「已经保证了一切」：branch protection 守的是 main 这道闸，它不阻止 agent 在 feature 分支上改错东西、也不阻止它在 PR 里产出垃圾——那些得靠仓库内的 Hook（行动前拦截路径权限、凭据）和评审层来管。两道是叠加关系，不是替代：Hook 管「agent 动手时」，branch protection 管「成果进主干时」。少任何一道，确定性层都有洞。

回归层：把 evals 套件设成 required status check，任何改 CLAUDE.md、Skills、Hooks 的 PR 都必须全绿才能 merge。配置变更本身被回归测试，这是 playbook 里最容易被跳过、但最防「改回去」的一环。

怎么配：一个最小可行 workflow

下面是能直接用的骨架。Anthropic 官方的 claude-code-action 支持三种触发：issue/PR 评论里 @claude、issue 被指派、issue 被打上指定 label。我们用 label + @claude 两种：

name: Claude Code SDLC
on:
  issues:
    types: [opened, labeled]
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  claude:
    # 防自环：只响应人类，不响应 bot（含 Claude 自己）
    if: |
      github.event.comment.user.type != 'Bot' &&
      ((github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
       (github.event_name == 'issues' && contains(github.event.label.name, 'claude')))
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            你是本仓库的 SDLC agent，遵守 docs/sdlc/REVIEW.md 和 CLAUDE.md。
            1. 被要求「实现」时：先在评论里产出 plan，等人类回复「接受计划」，
               然后才提交代码 PR。永远不要拿到需求就直接写代码。
            2. 所有产物（intent/spec/plan.md）都提交进仓库，PR body 写 Closes #<issue>。
            3. 永远不直接 push main，只开 PR。
          claude_args: "--allowedTools 'Read,Edit,Bash(make test),Bash(make lint)'"
# generated by hugo AI

那个 if 条件里的防自环，是我特意加的，也是新手最容易漏的。不加的话，Claude 在 issue 上回一条评论，评论里带着 @claude 或触发词，就会再次唤醒 Claude——runbook 把自己当素材，越滚越多。这个坑我在 Runbook：把「代码为什么是现在这样」写进版本库 里专门写过：防递归要有两半，少任何一半都会自我喂养。GitHub 这一半，靠过滤 bot 作者来挡。

label 体系建议先建这几个，够用：

claude              # 触发 agent
stage:intent        # 规划中
stage:spec-ready    # 待设计
stage:plan-ready    # 待构建
stage:implementing  # 实现中
trigger:incident    # 维护阶段自动开的事故 issue

走一遍：一个需求的完整旅程

把上面的机制串起来，看一个需求怎么从 issue 走到上线。以下是一个示意需求（给后台加一个「导出对账单」接口），用来演示流转，不是真实战报。

① 开 issue（规划）。运营同学——注意，不是工程师——按 intent 模板开了 issue #123：「客户每月要人工导出对账单，一次 20 分钟，容易错。希望后台有个一键导出。」打上 claude label。

② @claude 头脑风暴。产品负责人在 issue 下评论：「@claude 帮我把这个需求结构化成 intent.md，问清楚我边界。」Claude 反问几个问题（导出哪些字段？权限范围？格式？），收敛后提一个 PR：新增 intent/2026-09-statement-export.md，body 写 Refs #123。负责人 merge 这个 PR = 规划批准，merge 记录就是审批记录。打 stage:spec-ready。

③ 产出 spec（设计）。label 触发 workflow，Claude 读 intent.md，在组织 Skills（含安全 API 审查 Skill）约束下产出 spec.md PR，明确标出一个策略冲突：「导出含金额字段，但安全 Skill 要求 PII 不落日志——导出日志需要脱敏。」负责人和策略负责人在 PR 里讨论、merge = 设计批准。打 stage:plan-ready。

④ Plan 先行，再实现（构建）。这一步是关键：Claude 不直接写代码。它在 Plan 模式（只读）下产出计划——改哪几个文件、什么顺序、风险（导出接口要限速）、怎么验证——贴在 issue 评论里，然后 停下等人。工程师回复「接受计划」，Claude 才开代码 PR，body 里链全 intent/spec/plan 三个产物。打 stage:implementing。

⑤ 门禁全开（测试 + 部署）。这个代码 PR 要过三关：evals required check 全绿；Claude 按 REVIEW.md 审一轮（只报 Bug/安全/合规，小建议限 5 条）；branch protection 要求一名人类 approve。三关都过，才 merge。merge 触发部署 workflow。

⑥ 事故回流（维护）。两周后监控脚本发现导出接口 5xx 率突破 2σ，自动开 issue #156，body 已按 intent 模板预填（异常、证据、受影响系统、待确认问题），打 trigger:incident。值班工程师分诊，路由给产品负责人——循环回到第①步。修复上线后，照 playbook 的规矩，给这个事故补一条永久 eval。

整个旅程里，人的注意力只集中在几个 门禁点：merge intent、merge spec、接受 plan、approve 代码 PR、分诊事故。其余搬运、起草、自检，全是 agent 在跑。这就是 playbook 说的「人类的注意力转向行为和风险」。

必须定死的一件事：唯一真源

走到这里，最聪明的读者一定会问一个问题——这也是我建议你团队上线前必须回答的：

issue 的 label 状态，和仓库里的产物文件，万一不一致怎么办？issue 关了，但 spec.md 没 merge，到底算不算设计批准了？

这是 playbook 反复强调的 single-source-of-truth 问题。issue 驱动模式天然有两个状态来源：issue 的 label，和仓库的产物 + merge 记录。不定死谁是权威，它俩迟早漂移，然后你的整个审计链就不可信了。

我的答案很明确，也建议团队照抄：

label 只是视图，产物文件 + PR merge 记录才是权威。

• issue 的 label 是给看板用的、给人扫一眼用的——它是「投影」
• 一个阶段算不算批准，只看对应的产物 PR 有没有 merge
• issue 关了但 spec.md 没 merge？以 git 为准：设计没批准
• 出现分歧时，永远信仓库，不信 label

这正好对应 playbook 给遗留系统的三个方案里的 方案二（遗留系统为真源）的反向选择——我建议你选 方案一：仓库为唯一真源。issue 在这套设计里被刻意降级成「壳和触发器」，而不是真源。一旦你把 issue 当成权威状态机，漂移问题无解；一旦你把它当成视图，问题自动消失。

这个取舍和我在 评测集是一份没人签字的文件 里说的是同一件事：飞轮停摆的根因，往往是「什么叫好」「什么算批准」没有唯一的、签了字的归属。在 GitHub 上，那个签字就是 merge。

给 Leader 的落地路线

如果你认同上面的设计，不要六个阶段一起上。playbook 自己说这些打法是模块化的，我建议这个顺序，每一步都独立见效：

1. 先配构建阶段（一周内能做完）：仓库放一个 CLAUDE.md，配好上面那个 workflow，约定「@claude 实现某需求」。让团队先体验「plan 先行、产物进仓库」。这一步零风险，因为 branch protection 兜底，agent 推不进 main。
2. 再加测试门禁：把 make test / evals 设成 required check。从此「改坏配置的 PR 进不了 main」。
3. 然后补规划设计：定 intent.md / spec.md 模板，让产品同学也能在 issue 里 @claude 起草。这一步需要产品和工程对齐模板，但一旦跑通，需求到代码的流转会顺很多。
4. 最后接维护回流：写一个监控脚本，破阈值自动开 issue。闭环到这一步才真正闭上。

每一步都能独立停下来、独立产生价值。Leader 要做的不是「批准一个大改造」，而是「让团队先跑第一步，看它自己证明价值」。

Leader 怎么知道它生效了

「让团队自己证明价值」的前提，是你手里得有证据，而不是听汇报。这套设计的好处是——因为产物全进 git、门禁全在 GitHub，度量不需要额外埋点，从你已有的 git 历史和 PR 数据里就能直接读出来。playbook 给每个阶段都配了先导指标和滞后指标，我挑 Leader 最该盯的几个，全部可量化、可溯源：

这几个指标里，我最看重 产物链完整率。它是整套东西的「心电图」：如果代码 PR 普遍链不到上游产物，说明团队只是把 AI 当成「更快的码农」，六阶段闭环根本没转起来——那你做的就只是阶段三，不是 AI-Native SDLC。这个比例从「几乎为零」开始爬，比任何「我们提效了 X%」的口头汇报都诚实，因为它骗不了人，git 历史就在那儿。

反过来提醒一句：别去量 token 消耗、agent 调用次数、自动化率这些——它们只说明「你花了很多 AI」，不说明「你交付得更好」。我在 数字员工的自我进化 里讲过同一个判断：决定商业模型成不成立的，不是 agent 能跑多少演示任务，而是极少人工介入下的规模增长。研发流程也是——盯产物链和人类介入点，别盯调用量。

写在最后

playbook 那套东西看着唬人，但拆开看，它要的三样东西——状态机、产物链、门禁——你的 GitHub 仓库里全都有现成的对应物。真正要新建的，只有一个 workflow 文件、几个 label、和一条团队约定：产物进仓库，label 只是视图，merge 才是签字。

代码不再是瓶颈了。但瓶颈转移之后，你的流程得跟得上——而跟上它，不需要你从零搭一套系统，需要你把已经在用的 GitHub，重新接一遍线。

你的团队现在用什么管需求？如果要把这套 issue 驱动的闭环落进去，你觉得最先卡住的会是哪一步？欢迎留言聊聊。

See also

• Runbook：把「代码为什么是现在这样」写进版本库
• Anthropic 给 Claude 装了一套个人操作系统
• 代码不再是瓶颈：Anthropic 的 AI 原生 SDLC 手册，印证了组织摩擦这件事
• Anthropic 领先行业 6 个月——但只有前两层算数
• 从 Cowork 到 Tag：AI 的竞争单位，正在从个人变成组织