提示词优化

解决什么问题

当任务逻辑复杂、步骤繁多时，模型常因提示词结构松散而出现输出漂移：要么步骤遗漏、要么格式混乱，甚至直接生成无关内容。尤其在 Agent 开发、数据分析、归因分析等需要高准确率与可复现性的场景中，随意编写的提示词往往无法稳定约束模型行为——输入稍变就输出格式崩塌，或模型自行「脑补」未定义的步骤。

如何工作

本技能通过 六段式框架 将提示词拆解为可度量、可迭代的结构单元，核心逻辑如下：

• 角色与任务（置顶）：用一句话明确「你是谁」（如 你是测试失败分析助手）与「要做什么」（如 定位失败步骤并输出结构化原因），将模型能力收束到专业域。
• 核心原则（≤3 条）：提取任务中反复出错的约束（如「禁止在 JSON 外附加解释」），作为纲领性规则，避免长提示词中的关键要求被忽略。
• 上下文处理：长上下文（如 RAG 结果、工作流上游数据）必须放在提示词末尾，并明确标注其结构与作用（如 以下是接口日志，用于定位请求异常），避免打断主指令逻辑。
• CoT / 执行步骤：对逻辑强、步骤多的任务，显式写出「第一步做什么、第二步做什么」，复杂规则用 伪代码 描述（如 if status == "failed": 记录错误码），实践中可提升约 20% 准确率。
• 输出规范：必须包含 期望（如 返回 JSON，字段包含 status, steps, suggestions）与 禁止（如 禁止输出自然语言解释），结构化输出前先写清字段结构。
• Few-Shot（可选）：当通用规则能覆盖 60-70% 场景时，少量添加示例，且示例中的名词需模糊化（如 某商品 而非 iPhone 15），步骤与 CoT 完全一致，避免过拟合。

关键步骤

1. 定义成功标准：明确输入、输出形式（如「输出必须是 JSON，含 5 个字段」）与验收条件。
2. 准备评测集：收集 3-5 组输入与期望输出，标注易错点（如「超长日志需截断前 1000 字」），用于自动化评测。
3. 生成初版：用「目标 + 输入/输出说明 + 框架」让模型生成提示词初稿，优先跑通「提示词 + 评测集 + 自动化测试」闭环。
4. AI 辅助调优：每次提供「当前提示词 + 输入 + 实际输出 + 问题描述」，由模型生成修改建议，循环迭代。

适用边界与注意点

• 禁止滥用 Few-Shot：示例过多会增加 token 消耗、提高过拟合风险，且可能导致模型死记硬背示例中的名词（如将 iPhone 15 误认为通用规则）。
• 上下文必须精简：冗余信息（如重复日志、无关数据）易导致模型注意力错位，能在代码中先筛选的（如过滤 DEBUG 日志），先处理再交给模型。
• 版本管理：每次修改前保存当前版提示词，当采纳率达 70% 后，可结合 ReAct、RAG 等技术提升上限，而非继续堆砌规则。
• 伪代码优于自然语言：当规则涉及条件分支、时间逻辑（如 若状态码为 404 且时间在 10 分钟内），用伪代码描述比自然语言更易被模型理解。
• 不适用场景：简单任务（如单轮问答、格式转换）无需严格遵循六段式，按需增删模块即可；超短任务强行套用框架反而会增加 token 消耗。