139 lines
6.9 KiB
Markdown
139 lines
6.9 KiB
Markdown
---
|
|
name: idea-to-product
|
|
description: 将已经通过的软件点子依次推进为固化需求、实施方案、项目骨架、纵向功能、功能验收和发布候选版本。适用于用户提出应用、网站、服务、工具或其他软件项目，并希望 Agent 不进行市场、竞品或价值分析而直接落地的场景；也适用于继续执行已经由本流程管理的项目。开始开发前的每个阶段都必须获得明确的人工确认。
|
|
---
|
|
|
|
# 从点子到产品
|
|
|
|
通过一套由项目文件持续记录的流程，将已经通过的软件点子落地为可验收产品。默认点子已经立项，只关注交付。
|
|
|
|
## 不可违反的规则
|
|
|
|
- 不进行市场、竞品、需求价值或商业价值分析。
|
|
- 对不影响方向的歧义采用合理默认值。
|
|
- 只有当选择会改变产品方向、产生明显成本差异、涉及敏感数据、缺少必要权限或造成需求冲突时才询问用户。
|
|
- 当前版本保持精简，但核心流程必须端到端可用。
|
|
- 把决策和进度写入项目文件，不依赖聊天记录。
|
|
- 三个开发前阶段未全部获得明确人工确认时，绝不进入纵向功能开发。
|
|
- 不得把沉默、话题切换或要求解释理解为确认。
|
|
- 不得代替用户批准阶段门。
|
|
|
|
## 项目控制文件
|
|
|
|
新项目应从 `assets/` 复制模板，结合项目内容生成以下文件：
|
|
|
|
```text
|
|
AGENTS.md
|
|
.ai-project/state.yaml
|
|
docs/REQUIREMENTS.md
|
|
docs/IMPLEMENTATION.md
|
|
docs/FEATURES.md
|
|
docs/ACCEPTANCE.md
|
|
```
|
|
|
|
如果已有 `AGENTS.md`，保留原有内容，只合并本项目需要的流程规则，不得删除用户指令。
|
|
|
|
继续已有项目时，先读取 `AGENTS.md`、`.ai-project/state.yaml`、相关 `docs/` 文件、仓库状态和已有实现，再从记录的阶段继续。如果状态文件与实际产物不一致，停止执行并报告差异，不得自行猜测。
|
|
|
|
开始或继续流程前，读取 [references/stage-gates.md](references/stage-gates.md)。
|
|
|
|
## 状态流转
|
|
|
|
在 `.ai-project/state.yaml` 中使用以下阶段值：
|
|
|
|
```text
|
|
需求起草
|
|
需求待确认
|
|
实施方案起草
|
|
实施方案待确认
|
|
骨架构建中
|
|
骨架待确认
|
|
纵向功能开发
|
|
功能验收中
|
|
验收待确认
|
|
发布候选
|
|
```
|
|
|
|
阶段开始、产物变化、阶段门确认或出现阻塞时，都要更新状态文件。
|
|
|
|
## 执行流程
|
|
|
|
### 1. 记录点子
|
|
|
|
把用户的点子整理成简短的项目身份信息：暂定名称、一句话说明、目标用户、核心流程、交付形态和采用的默认值。不要评估这个点子是否值得做。
|
|
|
|
除非存在会改变产品方向的歧义，否则立即基于这份理解起草需求。
|
|
|
|
### 2. 固化需求——人工确认门 1
|
|
|
|
根据 `assets/REQUIREMENTS.md.template` 创建或更新 `docs/REQUIREMENTS.md`。
|
|
|
|
让每条规则都能被开发和测试。包含用户角色、用户流程、页面或接口、功能、业务规则、数据、权限、正常和异常流程、非目标以及验收标准。
|
|
|
|
把阶段设为“需求待确认”，展示精简的范围摘要和变更文件，然后停止。请用户确认或提出修改。
|
|
|
|
只有用户明确说出“需求确认”“通过，进入下一阶段”或同等明确的话语后才能继续。把确认记录到需求文档和状态文件中，并冻结当前版本范围。
|
|
|
|
### 3. 生成实施方案——人工确认门 2
|
|
|
|
根据 `assets/IMPLEMENTATION.md.template` 创建或更新 `docs/IMPLEMENTATION.md`。
|
|
|
|
只依据已经冻结的需求和仓库约束制定方案。明确架构、技术栈、目录结构、路由、数据模型、接口、身份认证、存储、外部服务、状态流转、失败处理、安全、可观测性、环境、测试、验证命令、部署形态和有序的纵向功能切片。
|
|
|
|
把阶段设为“实施方案待确认”，展示关键技术决策和变更文件，然后停止。不得创建项目骨架或编写产品代码。
|
|
|
|
只有用户明确确认实施方案后才能继续。记录确认人和确认时间。
|
|
|
|
### 4. 生成并验证项目骨架——人工确认门 3
|
|
|
|
把阶段设为“骨架构建中”。只构建已确认方案中定义的基础工程：项目初始化、目录、依赖、配置示例、质量工具、必要的数据库与迁移机制、基础布局、健康检查、错误与日志基础以及最小冒烟测试。
|
|
|
|
不得提前实现计划中的产品功能。实际运行文档中规定的安装、格式或静态检查、类型检查、测试和生产构建命令，并把准确命令和结果记录到 `docs/IMPLEMENTATION.md`。
|
|
|
|
把阶段设为“骨架待确认”，总结项目结构、验证结果、尚未配置的外部服务和建议的第一个纵向功能，然后停止。
|
|
|
|
只有用户明确确认项目骨架后才能开始产品功能开发。确认后记录结果，并把阶段设为“纵向功能开发”。
|
|
|
|
### 5. 按纵向功能开发
|
|
|
|
根据 `assets/FEATURES.md.template` 创建或更新 `docs/FEATURES.md`，从已确认的实施方案生成有序的功能切片清单。
|
|
|
|
每次只完成一个切片。每个切片必须覆盖所有适用的界面、服务或接口、数据持久化、身份与权限、输入校验、加载/空白/成功/失败状态、重试与幂等、日志、自动化测试和人工验证步骤。
|
|
|
|
每个切片按以下步骤执行：
|
|
|
|
1. 标记为“进行中”。
|
|
2. 修改前先检查现有代码。
|
|
3. 只实现当前切片及其直接前置条件。
|
|
4. 运行相关检查，并在风险相称时运行完整检查套件。
|
|
5. 工具允许时，人工操作验证核心流程。
|
|
6. 记录证据并标记为“已完成”，不得标记为已经获得人工验收。
|
|
|
|
除非遇到阻塞或用户要求暂停，否则持续完成已确认的切片清单。新功能想法只记录到后续版本，不得加入当前版本。
|
|
|
|
### 6. 执行功能验收——人工确认门 4
|
|
|
|
把阶段设为“功能验收中”。根据 `assets/ACCEPTANCE.md.template` 创建或更新 `docs/ACCEPTANCE.md`。
|
|
|
|
把每条冻结需求和验收标准映射到具体实现与验证证据。运行全部必要的静态检查、测试、生产构建、迁移验证、权限与数据隔离检查、密钥检查、失败恢复检查和可执行的端到端流程。
|
|
|
|
修复冻结范围内能够明确判断的实现缺陷，增加回归测试，并重新运行受影响的检查。把结果分为已通过、未通过、仅能人工验证、已知限制、发布阻塞项和非阻塞项。
|
|
|
|
自动验收不存在发布阻塞项后，把阶段设为“验收待确认”，提供准确的人工测试步骤，然后停止。必须由用户明确报告验收通过，不能只凭 AI 的验证结果标记为通过。
|
|
|
|
用户明确验收通过后，记录结果并把阶段设为“发布候选”。除非用户另外要求部署，否则不得自行部署。
|
|
|
|
## 阶段门回复格式
|
|
|
|
每个人工确认门都只使用以下栏目回复：
|
|
|
|
```text
|
|
阶段结果
|
|
关键内容
|
|
验证证据
|
|
需要你确认
|
|
确认后下一步
|
|
```
|
|
|
|
保持回复简洁，并链接相关项目文件。明确说明尚未开始下一阶段。
|