Michael的笔记本

AI-First Waterfall（AI主导瀑布模型）

核心变化：

• 阶段 ：从线性推进变为“人定义约束 → AI生成 → 人验证 → AI细化”的内循环。
• 角色 ：传统BA、PM、QA、Dev等角色演变为 AI的输入者、训练者、验证者、环境管理者 。
• 产出物 ：从说明书变为 结构化提示词、测试用例集、模式定义文件、验证脚本 。

阶段一：需求形式化（替代传统“需求分析”）

目标 ：将模糊的业务需求转成AI可严格遵循的目标描述。

参与角色 ：

1. 需求架构师（原BA/PM） ：主导与业务方沟通。
2. AI提示工程师 ：负责将需求拆解为AI可理解的层次化目标。
3. 领域数据专家 ：准备示例和约束数据。

分工 ：

• 需求架构师：产出业务目标、用户角色、成功标准（定量）。
• AI提示工程师：定义任务的 系统指令框架 、边界条件、禁止行为。
• 领域数据专家：提供few-shot示例、预期输入输出对。

产出物 （供AI理解）：

• requirements.yaml：结构化需求，含目标、用户故事、验收阈值。
• constraints.txt：技术要求（语言、框架、API协议）、性能基线。
• examples/：3-5个典型场景的输入→期望输出示例。

阶段二：架构与接口契约化（替代传统“概要/详细设计”）

目标 ：为AI定义清楚“如何组合”及“模块间如何对话”，不依赖人类UML图。

参与角色 ：

1. 系统分解师（原架构师） ：决定模块拆分与数据流。
2. 契约定义者（原接口设计者） ：生成机器可读的接口规范。
3. 测试架构师 ：定义模块级的验证方式。

分工 ：

• 系统分解师：输出模块职责清单、依赖关系图（用Mermaid或PlantUML，便于AI解析）。
• 契约定义者：输出OpenAPI/Swagger/Protobuf/GraphQL Schema；数据库Schema（SQL或Prisma）。
• 测试架构师：输出每个模块的 单元测试用例骨架 （仅输入输出预期，无实现）。

产出物 （供AI理解）：

• architecture.md：模块功能描述、数据流向、异常处理策略。
• api_specs/：接口定义文件（OpenAPI 3.0等）。
• db_schema.sql / schema.prisma。
• test_contracts/：每个模块的输入输出契约测试（空函数 + 测试数据）。

阶段三：AI编码执行（替代传统“编码”）

目标 ：AI根据前两阶段的产出生成完整、可集成、符合约束的代码。

参与角色 ：

1. AI编排员（原技术Leader） ：选择模型、编排子任务、处理长上下文拆分。
2. 环境工程师 ：准备构建、运行、数据库等环境。
3. 验证员（原QA + 部分Dev） ：运行契约测试，判定AI输出质量。

分工 ：

• AI编排员：将系统拆解为AI可逐个实现的子任务（每个子任务有：提示词、接口契约、测试用例、依赖模块）。
• 环境工程师：提供Dockerfile、docker-compose、CI流水线基座。
• 验证员：自动执行每个模块的测试用例，失败则反馈给AI编排员触发重试。

产出物 （供AI理解）：

• generated_code/：按模块生成的代码（控制器、服务、模型、中间件）。
• test_reports/：每轮编码后的自动化测试报告。
• fix_prompts.txt：针对失败测试生成的纠正提示词（人辅助生成）。

注意：人的工作此时主要是“运行测试 → 收集失败信息 → 以结构化方式反馈给AI → 让AI修复”。

阶段四：AI集成与验证（替代传统“测试”）

目标 ：端到端验证系统是否符合需求，所有测试用例由AI生成或人辅助定义。

参与角色 ：

1. 测试工程师（转型为测试提示工程师） ：设计端到端测试场景提示词。
2. 安全/性能专家 ：定义非功能测试的约束。
3. AI验证管理者 ：多轮运行测试，汇总结果。

分工 ：

• 测试工程师：生成e2e_scenarios.json（模拟真实用户路径）；调用AI生成测试数据。
• 安全/性能专家：设置压力测试阈值、SQL注入检查提示词。
• AI验证管理者：执行全部测试套件，自动分类失败原因（需求不明/接口契约错/实现bug）。

产出物 （供AI理解）：

• e2e_tests/：端到端测试脚本（Playwright/Cypress格式，但由AI生成）。
• performance_profile.json：各API响应时间、错误率。
• security_audit.log：自动扫描结果。
• test_feedback.yaml：每一失败项对应到原需求/设计/代码阶段。

阶段五：部署与运行反馈闭环（替代传统“交付与维护”）

目标 ：系统上线后，运行时产生的错误或变更需求，以AI可理解方式流回阶段一/二。

参与角色 ：

1. 运维提示工程师（原SRE/DevOps） ：将异常日志转换为结构化问题描述。
2. 反馈处理器 ：收集用户报错/新需求，拆解为修改请求。
3. 模型更新管理者 ：必要时微调或更新模型上下文。

分工 ：

• 运维提示工程师：编写error_to_prompt.sh（将堆栈跟踪 + 当前阶段产出 → 修复提示）。
• 反馈处理器：整理“新需求”为requirements_v2.yaml差异文件。
• 模型更新管理者：管理项目级知识库（存储之前AI成功/失败的案例）。

产出物 （供AI理解）：

• runtime_errors/：结构化的错误上下文（请求、代码段、环境、预期行为）。
• change_requests/：新需求或修改请求，格式同阶段一的YAML。
• prompt_library/：本次迭代中证明有效的提示词模板。

总结表：角色演变与产出物特征

关键区别总结（与以人为本的瀑布对比）：

• 人写文档 → 人写AI提示+约束+测试
• 人理解设计 → AI理解结构化定义
• 人工评审 → 自动测试+反馈循环
• 项目经理管人 → 提示工程师管理上下文和模型输出质量

你团队如果要真正落地这个模式，最关键的第一步是： 产出物标准化 （所有需求/设计/测试都写成YAML/JSON/代码格式），并建设一个 “反馈转提示”的自动化工具链 。