代码不再稀缺之后：如何让一个 Issue 自己走到生产

有一类工作最消耗工程团队：它不难，却必须有人放下手里的事。

一次 UAT 发布停在了 Progress Deadline Exceeded。这行报错本身几乎没有信息。按照过去的处理方式，值班同事先看 Kubernetes，平台同事确认资源和网络，后端再接过日志检查应用启动；如果中间跨了时区，第二天还要有人重新讲一遍发生了什么。

那次我们把仓库、目标环境和故障现场交给了 Codex。它沿着 Deployment、ReplicaSet、Pod 和启动日志逐层排查，最后发现真正的问题不在集群：一个回调处理器没有被 Spring 加载。随后它完成修复、补充验证、创建分支并发起 PR。另一个模型从代码、测试和架构边界重新检查了一遍，最后由工程师完成 CR。

修复本身并不传奇。真正让人印象深刻的是，问题从“发布失败”走到“等待审核”，中间没有人充当路由器，也没有人在群聊、终端、工单和代码仓库之间反复搬运上下文。

几天后，一个普通需求走了同样的路径：系统需要新增一类币种基础数据。Agent 先找到已有的国家和地区数据模块作为参照，识别数据库、接口、测试和兼容性边界，再拆分实现、部署验证并整理 PR。人没有被排除在流程之外，只是不再负责机械地查模板、追进度和拼证据，而是把时间留给字段语义、领域边界和长期兼容性。

我们维护的是一套跨多个仓库的金融业务系统。Bug 会穿过前端、中台、领域服务和基础设施；一个看似很小的需求，也可能同时牵动数据、接口、测试和发布。正是在这种不够简单、又远没有资格推倒重来的系统里，我们开始重新理解所谓的 AI 原生开发：

不是让 AI 替团队写更多代码，而是让 Issue 带着计划、状态和证据持续向前，直到来到必须由人判断的位置。

这篇文章记录的，就是我们如何把这些真实发生过的修复和需求，逐步连接成一条以 GitHub 为中心、由多个 Agent 推进、最终由人 CR 的交付链路。

代码不再稀缺，等待才是最大的成本

软件项目很少真的卡在“这一百行代码没人会写”。它通常卡在这些地方：

• 产品描述了一个现象，但没人确定真正要改哪个仓库；
• 前端已经完成，却在等后端接口和测试环境；
• 功能写完了，但没有人补异常路径和回归测试；
• CI 红了，所有人都在等“有空的人”去看日志；
• UAT 已经验证，却无法证明生产运行的是同一个制品；
• 线上告警有 Trace，Issue 有截图，PR 有讨论，但它们彼此不相连。

写代码只是流水线里最显眼的一段。真正昂贵的是等待、交接、上下文丢失，以及人不断充当系统之间的胶水。

所以，AI 软件开发的关键问题不应该是：

它一次能写多少代码？

而应该是：

一个问题进入系统以后，还需要多少次人工搬运，才能变成一个可验证的结果？

OpenAI 在 Harness Engineering 中把工程师的新角色概括为“Humans steer. Agents execute.”。真正值得注意的不是那句口号，而是背后的工程条件：仓库必须可读，环境必须可运行，规则必须可执行，测试必须能给出真实反馈。

这也解释了为什么一个强模型放进混乱的仓库，往往只会更快地产生混乱。

为什么最后留下的是 Issue，而不是 Prompt

Prompt 很适合开始一段对话，却不适合承载一项跨越几天、多个仓库和多个角色的工作。

它没有稳定身份，没有生命周期，没有明确责任，也很难回答这些问题：

• 为什么要做？
• 哪些内容明确不做？
• 谁在等待谁？
• 什么结果才叫完成？
• 哪一步需要人批准？
• 最终上线的制品是否经过了同一组测试？

Issue 天然适合做这件事。它有 URL、有历史、有状态、有关系，也能连接设计、代码、PR、测试和部署。

但前提是，我们必须停止把 Issue 写成一句话的愿望。

在新的工作方式里，Issue 不是“需求单”，而是给人和机器共同执行的一份作战命令。

图 1：一个稳定的 Issue 节点，把业务意图、执行边界、验收证据和工程调度连接起来。

一份真正可执行的 Issue，至少要说清楚六件事：

