技术方案怎么用AI写？四段Prompt链加3个可抄模板

我在 V2EX 看到过一个让很多人共鸣的帖子：楼主说自己「下午开完需求评审，明天下午就要开技术评审」，而且每次都是开发到一半才发现技术细节有遗漏，方案文档里压根没写。楼下高赞回复更直接：能让你棘手的问题，大概率是开发过程中才暴露的，能提前评估出来的少之又少，成熟的做法是「提出问题，解决问题，然后更新方案」。

时间紧、细节漏、对着空白文档不知道从哪写起------这是写技术方案的三大日常。

这篇不讲「AI 很强」，给一套我自己在用的东西：一条四段式 Prompt 链（需求消化 → 骨架生成 → 人填决策 → 评审模拟），三道人审关卡，外加 3 个逐字可抄的完整模板。模板工具无关，ChatGPT、Claude、通义都能跑。走完这套流程，你带进评审会的是一份骨架完整、数字和决策都有人背书、而且开会前已经被「骂」过一遍的文档。

先划边界：AI 负责让文档「完整」，你负责让文档「正确」

技术方案文档的瓶颈从来不是「写」，是「想」。选型、容量、兼容性边界，这些是决策；把决策组织成章节目录、补全表格格式、换个视角挑刺，这些是体力活。AI 替代的是后者，不是前者。

我在之前一篇 AI Agent 实测文章里跑过 8 类真实任务，文档撰写类（接口文档、变更说明、方案初稿）的结论是：八成情况下 AI 能给出可用骨架，起草一份初稿能省 30 到 40 分钟。但它同时也是最容易出「不可见错误」的地方------字段名给你写错（userId 写成 user_id），参数的业务含义描述得似是而非，格式完美、内容有毒，不逐字核对根本看不出来。

行业层面，「规格先行」已经成了气候：GitHub 官方的 spec-kit（Spec-Driven Development 工具包），我 2026 年 9 月 4 日用 gh api 查的时候 stars 是 133,429。但那套工具面向新项目全流程，仪式感重；我们大多数人面对的是「现有公司里每周要写的评审文档」，需要的是轻量、工具无关、当天就能上手的版本------就是本文这套。

往下走之前，先把 AI 的产出按可信度分三级，后面三个模板的设计全围绕这张分级表：

骨架、章节目录、表格框架、检查清单、简单 mermaid 图，这些格式性工作可以直接用；行业常识、通用方案的优缺点、接口字段名、状态枚举，必须逐项核对；QPS、容量、延迟、成本这类数字，选型结论和放弃理由，兼容性边界，涉密内容，必须人写------AI 填得越有鼻子有眼，越危险。

工作流总览：四段 Prompt 链，卡三道人审关

最常见的误用是一个巨型 Prompt 打过去：「帮我写一份 XX 系统的技术方案」。出来的东西章节齐全、话术专业，然后你在评审会上被问「这个 3000 QPS 哪来的」「为什么选 MQ 不选同步」，一个都答不上------因为答案不是你想出来的，是它编出来的。

我的做法是把「从 PRD 到评审」拆成四段，每段只干一件事，每段的产出过一道人审关才放行：

第一段，需求消化：把 PRD 喂进去，产出一句话需求概括、改动点清单和一份分级的澄清问题清单。人审关①：P0 问题没清零，不许进入写方案阶段。

第二段，骨架生成：带着清零后的问题清单和团队技术栈约束，让 AI 按评审真实章节结构出骨架，所有数字格、结论行留空。

第三段是人的动作，人审关②：你本人把选型决策、容量数字、字段枚举填进骨架，每一处都有出处。

第四段，评审模拟：让 AI 扮演评审会上最严格的架构师、QA、DBA 挑刺。人审关③：挑出的问题逐条处理完，空着的「待填写」全部补完，然后才去开会。

两个打回回路也要有：问题清零关没过，回去补需求澄清；模拟评审挑出硬伤，回骨架阶段改文档。

模板 1：需求消化器------问题清单不清零，不许写方案

方案写不下去，十次有八次不是文笔问题，是需求没懂。第一步千万别让 AI 写方案，让它当质检员，把 PRD 里的窟窿挖出来。

