AI-native 工程全链路：意图可验证、产物可审计、人仍握合并与上线权
公开实践整理：Discovery→Release→Ops 全链路、门禁顺序与 CO（人机卡点）；工具可换，验证顺序不乱。
AI-native 工程，是把整条研发链做成「意图可验证、产物可审计、人仍握合并与上线权」的系统。
工具可以替换，门禁顺序保持稳定：先写清 Spec 与可执行验证，再生成代码，再做独立审查，最后由人批准合并与上线。真正拉开差距的，是治理与制品——意图能否被验证、产物能否被审计、合并与上线是否仍由人握着。
图里分成三段：上游意图（Discovery → PRD → Spec＋仓规 → Plan）、构建与验证环（Coding⇄Test → Security → CR∥CI → Preview）、人握权的发布段（Merge → Release → Ops → Incident）。右侧的 CO（Change Ops，人机卡点）贯穿全程。
门禁顺序
先写清 Spec 与可执行验证，再生成代码；独立审查通过后，由人批准合并与上线。工具可以换，验证顺序保持稳定。
本文是公开实践整理，给团队对照自己的流程用。海外渠道请用英文版：AI-native Engineering Pipeline。它和七月那篇《AI Native 工作流》互补：那一篇拆人和 AI 的职责边界，这一篇把门禁、产物和卡点落到 Discovery 到 Ops 的整条链上。
全链路顺序
Discovery → PRD → Spec＋仓规 → Plan → Coding⇄Test → Security → CR∥CI → Preview → Merge → Release → Ops → Incident／回写，CO 贯穿全程。
Coding 与 Test 常常交织：写一小段就跑对应测试，测试失败再改。CR（代码审查）与 CI（持续集成）常常并行：一边有人看 diff，一边流水线跑构建、测试和扫描。Discovery、Evals（评测集）、Incident 可以按场景出现，篇幅紧时可以收成侧栏；「先验证再生成」这一条不要倒过来。
环节、产物与常见机制
| 环节 | 流程产物 | 常见工具／机制 |
|---|---|---|
| Discovery | 调研笔记、约束与竞品要点 | 公开检索、Notion／Issues 备忘 |
| PRD | 短愿景、用户、成功标准 | Notion／Linear／GitHub Issues；GenAI 产品旁挂 Evals |
| Spec＋仓规 | 可验证 Spec、Always／Ask／Never、AGENTS.md／rules | GitHub Spec Kit、仓内 Markdown、Osmani 六块仓规 |
| Plan | 任务拆解、触及文件、风险 | Claude Plan Mode、Cursor Plan、Agent 只读会话 |
| Coding⇄Test | 小分支 PR、单测／契约／关键 E2E | Cursor／Claude Code／Copilot；Jest／Vitest／Playwright；Agent 跑全套 |
| Security | 依赖／幻觉包／密钥边界 | 依赖审计、secret scan、权限白名单 |
| CR∥CI | Diff 审＋必绿门禁 | 另一模型审＋人 Approve；Actions／GitLab CI／CircleCI |
| Preview | 可点预览环境 | Preview／Staging 自动部署 |
| Merge／Release | 合入与上线 | 人 Approve；生产仍由人点 |
| Ops | 日志、告警、回滚 | 既有观测栈；dry-run／熔断／Red Button（大厂参考） |
| Incident／回写 | 复盘、规则与 Spec 更新 | Postmortem 页＋回写仓规／文档 |
| CO（贯穿） | 卡点、停权、变更叙事 | PR 模板、交付链、GitLab Human Checkpoints |
表里的工具只是常见例子。换编辑器、换 Agent、换 CI 品牌都可以；换完之后，产物仍要能验证，卡点仍要能审计。
总论：流程围着 Agent 重设计
GitLab 的 AI-Native Engineering Playbook 把这条路写得很清楚：先找真正拖慢交付的瓶颈，再改流程，再划人机分工，再让仓库与上下文能被 Agent 使用，再验证产物，最后把权限和证据留下来。
Uvik 在 What Does AI-Native Mean? 里强调，差别落在治理与制品上。团队把精力挪到意图、约束和评审，比追新模型更稳。Thoughtworks 在 Claude Code Radar 里提醒两件事：对 AI 写出的代码保持警惕，同时把 context engineering 和共享指令做成仓库资产。
围着 Agent 重设计流程，不等于把合并键交给模型。Agent 负责扩执行面；人负责方向、约束、验收，以及合入与上线。
PRD：先把意图写到 Agent 不用猜
公开资料里，独立成篇的「AI PRD」模板并不多。实务上更常见的做法，是先写一段短愿景——目标、用户、成功标准——再扩成可验证 Spec。Addy Osmani 的 How to Write a Good Spec for AI Agents 和 GitHub Spec Kit 都走这条路。
票面要写到 Agent 不用猜：用户是谁、做成什么样算成功、哪些约束不能破、哪些文件可以动。Uvik 把这一点写成「把工作写清楚，让 Agent 接得住」。
如果产品本身是 GenAI，可以旁挂 Evals。Martin Fowler 等人的 Emerging Patterns in Building GenAI Products 讲的是如何做 AI 产品；写业务代码时，评测集只作旁挂参考，用来卡住回答质量，业务代码仍靠下面的 Spec 与测试合同验收。
Spec 与仓规：证据最厚的一环
Spec 按合同来写。Razorpay 的 Spec-first 列了最低字段：目标、触及文件、步骤、可执行验证、Done。Augment 的 Spec-Driven Development 再补六要素：期望结果、范围内与范围外、约束、已定决策、任务拆解、验证方式。
Osmani 把仓级规则拆成六块：Commands、Testing、Structure、Style、Git、Boundaries，并且要求写清 Always／Ask first／Never。AGENTS.md、Cursor rules、Claude 指令，都是这块的落点。规则越具体，Agent 越容易遵守；规则越像口号，越容易被忽略。
Spec Kit 把门控写成一条链：Constitution → Specify → Clarify → Plan → Tasks → Implement。GitLab 的 Human Checkpoints 提醒：主卡点往往落在计划与意图阶段。写码之前把「做什么、不做什么、怎么验收」钉住，后面的生成才有合同可对。
实践原则
每个交给 Agent 的任务都要有输入、输出、约束和验收标准。没有验收标准的任务，生成得越快，返工越快。
Coding、Test、Security、CR
Plan 宜先只读：让 Agent 列出触及文件、风险和验证命令，人确认后再打开写权限。Coding 保持小 diff、限制可写文件，禁止 Agent 自主合入生产。Osmani、Razorpay、Uvik 和 Cursor 的 Reviewing and testing 都指向同一组约束。
生成与验证的角色宜分离。同一次会话里「你写完再自己宣布通过」，很容易互相迁就。Augment 和 Google SRE 谈 AI 运维 都建议：生成的一方与验收的一方分开，证据才能站得住。
测试就是合同。跑全套单测、类型检查和 lint；关键路径再加契约测试或 E2E。GitHub 的 Review AI-generated code 特别提醒：要防 Agent 为了「变绿」删测试、放宽断言或跳过失败用例。
Security 卡在 Coding 与 CR 之间，CI 再兜底。这一段至少看三件事：依赖是否真实存在（防幻觉包）、密钥有没有进仓、权限是否超出白名单。幻觉包指模型编造出仓库里并不存在的依赖名；它一旦写进清单，安装源被掉包的风险会跟着上来。
CR 把机械项前移到 lint、types 和扫描，把人的时间留给行为、权限和数据兼容。再用另一会话或另一模型做独立审查，对照验收标准看 diff 和测试证据。GitLab 的 Verify what agents produce 和 CircleCI 的 AI-driven SDLC 都观察到：生成变快之后，瓶颈会移到评审。评审跟不上，未审风险只会堆得更快。
CI、Preview、Merge、Release
确定性门禁仍保持权威。CD Foundation 在 Engineering Trust in AI-Native CI/CD 里写得很硬：构建、测试、扫密的结果，不能被模型输出改写。Agent 可以解释失败、提议补丁；绿灯仍由流水线给出。
Preview 可以抽成合入前的半步：自动部署一个可点的预览环境，让产品和审查者看真实行为，而不只看 diff。合入与上线仍由人点。CircleCI 提醒验证环必须跟得上生成速度；验证慢、生成快，队列里会堆满「看起来能合、实际上没人看完」的 PR。
Ops、Incident 与贯穿全程的 CO
运维侧可以参考 Google SRE 的透明、实时风险和渐进授权，以及 dry-run、熔断、Red Button。这些材料偏超大厂语境。中小团队应把它们当作参考上限：先保证日志、告警和回滚能用，再按风险逐步授权，避免一上来写成已经普遍高自治。
事故发生后，复盘要写回 Spec 与仓规。只写一份 postmortem、仓库规则原样不动，下一次 Agent 仍会踩同一个坑。回写完成，这条链才闭环。
CO（Change Ops）是贯穿全程的人机卡点：按风险预设「必须停下来问人」的位置，规则进仓，并保留 Spec → Plan → PR 的审计链。GitLab、Uvik 和 Spec Kit 都把卡点写成流程资产。谁批准了什么、依据哪份 Spec、哪次 CI 变绿，事后都能翻出来。
证据强弱与提速叙事
公开材料的厚度并不均匀，写稿和落地时都值得诚实对待：
| 环节 | 公开证据 |
|---|---|
| Spec／Coding／CR | 强 |
| CI/CD | 中 |
| Ops | 强，但偏超大厂 |
| PRD／CO | 弱，需团队自行拼装 |
关于「用了 AI 就会更快」：公开叙事存在矛盾。有报告给出大约 +55% 的提速，也有熟手场景给出大约 −19% 的减速。这两个数字适合当作警示：生成行数上升，不等于交付变快；评审、返工和事故回写都要算进总时间。把它写成口号，会把门禁谈判成「为了速度可以先跳过」。
相关阅读
- English edition: AI-native Engineering Pipeline
- AI Native 工作流：从想法到上线的协作方式
- AI Coding 项目初始化：从空目录到可协作仓库
- AI 代码审查实践：如何让模型帮你发现真实问题
- AI 产品交付流程：从 Demo 到可持续迭代
- Human-in-the-loop：Agent 什么时候必须停下来问人
参考资料
- The AI-Native Engineering Playbook (GitLab)
- Build human checkpoints into the workflow (GitLab)
- Verify what agents produce (GitLab)
- What Does AI-Native Mean? (Uvik, 2026-10-08)
- How to Write a Good Spec for AI Agents (Addy Osmani / O’Reilly, 2026-02-20)
- Spec-first / agentic-loop design (Razorpay AI Playbook)
- Spec-Driven Development Quickstart (GitHub Spec Kit)
- What Is Spec-Driven Development? (Augment Code)
- Reviewing and testing code (Cursor)
- Review AI-generated code (GitHub Copilot Docs)
- The new AI-driven SDLC (CircleCI, 2025-10-10)
- Engineering Trust in AI-Native CI/CD (CD Foundation, 2025-09-26)
- AI in SRE: How Google is Engineering Reliable Operations
- Claude Code — Thoughtworks Technology Radar
- Emerging Patterns in Building GenAI Products (Fowler et al., 2025-02)
结论
AI-native 工程是一条可验证、可审计、人仍握权的系统。工具会换；门禁顺序与人机卡点，值得先写进仓规，再交给 Agent 去扩执行面。
讨论
继续讨论这篇笔记
有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。
AI-native Engineering Pipeline: Verifiable Intent, Auditable Artifacts, Humans Hold Merge and Release
Public practice notes covering Discovery through Release and Ops, gate order, and human checkpoints (CO). Tools can change; the verification order stays.
Agent 工作流模式：先别急着做 Autonomous Agent
梳理 prompt chaining、routing、parallelization、orchestrator-workers、evaluator-optimizer 和 autonomous agent 的适用边界。