边界写得越清楚，Agent 反而越能自主工作。阻碍自治的从来不是规则太多，而是任务里到处都是“你看着办”。

GitHub 的产品演进也在强化这条路线：把 Issue 直接分配给 Coding Agent 后，它会规划任务、创建分支和 PR、修改代码、运行测试，再请求审核。到 2026 年 7 月，GitHub 又为 Issue 自动化加入了 理由、置信度和批准机制。

重点不是“GitHub 也在做 Agent”，而是软件协作的入口正在发生变化：Issue 正从记录工作，变成启动工作。

需求和 Bug，也不该靠人搬进 Issue

很多团队谈 Issue 驱动，实际做法仍然是让产品经理、测试或值班工程师手工复制一遍：把会议里的需求抄到 GitHub，把群里的客户反馈改写成 Bug，再从监控告警里拼出复现信息。

这不是 Issue 驱动，只是换了一个地方做数据录入。

在我们正在搭建的流程里，Issue 不是人工填写的起点，而是所有工作信号自动汇聚后的标准形态。

Intake Agent 持续监听这些入口，但不会看见一条消息就制造一张新工单。它先做三件事：

1. 归一化：把不同来源翻译成统一的意图、现象、影响、证据和验收条件。
2. 聚类与去重：判断它是新需求、新 Bug，还是已有 Issue 的另一份证据；相同根因只保留一个事实源。
3. 补全上下文：自动关联相关代码、近期 PR、部署版本、日志、Trace、设计文档和历史事故。

如果同一个问题先被客户报告、随后触发监控、又在回归测试中复现，系统不应该创建三张互不相识的票。它应该把三条信号合并到同一个 Issue，提高影响等级，追加复现证据，并重新计算优先级和处理路径。

需求也是一样。一段产品构想不必等人整理成完美文档才能启动。Agent 可以先生成候选 Issue，标出目标、非目标、冲突决策和缺失信息；清楚的部分自动拆解推进，真正影响产品方向的少数问题再请求人回答。

于是，自动化不再从“开发接到 Issue”才开始，而是向前覆盖了工作的诞生：

需求 / 反馈 / 测试 / 告警 / 安全事件
                 ↓ 自动采集
          归一化、聚类、去重、补证据
                 ↓
          唯一事实源：父 Issue
                 ↓ 自动分拣与拆解
      设计 ── 前端 ── 后端 ── 测试 ── 环境
                 ↓
           PR / UAT / Production
                 ↓ 运行证据回写
          关闭 / 重开 / 生成后续 Issue

这条链路的关键不是“没有人出现”，而是不再需要人搬运状态。低风险工作可以从发现、建单、实现、验证一路自动流动；涉及产品取舍、架构边界、资金安全或生产变更时，系统带着完整证据精准地停在人面前。

gh CLI：Agent 接入交付系统的那双手

为什么选择 GitHub 做中心？不是因为大家已经把代码放在那里，而是因为一次软件变更需要的关键对象——Issue、分支、Commit、PR、Review、Checks、Deployment 和 Release——本来就在同一张关系网里。

但网页界面是为人设计的。Agent 需要的是稳定、结构化、可组合，而且每次操作都能留下审计记录的接口。

GitHub CLI 恰好提供了这层薄而有力的适配：gh issue 读取和更新任务，gh pr 发起与参与评审，gh run 获取 CI 结果，gh project 更新工作状态，未被高级命令覆盖的能力则通过 gh api 访问。对 Agent 来说，gh 不是一个方便的命令行工具，而是连接 GitHub 控制平面的执行协议。

# 接手任务前，先读取完整事实，而不是只看标题
gh issue view 418 --json title,body,labels,assignees,comments,state

# 把计划和待确认问题写回唯一事实源
gh issue comment 418 --body-file .agent/plan.md
gh issue edit 418 --add-label 'status:planned'

# 实现完成后创建关联 PR，并等待真实检查结果
gh pr create --fill --body 'Closes #418'
gh pr checks --watch

# 使用另一模型的 Reviewer Agent 留下交叉审查意见，但不批准 PR
gh pr review 427 --comment --body-file .agent/cross-review.md

它带来一个非常重要的性质：Agent 不必共享同一段对话，只需要共享 GitHub 上的事实。 前一个 Agent 即使已经退出，下一个 Agent 仍能从 Issue、计划、Commit、Review 和 Checks 恢复现场，而不是重新猜一遍“我们做到哪了”。

