第四章：上下文结构设计

系统提示词、用户提示词、助手回复——这三者怎么组织？说白了，就是给AI搭一个清晰的对话框架。我刚开始做提示词工程时，经常把角色设定和场景描述混在一起写，结果AI要么跑偏，要么前后矛盾。后来我琢磨出一套方法，今天跟你聊聊。

4.1 三层结构的核心逻辑

我个人习惯把上下文分成三层：

• 系统提示词（System Prompt）：定义AI的底层身份和行为规则
• 用户提示词（User Prompt）：当前任务的具体输入
• 助手回复（Assistant Response）：AI的输出格式和风格约束

这三层各司其职，不能混为一谈。我在项目中遇到过有人把「你是一个Python专家」写在用户提示词里，结果AI每次都要重新理解身份，效率低得吓人。

4.2 系统提示词：定调子

系统提示词是AI的「人设」。你想想看，如果每次对话都要重新介绍自己，多累？所以这部分要写死。

我一般这样写：

你是一名资深Python工程师，精通异步编程和性能优化。
你的回答必须：
1. 优先给出代码示例
2. 解释关键设计决策
3. 指出潜在的性能陷阱

嗯，这里要注意：系统提示词不要写具体任务。比如「帮我写一个爬虫」这种话，应该放到用户提示词里。

4.3 用户提示词：给任务

用户提示词是每次对话的「输入」。这部分要具体、清晰，最好带上上下文。

举个例子：

我需要一个异步爬虫，抓取某电商网站的商品价格。
要求：
- 使用aiohttp
- 处理反爬机制
- 输出CSV格式

我曾经犯过一个错：把任务描述得模棱两可，结果AI给我写了三个不同版本的代码，每个都不对。后来我学乖了，每次都给明确的输入输出格式。

4.4 助手回复：定输出

助手回复这部分，很多人忽略。其实它决定了AI的输出风格。我习惯在系统提示词里定义好回复模板：

你的回复格式：
## 方案概述
（一句话说明）
## 代码实现
（完整代码，带注释）
## 注意事项
（3-5个关键点）

这样做的好处是，AI的输出结构稳定，方便后续解析。我在做自动化工具时，就靠这个模板把AI输出直接转成文档。

4.5 角色与场景分离

这是我最想强调的一点。很多人把角色和场景混在一起写，比如：

你是一个电商客服，现在用户投诉商品质量问题。

这样写的问题在于，角色和场景绑死了。下次换个场景，又得重新定义角色。我建议分开：

• 角色定义：你是一名电商客服专家，擅长处理售后纠纷。
• 场景描述：用户投诉商品有质量问题，要求退款。

分开之后，角色可以复用，场景可以灵活切换。我在项目中遇到过需要同时处理客服、销售、技术支持三个角色的情况，用这种分离方式，代码复用率提高了40%。

4.6 结构化组织的表格化示例

为了让你更清楚，我整理了一个对比表：

层级	内容	示例
系统提示词	角色定义+行为规则	你是一名Python专家，回答要带代码示例
用户提示词	具体任务+输入数据	写一个爬虫，抓取某网站数据
助手回复	输出格式+风格约束	用Markdown格式，先给方案再给代码

这个表格我每次做项目都会贴出来，提醒自己别搞混。

4.7 常见错误与修正

我总结了几种常见错误，你对照看看：

• 角色重复定义：系统提示词和用户提示词都写「你是专家」——删掉用户提示词里的重复内容。
• 场景混入角色：把具体任务写进系统提示词——移到用户提示词里。
• 输出格式不明确：AI自由发挥——在系统提示词里定义模板。

我曾经在一个项目里，因为没注意这些细节，导致AI输出格式乱七八糟，最后花了三天时间手动整理。嗯，从那以后我再也不敢偷懒了。

4.8 小结

上下文结构设计，说白了就是给AI搭一个清晰的对话框架。系统提示词定调子，用户提示词给任务，助手回复定输出。角色和场景一定要分开，这样复用性才高。你想想看，如果每次都要重新定义角色，那跟从头开始有什么区别？

下一章我会讲如何管理长对话的上下文窗口，到时候再聊。