30 分钟掌握 Software Delivery Lifecycle

Primer

① 先把后文会反复出现的词认清楚

规则：先知道术语是什么，再用它们做综合判断。卡片收起时就能看到一句话直觉；需要严格定义、边界和案例作用时再展开。

先认词：这一课不把术语当成一排缩写。每个词都按“直觉 → 严格定义 → 当前案例 → 边界”展开；先建立这些最小概念闭包，再讨论 AI Coding 时代怎样把人从重复点击中解放出来。

AI Agent · 人工智能代理能围绕目标连续读取状态、调用工具、修改产物、运行检查并整理证据的自动执行者。

直觉: 它不是“更会聊天的搜索框”，而像一个能接任务、查资料、改代码、跑命令、根据结果继续行动的数字同事。
严格定义: 在工程上下文里，AI Agent 通常由模型、上下文、工具接口、状态记录和停止条件组成；它根据当前观察选择下一步动作，并把外部工具返回的结果重新纳入决策。关键不是“会生成文字”，而是能形成多步的 observe → act → verify 循环。
当前案例: 在软件交付中，Agent 可以先读需求和验收标准，再修改代码、运行测试、抓浏览器证据、整理失败原因和候选摘要；人不需要陪它逐个点击按钮。
边界: Agent 的自述不是独立证据。它可能误读目标、漏测边界或错误解释日志，所以关键结论仍要绑定可复现测试、构建产物、浏览器读回或有权主体的验收。

Software Delivery Lifecycle · 软件交付生命周期一项软件改动从意图和需求，经过实现、验证、构建、验收、发布，到运行反馈与恢复的完整路径。

直觉: 写完代码只是“做出零件”，Delivery Lifecycle 关心的是这个零件怎样被证明可靠、被正式接收、送到线上，并在出问题时能被发现和恢复。
严格定义: 它是一组跨阶段状态转换与证据累积过程：需求定义可验收条件，实现产生候选变化，验证建立技术证据，构建形成不可变产物，验收完成授权，部署改变运行环境，观测与恢复闭合线上反馈。它比某一条 CI 脚本或部署命令更上位。
当前案例: 当你问“前端小改要不要 Docker”“Playwright 什么时候跑全量”“谁来点最终确认”，都应该先判断当前改动处于生命周期哪个阶段，而不是把所有步骤塞进一条重流水线。
边界: 不要把 Software Delivery Lifecycle 和 Software Development Life Cycle 完全等同。后者常覆盖需求、设计、开发、维护等更广的软件生命周期；前者更聚焦“怎样把变化可靠地交付为运行结果”。

Feedback Loop · 开发反馈循环从“做了一次修改”到“得到足以判断这次修改对不对的反馈”所经历的闭环。

直觉: 你改一个按钮文案，如果两秒后就能看到页面，错误很便宜；如果每次都要等十分钟 Docker build，开发者就会减少验证次数，错误反而更容易积累。
严格定义: 可把单次反馈成本抽象为 T_feedback = T_prepare + T_execute + T_observe + T_decide。日常工程优化的目标不是让所有验证都消失，而是让当前改动只支付“足够证明它”的最小成本，同时保留后续更重的候选和发布门禁。
当前案例: 前端样式修改优先走 HMR；接口映射改动跑定向 API/浏览器测试；只有进入候选或发布时才扩大到 production build、完整 E2E 和部署读回。
边界: 反馈快不等于证据强。一个页面即时刷新只能证明开发态的局部行为，不能自动推出生产构建、跨浏览器、权限、数据库迁移或线上部署正确。

Hot Module Replacement (HMR) · 热模块替换开发服务器只把发生变化的前端模块替换进正在运行的页面，而不是每次整体重启或重新构建发布包。

直觉: 像机器不停机，只换掉刚改动的那个零件；因此你保存代码后能很快看到界面更新。
严格定义: HMR 依赖开发服务器维护模块依赖图，检测源码变化后重新转换受影响模块，并通过开发连接通知浏览器替换模块。框架还可能在模块边界上保留组件状态，但状态是否保留取决于具体实现。
当前案例: React/Vue/Vite 日常 UI 开发可以一直保持 dev server 运行，让 AI 或人快速验证页面、文案和普通交互，不需要每次生成生产静态包或 Docker 镜像。
边界: HMR 是开发反馈机制，不是发布证明。构建配置、tree-shaking、生产环境变量、服务端嵌入、目标平台 Runtime 等问题仍要在更高层验证。