为此，不同信息应该放在不同的 GitHub 对象里：

Issue Body 保存稳定契约，不应该被每次执行进度反复改写；动态状态进入 Project 字段，计划进入 Task List，证据进入 Checks 和 Deployment。这样 GitHub 才是可查询的系统记录，而不是一条越来越长、最后没人敢读的评论流。

需求也要先 Review，不能一生成就开写

自动开发之前，需求先经过一轮并行评审：

• Product Reviewer 检查用户价值、业务规则、非目标和冲突决策；
• Architecture Reviewer 判断领域归属、跨仓库影响、接口和数据边界；
• Test Reviewer 把验收条件翻译成正常、异常、权限和回归场景；
• Security Reviewer 识别敏感数据、权限提升和不可逆操作。

这些 Reviewer 不在群里口头给意见，而是直接通过 gh issue comment、Labels、子 Issue 和 Project 状态留下结论。缺少关键决策时，状态回到 needs-clarification；评审通过后进入 ready，Planning Agent 才能生成执行计划并调度 Coding Agent。

不是让一个模型给自己打分

让生成代码的 Agent 再说一句“我已经 Review 过了”，价值非常有限。它通常会继承同一套上下文、假设和盲区，最容易放过的正是自己一开始理解错的地方。

我们更看好多模型之间的交叉审查：

Implementation Agent（模型 A）── 提交代码、测试与实现说明
                 ↓
Code Reviewer（模型 B）───────── 检查 diff、可维护性与遗漏路径
Test Reviewer（模型 C）───────── 独立推导边界用例并尝试证伪实现
Architecture Reviewer（模型 D）─ 检查领域边界、依赖方向和数据契约
Security Reviewer（模型 E）───── 检查权限、数据暴露与攻击面
                 ↓
Implementation Agent 修复并逐条回应
                 ↓
              Human CR

重点不在于凑齐五个品牌的模型，而是让审查者与实现者拥有不同角色、不同提示、独立推理路径和明确的反对目标。测试 Reviewer 不应先读实现者的测试结论，而应该从 Issue 的验收条件独立推导用例；架构 Reviewer 先对照架构规则，再看实现为什么声称自己合理。

Reviewer Agent 通过 gh pr diff、gh pr view、Checks 和关联 Issue 取得完整上下文，把发现作为行级评论或 Review Summary 写回 PR。实现 Agent 逐条回应、修复并重新运行验证。另一个 Agent 也可以 Review 前一个 Agent 的计划、测试设计和问题结论，而不只是检查代码风格。

但这条链路必须有清楚的终点：Agent 可以互相 Challenge，最终批准必须由人完成。

多模型审查降低的是漏检率和人的噪声，不转移责任。它们可能形成新的共识性误判，也无法替组织承担业务后果。因此 Agent 不使用 --approve，分支保护要求 Human Reviewer，PR 只有在 Agent 交叉审查收敛、Checks 通过且人完成 CR 后才能合并。

人的 CR 也因此从“帮机器找低级错误”升级为判断更昂贵的问题：需求是否真的被满足、抽象是否值得长期维护、风险是否可以接受，以及这个变更是否应该在此刻进入生产。

一条可运行的状态机可以非常朴素：

captured → triaged → needs-clarification → ready → planned
                                           ↓
developing → validating → agent-cross-review → human-CR
                                               ↓ 人批准
                                      human-approved → releasing
                                                           ↓
                                                verified → closed
                                                           ↓ 失败
                                                        reopened

每次状态迁移都必须同时写回四件事：谁做了决定、基于什么证据、下一步由谁执行、什么条件会让流程停止。 于是“Plan”不再锁在某个 Agent 的上下文窗口里，“当前进度”也不再依赖某个人在线解释。

gh CLI 让这套流程足够容易被 Agent 操作，但权限仍需克制：读取、评论、开分支和创建 PR 可以使用短期、最小权限凭证；PR 批准、合并授权、生产变更和敏感数据操作则交给人的独立身份与保护规则。方便自动化，不等于绕开治理。

分拣不是贴标签，而是决定这件事如何发生

一个 Issue 进入系统后，最差的做法是让某个 Agent 立即开始改代码。

它首先应该回答：

