【人工智能】大模型提示词实战：生成技术方案对比文档的提示词模板

本文介绍了如何利用大模型生成高质量技术方案对比文档的提示词模板。通过5个核心模块设计：明确对比对象、定义对比维度、要求数据量化、结合业务场景和指定输出格式，有效解决了传统方式耗时、维度不全等问题。文章提供了通用模板和3个实战案例（数据库选型、缓存中间件选型和架构选型），展示了模板的具体应用方法。同时针对常见问题如维度缺失、数据不准确等给出了解决方案，并扩展了消息队列、搜索引擎等其他应用场景。最后分

猩猩优越

736人浏览 · 2025-09-26 17:22:53

猩猩优越 · 2025-09-26 17:22:53 发布

大模型提示词实战：生成技术方案对比文档的提示词模板

1. 前言

在技术工作中，我们经常需要对比不同的技术方案。比如选择数据库时，要对比 MySQL 和 PostgreSQL 的性能差异；设计架构时，要对比微服务和单体架构的适用场景；选型中间件时，要对比 Redis 和 Memcached 的功能特性。

传统的技术方案对比，需要手动收集资料、整理维度、填充数据，整个过程耗时耗力，还容易遗漏关键对比项。而借助大模型生成技术方案对比文档，能大幅提升效率，但前提是要有精准的提示词 —— 如果提示词模糊，大模型输出的对比内容会出现维度混乱、数据不准确、重点不突出等问题。

本文将聚焦 “技术方案对比文档” 这一高频场景，从核心需求分析、提示词模板设计、实战案例演示、常见问题解决等方面，详细讲解如何设计提示词模板，让大模型稳定输出高质量的技术方案对比文档，帮助技术人员节省时间、聚焦核心决策。

2. 技术方案对比文档的核心需求与痛点

在设计提示词模板前，我们需要先明确技术方案对比文档的核心需求，以及传统方式和普通提示词生成时的痛点，这样才能让模板更贴合实际使用场景。

2.1 核心需求

技术方案对比文档的核心目标是 “为决策提供依据”，因此需要满足以下 3 个需求：

2.1.1 对比维度全面

需覆盖技术方案的关键维度，避免因维度缺失导致决策偏差。常见的对比维度包括：

功能特性：是否支持某核心功能（如数据库是否支持事务、中间件是否支持分布式锁）；

性能表现：在特定场景下的性能数据（如 QPS、响应时间、吞吐量）；

适用场景：适合的业务场景（如高并发、高可用、数据量大的场景）；

成本投入：部署成本、运维成本、学习成本（如是否需要专业运维人员、学习曲线陡峭程度）；

兼容性与扩展性：是否兼容现有系统、后续扩展是否方便（如是否支持水平扩容、是否兼容其他技术栈）；

社区与生态：社区活跃度、文档丰富度、第三方工具支持（如是否有成熟的监控工具、插件）。

2.1.2 数据准确且量化

对比内容不能只停留在 “定性描述”（如 “性能较好”“成本较低”），需尽量包含量化数据（如 “QPS 可达 10 万”“部署成本每月 500 元”），这样才能更直观地判断方案优劣。

2.1.3 结论清晰且有针对性

对比文档末尾需给出明确的 “选型建议”，并结合具体业务场景说明 “哪种方案更适合”，而不是泛泛而谈 “各有优势”。

2.2 传统方式与普通提示词的痛点

2.2.1 传统手动制作的痛点

耗时久：收集不同方案的资料（如官网文档、技术博客、测试报告）需要 1-2 天，整理成对比表格和文档又需要半天到 1 天；

维度不全：容易遗漏个性化维度（如某业务需 “支持国产化操作系统”，传统对比时可能忘记添加该维度）；

数据滞后：手动收集的数据可能是几个月前的，无法反映方案最新版本的特性（如数据库新版本新增的功能）。

2.2.2 普通提示词生成的痛点

如果仅用 “对比 MySQL 和 PostgreSQL”“生成微服务与单体架构的对比文档” 这类简单提示词，大模型输出会存在以下问题：

维度混乱：对比维度随机排列（如先讲性能，再讲社区，又回头讲功能），逻辑不清晰；

数据模糊：缺乏量化数据，多用 “性能较高”“扩展性好” 等定性描述，无法支撑决策；

重点缺失：不结合具体业务场景，输出的对比内容 “大而全” 但无针对性（如业务需要 “高并发读写”，但对比中未重点突出该场景下的表现）；

结论笼统：末尾结论仅说 “各有优势，需根据实际情况选择”，未给出具体选型建议。

3. 生成技术方案对比文档的提示词模板设计逻辑

要解决上述痛点，提示词模板需要包含 “明确对比对象”“定义对比维度”“要求数据量化”“结合业务场景”“指定输出格式” 5 个核心模块。这 5 个模块环环相扣，确保大模型输出的内容全面、准确、有针对性。

3.1 模块 1：明确对比对象与背景

该模块需清晰说明 “对比哪几个技术方案”“为什么要对比（业务背景）”，避免大模型误解对比范围。

3.1.1 核心内容

对比方案名称：明确列出需要对比的技术方案，包括版本信息（如 “MySQL 8.0”“PostgreSQL 14”，而非仅写 “MySQL”“PostgreSQL”）；

业务背景：说明对比的目的和业务场景（如 “为电商平台订单系统选择数据库，订单系统日均订单量 100 万，要求支持事务、高并发读写，延迟低于 100ms”）。

3.1.2 示例表述

“需要对比的技术方案：① MySQL 8.0（InnoDB 引擎）；② PostgreSQL 14。业务背景：为电商平台订单系统选择主数据库，该系统日均订单量 100 万，峰值订单量每秒 5000 笔，核心需求包括：支持 ACID 事务、高并发读写（读多写少）、数据延迟低于 100ms、支持按月分表。”

3.2 模块 2：定义对比维度与子项

该模块需提前规划对比维度和每个维度下的子项，确保对比内容全面且逻辑清晰。维度设计需兼顾 “通用维度” 和 “业务个性化维度”。

3.2.1 通用维度（适用于大多数技术方案对比）

功能特性：子项包括 “核心功能支持情况”“特有功能”“不支持的功能”；

性能表现：子项包括 “并发能力（QPS/TPS）”“响应时间”“吞吐量”“资源占用（CPU / 内存）”；

适用场景：子项包括 “数据量范围”“并发量范围”“业务类型适配（如读多写少、写多读少）”；

成本投入：子项包括 “部署成本（硬件 / 云资源）”“运维成本（是否需专职运维）”“学习成本（团队熟悉程度）”；

兼容性与扩展性：子项包括 “与现有技术栈兼容性”“水平扩容能力”“垂直扩展能力”；

社区与生态：子项包括 “社区活跃度（GitHub 星数 / Issues 处理速度）”“文档丰富度”“第三方工具支持（监控、备份工具）”。

3.2.2 个性化维度（根据业务需求添加）

例如：

数据库对比：需添加 “事务支持”“分表分库能力”“索引类型支持（如是否支持全文索引、空间索引）”；

中间件对比（如缓存）：需添加 “数据结构支持”“过期策略”“分布式锁支持”；

架构对比（如微服务 vs 单体）：需添加 “开发效率”“部署复杂度”“故障影响范围”。

3.2.3 示例表述

“对比维度及子项：

功能特性：① 事务支持（是否支持 ACID、隔离级别）；② 索引支持（是否支持 B-tree、全文索引、哈希索引）；③ 分表分库能力（是否原生支持、支持方式）；

性能表现：① 并发读能力（QPS，基于 4 核 8G 服务器）；② 并发写能力（TPS，基于 4 核 8G 服务器）；③ 响应时间（单条查询 / 写入延迟，单位 ms）；④ 资源占用（4 核 8G 服务器下，日均 CPU 使用率、内存占用）；

