#实战案例

三个短练习，覆盖「改合同」「给程序吃」「给 Agent 当宪法」。可以贴进任何聊天框；有 API 时把 system / user 按注释拆开。

#案例 1：一句含糊提示，三种合法改写

原话（不要直接用）：

帮我看看这个函数。

假设函数是下单路径上的 parse_order。三种读者、三种合同——不要合成「既详细又只要一句话」的怪物。

改写 A — 代码评审（给作者）

角色：后端评审，读者是作者。
任务：只评 parse_order。列出正确性 / 失败处理 / 复杂度问题。
约束：不改代码；没有证据的条目标「猜测」；最多 6 条。
输出：Markdown 表格，列：严重度（high/medium/low）、位置、问题、建议。

改写 B — 给新人讲解

角色：导师。读者刚加入组，会 Python，不熟业务。
任务：用一段话说明 parse_order 的输入、输出、失败时谁负责。
约束：不要讲语言语法基础；不要引入文档里没有的服务名。
输出：三段：做什么、怎么失败、下一步该读哪个文件（给路径）。

改写 C — 只要风险清单（给工单系统）

任务：抽取 parse_order 的可操作风险。
约束：每条必须能改成一个工单标题；不要风格意见。
输出：JSON 数组，项为 {"title": str, "severity": "high"|"medium"|"low"}。不要 JSON 以外的文字。

把 A/B/C 各当一条金标题的「提示词版本」。同函数、不同合同，输出不可互换——这是评估要锁住的行为。

#案例 2：从邮件抽取 JSON

system：

你抽取支持工单。不要编造订单号或负责人。
priority 只能是 low、medium、high（出现「今天」「生产挂了」才可 high）。

user：

从 <email> 抽出 Ticket。schema：
title, priority, order_id (string|null), owner (string|null)

<email>
嗨，订单 8891 结账一直转圈。今早生产也有人报。让平台组看一下。——Lina
</email>

期望（示例）：

{
  "title": "Checkout spinner on order 8891",
  "priority": "high",
  "order_id": "8891",
  "owner": "平台组"
}

接 API 时用 结构化输出 的 Pydantic 类，而不是事后用正则抠。再加一条金标题：邮件里 没有 订单号，order_id 必须是 null。

#案例 3：仓库级 Agent 指令

放到仓库根 AGENTS.md（或 Cursor 规则、Claude Code CLAUDE.md、LangChain system_prompt）。用户每次只说任务，不重复政策。

# Agent 指令（本仓库）

你是这个教程站点的编程助手。先读再改。

## 范围
- 文档在 `docs/zh/` 与 `docs/en/`；改中文必须同步英文，除非用户只要一边。
- 不要改 `node_modules/`、构建产物、密钥文件。

## 工具
- 需要核对页面时再开浏览器；不要拿训练记忆代替仓库里的现稿。
- 终端用 PowerShell 7；不要假设 bash。
- 不要 `git push`、不要改 git config，除非用户明说。

## 质量
- 跟随邻近 Markdown 的标题与表格风格。
- 不确定的 API 以官方文档为准；不要编造未出现的 CLI 旗标。

## 结束时
用子弹列出：改了哪些路径、如何本地预览、仍未做的事。

这是 工具与 Agent 的落地。接到 Cursor、Claude Code、LangChain 时，只换容器，不换四个构件。

#练习

1. 把你最近一条失败的聊天记录，按案例 1 拆成 A/B 两种合同，跑同一段输入。
2. 为案例 2 补三条金标题（缺字段、注入噪声、语言混用）。
3. 给你正在做的仓库写一页不超过 40 行的 AGENTS.md，删掉所有无法验收的形容词。

#下一步

• 资源与延伸阅读
• Cursor 规则 · Dify Agent · LangChain 快速上手