产品交付流程优化

为什么要改

原流程里，产品 Story 往往直接交给开发，产品下挂的 Task 转成 Story 给开发，变得结构混乱、关系不清，开发真正需要的技术方案没有沉淀，测试 Story 也和产品 Story 脱节。结果是：需求、实现、测试分别在跑，出了问题很难判断责任、进度和验收依据。

结构要分清产品 Story 不再承载开发任务细节，开发执行统一放到开发 Story。

方案要先行开发不直接依赖长篇产品文档，而是依赖经过 review 的 Spec 和技术方案。

质量要闭环联调、自测、测试都要成为明确任务，并绑定对应用例。

验收要可追溯测试与产品 Story 建立关联，最后按原始产品目标验收关闭。

新的交付结构

优化后的核心是“流程解耦，内容强关联”：产品 Story 负责定义需求目标，开发 Story 负责承接 SDD 流程并推进技术实现，测试再反向关联产品 Story 完成验收闭环。这样既避免产品需求和开发任务混挂，也让 Spec、技术方案、AI 生成 Plan、联调自测和测试用例都沉淀在同一条开发链路里。通过 SDD 引入，提升开发效率，让开发有时间去自测实现的功能点。

产品 Story：定义做什么

承载 PRD、需求范围、业务目标和验收标准。
不直接挂前端、后端、联调、自测等开发执行 Task。
状态按产品视角流转：New、Active、Resolved、Closed。
当开发与测试都完成后，再回到产品 Story 做最终验收。

开发 Story：定义怎么做

与产品 Story 建立 1:1 或 1:N 关联，不作为产品 Story 的子 Task。
作为 SDD 流程的主载体，承载 Spec、技术方案、AI 生成 Plan、代码实现和任务拆分。
前端、后端、联调、自测、测试 Task 都挂在开发 Story 下。
开发 Story 的状态独立流转，进度由下属 Task 汇总。

加入 SDD 后带来的变化

开发不再直接从产品文档跳到写代码，而是先把需求整理成 Spec，再生成技术方案和实现 Plan。
AI 生成有明确输入和边界，减少“凭理解发挥”的风险，生成结果也更方便 review。
技术方案、提示词、模型信息、开发计划、自测用例和测试用例都沉淀在开发 Story，后续维护者不用只靠读代码理解历史决策。
测试用例由技术方案反向生成，开发自测和测试验收使用同一套需求上下文，降低漏测和验收偏差。

开发 Owner 怎么定

开发 Story 必须有明确 Owner。Owner 不是“谁写最多代码”，而是谁负责把这条需求从技术方案推进到提测。

为什么要定开发 Owner

需要有人对开发 Story 的整体推进负责，避免前端、后端、测试各做各的，最后没人收口。
需要有人维护技术方案、评审结论、提示词、模型信息和变更记录，保证后续迭代能追溯。
需要有人判断什么时候可以进入开发、联调、自测和提测，避免关键质量环节被口头跳过。
当需求、接口或验收标准不清楚时，需要 Owner 及时拉齐产品、开发和测试，并推动补齐输入。

场景	Owner 建议	原因	责任边界
常规前后端需求	前端开发	前端最接近交互、接口联调和端到端体验。	前端牵头方案与联调，后端提供接口支持并承担后端 Task。
纯接口或中后台服务	后端开发	主要复杂度在服务、数据和接口契约。	后端牵头方案，前端按接口契约配合接入。
需求不清或验收缺失	暂不开工	没有清晰输入，后续 Spec、方案和测试都会失真。	Owner 可要求产品补齐 PRD、范围或验收标准。

从需求到上线的主流程

1产品输入

产品 Story 中明确目标、范围、边界和验收标准。

2创建开发 Story

关联产品 Story，指定开发 Owner，确认是否具备开工条件。

3生成并评审 Spec

把产品文档改写成 AI 和开发都能执行的 feature_spec.md。

4生成技术文档包

输出总体方案、前端实现、接口对接、后端支持和测试用例。

5拆分 Task

按方案拆出前端、后端、联调、自测、测试任务。

6AI 生成 Plan 和代码

Plan 先 review，再进入代码生成；核心逻辑仍由人工把关。

7联调与自测

前后端完成后联调；联调通过后按自测用例执行。

8测试验收

测试按完整用例验证，产品按验收标准确认结果。

9上线关闭

正式环境验证通过后上线，并关闭对应产品 Story。

10沉淀复盘

把方案变更、提示词、模型、问题和结论沉淀回开发 Story。

什么是 SDD

SDD 是 Spec-Driven Development，中文可以理解为“规格驱动开发”。它的核心做法是：在写代码之前，先把产品需求整理成一份结构化、可执行、可验收的 Spec，让开发人员和 AI 都围绕同一份规格工作。

SDD 解决什么

把“需求文档 → prompt → AI 写代码”的松散过程，升级为“需求文档 → Spec → 技术方案 → Plan → 代码”。
减少 AI 对需求的自由发挥，明确目标、范围、边界和验收标准。
让开发 review 的对象从零散 prompt 变成可沉淀、可追溯的规格和方案。

Spec 里要说清什么

目标：这次需求要达成什么结果。
要做的事：具体页面、入口、行为、接口或状态变化。
不能动的地方：非目标、兼容要求、边界和约束。
怎么验收：通过标准、主要场景和待确认问题。

Spec.md 模版

Spec.md 用来把产品需求整理成后续技术方案和 AI 实现都能直接使用的规格说明。内容保持简洁，重点写清楚背景、范围、交互规则、验收标准和待确认问题。

# <功能名称>规格

## 1. 背景

<用 1-3 句话说明为什么做，以及本次解决什么问题。>

## 2. 需求范围