适用场景：① 数据量范围（单表支持最大数据量）；② 并发量适配（支持的每秒最大读写次数）；③ 业务类型（读多写少 / 写多读少 / 读写均衡）；

成本投入：① 部署成本（4 核 8G 云服务器月均费用，单位元）；② 运维成本（是否需专职 DBA、每周运维耗时）；③ 学习成本（团队现有成员中，熟悉该数据库的人数占比）；

兼容性与扩展性：① 与现有技术栈兼容性（是否支持 Java/Python 项目连接、是否支持 MyBatis/ORM 框架）；② 水平扩容能力（是否支持主从复制、读写分离）；

社区与生态：① GitHub 星数、Issues 平均处理时间；② 官方文档完整性；③ 监控工具支持（是否支持 Prometheus、Grafana）。”

3.3 模块 3：要求数据量化与来源

该模块需强制大模型输出量化数据，并说明数据来源，确保对比内容的准确性和可信度。

3.3.1 核心要求

数据量化：每个性能相关的子项必须包含具体数值（如 “QPS 可达 8000”，而非 “QPS 较高”）；

数据来源：说明数据的来源（如 “官方测试报告”“第三方测评（如 PingCAP 博客）”“行业通用数据”），若为估算数据需注明（如 “基于 4 核 8G 服务器的估算数据”）。

3.3.2 示例表述

“每个对比子项需包含量化数据（不允许定性描述），例如‘并发读 QPS’需写‘8000’，而非‘较高’；数据来源需标注（如‘MySQL 官方性能测试报告’‘PostgreSQL 14 官方文档’），若为估算数据需注明‘基于 4 核 8G 服务器的估算值’。”

3.4 模块 4：指定输出格式与结构

该模块需明确文档的输出格式，包括 “整体结构”“表格样式”“结论要求”，确保文档清晰易读，便于快速获取关键信息。

3.4.1 整体结构要求

文档标题：需包含对比方案和业务场景（如 “电商订单系统数据库对比文档：MySQL 8.0 vs PostgreSQL 14”）；

文档目录：列出文档包含的章节（如 “1. 对比背景与目标”“2. 对比维度与子项”“3. 详细对比内容”“4. 选型建议”）；

详细对比：用表格呈现每个维度的对比内容，表格需包含 “对比维度”“对比子项”“方案 A（如 MySQL 8.0）”“方案 B（如 PostgreSQL 14）”“数据来源” 5 列；

选型建议：分 “推荐方案”“推荐理由”“不推荐方案的局限性”“注意事项” 4 个子项表述。

3.4.2 示例表述

“输出格式要求：

文档标题：需包含对比方案和业务场景，如‘电商订单系统数据库对比文档：MySQL 8.0 vs PostgreSQL 14’；

文档目录：包含‘1. 对比背景与目标’‘2. 对比维度与子项说明’‘3. 详细对比表格’‘4. 选型建议’4 个章节；

详细对比表格：每个对比维度单独成表，表格列包括‘对比子项’‘MySQL 8.0（InnoDB）’‘PostgreSQL 14’‘数据来源’，例如‘性能表现’维度的表格需包含‘并发读 QPS’‘并发写 TPS’等子项的具体数据；

选型建议：需明确‘推荐方案’，并结合业务场景说明‘推荐理由’（如‘推荐 MySQL 8.0，因为订单系统读多写少，MySQL 的读性能更优，且团队现有 80% 成员熟悉 MySQL’），同时说明‘不推荐方案的局限性’（如‘PostgreSQL 14 在高并发读场景下 QPS 仅为 MySQL 的 70%，无法满足订单系统峰值读需求’），最后给出‘注意事项’（如‘使用 MySQL 时需开启主从复制，实现读写分离’）。”

3.5 模块 5：添加约束条件（可选）

该模块用于添加特殊要求，如 “避免遗漏某维度”“重点突出某场景”“控制文档长度” 等，进一步优化输出内容。

3.5.1 常见约束条件

重点突出：要求大模型在对比中重点强调某业务场景的表现（如 “重点突出高并发读场景下的性能对比，该场景是订单系统的核心场景”）；

避免遗漏：明确要求不能遗漏某关键子项（如 “必须包含‘分表分库能力’的对比，订单系统需按月分表存储历史订单”）；

语言风格：要求语言简洁专业，避免口语化（如 “使用技术文档风格，避免‘挺好的’‘还不错’等口语化表述”）。

3.5.2 示例表述

“约束条件：1. 重点突出‘高并发读场景’的性能对比（订单系统日均读请求占比 70%）；2. 必须包含‘分表分库原生支持情况’的对比，订单系统需按月分表存储 1 年以上的历史订单；3. 语言简洁专业，每个对比子项的描述不超过 20 字，避免口语化表述。”

4. 通用提示词模板（可直接复用）

基于上述 5 个模块，整理出 “生成技术方案对比文档” 的通用提示词模板，使用时只需替换模板中的占位符（【】内的内容）即可。

4.1 通用提示词模板

需求：生成技术方案对比文档，请按以下要求输出：

一、对比对象与业务背景

1. 对比方案：【列出需对比的技术方案，包含版本信息，如“① MySQL 8.0（InnoDB）；② PostgreSQL 14”】

2. 业务背景：【说明对比目的和业务场景，包含核心需求，如“为电商订单系统选择数据库，日均订单100万，需支持事务、高并发读，延迟<100ms”】

二、对比维度与子项

请按以下维度和子项进行对比，若有个性化维度需补充在“其他个性化维度”中：

1. 功能特性

- 子项1：核心功能支持情况（如事务、索引类型）

- 子项2：特有功能（其他方案不具备的功能）

- 子项3：不支持的关键功能（业务可能用到的功能）

2. 性能表现（基于【说明服务器配置，如“4核8G云服务器”】）

- 子项1：并发能力（读QPS/写TPS）

- 子项2：响应时间（单条查询/写入延迟，单位ms）

- 子项3：资源占用（CPU使用率、内存占用，单位%/GB）

3. 适用场景

- 子项1：数据量范围（单表/单实例支持最大数据量）

- 子项2：并发量适配（支持的每秒最大读写次数）

- 子项3：业务类型适配（读多写少/写多读少/读写均衡）

4. 成本投入

- 子项1：部署成本（【说明配置】下的月均费用，单位元）

- 子项2：运维成本（是否需专职人员、每周运维耗时）

- 子项3：学习成本（团队熟悉该方案的人数占比）

5. 兼容性与扩展性

- 子项1：与现有技术栈兼容性（如支持的开发语言、框架）

- 子项2：水平扩容能力（如是否支持主从、分片）

- 子项3：垂直扩展能力（如是否支持升级硬件）

6. 社区与生态

- 子项1：社区活跃度（GitHub星数、Issues处理时间）

- 子项2：文档丰富度（官方文档完整性、是否有中文文档）

- 子项3：第三方工具支持（监控、备份、迁移工具）

7. 其他个性化维度（根据业务需求补充）

- 子项1：【如“分表分库能力”“国产化适配”等】

- 子项2：【补充其他个性化子项】

三、数据要求

1. 所有性能相关子项必须包含量化数据（如“QPS=8000”，不允许“QPS较高”等定性描述）；

2. 数据来源需标注（如“官方测试报告”“第三方测评”“行业通用数据”），估算数据需注明“基于【配置】的估算值”；

3. 若某子项无明确数据，需说明“暂未获取到相关数据”，不允许空白或模糊表述。

四、输出格式

1. 文档标题：需包含对比方案和业务场景，如“【业务场景】技术方案对比文档：【方案A】vs【方案B】”；

2. 文档结构：包含以下4个章节，每个章节需单独成段，使用二级标题（如</doubaocanvas>

“## 1. 对比背景与目标”“## 2. 对比维度与子项说明”）：

章节 1：对比背景与目标，包含 “对比方案列表”“业务背景”“核心需求” 三个子部分；

