Agent 跑偏是日常。本文是我反复调教 Agent 的提示词工程笔记。

反模式：让 Agent 自己"理解需求"

❌ "优化下这个文件的代码"

Agent 会按它认为的"优化"动手——可能改架构、可能换库、可能加注释。完全失控。

✅ "这个文件第 50-80 行是循环嵌套，重构成单次扫描。不要改函数签名，不要加注释。"

具体到行号、到约束、到禁止项。

反模式：奖励"努力"而非"结果"

❌ "详细分析一下这个 bug"

Agent 输出 500 字分析，然后说"建议进一步排查"，然后停了。

✅ "修复这个 bug，给我可运行的代码。如果定位不到根因，列出 3 个最可能的原因和验证方法。"

明确产出物：要么 fix，要么决策清单。

Pattern 1：用"角色 + 任务 + 约束 + 产出"四件套

你是 Linux 性能优化专家。
任务：分析下面的 perf 数据，找出 CPU 热点。
约束：
- 不要建议加机器
- 不要建议换语言
- 只看代码层面的优化
产出：
- 列 3 个最热的函数
- 每个函数给具体优化方法
- 预计性能提升幅度

Pattern 2：让 Agent 先回放需求

我要让你做 X。
**在动手前，用一句话总结你即将做的事，等我确认 OK 再执行。**

强制 Agent 把它理解的需求说出来，你能在它跑歪前抓住。

Pattern 3：给"反例"

只给正例 Agent 会过拟合。加反例：

任务：写一个 Bash 脚本备份 MySQL。

正例风格（参考）：
- 用 set -euo pipefail
- 每步都 echo 进度
- 失败要 exit 非 0

反例（不要这样）：
- 不要用 mysqldump > /backup/$(date)，因为 date 没引号会出空格
- 不要用 sleep 然后 polling，用 wait 或者 trap
- 不要 silent fail

Pattern 4：长任务用 checkpoint

这个任务有 5 步。
每完成一步，输出：
✓ Step N: <做了什么>，<关键产出>
然后等 30 秒（用 sleep 30）让我有机会打断。

让 Agent 在每个 checkpoint 停一下，你能控制进度。

Pattern 5：给"Agent 工作日志"模板

解决问题时，按这个格式输出：
- 假设：我认为问题是 ...
- 验证：跑这个命令 ...
- 观察：看到 ...
- 结论：所以 ...
- 行动：因此我会 ...

如果观察推翻假设，重新出一组。

把 Agent 的内部推理外化，方便你审查。

Pattern 6：禁止开放性结尾

❌ "任务完成。如有问题随时告诉我。"（Agent 默认这种结尾）

✅ 在提示词里加：

完成后不要写"如有问题告诉我"或"需要可以继续"。
只输出：
- 改了什么文件
- 验证命令
- 失败的边界场景

Pattern 7：用 example 引导

任务：写一个 K8s YAML 部署 redis。

参考这个 nginx 部署的格式：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 3
  ...

注意：
- labels 风格要一致
- replicas 默认 3
- 资源 requests/limits 必填

给一个完整 example 比写 10 条约束更有效。

最后

Prompt engineering 不是玄学，本质是让 Agent 的不确定性 → 你的确定性。每一句话都在缩小可能的输出空间。

教训：好提示词 = 角色明确 + 任务具体 + 约束清晰 + 产出可验证 + 反例兜底。

标签: none

添加新评论