BMAD之核心架构：为什么“方案化”至关重要 (Phase 3 Solutioning)——必学！BMAD 方法论架构从入门到精通

核心架构------为什么"方案化"至关重要 (Phase 3: Solutioning)

文章目录

- 核心架构------为什么"方案化"至关重要 (Phase 3: Solutioning)
- - [📌 摘要](#📌 摘要)
  - [3.1 为什么Solutioning至关重要？------ 它是BMAD的"防火墙"](#3.1 为什么Solutioning至关重要？—— 它是BMAD的“防火墙”)
  - - [🚨 没有Solutioning，你会踩哪些坑？](#🚨 没有Solutioning，你会踩哪些坑？)
    - [✅ Solutioning的核心价值](#✅ Solutioning的核心价值)
    - [🧩 Solutioning过程架构图（可视化拆解）](#🧩 Solutioning过程架构图（可视化拆解）)
  - [3.2 Solutioning实践步骤（手把手实操，新手可直接套用）](#3.2 Solutioning实践步骤（手把手实操，新手可直接套用）)
  - - [**Step 1：Brainstorm 方案（强制3个，分类型）**](#Step 1：Brainstorm 方案（强制3个，分类型）)
    - [**Step 2：Trade-off 表格评估（核心步骤）**](#Step 2：Trade-off 表格评估（核心步骤）)
    - [**Step 3：输出 Tech Spec（技术规范文档）**](#Step 3：输出 Tech Spec（技术规范文档）)
    - [**Step 4：接口一致性校验（避坑关键）**](#Step 4：接口一致性校验（避坑关键）)
    - [**Step 5：风险规避（PoC前置，降低返工率）**](#Step 5：风险规避（PoC前置，降低返工率）)
    - [**Step 6：方案定稿与角色同步**](#Step 6：方案定稿与角色同步)
  - [3.3 实战：计算器Solutioning完整落地（PoC+Tech Spec实操）](#3.3 实战：计算器Solutioning完整落地（PoC+Tech Spec实操）)
  - [3.4 常见问题与优化技巧（Solutioning踩坑总结）](#3.4 常见问题与优化技巧（Solutioning踩坑总结）)
  - - **问题1：方案同质化，3个方案差别不大，无法对比选优**
    - **问题2：PoC验证流于形式，只验证"能运行"，不验证风险点**
    - [**问题3：Tech Spec写得太复杂，Dev/QA Agent看不懂，无法落地**](#问题3：Tech Spec写得太复杂，Dev/QA Agent看不懂，无法落地)
    - **问题4：方案同步不彻底，部分AI角色偏离方案**
  - [3.5 总结与进阶挑战](#3.5 总结与进阶挑战)
  - - **核心总结**
    - **进阶挑战（巩固Solutioning实操）**

📌 摘要

通过前两篇文章，我们已经掌握了BMAD的入门逻辑，也学会了用Phase 1（业务理解）和Phase 2（产品规划）生成高质量PRD。但到这一步，很多人会陷入一个新的误区------拿着PRD就直接让Dev Agent写代码，结果导致AI输出的接口混乱、方案冲突，甚至出现"技术能实现，但不符合业务价值"的尴尬局面。

其实BMAD的核心，既不是前期的业务分析，也不是后期的编码，而是 Phase 3：Solutioning（方案化） 。BMAD社区资料"9-why-solutioning-matters"里明确提到，Solutioning是防止AI角色冲突、规避项目失败的关键，它就像一座桥，一头连着PRD的"what（要做什么）"，另一头连着编码的"how（怎么做）"。

这篇文章是我结合实战踩坑经历优化的，重点突出 Solutioning "多样性（多方案）+ 验证（PoC）" 的核心原理，补充了Trade-off架构图和我平时实操中常用的风险规避模板，通过计算器案例深度解析Phase 3的每一个步骤，帮大家掌握方案对比和架构决策的技巧。如果你已经规划好PRD，想避免后期编码返工、AI输出冲突，这篇文章会让你精通Solutioning，真正吃透BMAD的核心架构逻辑。

3.1 为什么Solutioning至关重要？------ 它是BMAD的"防火墙"

我当初第一次做计算器项目时，跳过了Solutioning环节，直接拿着PRD让Dev Agent写代码，结果踩了大亏：Dev Agent同时生成了CLI和Web两个版本的代码，接口命名混乱，两个版本的计算逻辑冲突，后期重构花了整整2天时间，远比做Solutioning的时间还多。后来我仔细研究了"9-why-solutioning-matters"这份资料才明白，Solutioning的核心价值，就是桥接PRD的"what"和编码的"how"，避免AI角色独立决策导致的冲突，从根上规避风险。

先给大家明确Solutioning的核心原理，新手记好，不用死记资料里的复杂理论，抓住核心就能上手：

多样性（强制 brainstorm 3+ 方案）+ 验证（PoC 概念验证）

这两个点结合起来，能规避70%以上的AI开发风险，避免后期返工。

🚨 没有Solutioning，你会踩哪些坑？

痛点1：AI输出不一致，角色冲突严重

没有统一的方案规范，Dev Agent可能按自己的理解写代码，QA Agent按另一种逻辑做测试，甚至同一个Dev Agent两次生成的接口、架构都不一样，最后导致代码混乱，无法整合。
痛点2：接口混乱，扩展维护难

跳过方案对比，直接编码，很容易出现接口命名不统一、参数混乱、架构无设计的问题，后期想加功能、改Bug，根本无从下手，只能推倒重构。
痛点3：方案不合理，偏离业务价值

有时候AI生成的技术方案，虽然能实现PRD的功能，但不符合业务目标------比如计算器PRD的核心是"高效、轻便"，AI却生成了一个依赖大量第三方库的复杂方案，反而降低了计算速度，违背了最初的业务价值。

✅ Solutioning的核心价值

通过多方案 brainstorm，对比不同方案的优劣、风险和成本，再通过PoC验证高风险点，最终选择最贴合业务价值、最稳妥的方案，给后续编码定好"统一标准"，让AI所有角色都围绕同一个方案发力，避免冲突和无效开发。

🧩 Solutioning过程架构图（可视化拆解）

我根据资料里的逻辑，结合自己的实操经验，画了一张Solutioning的过程架构图，把"从PRD输入到方案确定"的每一步都拆得明明白白：

简单解读这张图：Solutioning不是"想一个方案就完事"，而是一个 " brainstorm→评估→验证→调整→确定"的小闭环 。重点是 "3+方案"（避免思维局限） 和 "PoC验证"（规避高风险） ，最后输出的 Tech Spec（技术规范），就是后续所有AI角色的"行动指南"，确保大家方向一致，不出现冲突。

3.2 Solutioning实践步骤（手把手实操，新手可直接套用）

很多新手觉得Solutioning复杂，其实只要跟着这5个步骤来，每一步都做扎实，就能快速完成方案化，重点是 "不偷懒、不凭感觉"，强制自己做3+方案和PoC验证。下面的步骤，我结合了资料要求和自己的实操技巧，比官方步骤更贴合新手：

Step 1：Brainstorm 方案（强制3个，分类型）

不要只想一个方案，一定要 brainstorm 至少3个，且分 "保守、平衡、激进" 三种类型，这样才能对比出最优解。

例如计算器项目：

保守方案：CLI版本（简单、易实现）
平衡方案：Web版本（兼顾易用性和开发成本）
激进方案：AI增强版本（加智能纠错，但风险高）

这样分类，能快速明确每个方案的定位，避免方案同质化。

Step 2：Trade-off 表格评估（核心步骤）

这是方案对比的关键，把每个方案的优势、风险、成本、验证方式都列清楚，直观对比，避免凭感觉选方案。我给大家准备了一个实战优化版Trade-off模板，新手可以直接套用：

方案类型	具体方案	优势（贴合业务价值）	风险（明确可验证）	成本（开发工期/依赖）	验证方式（PoC重点）
保守方案	CLI版本计算器（Python实现）	开发快（1天完成），无依赖，符合"轻便"业务目标，适合新手操作	易用性差，无可视化界面，不符合职场文员的使用习惯	低（1人1天，无需第三方库）	PoC测试：运行脚本，验证加减乘除功能是否正常，响应时间<50ms
平衡方案	Web版本计算器（Flask+HTML）	有可视化界面，易用性强，兼顾初中生和职场文员，贴合业务目标，可扩展	依赖Flask框架，部署简单，无高风险点	中（1人2天，需掌握基础Flask用法）	PoC测试：启动服务，验证界面交互和计算功能，响应时间<100ms
激进方案	AI增强计算器（Flask+AI纠错）	有智能纠错功能，提升用户体验，超出PRD基础需求，有差异化	依赖AI接口，API延迟可能过高，开发复杂度高，易出现纠错逻辑错误	高（1人4天，需调用AI接口，有API成本）	PoC测试：验证AI纠错准确性和API延迟，确保延迟<100ms，纠错准确率>90%

Step 3：输出 Tech Spec（技术规范文档）

这是Solutioning的核心输出，也是后续编码的"标准手册"，不能省略。Tech Spec不用写得太复杂，重点包含3点：

架构设计（比如Web版本用MVC架构）
接口规范（比如计算器的核心接口定义，明确请求方式、参数、返回值）
编码规范（比如变量命名、注释要求）

结合计算器平衡方案（Web版本），给大家一个简单可套用的Tech Spec示例：

markdown 复制代码

【计算器Web版本 Tech Spec 核心内容】

1. **架构设计**：采用MVC架构
   - Model层：负责计算逻辑（calc_model.py）
   - View层：负责页面展示（templates/index.html）
   - Controller层：负责接收请求、调用Model、返回结果（app.py）
   降低代码耦合度，方便后续扩展。

2. **接口规范**：核心计算接口统一前缀为 `/api/calc`，支持GET请求，参数采用键值对形式，返回值为JSON格式。
   - 加法接口：`/api/calc/add?num1=10&num2=20`
     返回：`{"code":200,"msg":"success","result":30}`
   - 异常处理：参数非数字时，返回 `{"code":400,"msg":"请输入有效数字","result":null}`

3. **编码规范**：
   - 变量命名采用小驼峰式（如 `calcResult`）
   - 函数命名需体现功能（如 `addNum`）
   - 关键逻辑添加注释，避免冗余代码

Step 4：接口一致性校验（避坑关键）

很多新手做完接口规范就忽略这一步，导致后续Dev Agent生成的接口参数、返回格式不一致，增加调试成本。实操时，我常用的校验方法有3个，简单易落地：

整理一份简易接口文档（表格形式即可），明确每个接口的请求方式、参数类型、返回格式、异常处理，同步给Dev和QA Agent，作为统一标准。
让Dev Agent先生成接口骨架（不写具体业务逻辑），QA Agent根据Tech Spec的接口规范，先校验接口骨架的一致性，不一致直接返回调整。
补充一个简单的接口校验脚本（Python），快速校验接口参数和返回格式，避免手动校验遗漏：

python 复制代码

# 计算器接口一致性校验脚本（简易版）
def check_api_consistency(api_path, param_types, return_format):
    # 模拟接口请求，校验参数类型和返回格式
    print(f"校验接口：{api_path}")
    # 1. 校验参数类型（以加法接口为例，num1和num2需为数字）
    if param_types != {"num1": "int/float", "num2": "int/float"}:
        return False, f"参数类型不符，需符合{param_types}"
    # 2. 校验返回格式（需为JSON，包含code、msg、result字段）
    if not all(key in return_format for key in ["code", "msg", "result"]):
        return False, "返回格式不符，需包含code、msg、result字段"
    return True, "接口校验通过"

# 校验计算器加法接口（贴合Tech Spec规范）
result, msg = check_api_consistency(
    api_path="/api/calc/add",
    param_types={"num1": "int/float", "num2": "int/float"},
    return_format={"code": 200, "msg": "success", "result": 0}
)
print(msg)

小提示 ：接口一致性校验不用搞复杂，核心是 "先统一标准、再校验骨架、最后简单脚本兜底"，这一步能规避后期Dev和QA角色因接口认知不一致导致的返工。

Step 5：风险规避（PoC前置，降低返工率）

结合Trade-off表格中的风险点，列出所有高风险项，提前做PoC验证------不验证不进入编码环节。这是我实战中总结的避坑技巧，能规避80%的后期风险。这里给大家补充一个实战优化版的风险规避模板：

高风险点	对应方案	PoC验证方式	验证标准	应对措施（验证失败时）
AI增强方案API延迟过高	激进方案（AI增强计算器）	调用AI接口，模拟100次加法纠错请求	平均延迟<100ms，纠错准确率>90%	放弃激进方案，改用平衡方案，后期迭代再添加AI功能
Web版本Flask部署失败	平衡方案（Web版本计算器）	本地部署Flask服务，测试页面访问和计算功能	服务启动成功，页面正常交互，计算无错误	简化部署步骤，改用轻量Flask模板，添加部署步骤注释
CLI版本易用性差	保守方案（CLI版本）	模拟用户操作，测试10次基础计算	平均完成时间<10秒	优化CLI交互提示，添加操作指南，仅作为备用方案

小提示 ：风险规避的核心是 "提前预判、重点验证" ，不用对所有风险点都做复杂PoC，聚焦Trade-off表格中 "高风险、高影响" 的项即可，节省时间的同时规避核心风险。

Step 6：方案定稿与角色同步

完成前面5步后，结合Trade-off表格评估结果和PoC验证情况，确定最终方案。例如计算器项目中，平衡方案（Web版本Flask+HTML）是最优选择，既贴合"高效、轻便"的业务目标，又兼顾易用性和开发成本，风险可控、工期合理。

方案确定后，一定要同步给所有AI角色（Analyst、PM、Dev、QA），明确告知"最终采用XX方案，严格遵循Tech Spec中的架构、接口和编码规范"，避免后续角色独立决策。我实战中会专门写一段简短的同步提示，直接传入AI团队的Prompt中：

同步提示示例

"请所有角色同步：本次计算器项目最终采用Web版本（Flask+HTML）方案，严格遵循Tech Spec中的MVC架构、接口规范和编码要求。Dev编码需符合接口定义，QA测试需对照验收标准和接口规范，全程对齐'提升用户计算效率'的业务目标。"

3.3 实战：计算器Solutioning完整落地（PoC+Tech Spec实操）

前面讲了Solutioning的6个步骤，下面这个实战是我当初完整落地的计算器Solutioning流程，从方案 brainstorm 到PoC验证、Tech Spec落地，全程贴合前面的步骤，代码和验证过程都能直接复制实操。

实战前提

已完成Phase 1&2，拿到计算器PRD（核心：Web版本、加减乘除功能、可视化界面）
已安装bmad-builder、Flask框架（Web版本依赖），确保能正常调用Dev、QA Agent
（可选）有AI接口密钥（用于激进方案PoC验证，不用也可跳过激进方案，重点练平衡方案）

实战步骤（完整闭环）

1. 执行Step 1-Step 2：完成3个方案 brainstorm 和Trade-off表格评估（直接使用前面分享的模板），明确"平衡方案（Flask+HTML Web版本）"为候选最优方案，重点验证其部署可行性和接口一致性。

2. 执行Step 3：输出完整Tech Spec（基于前面的示例，补充细节，方便Dev直接复用）：

markdown 复制代码

【计算器Web版本 Tech Spec 完整版】

一、**架构设计**：采用轻量MVC架构
- Model层（calc_model.py）：负责核心计算逻辑，封装add、sub、mul、div四个函数，处理异常（如除数为0）
- View层（templates/index.html）：简单可视化界面，包含两个输入框、四个运算按钮、结果显示区
- Controller层（app.py）：Flask主程序，接收前端请求，调用Model层函数，返回计算结果，处理接口异常

二、**接口规范**：核心计算接口统一前缀 `/api/calc`，支持GET请求
1. 加法接口：`/api/calc/add?num1=xxx&num2=xxx`  
   - 参数：num1（int/float）、num2（int/float），必传
   - 正常返回：`{"code":200,"msg":"success","result":计算结果}`
   - 异常返回：`{"code":400,"msg":"请输入有效数字","result":null}`（参数非数字）
2. 减法接口：`/api/calc/sub?num1=xxx&num2=xxx`（参数、返回格式同加法，逻辑为num1-num2）
3. 乘法接口：`/api/calc/mul?num1=xxx&num2=xxx`（同加法）
4. 除法接口：`/api/calc/div?num1=xxx&num2=xxx`（额外异常：num2=0时，返回 `{"code":400,"msg":"除数不能为0","result":null}`）

三、**编码规范**
- 文件名/函数名：小写字母+下划线（如 `calc_model.py`、`add_num`）
- 变量名：小驼峰式（如 `calcResult`、`inputNum1`）
- 注释要求：核心函数、异常处理逻辑必须加注释
- 冗余控制：不添加PRD外的功能，不引入多余第三方库

3. 执行Step 4：接口一致性校验，使用校验脚本批量验证：

python 复制代码

# 计算器接口一致性校验脚本（完整可运行版）
def check_api_consistency(api_path, param_types, return_format, extra_err=None):
    print(f"校验接口：{api_path}")
    # 1. 校验参数类型（必传参数及类型）
    if not all(param in param_types for param in ["num1", "num2"]):
        return False, "缺少必传参数num1或num2"
    if param_types != {"num1": "int/float", "num2": "int/float"}:
        return False, f"参数类型不符，需符合{param_types}"
    # 2. 校验返回格式（必须包含code、msg、result字段）
    if not all(key in return_format for key in ["code", "msg", "result"]):
        return False, "返回格式不符，需包含code、msg、result字段"
    # 3. 校验额外异常（如除法的除数为0）
    if extra_err and api_path == "/api/calc/div":
        if "除数不能为0" not in extra_err:
            return False, "除法接口缺少除数为0的异常处理"
    return True, "接口校验通过"

# 批量校验所有核心接口
apis = [
    ("/api/calc/add", {"num1": "int/float", "num2": "int/float"}, {"code":200,"msg":"success","result":0}),
    ("/api/calc/sub", {"num1": "int/float", "num2": "int/float"}, {"code":200,"msg":"success","result":0}),
    ("/api/calc/mul", {"num1": "int/float", "num2": "int/float"}, {"code":200,"msg":"success","result":0}),
    ("/api/calc/div", {"num1": "int/float", "num2": "int/float"}, {"code":200,"msg":"success","result":0}, "除数不能为0")
]

for api in apis:
    if len(api) == 4:
        result, msg = check_api_consistency(api[0], api[1], api[2], api[3])
    else:
        result, msg = check_api_consistency(api[0], api[1], api[2])
    print(f"校验结果：{msg}\n")

运行脚本后，若所有接口均提示"接口校验通过"，则说明接口规范一致，可进入下一步；若有异常，及时修改Tech Spec的接口定义，直至校验通过。

4. 执行Step 5：PoC验证（重点验证平衡方案，简化保守/激进方案验证）

平衡方案（Web版本）PoC验证：
- 操作：新建Flask项目，按Tech Spec创建app.py、calc_model.py和templates/index.html三个文件，编写基础代码（Dev Agent可直接生成，传入Tech Spec即可）。
- 验证点：本地启动Flask服务（python app.py），访问localhost:5000，测试四个运算功能，查看响应时间和结果准确性。
- 验证结果：服务启动成功，界面正常交互，加减乘除运算正确，响应时间均<100ms，符合验证标准，PoC通过。
激进方案（AI增强）PoC验证（可选）：
- 操作：调用AI接口，编写简单纠错逻辑，模拟100次错误输入（如非数字、除数为0），测试纠错准确性和接口延迟。
- 验证结果：AI纠错准确率85%（未达到90%的标准），API平均延迟120ms（超出100ms限制），PoC失败，放弃激进方案。

5. 执行Step 6：方案定稿与角色同步

将"Web版本Flask+HTML方案"同步给所有AI角色，补充Dev和QA的专项提示，确保编码和测试对齐Tech Spec：

同步提示示例（传入AI团队Prompt）

"所有角色同步：本次计算器项目最终采用Web版本（Flask+HTML）方案，严格遵循Tech Spec的MVC架构、接口规范和编码要求。Dev需按Tech Spec编写代码，拆分Model/View/Controller三层，确保接口符合定义；QA需重点测试接口一致性、运算准确性和异常处理，对照PoC验证标准，确保功能符合PRD验收要求，全程对齐'提升用户计算效率'的业务目标。"

实战结果与解读

完成以上实战后，我们得到了3个核心输出：

明确的最优方案（Web版本）
可直接复用的Tech Spec（编码标准）
PoC验证报告（确认方案可行）

后续Dev Agent按Tech Spec生成的代码，结构清晰、接口统一，QA Agent测试也有明确依据，不会出现"接口混乱、方案冲突"的问题------这就是Solutioning的价值，提前定好标准、验证风险，后期编码就能事半功倍。

我当初实战时，Dev Agent生成的代码直接贴合Tech Spec，无需大幅修改，仅调整了界面交互细节，QA测试也只发现1个小Bug（除法异常提示不规范），返工率远低于跳过Solutioning的情况，这也印证了"方案化先行"的重要性。

3.4 常见问题与优化技巧（Solutioning踩坑总结）

我在多次实战Solutioning环节时，踩过不少新手易犯的坑，总结了4个最常见的问题，每个问题都对应具体的优化技巧，新手可以直接对照自查：

问题1：方案同质化，3个方案差别不大，无法对比选优

表现：brainstorm的3个方案，本质都是同一种实现方式（比如都是Web版本，只是框架不同），无法通过Trade-off表格对比优劣。
优化技巧 ：强制按 "保守、平衡、激进" 分类，每个方案的核心差异点要明确------保守方案求"快、稳、无依赖"，平衡方案求"兼顾业务与成本"，激进方案求"差异化、超出基础需求"，避免方案同质化。

问题2：PoC验证流于形式，只验证"能运行"，不验证风险点

表现：PoC只简单运行一下代码，确认功能能实现，就认为验证通过，忽略了Trade-off表格中的高风险点（如API延迟、部署难度），后期还是会出现问题。
优化技巧 ：PoC验证要 "聚焦风险点"，而不是"验证功能"，每个方案的PoC重点要对应其风险点------比如激进方案的风险是"API延迟高"，PoC就重点测试延迟；平衡方案的风险是"部署失败"，PoC就重点测试部署流程。

问题3：Tech Spec写得太复杂，Dev/QA Agent看不懂，无法落地

表现：Tech Spec堆砌大量专业术语，架构设计、接口规范写得过于繁琐，AI角色无法理解。
优化技巧 ：Tech Spec要 "简洁、具体、可落地" ，新手不用写完整的技术文档，重点突出 "架构拆分、接口定义、编码规范" 3点，多用示例（比如接口示例、代码片段示例），避免专业术语堆砌，确保AI角色能直接复用。

问题4：方案同步不彻底，部分AI角色偏离方案

表现：方案确定后，只同步给Dev Agent，Analyst、PM、QA Agent未同步，导致测试、需求调整时偏离方案。
优化技巧 ：方案同步要 "全员覆盖、重点强调"，不仅要告知所有AI角色最终方案，还要明确每个角色的核心要求------Dev对齐Tech Spec，QA对齐Tech Spec和PRD，PM不随意新增需求，Analyst跟踪方案是否贴合业务目标，必要时将同步提示直接嵌入每个角色的Prompt中，双重保障。

补充实战小技巧 ：Solutioning环节可以让 QA Agent提前参与，让QA Agent根据PRD和Tech Spec，提前输出简单的测试用例（比如计算器的运算测试、异常测试用例），这样PoC验证时就能直接复用，节省时间，也能确保测试标准和方案对齐。

3.5 总结与进阶挑战

核心总结

Phase 3（Solutioning）是BMAD方法论的 "核心骨架" ，也是连接PRD（做什么）和编码（怎么做）的关键桥梁，其核心精髓就是 "多样性+验证"------不凭感觉选方案，强制 brainstorm 3+差异化方案，通过Trade-off表格客观评估，再用PoC验证高风险点，最后用Tech Spec定好统一标准，让所有AI角色围绕同一个方案发力。

很多新手觉得Solutioning浪费时间，总想跳过这一步直接编码，但实战证明，跳过Solutioning，后期会陷入"接口混乱、方案冲突、返工不断"的困境，花费的时间远比做Solutioning多。对于新手来说，不用追求方案的"完美"，重点是掌握 "多方案对比、风险前置验证、标准统一" 的逻辑，先把闭环跑通，再逐步优化方案质量。

一句话记住Solutioning核心：
先定标准再编码，先验风险再落地，不凭感觉选方案。

进阶挑战（巩固Solutioning实操）

结合前两篇的进阶挑战，给大家准备了一个贴合实战的Solutioning进阶挑战，重点练习"多方案对比、PoC验证、Tech Spec落地"的完整闭环，难度比计算器项目稍高：

需求：基于第二篇进阶挑战生成的 "学生错题本App"PRD（含用户故事、验收标准），完成完整的Solutioning流程。要求：

brainstorm 3个差异化方案（保守、平衡、激进），明确每个方案的具体实现方式（例如：保守=本地文本存储、平衡=Flask+数据库、激进=云存储+AI错题分析）。

用Trade-off表格评估3个方案，重点分析优势、风险、开发成本和PoC验证重点。

输出平衡方案的Tech Spec（明确架构设计、核心接口规范、编码规范）。

完成平衡方案的PoC验证，编写简单的验证脚本，重点验证核心风险点（如数据库连接、错题存储/查询功能）。

编写方案同步提示，同步给所有AI角色，明确各角色的核心要求。

进阶要求：PoC验证后，对比"验证结果"和"Trade-off表格中的风险预判"，分析两者的差异，总结自己在风险预判中的不足（比如"预判数据库连接无风险，但PoC中发现连接超时，需优化数据库配置"），通过复盘进一步提升Solutioning的风险规避能力。

必学！BMAD 方法论架构从入门到精通，深度讲解成就专业提升

下一篇介绍《落地实施------像CTO一样指挥AI编码 (Phase 4: Implementation)》

掌握了方案设计的核心后，本文将聚焦"落地实操"，核心目标是帮助开发者利用Sprint Planning（迭代规划）和Dev Agent，将Phase 3设计的方案转化为可运行的代码，同时借助QA Agent搭建测试闭环，确保代码质量可控、符合规范。

如果以上分享对你有帮助，Star就是最好的鼓励。我是逻极，一名爱写代码也爱写字的程序员。