章节 2：对比维度与子项说明，逐一解释每个维度及子项的含义（如 “‘并发能力’指单实例在 4 核 8G 服务器下的每秒最大查询 / 写入次数”）；

章节 3：详细对比表格，每个维度单独生成一个 Markdown 表格，表格列固定为 “对比子项”“方案 A”“方案 B”“方案 C（若有）”“数据来源”；

章节 4：选型建议，包含 “推荐方案”“推荐理由（结合业务场景）”“不推荐方案的局限性”“实施注意事项” 四个子部分。

语言要求：使用技术文档风格，避免口语化表述（如不用 “挺好”“还行”），每个对比子项的描述控制在 20 字以内，数据部分加粗显示（如 “8000 QPS”）。

五、约束条件（可选）

【补充特殊要求，如 “重点突出高并发场景性能对比”“必须包含国产化适配维度” 等，无特殊要求可写 “无”】

### 4.2 模板使用说明

1. 占位符替换：将“【】”内的内容替换为实际需求，例如对比3个方案时，在“对比方案”中补充“③ 方案C（版本信息）”，表格列增加“方案C”；

2. 维度调整：若某维度与业务无关（如对比“无事务需求的缓存中间件”时，可删除“事务支持”子项），直接在模板中删除对应维度或子项；

3. 方案数量适配：支持2-3个方案对比，超过3个方案时，需在“对比方案”和表格列中同步增加，确保一一对应；

4. 数据来源补充：若已知具体数据来源（如“阿里云性能测试报告2024”），可在模板中直接填写，提升数据可信度。

## 5. 实战案例一：数据库选型对比（MySQL 8.0 vs PostgreSQL 14）

下面以“电商订单系统数据库选型”为例，演示如何使用通用模板生成提示词，并展示大模型的输出结果，帮助读者直观理解模板的应用效果。

### 5.1 步骤1：填充通用模板生成提示词

根据电商订单系统的需求，填充通用模板后的完整提示词如下：

需求：生成技术方案对比文档，请按以下要求输出：

一、对比对象与业务背景

对比方案：① MySQL 8.0（InnoDB 引擎）；② PostgreSQL 14

业务背景：为电商平台订单系统选择主数据库，订单系统日均订单量 100 万，峰值订单量每秒 5000 笔，核心需求：支持 ACID 事务、高并发读写（读多写少，读请求占比 70%）、数据延迟低于 100ms、支持按月分表存储 1 年以上历史订单、兼容 Java+MyBatis 技术栈。

二、对比维度与子项

请按以下维度和子项进行对比，若有个性化维度需补充在 “其他个性化维度” 中：

功能特性

- 子项 1：事务支持（是否支持 ACID、隔离级别）

- 子项 2：索引支持（是否支持 B-tree、全文索引、哈希索引）

- 子项 3：不支持的关键功能（订单系统可能用到的功能）

性能表现（基于 4 核 8G 云服务器）

- 子项 1：并发读能力（QPS）

- 子项 2：并发写能力（TPS）

- 子项 3：响应时间（单条订单查询延迟，单位 ms）

- 子项 4：资源占用（日均 CPU 使用率、内存占用，单位 %/GB）

适用场景

- 子项 1：数据量范围（单表支持最大数据量）

- 子项 2：并发量适配（支持的每秒最大读写次数）

- 子项 3：业务类型适配（读多写少 / 写多读少 / 读写均衡）

成本投入

- 子项 1：部署成本（4 核 8G 云服务器月均费用，单位元）

- 子项 2：运维成本（是否需专职 DBA、每周运维耗时）

- 子项 3：学习成本（团队现有成员中，熟悉该数据库的人数占比）

兼容性与扩展性

- 子项 1：与现有技术栈兼容性（是否支持 Java+MyBatis）

- 子项 2：水平扩容能力（是否支持主从复制、读写分离）

- 子项 3：分表分库能力（是否原生支持、支持方式）

社区与生态

- 子项 1：社区活跃度（GitHub 星数、Issues 平均处理时间）

- 子项 2：文档丰富度（是否有中文官方文档）

- 子项 3：第三方工具支持（监控工具、分表中间件）

其他个性化维度

- 子项 1：历史数据存储（是否支持按月分表高效查询）

三、数据要求

所有性能相关子项必须包含量化数据（如 “QPS=8000”，不允许 “QPS 较高” 等定性描述）；

数据来源需标注（如 “官方测试报告”“第三方测评”“行业通用数据”），估算数据需注明 “基于 4 核 8G 服务器的估算值”；

若某子项无明确数据，需说明 “暂未获取到相关数据”，不允许空白或模糊表述。

四、输出格式

文档标题：需包含对比方案和业务场景，如 “电商订单系统数据库对比文档：MySQL 8.0 vs PostgreSQL 14”；

文档结构：包含以下 4 个章节，每个章节需单独成段，使用二级标题（如 “## 1. 对比背景与目标”）：

- 章节 1：对比背景与目标，包含 “对比方案列表”“业务背景”“核心需求” 三个子部分；

- 章节 2：对比维度与子项说明，逐一解释每个维度及子项的含义；

- 章节 3：详细对比表格，每个维度单独生成一个 Markdown 表格，表格列固定为 “对比子项”“MySQL 8.0（InnoDB）”“PostgreSQL 14”“数据来源”；

- 章节 4：选型建议，包含 “推荐方案”“推荐理由（结合业务场景）”“不推荐方案的局限性”“实施注意事项” 四个子部分。

语言要求：使用技术文档风格，避免口语化表述，每个对比子项的描述控制在 20 字以内，数据部分加粗显示（如 “8000 QPS”）。

五、约束条件

重点突出 “高并发读场景” 和 “分表分库能力” 的对比，这两个是订单系统核心需求；

历史数据存储维度需说明 “按月分表后，查询近 1 年数据的效率”。

### 5.2 步骤2：大模型输出结果

#### 5.2.1 文档标题

电商订单系统数据库对比文档：MySQL 8.0 vs PostgreSQL 14

#### 5.2.2 章节1：对比背景与目标

1. 对比方案列表

- 方案A：MySQL 8.0（InnoDB存储引擎）

- 方案B：PostgreSQL 14

2. 业务背景

电商平台订单系统需选择主数据库，系统日均订单量100万，峰值订单量每秒5000笔，读请求占比70%（读多写少），需存储1年以上历史订单数据，技术栈为Java+MyBatis。

3. 核心需求

- 支持ACID事务，隔离级别不低于Repeatable Read；

- 高并发读场景下QPS≥8000，单条查询延迟≤100ms；

- 支持按月分表，查询近1年历史订单效率高；

- 兼容Java+MyBatis技术栈，可快速集成。

#### 5.2.3 章节2：对比维度与子项说明

1. 功能特性：评估数据库核心功能是否满足订单系统需求，如事务、索引支持情况；

2. 性能表现：基于4核8G云服务器，测试高并发场景下的QPS、TPS、响应时间及资源占用；

3. 适用场景：分析数据库适配的数据量、并发量及业务类型（读多写少等）；

4. 成本投入：计算部署、运维及团队学习的成本；

5. 兼容性与扩展性：评估与现有技术栈的兼容性，及后续扩容、分表能力；

6. 社区与生态：判断社区活跃度、文档及第三方工具支持情况；

7. 历史数据存储：重点评估按月分表后的查询效率，满足1年历史数据存储需求。

#### 5.2.4 章节3：详细对比表格

1. 功能特性对比表

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

2. 性能表现对比表（4核8G服务器）

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 并发读能力（QPS） | **8500** | **6000** | 阿里云性能测试报告2024 |

| 并发写能力（TPS） | **2000** | **1800** | 阿里云性能测试报告2024 |

| 单条查询延迟（ms） | **50** | **70** | 实测数据（4核8G服务器） |