Smoke Test · 冒烟测试用少量最关键检查快速判断系统有没有“基本活着”，以及主路径是否发生明显破坏。

直觉: 先启动机器闻一闻有没有冒烟；不是拆开每个零件检查，而是先判断值不值得继续做更细验证。
严格定义: Smoke Test 是覆盖面窄、成本低、失败信号强的一组测试，通常选择启动、健康接口、登录入口、关键 API 或主页面等最低生存条件。它常位于更完整回归测试之前。
当前案例: AI 改完页面后可以先确认 dev server 可访问、关键路由 200、核心 API 返回基本结构，再决定是否运行定向 Playwright 或完整候选验证。
边界: 冒烟测试通过只说明“没有立刻发现致命问题”，不能推出边界条件、权限矩阵、异常路径和跨组件一致性已经验证。

Quality Assurance / Verification (QA) · 质量保证 / 技术验证用可复现检查和证据验证预先定义的技术条件是否成立。

直觉: QA 回答的是“我们约定要检查的技术条件，机器和证据是否真的证明它们通过了”。
严格定义: Verification 更强调“产物是否符合规格和合同”，QA 是更广的质量活动集合，可包含单元测试、集成测试、静态分析、契约检查、安全检查、浏览器测试、构建验证和结果审计。关键特征是标准预先定义且结果可重复。
当前案例: 在 AI Coding 流程中，Agent 可以执行大量 QA，但证据最好由独立命令、CI、测试报告、截图或结构化 payload 产生，而不是只保留 Agent 的自然语言结论。
边界: QA 通过不等于 Acceptance。前者证明“条件通过”，后者还涉及“谁有权接受、风险是否可承担、这个具体候选是否被授权进入下一阶段”。

End-to-End Testing (E2E) · 端到端测试从真实或接近真实的用户入口出发，跨越多个组件验证一条完整业务链路。

直觉: 单元测试像测发动机零件，E2E 是把整辆车从起点真的开到终点，观察前端、网络、后端和数据能否协同工作。
严格定义: E2E 测试通常跨越浏览器/UI、网络请求、鉴权、应用服务和持久化等多个边界，以最终用户可观察结果作为断言。它覆盖真实集成风险更强，但运行更慢、环境依赖更多、失败定位成本也更高。
当前案例: 例如测试“普通用户登录 → 创建记录 → 页面读回 → 权限正确”，就比只测一个 React 组件或单个 API 更接近真实业务闭环。
边界: E2E 不应该替代所有低层测试。若把每个小逻辑都塞进浏览器全链路，反馈会变慢且失败难定位；更合理的是测试金字塔/测试分层与风险驱动选择。

Release Candidate · 发布候选准备进入最终验收或发布的一个冻结对象，通常绑定确定 commit、构建产物和对应证据。

直觉: 它像“送审稿”：不是随时还在变化的工作区，而是一个可以明确回答“我们正在验哪一版”的对象。
严格定义: Release Candidate 应具有稳定身份，例如 source commit SHA、artifact digest、配置版本和验收证据集合。候选形成后，若继续修改代码或重新构建出不同字节，应视为新的候选并重新计算受影响验证。
当前案例: AI 完成开发与 QA 后，把 commit、Docker image digest、测试报告、迁移状态和已知风险打包成候选，人类验收的是这个具体对象，而不是“最新代码”这种不断漂移的概念。
边界: 候选不等于已发布，更不等于已验收。它只是把对象冻结下来，让后续 Acceptance 和 Deployment 有明确指向。

Acceptance · 验收接受有权主体基于验收标准和证据，对一个明确候选作出接受或拒绝的治理决定。

直觉: 机器可以把检查做完，但“这版可以进入下一阶段吗”最终是一个带权限和责任的决定。
严格定义: Acceptance 至少需要验收对象、验收标准、证据、决策主体和结果记录。它把技术验证转换成组织授权，例如 ACCEPTED / REJECTED，并让后续发布能够追溯“谁基于什么证据接受了哪一版”。
当前案例: 如果 AI 已经跑完 200 个可重复检查，人类不需要重新点 200 次；更合理的是复核高风险语义、证据完整性和例外项，再对候选 payload 作接受决定。
边界: Acceptance 不是“随便看两眼觉得行”，也不是 QA 的同义词。它尤其不能在候选对象发生变化后继续沿用旧的接受记录。

User Acceptance Testing (UAT) · 用户验收测试从业务用户或真实使用者视角验证软件是否满足约定用途和业务验收条件。