text 复制代码

你是资深后端工程师，我明天要做技术方案评审，现在手上只有 PRD。
请你当我的「需求消化器」：不要写方案、不要给技术选型，只做需求理解和问题排查。

【输入材料】
<<<
（这里贴 PRD 摘要 / 需求评审纪要 / 相关聊天记录。
 涉密内容先脱敏：替换真实服务名、表名、数字量级）
>>>

【背景信息】
- 业务背景：（一句话，例如：订单系统要支持拼团）
- 现有相关系统/模块：（列你知道的，不知道就写「待确认」）
- 团队技术栈：（例如 Java + Spring Cloud + MySQL + Redis + Kafka）

【请严格按以下结构输出】
1. 一句话需求概括：用「谁，在什么场景下，要完成什么，达成什么业务结果」格式
2. 涉及的现有系统与模块：列出可能被改动或被影响的模块，标注「确定 / 推测」
3. 改动点清单：分新增 / 修改 / 废弃三类，每条一行
4. 澄清问题清单（这是重点）：按三级分类，每条注明「为什么问、不问清会怎样」
   - P0 阻塞开发：不澄清就没法动手的（资金口径、状态机定义、兼容范围等）
   - P1 不阻塞但影响方案：有默认答案但需确认的（量级预估、非功能需求等）
   - P2 纯确认：你推测答案、只需对方点头的
5. 验收标准草案：基于 PRD 推导 5-8 条可测试的验收条件

【硬性约束】
- 不允许编造 PRD 里没有的业务规则；信息不足就写「待确认」，不许脑补
- 不允许给技术方案和选型建议，那是下一步的事
- 问题清单少于 5 条，说明你没认真挖，重读材料后重新输出

用法有两个要点。第一，问题分级是这个模板的灵魂：P0 拿去直接找产品和上游确认，P1 给出你的默认答案让对方点头，P2 自问自答。如果输出只有三四条问题，通常是 AI 在讨好你，让它重读材料再来一遍。第二，人审关①卡的就是 P0------我见过太多人带着一脑袋「应该是这样吧」进骨架阶段，写到容量章节才发现业务量级没人说得清，返工两遍。

模板 2：方案骨架生成器------章节对齐真实评审清单，数字格一律留空

章节结构不要自己发明。我在 V2EX 一个讨论设计文档的老帖里看到国内工程师汇总的文档实际构成：模块图、关键流程时序图、ER 图和建表 SQL、接口文档、多泳道流程图、资源配置表、排期。模板的章节就按这份真实清单来，评审委员找什么，你文档里有什么。

方案对比这一节，我借的是 ADR（Architecture Decision Record）的做法。Michael Nygard 2011 年在《Documenting Architecture Decisions》里把这件事讲透了：决策记录要写「我们为什么这样选、放弃了什么替代方案」，而不是只写「用了什么」。所以模板里选型表至少两个候选，每个都要写优缺点和成本，最后一行的结论和放弃理由留给人填。

text 复制代码

你是资深架构师，帮我生成一份可直接进技术评审的方案文档【骨架】。
注意：只要骨架和表格框架。凡是需要真实数据和人工决策的地方，
一律留「【需你填写：xxx】」，绝对不许编造数字和字段名。

【输入 1：需求消化结果（含已清零的澄清问题清单）】
<<<
（贴模板 1 的最终产出）
>>>

【输入 2：团队技术栈与约束】
（例如：主语言 Java，注册中心 Nacos，MySQL 8.0，
 未经批准不许引入新中间件，排期 2 人周）

【输入 3：文档章节要求（按此结构，不许增删大节）】
1) 背景与目标：业务背景、要解决的问题、成功指标（指标留空）
2) 范围与不做什么：本期范围、明确不做的事
3) 现状分析：现有相关模块、当前链路（模块图留图位）
4) 方案对比（ADR 式）：至少 2 个候选方案，每个给
   「方案描述 / 优点 / 缺点 / 资源成本」，最后一行固定为
   「最终选择：【需你填写】；放弃理由：【需你填写】」
5) 详细设计：改动点逐个展开，关键流程留时序图位置
   （可给 mermaid 初稿，节点不超过 8 个）