3. 适用场景对比表

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 每秒最大读写次数 | 读**8500**/写**2000** | 读**6000**/写**1800** | 阿里云性能测试报告2024 |

4. 成本投入对比表

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

5. 兼容性与扩展性对比表

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

6. 社区与生态对比表

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

7. 历史数据存储对比表

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

#### 5.2.5 章节4：选型建议

1. 推荐方案

推荐选择 **MySQL 8.0（InnoDB引擎）** 作为电商订单系统主数据库。

2. 推荐理由（结合业务场景）

- 高并发读适配：订单系统读多写少（读占比70%），MySQL 8.0的并发读QPS达**8500**，高于PostgreSQL 14的**6000**，且单条查询延迟**50ms**，满足“延迟<100ms”需求；

- 团队成本低：团队80%成员熟悉MySQL，学习成本低，无需额外培训；运维每周仅需4小时，低于PostgreSQL的5小时，长期运维成本更优；

- 技术栈兼容：完全兼容Java+MyBatis，可快速集成，无需修改现有代码；

- 生态成熟：第三方工具丰富，分表可依赖Sharding-JDBC（行业主流方案），后续问题易找到解决方案。

3. 不推荐方案的局限性

PostgreSQL 14虽在分表查询效率（200ms）上优于MySQL，但存在以下局限性：

- 高并发读性能不足：QPS仅6000，无法满足订单系统峰值读需求；

- 团队熟悉度低：仅30%成员熟悉，集成和后续运维易出现问题；

- 中文文档缺失：官方无中文文档，排查问题时效率低，增加运维难度。

4. 实施注意事项

- 分表方案：使用Sharding-JDBC中间件实现按月分表，分表字段选择“create_time”（订单创建时间）；

- 性能优化：开启MySQL主从复制，实现读写分离（主库写、从库读），进一步提升读并发能力；

- 监控配置：集成Prometheus+Grafana，监控CPU、内存、QPS/TPS等指标，确保系统稳定运行。

## 6. 实战案例二：缓存中间件选型对比（Redis 7.0 vs Memcached 1.6）

除了数据库，缓存中间件也是技术选型的高频场景。下面以“电商商品详情页缓存”为例，演示模板的应用。

### 6.1 步骤1：填充模板生成提示词

需求：生成技术方案对比文档，请按以下要求输出：

一、对比对象与业务背景

对比方案：① Redis 7.0；② Memcached 1.6

业务背景：为电商商品详情页设计缓存方案，商品详情页日均访问量 500 万次，峰值访问量每秒 3000 次，核心需求：支持缓存过期策略（如 TTL 自动过期）、支持热点数据缓存、单条缓存数据大小不超过 10KB、兼容 Java 技术栈，且需保证缓存服务可用性（无故障运行时间≥99.9%）。
二、对比维度与子项

请按以下维度和子项进行对比，若有个性化维度需补充在 “其他个性化维度” 中：
功能特性
- 子项 1：数据结构支持（如字符串、哈希、列表等）
- 子项 2：缓存过期策略（如 TTL、惰性删除、定期删除）
- 子项 3：高可用特性（如主从复制、哨兵、集群）
性能表现（基于 4 核 8G 云服务器）
- 子项 1：并发读写能力（QPS）
- 子项 2：单条数据响应时间（单位 ms）
- 子项 3：资源占用（CPU 使用率、内存占用，单位 %/GB）
- 子项 4：单条数据最大存储大小（单位 KB）
适用场景
- 子项 1：并发量适配（支持的每秒最大访问次数）
- 子项 2：数据类型适配（简单字符串 / 复杂结构数据）
- 子项 3：可用性要求（支持的 SLA 等级）
成本投入
- 子项 1：部署成本（4 核 8G 云服务器月均费用，单位元）
- 子项 2：运维成本（是否需专职运维、每周运维耗时）
- 子项 3：学习成本（团队现有成员熟悉度占比）
兼容性与扩展性
- 子项 1：与 Java 技术栈兼容性（如是否支持 Spring Cache）
- 子项 2：水平扩容能力（是否支持集群、节点扩容方式）
- 子项 3：数据持久化（是否支持 RDB、AOF 持久化）
社区与生态
- 子项 1：社区活跃度（GitHub 星数、Issues 处理时间）
- 子项 2：文档丰富度（是否有中文官方文档）
- 子项 3：第三方工具支持（监控工具、连接池）
其他个性化维度
- 子项 1：热点数据处理（是否支持热点 Key 隔离、防缓存击穿）
- 子项 2：故障恢复能力（宕机后数据恢复时间，单位 min）
三、数据要求
所有性能相关子项必须包含量化数据（如 “QPS=10000”，不允许 “性能好” 等定性描述）；
数据来源需标注（如 “Redis 官方测试报告 2024”“Memcached 官网文档”），估算数据需注明 “基于 4 核 8G 服务器的估算值”；
若某子项无明确数据，需说明 “暂未获取到相关数据”，不允许空白或模糊表述。
四、输出格式
文档标题：需包含对比方案和业务场景，如 “电商商品详情页缓存方案对比文档：Redis 7.0 vs Memcached 1.6”；
文档结构：包含以下 4 个章节，每个章节单独成段，使用二级标题：
- 章节 1：对比背景与目标（含方案列表、业务背景、核心需求）；
- 章节 2：对比维度与子项说明（逐一解释维度含义）；
- 章节 3：详细对比表格（每个维度单独成表，列含 “对比子项”“Redis 7.0”“Memcached 1.6”“数据来源”）；
- 章节 4：选型建议（含推荐方案、理由、不推荐局限、注意事项）；
语言要求：技术文档风格，每个子项描述≤20 字，数据部分加粗。
五、约束条件
重点突出 “并发读写性能” 和 “高可用特性” 对比，这是商品详情页核心需求；
热点数据处理维度需说明 “如何防范缓存击穿、缓存雪崩”。
### 6.2 步骤2：大模型输出结果

#### 6.2.1 文档标题

电商商品详情页缓存方案对比文档：Redis 7.0 vs Memcached 1.6

#### 6.2.2 章节1：对比背景与目标

1. 对比方案列表

- 方案A：Redis 7.0（单机+哨兵模式）

- 方案B：Memcached 1.6（单机模式）

2. 业务背景

电商商品详情页日均访问量500万次，峰值每秒3000次，缓存数据为商品基本信息（如名称、价格、库存），单条数据≤10KB，技术栈为Java+Spring Boot，需保证缓存服务SLA≥99.9%。

3. 核心需求

- 支持TTL过期策略（商品信息需2小时自动更新）；

- 并发QPS≥3000，单条响应时间≤10ms；

- 支持防缓存击穿（热点商品访问量高，需避免DB压力）；

- 兼容Spring Cache，可快速集成；

- 服务无故障运行时间≥99.9%（每月故障不超过43分钟）。

#### 6.2.3 章节2：对比维度与子项说明

1. 功能特性：评估缓存中间件是否支持数据结构、过期策略及高可用能力，适配商品详情页缓存需求；

2. 性能表现：基于4核8G服务器，测试并发读写、响应时间等，满足峰值访问需求；

3. 适用场景：分析中间件适配的并发量、数据类型，匹配商品详情页“简单数据+高并发”场景；

4. 成本投入：计算部署、运维及团队学习成本，控制项目开销；

5. 兼容性与扩展性：评估与Java技术栈的兼容性，及后续扩容、数据持久化能力；

6. 社区与生态：判断社区活跃度、文档及工具支持，确保问题可快速解决；

7. 热点数据处理：重点评估防缓存击穿、故障恢复能力，保障服务稳定。

#### 6.2.4 章节3：详细对比表格

1. 功能特性对比表

| 对比子项 | Redis 7.0 | Memcached 1.6 | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 数据结构支持 | 支持字符串、哈希、列表等6种结构 | 仅支持字符串结构 | 官方文档 |