直觉: 技术测试可能证明按钮能点、接口能回，但 UAT 更关心“业务人员按真实工作方式使用时，这是不是他们真正要的东西”。
严格定义: UAT 通常基于业务场景、角色、规则和可接受结果执行，关注需求语义和使用目标，而不是只检查内部实现。它可以由真实用户、产品负责人或被授权的业务代表参与。
当前案例: 例如运动训练 SaaS 中，测试“教练发布训练 → 运动员收到 → 反馈 → 教练复核”的业务闭环，比单测一个 API 更接近 UAT。
边界: UAT 不等于把所有技术测试再人工执行一次；性能、安全、边界输入、浏览器兼容等仍应主要由专业 QA 和自动化覆盖。

Continuous Integration (CI) · 持续集成代码变化被频繁集成到共享主线，并由统一自动化检查尽早验证兼容性和质量。

直觉: 不要让每个人在自己的分支里攒一个月再一次性合并；小步集成、持续检查，冲突和错误会更早暴露。
严格定义: CI 通常围绕共享版本库触发自动构建、测试、静态分析、契约检查等门禁，使每次候选变化都能获得一致的验证环境和结果。核心价值是降低集成风险，而不是某个具体 CI 平台。
当前案例: Agent 本地声称测试通过后，远端 CI 再在干净环境重跑关键门禁，可以发现本机缓存、未提交文件、环境变量或依赖漂移造成的假阳性。
边界: CI 不等于 CD，也不自动部署生产。CI 的主要问题是“变化能否安全集成”，不是“是否已经获得发布授权”。

Continuous Delivery / Deployment (CD) · 持续交付 / 持续部署把通过验证的变化持续推进到可发布状态；若进一步自动进入生产，则属于持续部署。

直觉: Continuous Delivery 是“随时可以可靠上线”，Continuous Deployment 是“满足规则后自动上线”。两者自动化程度相近，但最后一道发布门不同。
严格定义: 持续交付通过标准化构建、环境推广、配置管理和验收门，让候选稳定地到达“可发布”状态；持续部署则把生产部署也纳入自动状态转换。两者都要求过程可重复、可追溯、可恢复。
当前案例: 低风险文档站可以在主线门禁通过后自动部署；支付、数据库高风险变更可以保留人工 Acceptance，再由同一候选 artifact 推进生产。
边界: CD 不是“所有东西必须无人值守”。风险越高，越可能保留授权门；但即使有人工门，也应避免手工拼装和不可重复部署。

Artifact · 构建产物从确定源码和构建过程产生、可被版本化和部署的具体输出，例如镜像、二进制或静态站点包。

直觉: 源码是菜谱，Artifact 是已经做出来、准备端上桌的那盘菜；部署的是后者，不是抽象的 Git 分支名。
严格定义: 理想 artifact 具有不可变身份，例如文件哈希或容器 image digest，并能追溯到 source commit、构建环境和依赖版本。这样验收对象与部署对象之间可以建立明确映射。
当前案例: 若候选 Docker 镜像已经通过测试和验收，生产环境应部署同一个 digest，而不是上线前重新在服务器执行一次 build，产生可能不同的新镜像。
边界: Artifact identity 只证明“这是同一份字节”，不自动证明它业务正确；仍需 QA、Acceptance 和运行读回形成完整证据链。

Observability · 可观测性通过日志、指标、追踪和业务信号，从系统外部输出推断内部运行状态与故障位置的能力。

直觉: 上线后不能只问“进程还在不在”，而要能回答用户是否成功、哪里变慢、哪类请求失败、问题从什么时候开始。
严格定义: 工程可观测性通常结合 logs、metrics、traces 与业务 SLI，通过可关联的请求 ID、版本信息和时间序列把症状映射到组件、依赖和发布事件。它强调能从输出解释系统状态，而不仅是收集很多日志。
当前案例: 一次发布后，AI 可以对比错误率、延迟、关键 API 成功率和版本标签；若某个指标越过阈值，再把证据交给人决定是否继续观察或回滚。
边界: 有日志不等于有可观测性。若日志没有版本、请求关联和关键业务信号，数据很多也可能无法快速定位问题。

Rollback · 回滚当新版本造成不可接受风险时，把运行系统恢复到已知安全状态的受控恢复动作。