### 2.1 <需求项>

- <明确的展示位置、入口、行为或规则。>
- <点击、切换、提交、查看等关键动作。>
- <与现有页面或组件的关系。>

## 3. 交互规则

- <入口位置、展示条件、跳转、空态、禁用态等规则。>
- <只保留会影响技术方案的交互细节。>

## 4. 验收标准

- <可验证的完成标准。>
- <覆盖主要入口、主要状态和不影响原功能。>

## 5. 待确认问题

1. <会影响技术方案但产品文档尚未明确的问题。>

SDD 在流程里的位置

SDD 是开发 Story 的执行方法。它不是替代产品文档，也不是直接让 AI 写代码，而是在写代码前先把需求翻译成结构化 Spec，再从 Spec 生成技术方案和开发计划。

产品文档 写给人看。说明业务目标、功能范围、用户行为和验收标准。

Spec 写给 AI agent 和开发看。把需求拆成目标、范围、交互规则、边界和待确认问题。

技术方案 / Plan 写给实现过程看。明确怎么改、谁支持、对接什么接口、如何验证。

阶段	产物	重点内容	进入下一阶段条件
规格整理	`feature_spec.md`	使用 `write-feature-spec` Skill 生成 `feature_spec.md`，内容包含背景、范围、交互规则、验收标准、待确认问题。	开发 review 通过，需求缺口已补齐或明确标记。
技术拆解	技术文档包	通过 `write-tech-design-pack` Skill 生成总体技术文档、前端交互实现、前端接口对接、后端接口支持、开发自测用例、测试人员测试用例。	方案 review 通过，接口契约和实现边界明确。
实现计划	AI 生成 Plan	实现步骤、依赖顺序、风险预案、与现有代码结构的兼容方式。	开发 Owner 和实现方 review 通过。
代码实现	代码 + PR	AI 主要处理样板代码、重复结构和接口对接；核心逻辑、关键算法由人工把关。	开发 Task 完成，进入联调和自测。

开发 Story 下必须拆出的任务

Task 的作用不是把工作切碎，而是让每个关键环节都有负责人、时间点和完成定义。尤其是联调和自测，必须显式成为任务。

任务	负责人	完成定义
前端开发 Task	前端	页面、交互、状态、接口调用完成，并符合技术方案。
后端开发 Task	后端	接口、数据、校验、错误场景和兼容支持完成。
联调 Task	开发 Owner 牵头	涉及前后端或多端协作时必须执行；主流程跑通，不通过则回退对应开发 Task。
开发自测 Task	实现方	挂载开发自测用例，覆盖核心路径、异常分支和关键交互，全部通过后才能提测。
测试 Task	测试人员	依据测试人员用例覆盖功能、边界、异常、回归和兼容性。

一周五天怎么跑

周期节奏按“周五启动，下周四发布”设计。周五先把需求和方案确定下来，周一集中实现和联调，周二完成自测与提测，周三到周四完成测试、验收和上线。

周五上午需求交接，拉齐目标、范围、边界，确认本周迭代。

周五下午全部 Spec 确定，技术方案文档确定，开发 Story 具备开工条件。

周一上午AI 跑完主体实现代码，覆盖本周全部需求。

周一下午联调；部分小需求可优先提测以缩短链路。

周二开发自测、修复问题，所有需求在本日提交测试。

周三测试环境测试，覆盖功能、回归和兼容性。

周四正式环境测试、产品验收、正式上线。

蓝湖设计稿如何进入 Spec

蓝湖规范主要服务于“页面还原类需求”。它解决的是截图描述不完整、Figma 链接不稳定、纯文字还原失真的问题：用蓝湖导出的 HTML/CSS 作为结构化视觉输入，再用 Spec 说明页面之间怎么跳。

蓝湖侧操作

在蓝湖中选中一个完整可交互页面，不跨页面框选。
进入代码模式，导出 HTML + CSS 压缩包。
每个页面单独导出一份压缩包，按页面中文名命名，例如 日记列表页.zip。
不要一次导出整条流程，否则页面边界不清，AI 无法判断跳转起点。

Spec 必写内容

页面清单：列出所有页面，每个页面一句话说明用途。
跳转与交互规则：使用“触发位置 + 动作 + 跳转目标 + 备注”的表格。
附件清单：列出每个 zip 对应的页面和用途。
非功能性要求：字号、颜色、间距按 CSS；适配以 Flutter SafeArea / MediaQuery 为准。

跳转规则写法

字段	写法	示例
触发位置	页面名 + 元素名	倾诉首页 · 最近日志卡片
动作	只使用点击、长按、滑动、双击等原子动作	点击
跳转目标	写明页面和附件压缩包	日记列表页，见附件 `日记列表页.zip`
备注	记录静态稿无法推断的信息	携带日志 ID；返回时保留滚动位置。

蓝湖导出包只负责还原单页结构和样式；页面跳转、传参、登录拦截、返回保留滚动位置等动态逻辑，必须写进 Spec。这样 AI 才不会把视觉稿误当成完整业务流程。

关键准入规则

AI 草拟的 Spec、技术方案和 Plan 都必须经人工 review。
技术方案未确定，不允许进入开发 Task 执行。
开发 Plan 未 review 通过，不允许进入代码生成。
开发 Story 中涉及 AI 生成的部分，需要记录提示词内容和生成模型。
Owner 不明确则 Story 不开，避免无人牵头。
联调 Task 不通过，不允许进入测试阶段。
开发自测不通过，测试人员不接单。
自测 Task 必须挂载自测用例文档，不允许凭印象自测。
测试 Story 必须能追溯到产品 Story，保证验收闭环。
方案 review 后的变更、评审结论和版本记录由开发 Owner 维护。