技術選型怎麼做提示詞：框架 / 數據庫 / 中間件選型對比評分表與決策建議
在幾個技術方案之間猶豫（React 還是 Vue、PostgreSQL 還是 MongoDB、自建還是用雲服務）時用：讓 AI 先把評價維度和權重跟你的實際約束對齊，再逐項打分對比，列出需要驗證的關鍵假設和最小驗證方案，而不是給一個「看情況」的回答。
通用大模型 對話模型通用
你是一名務實的技術負責人，做選型時最看重團隊能否長期維護，而不是技術是否新潮。請幫我做一次技術選型。 - 選型對象：[如 Web 前端框架、主數據庫、任務隊列] - 候選方案：[方案 A、方案 B、方案 C] - 項目情況：[項目類型、預計規模、生命週期] - 團隊情況：[人數、現有技能、招聘難度] - 硬性約束：[如必須支持私有化部署、預算有限、合規要求] - 我目前的傾向和原因：[沒有就寫無] 步驟： 1. 確定評價維度和權重：從這些候選維度中挑出與我的情況相關的（功能是否滿足、性能、學習與招聘成本、生態與社區活躍度、長期維護風險、運維成本、許可證、與現有系統的集成成本、廠商鎖定），給出權重和理由。硬性約束不參與打分，不滿足直接淘汰。 2. 對比表：維度 | 權重 | 各方案得分（1 到 5）| 打分依據。打分依據要具體，不能只寫「好」「一般」。 3. 計算加權總分，但明確說明：分數只是輔助，真正決定結論的是哪一兩個維度。 4. 關鍵假設：列出影響結論的關鍵假設（例如「數據量三年內不超過 1 億行」「團隊能在一個月內上手」），並說明如果假設不成立，結論會怎麼變。 5. 驗證方案：針對最沒把握的假設，設計一個一到兩週內能完成的最小驗證（原型、壓測、關鍵功能演示），寫清成功標準。 6. 結論：推薦哪個方案；不推薦的方案在什麼情況下會變成更好的選擇。 7. 我的傾向如果存在明顯的認知偏差（比如只因為熟悉或者只因為新），直接指出。 涉及版本特性、許可證變化、項目維護狀態等可能已經變化的資訊，標註「需核對最新官方資訊」。
高亮處換成你自己的內容：[如 Web 前端框架、主數據庫、任務隊列]、[方案 A、方案 B、方案 C]、[項目類型、預計規模、生命週期]、[人數、現有技能、招聘難度]、[如必須支持私有化部署、預算有限、合規要求]、[沒有就寫無]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[團隊情況] 和 [硬性約束] 往往比技術本身更決定結果。三個人的團隊都只會 Vue，選 React 帶來的招聘和學習成本，通常比兩個框架之間的技術差異重要得多。[我目前的傾向和原因] 盡量誠實地寫，AI 會幫你檢查是不是被偏好帶偏了。
常見坑：
- 打分表看起來很科學，但權重是隨手定的，結論就可以被任意操控。先討論清楚權重再打分。
- AI 對某些項目當前的維護狀態、許可證變化可能掌握的不是最新資訊，這類資訊一定要自己去官方倉庫和公告核實。
- 只比較功能，忽略「三年後誰來維護」。項目生命週期越長，維護和招聘成本的權重應該越高。
追問技巧：追問「如果你是方案 B 的忠實支持者，你會怎麼反駁這個結論」，讓 AI 從對立面檢驗結論；或者讓它把結論寫成一份可以發給團隊討論的 ADR（參考 1020 號提示詞）。
示例輸出
示例，僅供參考（內部管理後台：React 與 Vue，節選）
| 維度 | 權重 | React | Vue | 依據 |
|---|---|---|---|---|
| 團隊現有技能 | 30% | 2 | 5 | 3 人中 3 人有 Vue 項目經驗，無人用過 React |
| 後台組件庫成熟度 | 25% | 4 | 4 | 兩者都有成熟的中後台組件庫 |
| 招聘難度 | 15% | 4 | 4 | 本地市場兩者都容易招到 |
| 長期維護風險 | 20% | 5 | 4 | 均為大型社區維護，需核對最新官方資訊 |
結論：推薦 Vue。決定性因素是團隊技能（權重最高且差距最大）。如果未來要和公司內已有的 React 組件庫深度共用代碼，這個結論需要重新評估。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～