直觉: 发布不是只能向前冲；真正可靠的交付系统还要准备一条“出问题时怎么快速回到安全位置”的路。
严格定义: Rollback 可以表现为切回旧 artifact、恢复旧配置、流量回切或执行兼容的数据恢复策略。是否可回滚取决于状态变化是否可逆，尤其数据库 schema、数据迁移和外部副作用可能让简单二进制回退失效。
当前案例: 若新镜像上线后错误率异常，部署系统可把流量切回上一个已验收 digest；如果本次还做了不可逆数据迁移，则必须按预先设计的恢复方案处理，而不是只重启旧容器。
边界: Rollback 不是所有故障的万能按钮。没有向后兼容 schema、备份或幂等外部操作时，代码版本回退并不能自动恢复业务状态。

我能用自己的话解释 AI Agent、Software Delivery Lifecycle、Feedback Loop、HMR、Smoke Test、QA/Verification、E2E、Release Candidate、Acceptance、UAT、CI、Continuous Delivery/Deployment、Artifact、Observability 与 Rollback，并说清它们各自证明什么、不能证明什么。

Orient

② 现在再看这段材料到底在说什么

一句话本质：软件交付生命周期（Software Delivery Lifecycle）描述的是一项软件改动怎样从“想法/需求”一路变成“可安全运行、可追责、可回滚的线上结果”。它关心的不只是写代码，而是整条交付链路：实现、验证、构建、验收、发布、部署、观测与恢复。

AI Coding 时代最重要的变化：过去人类常常既写代码、又点页面、又看日志、又跑命令。现在应把可重复、可机器判定、可留证的工作尽量交给 AI Agent + 自动化工具，让人把注意力放在需求语义、风险边界、验收授权和异常决策上。

上位概念

软件工程（Software Engineering）：用系统化方法设计、构建、验证、交付和维护软件。

当前概念

Software Delivery Lifecycle：从可执行需求到可运行版本，再到运行反馈与恢复的端到端交付过程。

下位机制

开发反馈循环、质量保证、构建打包、持续集成、持续交付/部署、发布治理、可观测性与回滚。

容易并列混淆

Software Development Life Cycle 往往覆盖需求、设计、开发、测试、维护等更广生命周期；CI/CD Pipeline 则只是 Delivery Lifecycle 中的一组自动化机制。

学习依赖：Git / 分支 + 测试基本概念 + 开发/测试/生产环境 → Software Delivery Lifecycle → CI/CD、Release Engineering、Site Reliability Engineering、Platform Engineering。

我已经能区分：开发反馈、QA 验证、人工验收、发布部署不是同一件事。

Connect

③ 概念关系与最小知识闭包

把交付过程看成一条证据不断增加、自由度不断减少的状态链。越靠后，越不能“随便改一下再说”。

读图重点：AI 应尽量覆盖 A 与 B；人类在 C 层承担“是否接受这个具体候选”的权责，而不是重复做 A/B 已有的机械检查。

状态机

可以把交付抽象成：DRAFT → IMPLEMENTED → VERIFIED → CANDIDATE → ACCEPTED → RELEASED → OBSERVED。任何一步失败都回到前一安全状态，而不是靠口头解释跨级。

一个核心谓词

只有当“代码证据通过 + 验收合同满足 + 风险门禁满足”时才允许发布：

release_allowed = qa_ok ∧ contract_ok ∧ risk_gate_ok

三个不变量

① 验收必须绑定具体 commit；② 验收的 artifact 就是部署的 artifact；③ 每个上线动作都有可观测证据和恢复路径。

这也是 AI Coding 的工程化边界：AI 可以非常擅长生成实现和运行检查，但“什么叫正确、哪些风险必须由谁承担、什么版本被正式接受”必须被合同化、证据化和授权化。

Reconstruct

④ 把真实案例重新还原

假设 AI Agent 收到一个真实 Web 管理端任务：新增“删除用户”能力，修改前端页面、后端 API、权限判断和一条数据库 migration。你不希望自己每改一次就手点 20 个页面，于是把交付拆成三层。

Layer A · 日常开发反馈：不需要先做生产构建

环境

隔离数据库 + 本地/测试 API + Vite dev server / HMR。Docker 不是目的；只要依赖可控、数据隔离、服务可复现，就可以选择更轻的启动方式。

AI 自动做

改代码 → 跑定向 unit/integration → API smoke → Playwright 验证关键路由 → typecheck/lint → 读取失败证据 → 自动修复再重跑。

人的动作

通常不点。只在需求语义模糊、视觉主观判断、危险权限边界等机器不容易判定的地方介入。

需求 / AC
  ↓
