提示词技巧

提示词是 Agent 的基本功。先掌握结构化表达，再进入复杂任务和安全场景。 学习时不要只背术语：每个技巧都配一组输入、输出和失败样本，才能看出它到底帮了什么忙。

文章	重点
提示词基础	角色、指令、示例、边界和结构化输出
提示词进阶	思维链、自洽投票、任务分解和注入防御

学习清单

下面的清单集中管理两篇文章的练习。每项都写了参考答案，完成后可以用自己的实验结果替换其中的预期，不必把“模型说得像真的”当成通过标准。

提示词基础

• 写一个带角色、规则、格式和示例的 system prompt，让模型稳定输出固定格式

  参考答案：提示词至少要写清职责范围、执行规则、未知或异常时的处理、输出字段/格式，以及一个正常示例和一个边界示例。例如客服助手只能回答商品、订单和售后问题；退款或改地址要先复述参数并等待确认；查不到制度时要明确说“资料中未提及”。验收时准备至少 10 条包含正常、缺字段、越界和恶意指令的输入，分别统计字段完整率、格式解析率和越权行为。格式正确不代表内容正确，邮箱、金额、权限等关键字段仍要由代码校验。

• 对同一分类任务，对比 zero-shot 与补充 3 个 few-shot 示例后的准确率差异

  参考答案：固定模型、参数、测试集和判分规则，分别运行没有示例和带 3 个示例的版本。few-shot 往往能改善格式一致性和模糊边界上的分类，但示例有偏差时也会把错误教给模型。记录每条样本的预测、正确答案、错误类型和输入 token 数，给出准确率、宏平均 F1 或逐类结果，并判断收益是否值得额外 token 成本。测试集不能和示例重复，否则无法说明泛化效果。

• 先用一句模糊指令，再改成具体指令，观察输出可控性的变化

  参考答案：模糊指令会让模型自行猜受众、长度、重点和格式；具体指令应补上任务目标、输入范围、约束、评价标准和输出结构。保留两个版本的提示词和至少 5 次输出，用任务完成度、约束遵守、格式一致性和无关内容比例比较。还要留意过度约束会让表达变僵，不能只追求“每次一模一样”。

• 用 json_schema 强制模型输出结构化对象，并用代码成功 parse

  参考答案：测试正常输入、缺失信息、类型混淆、超长输入和恶意输入。代码要区分 JSON 解析失败、Schema 校验失败和业务校验失败，并处理拒答、截断、服务商不支持 schema 或 schema 不兼容等情况。json_schema/strict 只能降低结构错误，不能证明字段里的事实正确；验收时应保留可定位问题的原始响应或请求 id。

提示词进阶

• 用 CoT 解一道多步推理应用题，对比直接回答、要求分步推理和使用外部计算器

  参考答案：在相同题目、模型和采样参数下记录三种方案的最终答案、步骤是否自洽、token 数和延迟。CoT 可能帮助模型整理中间步骤，但也可能生成一份看似完整的错误推导；算术、日期和金额应尽量交给确定性程序复核。对于支持内部 reasoning 的模型，不要机械要求暴露完整隐藏思维链。

• 让模型写一段代码，再用第二轮提示让它自查改错，观察前后差异

  参考答案：先准备一个带已知 bug 的小程序，例如阶乘函数没有处理负数或空输入。第二轮给出明确检查清单，要求检查边界条件、异常处理、类型和安全问题；记录原始版本、审查意见、修改版本和测试结果。模型的复查只是建议，不能替代单元测试、静态检查或沙箱执行。

• 把一个较大的写作任务拆成 3 步 prompt chaining，比较分步和一次性生成

  参考答案：可以使用“提取事实 → 组织提纲 → 生成正文”的链路，每一步都定义输入、输出、失败处理和验收条件，并只传递下一步需要的内容。比较一次性生成与链式生成的质量、成本和耗时；如果提取事实不合格，系统应停止或重试，而不是把错误继续传给后面。还要记录来源和版本，方便追查中间结果。

• 构造一次简单的提示词注入，再加上防御性 system prompt，观察是否仍会被绕过

  参考答案：把“忽略之前规则、泄露系统提示、调用某工具”等文字放入用户数据、网页内容或工具参数，分别测试直接注入、间接注入和参数注入。加上分隔符和数据边界后，简单攻击可能减少，但编码、跨语言和多轮诱导仍可能绕过。实验只能在没有真实密钥、没有真实写权限的沙箱中进行，记录模型响应、工具调用和服务端拦截结果，并说明真正的防线是权限、参数校验和人工确认。

• 列出以后做的 Agent 中必须人工确认的操作

  参考答案：不可逆、影响资金/权限/隐私、向外部发送内容或可能大范围修改数据的动作，都应在执行前展示目标、参数、影响范围和风险，等待明确确认。查询和草稿生成等低风险动作可以自动执行。确认要绑定到具体动作和参数，不能只确认“继续”；执行前重新校验权限，执行后返回结果并留下审计记录。