Day 11：Prompt 模板库建设
学习目标
过去三天你学会了调用模型、获取结构化输出、使用 Function Calling。今天要解决的是一个不同层面的问题：怎么管理你的 Prompt。
在 Week 1 的 Day 3 中，你学过 Prompt 工程的基本概念。那时候你写了 10 个企业级 Prompt。但随着项目推进，Prompt 会越来越多——行业分析、岗位拆解、流程优化、报告生成、风险评估，每个场景都有不同的 Prompt。如果这些 Prompt 散落在代码的各个角落，你的项目很快就会变成一团乱麻。改了一个 Prompt 不知道影响哪些功能，想复用一个 Prompt 找不到在哪个文件里，同一个场景有三个不同版本的 Prompt 不知道该用哪个。
今天要做的就是把 Prompt 从”散装状态”升级为”系统化管理”。你要建立一个 Prompt 模板库，每个 Prompt 都有清晰的分类、命名、版本、输入参数、输出格式、测试样例和评分。
完成今天的学习后，你的 Prompt 不再散落各处，每个 Prompt 都有明确的用途和标准，你可以快速找到并复用已有的 Prompt，而不是每次从零开始写。
核心概念
一、Prompt 分类
Prompt 分类是建立模板库的第一步。没有分类，几十个 Prompt 堆在一起根本无法管理。
分类的原则是：按用途分类，而不是按技术分类。不要按”JSON 输出类 Prompt”、“Few-shot Prompt”这种技术维度来分，而要按”这个 Prompt 解决什么业务问题”来分。
为什么？因为你找 Prompt 的时候想的是”我要做一个行业分析”，而不是”我要一个 JSON Mode 的 Prompt”。按用途分类让你能快速定位到需要的 Prompt。
建议的分类体系：
分析类 Prompt。用于分析某个对象并输出结构化的分析结果。包括：行业分析、公司分析、岗位分析、流程分析、竞品分析、市场分析、技术趋势分析。这类 Prompt 的特点是输入一个分析对象（名称或描述），输出多维度的结构化分析结果。
生成类 Prompt。用于生成特定类型的内容。包括：报告生成、方案生成、邮件生成、文案生成、摘要生成、翻译。这类 Prompt 的特点是输入一些关键信息，输出一段完整的文本内容。
评估类 Prompt。用于对某个对象进行量化评估。包括：AI 机会评分、风险评估、可行性评估、ROI 评估、质量评估。这类 Prompt 的特点是输入一个场景描述，输出一组评分和评语。
转换类 Prompt。用于将内容从一种形式转换为另一种形式。包括：文本转 JSON、长文转摘要、会议记录转待办事项、自由文本转结构化数据。这类 Prompt 的特点是输入和输出的信息相同，只是格式变了。
交互类 Prompt。用于模拟某种角色进行对话或咨询。包括：客户访谈模拟、需求澄清、方案讨论、销售话术。这类 Prompt 的特点是多轮交互，模型扮演特定角色。
每类 Prompt 有一些共性的设计模式。分析类 Prompt 通常包含分析维度列表和输出格式说明。评估类 Prompt 通常包含评分标准和分数含义。生成类 Prompt 通常包含内容结构模板和风格要求。识别这些模式可以帮助你批量设计同类 Prompt。
二、Prompt 命名
命名看起来是小事，但它直接影响团队的沟通效率。当你在会议上说”用那个行业分析的 Prompt”，如果仓库里有三个行业分析相关的 Prompt（一个概览版、一个详细版、一个对比版），就会产生歧义。
好的命名规则：
前缀表示类别。用简短的类别标识作为前缀，比如 analyze_industry、generate_report、evaluate_risk、transform_meeting_notes。一看名字就知道这个 Prompt 属于哪个类别。
核心词表示功能。名字的核心部分要准确描述功能。analyze_industry 比 analyze_business 清晰，generate_industry_report 比 generate_document 具体。
后缀表示变体。同一个功能的不同版本用后缀区分。比如 analyze_industry_overview（概览版）、analyze_industry_deep（深入版）、analyze_industry_comparison（对比版）。
避免技术术语。不要在名字里包含技术细节。不要叫 prompt_json_mode_v2_temperature03，这种名字对理解 Prompt 的用途没有帮助。
一致性。一旦确定了命名规则，所有 Prompt 都要遵守。不要有的用下划线有的用驼峰，有的有前缀有的没有。
命名规范应该在模板库建立之初就确定。后期改名字的成本很高——你的代码中引用了 Prompt 名称，文档中提到了 Prompt 名称，一旦改名所有引用都要更新。
三、Prompt 版本
Prompt 不是一次写好就不变的。你会发现模型升级后 Prompt 效果变差了、业务需求变化需要调整输出格式、用户反馈某个 Prompt 的结果不够好。这些都需要修改 Prompt，而修改就需要版本管理。
版本管理的核心是追踪变化：谁在什么时候改了什么，改了之后效果是变好了还是变差了。
版本号的建议规则：主版本号.次版本号。主版本号在输出格式或核心逻辑发生重大变化时递增（比如从 v1 到 v2），次版本号在小调整时递增（比如从 v1.0 到 v1.1）。
每个版本应该记录以下信息：
版本号和日期。方便按时间回溯。
变更内容。具体改了 Prompt 的哪个部分。不要只写”优化了 Prompt”，要写”增加了竞争格局分析维度”或”调整了输出格式，增加了 risk_level 字段”。
变更原因。为什么要改？是业务需求变化、模型升级导致效果下降、还是用户反馈问题？
变更前后效果对比。用同一组测试数据，比较变更前后的输出质量。这是判断变更是否有效的唯一依据。
回滚方案。如果新版本效果不如旧版本，如何快速回滚。
版本管理的实现方式可以很简单——一个表格或一个 JSON 文件，记录每个 Prompt 的版本历史。重要的是养成记录的习惯，而不是用什么高级工具。
四、Prompt 输入参数
Prompt 模板和直接写 Prompt 的区别在于：模板有参数化的输入。
一个裸 Prompt 可能是：“请分析半导体行业的发展趋势、市场规模、竞争格局和 AI 应用机会。“这个 Prompt 是硬编码的，只能分析半导体行业。
一个参数化的模板是：“请分析{industry_name}行业的发展趋势、市场规模、竞争格局和 AI 应用机会。“其中 industry_name 是一个参数，你可以传入任何行业名称。
参数化设计的好处：
复用性。同一个模板可以用于不同的输入。行业分析模板可以分析半导体、制造业、金融业等任何行业。
可测试性。有了固定的模板和可变的参数，你可以设计标准的测试集——对每个模板用不同的参数测试，评估输出的稳定性和质量。
可维护性。需要调整分析维度时，只需要修改模板，不需要修改每个使用场景的代码。
参数设计的原则：
参数要少而精。每个模板的参数不要超过 5 个。参数太多说明模板的通用性设计有问题——要么模板太笼统，要么应该拆成多个模板。
参数要有类型。每个参数需要定义类型（字符串、数字、布尔值、枚举）和约束（长度、范围、必填/选填）。这些类型信息不仅用于文档，也用于运行时验证——在构造 Prompt 之前先验证参数是否合法。
参数名要有意义。用 industry_name 而不是 param1，用 analysis_depth 而不是 option。
参数可以有默认值。某些参数不传时使用默认值，提高使用的便利性。比如 analysis_depth 不传时默认为”标准”。
五、Prompt 输出格式
每个 Prompt 模板都应该定义清晰的输出格式。这和 Day 9 学的结构化输出是一脉相承的。
输出格式的定义包括两部分：
格式规范。输出是 JSON、Markdown、还是自由文本？如果是 JSON，JSON 的结构是什么（对应 Day 9 的 JSON Schema）？如果是 Markdown，包含哪些章节？
质量标准。输出的内容应该满足什么质量要求？比如”行业概述应该在 100-300 字之间”、“AI 机会列表应该包含 3-5 个具体的场景”、“每个评分必须附带理由”。
定义输出格式的目的是让使用者（你或你的同事）知道这个 Prompt 会产出什么，也让评估者知道按什么标准来评估输出质量。
一个好的做法是在模板的元数据中同时附上输出格式的 Schema 和一个输出样例。Schema 是机器可读的精确描述，样例是人可读的具体参考。两者配合，使用者能快速理解输出的样子。
六、Prompt 测试样例
测试样例是验证 Prompt 效果的标准数据集。
为什么需要测试样例？因为 Prompt 的效果不能只凭感觉判断。你觉得这个 Prompt 挺好的，但换一个输入可能输出质量就很差。测试样例提供了一个客观的衡量标准——同一组输入，看看输出是否稳定、是否满足质量要求。
测试样例的设计原则：
覆盖典型场景。每个 Prompt 至少准备 3-5 个典型的测试输入。比如行业分析 Prompt 的测试样例应该包含不同类型的行业：制造业（半导体）、服务业（教育）、金融业（保险）。
覆盖边界场景。除了典型输入，还要测试边界情况：极短的输入（只给行业名称不给其他信息）、极长的输入（给了一大段描述）、模糊的输入（“帮我看看那个行业”——哪个行业？）、不合法的输入（传入了空字符串）。
测试样例要固定。一旦确定了测试样例，就不要随意更改。更改测试样例会导致前后评估结果不可比较。
预期输出要标注。每个测试样例应该有一个”期望输出”的描述。不一定要精确到每个字段值，但至少要说明期望的输出结构和关键内容。比如”期望输出包含 4 个分析维度，每个维度有描述和评分”。
测试样例可以按难度分级：
基础样例（Level 1）。标准输入，期望标准输出。这是最基本的功能测试。
变化样例（Level 2）。输入有所变化，测试 Prompt 的适应性。比如行业名称用英文缩写传入。
压力样例（Level 3）。极端或异常输入，测试 Prompt 的鲁棒性。比如输入”未知行业”或者包含特殊字符。
七、Prompt 评分
评分体系是量化 Prompt 质量的工具。
没有评分体系，你只能说”这个 Prompt 感觉还行”。有了评分体系，你可以说”这个 Prompt 在准确性上得 8 分，在格式合规上得 9 分，在信息完整度上得 7 分，综合得分 8.0”。
评分维度建议：
格式合规度（1-10 分）。输出格式是否符合定义的 Schema？JSON 结构是否正确？字段是否齐全？
内容准确性（1-10 分）。输出的内容是否事实正确？有没有明显的错误或幻觉？
信息完整度（1-10 分）。是否覆盖了所有要求的维度？有没有遗漏重要信息？
可操作性（1-10 分）。输出是否足够具体、可执行？还是泛泛而谈、缺乏细节？
稳定性（1-10 分）。同样的输入多次执行，输出的差异有多大？差异越小稳定性越高。
评分方式：
人工评分。人工阅读输出并按维度打分。准确性高但效率低，适合关键 Prompt 的定期评估。
自动评分。用另一个 Prompt 来评估输出质量。效率高但准确性依赖评估 Prompt 的设计，适合日常批量评估。
模型自评。让模型给自己的输出打分。效率最高但自我评估的客观性存疑，适合快速筛查。
一个实用的做法是：建立评分后设定一个及格线（比如综合分 7 分以下需要优化），以及一个优秀线（比如综合分 9 分以上可以作为标杆）。
八、Prompt 迭代记录
迭代记录是 Prompt 从初始版本到当前版本的演进历史。
为什么迭代记录重要？因为在实际项目中，Prompt 的优化是一个反复迭代的过程。你可能改了十几次才达到满意的效果。如果没有记录，你不知道哪次改动了什么、效果变好了还是变差了、当前版本是不是最优的。
迭代记录的格式建议：
每次迭代的记录应该包含：迭代编号、日期、变更描述（改了什么）、变更原因（为什么改）、测试结果（改了之后效果如何）、决策（保留这个变更还是回滚）。
迭代记录的用途：
知识积累。记录哪些改法有效、哪些无效。这些经验对未来设计其他 Prompt 有参考价值。
问题排查。当某个 Prompt 的效果突然变差，可以通过迭代记录定位是哪次变更导致的问题。
团队协作。多人协作时，迭代记录让大家知道 Prompt 的演变过程和当前状态。
避免重复。防止不同的人在不同时间做同样的修改尝试。
一个常见的问题是：迭代记录写了但不看。为了避免这个问题，可以在每次修改 Prompt 前先回顾一下迭代记录，看看有没有之前尝试过类似修改但失败的案例。
概念关系图
+-------------------------------------------------------+
| Prompt 模板库 |
+-------------------------------------------------------+
| |
| +-- 分类体系 --+ +-- 命名规范 --+ +-- 版本管理 --+ |
| | 分析类 | | 前缀_核心_后缀| | v1.0 -> v1.1 | |
| | 生成类 | | snake_case | | 变更记录 | |
| | 评估类 | | 语义化命名 | | 回滚方案 | |
| | 转换类 | | | | | |
| | 交互类 | | | | | |
| +------+-------+ +------+-------+ +------+-------+ |
| | | | |
+---------+------------------+------------------+---------+
| | |
v v v
+-------------------------------------------------------+
| 单个 Prompt 模板的结构 |
| |
| 元数据：名称、分类、版本、创建时间、最后更新时间 |
| 输入参数：参数名、类型、约束、默认值 |
| 模板正文：带参数占位符的 Prompt 文本 |
| 输出格式：JSON Schema 或格式说明 |
| 测试样例：3-5 组输入 + 期望输出 |
| 评分记录：各维度的历史评分 |
| 迭代记录：版本变更历史和效果对比 |
| |
+-------------------------------------------------------+
|
v
+-------------------------------------------------------+
| Prompt 使用流程 |
| |
| 1. 根据业务需求选择分类和模板 |
| 2. 准备输入参数 |
| 3. 参数填充到模板，生成完整 Prompt |
| 4. 调用模型（通过 LLM Client） |
| 5. 校验输出格式（通过结构化输出机制） |
| 6. 记录评分和日志 |
| |
+-------------------------------------------------------+
实战分析
任务一：建立 Prompt 模板库目录
模板库的目录结构决定了你的管理效率。
建议的目录结构：按分类建立文件夹，每个 Prompt 模板是一个独立文件。每个文件包含模板定义（YAML 或 JSON 格式）和模板正文（Markdown 格式）。
模板定义文件包含：metadata（名称、分类、版本、作者、创建时间、更新时间）、input_schema（输入参数的定义）、output_schema（输出格式的定义）、test_cases（测试样例列表）、score_history（评分历史）。
这个结构的好处是：机器可读（JSON/YAML 可以被程序解析），人可读（Markdown 正文可以直接阅读），版本可控（文件可以纳入 Git 管理）。
任务二：写 20 个 Prompt 模板
指南要求写 20 个模板。这些模板覆盖你的核心业务场景。
按分类分配：
分析类（8 个）：行业概览分析、行业深度分析、公司竞争力分析、岗位任务拆解、流程效率分析、竞品对比分析、市场机会分析、技术趋势分析。
评估类（4 个）：AI 机会评分、风险评估、可行性评估、ROI 快速估算。
生成类（5 个）：行业报告生成、解决方案生成、实施计划生成、客户提案生成、销售话术生成。
转换类（2 个）：会议记录转待办、自由文本转结构化 JSON。
交互类（1 个）：客户需求访谈引导。
每个模板的设计要遵循统一的格式：有明确的输入参数定义、清晰的输出格式说明、至少 2 个测试样例。
任务三：设计评分维度
综合前面提到的评分维度，设计一套标准的评分表。
评分维度和权重：格式合规度（权重 20%）、内容准确性（权重 30%）、信息完整度（权重 20%）、可操作性（权重 20%）、稳定性（权重 10%）。
综合分 = 各维度加权求和。
及格线：综合分 7.0 分。低于此分数的 Prompt 需要优化。 优秀线：综合分 9.0 分。达到此分数的 Prompt 可作为标杆。
每个测试样例都要评分，一个 Prompt 的最终得分是所有测试样例得分的平均值。
补充：从零开始写第一个模板的完整过程
很多人觉得模板库很抽象，不知道从哪里下手。这里用一个具体的例子走一遍完整流程——从需求分析到模板定稿。
假设你要写一个”行业 AI 机会快速评估”的 Prompt 模板。
第一步，明确用途。这个模板用于快速评估某个行业中是否存在高价值的 AI 应用机会。使用场景是：你在和客户初次沟通时，客户提到他的行业，你想快速判断值不值得深入分析。
第二步，确定输入。行业名称（必填）、简要的上下文信息（选填，比如客户提到的一些痛点）。
第三步，确定输出。AI 机会评分（1-10 分）、前三个最有价值的 AI 场景、每个场景的简要描述和预期效果、总体建议（值得深入/需要调研/暂时不建议）。
第四步，写模板正文。模板的核心结构包括：角色设定（你是一个行业 AI 应用评估专家）、任务描述（评估指定行业的 AI 应用机会）、输出格式（JSON 格式，包含评分、场景列表、建议）、约束条件（输出要基于事实，不要过度乐观）。
第五步，写测试样例。至少准备三个测试行业：一个 AI 机会丰富的行业（制造业）、一个 AI 机会较少的行业（传统零售）、一个你不太了解的行业（宠物医疗）。对比三次输出的质量。
第六步，打分和迭代。根据评分结果调整模板。如果发现输出太笼统，在模板中增加”每个场景描述至少 50 字”的约束。如果发现评分不合理，在模板中增加评分标准的说明。
这个过程看起来繁琐，但跑过一次就熟练了。后续每个新模板都可以按这个流程走。前期花在模板设计上的时间，会在后续复用时成倍地节省回来。
补充：模板库的日常维护策略
模板库建好了不代表万事大吉。它需要持续的维护和更新。
维护的节奏建议：
每周回顾。每周花 30 分钟回顾本周使用过的 Prompt。有没有哪个 Prompt 的输出质量下降了？有没有新的业务场景需要新的模板？有没有可以合并的重复模板？
每月评分。每月对所有核心 Prompt 做一次完整评分。对比本月和上月的评分变化——如果某个 Prompt 的评分持续下降，说明可能需要优化或者模型更新导致了效果变化。
季度清理。每季度清理一次模板库。删除不再使用的模板、合并功能重复的模板、归档过时版本的模板。模板库应该是精炼的，不是臃肿的。
维护的常见信号。当你发现以下情况时，说明某个模板需要维护：团队成员不再使用某个模板而是自己从头写 Prompt（说明模板不好用）、同一个场景有多个版本的模板在同时使用（说明没有做好版本管理）、模板的评分连续两个月下降（说明需要优化）。
一个好的模板库像一个活的有机体——不断有新的模板加入，旧的模板被优化或淘汰，整体质量在持续提升。一个停滞不前的模板库很快就会失去价值，因为业务在变、模型在变、需求在变。
当日产物说明
Prompt 模板库 v1
包含 20 个 Prompt 模板的完整模板库。每个模板都有：元数据（名称、分类、版本）、输入参数定义、模板正文、输出格式说明、至少 2 个测试样例。
模板库应该有总览文档（README），列出所有模板的名称、分类、用途简述，方便快速查找。
Prompt 版本管理表
一个表格（Excel 或 Markdown），记录每个 Prompt 的版本历史。每个版本包含：Prompt 名称、版本号、变更日期、变更内容、变更原因、测试结果（通过/未通过/部分通过）、备注。
Prompt 测试样例 20 条
20 组完整的测试数据。每组包含：模板名称、输入参数（完整的参数值）、期望输出描述（关键信息的检查清单）、实际输出（首次测试的结果）、评分（各维度分数）。
测试样例要覆盖不同的场景——不要 20 个全是简单场景。至少有 5 个是边界或压力场景。
常见误区与避坑
误区一：Prompt 写完就不管了
花了一下午写了 20 个 Prompt，写完就丢到文件夹里再也不看。模型升级了不知道效果有没有变化，业务需求改了没有同步更新 Prompt。Prompt 是需要持续维护的资产，不是一次性交付物。建议每周花 30 分钟回顾核心 Prompt 的效果。
误区二：不区分模板和实例
在代码里直接硬编码了一个 500 字的 Prompt，然后复制粘贴到另一个文件稍微改改就用。这不是模板化。模板应该是参数化的——核心框架固定，可变部分用参数占位。代码中只引用模板名称和传入参数，不直接写 Prompt 内容。
误区三：版本管理形同虚设
记录了版本号但没有记录变更内容和效果对比。看到 Prompt 版本从 v1.3 变成了 v2.0，但不知道改了什么、效果是变好了还是变差了。版本管理的关键不是版本号本身，而是版本号背后的变更记录和效果对比。
误区四：测试样例太单一
所有测试样例都是类似的输入，比如行业分析 Prompt 的测试样例全是热门行业（半导体、新能源、AI）。应该加入冷门行业（殡葬服务、宠物食品、工业气体）来测试 Prompt 的适应能力。
误区五：评分全靠主观感觉
打分的时候没有固定标准，心情好就打高分，心情差就打低分。评分体系的价值在于标准化——不同时间、不同人打出来的分数应该具有可比性。每个维度要有明确的评分标准（比如 8 分意味着什么、5 分意味着什么）。
延伸思考
Prompt 模板库不是一个独立的工具，它是你整个 AI 应用的”大脑”。你的后端服务收到一个”分析行业”的请求时，第一步就是从模板库中选择合适的 Prompt 模板，填入参数，调用模型。模板库的质量直接决定了你系统的输出质量。
在后续的 Week 5 工程化阶段，你会把模板库从文件系统升级为数据库存储，加上权限管理、版本对比、A/B 测试等高级功能。但无论工具怎么升级，核心逻辑不变——分类、命名、版本、参数、测试、评分、迭代。
从更商业化的角度看，Prompt 模板库就是你作为 AI 应用开发者的”核心资产”。你为客户做的行业分析、方案设计，最终沉淀下来的就是一套经过验证的 Prompt 模板。这套模板越用越完善，你的交付效率越来越高，交付质量越来越稳定。这就是为什么花时间建立模板库不是”浪费时间”而是”投资”。
自测问题
- 为什么 Prompt 分类要按用途而不是按技术维度？给你一个具体的场景说明区别。
- Prompt 命名规范的 snake_case 规则是什么？为什么要保持一致性？
- Prompt 版本管理中，什么情况下应该递增主版本号？什么情况下递增次版本号？
- 参数化的 Prompt 模板和硬编码的 Prompt 相比，有什么好处？
- 测试样例为什么要覆盖边界场景？只覆盖典型场景有什么问题？
- Prompt 评分体系中，为什么”稳定性”维度很重要？一个不稳定但偶尔输出优秀的 Prompt 有什么问题？
- 迭代记录的核心价值是什么？如果没有迭代记录，你在什么场景下会遇到困难？
- 如果一个 Prompt 的综合评分只有 6.5 分（低于及格线 7.0），你应该按什么步骤来优化它？
- 为什么说 Prompt 模板库是 AI 应用开发者的”核心资产”？
- 在团队协作中，Prompt 模板库能解决什么沟通问题？
关键词
- Prompt 分类：按业务用途对 Prompt 进行分组管理（分析类、生成类、评估类、转换类、交互类）
- Prompt 命名：使用前缀_核心_后缀的规则为 Prompt 赋予唯一标识
- Prompt 版本：追踪 Prompt 变更历史的管理机制，包含变更内容和效果对比
- 输入参数：Prompt 模板中的可变部分，通过参数化实现模板复用
- 输出格式：每个 Prompt 模板定义的标准输出结构，对应 JSON Schema
- 测试样例：用于验证 Prompt 效果的标准输入输出数据集
- Prompt 评分：按多维度对 Prompt 输出质量进行量化评估的体系
- 迭代记录：Prompt 从初始版本到当前版本的完整演进历史
- 模板库：集中管理所有 Prompt 模板的系统，支持分类检索和版本管理
- 参数化模板：将 Prompt 中的可变部分抽象为参数的模板设计模式