Prompt体系与AI协作实践
1. Prompt体系概览
本章说明 A2E 项目在研发阶段采用的 Prompt 驱动协作机制。该体系用于组织需求澄清、技术拆解、实现推进与交付复盘，不属于 A2E 引擎运行时能力。
Prompt 体系由两类文档构成：
Guide：定义阶段目标、边界、输入、输出与完成标准。Template：定义阶段文档结构，约束记录格式与交付内容。
当前体系覆盖三类起点与六个主阶段：
- 起点：
Story / Feature / Issue - 主流程：
Draft -> Plan -> Code -> Iteration -> Review
2. 文档驱动开发流程
这条流程的目标是把“想法”逐步转换为“可验证的交付结果”，并在每一步留下可追踪记录。
2.1 Story
Story / Feature / Issue 作为流程入口，负责定义“这次要解决什么问题”。
Story：用于新的业务目标或新能力。Feature：用于既有能力的增强、修改或范围调整。Issue：用于缺陷与异常行为修复。
该阶段强调“问题定义清晰”，不进入实现方案。
2.2 Draft
Draft 负责需求澄清与原型确认，是从业务语言过渡到工程语言的关键层。
- 从用户角度描述核心场景、边界和异常状态。
- 明确本次范围与不在范围（Out-of-scope）。
- 给出可讨论的原型或界面要点，用于快速对齐预期。
这一步的价值是减少返工：先对齐“做什么”，再进入“怎么做”。
2.3 Plan / Code / Iteration / Review
Plan：技术拆解与验收清单阶段
- 将需求映射为技术任务与执行顺序。
- 用可验证的验收条目表达成功标准。
- 明确风险、依赖与回退策略。
Code：实现记录阶段
- 按既定计划推进结构设计、替身策略、测试设计与功能实现。
- 记录关键决策和变更影响，保证可追溯。
Iteration：问题收敛阶段
- 首轮测试执行后，进行问题归类、修复与复测。
- 目标是把主要问题收敛到可交付状态，并清晰记录遗留项。
Review：交付确认阶段
- 面向用户反馈做差异分析（预期 vs 实际）。
- 将确认过的修正事项转为下一轮迭代输入。
Guide 与 Template 的对应关系如下：
| 阶段 | Guide 关注点 | Template 产出 |
|---|---|---|
| Story / Feature / Issue | 问题定义与范围 | St / Ft / Is 记录 |
| Draft | 需求澄清与原型确认 | Df 文档 |
| Plan | 技术拆解与验收标准 | Pl 文档 |
| Code | 实现过程与变更记录 | Cd 文档 |
| Iteration | 测试收敛与修复闭环 | It 文档 |
| Review | 反馈分析与修正确认 | Rv 文档 |
3. 人机协作分工
在 A2E 的协作方式里，人和 AI 各自承担不同职责：
- 人负责：
- 目标定义与范围裁剪
- 关键取舍与最终验收
- 风险判断与优先级决策
- AI 负责：
- 文档草拟与结构化整理
- 技术拆解与实现推进
- 测试修复与回归建议
- 共担职责：
- 保持术语一致
- 维持文档与实现同步
- 对交付结果可解释、可追踪负责
这种分工强调“人主导、AI加速”，而不是把决策外包给工具。
4. 质量门禁与回归策略
质量控制分三层：
- 文档门禁
- 各阶段必须有对应记录，确保目标、实现和验收可追踪。
- 工程门禁
- 通过项目既有质量检查流程（如类型、风格、构建、测试）验证变更稳定性。
- 交付门禁
- 在 Review 中完成用户反馈闭环，未达成一致不视为完成。
回归策略强调“小步快跑”：
- 先聚焦核心路径，再扩展边界场景。
- 每轮迭代都要给出“已解决/未解决/推迟”的明确结论。
- 对未解决问题保留可执行的下一步，而不是停留在描述层。
5. 实践经验与限制
实践经验：
- 统一的 Guide + Template 可以显著降低沟通成本。
- 文档驱动能把复杂协作拆成可管理的小阶段。
- 同一套流程可同时支持产品讨论、技术执行和交付复盘。
当前限制：
- 该体系仍是
Experimental阶段，持续在真实开发中迭代。 - 流程质量高度依赖输入质量：目标不清晰时，后续阶段会放大偏差。
- AI 能提升速度，但关键决策仍需人工把关，尤其在边界与风险问题上。