name: ctx-prompt-audit description: “审计提示模式。定期使用以帮助用户提升提示质量，减少澄清循环。”
分析最近的会话记录，识别导致不必要澄清来回的提示。
审计前准备
- 检查会话数据：在
.context/journal/目录中查找要分析的记录 - 至少需要3个会话：少于3个样本量太小；告知用户稍后再试
- 确认范围：如果用户指定了会话或日期范围，则使用该范围；否则默认使用最近的5个会话
使用时机
- 定期使用以帮助用户改进提示方式
- 当用户要求反馈其提示风格时
- 注意到最近会话中有多次澄清循环后
- 在经历了异常多来回的会话后
不应使用的时机
- 用户首次会话后立即（数据不足）
- 当用户感到沮丧时；在用户已经烦恼时进行指导效果不佳
- 未经请求；仅在用户调用或明确要求反馈时运行
使用示例
/ctx-prompt-audit
/ctx-prompt-audit --sessions 10
/ctx-prompt-audit 2026-01-24
数据来源
会话记录存储在日志中：
| 来源 | 格式 |
|---|---|
.context/journal/ |
导出的会话日志（更丰富） |
日志条目包含完整的逐轮对话，是模式检测的最佳来源。
处理流程
- 收集记录：从日志中读取3-5个最近的会话
- 提取用户提示：分离出用户发出的提示
- 识别模糊提示：标记那些导致澄清问题的提示（见以下标准）
- 交叉参考模式：寻找跨会话的重复习惯，而非一次性错误
- 生成指导报告：使用以下输出格式
- 呈现与讨论：分享报告，询问用户是否想深入探讨任何示例
什么使提示“模糊”
寻找那些导致助手询问澄清问题而非直接行动的提示：
- 缺少文件上下文：未指定哪个文件或错误就说“修复bug”
- 范围模糊：未说明优化什么或成功标准就说“优化它”
- 目标未定义：存在多个组件时说“更新组件”
- 缺少错误详情：只说“它不工作”而没有症状描述
- 模糊的行动词：“让它更好”、“清理这个”
重要细微差别
并非每个简短提示都是模糊的。考虑上下文：
- 在讨论特定错误后说“修复bug”：不模糊
- 作为第一条消息说“修复bug”：模糊
- 在模式建立后说“同上：”：不模糊（用户建立了惯例且高效）
- 引用共享上下文的简写是良好的提示，而非懒惰的提示
输出格式
## 提示审计报告
**分析的会话数**：5
**审查的用户提示数**：47
**发现的模糊提示数**：4 (8.5%)
---
### 示例1：缺少文件上下文
**您的提示**：“修复bug”
**发生了什么**：我不得不询问哪个文件和什么错误。
**更好的提示**：“修复src/auth/login.ts中的JWT验证失败导致401的身份验证错误”
---
## 需要注意的模式
根据您的会话，您倾向于：
1. 跳过提及文件路径（出现3次）
2. 在未明确“它”指代什么的情况下使用“它”（出现2次）
## 您做得好的地方
- 调试时提供错误输出（5个会话中有4个）
- 大多数提示中按路径引用特定文件
## 建议
- 讨论特定代码时，以**文件路径**开始提示
- 调试时包含**错误消息**
- 为优化任务指定**成功标准**
指导原则
- 建设性，非批判性：将建议框定为改进，而非纠正
- 展示实际提示：引用其会话中的内容，使示例具体而非假设
- 解释后果：提示模糊导致了什么（额外的来回、编辑了错误文件等）
- 提供改写：为每个示例展示具体的更好替代方案
- 肯定优点：包含“您做得好的地方”部分；纯粹批评时人们学习效果不佳
- 寻找模式：一个模糊提示是噪音；三个同类型提示是值得解决的习惯
- 以可操作建议结尾：3-5个具体、易记的建议
质量检查清单
呈现报告前，验证：
- [ ] 至少分析了3个会话（非极小样本）
- [ ] 每个“模糊”示例包含实际引用的提示
- [ ] 每个示例都有具体改写（不只是“更具体些”）
- [ ] 考虑了上下文（简短≠模糊）
- [ ] 报告包含积极观察，而不仅仅是批评
- [ ] 建议针对该用户的模式，而非通用建议