| 缓存过期策略 | 支持TTL、惰性+定期删除 | 仅支持TTL，无主动删除机制 | 官方文档 |

| 高可用特性 | 支持主从复制、哨兵，故障自动切换 | 不支持主从，需依赖第三方工具实现高可用 | 官方文档+行业实践 |

2. 性能表现对比表（4核8G服务器）

| 对比子项 | Redis 7.0 | Memcached 1.6 | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 并发读写QPS | **3500**（字符串类型） | **4000**（字符串类型） | 第三方测评（2024.06） |

| 单条数据响应时间（ms） | **5**（10KB数据） | **3**（10KB数据） | 实测数据 |

| 资源占用（CPU/内存） | 峰值CPU **25%**，内存 **2GB** | 峰值CPU **20%**，内存 **1.5GB** | 实测数据 |

| 单条数据最大存储（KB） | **51200**（50MB） | **1024**（1MB） | 官方文档 |

3. 适用场景对比表

| 对比子项 | Redis 7.0 | Memcached 1.6 | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 每秒最大访问次数 | **3500**（稳定支持） | **4000**（稳定支持） | 第三方测评（2024.06） |

| 数据类型适配 | 简单/复杂结构数据均可 | 仅适配简单字符串数据 | 官方文档 |

| 可用性要求（SLA） | 支持99.9%以上（哨兵模式） | 仅99.5%（单机模式） | 行业SLA标准 |

4. 成本投入对比表

| 对比子项 | Redis 7.0 | Memcached 1.6 | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 4核8G服务器月均费用 | **900元**（含哨兵节点，2台服务器） | **450元**（单机，1台服务器） | 阿里云官网2024报价 |

| 运维成本 | 需运维，每周**3小时**（哨兵配置维护） | 基本无需运维，每周**1小时**（仅监控） | 企业运维统计 |

| 团队熟悉度占比 | **70%**（假设20人，14人熟悉） | **40%**（假设20人，8人熟悉） | 假设团队情况 |

5. 兼容性与扩展性对比表

| 对比子项 | Redis 7.0 | Memcached 1.6 | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| Java+Spring Cache兼容 | 完全兼容，支持自动缓存注解 | 兼容，需自定义配置，无原生注解支持 | 实测集成结果 |

| 水平扩容能力 | 支持集群，可新增节点扩展 | 支持分布式，但需手动配置一致性哈希 | 官方文档 |

| 数据持久化 | 支持RDB+AOF，宕机可恢复数据 | 不支持持久化，宕机数据丢失 | 官方文档 |

6. 社区与生态对比表

| 对比子项 | Redis 7.0 | Memcached 1.6 | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| GitHub星数/Issues处理时间| 星数**61.2k**，Issues平均**12小时**响应 | 星数**24.8k**，Issues平均**3天**响应 | GitHub官网2024.06 |

| 中文官方文档 | 有完整中文文档 | 无官方中文文档，依赖社区翻译 | 官方网站 |

| 第三方工具支持 | 支持Prometheus、RedisInsight、Spring Cache | 支持Prometheus，缓存框架支持较少 | 工具官网兼容性说明 |

7. 热点数据处理对比表

| 对比子项 | Redis 7.0 | Memcached 1.6 | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 防缓存击穿机制 | 支持互斥锁、热点Key永不过期 | 需业务代码实现，无原生机制 | 官方文档+行业实践 |

| 宕机数据恢复时间（min） | **5**（AOF持久化，快速恢复） | 不可恢复（无持久化） | 实测数据 |

#### 6.2.5 章节4：选型建议

1. 推荐方案

推荐选择 **Redis 7.0（主从+哨兵模式）** 作为电商商品详情页缓存中间件。

2. 推荐理由（结合业务场景）

- 高可用满足需求：商品详情页需SLA≥99.9%，Redis哨兵模式支持故障自动切换，可实现99.9%以上可用性，而Memcached单机仅99.5%，无法满足；

- 热点数据防护强：Redis原生支持防缓存击穿机制（如热点Key永不过期），可避免商品详情页高并发时的DB压力，Memcached需手动编码实现，成本高；

- 数据安全有保障：Redis支持AOF持久化，宕机后5分钟可恢复数据，Memcached数据丢失无法恢复，若缓存宕机将导致DB直接承受500万日访问量，风险高；

- 技术栈适配性好：完全兼容Spring Cache，可通过@Cacheable注解快速集成，无需自定义配置，Memcached需额外开发适配代码，增加工作量。

3. 不推荐方案的局限性

Memcached 1.6虽在并发QPS（4000）和单机成本（450元/月）上有优势，但存在关键缺陷：

- 可用性不足：无主从和故障切换，单机宕机将导致缓存服务中断，影响商品详情页访问；

- 数据无保障：不支持持久化，宕机后数据全部丢失，DB将面临流量洪峰，可能引发连锁故障；

- 功能单一：仅支持字符串结构，后续若需缓存复杂数据（如商品规格列表），需重新选型，扩展性差。

4. 实施注意事项

- 部署方案：采用“1主2从+3哨兵”架构，主节点负责写，从节点负责读，哨兵监控故障；

- 性能优化：开启Redis内存淘汰策略（LRU），设置最大内存为服务器内存的80%（4核8G服务器设为6.4GB），避免内存溢出；

- 热点防护：对TOP1000热点商品（如销量前1000）设置“永不过期+定时更新”，其他商品设置2小时TTL，防范缓存击穿；

- 监控配置：集成Prometheus+Grafana，监控QPS、响应时间、内存使用率，设置阈值告警（如QPS>3000时告警）。

## 7. 实战案例三：架构选型对比（微服务架构 vs 单体架构）

除了中间件选型，架构选型也是技术决策的核心场景。下面以“小型电商平台（日均订单5万）架构选型”为例，演示模板的应用。

### 7.1 步骤1：填充模板生成提示词

需求：生成技术方案对比文档，请按以下要求输出：

一、对比对象与业务背景
对比方案：① 微服务架构（Spring Cloud Alibaba）；② 单体架构（Spring Boot）
业务背景：为小型电商平台设计技术架构，平台包含商品、订单、用户、支付 4 个核心模块，日均订单 5 万，团队规模 10 人（含 3 名后端开发），核心需求：支持未来 1 年业务增长（订单量翻倍至 10 万 / 日）、开发周期控制在 2 个月内、运维成本低。
二、对比维度与子项

请按以下维度和子项进行对比，若有个性化维度需补充在 “其他个性化维度” 中：
功能特性
- 子项 1：模块解耦程度（是否支持模块独立开发、部署）
- 子项 2：技术组件支持（如服务发现、配置中心）
- 子项 3：扩展性（是否支持新增模块、功能迭代）
性能表现（基于 4 核 8G 服务器，2 台部署）
- 子项 1：系统吞吐量（日均订单处理能力）
- 子项 2：响应时间（订单创建接口延迟，单位 ms）
- 子项 3：资源占用（峰值 CPU / 内存使用率，单位 %/GB）
适用场景
- 子项 1：团队规模适配（适合的后端开发人数）
- 子项 2：业务复杂度（适合的模块数量、订单量）
- 子项 3：开发周期（从搭建到上线的时间，单位月）
成本投入
- 子项 1：部署成本（服务器数量、月均费用，单位元）
- 子项 2：运维成本（每周运维耗时、是否需专职运维）
- 子项 3：学习成本（团队掌握架构所需时间，单位周）
兼容性与扩展性
- 子项 1：技术栈兼容性（是否支持 Java、MySQL 等现有技术）
- 子项 2：业务扩展能力（支持订单量翻倍的改造难度）
- 子项 3：故障隔离（某模块故障是否影响整体系统）
社区与生态
- 子项 1：架构组件活跃度（如 Spring Cloud Alibaba 更新频率）
- 子项 2：文档丰富度（是否有中文教程、最佳实践）
- 子项 3：问题解决效率（社区提问响应时间，单位小时）
其他个性化维度
- 子项 1：故障恢复能力（某模块故障后的恢复时间，单位 min）
- 子项 2：开发协作效率（多模块并行开发的冲突率）
三、数据要求
所有性能和成本相关子项必须包含量化数据（如 “开发周期 2 个月”，不允许 “开发快” 等描述）；
数据来源需标注（如 “Spring 官方文档”“小型电商架构实践报告”），估算数据需注明 “基于小型电商实践的估算值”；
3. 若某子项无明确数据，需说明 “暂未获取到相关数据”，不允许空白或模糊表述。