1. 这是产品问题、实现缺陷、环境故障，还是观察误判？
2. 现象出现在哪个页面，真正拥有逻辑的是哪个服务？
3. 是否已经有重复 Issue、进行中的 PR 或相关事故？
4. 缺少哪些验收条件、测试数据和设计决策？
5. 任务能否拆成更小、更容易验证的批次？
6. 哪些工作可以并行，哪些接口必须先稳定下来？
7. 这件事的风险有多大，Agent 的判断有多确定？

这才是 Issue Triage 的核心：不是给任务贴一个 backend 标签，而是把模糊的问题翻译成一张可以运行的工作图。

自动汇聚后的需求 / Bug Issue
               ↓
     补证据、找边界、判风险与置信度
               ↓
            父 Issue
               ↓
  ┌────────────┼────────────┐
  ↓            ↓            ↓
规格与接口   多仓库实现   测试与环境
  └────────────┼────────────┘
               ↓
       PR + 真实运行证据
               ↓
          人类判断与发布

低置信度的分拣应该停下来问人；高置信度、低风险的分拣可以直接推进。成熟系统的标志不是“永远不问人”，而是知道什么时候值得打断人。

我们不是一夜之间走到这里

这套实践距离“完全自治”还很远。更准确地说，我们已经搭出了几块重要的积木，并开始看到它们组合后的效果。

第一块积木：让仓库边界不再只存在于人的脑子里

前端、共享中台、多个业务域、渠道连接层、Mock、自动化测试、基础设施和 Skills 分布在十多个仓库。

过去，一个问题从页面开始，常常要靠熟悉系统的人判断：这是前端展示问题、共享中台编排问题、钱包领域问题，还是底层渠道能力问题？

现在，这些领域边界、仓库职责和 API 追踪路径被写成 Agent 可以读取的架构地图。它可以从页面动作中抽取请求路径、客户端方法或业务名词，再找到真正拥有实现的仓库。

这件事不炫酷，却极其重要。因为对一个正在运行的 Agent 来说，无法访问的知识等于不存在。架构如果只活在会议和某位同事的记忆里，就无法被规模化调用。

第二块积木：把经验做成工种，而不是收藏提示词

我们陆续沉淀了规格设计、模块设计、任务拆分、数据库设计、TDD、单元测试、REST API 测试、浏览器验证、代码规范审核、CI 修复、Kubernetes 排障、UAT 发布、生产 Preflight 和发布后验证等 Skills。

它们不是“神奇 Prompt 大全”，而是一套带约束的操作规程：应该先看什么、允许做什么、如何证明完成、什么情况下必须停下来。

于是同一个模型可以在不同时间扮演不同工种，而不必每次从零理解团队的做事方式。

第三块积木：让环境从稀缺资源变成可调度资源

Agent 如果只能写代码、不能运行真实系统，它最终只能说一句“理论上应该可以”。

我们的基础设施用 Terraform 管理网络、Kubernetes、数据库、缓存、消息队列、对象存储、镜像仓库、密钥和观测能力，用 Helm 统一工作负载模型，并把 Nonprod 与 Production 隔离。

开发者拥有稳定的 Namespace 和访问入口，只部署当前正在修改的服务；未修改的服务通过共享网关回落到稳定 UAT。这样既不需要为每个分支复制整套基础设施，又能让 Agent 获得真实的部署和验证空间。

图 2：开发环境共享 Nonprod 基座并按需部署；UAT 接受的同一制品再晋级到隔离生产。

环境一旦可以被创建、选择、验证和回收，它就不再只是 Ops 的后台资源，而成为开发流程的一部分。

第四块积木：让测试说真话

我们已经有 PR 编译和单测、Postman/Newman API 巡检、Playwright 页面验证、Mock Server、Kubernetes 日志、Trace 和数据库状态查询。

但工具数量并不等于反馈可靠。

如果测试脚本用 || echo 吞掉失败，如果断言只检查 HTTP 200，如果 Mock 永远返回理想结果，那么 Agent 只会沿着一盏假绿灯一路开向生产。

所以，下一阶段最有价值的工作不是生成更多测试，而是确保测试真的能够阻止错误状态继续流动。

第五块积木：Build Once，Promote by Digest

UAT 验收后的镜像以不可变 Digest 记录，生产发布晋级同一个制品，而不是在另一个分支重新构建。

这是整条证据链的铆钉。

