周一早上，你要写技术方案了
技术选型、架构设计、风险评估、排期预估。
这些内容写不好，评审会上一轮就被怼回来。写得好，开发顺风顺水。
这个模板解决的是整个技术方案写作流程：从思路梳理到最终文档，每一步都有对应的AI辅助方式。
模板一：技术方案自动生成
适合场景：你有一个大概想法，需要AI帮你写成一份结构完整的技术方案文档。
你是一位资深技术架构师，擅长写清晰、可落地技术方案。请帮我写一份技术方案文档。
【项目背景】
[简述你要做什么，比如：设计一个用户积分系统]
【核心需求】
1. [需求1]
2. [需求2]
3. [需求3]
【技术约束】
- 团队技术栈：[如：Go + MySQL + Redis + Kafka]
- 预计日活：[数字]
- 预算/资源限制：[如有]
【输出要求】
请按以下结构输出完整的技术方案：
## 一、需求分析与拆解
- 功能模块划分
- 非功能性需求（性能/安全/可维护性）
## 二、整体架构
- 系统架构图描述（用文字描述即可）
- 核心模块关系说明
- 数据流向说明
## 三、技术选型
- 每个模块的选型理由（对比2-3个方案）
- 为什么不用其他方案
## 四、数据库设计
- 核心表结构（字段+类型+索引）
- 分库分表策略（如果涉及）
- 缓存策略
## 五、关键技术方案
- 高可用方案
- 容灾/降级策略
- 监控方案
## 六、开发计划
- 模块拆解（按开发阶段）
- 里程碑时间节点
- 风险点及应对措施
## 七、成本预估
- 服务器成本
- 人力成本
- 其他成本
模板二：技术方案评审找茬（红队模式）
适合场景：方案写好了，但在评审之前让AI当"反派"帮你挑毛病。
你是一位挑剔的技术评审专家，以毒舌著称。请帮我评审以下技术方案，找出所有问题。
【技术方案内容】
[粘贴你的技术方案全文]
请从以下维度逐条找出问题：
1. 架构合理性 — 有没有不合理的地方？
2. 性能瓶颈 — 在高并发/大数据量下会挂在哪？
3. 可扩展性 — 日活翻10倍后哪里会最先撑不住？
4. 安全性 — 有没有安全漏洞？
5. 可维护性 — 3个月后谁来接手？能看懂吗？
6. 成本效率 — 有没有更省资源的做法？
7. 遗漏项 — 技术方案里应该写但没写的东西
每个问题给出：
- 问题描述
- 严重程度（S/M/L）
- 修改建议（如果方便的话）
最后给一个总分（0-10分），并列出 Top 3 最该改的问题。
模板三：技术方案改写（从口语到文档）
适合场景：你在会上口头描述了方案，录音转文字后乱七八糟，需要AI帮你整理成正式文档。
以下是我口头描述的技术方案录音转写文本，内容比较零散、口语化。
请帮我整理成一份结构化的技术方案文档，要求：
1. 提取核心观点和关键决策
2. 补充逻辑连接，让文档读起来连贯
3. 识别模糊表述并标注「需确认」
4. 保持我原有的技术决策和思路不变
5. 输出格式为正式技术文档（Markdown）
【原始文本】
[粘贴转写文本]
模板四：技术方案对比分析
适合场景：有两个或多个方案，需要客观对比后再做决定。
我正在做一个技术决策，需要在以下两个方案中选择一个：
【方案A】
[描述]
【方案B】
[描述]
【决策标准（按重要性排序）】
1. [标准1]
2. [标准2]
3. [标准3]
请帮我做一个对比分析：
- 按上述标准逐项打分（1-10）
- 列出每个方案的优势和劣势
- 给出推荐意见和理由
- 如果可能，提出一个融合方案的思路
使用技巧
先想清楚再问。 技术方案Prompt最值钱的部分是你提供的「项目背景」和「技术约束」。如果你只丢一句"帮我设计一个电商系统"，AI给你的是一个泛泛而谈的模板。给它越具体的约束，出来的方案越落地。
用模板二做预评审。 在正式评审前，用红队模式跑一遍。你会发现很多平时忽略的问题——尤其是"日活翻10倍后哪里会先挂"这种问题，自己写方案时很少会想那么远。
让AI帮你列风险清单。 技术方案评审会上，最容易被问倒的是"如果XX挂了怎么办"。用模板一的第七节提前让AI帮你列一份风险清单，会前心里有底。
保存你的Prompt模板。 每次写完技术方案后，把这个Prompt和你的项目背景一起存下来。下次做类似项目时，改动几个字段就能复用，效率提升很明显。
效果示例
输入（项目背景）：
【项目背景】
公司需要开发一个推送系统，支持App/Web/短信三种渠道，日均推送量500万。
【核心需求】
1. 支持定时推送和实时推送
2. 支持按标签精准推送（用户画像匹配）
3. 单条推送响应时间<1秒
4. 支持推送频率限制（每个用户每天最多3条）
【技术约束】
- 团队技术栈：Go + MySQL + Redis + Kafka
- 当前日活50万，预计半年后到200万
- 有现成的消息队列基础设施
AI输出（架构部分摘要）：
二、整体架构
系统分为四层：
接入层：Go微服务，负责接收推送请求、参数校验、频率限制判断。单机QPS目标1000+。
队列层：Kafka作为消息队列，按topic区分渠道（app/web/sms）。实时推送走高优先级topic，定时推送走低优先级topic。
分发层：消费者集群，按用户标签进行消息路由。支持Fanout模式（一个推送任务分发给多个渠道）。
渠道层：各渠道SDK/Adapter，统一接口适配不同推送通道（APNs、FCM、自定义SDK、短信网关）。
核心数据流：PushRequest → 接入校验 → Kafka → 分发消费 → 渠道Adapter → 触达用户
红队评审（模板二）输入后，AI给出：
| 问题 | 严重程度 | 建议 |
|---|---|---|
| Kafka消费者没有处理消息失败的重试机制 | M | 增加DLQ死信队列 + 指数退避重试 |
| 频率限制只用了Redis SETNX，无法做按用户维度的滑动窗口 | S | 改用Redis SORTED SET记录每次推送时间 |
| 未考虑推送任务的去重（同一个用户被同一campaign重复添加） | M | 在投递前加一层布隆过滤器去重 |
| 监控只提了QPS，缺少延迟和错误率指标 | L | 增加P99延迟监控和渠道成功率指标 |
| 推送渠道SDK异常时没有熔断机制 | M | 增加Hystrix/Resilience4j熔断器 |
总分：6.5/10
💡 下一步： 这周如果你要写技术方案，先把模板一跑一遍，拿到初稿再手动改。效率绝对比从零写快一倍以上。