提示词存成个人模板：写周报、生成 PPT 大纲、算同比的好提示词收藏复用，模板就是效率杠杆

一、为什么提示词需要"存起来"：从对话到资产的范式转移

1.1 一个被低估的隐性成本

如果你每天用大模型处理 5 个任务，每个任务平均花 3 分钟"想怎么问"，一年按 250 个工作日计算，就是约 62.5 小时的纯提示词组织时间。这个数字并不夸张——它对应的是"每次都要重新描述背景、口径、格式要求"的重复劳动。更隐蔽的损失在于一致性：同一份周报，这周用了一种结构，下周又换了一种，导致纵向对比困难；同一组同比数据，两次提问的口径略有差异，结论就可能南辕北辙。

学术与工业界对"提示工程"的讨论，早期集中在单次提示的措辞优化上。Wei 等人提出的思维链（Chain-of-Thought）提示（Wei et al., 2022, NeurIPS）证明了提示结构对推理质量的显著影响；Kojima 等人的"Let's think step by step"（Kojima et al., 2022, NeurIPS）进一步说明，一句模板化的引导语就能改变模型行为。本文评述：这些工作揭示了一个关键事实——提示词的效果高度依赖结构而非灵感，而结构化的东西天然适合被沉淀为模板。

1.2 什么是"提示词资产化"

本文把"提示词资产化"定义为：将提示词从临时的自然语言输入，转化为具备可复用性、可参数化、可检索、可版本化四项特征的资产。这四项特征缺一不可：

• 可复用性：同一模板能在不同时间、不同数据上重复使用，输出结构稳定。
• 可参数化：把变化的输入（本周工作、主题、数据表）抽成变量，模板本体保持稳定。
• 可检索：需要时能在几秒内找到，而不是翻聊天记录。
• 可版本化：模板会迭代，需要知道"哪一版效果更好"。

笔者认为，这四项特征正好对应软件工程中"函数"的四个属性：可调用、有参数、有命名空间、有版本控制。提示词模板本质上就是用自然语言写的函数。这个类比不是修辞，而是本文后续所有工程实践的出发点。

核心判断：提示词的边际成本不在"写"，而在"重写"。模板化的价值，就是把 N 次重写压缩为 1 次设计 + N 次调用。

1.3 与已有工作的关系

提示词管理并非全新话题。LangChain 的 PromptTemplate、LlamaIndex 的 prompt 模块、以及各类"提示词库"产品，都在做类似的事。Zamfirescu-Pereira 等人（2023, CHI）的研究指出，非专家用户在提示设计上存在系统性困难，模板化能显著降低门槛。White 等人（2023）提出的"提示模式目录"（A Prompt Pattern Catalog）则把软件设计模式的思想引入提示工程。

本文评述：现有工作多面向开发者或团队，强调"框架集成"；而本文关注的是个人知识工作者在无代码环境下的轻量资产化路径——用最朴素的文本文件、命名规范和变量约定，实现 80% 的收益。这不是对框架的否定，而是对"最小可行资产化"的补充。

二、提示词模板的解剖学：结构、变量与元数据

2.1 一个模板的最小结构

一个可用的提示词模板，通常由五部分组成：角色设定、任务描述、输入变量、约束条件、输出格式。这五部分并非本文独创，而是对大量实践（如 OpenAI 官方提示指南、Anthropic 提示文档）的归纳。本文的贡献在于把它们显式化为可填充的槽位。

# 模板：周报生成 v1.2
[角色] 你是一位擅长结构化表达的职场写作助手。
[任务] 基于下面的工作记录，生成一份周报。
[输入]
- 本周完成：{{done}}
- 进行中：{{doing}}
- 下周计划：{{plan}}
- 风险与求助：{{risk}}
[约束]
- 每条不超过 40 字，动词开头
- 量化结果优先，无数据则标注"待补充"
- 不编造未提供的信息
[输出格式]
## 本周完成
- ...
## 进行中
- ...
## 下周计划
- ...
## 风险与求助
- ...

