产品交付流程优化

为什么要改

原流程里，产品 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 编写规范

目标

把“蓝湖设计稿 → 可执行 Spec.md”的提取过程标准化，让 AI 能根据 Spec.md + 设计稿压缩包直接生成 Flutter 页面代码，不依赖逐张截图。

核心思路

在蓝湖上对每个交互页面分别下载 HTML + CSS 代码压缩包，再用一份 Spec.md 描述页面跳转 / 交互逻辑，把压缩包作为附件一起交给 AI。

方式	痛点	本方案
截图 + 文字描述	每个图标、文字、间距都要截图标注	HTML/CSS 压缩包直接把字号、颜色、布局全部还原
Figma Link	受限于海外网络与协作权限	蓝湖国内访问稳定，导出包体积小
纯文字描述	AI 还原失真，迭代成本高	HTML/CSS 是结构化数据，AI 还原度高

蓝湖侧操作流程

在蓝湖设计稿中选中一个完整可交互页面，必须是单个页面，不要跨页面框选。
顶部菜单 → 代码模式 → 导出 → 选择 HTML + CSS。
蓝湖会生成一个 .zip 压缩包，内含该页面的 index.html、*.css 和资源图片。
为每个页面单独导出一份压缩包，文件名用页面中文名，例如 日记列表页.zip、日记详情页.zip、倾诉首页.zip。

不要一次导出一整条流程，那会丢失页面边界，AI 无法判断跳转起点。

Spec.md 编写模板

每份功能需求的 Spec.md 至少包含三块：页面清单、跳转 / 交互规则、附件清单。

1. 页面清单

列出本次需求涉及的所有页面，每个页面一句话功能描述：

- 倾诉首页：用户进入倾诉模式的入口，展示今日情绪状态与历史日志缩略图
- 日记列表页：按时间倒序展示用户所有日志，支持搜索
- 日记详情页：展示某一篇日记的完整内容与情绪曲线

2. 跳转与交互规则

这是核心。用 触发动作 → 目标页面（附件文件） 的格式书写：

## 跳转规则

| # | 触发位置 | 动作 | 跳转目标 | 备注 |
| - | -------- | ---- | -------- | ---- |
| 1 | 倾诉首页 · 日记Icon | 点击 | 日记列表页 | 见附件 `日记列表页.zip` |
| 2 | 日记列表页 · 列表项 | 点击 | 日记详情页 | 见附件 `日记详情页.zip` |
| 3 | 日记详情页 · 返回按钮 | 点击 | 日记列表页 | 保留滚动位置 |

写法约定

触发位置写“页面名 + 元素名”，AI 才知道从哪找节点。
动作只用 点击 / 长按 / 滑动 / 双击 这几个原子词，不要写“轻触后弹出”。
跳转目标必须写明附件压缩包文件名，AI 才知道去哪份 HTML/CSS 里还原。
备注写页间传参、特殊状态等 AI 无法从静态稿推断的信息，例如 ID、登录拦截、返回保留滚动位置。

反例（不要这样写）

点击倾诉页面日记Icon，需要跳转到，日记列表页.zip

“倾诉页面”是哪一份附件没说清。
“日志图片”是轮播首图还是最近一张图，AI 不知道。
中英文标点混杂。

正例

3. 附件清单

列出本次交付给 AI 的所有压缩包，并带一行说明，让 AI 知道每份对应哪个页面：

## 附件清单

| 文件名 | 对应页面 | 用途 |
| ------ | -------- | ---- |
| 倾诉首页.zip | 倾诉首页 | 还原首屏布局与样式 |
| 日记列表页.zip | 日记列表页 | 还原列表项结构，复用倾诉首页的 Card 样式 |
| 日记详情页.zip | 日记详情页 | 还原正文与底部情绪曲线 |

给 AI 的标准提示词模板

把 Spec.md 和压缩包一起交给 AI 时，统一用以下 prompt：

根据附件中的 Spec.md 与每页对应的 HTML+CSS 压缩包，逐页还原为 Flutter 页面。

约束：
1. 严格按照 Spec.md 的跳转规则实现，不要新增未声明的跳转
2. 字号、颜色、间距按压缩包中的 CSS 取值，不要“看起来差不多”
3. 资源图片沿用蓝湖导出的原始素材
4. 命名遵循《docs/代码规范.md》
5. 每个页面单独一个 widget 文件，文件名与页面中文名一致（拼音或英文均可）

一份完整的 Spec.md 示例

需求：倾诉首页 → 日记列表 → 日记详情，三页基本链路。

# 倾诉模式基础链路 Spec

## 页面清单
- 倾诉首页：情绪状态展示 + 最近日志卡片
- 日记列表页：全量日志列表
- 日记详情页：单篇日记详情

## 跳转规则
| # | 触发位置 | 动作 | 跳转目标 | 备注 |
| - | -------- | ---- | -------- | ---- |
| 1 | 倾诉首页 · 最近日志卡片 | 点击 | 日记列表页 | 见附件 `日记列表页.zip` |
| 2 | 日记列表页 · 列表项 | 点击 | 日记详情页 | 见附件 `日记详情页.zip`，携带日志 ID |
| 3 | 日记详情页 · 顶部返回 | 点击 | 日记列表页 | 保留列表滚动位置 |

## 附件清单
- `倾诉首页.zip` — 还原首屏
- `日记列表页.zip` — 还原列表
- `日记详情页.zip` — 还原详情

## 非功能性要求
- 字号 / 颜色 / 间距严格按 CSS 取值
- 仅实现 Spec 声明的跳转，不引入额外页面

把这份 Spec.md 与三个 zip 一并提交给 AI，即可开始还原。

关键准入规则

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