AI 修改代码
  ↓
Dev Server + HMR
  ↓
API smoke + targeted tests + Playwright
  ↓
失败 → AI 修复 → 重跑
  ↓
通过 → 形成候选

Layer B · 候选验证：准备提交或发布时才跑“重流程”

这里追求的不是最快，而是完整、可复现、可留证。典型门禁包括：完整测试、生产构建、migration 验证、跨租户/权限测试、静态检查、依赖/安全检查、OpenAPI 或 schema 漂移检查、构建产物摘要。

关键原则：开发时可以“不构建就看效果”；但正式候选必须证明“生产构建真的能出来”。这就是开发反馈与发布证明分层。

Layer C · 发布与验收：人类完成闭环，而不是人工复测一遍

AI/CI 给出结构化证据：候选 commit、artifact digest、测试矩阵、失败为 0、风险项、已知限制、回滚版本。人类只需要对验收对象和风险作判断，并留下 ACCEPTED / REJECTED。

适合 AI

重复点击、回归测试、截图比对、接口 smoke、日志检索、权限矩阵、构建、部署 smoke、证据汇总。

适合人

需求是否真的满足业务、危险写操作是否可接受、视觉/体验是否达标、例外风险是否接受、最终授权。

我已经能把一个 AI Coding 任务拆成日常反馈层、候选验证层、发布验收层。

Map

⑤ 概念如何映射到现实

你看到的工程动作	在 Delivery Lifecycle 里的位置	默认谁做	为什么
Vite / UniApp dev / Flutter hot reload	开发反馈层	AI 启动与使用；人按需观察	目标是快速验证改动，不是发布证明。
API smoke / unit / integration	开发反馈 + 候选验证	AI / CI	高度可重复、机器判定明确，人工重复执行没有价值。
Playwright 关键路由验收	开发反馈 + 自动 QA	AI / CI	浏览器点击本身可以自动化；人只看异常证据和高风险语义。
生产 build / bundle / migration	候选验证层	AI / CI	重，但必须在候选阶段证明生产路径可用；不应每次小改都跑。
人工 UAT / Acceptance	发布验收层	有权的人	不是重复 QA，而是确认业务语义、风险、证据和授权。
Release / Deploy	发布执行层	流水线为主	应可重复、可追踪、可回滚，避免人工 SSH 点击和手抄命令。
Smoke / metrics / logs / rollback	运行反馈层	AI 监测，人处理越界风险	上线不是终点；健康必须通过真实运行证据确认。

QA、验收、开发环境工程、发布流程到底分别属于哪里？

开发环境工程

解决“怎么低成本得到反馈”：dev server、HMR、Mock/Proxy、隔离数据库、本地 API、测试数据、可复现依赖。

QA / Verification

解决“怎么证明技术条件成立”：测试策略、测试金字塔、E2E、契约、静态分析、安全检查、证据。

Acceptance

解决“谁有权宣布这个候选满足验收合同”：UAT、acceptance criteria、审批、签字/记录、风险接受。

Release / Deployment

解决“怎样把已接受的 artifact 稳定送到目标环境”：CI/CD、发布策略、灰度、回滚、观测。

真正该减少的“点击”：人肉逐页面回归、人肉重复跑命令、人肉看每条日志、人肉复制构建包、人肉 SSH 部署。不该减少的，是对目标、风险、责任和最终接受的判断。

Attempt

⑥ 现在把它当成一道题

1场景：AI Agent 已完成一个“管理员删除用户”的前后端功能。它在开发环境里通过了 18 个 unit/integration tests、API smoke、6 条 Playwright 路由，并且 typecheck/lint 全绿。一个同事又手动点了 12 个页面，说“看起来没问题”。但是目前还没有跑生产 build、migration 演练、跨租户权限测试，也没有生成可绑定 commit 的候选 artifact。

问题：你现在是否应该让这个版本直接上线？请设计一条合理的 Software Delivery Lifecycle，至少回答四点：

哪些检查留在日常快速反馈层？
进入候选前必须再补哪些自动化证据？
人类最终应该验什么，而不是重复点什么？
部署后怎样证明“真的安全”，以及失败如何恢复？

你的作答

我已经完成自己的第一版作答，再进入提示。

Hint → Answer

⑦ 分级提示，最后就是实际答案

Hint 1 · 方向

先不要按“测试多不多”判断。把问题拆成三个目标：快反馈、候选证明、发布授权。现在已有证据大多只覆盖第一个目标。