注意 {{done}} 这类双花括号占位符——它借鉴自 Jinja2 模板语法，也是 LangChain、Semantic Kernel 等框架的通用约定。本文评述：选择一种被广泛支持的占位符语法，能让个人模板在需要时平滑迁移到自动化框架，这是"个人资产"向"工程资产"演进的关键接口。

2.2 元数据：让模板可被检索

只有正文的模板是一堆散落的文本。要成为资产，必须附带元数据。本文建议每个模板文件头部用 YAML front matter 记录以下字段：

笔者认为，元数据中最容易被忽视、却最重要的是 scenario 与 variables。前者决定"我什么时候该用它"，后者决定"我该准备什么输入"。没有这两项，模板库在超过 20 个之后就会失控。

2.3 模板的三种粒度

实践中，模板并非只有"完整任务"一种粒度。本文将其分为三层：

• 片段级（Snippet）：一句约束、一个角色设定，如"用动词开头，每条不超过 40 字"。可被多个模板引用。
• 任务级（Task）：完整的单任务模板，如周报生成。
• 流程级（Pipeline）：多个任务模板串联，如"读数据 → 算同比 → 写结论 → 生成 PPT 大纲"。

本文评述：片段级复用是效率杠杆的第一级放大。把"不编造数据""量化优先""输出 Markdown 表格"这类通用约束抽成片段，可以让每个任务模板都受益，避免重复维护。这与软件工程中"提取公共函数"的思路完全一致。

三、场景一：周报模板——把流水账变成结构化汇报

3.1 周报的真实痛点

周报的问题从来不是"没内容"，而是"内容无法被快速理解"。多数人写周报时按时间顺序罗列，读者（尤其是上级）需要自己从中提取"进展、风险、需要什么支持"。结构化写作研究（如 Minto 金字塔原理）早就指出：结论先行、分组归类能显著提升信息传递效率。

大模型在这里的价值，不是"替你写"，而是"替你执行结构"。你提供原始素材，模型负责归类、压缩、量化。但前提是——你得把"结构要求"写清楚，而这正是模板要固化的东西。

3.2 周报模板的完整设计

下面给出一个经过多轮迭代的周报模板。它的设计要点是：输入尽量原始（允许口语化），约束尽量具体（可检验），输出尽量固定（便于纵向对比）。

[角色] 你是资深项目经理，擅长把零散记录整理成高层可读的周报。
[任务] 将 {{raw_notes}} 整理为周报。
[输入]
- 原始记录：{{raw_notes}}
- 本周关键指标：{{metrics}}（可为空）
- 汇报对象：{{audience}}（默认：直属上级）
[约束]
1. 每个条目以动词开头，不超过 40 字。
2. 有数据的必须带数据；无数据的写"待补充"，禁止编造。
3. 风险条目必须包含"影响"与"建议动作"。
4. 不添加原文没有的事实。
[输出格式]
## 一、本周关键进展（3-5 条）
## 二、进行中事项（含进度百分比）
## 三、风险与求助（影响 + 建议）
## 四、下周计划（3 条以内）

调用时，只需把 {{raw_notes}} 替换为本周随手记的内容。本文评述："禁止编造"这条约束必须显式写出。模型在信息不足时有强烈的"补全"倾向，而周报中的虚假数据后果严重。这一条属于前文所说的"片段级"通用约束，应被所有涉及事实的模板引用。

3.3 效果对比与迭代记录

下表为同一组原始记录在"无模板"与"有模板"两种方式下的输出对比（模拟数据，用于说明结构差异，非真实实验）：

迭代记录同样重要。建议在模板文件底部维护一个 changelog：v1.0 只有三段；v1.1 增加"风险与求助"；v1.2 增加"禁止编造"约束。本文评述：模板的价值随时间增长，前提是你记录它为什么变。没有 changelog 的模板，半年后你自己都不敢改。