四、输出格式
文档标题：需包含对比方案和业务场景，如 “小型电商平台架构对比文档：微服务架构 vs 单体架构”；
文档结构：包含以下 4 个章节，每个章节单独成段，使用二级标题：
- 章节 1：对比背景与目标（含方案列表、业务背景、核心需求）；
- 章节 2：对比维度与子项说明（逐一解释维度含义）；
- 章节 3：详细对比表格（每个维度单独成表，列含 “对比子项”“微服务架构（Spring Cloud Alibaba）”“单体架构（Spring Boot）”“数据来源”）；
- 章节 4：选型建议（含推荐方案、理由、不推荐局限、注意事项）；
语言要求：技术文档风格，每个子项描述≤20 字，数据部分加粗。
五、约束条件
重点突出 “开发周期” 和 “运维成本” 对比，这是小型团队核心诉求；
业务扩展能力维度需说明 “订单量翻倍时的改造工作量”。
### 7.2 步骤2：大模型输出结果

#### 7.2.1 文档标题

小型电商平台架构对比文档：微服务架构 vs 单体架构

#### 7.2.2 章节1：对比背景与目标

1. 对比方案列表

- 方案A：微服务架构（基于Spring Cloud Alibaba，含Nacos、Sentinel等组件）

- 方案B：单体架构（基于Spring Boot，模块内部分包，无分布式组件）

2. 业务背景

小型电商平台包含商品、订单、用户、支付4个核心模块，日均订单5万，团队共10人（3名后端开发、2名前端开发、1名测试、4名非技术人员），计划1年内实现订单量翻倍至10万/日，需控制开发和运维成本。

3. 核心需求

- 开发周期≤2个月，确保平台快速上线；

- 支持1年内订单量翻倍，改造工作量少；

- 运维成本低，无需专职运维人员；

- 技术栈匹配团队现有能力（团队熟悉Java+MySQL，无分布式经验）。

#### 7.2.3 章节2：对比维度与子项说明

1. 功能特性：评估架构的模块解耦、组件支持及扩展能力，适配电商4个核心模块的开发需求；

2. 性能表现：基于2台4核8G服务器，测试订单处理能力、响应时间，满足当前及未来1年业务需求；

3. 适用场景：分析架构适配的团队规模、业务复杂度，匹配小型团队+低订单量场景；

4. 成本投入：计算部署、运维及学习成本，贴合小型团队预算限制；

5. 兼容性与扩展性：评估与现有技术栈的兼容性，及订单量翻倍时的扩展能力；

6. 社区与生态：判断架构组件的活跃度、文档支持，确保问题可快速解决；

7. 故障与协作：评估故障恢复效率和多模块开发协作成本，保障开发和运行稳定性。

#### 7.2.4 章节3：详细对比表格

1. 功能特性对比表

| 对比子项 | 微服务架构（Spring Cloud Alibaba） | 单体架构（Spring Boot） | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 模块解耦程度 | 完全解耦，支持独立开发、部署 | 模块内部分包，需整体开发、部署 | Spring官方文档 |

| 技术组件支持 | 支持服务发现、配置中心、熔断降级 | 无分布式组件，需手动开发基础功能 | Spring官方文档 |

| 扩展性 | 新增模块无需修改现有代码，扩展灵活 | 新增模块需修改单体项目，易引发冲突 | 小型电商架构实践报告 |

2. 性能表现对比表（2台4核8G服务器）

| 对比子项 | 微服务架构（Spring Cloud Alibaba） | 单体架构（Spring Boot） | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 日均订单处理能力 | **20万**（分布式部署，支持横向扩展） | **10万**（单体部署，依赖服务器配置升级） | 性能测试报告（2024.06） |

| 订单创建接口延迟（ms） | **80**（含服务调用耗时） | **30**（本地方法调用，无网络开销） | 实测数据 |

| 峰值资源占用（CPU/内存）| 峰值CPU **60%**，内存 **6GB** | 峰值CPU **50%**，内存 **4GB** | 实测数据 |

3. 适用场景对比表

| 对比子项 | 微服务架构（Spring Cloud Alibaba） | 单体架构（Spring Boot） | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 团队规模适配 | 适合后端开发≥5人，需分布式经验 | 适合后端开发≤3人，无分布式经验也可上手 | 行业架构选型指南 |

| 业务复杂度适配 | 适合模块≥6个、订单量≥10万/日 | 适合模块≤5个、订单量≤10万/日 | 小型电商架构实践报告 |

| 开发周期 | **3-4个月**（含组件学习、架构搭建） | **1.5-2个月**（直接开发业务功能） | 企业项目周期统计 |

4. 成本投入对比表

| 对比子项 | 微服务架构（Spring Cloud Alibaba） | 单体架构（Spring Boot） | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 部署成本（月均） | **2400元**（4台4核8G服务器，含组件部署） | **900元**（2台4核8G服务器，直接部署） | 阿里云官网2024报价 |

| 运维成本 | 需专职运维，每周**8小时**（组件监控、故障处理）| 无需专职运维，每周**2小时**（仅服务监控） | 企业运维统计 |

| 学习成本 | 团队需**4周**掌握分布式组件使用 | 团队需**1周**熟悉项目结构即可开发 | 团队技能培训记录 |

5. 兼容性与扩展性对比表

| 对比子项 | 微服务架构（Spring Cloud Alibaba） | 单体架构（Spring Boot） | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| Java+MySQL兼容性 | 完全兼容，需额外集成分布式组件 | 完全兼容，直接使用现有技术栈 | 实测集成结果 |

| 订单量翻倍改造难度 | 新增2台服务器，1周内完成扩容 | 需升级服务器配置（8核16G），2周内完成迁移 | 性能扩展测试报告 |

| 故障隔离能力 | 某模块故障（如支付）不影响其他模块 | 某模块故障导致整个系统不可用 | 故障模拟测试 |

6. 社区与生态对比表

| 对比子项 | 微服务架构（Spring Cloud Alibaba） | 单体架构（Spring Boot） | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 组件活跃度 | Spring Cloud Alibaba每3个月更新1次 | Spring Boot每6个月更新1次 | 官方GitHub更新记录 |

| 文档丰富度 | 有中文教程、大量企业实践案例 | 中文文档齐全，入门教程多，适合新手 | 官方网站+社区博客 |

| 问题解决效率 | 社区提问平均**4小时**响应 | 社区提问平均**2小时**响应 | 个人社区提问记录 |

7. 其他个性化维度对比表

| 对比子项 | 微服务架构（Spring Cloud Alibaba） | 单体架构（Spring Boot） | 数据来源 |

|-------------------------|----------------------------------------------|----------------------------------------------|---------------------------|

| 故障恢复时间（min） | **30**（需定位组件故障，重启服务） | **5**（直接重启单体服务，快速恢复） | 故障模拟测试 |

| 开发协作冲突率 | **5%**（模块独立开发，冲突少） | **15%**（多模块并行开发，易冲突） | 团队开发管理记录 |

#### 7.2.5 章节4：选型建议

1. 推荐方案

推荐选择 **单体架构（Spring Boot）** 作为小型电商平台的初始架构。

2. 推荐理由（结合业务场景）

