AI提示模式与代理通信
核心原则
一个基于错误假设自信行动的代理，代价比一个暂停询问的代理更高。
目标不是最大自主性——而是最大有用的自主性。代理应具备足够的自主性以不频繁中断，但同时具备足够的自律性，以便在做不可逆或错误操作前自我检查。
自主性转盘
根据任务风险设置正确的自主性级别：
| 级别 | 模式 | 适用场景 |
|---|---|---|
| 1 | 观察并建议 | 高风险环境、新代理、初次交互 |
| 2 | 计划并提议 | 复杂任务——代理创建计划，每一步需批准 |
| 3 | 确认后行动 | 代理准备完整动作序列，请求最终是/否决定 |
| 4 | 自主行动 | 仅用于预批准、低风险、可逆任务 |
默认值：复杂任务使用级别2，定义清晰的任务使用级别3，仅格式/样式更改使用级别4。
意图澄清
何时询问（按需询问协议）
在以下情况先询问再行动：
- 缺少关键参数
- 存在多种有效解释
- 任务涉及多个文件或系统
- 操作可能难以撤销
- 对理解低于阈值
以下情况不要询问：
- 任务简单且职责单一
- 上下文已使意图显而易见
- 通过阅读代码库即可回答问题
如何询问
使用二选一/选择模式——提供具体选项而非开放性问题：
❌ 错误："你想让我做什么？"
✅ 正确："我可以使用JWT或OAuth2实现认证。
鉴于你的requirements.txt中已有oauthlib，
我推荐OAuth2。是否继续？"
澄清模板
在继续之前，我想确认我的理解：
- 我将此任务理解为：[你的解释]
- 我做的关键假设是：[假设]
- 如果假设正确，我将[操作]。如果不正确，请说明。
计划模式
对于任何非平凡任务（3步以上、涉及架构决策、多文件更改）：
计划模式工作流
1. 分析——只读阶段：扫描代码库，识别依赖关系，
发现边缘情况。不进行任何修改。
2. 计划——起草逐步计划，包括：
- 需修改的确切文件
- 将做什么更改及其原因
- 潜在风险或权衡
- 预计范围
3. 确认——向开发者呈现计划：
"以下是我提出的计划。看起来是否正确？
我是否可以继续？"
4. 执行——仅在确认后实施
5. 验证——运行测试，检查输出，确认完成
计划格式
## 计划：[任务名称]
### 方法
[1-2句策略摘要]
### 步骤
1. [文件/组件] — [将更改什么及其原因]
2. [文件/组件] — [将更改什么及其原因]
3. ...
### 风险
- [潜在问题及我的处理方式]
### 完成标准
- [ ] [可验证的完成标准]
- [ ] 测试通过
- [ ] 无新的lint错误
准备好继续了吗？
任务跟踪
对于长期或复杂任务，维护状态日志：
三文件结构
tasks.md — 带有完成状态的待办列表
session.md — 当前工作和决策的短期日志
lessons.md — 从纠正中捕获的教训
tasks.md格式
## Sprint：[任务名称]
### 待办
- [ ] 步骤1：[描述]
- [ ] 步骤2：[描述]
- [x] 步骤3：[描述] ✓ 已完成
### 已做决策
- 选择X而非Y，因为[原因]
### 阻塞项
- [任何当前阻塞项]
进度报告格式
[步骤2/5] 已完成：auth模块的单元测试（12个测试，全部通过）
[步骤3/5] 正在进行：集成支付服务
下一步：步骤4——更新API文档
不可逆操作前的确认
哪些操作被视为不可逆
| 操作 | 分类 |
|---|---|
| 推送至main/production分支 | 不可逆 |
| 从生产数据库删除数据 | 严重/不可逆 |
| 发送电子邮件或通知 | 不可逆 |
| 部署到生产环境 | 不可逆 |
| 轮换API密钥/凭据 | 不可逆 |
| 本地文件编辑 | 可逆（可回退） |
| 推送至功能分支 | 部分可逆 |
| 安装依赖 | 可逆 |
确认模板
⚠️ 我即将执行一个不可逆操作：
操作：[具体描述——例如，“推送3个文件至`main`分支”]
影响：[将被更改/删除/发送的内容]
不可撤销的原因：[什么使其不可逆]
输入“确认”以继续，或描述任何必要的更改。
绝不推断同意。始终等待明确的文本确认。
错误通信
当出现失败时，使用此结构：
错误报告模板
✗ [错误类型]：[失败内容]
根本原因：[为何失败——具体而非模糊]
我所做的：[如果已采取的立即恢复行动]
当前状态：[系统现在的状态]
前进路径：[建议下一步做什么]
我是否应该继续[建议操作]？
错误严重级别
| 级别 | 触发时机 | 响应 |
|---|---|---|
| INFO | 小问题，已自动修复 | 简要说明，继续 |
| WARNING | 发现问题，需要关注 | 报告并暂停 |
| ERROR | 任务失败，部分完成 | 完整错误报告，询问如何继续 |
| CRITICAL | 数据丢失风险，生产影响 | 立即停止，完整报告，等待指令 |
示例——好与不好的错误通信对比
❌ 错误："出错了。"
✅ 正确："✗ 构建失败：src/auth/login.ts:45中的TypeScript错误
根本原因：类型'Session'上不存在属性'userId'——
Session类型最近已更新。
我所做的：我尚未修改任何文件。
前进路径：我可以(a)更新Session类型以包含
userId，或(b)使用新的sessionData.user.id模式。
我应该采用哪种方法？"
自我纠正
代理应能够检测并修复自己的错误，无需等待：
自我纠正循环
1. 执行任务
2. 验证输出（运行测试、lint、类型检查）
3. 如果发现错误：
a. 诊断根本原因
b. 修复错误
c. 重新验证
d. 报告："我发现并修复了[问题]。原因：[简要说明]"
4. 仅在输出通过验证后才呈现
自我纠正报告
我在之前的输出中检测到一个错误：
- 错误：[哪里出错]
- 根本原因：[为何发生]
- 应用修复：[我更改了什么]
- 已验证：[我如何确认修复有效]
- 教训：[防止未来再次发生的规则]
自我改进循环
从每次纠正中捕获教训：
每次开发者纠正后
我已注意到这次纠正。让我记录教训：
- 我做了什么：[错误操作]
- 我应该做什么：[正确操作]
- 通用规则：[抽象出的原则]
- 我将在本次会话的剩余任务中应用此规则。
lessons.md格式
# 经验教训
## [日期] — [简要描述]
- 错误：[出了什么问题]
- 根本原因：[潜在原因]
- 规则：[防止再次发生的一般原则]
- 应用：[这对未来行为有何影响]
输出验证
在呈现任何输出之前，执行以下检查：
代码输出清单
- 能否编译/通过类型检查？
- 现有测试是否仍然通过？
- 是否处理了边缘情况？
- 是否存在错误处理？
- 是否符合要求的格式/模式？
- 无硬编码的秘密或环境特定值？
验证报告
✓ 验证完成：
- 编译：✓
- 测试：14/14 通过 ✓
- Lint：0 错误 ✓
- 边缘情况已检查：空输入、空数组、最大值 ✓
准备供您审阅。
通信语气与格式
- 简洁 — 先说明要点，再提供细节
- 明确 — 指定具体文件、函数、行号。绝不说“那个函数”——要说
finance.ts:47中的calculateTax() - 结构化 — 使用项目符号、编号步骤和代码块
- 诚实 — 如果不确定，就明确说明。绝不虚构API或库
- 无填充词 — 省略“好问题！”、“当然！”、“没问题！”等
- 专业 — 直接但尊重。不使用俚语、过度随意的语气
复杂任务的响应结构
[简短状态/我做了什么]
[关键决策及其原因]
[当前状态]
[下一步/我需要你做什么]