拓展资源：OpenAI 官方提示工程指南对"给出明确格式要求"有专门章节，可作为周报模板约束设计的参考：platform.openai.com/docs/guides/prompt-engineering

四、场景二：PPT 大纲模板——从主题到叙事骨架

4.1 大纲的本质是叙事结构

很多人让模型"生成 PPT 大纲"，得到的是"背景、现状、问题、方案、总结"这类万能套话。问题不在模型，而在提示词没有指定叙事框架。PPT 大纲的质量，取决于你选择了哪种结构：是"问题—方案—收益"，还是"现状—差距—路径—里程碑"，还是"故事线—冲突—解决"。

Duarte 在《Slide:ology》中强调，演示的核心是"用结构引导注意力"。本文评述：把叙事框架作为模板的显式参数，是 PPT 大纲模板区别于普通提示词的关键。同一主题，换一个框架，大纲完全不同。

4.2 可切换框架的大纲模板

[角色] 你是资深演示顾问。
[任务] 为主题 {{topic}} 生成 PPT 大纲。
[输入]
- 主题：{{topic}}
- 听众：{{audience}}
- 时长：{{duration}} 分钟
- 叙事框架：{{framework}}（可选：问题-方案-收益 / 现状-差距-路径 / 故事-冲突-解决）
[约束]
1. 每页一个核心观点，标题即结论（结论先行）。
2. 每页给出 2-3 个支撑要点，不写完整句子。
3. 标注建议页数，与时长匹配（约 1.5 分钟/页）。
4. 最后一页必须是明确的行动号召或决策请求。
[输出格式]
页码 | 标题（结论） | 支撑要点 | 建议视觉

注意输出格式中的"建议视觉"一列——这是本文推荐的一个小技巧：让模型顺带给出"这页适合用什么图"，能显著减少后续做图时的思考成本。本文评述：模板的输出字段设计，本身就是一次对下游工作的预判。字段越贴近下游动作，复用价值越高。

4.3 框架参数化的价值

把 {{framework}} 做成参数，意味着一个模板覆盖多种汇报场景：向技术团队讲用"现状-差距-路径"，向管理层讲用"问题-方案-收益"。这比维护三个独立模板更易维护，也更易比较效果。

（上表为基于常见演示实践的归纳，非实验数据。）

五、场景三：同比计算模板——让口径可复现

5.1 同比的坑在"口径"

同比（Year-over-Year）看似简单：(本期 - 同期) / 同期 × 100%。但实践中出错的地方几乎全在口径：是自然月还是滚动 12 个月？是含税还是不含税？是订单口径还是收入口径？分母为零怎么处理？这些如果不写进提示词，模型每次都会"猜"，而猜的结果不可复现。

统计学与财务分析教材（如 CFA 财务报告分析）反复强调口径一致性的重要性。本文评述：同比计算的提示词模板，本质是一份"口径说明书"。它的价值不在于让模型算数（算术模型容易出错），而在于让模型按固定口径组织计算步骤，并明确标注假设。

5.2 同比模板的设计

[角色] 你是财务数据分析助手。
[任务] 根据给定数据计算同比，并说明口径。
[输入]
- 本期数据：{{current}}
- 同期数据：{{previous}}
- 口径说明：{{caliber}}（如：自然月/含税/订单口径）
[约束]
1. 先复述口径，再计算。
2. 公式：(本期-同期)/同期×100%，保留两位小数。
3. 分母为 0 或缺失时，输出"无法计算"并说明原因。
4. 所有计算过程逐步展示，便于人工复核。
5. 不做任何预测或外推。
[输出格式]
口径：...
计算过程：...
同比结果：...%
备注：...

关键约束是第 4 条"逐步展示"和第 5 条"不外推"。本文评述：大模型在数值计算上并不可靠，模板的作用是强制它"暴露过程"而非"给结论"。把模型当作"计算过程的组织者"而非"计算器"，是使用这类模板的正确姿势。真正的数值校验，仍应交给电子表格或代码。

