KAIzen — AI 时代对敏捷的需求
Source: Dev.to
请提供需要翻译的正文内容，我将按照要求进行简体中文翻译并保留原始的格式、Markdown 语法以及技术术语。
一家游戏公司小团队如何将流效率从 32 % 提升至 85 % —— 通过改变我们提供给 AI 的内容
我们的团队严格按照 Scrum by the book：两周冲刺、需求梳理、计划扑克、回顾。按照所有传统衡量标准，我们都在正确地实践敏捷。
随后我测量了我们的 flow efficiency —— 活跃工作时间与总耗时的比率 —— 结果只有 32 %。每工作一小时，实际有效工作约 19 分钟，其余时间都在等待（等待需求梳理、澄清、评审、对故事实际含义的对齐）。
Industry average for software teams is 15‑25 %.
我们高于平均水平，但 “above average at wasting time” 并不是任何人会放在幻灯片上的指标。
更糟的是，我们开始使用 AI 编码助手。承诺是更快的交付，实际却是更快的 code generation —— 但代码常常出错，因为输入过于模糊。一个用户故事写成 “As a user, I want to receive rewards so that I feel valued”，人类可以据此提出有针对性的问题；而 AI 则会凭借这些信息自信地产生幻觉式的代码。
AI 不仅仅加快了编码，它 moved the bottleneck。
瓶颈不再是 “how fast can we write code?” 而变成了 “how precisely can we define what we want?” 我们的整个流程是为人类是瓶颈的世界而优化的，而那个世界已经不复存在。
我应该诚实地说：当时我并没有把随后发生的事情称作 KAIzen。我们没有给任何东西起名字，只是开始改变工作方式。本文中使用的词汇——Blueprint、Runbook——是后来才出现的，用来让这些模式更易共享。工作是真实的，命名只是事后想的。
灵感——以及我为何需要不同的方案
我并不是从零开始。Amazon 的 AI‑DLC（AI‑驱动开发生命周期）是一个重要的灵感来源。AWS 已经展示了以规范为驱动、AI 增强的开发在大规模下是可行的。但当我尝试将其应用到我的团队时，成本很高：AI‑DLC 要求你替换整个开发流程——新的阶段、新的角色、新的产出物，从头开始全新的工作方式。
我们没有这种余地。我们正处于冲刺中、季度中、交付中。我需要的是一种 可以嵌入现有流程的方案——而不是取代它。在 AI‑DLC 要求你全部改动的情况下，我只想改动一件事：我们输入给 AI 的质量。保持我们的冲刺，保持我们的看板，在上面再加一层。
我现在把这种方法称为 KAIzen，取自 kaizen（改善）——日本的持续改进哲学。小的改变，由实际执行工作的人员主导。KAIzen 将这一原则与 AI 作为杠杆结合起来。不是一种新方法论。不是一次流程大改。是一层可以叠加在任何已有 Agile 流程之上的层。
规范作为主要杠杆
转折点很小。与其编写用户故事，我为一个功能写了详细的工程规范——包括输入、输出、边缘情况、约束、验收标准。我把它交给我们的 AI 助手，生成的代码在第一次就已经可以审查。
之前的那个功能——复杂度相似，描述为用户故事——耗费了三轮审查、两个 Slack 讨论串和一次同步会议。使用相同的 AI、相同的团队。区别完全在于输入。
规范现在就是产品本身。 而不是代码。规范的质量决定了后续一切的质量。
我把这称为蓝图——一种结构化的规范，足够精确以供 AI 构建。对于复杂工作，你还需要一个运行手册——从蓝图衍生的有序实现计划。对于小的修复，轻量级蓝图就足够。
我们如何生成蓝图
- 功能简要 – 产品负责人提供目标、背景、用户需求。
- SpecKit – 我们定制的 GitHub Copilot 代理起草蓝图（包括输入、输出、边缘情况、约束、验收标准）。
- 审查与完善 – 开发者投入实际时间（对复杂功能常常需要两小时）对草稿进行打磨。
草稿并不是最终产物——审查后的蓝图才是。此投入才是关键。精确的蓝图使运行手册连贯，AI 生成的代码可直接审查。代理消除了空白页问题，帮助你完成约 70 % 的工作；开发者的判断填补剩余的 30 %——质量正体现在这里。
随着时间推移，出现了意想不到的变化：我们的产品负责人开始使用同一个代理来撰写功能简要，并对其进行结构化，使后续的蓝图更清晰。整个链条因此更加紧密：
更好的简要 → 更好的蓝图 → 更好的运行手册 → 更好的 AI 生成代码 → 更少的审查循环。
该代理不仅帮助了开发者；它还将整个团队拉向更高的精确度。
什么被解散
我们并没有决定停止使用 Scrum，只是开始在冲刺中编写蓝图（Blueprint）。但有几个仪式自行消失了：
| 仪式 | 发生了什么 |
|---|---|
| Grooming（需求梳理） | 多余——蓝图已经回答了需求梳理本来要提出的所有问题。 |
| Estimation（估算） | 已不再有意义——基于规范的工作本身就已经确定了范围。 |
| Sprint planning（冲刺计划） | 变成了纯粹的优先级排序：“接下来哪个蓝图？” |
| Kanban vs. Scrum（看板 vs. Scrum） | 已无关紧要——我们保留了所需的外层循环（站会、回顾、优先级排序）。内部循环——先写规范、AI 增强——推动了结果。 |
与 AI‑DLC 方法的核心区别在于我们 不需要任何人的许可就可以开始。没有流程大改，没有新角色，没有全组织的认同。一个团队，一个蓝图，一个冲刺。该层通过实际结果而非提案文档证明了自己的价值。
数字
| 指标 | 之前 | 之后 1 | 之后 2 |
|---|---|---|---|
| 流动效率 | 32 % | 47 % | 85 % |
| 周期时间 | 36 天 | 36 天 | 13 天 |
三个史诗，相同领域，类似复杂度——改进不言自明。
活跃工作时间几乎没有变化。 消失的是等待——需求梳理、澄清、对齐的开销，这些在冲刺速度中是看不见的。
注意事项： 三个史诗是一个信号，而非证据。它们的范围并不完全相同。团队规模小，我直接进行辅导。我更希望你直接听到我的这些说明。三个数据点并非证明；它们是值得进一步调查的信号。
我学到的
-
Blueprint 是新的瓶颈——但它是更好的瓶颈。
使用 SpecKit 起草第一稿后，空白页问题消失了。审查仍然需要真实的时间，而且应该如此——因为那是工程判断所在。开发者的工作从 “从头编写规范” 转变为 “验证并完善规范”，这更好地利用了他们的专业技能。 -
并非所有人都想写规范。
只要一次演示，阻力就会瓦解。向开发者展示一个模糊故事生成的 AI 输出与一个优秀 Blueprint 生成的 AI 输出并列。之后，大多数人会去写规范——不是因为流程争论，而是因为这让他们的下午更轻松。 -
这就是 kaizen——从根本上持续改进。
我们改变了一件事，测量了结果，并不断改进。 -
单个团队的局限。
我们的流动效率在自己的领域达到了 85 %。随后，一个跨 Gaming、Rewards 和 Sportsbook 的项目出现，突然我们的速度变得无关紧要。我们被其他团队的 API 阻塞，在 Slack 上争论事件模式，并参加对齐会议——六个人讨论的内容本可以在私聊中由两个人决定。
如果功能在边界卡住，即使一个团队在改进也毫无意义。这是 Part 2。
Part 2: “跨边界的 KAIzen” — 下周发布。
想今天就尝试吗？
- 选择你的下一个功能。
- 将产品简报输入 AI 助手，让它生成规范——包括输入、输出、边缘情况、约束、验收标准。
- 对其进行完善。
- 基于该规范进行构建。
- 测量前后你的流动效率。
一个规范。看看会发生什么。
#ai #agile #softwareengineering #productivity