需求开发工作流程CodeNarrator v2.3 · 需求开发工作流教程 · 最后更新 2026-08-03一、这篇教程解决什么问题一句话定位一套从模糊想法到规格冻结的需求开发流程用真实项目CodeNarrator v2.3的完整过程做全程案例。需求开发最常见的失败不是想不到而是想乱了症状典型表现讨论不收敛同一个概念改了又改、反复横跳十几轮下来还是模糊文档漂移多份规格文档各自演化对同一规则说法互相矛盾UI 反推架构看到某个界面想做 → 反推需要什么状态 → 状态膨胀 → 架构失控范围蔓延“文档写了就必须做”未来能力被提前实体化本教程的方法不是发明出来的是 CodeNarrator 从 v1 失败到 v2 规格冻结的真实过程中长出来的——每一步都有实际案例包括一次真实的事故教学。跳读指南只想跑流程 → 十一、速查卡15 步检查清单 模板想理解原理 → 二、原理速览只想看坑 → 十、常见失败模式想按步骤复刻 → 从 三、第 1 步 顺序读阅读前提无硬性前置。案例引用的规格文档在项目根/docs/下参考文献不读原文也能跟上读了收获更大。读完能得到什么四层规格模型意图 / 行为 / 状态 / 交互——防止 UI 驱动架构讨论协议提案 → 确认 → 冻结——让讨论收敛变更治理登记表 一致性审计——防止文档漂移一套可复用的模板速查卡二、原理速览需求是可逼近的三句核心信念全部来自实战1. 需求不是一次想清楚的是靠提案 → 确认 → 重做循环逼近的。这条循环不仅适用于产品内容也适用于需求本身——与精益开发的Build-Measure-Learn循环同构The Lean Startup, Eric Ries先验证最小假设再谈扩展。CodeNarrator 的 v1 死因之一就是全自动一次生成——把自动化当成质量来源。v2 把同样逻辑用在需求上定位方案从全自动编译器反复收敛到人机协作创作 IDE中间经过十几轮辩论第 3 步。2. 问题先行。每个新概念先问它解决哪个具体问题答不上来就删。从问题出发的讨论会收敛从名词出发会膨胀——这是全程最值钱的一条原则。3. 分层是防失控的关键。把为什么做 / 发生什么 / 如何记录 / 如何展示分成四层单向依赖方案书产品意图为什么做 ↓ UserWorkflow用户行为发生什么 ↓ Runtime-State系统契约如何记录 ↓ UI-Interaction交互映射如何操作观察依赖方向单向UI 不得反向修改上层。四层的完整定义与越权信号见 四、第 2 步。为什么分层能救需求失控CodeNarrator v1 的失败归因里有一条——约 70% 代码投入在怎么跑状态机 / GUI / API / workspace 管理只有约 20% 在产出什么。分层让每个问题在正确的层里被讨论v1 的工程抢戏本质上就是分层缺失。三、第 1 步需求剖析与问题定义做什么竞争研究有没有人做过、做对了什么、缺什么CodeNarrator 研究了 50 竞品覆盖 7 个类别失败归因重构项目必须回答旧版本为什么失败且要有证据v1 归因出 5 条根因每条带证据定位一句话为谁解决什么问题“面向技术创作者的内容创作 IDE——Cursor 是代码 IDECodeNarrator 是技术表达 IDE”明确不做清单至少 5 项v2 的不做无人值守全自动 / 不做多平台量产 / 不做 API 服务化 / 不做多用户 / 不做真人配音需求开发启发 → 分析 → 规格化 → 验证本身就是需求工程的标准流程IEEE/ISO/IEC 29148:2018——上面的 4 项是它的轻量版启发竞争研究→ 分析失败归因→ 规格化定位 不做清单→ 验证后文的检查点。检查点做到什么程度可以进入下一步能一句话说清为谁解决什么问题不做清单 ≥ 5 项每个要做都能指向一个具体问题案例竞争研究结论技术内容代码级准确 × 专业观感 × 人机协作精修三者兼备的产品目前为零——差异化定位不是拍脑袋是排除了 50 个对手后剩下的空位。警示信号讨论从名词开始我们做一个 XXX 系统而没有要解决的问题→ 后续必膨胀无法回答谁会用、解决什么→ 需求还没成型继续剖析而不是开始设计练习给下一个项目写一句话定位 不做清单各不超过 50 字。四、第 2 步分层规格模型四层定义层回答的问题典型越权信号写歪的早期征兆方案书为什么做、产品原则写实现细节、写状态枚举UserWorkflow用户与系统发生什么出现 UI 名称“用户点击按钮”定义数据结构Runtime-State系统如何记录写用户故事、写产品叙事UI-Interaction如何操作观察定义业务规则、制造新概念、拥有状态机关键洞察先行为后状态。先定义用户做什么UserWorkflow再定义系统记录什么Runtime-State最后才定义界面怎么展示UI-Interaction。顺序一旦颠倒UI 就会反过来逼迫系统造状态——这就是UI 驱动架构的成因。四层单向依赖是 Clean Architecture依赖规则The Clean Architecture, Robert C. Martin的规格化实践——源代码依赖只能向内越靠外越容易变规格文档同理越靠下的层越稳定。配套规则从实战提炼状态三类分离资产生命周期状态draft/approved≠ 派生状态stale计算视图≠ 执行状态任务级/系统级。任何新状态先归类归不进这三类就是 UI 展示状态不进系统展示状态 ≠ 系统状态UI 可以显示正在生成 / 需要确认但审核中 / 编辑中不能成为系统状态术语统一每份文档配术语表跨文档发现同一词两个定义或同一概念两个名字立即登记第 5 步案例三份文档方案书 / UserWorkflow / Runtime在同步轮前做一致性审计抓到系统状态一词在方案书里指 stale、在 Runtime 里指 normal/error——同一词两个定义靠术语修正C-001一次改掉。练习给你项目画四层草图每层一行字。五、第 3 步讨论协议把想法收敛三步协议提案提出方案 理由 ↓ 确认或反驳对方给判断同意 / 反对 / 修改必须附理由 ↓ 冻结达成共识后记录成文不再反复识别征求判断 vs 授权修改最容易踩的雷对方说含义你的动作“你觉得怎么样” / “你怎么看”征求判断回答立场 列出如果要改我会改这几处不改文档“可以” / “确认” / “动手” / “执行”授权修改给出修改计划清单 → 执行边界冻结仪式写任何规格文档前必做先确认三件事再写正文本文档装什么只装行为只装状态只装交互本文档不装什么明确排除清单本文档在权威链的哪一层依赖谁、被谁依赖边界不冻结就写正文文档大概率写歪成第二份方案书。案例Patch 概念十几轮辩论。从要不要→和撤销什么区别→存什么内容→和摘要有什么区别→最终删除。收敛的标志不是争赢了而是问题被问透了——每个追问都让概念更清晰直到发现它不解决任何独立问题。反例教学真实事故一次未经讨论直接修改已冻结文档对方问你觉得以上建议怎么样后直接执行了 7 处编辑→ 对方选择全部回滚。“你觉得怎么样永远不等于动手改”。代价是一整轮回滚。警示信号同一概念被追问三轮还在模糊 → 概念没想清继续问而不是继续写讨论陷入再讨论一轮循环 → 缺冻结仪式先把已共识的部分冻结练习模拟一次提案-反驳-收敛要求反驳必须附理由。六、第 4 步文档生命周期七个阶段边界冻结 → 正文 → 评审 → 修订 → 正式冻结 → 一致性审计 → 同步回填关键规则每阶段有明确出口评审通过才授权修订前先给修改计划清单第 3 步愿景标注愿景级表述 vs 实施级子集显式区分。案例改一句 → 全文重写保持语气统一是产品愿景M3 能力M1 只做步级字段级修改——不标注表面冲突会被反复追问每个新人都会问一遍M 标记每节标注状态M1 落地 | 范围… | 延后…“防止文档写了就必须做”范围蔓延的核心解药案例UserWorkflow 文档从讨论稿到正式冻结经历 6 项修订——包括审批 → 确认的术语统一企业审批流的联想会诱导做出权限系统、NeedConfirmation 不能成为第 3 个权威状态的边界裁定。每次修订都是先列清单、确认后落盘。七、第 5 步变更治理防止漂移已冻结规则不得直接修改。任何变更先登记格式固定Title: 变更标题 Original: 原文规则 Changed: 新规则 Reason: 为什么改——必须写清 Affected: 影响哪些文档两条通道分离防止改一个实现任务 修改产品规格的维护爆炸通道内容典型条目Spec-ChangeLog规格变更产品规则A-001A-006规则修订、C-001C-017审计发现Implementation-Alignment实现文档与规格的差异对齐C-010~C-015拆解文档修正销账规则每项落回对应文档后状态改已同步并注明落回位置“落回方案书 7.438”——决策永远可追溯为什么改、改在哪、谁批准的。警示信号实现开始兼容旧契约旧数据结构 新数据结构并存→ 需要对齐登记两份文档对同一规则说法不同 → 找登记表而不是猜哪个对八、第 6 步一致性审计怎么查错审计清单可复用检查项交叉核对相邻层文档#检查项实战案例1术语冲突同一词两边定义不同系统状态在方案书 stale在 Runtime normal/error2依赖遗漏链路上少了节点依赖链漏了 knowledgematerial 直接连 outline3愿景混淆愿景级表述被当成实施级承诺4.2 主流程的全文重写被当成 M1 能力4命名碰撞同一概念两个名字工作台同时指首页和核心编辑页5边界越权某层写了不该它管的内容Runtime 文档出现产品叙事被边界声明挡回做法逐条核对相邻层对同一规则的表述术语 / 链 / 粒度发现项进 Change Log 编号登记C-xxx同步轮逐条销账第 5 步 的销账规则案例三文档一致性审计产出 15 条发现项——2 条实质修正术语冲突、依赖遗漏、3 条愿景标注、4 条小同步、6 条实现对齐。没有一条推翻设计——这正是审计的价值它证明主体一致并把边缘问题一次清光而不是等到实现阶段才发现。练习拿任意两份相关文档15 分钟内找出 3 处不一致。九、第 7 步验证——垂直切片原则切片目标 验证规格闭环能否跑通不是验证单个技术点只做一个最小闭环不铺全量——垂直切片是敏捷的成熟实践Vertical Slicing – Smaller is Better, Agile Alliance每次交付一个跨层的可用薄片用户界面 后端逻辑而不是横向切层先前端、后数据库。规格验证同理切片必须跨层行为 / 状态 / 交互 / 循环只验证单层不算闭环每个层在切片里都出现状态契约 行为动作 交互投影 修订循环案例M1 Vertical Slice SpikeCodeNarrator 的单步最小闭环建项目 → 导入素材 → 素材请求 → 生成一个 Step → 步审阅 → 发起修订 → 产生提案 → 确认 → 版本更新 → 预览刷新只做一个 Step不出视频、不出音频。它同时验证版本化写入带版本依赖边、派生 stale 计算、提案-确认流程、UI 投影素材请求卡 / 步卡片 / 提案卡 / 预览画布、修订只影响单步下游。执行结果2026-08-03落地于spike_m1/垂直切片已跑通——素材→单步生成→步审阅→修订→提案→确认→版本更新→预览刷新全链路通过。Revision Cost 验证单步反馈只重生成该步下游script/scene/preview 版本递增material 等无关资产 mtime/version 不变stale 单跳语义与 Runtime-State 3.0 契约一致改 script 只立即失效 scenepreview 在 scene 重生成后才级联失效。诚实标注流程的一部分本切片仍是最小验证——单步、单字段修改、模板渲染多步脚本、真实 LLM 生成、UI 投影对接后端FastAPI SSE均未覆盖留待正式 M1 开发逐项验证。未验证的环节必须明说不能因为切片通过了就当全部规格成立。十、常见失败模式#现象根因机制层修正机制检查点1讨论不收敛改了又改缺冻结仪式三步协议 边界冻结每个决策有冻结记录2文档互相矛盾多份文档各自演化单一权威链 登记表变更必登记3UI 反推架构界面需求直接变系统状态四层单向依赖UI 文档无业务规则4状态模型膨胀每个 UI 状态都进模型状态三类分离派生 计算视图5范围蔓延“文档写了就必须做”M 标记 不做清单每节有里程碑标记6术语混乱一词两义 / 两词一义术语表 碰撞检测审计清单第 1 项7旧代码反向影响新架构迁移先于目标先 Target 再 Migration规格冻结后再处置代码8规格与实现脱节实现不知道契约对齐日志 头部对齐声明实现文档头部有声明9决策无记录改了不知道为谁批的登记表 销账每条注明落回位置10只靠代码 review 保质量质量被窄化为代码质量单测 审计 切片三层验证工作流被执行十一、速查卡卡 115 步全程检查清单#步骤检查点做到即可进入下一步1一句话定位能说清为谁解决什么问题2不做清单≥ 5 项3四层草图每层一行单向依赖4讨论协议就位确认征求判断 vs 授权修改的识别规则5边界冻结仪式每份文档装什么 / 不装什么 / 在哪层6写正文含 M 标记 愿景标注7评审有人挑刺问题被问透8修订修改计划先行确认后落盘9正式冻结版本号 状态标记10建立登记表Original / Changed / Reason / Affected 格式11一致性审计5 项检查清单全过12发现项登记编号入 Change Log13同步回填逐条销账注明落回位置14实现对齐实现文档头部声明 对齐日志15垂直切片最小闭环验证规格卡 2越权信号速查层写歪的征兆方案书出现状态枚举、实现细节UserWorkflow出现 UI 名称“点击按钮”Runtime-State出现用户故事、产品叙事UI-Interaction定义业务规则、制造新概念卡 3修订登记表字段Title / Original / Changed / Reason / Affected / 状态待登记→已同步落回位置卡 4M 标记格式状态M1 落地 | 范围… | 延后…卡 5讨论协议速查你觉得怎么样 征求判断 → 回答立场不改文档 可以 / 确认 / 动手 授权修改 → 先给修改计划再执行 提案 → 确认/反驳附理由→ 冻结十二、参考文献The Lean Startup — Eric Ries — Build-Measure-Learn 循环二、原理速览 引用The Clean Architecture — Robert C. Martin — 依赖规则依赖只能向内四、第 2 步 引用Vertical Slicing – Smaller is Better — Agile Alliance — 垂直切片跨层交付九、第 7 步 引用IEEE/ISO/IEC 29148:2018 — Requirements Engineering — 需求工程标准流程三、第 1 步 引用本教程全部内容来自上述文档对应的真实开发过程外部来源均为正文实际引用的权威出处。 需求讨论总返工？15 步工作流让规格一次冻结
需求开发工作流程CodeNarrator v2.3 · 需求开发工作流教程 · 最后更新 2026-08-03一、这篇教程解决什么问题一句话定位一套从模糊想法到规格冻结的需求开发流程用真实项目CodeNarrator v2.3的完整过程做全程案例。需求开发最常见的失败不是想不到而是想乱了症状典型表现讨论不收敛同一个概念改了又改、反复横跳十几轮下来还是模糊文档漂移多份规格文档各自演化对同一规则说法互相矛盾UI 反推架构看到某个界面想做 → 反推需要什么状态 → 状态膨胀 → 架构失控范围蔓延“文档写了就必须做”未来能力被提前实体化本教程的方法不是发明出来的是 CodeNarrator 从 v1 失败到 v2 规格冻结的真实过程中长出来的——每一步都有实际案例包括一次真实的事故教学。跳读指南只想跑流程 → 十一、速查卡15 步检查清单 模板想理解原理 → 二、原理速览只想看坑 → 十、常见失败模式想按步骤复刻 → 从 三、第 1 步 顺序读阅读前提无硬性前置。案例引用的规格文档在项目根/docs/下参考文献不读原文也能跟上读了收获更大。读完能得到什么四层规格模型意图 / 行为 / 状态 / 交互——防止 UI 驱动架构讨论协议提案 → 确认 → 冻结——让讨论收敛变更治理登记表 一致性审计——防止文档漂移一套可复用的模板速查卡二、原理速览需求是可逼近的三句核心信念全部来自实战1. 需求不是一次想清楚的是靠提案 → 确认 → 重做循环逼近的。这条循环不仅适用于产品内容也适用于需求本身——与精益开发的Build-Measure-Learn循环同构The Lean Startup, Eric Ries先验证最小假设再谈扩展。CodeNarrator 的 v1 死因之一就是全自动一次生成——把自动化当成质量来源。v2 把同样逻辑用在需求上定位方案从全自动编译器反复收敛到人机协作创作 IDE中间经过十几轮辩论第 3 步。2. 问题先行。每个新概念先问它解决哪个具体问题答不上来就删。从问题出发的讨论会收敛从名词出发会膨胀——这是全程最值钱的一条原则。3. 分层是防失控的关键。把为什么做 / 发生什么 / 如何记录 / 如何展示分成四层单向依赖方案书产品意图为什么做 ↓ UserWorkflow用户行为发生什么 ↓ Runtime-State系统契约如何记录 ↓ UI-Interaction交互映射如何操作观察依赖方向单向UI 不得反向修改上层。四层的完整定义与越权信号见 四、第 2 步。为什么分层能救需求失控CodeNarrator v1 的失败归因里有一条——约 70% 代码投入在怎么跑状态机 / GUI / API / workspace 管理只有约 20% 在产出什么。分层让每个问题在正确的层里被讨论v1 的工程抢戏本质上就是分层缺失。三、第 1 步需求剖析与问题定义做什么竞争研究有没有人做过、做对了什么、缺什么CodeNarrator 研究了 50 竞品覆盖 7 个类别失败归因重构项目必须回答旧版本为什么失败且要有证据v1 归因出 5 条根因每条带证据定位一句话为谁解决什么问题“面向技术创作者的内容创作 IDE——Cursor 是代码 IDECodeNarrator 是技术表达 IDE”明确不做清单至少 5 项v2 的不做无人值守全自动 / 不做多平台量产 / 不做 API 服务化 / 不做多用户 / 不做真人配音需求开发启发 → 分析 → 规格化 → 验证本身就是需求工程的标准流程IEEE/ISO/IEC 29148:2018——上面的 4 项是它的轻量版启发竞争研究→ 分析失败归因→ 规格化定位 不做清单→ 验证后文的检查点。检查点做到什么程度可以进入下一步能一句话说清为谁解决什么问题不做清单 ≥ 5 项每个要做都能指向一个具体问题案例竞争研究结论技术内容代码级准确 × 专业观感 × 人机协作精修三者兼备的产品目前为零——差异化定位不是拍脑袋是排除了 50 个对手后剩下的空位。警示信号讨论从名词开始我们做一个 XXX 系统而没有要解决的问题→ 后续必膨胀无法回答谁会用、解决什么→ 需求还没成型继续剖析而不是开始设计练习给下一个项目写一句话定位 不做清单各不超过 50 字。四、第 2 步分层规格模型四层定义层回答的问题典型越权信号写歪的早期征兆方案书为什么做、产品原则写实现细节、写状态枚举UserWorkflow用户与系统发生什么出现 UI 名称“用户点击按钮”定义数据结构Runtime-State系统如何记录写用户故事、写产品叙事UI-Interaction如何操作观察定义业务规则、制造新概念、拥有状态机关键洞察先行为后状态。先定义用户做什么UserWorkflow再定义系统记录什么Runtime-State最后才定义界面怎么展示UI-Interaction。顺序一旦颠倒UI 就会反过来逼迫系统造状态——这就是UI 驱动架构的成因。四层单向依赖是 Clean Architecture依赖规则The Clean Architecture, Robert C. Martin的规格化实践——源代码依赖只能向内越靠外越容易变规格文档同理越靠下的层越稳定。配套规则从实战提炼状态三类分离资产生命周期状态draft/approved≠ 派生状态stale计算视图≠ 执行状态任务级/系统级。任何新状态先归类归不进这三类就是 UI 展示状态不进系统展示状态 ≠ 系统状态UI 可以显示正在生成 / 需要确认但审核中 / 编辑中不能成为系统状态术语统一每份文档配术语表跨文档发现同一词两个定义或同一概念两个名字立即登记第 5 步案例三份文档方案书 / UserWorkflow / Runtime在同步轮前做一致性审计抓到系统状态一词在方案书里指 stale、在 Runtime 里指 normal/error——同一词两个定义靠术语修正C-001一次改掉。练习给你项目画四层草图每层一行字。五、第 3 步讨论协议把想法收敛三步协议提案提出方案 理由 ↓ 确认或反驳对方给判断同意 / 反对 / 修改必须附理由 ↓ 冻结达成共识后记录成文不再反复识别征求判断 vs 授权修改最容易踩的雷对方说含义你的动作“你觉得怎么样” / “你怎么看”征求判断回答立场 列出如果要改我会改这几处不改文档“可以” / “确认” / “动手” / “执行”授权修改给出修改计划清单 → 执行边界冻结仪式写任何规格文档前必做先确认三件事再写正文本文档装什么只装行为只装状态只装交互本文档不装什么明确排除清单本文档在权威链的哪一层依赖谁、被谁依赖边界不冻结就写正文文档大概率写歪成第二份方案书。案例Patch 概念十几轮辩论。从要不要→和撤销什么区别→存什么内容→和摘要有什么区别→最终删除。收敛的标志不是争赢了而是问题被问透了——每个追问都让概念更清晰直到发现它不解决任何独立问题。反例教学真实事故一次未经讨论直接修改已冻结文档对方问你觉得以上建议怎么样后直接执行了 7 处编辑→ 对方选择全部回滚。“你觉得怎么样永远不等于动手改”。代价是一整轮回滚。警示信号同一概念被追问三轮还在模糊 → 概念没想清继续问而不是继续写讨论陷入再讨论一轮循环 → 缺冻结仪式先把已共识的部分冻结练习模拟一次提案-反驳-收敛要求反驳必须附理由。六、第 4 步文档生命周期七个阶段边界冻结 → 正文 → 评审 → 修订 → 正式冻结 → 一致性审计 → 同步回填关键规则每阶段有明确出口评审通过才授权修订前先给修改计划清单第 3 步愿景标注愿景级表述 vs 实施级子集显式区分。案例改一句 → 全文重写保持语气统一是产品愿景M3 能力M1 只做步级字段级修改——不标注表面冲突会被反复追问每个新人都会问一遍M 标记每节标注状态M1 落地 | 范围… | 延后…“防止文档写了就必须做”范围蔓延的核心解药案例UserWorkflow 文档从讨论稿到正式冻结经历 6 项修订——包括审批 → 确认的术语统一企业审批流的联想会诱导做出权限系统、NeedConfirmation 不能成为第 3 个权威状态的边界裁定。每次修订都是先列清单、确认后落盘。七、第 5 步变更治理防止漂移已冻结规则不得直接修改。任何变更先登记格式固定Title: 变更标题 Original: 原文规则 Changed: 新规则 Reason: 为什么改——必须写清 Affected: 影响哪些文档两条通道分离防止改一个实现任务 修改产品规格的维护爆炸通道内容典型条目Spec-ChangeLog规格变更产品规则A-001A-006规则修订、C-001C-017审计发现Implementation-Alignment实现文档与规格的差异对齐C-010~C-015拆解文档修正销账规则每项落回对应文档后状态改已同步并注明落回位置“落回方案书 7.438”——决策永远可追溯为什么改、改在哪、谁批准的。警示信号实现开始兼容旧契约旧数据结构 新数据结构并存→ 需要对齐登记两份文档对同一规则说法不同 → 找登记表而不是猜哪个对八、第 6 步一致性审计怎么查错审计清单可复用检查项交叉核对相邻层文档#检查项实战案例1术语冲突同一词两边定义不同系统状态在方案书 stale在 Runtime normal/error2依赖遗漏链路上少了节点依赖链漏了 knowledgematerial 直接连 outline3愿景混淆愿景级表述被当成实施级承诺4.2 主流程的全文重写被当成 M1 能力4命名碰撞同一概念两个名字工作台同时指首页和核心编辑页5边界越权某层写了不该它管的内容Runtime 文档出现产品叙事被边界声明挡回做法逐条核对相邻层对同一规则的表述术语 / 链 / 粒度发现项进 Change Log 编号登记C-xxx同步轮逐条销账第 5 步 的销账规则案例三文档一致性审计产出 15 条发现项——2 条实质修正术语冲突、依赖遗漏、3 条愿景标注、4 条小同步、6 条实现对齐。没有一条推翻设计——这正是审计的价值它证明主体一致并把边缘问题一次清光而不是等到实现阶段才发现。练习拿任意两份相关文档15 分钟内找出 3 处不一致。九、第 7 步验证——垂直切片原则切片目标 验证规格闭环能否跑通不是验证单个技术点只做一个最小闭环不铺全量——垂直切片是敏捷的成熟实践Vertical Slicing – Smaller is Better, Agile Alliance每次交付一个跨层的可用薄片用户界面 后端逻辑而不是横向切层先前端、后数据库。规格验证同理切片必须跨层行为 / 状态 / 交互 / 循环只验证单层不算闭环每个层在切片里都出现状态契约 行为动作 交互投影 修订循环案例M1 Vertical Slice SpikeCodeNarrator 的单步最小闭环建项目 → 导入素材 → 素材请求 → 生成一个 Step → 步审阅 → 发起修订 → 产生提案 → 确认 → 版本更新 → 预览刷新只做一个 Step不出视频、不出音频。它同时验证版本化写入带版本依赖边、派生 stale 计算、提案-确认流程、UI 投影素材请求卡 / 步卡片 / 提案卡 / 预览画布、修订只影响单步下游。执行结果2026-08-03落地于spike_m1/垂直切片已跑通——素材→单步生成→步审阅→修订→提案→确认→版本更新→预览刷新全链路通过。Revision Cost 验证单步反馈只重生成该步下游script/scene/preview 版本递增material 等无关资产 mtime/version 不变stale 单跳语义与 Runtime-State 3.0 契约一致改 script 只立即失效 scenepreview 在 scene 重生成后才级联失效。诚实标注流程的一部分本切片仍是最小验证——单步、单字段修改、模板渲染多步脚本、真实 LLM 生成、UI 投影对接后端FastAPI SSE均未覆盖留待正式 M1 开发逐项验证。未验证的环节必须明说不能因为切片通过了就当全部规格成立。十、常见失败模式#现象根因机制层修正机制检查点1讨论不收敛改了又改缺冻结仪式三步协议 边界冻结每个决策有冻结记录2文档互相矛盾多份文档各自演化单一权威链 登记表变更必登记3UI 反推架构界面需求直接变系统状态四层单向依赖UI 文档无业务规则4状态模型膨胀每个 UI 状态都进模型状态三类分离派生 计算视图5范围蔓延“文档写了就必须做”M 标记 不做清单每节有里程碑标记6术语混乱一词两义 / 两词一义术语表 碰撞检测审计清单第 1 项7旧代码反向影响新架构迁移先于目标先 Target 再 Migration规格冻结后再处置代码8规格与实现脱节实现不知道契约对齐日志 头部对齐声明实现文档头部有声明9决策无记录改了不知道为谁批的登记表 销账每条注明落回位置10只靠代码 review 保质量质量被窄化为代码质量单测 审计 切片三层验证工作流被执行十一、速查卡卡 115 步全程检查清单#步骤检查点做到即可进入下一步1一句话定位能说清为谁解决什么问题2不做清单≥ 5 项3四层草图每层一行单向依赖4讨论协议就位确认征求判断 vs 授权修改的识别规则5边界冻结仪式每份文档装什么 / 不装什么 / 在哪层6写正文含 M 标记 愿景标注7评审有人挑刺问题被问透8修订修改计划先行确认后落盘9正式冻结版本号 状态标记10建立登记表Original / Changed / Reason / Affected 格式11一致性审计5 项检查清单全过12发现项登记编号入 Change Log13同步回填逐条销账注明落回位置14实现对齐实现文档头部声明 对齐日志15垂直切片最小闭环验证规格卡 2越权信号速查层写歪的征兆方案书出现状态枚举、实现细节UserWorkflow出现 UI 名称“点击按钮”Runtime-State出现用户故事、产品叙事UI-Interaction定义业务规则、制造新概念卡 3修订登记表字段Title / Original / Changed / Reason / Affected / 状态待登记→已同步落回位置卡 4M 标记格式状态M1 落地 | 范围… | 延后…卡 5讨论协议速查你觉得怎么样 征求判断 → 回答立场不改文档 可以 / 确认 / 动手 授权修改 → 先给修改计划再执行 提案 → 确认/反驳附理由→ 冻结十二、参考文献The Lean Startup — Eric Ries — Build-Measure-Learn 循环二、原理速览 引用The Clean Architecture — Robert C. Martin — 依赖规则依赖只能向内四、第 2 步 引用Vertical Slicing – Smaller is Better — Agile Alliance — 垂直切片跨层交付九、第 7 步 引用IEEE/ISO/IEC 29148:2018 — Requirements Engineering — 需求工程标准流程三、第 1 步 引用本教程全部内容来自上述文档对应的真实开发过程外部来源均为正文实际引用的权威出处。