字数
2081 字
阅读时间
9 分钟
参考：
一、通用型Prompt工程框架：PEEL框架（Purpose-Explicit-Example-Limit）
适用于绝大多数基础任务（如生成、分析、改写等），核心是通过四要素分层明确指令边界。
框架结构：
Purpose（任务目标）
- 用1-2句话精准定义核心任务，包含“动作+对象+预期结果”三要素。
- 例：“动作（总结）+ 对象（2024年全球AI芯片市场报告）+ 预期结果（提炼3个关键趋势及对应的头部企业动态）”。
Explicit Context（显性上下文）
- 补充任务依赖的前提信息：时间范围、领域限定、背景知识、用户身份（如“作为新能源行业分析师”）等。
- 例：“背景：该报告数据来源为IDC和Gartner，需排除未公开的初创企业数据；用户身份：面向非技术背景的企业决策者，避免专业术语”。
Example（示例引导）
- 对格式/风格/逻辑有要求时，提供1个正向示例（Few-Shot）或反例（Negative Example）。
- 例：“输出格式示例：
趋势1：[趋势名称]- 核心表现：[1句话概括]
- 头部企业：[企业A]（动作：[具体行为]）、[企业B]（动作：[具体行为]）”。
Limit（约束条件）
- 限定输出的量化指标（长度、结构）、禁忌规则（如“禁止推测未提及的数据”）、优先级（如“优先突出与2023年相比的变化”）。
- 例：“总字数≤500字，每个趋势用项目符号列出，禁止使用‘可能’‘或许’等模糊表述”。
优势：
- 要素全面且分层清晰，适合新手快速上手；
- 可根据任务复杂度删减要素（如简单任务可省略Example）。
二、复杂推理任务框架：CoT+Decompose（思维链+任务拆解）
针对逻辑推理、问题诊断、多步骤决策等复杂任务，核心是引导模型“显式思考”并拆分问题。
框架结构：
Problem Decomposition（任务拆解）
- 将复杂问题拆分为3-5个递进的子问题，明确子问题之间的逻辑关系（如因果、并列、步骤）。
- 例：问题“如何降低电商APP的用户退货率？”
拆解为：
① 分析退货率高的3类核心原因（产品、物流、用户认知）；
② 针对每类原因，列举2个具体场景（如“产品原因：尺寸不符、质量与描述差异”）；
③ 对每个场景，提出可落地的解决方案（含执行主体和指标）。
Chain-of-Thought Trigger（思维链触发）
- 用指令引导模型输出中间推理过程，而非直接给结论。
- 例：“请先分析每个子问题的推理逻辑（如‘为什么尺寸不符会导致退货？因为用户依赖商品详情页的尺寸表，若表中数据误差＞2cm，试穿后大概率退货’），再汇总结论”。
Verification Rule（验证规则）
- 设定推理有效性的判断标准，避免模型跳过关键逻辑。
- 例：“每个解决方案需满足：① 与对应原因直接相关；② 可通过A/B测试验证效果；③ 成本≤每月5万元”。
优势：
- 强制模型暴露推理路径，便于定位逻辑漏洞；
- 降低模型因“跳跃性思考”导致的错误（尤其对数学题、故障诊断等任务）。
三、内容生成类框架：TASP框架（Target-Audience-Style-Purpose）
针对文案创作、故事生成、观点输出等内容类任务，核心是对齐“受众需求”与“内容风格”。
框架结构：
Target（核心主题）
- 明确内容的核心对象和关键信息，避免偏离主题。
- 例：“主题：介绍家用扫地机器人的‘自动集尘’功能；关键信息：集尘容量（3L）、清理周期（30天）、适用人群（养宠家庭）”。
Audience（目标受众）
- 定义受众特征（年龄、身份、痛点、知识水平），针对性调整表述。
- 例：“受众：30-40岁职场妈妈，痛点是‘没时间频繁倒垃圾’‘宠物毛发清理麻烦’，对技术参数不敏感，注重‘省心’‘高效’”。
Style（风格与调性）
- 限定语言风格（如口语化/专业严谨/幽默俏皮）、修辞要求（如比喻、排比）、情感倾向（如亲切、权威）。
- 例：“风格：口语化，像朋友推荐一样；用1个养宠场景的比喻（如‘像给机器人装了个“零食罐”，毛发灰尘自己“吃”进去，一个月不用管’）”。
Purpose（内容目的）
- 明确内容要达成的效果（如“让受众理解功能价值”“激发购买欲”“消除使用顾虑”）。
- 例：“目的：突出‘自动集尘’相比传统扫地机的‘省时’‘卫生’优势，消除用户对‘清理麻烦’的顾虑”。
优势：
- 内容生成更贴合实际场景需求，避免“自说自话”；
- 可复用性强，换主题/受众后仅需替换对应要素。
四、专业领域框架：Domain-Specific Prompt（领域适配框架）
针对法律、医疗、代码开发等专业领域，需结合领域特性补充“专业约束”和“格式规范”。以代码开发为例：
框架结构（Code Prompt）：
Function Definition（功能定义）
- 明确代码要实现的具体功能，包含输入输出、核心逻辑。
- 例：“功能：用Python写一个批量处理Excel文件的脚本；输入：多个含‘姓名、成绩’列的Excel文件（路径：./data/）；输出：合并后的Excel（路径：./result.xlsx），并新增‘平均分’列（保留2位小数）”。
Technical Constraints（技术约束）
- 限定工具库（如“使用pandas而非openpyxl”）、性能要求（如“处理1000行数据耗时≤5秒”）、兼容性（如“支持Python 3.8+”）。
Explanation Requirement（解释要求）
- 要求代码附带关键步骤注释，或单独输出“逻辑说明”（便于非开发者理解）。
- 例：“每段核心逻辑需加注释，最后用3句话说明脚本的执行流程（从读取文件到输出结果）”。
Error Handling（异常处理）
- 强制考虑边界情况（如“文件不存在”“列名缺失”），要求代码包含异常捕获逻辑。
- 例：“若某文件缺少‘成绩’列，需跳过该文件并在控制台打印警告：‘文件[文件名]格式错误，已跳过’”。
五、框架设计的通用原则（跨框架适用）
- 要素模块化：每个框架的要素应可独立调整（如PEEL中的Example可根据任务复杂度增删），避免“一刀切”。
- 模型适配性：根据模型特性调整框架细节（如GPT-4支持更长上下文，可增加子问题数量；而小模型可能需要更精简的指令）。
- 迭代反馈机制：框架需预留“优化入口”，例如在输出后添加“若不符合预期，请指出：①目标未达成 ②格式错误 ③信息缺失”，便于二次调整。
贡献者
jiechen