6) 接口设计：新增/修改接口的签名、入参出参字段表
   （字段名留空给我填，不许编字段名）
7) 数据模型：建表/改表语句框架，字段名、索引、数据量级留空
8) 容量与性能：只给表格框架（预估 QPS / 数据日增量 /
   存储增长 / 峰值假设），每个数字格写「【需你填写：口径=xxx】」，
   并附一行「数字依据」栏
9) 监控与回滚：监控指标与告警阈值框架（阈值留空）、
   回滚步骤、灰度方案
10) 排期与风险：任务拆解表（人日留空）、风险清单与应对

【硬性约束】
- 任何 QPS、延迟、容量、成本、人日数字，一律不许填，
  留「【需你填写】」并标注需要什么口径
- 选型结论行留空；候选方案的优缺点要写透，
  尤其要逼我回答「放弃了什么、为什么放弃」
- 接口字段名、表字段名、状态枚举不许编造，全部留空
- 每节末尾加一行「本节待办：」，列出我需要补的内容

这个模板最硬的一条约束是「不许填数字」。容量与性能节只给表格框架和口径提示，每个数字格写「【需你填写】」。原因在失败边界一节展开，这里先说结论：AI 填的 QPS 和存储增量全是编的，而且编得特别像真的。

人审关②：AI 给选项，你拍板

骨架出来之后，轮到你干这份文档里唯一不可外包的活。

系统设计类问题（功能放哪个服务、事件驱动还是同步调用、怎么分表），AI 能给你一份很漂亮的选项分析，但它给的是选项，不是决策。决策依赖的上下文它一个都没有：团队的技术栈底线、运维能不能 hold 住新中间件、业务增长预期、成本预算。这些在你和你同事的脑子里，不在模型里。

这一关你要填四类东西：

选型结论和放弃理由：ADR 表最后一行。放弃理由尤其要自己写，它体现的是团队约束，这是评审会上最容易被追问的地方。
容量数字：每个数字附口径和来源------监控取数、压测结果、还是业务方预估，写清楚。
字段名与枚举：接口字段、表字段、状态枚举，照着现有代码和接口文档逐个抄。
兼容性边界：老数据怎么办、老接口调用方怎么办、App/前端/小程序三端是否同步发布。

填完这四类，这份文档才真正是你的------评审会上每个数字你都答得出来处。

模板 3：评审模拟器------开会前先让 AI 骂你一遍

回到开头那个 V2EX 帖子的高赞结论：棘手问题大多在开发中才暴露，提前能评估出来的少之又少。我们能做的，是把「开发中暴露」尽量提前到「评审前暴露」------用一个新鲜的、不客气的视角把文档挑一遍。你自己看自己的稿子有知识的诅咒，看三遍都觉得没问题；AI 没有。

text 复制代码

你是我司技术评审委员会里最严格的三个人：
吹毛求疵的架构师、盯异常流的 QA、抠 SQL 的 DBA。
我要把下面这份技术方案草稿带去评审会，
请你们提前开一次「模拟评审」，往死里挑刺。

【方案草稿】
<<<
（贴草稿全文，涉密信息已脱敏）
>>>

【评审规则】
1. 按以下维度逐个检查，每个维度至少给 2 个问题
   （没问题也要说明你检查了什么）：
   - 边界条件：空值、超限、并发、重复提交、幂等
   - 异常与回滚：失败链路、重试策略、回滚步骤是否可执行、灰度怎么切
   - 容量依据：每个数字是否有口径和来源，峰值假设是否站得住
   - 兼容性：老数据怎么办、老接口调用方怎么办、
     App/前端/小程序三端是否同步
   - 安全与权限：越权、敏感数据、资金/库存类操作的防护
   - 监控告警：出问题靠什么发现，告警阈值是否有依据
   - 排期依赖：跨团队依赖、关键路径、缓冲时间
2. 每个问题按严重度分级：
   - 【评审会必挂】逻辑硬伤、数据安全、回滚缺失
   - 【会被追问】依据不足、口径不清、遗漏场景
   - 【建议优化】表达、结构、可读性
