技术选型怎么做提示词：框架 / 数据库 / 中间件选型对比评分表与决策建议
在几个技术方案之间犹豫（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 条评论
还没有评论，来抢沙发～