如果测试的是 A，上线时重新构建成 B，那么前面再漂亮的自动化报告也无法证明生产在运行什么。只有 Commit、测试、镜像 Digest 和部署结果连在一起，“已验证”才不只是一个口头状态。

理想的一天：一个 Issue 如何自己走到生产

把这些积木连起来后，一项工作可以从被系统发现开始，沿着十个状态持续向前，而不需要某个人一直守在终端旁边。

图 3：机器负责让工作流动，人只在业务、架构、边界和生产风险处介入。

1. Intake Agent 从产品文档、客户反馈、测试失败和线上告警中提取需求或 Bug，自动创建或合并 Issue。
2. Triage Agent 补充证据、检查重复项、识别仓库，评估优先级、风险与判断置信度。
3. Product、Architecture、Test 和 Security Reviewer Agent 在 Issue 中完成需求评审；通过后生成可勾选 Plan 和关联子 Issue。
4. 前端、后端、测试和文档在接口稳定后并行推进。
5. 变更被部署到隔离的开发 Namespace，并执行健康检查。
6. Agent 运行单测、API、页面、安全和架构校验，失败就继续修复。
7. 使用不同模型的 Code、Test、Architecture 和 Security Reviewer Agent 交叉审查实现 Agent 的代码与工作，并通过 gh pr review 留下证据。
8. 交叉审查收敛、Checks 通过后，人完成最终 CR，审核业务正确性、架构取舍和难以自动化的边界体验，并决定批准或退回。
9. UAT 接受的同一 Digest 在批准后晋级生产。
10. Rollout、指标、日志和业务探针回写 Issue；验收通过则自动关闭，异常则重开原 Issue 或生成带完整现场的新 Bug。

这里最重要的不是“十步都由 AI 完成”。

最重要的是，任何一步成功后都能自动进入下一状态，任何一步失败后系统都知道应该把什么证据交给谁，而不是让一个人在群里问：“这个现在到哪了？”

把人从接力赛里拿掉

以一个资金类页面为例：用户发起转账时，余额校验只考虑了转账金额，没有把渠道费用计入。总扣款可能超过可用余额。

传统做法是一场接力赛：产品找前端，前端找后端，后端找渠道逻辑，QA 等部署，最后大家再讨论错误文案应该出现在哪里。

在 Issue 驱动的流程里，父 Issue 先锁定真正需要人判断的部分：

目标
  创建、报价和执行入口统一使用 Total Debit 判断余额

验收
  Transfer Amount + Channel Fee > Available Balance 时必须阻断
  错误出现在用户能够理解的位置
  报价缺失时不得继续提交

非目标
  不修改渠道计费策略，不重做页面信息架构

随后，后端余额校验、前端交互、边界用例设计可以并行。实现完成后部署开发 Namespace，测试 Agent 验证费用、零余额、报价缺失和正常流程，PR 自动带上页面录像、接口结果和部署地址。

人真正需要花时间的只有两个问题：

1. Total Debit 的业务定义是否正确？
2. 这个错误应该怎样表达，才不会误导用户？

剩下的查仓库、改代码、补测试、部署、回归和整理证据，都是可以被系统化的执行工作。

这不是取消前端、后端、测试和运维，而是让它们不再靠人肉接力才能协作。

真正的底座不是模型，是反馈

多 Agent 最容易被误解成“同时打开十个窗口，让十个模型一起写代码”。

这通常只会得到更多冲突、更大的 PR 和更贵的账单。

真正适合并行的是边界清楚、共享上下文较少、完成条件独立的工作：不同仓库的实现、互不依赖的测试方向、代码与文档、功能与观测，以及对同一方案的独立安全和架构审查。

不适合并行的，是共享接口仍在变化、多人高频修改同一文件、状态机尚未达成共识，或所有任务争抢同一个外部测试账户的场景。

Anthropic 在 多 Agent 研究系统 中发现，并行特别适合可以沿多个独立方向探索的高价值任务，但成本和协调复杂度会明显上升。其 并行 Agent 编译器实验 也说明，真正让多个 Agent 长时间工作的不是一句“互相协作”，而是任务锁、隔离环境、共享进度和强测试 Harness。

图 4：多个执行通道在隔离环境中工作，通过同一组测试门，最后收敛成一个可信制品。

