如果只是把“Kubernetes 和 Docker Swarm 哪个好”这类问题直接丢给大模型，得到的回答通常是一段没有重点的优缺点列表。想让AI真正辅助技术选型或产品决策，关键在于把对比需求拆成可执行的提示词：明确候选对象、列出评估维度、设定评分与输出格式，并要求模型给出基于场景的判断。本文将拆解这类提示词的设计方法，并提供可直接复用的模板。
一、先固定比较对象与场景，AI才有分析基础
比较对象模糊是编写AI对比提示词时最常见的问题。如果只写“比较一下RabbitMQ和Kafka”，大模型并不清楚你关注的是哪个版本、运行在什么环境、团队技术栈如何。模型可能会脑补大规模互联网场景，也可能忽略版本差异，最终输出一段看似全面但实际难以落地的内容。因此，提示词中应当写明方案A和方案B的具体名称、版本、适用场景以及团队背景。
场景信息会直接影响评估权重。例如，同样是消息队列，一个日活五万的小型电商系统与一个每秒百万事件的日志采集平台，对吞吐量、延迟、运维复杂度、消息可靠性的要求完全不同。提示词里可以把这些信息压缩成一小段背景描述，让AI在正确的条件下展开对比。下面是一个基础结构示例。
你是一名资深技术选型顾问，请严格按以下结构完成对比分析。 场景说明：中小型电商系统，日活约5万，团队以Java为主，运维人力有限。 方案A：RabbitMQ 3.13 方案B：Apache Kafka 3.7 评估维度： 1. 消息可靠性：包括确认机制、持久化、故障恢复能力 2. 吞吐量：在常见配置下的每秒消息处理能力 3. 延迟：端到端消息送达延迟表现 4. 运维复杂度：集群部署、监控、升级的难易程度 5. 学习成本：团队从零上手需要的时间 6. 社区生态：文档、客户端库、问题解决资源 输出要求： 先给出每个维度下两个方案的对比说明，再给出选择建议，并说明在什么条件下应选择另一个方案。
二、设置多维评估框架，避免AI只给笼统评价
很多对比提示词只停留在“优缺点”层面，导致模型输出一些泛泛的结论，比如“Go性能好”“Java生态成熟”。这些结论虽然没错，但难以用于真正决策。更有效的做法是建立一个多维评估框架，把方案拆成功能满足度、运行性能、长期成本、生态支持、安全风险、可维护性等维度，并针对每个维度给出简短定义。
功能只是其中一个维度，技术选型还必须关注交付效率、运行表现和长期成本。一个实用框架可以分成四类：交付能力包括功能满足度、开发效率、集成能力；运行表现包括性能、稳定性、可扩展性；长期成本包括许可费用、服务器成本、维护人力、学习曲线；风险因素包括安全、供应商锁定、社区活跃度。这样AI就不会只盯着某项技术指标，而忽略团队维护能力等现实问题。
提示词中还要明确每个维度的统计口径。比如成本维度要说明是否包括云资源、许可证、人力投入；性能维度要说明关注的是单机吞吐还是集群扩展能力。只有口径统一，不同方案的对比才不会失准。可以要求模型以表格形式输出，并加上差异说明。
你是一名云计算架构师，请对比以下两个部署方案。 方案A：容器化部署在云厂商托管Kubernetes集群 方案B：直接使用云厂商Serverless容器服务 评估维度：弹性能力、单位请求成本、运维投入、可观测性、供应商锁定风险、冷启动表现。 输出要求： 为每个维度给出方案A与方案B的表现说明，然后输出一个表格，包含维度、方案A评分、方案B评分、差异说明四列。评分使用1到5分，5分为最优。
三、用评分标准、权重和反方观点提升可靠性
如果直接让AI打分，分数可能偏主观，甚至每次提问结果不一致。原因在于模型缺少明确的评分锚点。提示词应当要求模型先定义每个分值代表什么含义，例如1分表示完全不满足当前场景，3分表示基本可用但需要额外改造，5分表示原生支持且生产成熟。之后再进行评估，可以明显提高评分稳定性。
除了评分标准，权重也能让对比结果更贴近真实决策。不同场景下维度的优先级不同：一个资源紧张的小团队可能更看重学习成本和运维复杂度，而一个大型平台可能更关注扩展性和安全性。可以要求模型先根据场景分配维度权重，再用加权分数生成总分，这样综合建议就不再是“各有利弊”的折中表述。
为了降低大模型偏向主流方案或热门技术的倾向，可以加入反方观点要求。让模型分别模拟方案A支持者和方案B支持者，写出针对对方最有力的反驳意见，最后再给综合判断。这会迫使模型考虑负面信息，减少一边倒的推荐。
你是一名中立技术评估专家。请对比以下两个编程语言方案。 场景：开发一个需要高并发网络通信的后端服务。 方案A：Go 1.22 方案B：Java 21 + Virtual Threads 评估维度：并发模型、内存占用、开发效率、性能调优难度、生态成熟度、招聘难度。 评分规则： 1分：完全不满足当前场景 2分：需要大量改造才能使用 3分：基本可用，但存在明显短板 4分：大部分场景表现良好 5分：原生支持且生产成熟 要求： 1. 先为每个维度写出1分和5分的具体锚点，再给出评分表。 2. 根据场景为每个维度分配权重，权重总和为100%。 3. 先模拟方案A支持者写出两条最有力的反驳。 4. 再模拟方案B支持者写出两条最有力的反驳。 5. 最后给出加权总分和综合评估，并说明在什么具体条件下推荐哪种方案。
四、把提示词模板化，批量生成对比报告
好的对比提示词不应只使用一次。实际工作中有大量重复的评估场景，例如数据库选型、框架调研、云服务对比。可以把这些提示词沉淀为模板，用占位符代替具体对象。每次使用时只需要替换候选方案、场景说明和评估维度，就能快速得到结构一致的对比报告。
模板化还能帮助团队统一评估口径。不同成员如果各自编写提示词，可能关注完全不同的维度，最后难以横向比较。统一模板后，可以固定评估维度、评分规则和输出结构，让不同项目的方案对比保持一致性。下面是一个使用Python进行参数化生成的简单示例。
prompt_template = """
你是一名资深技术顾问，请对比分析以下两个方案。
场景说明：{scenario}
方案A：{plan_a}
方案B：{plan_b}
评估维度：{dimensions}
输出要求：先给出评分表，再给出优缺点清单和决策建议。
"""
scenario = "小型团队选择一个适合快速迭代的Web框架"
plan_a = "Django 5.0"
plan_b = "FastAPI 0.110"
dimensions = "开发效率、性能、异步支持、生态丰富度、学习曲线"
prompt = prompt_template.format(
scenario=scenario,
plan_a=plan_a,
plan_b=plan_b,
dimensions=dimensions,
)
print(prompt)
在实际使用中，还可以根据首次输出继续迭代提示词。如果发现模型遗漏了安全或合规维度，可以追加要求；如果发现结果中出现无法核实的具体版本号或性能数字，可以在模板中加入“对于不确定的信息请明确标注，不要编造具体数据”。经过几轮调整，模板会越来越贴近业务需求，最终成为团队内部可复用的决策支持工具。