提示词优化

基于「角色 → 核心原则 → 上下文 → CoT/步骤 → 输出规范 → Few-Shot」六段式框架，适用于复杂任务、高准确率场景与 Agent 开发。

六段式结构（推荐顺序）

按需增删模块，顺序建议保持：

角色/任务 → 核心原则 → 上下文说明 → CoT/执行步骤 → 输出规范 → Few-Shot（可选）

1. 角色 / 任务（置顶）

• 角色：限定能力域（如「你是数据分析师」「你是测试失败分析助手」），从“杂学家”收束到专业场景。
• 任务：一句话说清要干什么（如：根据测试报告定位失败步骤并输出结构化原因）。
• 原则：角色 + 任务共同约束「用哪方面能力、做哪一件具体事」。

2. 核心原则（≤3 条）

• 执行任务时必须遵守的最高原则，纲领性质。
• 不超过 3 条，过多容易失效。
• 可将调优中反复出问题的约束提升为核心原则。

3. 上下文处理

• 位置：上下文较长时尽量放在提示词末尾，避免打断主指令。
• 必须写清：上下文的结构与组织形式；上下文在任务中的作用与价值。
• 来源：多轮记忆、RAG、工作流上游、知识库等。

4. CoT / 执行步骤（思维链）

• 适用：逻辑强、步骤多的任务（多步计算、归因、分步分析）。
• 做法：显式写出「第一步做什么、第二步做什么…」，约束按步骤思考与执行（实践中可带来约 20% 准确率提升）。
• 复杂逻辑：自然语言难精确表达时，用伪代码描述（时间规则、条件分支等），模型理解更快更准。

5. 输出规范

• 必要性：明确约束，避免多输出思考过程或无关内容。
• 建议包含：
• 期望：输出的内容与结构（格式、字段、语言等）；
• 禁止：不允许出现的内容或格式（如禁止在 JSON 外附带解释）。
• 结构化输出（如 JSON）前，先在提示词里把「结构」写清楚。

6. Few-Shot（可选）

• 对复杂或边界 case 有效；示例须与 CoT/执行步骤一致。
• 会增加过拟合与 token 消耗，使用策略见下方「调优原则」。

格式与表达

• 推荐格式：Markdown，结构清晰、易扩展；超长 JSON 慎用。
• 复杂逻辑：优先用伪代码替代大段自然语言。

优化前必做

1. 定义成功标准：要完成什么？什么样算符合预期？需要哪些输入？期望输出形式与内容？
2. 准备评测用例集：输入 + 期望输出 + 备注（可测量、可复现）；越早越好。
3. 快速得到第一版：用「目标 + 输入/输出说明 + 期望的提示词框架」让模型生成初版；优先跑通「提示词 + 评测集 + 自动化评测」闭环。

调优流程与原则

1. 用 AI 辅助优化：每次提供「当前系统提示词」「输入」「实际输出」「存在问题/优化目标」，由模型给出修改建议，多轮迭代。
2. 精简输入：只提供最小必要信息；冗余易导致分析不全、幻觉、注意力错位。能在代码里先筛选的，先筛再交给模型。
3. Few-Shot 使用：
• 起步建议 0 Few-Shot，先用清晰逻辑让模型理解规则。
• 当通用提示词已能应对大部分 case（如 60–70%）时，再少量增加示例。
• 示例中尽量模糊具体名词（如「某商品」「某 ID」），避免死记硬背；示例步骤与 CoT 完全一致。
4. 保持精炼：上下文与示例过长会增加 token、拖慢响应、提高过拟合风险；效果达标前提下持续精简。
5. 版本与回滚：每次改前保存当前版；采纳率到约 70% 后，可结合 ReAct、RAG、多 Agent 或「N 次取最佳」等提升上限。

检查清单（优化/评审时使用）

结构

• [ ] 角色 + 任务在最前且一句话说清
• [ ] 核心原则 ≤3 条且为纲领级
• [ ] 长上下文置于末尾并说明结构与作用
• [ ] 多步任务有显式 CoT/步骤或伪代码
• [ ] 输出规范含「期望」与「禁止」
• [ ] Few-Shot 若存在则与 CoT 一致且名词已模糊

质量

• [ ] 成功标准与评测集已定义
• [ ] 输入已精简为最小必要信息
• [ ] 格式为 Markdown，复杂逻辑用伪代码
• [ ] 有版本保存便于回滚

使用本 skill 时的输出建议

• 分析现有提示词：按六段式逐段对照，指出缺失或冗余，并给出具体修改建议。
• 从零起草：先确认成功标准与输入/输出，再按六段式生成初版，并提醒配置评测与回滚。
• 调优迭代：基于「当前提示词 + 输入 + 实际输出 + 问题/目标」给出下一版修改稿，并标注改动理由。

更多示例

• 完整六段式示例与 Few-Shot 用法见 examples.md。