- 开发周期适配：团队需2个月内上线，单体架构开发周期仅1.5-2个月，无需额外学习分布式组件，可快速聚焦业务功能开发；微服务架构需3-4个月，超出时间要求；

- 成本可控：单体架构部署成本900元/月（仅2台服务器），运维每周仅需2小时，无需专职运维；微服务部署成本2400元/月（4台服务器），还需4周学习时间，对小型团队成本过高；

- 团队能力匹配：团队仅3名后端开发且无分布式经验，单体架构1周即可上手开发；微服务需4周学习组件，短期内难以掌握，易引发开发事故；

- 业务需求满足：当前日均订单5万，1年内翻倍至10万，单体架构在2台4核8G服务器上可支持10万/日订单，后续仅需升级服务器配置（8核16G）即可，改造工作量少。

3. 不推荐方案的局限性

微服务架构虽在扩展性和故障隔离上有优势，但不适合当前场景：

- 开发周期过长：3-4个月上线时间，错过业务窗口期，无法快速抢占市场；

- 成本过高：部署和运维成本是单体架构的2-4倍，超出小型团队预算；

- 团队能力不匹配：无分布式经验，强行使用微服务易出现“分布式踩坑”（如服务调用超时、数据一致性问题），反而影响系统稳定性。

4. 实施注意事项

- 项目结构设计：按“模块分包”设计单体项目（com.xxx.goods、com.xxx.order等），为未来可能的微服务拆分预留空间；

- 性能优化：使用Redis缓存高频数据（如商品列表、用户信息），减少DB查询；订单表按月分表，提升查询效率；

- 扩展预留：选择云服务器部署，预留“配置升级”通道（当前4核8G，1年后可直接升级为8核16G）；

- 监控配置：集成Spring Boot Admin+Prometheus，监控服务运行状态，设置CPU、内存阈值告警（如CPU>80%时告警）。

## 8. 提示词模板使用的常见问题与解决方案

在使用“生成技术方案对比文档”的提示词模板时，可能会遇到大模型输出“维度缺失”“数据不准确”等问题。下面列出常见问题及解决方案，帮助大家提升模板使用效果。

### 8.1 问题一：大模型遗漏个性化对比维度

#### 8.1.1 问题表现

提示词中明确添加了个性化维度（如“国产化适配”），但大模型输出时仍未包含该维度，仅覆盖通用维度。

#### 8.1.2 原因分析

个性化维度的“优先级”未在提示词中强调，大模型默认优先输出通用维度，忽略个性化需求；或个性化维度描述模糊（如仅写“国产化适配”，未说明子项），导致大模型无法理解。

#### 8.1.3 解决方案

1. 强调个性化维度优先级：在提示词“约束条件”中添加“个性化维度（如国产化适配）必须优先输出，放在通用维度之前”；

2. 明确个性化维度子项：将模糊的维度描述拆分为具体子项，例如“个性化维度：国产化适配 - 子项1：是否支持麒麟操作系统；子项2：是否通过等保三级认证”；

3. 示例提示词片段：

五、约束条件
个性化维度 “国产化适配” 必须优先输出，放在 “功能特性” 维度之前；
国产化适配维度需包含 2 个子项：① 是否支持麒麟 V10 操作系统；② 是否通过等保三级认证，每个子项需明确 “是 / 否” 及相关依据。
### 8.2 问题二：大模型输出的数据缺乏来源或估算不标注

#### 8.2.1 问题表现

对比表格中“数据来源”列多为“行业通用数据”“官方文档”等模糊表述，无具体来源（如“某第三方测评2024”）；或估算数据未标注“估算”，误导用户认为是实测数据。

#### 8.2.2 原因分析

提示词中对“数据来源”的要求不够具体，仅说明“标注来源”，未要求“具体来源名称”；或未明确“估算数据的标注格式”（如“需注明‘基于XX配置的估算值’”）。

#### 8.2.3 解决方案

1. 要求具体来源名称：在“数据要求”中补充“数据来源需标注具体名称，如‘Redis官方测试报告2024.06’‘阿里云性能测评2024’，不允许‘官方文档’‘行业数据’等模糊表述”；

2. 明确估算标注格式：添加“估算数据需按‘XX（基于4核8G服务器的估算值）’格式标注，如‘QPS=5000（基于4核8G服务器的估算值）’”；

3. 示例提示词片段：

三、数据要求
所有性能相关子项必须包含量化数据，如 “QPS=8000”；
数据来源需标注具体名称（如 “Redis 官方测试报告 2024.06”），不允许模糊表述；
估算数据需按 “数值（基于 XX 配置的估算值）” 格式标注，如 “响应时间 = 60ms（基于 4 核 8G 服务器的估算值）”。
### 8.3 问题三：大模型输出的选型建议与业务场景脱节

#### 8.3.1 问题表现

选型建议仅泛泛而谈“微服务适合大规模业务，单体适合小规模业务”，未结合提示词中的具体业务场景（如“小型电商、日均订单5万、团队3人”），无法直接用于决策。

#### 8.3.2 原因分析

提示词中“选型建议”的要求不够具体，未明确“需结合业务场景中的XX信息（如订单量、团队规模）说明理由”；或业务背景描述不够详细（如仅写“小型电商”，未说明订单量、团队规模）。

#### 8.3.3 解决方案

1. 细化业务背景描述：在“对比对象与业务背景”中补充具体数据，如“小型电商（日均订单5万、团队3名后端开发、无分布式经验）”；

2. 明确选型建议关联业务场景：在“输出格式”的“选型建议”部分添加“推荐理由需包含3个业务场景关联点（如订单量、团队规模、开发周期），每个理由需对应提示词中的具体数据”；

3. 示例提示词片段：

四、输出格式

3. 选型建议：
推荐理由需包含 3 个业务场景关联点（如订单量、团队规模、开发周期），每个理由对应提示词中的具体数据（如 “团队仅 3 名后端开发，符合单体架构‘适合后端≤3 人’的场景”）；
不推荐方案的局限性需结合业务痛点（如 “开发周期 3-4 个月，超出 2 个月上线要求”）。
### 8.4 问题四：大模型输出的表格格式混乱

#### 8.4.1 问题表现

对比表格未按要求“每个维度单独成表”，而是将所有维度合并为一个大表；或表格列顺序错误（如“对比子项”列放在最后，不符合阅读习惯）。

#### 8.4.2 原因分析

提示词中“输出格式”对表格的“拆分规则”和“列顺序”描述不够明确，仅写“每个维度单独成表”，未说明“维度名称作为表格标题”；或未指定“表格列顺序为‘对比子项→方案A→方案B→数据来源’”。

#### 8.4.3 解决方案

1. 明确表格拆分规则：添加“每个维度单独生成一个表格，表格标题为维度名称（如‘功能特性对比表’），表格下方不添加额外描述”；

2. 固定表格列顺序：在“输出格式”中补充“表格列顺序固定为‘对比子项→方案A（如微服务架构）</doubaocanvas>

→方案 B（如单体架构）→数据来源’，不允许调整列顺序”；

3. 示例提示词片段：
四、输出格式

2. 详细对比表格：

- 每个维度单独生成一个表格，表格标题为维度名称（如“功能特性对比表”“性能表现对比表”）；

- 表格列顺序固定为“对比子项→方案A（微服务架构）→方案B（单体架构）→数据来源”，列宽适配内容，确保表格清晰易读；

- 表格内不允许合并单元格，每个子项对应一行数据。

8.5 问题五：大模型输出的技术术语不统一

8.5.1 问题表现

同一技术概念在文档中出现多种表述，例如 “并发读写能力” 在表格中有时写 “QPS”，有时写 “每秒访问次数”；“微服务架构” 有时简称 “微服务”，有时写 “Spring Cloud 架构”，导致文档阅读混乱。

8.5.2 原因分析

提示词中未对 “关键技术术语” 进行定义和统一，大模型根据训练数据中的不同表述自由输出；或在对比方案描述中未明确 “简称规则”（如 “微服务架构后续可简称‘微服务’”）。

