prompt-engineering

name	prompt-engineering
description	当你在编写或优化系统提示词、定义 Agent 的身份/规则/工作流程时使用；当 Agent 行为不稳定、规则执行不一致、频繁违反业务规则时使用。不适用于上下文布局与缓存优化（见 context-engineering），也不适用于工具接口描述（见 tool-design）。

提示词工程（Prompt Engineering）

角色与读者

面向 Agent 开发者和产品经理。本 Skill 服务的目标：把 Agent 的"员工手册"写到——一个聪明的新员工读完就知道该怎么做。核心哲学：LLM 的优势是遵循复杂指令、从长上下文提取信息，不应在业务规则制定上被赋予过多自由裁量权。

核心原则（配正例/反例）

1. 流程驱动，而非规则堆砌

   • 给 SOP（标准操作流程）：清晰的分步流程，让模型任何时刻都知道自己处于哪个阶段、当前目标、下一步、异常如何处理。
   • 反例：上百条零散规则无流程图无优先级——多条规则冲突、未覆盖情况模型就懵，消融实验中信息组织混乱导致成功率下降 30%+。
   • 正例：Step 1: Validation → Step 2: Classification → Step 3: Preprocessing → Step 4: Execution → Step 5: Verification，每步有分支（"If not found → log error and stop"）。

2. 业务规则细化到可执行（产品经理参与，工程师不擅自决定业务逻辑）

   • 模糊规则（"根据任务选计费类型"）会导致行为极不稳定。必须把决策规则写死到可执行粒度。
   • 正例：NEVER use percentage-based for refunds and service cancellations. Use fixed_fee instead.
   • 反例："退款算省钱吗？取消订阅算省钱吗？"——同一任务不同时间得到不同分类，业务不可预测。

3. 结构化提示：XML 负责精确语义，Markdown 负责组织逻辑

   • 标签名携带语义：<working_directory> 立即告诉模型这是工作目录。
   • 双层结构：XML 做机器可解析的精确语义边界，Markdown 做人机共读的组织层次。

4. Few-shot 示例：只在"规则难描述、示例易表达"时用，且固定位置

   • 2-3 个覆盖边界的高质量示例，胜过等量篇幅抽象规则，也胜过 10 个大同小异的示例。
   • 示例放系统提示词（对所有请求生效）或伪造 user/assistant 消息放首轮（按会话类型选示例集），一旦确定保持字节级稳定。
   • 反例：按请求动态检索"最相关"示例 = 每次改写前缀 = 缓存持续失效。

5. 关键约束用大写强调，但保留给真正关键的

   • "NEVER do X" 比 "Please avoid" 更能引起注意；过度使用会稀释效果。

执行流程（SOP 检查清单）

1. 明确 Agent 身份、权限边界、行为准则（"你是谁、能做什么、不能做什么"）。
2. 把任务流程写成 SOP（分步 + 分支 + 终止条件），而非罗列规则。
3. 让产品经理把业务规则细化到可执行（决策条件、阈值、计费规则都写死）。
4. 为"难用规则描述"的环节（特定风格、报告格式、语气分寸）配 2-3 个高质量 few-shot 示例。
5. 用 XML 包裹结构化字段，用 Markdown 组织层次。
6. 写完后用"新员工测试"检验：读完还不知道怎么做，Agent 也一样。

禁止清单（写清合法例外）

• 禁止让模型在业务规则制定上有过多自由裁量权（"你自己看着办"）。例外：真正需要模型判断的开放式部分（如何把合规方案表达得自然）才放开。
• 禁止按请求动态检索示例。例外：为每类任务准备固定示例集（而非逐请求挑选）。
• 禁止堆砌无优先级、无流程的零散规则。例外：简单单步任务可以只给简洁指令。
• 禁止过度使用大写/强调词。例外：保留给一两个真正不可违反的约束（如安全红线）。
• 禁止把提示词当知识库硬塞大量事实（大量事实用 RAG 或 Mid-training 承载）。例外：少量随示范学入参数可接受。

参考资料

• 本书第 2.4 节《提示工程：优化系统提示词》（语气风格、结构化、流程驱动、业务规则细化、few-shot、工具定义、提示注入）。
• 宝玉《别再用提示词去 AI 味了，方向就是错的》（Skill 写作方法）。
• 笔记 02-上下文工程.md 第 2.4 节。