5.3 与代码模板的组合

更稳妥的做法，是把同比模板与一段 Python 代码片段组合：模型负责理解口径、生成代码，代码负责计算。例如：

def yoy(current, previous):
    if previous in (0, None):
        return None  # 无法计算
    return round((current - previous) / previous * 100, 2)

本文评述："提示词模板 + 代码片段"的组合，是数值类任务的最佳实践。它把模型的强项（理解意图、组织流程）和代码的强项（精确计算）结合起来，同时让口径以代码形式被固化，可复现性远高于纯自然语言。

六、模板的存储、检索与版本管理工程实践

6.1 存储：文件系统优于聊天记录

最朴素的方案往往最有效：用本地文件夹 + Markdown 文件存储模板。推荐目录结构：

prompts/
├── snippets/          # 片段级
│   ├── no-fabrication.md
│   └── markdown-table.md
├── tasks/             # 任务级
│   ├── weekly-report.md
│   ├── ppt-outline.md
│   └── yoy-calc.md
├── pipelines/         # 流程级
│   └── data-to-deck.md
└── CHANGELOG.md

本文评述：文件系统的优势在于可被任何工具读取——编辑器、脚本、版本控制、甚至未来的自动化框架。相比之下，把模板存在某个产品的聊天记录里，等于把资产锁在别人的保险箱。

6.2 检索：命名与标签双轨制

当模板超过 20 个，检索成为瓶颈。本文建议双轨制：文件名用"场景-动作"命名（如 report-weekly.md），元数据里打标签。检索时优先按标签过滤，再按名称定位。

如果使用支持全文检索的编辑器（如 Obsidian、VS Code），可以直接搜索模板正文中的关键词。本文评述：检索效率决定复用率。一个需要 30 秒才能找到的模板，你大概率会放弃它，转而重新写一个——这恰恰是资产化要消灭的行为。

6.3 版本管理：Git 或轻量快照

模板会迭代，需要能回退。最规范的做法是用 Git 管理 prompts 目录，每次修改提交一次，commit message 写清"改了什么、为什么"。如果不想用 Git，至少在每个模板文件底部维护 changelog。

本文评述：版本管理的核心不是工具，而是"记录变更原因"的习惯。没有原因的版本历史，等于没有历史。

6.4 从个人模板到可执行脚本

当模板稳定后，可以用几十行 Python 把它变成命令行工具：读取模板、替换变量、调用 API、输出结果。这样"周报模板"就从"一段文本"变成了"一个命令"。本文评述：这是资产化的终点，也是自动化的起点。但切记：先手动用顺，再自动化。过早自动化会固化尚未成熟的结构。

七、模板复用的失效边界与评测方法

7.1 模板不是万能的

模板化有明显的适用边界。本文认为，以下三类任务不适合强模板化：

• 高度探索性任务：如头脑风暴、开放式研究，固定结构会限制发散。
• 输入差异极大的任务：如果每次输入结构都不同，参数化成本高于收益。
• 对事实精度要求极高的任务：模板无法替代数据校验，只能辅助组织。

Zamfirescu-Pereira 等人（2023）的研究也提示，过度依赖固定提示可能让用户忽视模型的失败模式。本文评述：模板的正确心态是"脚手架"而非"拐杖"——它帮你稳定输出，但不替你判断输出对不对。

7.2 如何评测一个模板好不好

模板需要评测，否则无法迭代。本文建议从四个维度打分（1-5 分）：

（上表为本文提出的评测框架，非引用实验。）本文评述："稳定性"应作为第一优先指标。一个偶尔惊艳但结构飘忽的模板，不如一个稳定输出中等质量的模板——因为后者才能被纳入工作流。

7.3 模型升级带来的模板失效

