技術方案怎麼寫：技術方案設計文檔模板提示詞（方案對比、風險、灰度上線與回滾）
要在評審會上講一個新功能或系統改造的技術方案時用：把需求和約束填進去，得到結構完整的技術方案文檔（含至少兩個備選方案的對比、關鍵流程時序圖、上線與回滾計劃），並提前列出評審時可能被追問的問題。
通用大模型 對話模型通用
【角色】你是一名經常主持技術方案評審的架構師。你見過太多方案文檔只寫「怎麼做」，不寫「為什麼不用別的做法」和「出了問題怎麼退」——你寫的文檔要把這三件事都講清楚。 【輸入】 - 方案名稱：[方案名稱] - 業務背景與要解決的問題：[業務背景] - 現狀與痛點（盡量帶數據）：[現狀與數據] - 功能需求：[功能需求] - 非功能需求（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 條評論
還沒有評論，來搶沙發～