06｜结构化提示词：从随意聊天到工程化模板

场景引入：你的prompt只有你自己能用

团队里的小陈花了两周时间打磨出一套prompt，用来让AI生成产品周报。效果非常好——格式清晰、数据准确、老板很满意。

然后小陈休假了。

同事小王接手这个任务，打开小陈的prompt文档，看到的是一段800字的自然语言长文：

你是一个产品分析专家，我需要你帮我写周报，周报要包含本周上线的功能和对应的
数据表现，还有下周的计划，格式要用markdown，数据部分用表格，要专业但不要太
生硬，语气要像是写给VP看的那种，对了数据如果有环比增长要标注百分比，还有功
能描述不要太技术化要让非技术人员也能看懂...

小王读了三遍也不确定哪些是必须的、哪些是可选的、哪里可以修改、哪里不能动。改了几个地方后，产出的周报完全变了样。

这就是非结构化prompt的致命问题：写的人知道每句话的意图，但其他人看到的只是一堵文字墙。

就像代码需要函数、类和模块来组织一样，prompt也需要清晰的结构来保证可读性、可维护性和可复用性。

为什么需要结构化

非结构化prompt的三大痛点：

可读性差。 所有信息揉在一起，阅读者需要自己分辨哪部分是角色设定、哪部分是任务说明、哪部分是格式要求。就像一本没有目录和章节的书，翻阅起来令人崩溃。

可维护性差。 当你想调整输出格式但不改变任务逻辑时，你需要在一大段文字中精准定位格式相关的描述，稍有不慎就会误改其他部分。

可复用性差。 如果你想把”生成产品周报”的prompt改造成”生成技术周报”，你需要逐句检查哪些部分需要替换、哪些可以保留——这本质上就是在”人肉重构”。

结构化的prompt用清晰的分区解决了这三个问题。每个区域职责单一，修改某个区域不会影响其他部分。

XML标签组织法

XML标签是组织prompt最直观的方式之一。用自定义标签将prompt分成不同的语义区块，每个区块的职责一目了然。

基础结构

<role>
你是一位资深产品经理，擅长将技术指标转化为业务语言。
你的沟通对象是公司高管层，所以表述需要简洁、数据驱动。
</role>

<context>
本周是Q1第8周。产品"智能客服系统"本周完成了2个功能迭代。
团队规模：前端3人、后端4人、测试2人。
</context>

<task>
根据提供的数据，生成本周的产品周报。
</task>

<requirements>
1. 每个功能用一段话描述业务价值，避免技术术语
2. 数据表现用表格展示，包含环比变化百分比
3. 风险项用红色标注（在markdown中用粗体替代）
4. 下周计划需要标注优先级（P0/P1/P2）
</requirements>

<output_format>
使用Markdown格式，包含以下章节：
## 本周功能上线
## 核心数据表现
## 风险与阻塞项
## 下周计划
</output_format>

<data>
功能1：智能工单分配
- 上线日期：周三
- 工单处理时效：从平均4.2小时降至2.8小时
- 用户满意度：从82%升至89%

功能2：多轮对话记忆
- 上线日期：周五
- 对话解决率：从71%升至78%
- 日均调用量：12,000次
</data>

这个结构的好处立刻可见：

想换一个角色风格？只改<role>
想调整输出格式？只改<output_format>
想复用这个模板处理下周的数据？只替换<data>
新同事接手？30秒就能理解整体结构

常用标签语义

标签	用途	说明
`<role>`	角色设定	AI应该扮演什么身份
`<context>`	背景信息	任务相关的背景知识和约束条件
`<task>`	核心任务	你到底要AI做什么
`<requirements>`	具体要求	质量标准、约束条件、注意事项
`<output_format>`	输出格式	期望的输出结构和样式
`<examples>`	示例	好的输出长什么样
`<data>` 或 `<input>`	输入数据	需要处理的原始材料
`<constraints>`	限制条件	不要做什么、边界在哪里

标签名称没有硬性规定，用你和团队觉得语义最清晰的名字即可。重要的是一致性——团队内统一标签命名规范。

Markdown结构化

如果你的工作流不涉及XML，用Markdown的标题、列表和代码块同样可以实现清晰的结构化。

# 角色
资深技术面试官，负责社招高级后端工程师的技术面评估。

# 背景
- 候选人简历显示5年Java经验，有分布式系统背景
- 目标岗位要求：高并发系统设计能力、微服务架构经验

# 任务
根据以下面试记录，生成技术面评估报告。

# 评估维度
1. **技术深度**：对核心技术的理解程度（权重30%）
2. **系统设计**：架构思维和权衡能力（权重30%）
3. **编码能力**：代码质量和问题解决思路（权重20%）
4. **沟通表达**：技术表达清晰度（权重20%）

# 输出格式
## 总体评价
一段话总结（2-3句）

## 各维度评分
表格，包含维度、分数（1-10）、简评

## 建议
录用/不录用/再面一轮，以及理由

# 面试记录
（在此粘贴面试记录内容）

XML和Markdown两种方式没有优劣之分。XML更适合需要程序解析的场景（比如prompt会被代码处理），Markdown更适合人工阅读和编辑的场景。