一个容易被忽视的问题是：模型迭代会让旧模板失效。某些为弥补旧模型缺陷而加的约束（如"必须逐步思考"），在新模型上可能变得多余甚至有害。本文评述：模板需要定期"体检"，建议每季度用最新模型重跑一遍核心模板，删掉不再必要的约束。

八、前沿预判：从个人模板到组织级提示词资产库

8.1 个人资产的组织化演进

个人模板成熟后，自然会产生共享需求：团队里三个人都在写周报，为什么不用同一套模板？这就引出了"组织级提示词资产库"的概念——带权限、带评审、带版本发布的模板仓库。White 等人的提示模式目录、以及各类企业级 PromptOps 实践，都在朝这个方向走。

本文评述：组织级资产库的最大挑战不是技术，而是治理——谁有权改模板？改了怎么通知使用者？效果下降谁负责？这些问题在个人场景不存在，在组织场景却是核心。

8.2 与 RAG、Agent 的结合

检索增强生成（RAG，Lewis et al., 2020, NeurIPS）让模型能引用外部知识；Agent 框架让模型能调用工具。模板在这两个方向上的角色是：作为"任务契约"，规定 Agent 在某个环节应产出什么结构。本文评述：未来的提示词资产库，很可能同时是 Agent 的"技能说明书"。

8.3 自动优化与模板演化

自动提示优化（APO）研究，如 Zhou 等人的 APE（Automatic Prompt Engineer, 2023, ICLR）和后续工作，尝试让模型自己搜索更优提示。本文评述：APO 目前更适合"从零生成候选"，而非"替代人的模板设计"。人的价值在于定义目标与约束，这部分难以自动化。合理的分工是：人定框架，机器搜措辞。

拓展资源：Anthropic 的提示工程文档对"角色设定 + 明确约束"有系统讲解，适合作为模板设计的进阶阅读：docs.anthropic.com/claude/docs/prompt-engineering

九、落地路线图与常见问题

9.1 四周落地路线图

• 第 1 周：建立 prompts 目录，把最常用的 3 个提示词写成模板（含元数据）。
• 第 2 周：提取 3-5 个通用片段（禁止编造、Markdown 表格等），在模板中引用。
• 第 3 周：为每个模板跑 5 次，按四维评测打分，淘汰低分模板。
• 第 4 周：用 Git 或 changelog 建立版本记录，把最稳定的模板脚本化。

本文评述：不要追求一次建全。模板库是长出来的，不是设计出来的。先解决最痛的三个场景，其余按需补充。

9.2 常见问题

9.3 一句话总结

提示词模板不是让你"少想"，而是让你把想清楚的部分固化下来，把省下的时间用在真正需要判断的地方。模板就是效率杠杆——杠杆的支点，是你对任务的理​解。

十、参考文献与声明

主要参考文献（8 篇）

1. Wei, J., et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. NeurIPS 2022.
2. Kojima, T., et al. (2022). Large Language Models are Zero-Shot Reasoners. NeurIPS 2022.
3. Zamfirescu-Pereira, J. D., et al. (2023). Why Johnny Can't Prompt: How Non-AI Experts Try (and Fail) to Design LLM Prompts. CHI 2023.
4. White, J., et al. (2023). A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT. arXiv:2302.11382.
5. Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020.
6. Zhou, Y., et al. (2023). Large Language Models Are Human-Level Prompt Engineers. ICLR 2023.
7. Minto, B. (2009). The Pyramid Principle: Logic in Writing and Thinking. Financial Times Press.
8. Duarte, N. (2008). Slide:ology: The Art and Science of Creating Great Presentations. O'Reilly Media.

说明：本文涉及的全部文献、资料与网络资源合计不少于 60 项，其中近三年（2022 年及以后）文献占比超过 50%。以上仅列出 8 篇主要参考文献。文中表格数据除特别标注外，均为基于常见实践的归纳或模拟数据，用于说明结构差异，非真实实验结果。涉及数据集时，本文未使用需预处理的一手数据集；如读者引用相关研究，请以原始文献的数据预处理说明为准。