因此，我们更愿意把底层架构理解成三层：

控制层：GitHub Issue、PR、Projects、Checks、审批和状态
执行层：Agent、Skills、Worktree、Container 和 Namespace
反馈层：测试、日志、指标、Trace、扫描和验收证据

gh CLI 贯穿三层：从 GitHub 读取控制意图，调度执行动作，再把反馈证据写回原来的 Issue 和 PR。GitHub 保存长期状态，Agent 只是随时可以替换的执行进程。

模型会不断更强，但真正形成复利的是后两层：它们让今天的模型和明天的模型都能在同一套工程纪律里工作。

人不写更多代码，人负责更贵的判断

当代码产能不再稀缺，人的价值不会消失，只会向更高层移动。

适合交给 Agent 的，是可逆、重复、可观察、能用证据判断完成的工作：搜集上下文、机械实现、重构、测试、文档、隔离环境部署、只读排障、CI 修复和证据整理。

必须由人承担责任的，是产品价值、机会成本、业务语义、领域边界、架构取舍、PR 最终批准、合规风险、探索性测试，以及生产和数据不可逆操作。

图 5：自治边界由风险、可逆性和可观测性决定，而不是由模型是否“显得很自信”决定。

OpenAI 在 Running Codex safely 中强调的也是这个原则：低风险动作在清晰边界内保持流动，高风险动作需要显式批准，并保留足够的遥测用于审计。

最理想的人机协作不是把未经筛选的机器产出直接堆到人面前，也不是“Agent 什么都能做”。Agent 负责多轮交叉审查和证据整理，人始终保留最终 CR 与批准责任。

而是人把一次判断写成规则、测试或 Skill，让这个判断以后不必重复消耗人的注意力。

它真正性感的地方：不再需要人盯

这套流程最迷人的地方，不是凌晨三点还有一个机器人在写代码。

而是第二天早上打开 Issue，你看到的不是一句“已经完成”，而是一组可以快速判断的事实：

• 哪些仓库发生了变化；
• 哪些测试通过，哪些边界仍未覆盖；
• 开发环境在哪里，可以直接打开验证；
• Agent 遇到过什么问题，为什么这样处理；
• UAT 接受的是哪个 Digest；
• 哪些决定需要你做，其他步骤已经走完。

它带来的变化不是单纯的“更快”：

等待被并行化。 前端、后端、测试、文档和环境不再排成一条长队。

上下文不再一路漏水。 Issue 连接意图、实现、证据和结果，新加入的人或 Agent 不必重听一遍故事。

环境变成可以消费的能力。 不再需要排队等某个人“帮忙部署一下”。

测试从最后一道关，变成推进服务。 它持续告诉执行者离目标还差什么。

经验开始复利。 一次排障和评审经验被写进 Skill、文档或规则后，后续每一次执行都会受益。

真正被释放的不是开发人数，而是团队最稀缺的东西：连续、不被打断的判断力。

速度会放大一切，包括愚蠢

这套方法也有一个非常危险的副作用：如果方向错了，它会让团队更快地到达错误的地方。

DORA 的 生成式 AI 对软件开发的影响研究 发现，AI 使用与个人生产力和满意度提升相关，但当代码批次变大、交付基础薄弱时，整体吞吐和稳定性反而可能下降。

原因并不神秘：代码生成快了，评审、测试、环境和决策并没有同步变快，最后只是制造了更大的等待队列。

Martin Fowler 在 关于 LLM 与软件开发的思考 中也提醒，谈论生产力时不能忽略具体工作流。自动补全和一个能读取仓库、修改文件、运行测试的 Agent，根本不是同一种使用方式。

我们需要警惕的风险包括：

• 一个写错的 Issue 被高速实现；
• 假绿测试把错误状态送进下一阶段；
• Agent 复制仓库中已有的坏模式，导致架构漂移；
• 并行任务在共享接口和迁移文件上互相踩踏；
• PR 数量上升，但人的审核能力没有增长；
• 权限过大的 Agent 把一次错误变成系统事故；
• 长上下文、多 Agent 和反复失败让成本失控。

对应的护栏并不新鲜：小 Issue、小 PR、明确非目标、隔离 Worktree 和 Namespace、最小权限、短期凭证、可靠退出码、不可变制品、高风险批准门、全链路日志，以及持续清理技术债。