8.5.3 解决方案
定义关键术语：在 “对比对象与业务背景” 中添加 “关键术语定义”，明确同一概念的统一表述，例如 “‘并发读写能力’统一用‘QPS/TPS’表述，‘微服务架构（Spring Cloud Alibaba）’后续可简称‘微服务’”；
示例提示词片段：
一、对比对象与业务背景

3. 关键术语定义：

- 并发能力：统一用“QPS（读）/TPS（写）”表述，单位为“次/秒”；

- 微服务架构：全称“微服务架构（Spring Cloud Alibaba）”，后续文档中可简称“微服务”；

- 单体架构：全称“单体架构（Spring Boot）”，后续文档中可简称“单体”；

- 所有术语需严格按上述定义使用，不允许出现其他表述。

9. 提示词模板的扩展应用场景

除了前文提到的 “数据库”“缓存中间件”“架构选型”，本文的提示词模板还可扩展到更多技术方案对比场景。下面列举 3 个常见扩展场景，并说明模板的调整要点，帮助读者灵活复用。

9.1 场景一：消息队列选型（RabbitMQ 3.12 vs Kafka 3.6）

9.1.1 业务背景示例

为电商平台 “订单状态同步” 场景选择消息队列，日均订单 50 万，需支持 “订单创建→支付→发货” 状态异步同步，核心需求：消息不丢失、支持延迟队列（如订单 30 分钟未支付自动取消）、吞吐量≥1 万条 / 秒。

9.1.2 模板调整要点
对比维度调整：
- 新增 “消息可靠性” 维度（子项：是否支持持久化、消息确认机制）；
- 新增 “特殊功能” 维度（子项：是否支持延迟队列、死信队列、消息回溯）；
- 性能表现维度补充 “吞吐量（条 / 秒）”“消息延迟（ms）” 子项。
数据要求调整：
- 需标注 “消息持久化情况下的吞吐量”“延迟队列的最小延迟时间” 等场景化数据；
- 数据来源优先选择 “官方性能测试报告”“电商场景实测数据”。
9.1.3 提示词片段示例（对比维度部分）
二、对比维度与子项

1. 功能特性

- 子项1：消息可靠性（持久化支持、确认机制）；

- 子项2：特殊功能（延迟队列、死信队列、消息回溯）；

- 子项3：协议支持（是否支持AMQP、MQTT、Kafka协议）；

2. 性能表现（基于4核8G服务器，消息大小1KB）

- 子项1：吞吐量（条/秒，持久化模式）；

- 子项2：消息延迟（ms，普通消息/延迟消息）；

- 子项3：资源占用（CPU使用率、内存占用，单位%/GB）；

3. 适用场景

- 子项1：数据量适配（日均消息量、单队列最大消息堆积量）；

- 子项2：业务类型（异步通信、日志采集、状态同步）；

- 子项3：可靠性要求（是否允许消息丢失、重复消费处理）；

...（其他通用维度不变）

9.2 场景二：搜索引擎选型（Elasticsearch 8.10 vs Solr 9.3）

9.2.1 业务背景示例

为电商平台 “商品搜索” 场景选择搜索引擎，商品数量 100 万，需支持 “关键词模糊搜索”“筛选（如价格区间、品牌）”“排序（销量、好评率）”，核心需求：搜索响应时间≤500ms、支持中文分词、索引更新延迟≤1 分钟。

9.2.2 模板调整要点
对比维度调整：
- 新增 “搜索能力” 维度（子项：是否支持模糊搜索、短语搜索、聚合查询）；
- 新增 “分词支持” 维度（子项：是否支持中文分词、自定义分词器、分词准确率）；
- 兼容性维度补充 “与电商系统集成难度（如是否支持 Spring Data 集成）” 子项。
数据要求调整：
- 需标注 “100 万商品数据下的搜索响应时间”“中文分词准确率（如‘手机壳’是否会拆分为‘手机’+‘壳’）”；
- 索引更新延迟需标注 “实时更新 / 近实时更新” 及具体延迟时间。
9.3 场景三：服务器操作系统选型（CentOS 7 vs Ubuntu Server 22.04）

9.3.1 业务背景示例

为企业内部 “数据库服务器” 选择操作系统，数据库为 MySQL 8.0，日均访问量 100 万，核心需求：稳定性高（每月故障≤1 次）、支持国产化适配（可选）、运维工具丰富、安全补丁更新及时。

9.3.2 模板调整要点
对比维度调整：
- 新增 “稳定性与安全性” 维度（子项：平均无故障时间、安全补丁更新频率、漏洞修复速度）；
- 新增 “国产化适配” 维度（子项：是否支持国产芯片、是否通过国产化认证）；
- 成本投入维度补充 “license 成本（开源 / 商业）”“技术支持成本（社区 / 厂商支持）” 子项。
数据要求调整：
- 需标注 “平均无故障时间（小时）”“安全补丁更新周期（天）” 等量化数据；
- 国产化适配需标注 “具体支持的国产芯片型号（如飞腾、鲲鹏）”“认证类型（如等保三级、国产化名录）”。
10. 模板使用的进阶技巧

为了进一步提升提示词模板的使用效果，下面分享 3 个进阶技巧，帮助读者生成更精准、更贴合需求的技术方案对比文档。

10.1 结合 “业务优先级” 调整维度权重

不同业务场景下，各对比维度的重要性不同。例如 “金融支付系统” 更关注 “数据可靠性”，“高并发秒杀系统” 更关注 “性能表现”。可在提示词中添加 “维度权重” 说明，让大模型在对比和选型建议中优先考虑高权重维度。

10.1.1 示例提示词片段
五、约束条件

1. 维度权重排序（按重要性从高到低）：

- 高权重：数据可靠性（消息不丢失、事务支持）、性能表现（吞吐量、响应时间）；

- 中权重：成本投入（部署、运维成本）、兼容性（与现有系统集成）；

- 低权重：社区生态、学习成本；

2. 对比表格中需用“★”标注高权重子项（如“消息可靠性★”）；

3. 选型建议需优先基于高权重维度给出理由，高权重维度不满足需求的方案直接排除。

10.2 补充 “负面约束” 排除不符合方案

若某业务有明确 “不允许的特性”（如 “不允许使用闭源软件”“不支持 Windows 操作系统”），可在提示词中添加 “负面约束”，让大模型直接排除不符合的方案，减少无效对比。

10.2.1 示例提示词片段
一、对比对象与业务背景

4. 负面约束：

- 不允许选择闭源软件，所有方案需为开源协议（如Apache、MIT协议）；

- 不支持Windows操作系统，方案需适配Linux系统（CentOS/Ubuntu）；

- 若某方案不符合上述约束，需在“对比背景与目标”中说明并排除，不进入后续对比。

10.3 分 “阶段输出” 优化复杂对比

对于 “3 个及以上方案对比”“多维度复杂场景”（如同时对比 “数据库 + 缓存 + 消息队列” 组合方案），可将提示词拆分为 “阶段输出”，先让大模型输出 “对比维度细化”“数据收集清单”，确认无误后再输出完整对比文档，避免一次性输出导致的内容混乱。

10.3.1 阶段 1：输出对比维度与数据清单
需求：为电商平台“订单系统”设计技术栈对比方案（数据库：MySQL 8.0/PostgreSQL 14；缓存：Redis 7.0；消息队列：RabbitMQ 3.12），请先输出：

1. 每个组件的对比维度及子项（需结合订单系统场景）；

2. 每个子项需收集的数据清单（含数据来源要求）；

3. 格式：用Markdown列表输出，每个组件单独成节。

10.3.2 阶段 2：输出完整对比文档

基于阶段 1 确认的维度和数据清单，补充具体业务需求后，再让大模型输出完整对比文档，确保内容符合预期。