模板变量：让prompt可复用

当你的prompt需要反复使用、只是每次输入数据不同时，引入模板变量是最佳实践。

变量标记法

用双花括号 {{变量名}} 标记可替换的部分：

<role>
你是一位{{行业}}领域的{{角色}}。
</role>

<task>
请对{{公司名称}}的{{分析对象}}进行深度分析，重点关注以下维度：
{{分析维度列表}}
</task>

<constraints>
- 分析时间范围：{{起始日期}} 至 {{结束日期}}
- 数据来源仅限：{{数据来源}}
- 输出语言：{{语言}}
</constraints>

<data>
{{原始数据}}
</data>

使用时只需填入变量值：

变量	本次填入值
`{{行业}}`	新能源汽车
`{{角色}}`	市场分析师
`{{公司名称}}`	某新势力品牌
`{{分析对象}}`	2025年Q4季度财报
`{{分析维度列表}}`	营收增长、毛利率变化、交付量趋势、研发投入
`{{起始日期}}`	2025-10-01
`{{结束日期}}`	2025-12-31

这样的模板可以被团队中任何人使用——不需要理解prompt的设计意图，只需要按照变量清单填空。

进阶：带条件的模板

有些变量可以控制prompt的行为分支：

<task>
分析以下代码的质量。

{{#如果目标是代码审查}}
请重点检查：安全漏洞、性能隐患、代码规范违反。
对每个发现的问题，给出严重级别（高/中/低）和修复建议。
{{/如果}}

{{#如果目标是学习辅导}}
请逐段解释代码的功能和设计意图，指出值得学习的优秀写法，
同时温和地指出可以改进的地方。
{{/如果}}
</task>

这类条件模板在实际使用时可以根据场景选择不同的分支，一个模板覆盖多个用途。

实战：从零搭建一个结构化prompt

让我们用一个完整的实战案例来演练。任务是：构建一个”竞品功能对比分析”的prompt模板。

第1步：明确任务边界

先想清楚这个模板要解决什么问题：

输入：两个或多个竞品的功能列表
输出：一份结构化的对比分析报告
使用者：产品经理、产品运营

第2步：设计结构

<role>
你是一位有10年经验的产品策略顾问。你擅长通过功能对比发现产品的
差异化优势和潜在机会点。你的分析风格是数据驱动、观点鲜明、直指要害。
</role>

<context>
行业：{{行业}}
分析目的：{{分析目的}}
目标读者：{{目标读者}}
</context>

<task>
对以下竞品进行功能对比分析，产出一份可直接用于决策会议的分析报告。
</task>

<requirements>
1. 功能对比必须基于提供的事实，不要猜测未经证实的功能
2. 每个差异点需要评估其对用户体验的实际影响（高/中/低）
3. 结论部分必须给出明确的策略建议，而非模糊的方向性描述
4. 如果某个功能的信息不足以做出判断，明确标注"信息不足"
</requirements>

<output_format>
## 核心发现（3句话以内）

## 功能对比矩阵
| 功能维度 | {{产品A}} | {{产品B}} | 差异影响度 | 备注 |

## 差异化分析
按影响度从高到低排列，每个差异点包含：
- 差异描述
- 对用户的具体影响
- 我方应对建议

## 机会与威胁
- 机会点（对手弱、我们可以突破的）
- 威胁点（对手强、我们需要防守的）

## 行动建议
按优先级排序的具体行动项（不超过5条）
</output_format>

<examples>
以下是一个差异化分析的示例（仅展示格式，非实际数据）：

### 差异点：离线使用能力
- **差异描述**：产品A支持完整的离线模式，产品B仅支持查看缓存内容
- **用户影响**：高。目标用户中有35%在通勤场景使用（地铁信号差）
- **应对建议**：Q2前实现核心功能的离线支持，优先覆盖"内容浏览"和"笔记编辑"
</examples>

<data>
{{竞品功能数据}}
</data>

第3步：编写使用说明

一个好的模板应该附带简要的使用说明：

【模板使用说明】
1. 替换所有 {{}} 中的变量
2. <data> 部分建议使用表格或列表格式整理竞品功能数据
3. 如竞品超过2个，在 output_format 的表格中增加对应列
4. 首次使用后根据输出质量调整 <requirements> 中的约束条件

长上下文处理技巧

当你的prompt中包含大量背景材料（如一篇长文档、一份完整的代码库、一段会议记录），信息的摆放位置会显著影响AI的处理效果。

原则一：文档在前，问题在后

早期研究发现大语言模型对靠近末尾的内容有更强的注意力（即”Lost in the Middle”现象，参见 Liu et al., 2024: Lost in the Middle: How Language Models Use Long Contexts，该论文于 2023 年在 arXiv 发布，2024 年正式发表于 TACL）。因此一个常用的做法是把需要分析的原始材料放在prompt的前半部分，把你的问题和指令放在后半部分。需要注意的是，较新的模型（如 Claude 3+ 系列、GPT-4o 等）已经通过训练优化了对长上下文中间位置的处理能力，这一问题有所缓解，但”文档在前、问题在后”的组织方式作为良好的结构化习惯仍然值得遵循。

<document>
（此处放入需要分析的完整文档，可能长达数千字）
</document>

<task>
基于以上文档，请回答以下问题：
1. 文档中提到了哪些关键风险？
2. 作者的核心观点是什么？
3. 你是否发现了逻辑不一致的地方？
</task>

如果反过来——先提问题再放文档——AI在读到文档时可能已经”忘记”了具体要回答什么。

原则二：引用原文后再分析

当你需要AI对长文档做分析时，要求它先引用相关原文，再给出分析。这有两个好处：一是确保分析有据可查，二是减少AI”编造”内容的风险。

<task>
请分析以下合同中的风险条款。

对每个风险点：
1. 先引用合同中的原始条款文字（用引用块格式）
2. 然后解释为什么这个条款存在风险
3. 最后给出修改建议
</task>

<document>
（合同全文）
</document>

这样AI的每一个分析观点都能追溯到原文，你可以快速验证它有没有”断章取义”或”无中生有”。

原则三：分段标记便于定位

如果文档很长，给不同段落加上标记，方便AI在回答时精准引用：

<document>
[第1节：项目背景]
本项目启动于2025年3月，目标是...

[第2节：技术方案]
系统采用微服务架构，核心服务包括...

[第3节：风险评估]
项目面临以下主要风险...

[第4节：预算与排期]
总预算为...
</document>

<task>
请回答以下问题，并在回答中标注你引用了哪一节的内容。
</task>

Prompt版本管理

当prompt被频繁修改时，如果没有版本记录，你很快就会陷入”上次改了什么来着”的困境。像管理代码一样管理prompt，是团队协作的必备实践。

方法一：在prompt头部添加元信息

<!--
prompt_id: weekly-report-v3
author: 陈工
created: 2025-11-15
updated: 2026-02-20
changelog:
  v3 (2026-02-20): 增加风险项自动标注逻辑
  v2 (2026-01-10): 将数据表格格式从文字描述改为markdown表格
  v1 (2025-11-15): 初始版本
-->

方法二：用Git管理prompt文件

最专业的做法是把prompt文件纳入版本控制系统：

prompts/
  ├── weekly-report/
  │   ├── template.xml       # prompt模板
  │   ├── variables.json     # 变量默认值
  │   └── test-cases/        # 测试用例
  │       ├── case-01.json
  │       └── expected-01.md
  ├── code-review/
  │   ├── template.xml
  │   └── ...
  └── README.md              # 使用说明

每次修改都是一个commit，有完整的变更历史，可以随时回滚到之前的版本。

方法三：命名规范

对于不使用Git的场景（如在AI平台的prompt库中管理），命名规范就是你的版本控制：

[团队]-[用途]-[版本]-[日期]

示例：
product-weekly-report-v3-20260220
backend-code-review-v2-20260115
hr-interview-eval-v1-20251201

团队prompt协作的最佳实践

1. 建立模板库

把团队常用的prompt模板集中管理，每个模板包含：

模板文件（带变量标记）
使用说明（变量含义和填写规范）
示例输入和期望输出
维护人和更新日志

2. 统一结构规范

团队约定统一的结构标准，例如：

统一使用XML标签（或统一使用Markdown）
标签命名规范（<role>而不是<persona>或<character>）
变量命名用全小写下划线（{{company_name}}）
每个模板必须包含<role>、<task>、<output_format>三个核心区块

3. 评审机制

重要的prompt上线前做同行评审，检查：

是否有歧义表述（不同人读出不同含义）
是否缺少边界条件处理（“如果数据为空怎么办”）
是否可以被误用（输入非预期内容时是否会产出不当结果）
变量标记是否完整（有没有忘了标{{}}的部分）

4. 持续迭代

每周收集使用反馈，记录常见的失败case，定期更新模板。一个月不更新的prompt大概率已经落后于模型能力的进步了。

本章回顾

概念	说明	关键要点
XML标签结构化	用标签分隔prompt的不同语义区块	`<role>` `<task>` `<output_format>`等
Markdown结构化	用标题和列表组织prompt	适合人工阅读和编辑
模板变量	用`{{变量名}}`标记可替换部分	实现prompt复用
长上下文处理	文档在前、问题在后	引用原文后再分析
版本管理	像管理代码一样管理prompt	命名规范、变更记录、Git管理
团队协作	模板库 + 统一规范 + 评审机制	让prompt成为团队资产而非个人技巧

核心原则： 结构化不是增加复杂度，而是通过清晰的组织降低理解和维护的成本。一个好的prompt模板，应该让任何人在30秒内理解它的用途、在3分钟内上手使用。

思考题

拿出你最近使用过的一个prompt，用XML标签对它进行结构化重构。对比重构前后，AI的输出质量有变化吗？
为你所在团队的某个高频任务（如日报生成、代码审查、会议纪要整理）设计一个结构化prompt模板，包含至少3个模板变量。
思考一下：如果你的prompt需要处理一份50页的技术文档，你会怎样组织信息的摆放顺序？如果文档超出了模型的上下文长度限制，你会怎么处理？