文档概述
本《意图规格说明书》是AI时代驱动软件开发的核心文档 ，是意图驱动开发（IDD-AI）的启动原点 。它摒弃传统冗长的需求文档，用一页纸的篇幅，精准对齐业务、技术与AI对"做什么、为何做、做成什么样"的理解，是人机协同的唯一事实来源 和最高效契约。
Markdown格式模板
markdown
## 意图规格说明书
### 1. 业务意图：我们为什么要做这个？
**一句话价值主张：**
[例如：解决用户因流程繁琐而放弃下单的核心痛点，将购物车转化率提升20%。]
**背景与问题：**
- **现状与痛点：** [当前用户需要7步才能完成支付，其中3步是重复信息填写。]
- **机会与价值：** [每简化一个必填项，转化率预计提升5%。]
- **成功指标：** [上线30天内，支付页人均停留时长减少50%，转化率提升15%。]
### 2. 功能意图：用户能用来做什么？
**核心用户旅程：**
1. **角色：** [例如：已登录的移动端用户]
2. **目标：** [在30秒内完成一笔订单支付]
3. **主要步骤：**
- 触发点：[从购物车点击"一键支付"]
- 核心交互：[系统自动填充地址、首选支付方式，用户仅需点击"确认支付"]
- 理想结果：[收到支付成功通知，进入订单详情页]
**功能范围清单：**
- ✅ **包含：** 自动填充已验证地址、调用默认支付方式、一键确认。
- ❌ **不包含：** 新建地址、更换支付方式、发票申请（本阶段）。
### 3. 特色与亮点：我们的与众不同之处？
请明确列出1-3个最核心的差异化设计或技术亮点。
1. **【体验亮点】**：真正意义上的"一键支付"，步骤从7步缩减为1步，为行业首创。
2. **【技术亮点】**：首次应用"实时风控与便捷支付平衡算法"，在简化流程的同时，将资损率控制在0.01%以下。
3. **【业务亮点】**：与XX银行深度合作，支持专属的Token化支付，提升成功率5个百分点。
### 4. 技术约束与目标：非功能性要求是什么？
**质量与性能：**
- **响应时间：** 从点击到跳转结果页，95%的请求响应时间 < 800ms。
- **可用性：** 服务可用性 >= 99.99%。
- **安全性：** 支付Token需符合PCI DSS标准，不落地服务器。
**兼容性与边界：**
- **支持平台：** iOS & Android 官方App最新两个版本。
- **数据边界：** 仅处理用户主动发起的支付订单数据，不用于其他画像分析。
### 5. 验收标准：怎么算我们成功了？
**业务验收：**
- [ ] 指标达成：上线后第30日，支付转化率较基线提升 ≥ 15%。
- [ ] 用户反馈：在NPS调研中，"支付体验"子项得分提升 ≥ 10分。
**功能验收（Given-When-Then格式示例）：**
- **场景：** 用户使用一键支付
- *Given* 用户已登录且购物车有商品
- *And* 用户已设置默认地址和支付方式
- *When* 用户点击"一键支付"按钮
- *Then* 系统应直接发起支付并跳转至成功页面
- *And* 用户应在3秒内收到支付成功的应用内推送
### 6. 团队与后续
- **意图负责人：** [产品/架构师姓名]
- **AI协作工程师：** [开发工程师姓名]
- **下一步：** 本说明书即作为AI进行系统设计、API生成和测试用例编写的输入依据。
- **文档版本：** v1.0文档结构与写法精要
1. 各章节核心作用与写作要点
| 章节 | 核心作用 | 写作要点与避坑指南 |
|---|---|---|
| 1. 业务意图 | 定方向、对齐价值。回答"为什么立项"，是评估项目成功与否的终极标准。 | 要点 ：从用户痛点或商业机会出发，用一句话说清价值。指标要可衡量（如"提升XX%"）。 避坑：避免说"提升用户体验"等模糊表述；避免罗列与核心价值无关的背景。 |
| 2. 功能意图 | 定范围、描述交互。清晰界定功能的边界，让所有人对"做什么"具象化。 | 要点 ：用"用户旅程"讲故事。用"包含/不包含"清单明确划界，防止范围蔓延。 避坑：避免陷入UI细节或技术实现；避免使用"可能"、"或许"等不确定词汇。 |
| 3. 特色与亮点 | 定焦点、彰显价值。明确资源倾斜点和市场宣传点，是团队的兴奋剂。 | 要点 ：分点阐述，明确标注【类型】。每个亮点都应有明确的技术或体验依据。 避坑：亮点不超过3个，否则等于没有亮点；避免与"功能意图"中的基础功能重复。 |
| 4. 技术约束与目标 | 定框框、设立标准。明确系统的质量、性能和安全基线，是技术的"宪法"。 | 要点 ：要求必须可测量、可验证。优先列出与业务成功直接相关的约束（如首屏时间）。 避坑：避免罗列所有可能性，只写最关键、必须达成的几条；避免使用"快速"、"稳定"等定性词。 |
| 5. 验收标准 | 定终点、统一共识。定义"完成"和"成功"的具体条件，是交付和验收的客观依据。 | 要点 ：业务指标和功能场景相结合。功能验收使用Given-When-Then确保无歧义。 避坑：验收标准必须在开发前达成一致，事后补充无效；避免标准不可观测或不可测试。 |
2. 核心作用：为什么它是"启动的起点"？
- 人机协作的刚性契约 ：这份文档是人类意图的最终封装 ，可直接作为指令输入给AI编码助手或智能体，生成代码、测试和配置。它确保了从"人想"到"机做"的信息无损传递。
- 团队对齐的高效工具 ：用15-30分钟的会议填充此文档，能强制产品、技术、业务等角色在最本质的问题上达成共识，避免后续因理解偏差导致的巨额返工。
- 决策与取舍的罗盘 ：在开发过程中，任何特性增减或方案争论，都可以回溯到这份文档，问："这是否更有利于实现我们定义的业务意图 和亮点？" 使之成为决策的客观依据。
- 开发流程的加速器 ：明确了"验收标准"和"技术约束"后，AI可以并行地开展系统设计、编写测试用例甚至生成部署脚本，将传统串行流程大幅压缩。
3. 使用流程建议
- 填写阶段 ：由产品负责人 或业务架构师 发起，召集核心开发工程师，以协作工作坊形式（建议30分钟内）共同完成。争论点恰恰是需要澄清的关键。
- 验证阶段 ：将完成的初稿交给AI（如ChatGPT-4、DeepSeek），发出指令："请以资深技术评审人的视角，审视这份《意图规格说明书》，指出其中不明确、有矛盾或技术实现上可能存在风险的地方。" 根据AI的反馈进行修订。
- 发布与追溯阶段 ：将最终版存入项目仓库根目录（如
INTENT.md）。后续所有的代码提交、AI对话和测试报告，都应关联到此文档的特定章节，确保全程可追溯。
总结而言 ，这份《意图规格说明书》模板，就是将你之前探讨的"从『如何编码』转向『需要什么』"这一核心理念，固化为一套可重复、可操作、且为AI时代量身定制的工作契约。它始于一个简单的表格，但通过结构化的思考和严谨的定义，成为驱动高质量、高效率智能开发的基石。