技术方案怎么写：技术方案设计文档模板提示词（方案对比、风险、灰度上线与回滚）
要在评审会上讲一个新功能或系统改造的技术方案时用：把需求和约束填进去，得到结构完整的技术方案文档（含至少两个备选方案的对比、关键流程时序图、上线与回滚计划），并提前列出评审时可能被追问的问题。
通用大模型 对话模型通用
【角色】你是一名经常主持技术方案评审的架构师。你见过太多方案文档只写「怎么做」，不写「为什么不用别的做法」和「出了问题怎么退」——你写的文档要把这三件事都讲清楚。 【输入】 - 方案名称：[方案名称] - 业务背景与要解决的问题：[业务背景] - 现状与痛点（尽量带数据）：[现状与数据] - 功能需求：[功能需求] - 非功能需求（QPS、延迟、可用性、数据一致性、合规）：[非功能需求] - 技术栈与现有系统约束：[现有技术栈] - 时间与人力：[工期与人数] - 我倾向的方案（没有就写无）：[倾向方案] 【文档结构】 1. 背景与目标：要解决的问题、可衡量的目标；明确写出「非目标」（这次不做什么）。 2. 现状分析：当前架构、问题的根因与数据。 3. 方案对比：至少 2 个可行方案，再加上「最小改动方案」作为基线。对比维度：实现复杂度、性能、可靠性、运维成本、对现有系统的侵入、团队熟悉度、扩展性。最后给出推荐方案及理由。 4. 详细设计（推荐方案）：架构图（Mermaid）、核心流程时序图（Mermaid sequenceDiagram）、数据模型变更、接口变更、关键算法或状态机。 5. 异常与边界：依赖服务超时或宕机、重复消息、并发冲突、数据不一致时的处理与补偿。 6. 兼容与迁移：老数据迁移、新老版本共存、对上下游的影响。 7. 上线计划：灰度策略（按比例、按用户、开关）、监控指标与告警阈值、回滚方案与回滚的触发条件。 8. 排期与里程碑、风险清单（风险 | 概率 | 影响 | 应对）。 9. 评审待决问题：需要评审会拍板的事项。 【写作约束】 - 我没提供的数据（如当前 QPS）写成「待补充：xxx」，不要编数字。 - 结论先行，每节开头一句话说清结论。 - 不要为了显得全面而堆砌技术名词；每引入一个新组件，都要说明它的运维成本。 【最后附加】 站在评审者的角度，列出最可能被追问的 5 个问题，并给出建议的回答要点。
高亮处换成你自己的内容：[方案名称]、[业务背景]、[现状与数据]、[功能需求]、[非功能需求]、[现有技术栈]、[工期与人数]、[倾向方案]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[非功能需求] 是区分好方案和普通方案的关键，「峰值 2000 QPS、P99 小于 200 毫秒、订单状态不能丢」会直接决定方案选型；不写的话 AI 会给一个看起来什么都好、其实没法评估的方案。[倾向方案] 填了也没关系，模板要求它和备选方案公平对比，评审时更有说服力。
常见坑：
- 只有一个方案的文档在评审会上最容易被问住：「为什么不用 xxx？」
- 回滚方案常被忽略，特别是涉及数据迁移的改动，要写清「数据回不去」时怎么办。
- AI 生成的 Mermaid 图要在团队的文档工具（飞书、Confluence、语雀等）里检查能否渲染。
追问技巧：文档写完后追问「假设你是最挑剔的评审者，指出这份方案最薄弱的三处」；评审后把会议结论贴回去，说「根据评审意见修订第 3、7 节，并在文首加修订记录」。
示例输出
示例，仅供参考（订单超时取消，方案对比节选）
| 方案 | 实现复杂度 | 时效精度 | 运维成本 | 主要风险 |
|---|---|---|---|---|
| 基线：定时任务每分钟扫表 | 低 | 分钟级 | 低 | 订单量大时扫表压力大，需索引支撑 |
| 延迟队列（如 RabbitMQ TTL + 死信队列） | 中 | 秒级 | 中，需维护 MQ | 消息丢失要有兜底扫表 |
| Redis 有序集合按到期时间轮询 | 中 | 秒级 | 中 | 需处理多实例重复消费 |
推荐：延迟队列 + 每 10 分钟一次的兜底扫表；原因是时效满足需求，且兜底任务保证消息丢失时订单最终也会被取消。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～