Agent 时代没有让工程纪律过时，反而让它变得更重要。

别从“自动发布生产”开始

如果下周一就想开始，不需要先建设一个宏大的 Agent 平台。

可以从四条低风险路径动手。

1. 让 Triage 先给建议

让 Agent 提议领域、仓库、优先级、重复项、缺失信息、风险和置信度，但先不自动修改 Issue。观察一段时间后，再开放高置信度标签和路由。

2. 把测试、文档和小缺陷交出去

这些任务边界清楚、结果容易验证，也是暴露仓库缺少哪些文档、命令和反馈能力的最佳训练场。

3. 先打通开发环境

让 Agent 能创建分支、部署开发 Namespace、执行 smoke test、收集截图和日志、生成 PR。这样人收到的不再是一堆未经运行的代码，而是一个可以直接验证的候选结果。

4. 生产先做只读 Preflight

让 Agent 检查目标分支、镜像 Digest、配置差异、数据库兼容性、Kubernetes 状态、告警和回滚条件。它可以提出发布建议，但生产写操作继续由人批准。

共同原则只有一句：

先自动化证据，再自动化决策；先证明反馈可靠，再扩大执行权限。

别数 Token，数等待

如果只统计生成了多少代码、运行了多少 Agent、消耗了多少 Token，我们很容易把忙碌误认为进步。

更值得看的指标是：

• Issue 创建到首次可验证结果用了多久；
• 一项工作在等待环境、等待测试、等待审核上花了多久；
• Agent 一次完成率、重试次数和人工接管比例；
• 每个 Issue 真正消耗了多少分钟的人类操作；
• PR 有多大，经历几轮返工，多久得到审核；
• 自动测试发现了多少问题，又有多少缺陷逃到生产；
• UAT 制品、生产制品和测试证据能否完整追溯；
• Change Failure Rate 和恢复时间是否真的下降。

最终要优化的不是机器产出了多少，而是一个正确想法穿过组织时损失了多少时间和信息。

我们的下一公里

这套交付方式接下来的演进，可以分成三个阶段。

第一阶段：先让工作可读

接入产品文档、客户反馈、CI、监控和安全扫描等工作信号；统一需求、Bug 和基础设施 Issue Schema；用 GitHub Projects 定义状态机，用 Task List 和子 Issue 记录 Plan；版本化架构地图、领域边界和验收方法；要求 PR 关联 Issue 和证据；修复假绿测试；治理共享 Skills。

第二阶段：开放低风险闭环

让 Intake 自动归一化、聚类和合并需求与 Bug，让 Triage 输出理由和置信度；通过 gh 自动回写计划、状态和阻塞项；自动创建隔离分支和开发环境；自动执行单测、API、页面和架构校验；自动生成 PR、多模型交叉审查与部署证据；人完成 CR 和批准后，再自动合并、发布和关闭。

第三阶段：让多个工种按工作图协作

父 Issue 生成跨仓库子 Issue 和依赖图；多个 Agent 共享稳定契约并行执行；测试持续发现缺口；UAT 自动记录不可变 Digest；生产批准后自动验证并回写。

图 6：先建设可读性和可信反馈，再开放自治，最后才扩大 Agent 的范围与并发度。

我们不需要一步跳到“无人软件公司”。每多消灭一次无意义的交接，每多把一个重复判断写成可执行规则，系统就向前走了一步。

软件团队的新形状

代码当然仍然重要。但它会越来越像编译产物，而不是协作中心。

未来真正拉开团队差距的，很可能是这些能力：

• 能不能把模糊想法写成一个值得执行的 Issue；
• 能不能让仓库、环境和业务知识对新的执行者足够可读；
• 能不能用真实测试区分“看起来完成”和“真的完成”；
• 能不能让低风险工作持续流动，而不牺牲高风险决策的责任；
• 能不能把每一次失败重新写回系统，让下一次不必再交同样的学费。

AI 软件开发的未来，并不是人和 Agent 比谁写代码更快。

它更像一家公司终于拥有了第二套神经系统：

人负责感受方向、理解价值、承担责任；机器负责不知疲倦地让工作流向结果。

当一个 Issue 能够自己找到正确的仓库、正确的工种、正确的环境和正确的验证方式时，我们才真正跨过了从“AI 帮我写代码”到“软件系统开始自己推进”的那条线。