3. 输出格式：问题编号 | 分级 | 所在章节 | 具体问题
   （引用原文）| 为什么是问题 | 我该补什么
4. 最后给出「评审会高频追问预测」：列 5 个评审人
   最可能当场问的问题

【约束】
- 只挑刺，不许帮我改文档；不许说「整体不错」这类安慰话
- 拿不准的标「存疑」，但不许跳过任何维度
- 草稿里任何【需你填写】还空着，直接记为【评审会必挂】

用法：把输出当成 checklist，逐条标「已修复 / 接受并说明理由 / 存疑待查」。人审关③卡的是这个逐条处理的动作，不是 AI 的判断本身------它会误报，会过度保守，没关系，宁可多问一句。最后那 5 个高频追问，提前把答案准备好，评审会上你会感谢自己。

图怎么办：mermaid 初稿可用，复杂图别强求

画图是另一个重灾区。V2EX 有个专门讨论文档画图的帖子，三十多条回复里最高频的吐槽是「经常能描述出这个意思，但画出来就不对劲」。社区验证下来可行的路子，是让 AI 输出 mermaid 或 PlantUML 语法再渲染，但要在 prompt 里加足风格规范，而且图不能复杂。

我的经验线是 8 到 10 个节点：这个规模以内，时序图、简单流程图 AI 出的初稿改改能用；超过 10 个节点的模块架构图，它连线会错乱------模块一多就把 A 的依赖连到 B 头上。复杂图老老实实自己画，或者拆成几张小图。模板 2 里把 mermaid 初稿节点数限制在 8 个以内，就是这个原因。

失效边界：这六种情况别硬用

涉密材料别直接贴公网模型。 PRD、公司代码、线上配置，先脱敏：服务名、表名、真实数字量级统统替换掉，或者干脆走公司内部部署的模型。这条没有侥幸。

数字一定会被编。 QPS、延迟、容量、成本、人日，AI 会填得有鼻子有眼但全是猜的。模板里硬性留空就是防这个；评审会上被问「这个数字哪来的」答不上，属于事故级尴尬。

选型结论不能让 AI 拍板。 候选方案的优缺点它可以帮你写透，结论行和放弃理由必须你写------那背后是团队约束，模型不知道。

图别贪复杂。 简单 mermaid 可用，大图连线错乱，必须人审。

别追求文档完美。 那个设计文档老帖里也有反面声音：「文档还没写完需求就变了」「国内都是走形式」。我的回应是：需求变得快，更要把关键路径优先落纸------接口契约、数据模型、回滚方案这三样先写扎实，其余保持轻。方案文档最大的价值是逼你在动手前把事情想一遍，文档本身只是副产物。

字段级错误不可见。 userId 写成 user_id 这种错，格式完美、肉眼难查。接口字段、状态枚举、业务术语，逐个对着代码核，别信任何一眼看上去对的东西。

写在最后

这套流程的本质就一句话：AI 负责让文档完整，你负责让文档正确。它起草、它挑刺，你决策、你背书。

今天就能做的最小一步：不用等下个需求，把手头任何一个 PRD 贴进模板 1，先跑一遍需求消化器，把 P0 问题清单发给产品。问题问出口的那一刻，你已经比昨天更接近一份能过审的方案了。

参考资料：

GitHub spec-kit：gh api repos/github/spec-kit，2026-09-04 抓取，stars 133,429
Michael Nygard，《Documenting Architecture Decisions》，2011（adr.github.io）
V2EX 主题 1142562《做技术方案的时间大概多久？》、1189173《写文档画图真的很繁琐，如何用 ai 助力？》、597639《想听听大家对写开发文档或者设计文档的看法》
本号 032《我让 AI Agent 干了一个月真实工作：8 类任务实测》

🔧 文中用到的完整 Prompt

以上我分享了最核心的几条，完整版合集（共 42 条，涵盖 Code Review · 重构 · 单测生成 · 架构设计 · AI Agent 调教）已整理好。

回复「prompt」即可获取，持续更新。

如果这篇对你有帮助，转发给你的程序员朋友 --- 大家都在摸索 AI 提效，你的分享可能帮他省很多时间。