📝 docs(prompts): refresh prompt templates
This commit is contained in:
parent
6774a9d4aa
commit
2554c879e4
|
|
@ -29,8 +29,8 @@
|
|||
### 工作流程
|
||||
|
||||
- [docs/prompts/coding/clarify.md](docs/prompts/coding/clarify.md) - 需求澄清
|
||||
- [docs/prompts/coding/verify.md](docs/prompts/coding/verify.md) - 验证检查
|
||||
- [docs/prompts/system/agent-behavior.md](docs/prompts/system/agent-behavior.md) - AI 行为规范
|
||||
- [docs/prompts/coding/review.md](docs/prompts/coding/review.md) - 复盘总结
|
||||
- [docs/prompts/system/agent-behavior.md](docs/prompts/system/agent-behavior.md) - 工作模式参考
|
||||
<!-- playbook:templates:end -->
|
||||
|
||||
<!-- playbook:framework:end -->
|
||||
|
|
|
|||
|
|
@ -1,41 +1,47 @@
|
|||
# 提示词库
|
||||
|
||||
本目录包含 AI 代理的工作流程模板和参考文档。
|
||||
本目录包含 AI 代理的工作流程参考模板。
|
||||
|
||||
## 目录结构
|
||||
|
||||
```text
|
||||
prompts/
|
||||
├── README.md # 本文件
|
||||
├── system/ # 系统级规范
|
||||
│ └── agent-behavior.md
|
||||
├── coding/ # 编码流程
|
||||
│ ├── clarify.md # 需求澄清模板
|
||||
│ └── verify.md # 验证检查清单
|
||||
└── user/ # 用户快捷命令
|
||||
└── quick-test.md # 快速测试命令
|
||||
├── README.md # 本文件
|
||||
├── system/
|
||||
│ └── agent-behavior.md # 工作模式参考
|
||||
├── coding/
|
||||
│ ├── clarify.md # 需求澄清模板
|
||||
│ └── review.md # 复盘总结模板
|
||||
└── meta/
|
||||
└── prompt-generator.md # 元提示词生成器
|
||||
```
|
||||
|
||||
## 使用方式
|
||||
|
||||
### AI 代理
|
||||
| 模板 | 触发场景 |
|
||||
| ----------------------- | ------------------------------ |
|
||||
| **agent-behavior.md** | 切换工作模式（探索/开发/调试） |
|
||||
| **clarify.md** | 需求不明确时澄清 |
|
||||
| **review.md** | Plan 完成后复盘总结 |
|
||||
| **prompt-generator.md** | 创建新的专用提示词 |
|
||||
|
||||
- 新会话时读取 `system/agent-behavior.md`
|
||||
- 需要澄清需求时参考 `coding/clarify.md`
|
||||
- 完成任务前检查 `coding/verify.md`
|
||||
## 工作流程
|
||||
|
||||
### 用户
|
||||
```
|
||||
需求不清 → clarify.md
|
||||
↓
|
||||
头脑风暴 → $brainstorming skill
|
||||
↓
|
||||
生成计划 → $writing-plans skill → docs/plans/*.md
|
||||
↓
|
||||
执行计划 → AGENT_RULES 主循环（留痕）
|
||||
↓
|
||||
完成复盘 → review.md
|
||||
↓
|
||||
沉淀提示词 → prompt-generator.md（可选）
|
||||
```
|
||||
|
||||
- 使用 `user/quick-test.md` 中的命令快速执行测试
|
||||
|
||||
## 文档说明
|
||||
|
||||
| 文件 | 用途 |
|
||||
| -------------------------- | ------------------------------- |
|
||||
| `system/agent-behavior.md` | AI 行为规范、工作模式、禁止行为 |
|
||||
| `coding/clarify.md` | 需求澄清步骤和问题模板 |
|
||||
| `coding/verify.md` | 代码、测试、文档验证清单 |
|
||||
| `user/quick-test.md` | 常用测试命令参考 |
|
||||
> **核心规则在 `AGENT_RULES.md`**，第三方 skills 负责规划，主循环负责执行和留痕。
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,10 @@
|
|||
# 需求澄清模板
|
||||
|
||||
<!--
|
||||
按需使用：当需求不明确或存在歧义时参考本模板。
|
||||
Vibe-coding 场景下可跳过，直接开始实现。
|
||||
-->
|
||||
|
||||
## 何时使用
|
||||
|
||||
- 需求描述不明确
|
||||
|
|
@ -10,119 +15,37 @@
|
|||
|
||||
## 澄清步骤
|
||||
|
||||
### 1. 理解当前需求
|
||||
|
||||
**复述需求**：
|
||||
### 1. 复述需求
|
||||
|
||||
```text
|
||||
我理解你的需求是：[用自己的话复述]
|
||||
```
|
||||
|
||||
**识别歧义点**：
|
||||
### 2. 识别歧义
|
||||
|
||||
- 歧义 1：[描述不明确的地方]
|
||||
- 歧义 2：[可能有多种理解的地方]
|
||||
|
||||
---
|
||||
|
||||
### 2. 提出澄清问题
|
||||
|
||||
**问题模板**：
|
||||
### 3. 提出问题
|
||||
|
||||
> 只问阻塞问题，最多 1–2 个；优先给出选项让用户选择。
|
||||
|
||||
#### 功能范围
|
||||
|
||||
- 这个功能是否包括 [场景 A]？
|
||||
- 是否需要支持 [边界情况 B]？
|
||||
- 优先级如何？必须有 vs 可选
|
||||
|
||||
#### 行为细节
|
||||
|
||||
- 当 [条件 X] 时，应该 [行为 Y] 还是 [行为 Z]？
|
||||
- 如果 [异常情况]，如何处理？
|
||||
- 是否需要与 [现有功能] 保持一致？
|
||||
|
||||
#### 技术约束
|
||||
|
||||
- 是否有性能要求？
|
||||
- 是否有兼容性要求？
|
||||
- 是否有安全要求？
|
||||
|
||||
---
|
||||
|
||||
### 3. 提供选项
|
||||
|
||||
**选项格式**：
|
||||
### 4. 提供选项
|
||||
|
||||
**选项 A**：[方案描述]
|
||||
|
||||
- 优点：[列出优点]
|
||||
- 缺点：[列出缺点]
|
||||
- 适用场景：[什么情况下选这个]
|
||||
- 优点：...
|
||||
- 缺点：...
|
||||
|
||||
**选项 B**：[方案描述]
|
||||
|
||||
- 优点：[列出优点]
|
||||
- 缺点：[列出缺点]
|
||||
- 适用场景：[什么情况下选这个]
|
||||
- 优点：...
|
||||
- 缺点：...
|
||||
|
||||
**推荐**：[推荐哪个选项，为什么]
|
||||
|
||||
---
|
||||
|
||||
### 4. 确认理解
|
||||
|
||||
**确认清单**：
|
||||
|
||||
- [ ] 功能范围明确
|
||||
- [ ] 行为细节清晰
|
||||
- [ ] 技术约束已知
|
||||
- [ ] 优先级确定
|
||||
- [ ] 验收标准明确
|
||||
|
||||
---
|
||||
|
||||
## 示例
|
||||
|
||||
### 需求
|
||||
|
||||
```text
|
||||
实现 XXX 功能
|
||||
```
|
||||
|
||||
### 澄清过程
|
||||
|
||||
**复述需求**：
|
||||
|
||||
```text
|
||||
我理解你的需求是：为 YYY 添加 XXX 功能，
|
||||
用于 ZZZ。
|
||||
```
|
||||
|
||||
**识别歧义点**：
|
||||
|
||||
- 歧义 1：XXX 是只读还是可写？
|
||||
- 歧义 2：是否需要支持所有场景？
|
||||
|
||||
**澄清问题**：
|
||||
|
||||
- 是否需要支持 [场景 A]？
|
||||
- 当 [条件 X] 时，应该如何处理？
|
||||
|
||||
**提供选项**：
|
||||
|
||||
**选项 A**：完整实现
|
||||
|
||||
- 优点：功能完整
|
||||
- 缺点：开发周期长
|
||||
|
||||
**选项 B**：核心功能
|
||||
|
||||
- 优点：快速交付
|
||||
- 缺点：功能有限
|
||||
|
||||
**推荐**：选项 A，因为 [原因]。
|
||||
**推荐**：[推荐哪个，为什么]
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,66 @@
|
|||
# 复盘模板
|
||||
|
||||
<!--
|
||||
用途：Plan 或阶段完成后的回顾总结
|
||||
触发：主循环汇总报告时、阶段性工作完成时
|
||||
-->
|
||||
|
||||
## 何时使用
|
||||
|
||||
- 一批 Plan 执行完毕后
|
||||
- 阶段性工作告一段落
|
||||
- 遇到重大阻塞需要总结
|
||||
|
||||
---
|
||||
|
||||
## 复盘格式
|
||||
|
||||
```markdown
|
||||
# 复盘: [日期/阶段名称]
|
||||
|
||||
## 完成情况
|
||||
|
||||
### 已完成
|
||||
- [x] Plan 1: 简述
|
||||
- [x] Plan 2: 简述
|
||||
|
||||
### 阻塞
|
||||
- [ ] Plan 3: 阻塞原因
|
||||
|
||||
### 跳过
|
||||
- [ ] Plan 4: 跳过原因
|
||||
|
||||
## 关键发现
|
||||
|
||||
### 做得好的
|
||||
- 发现1
|
||||
- 发现2
|
||||
|
||||
### 待改进
|
||||
- 问题1 → 建议改进方式
|
||||
- 问题2 → 建议改进方式
|
||||
|
||||
## 决策记录
|
||||
|
||||
| 决策 | 理由 | 影响 |
|
||||
|------|------|------|
|
||||
| 决策1 | 为什么 | 影响范围 |
|
||||
|
||||
## 下一步
|
||||
|
||||
- [ ] 待处理事项1
|
||||
- [ ] 待处理事项2
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 复盘原则
|
||||
|
||||
- **客观记录**：如实记录完成/阻塞/跳过
|
||||
- **提取经验**：总结做得好的和待改进的
|
||||
- **决策留痕**：重要决策记录到 decisions.md
|
||||
- **明确下一步**：列出后续待处理事项
|
||||
|
||||
---
|
||||
|
||||
**最后更新**：{{DATE}}
|
||||
|
|
@ -1,93 +0,0 @@
|
|||
# 验证检查清单
|
||||
|
||||
## 代码修改验证
|
||||
|
||||
### 语法检查
|
||||
|
||||
- [ ] 代码可正常运行（无语法错误）
|
||||
- [ ] 无未定义的变量或函数
|
||||
- [ ] 依赖引用正确
|
||||
|
||||
### 风格检查
|
||||
|
||||
- [ ] 命名符合规范
|
||||
- [ ] 缩进正确
|
||||
- [ ] 换行符正确（遵循 .gitattributes）
|
||||
- [ ] 无冗余注释
|
||||
|
||||
---
|
||||
|
||||
## 测试验证
|
||||
|
||||
### 单元测试
|
||||
|
||||
- [ ] 相关测试脚本存在
|
||||
- [ ] 测试可正常运行
|
||||
- [ ] 测试通过（无失败）
|
||||
|
||||
### 回归测试
|
||||
|
||||
- [ ] 现有测试仍然通过
|
||||
- [ ] 未破坏其他功能
|
||||
|
||||
---
|
||||
|
||||
## 文档验证
|
||||
|
||||
### 代码文档
|
||||
|
||||
- [ ] 复杂逻辑有注释说明
|
||||
- [ ] 公开 API 有使用示例（如需）
|
||||
|
||||
### 项目文档
|
||||
|
||||
- [ ] `memory-bank/progress.md` 已更新
|
||||
- [ ] 重要决策记录到 `memory-bank/decisions.md`
|
||||
|
||||
---
|
||||
|
||||
## Git 验证
|
||||
|
||||
### 提交前检查
|
||||
|
||||
- [ ] 只包含相关修改（无无关文件）
|
||||
- [ ] 提交信息清晰
|
||||
- [ ] 无临时文件或调试代码
|
||||
|
||||
### 分支检查
|
||||
|
||||
- [ ] 在正确的分支上工作
|
||||
|
||||
---
|
||||
|
||||
## 性能验证（如果涉及）
|
||||
|
||||
### 性能测试
|
||||
|
||||
- [ ] 处理时间可接受
|
||||
- [ ] 内存使用正常
|
||||
- [ ] 无明显性能退化
|
||||
|
||||
---
|
||||
|
||||
## 安全验证（如果涉及）
|
||||
|
||||
### 安全检查
|
||||
|
||||
- [ ] 无注入风险
|
||||
- [ ] 敏感信息已脱敏
|
||||
|
||||
---
|
||||
|
||||
## 快速检查清单（最小集）
|
||||
|
||||
**每次修改必须检查**：
|
||||
|
||||
- [ ] 代码可运行（无语法错误）
|
||||
- [ ] 相关测试通过
|
||||
- [ ] 换行符正确
|
||||
- [ ] `memory-bank/progress.md` 已更新
|
||||
|
||||
---
|
||||
|
||||
**最后更新**：{{DATE}}
|
||||
|
|
@ -0,0 +1,126 @@
|
|||
# 提示词生成器（元提示词）
|
||||
|
||||
<!--
|
||||
用途：根据场景自动生成专用提示词
|
||||
原理：α-prompts（生成）+ Ω-prompts（优化）递归循环
|
||||
-->
|
||||
|
||||
## 何时使用
|
||||
|
||||
- 需要为新场景创建专用提示词
|
||||
- 现有提示词不满足特定需求
|
||||
- 需要批量生成同类提示词
|
||||
|
||||
---
|
||||
|
||||
## 生成流程（α循环）
|
||||
|
||||
### 1. 分析场景
|
||||
|
||||
```markdown
|
||||
**场景名称**：[名称]
|
||||
**目标用户**：[AI/人类/两者]
|
||||
**触发条件**：[何时使用这个提示词]
|
||||
**预期输出**：[使用后应该产出什么]
|
||||
```
|
||||
|
||||
### 2. 提取约束
|
||||
|
||||
```markdown
|
||||
**必须做**：
|
||||
- 约束1
|
||||
- 约束2
|
||||
|
||||
**禁止做**：
|
||||
- 禁止1
|
||||
- 禁止2
|
||||
|
||||
**边界条件**：
|
||||
- 边界1
|
||||
- 边界2
|
||||
```
|
||||
|
||||
### 3. 生成草稿
|
||||
|
||||
```markdown
|
||||
# [提示词标题]
|
||||
|
||||
<!--
|
||||
用途：[一句话描述]
|
||||
触发：[触发条件]
|
||||
-->
|
||||
|
||||
## 何时使用
|
||||
|
||||
- 场景1
|
||||
- 场景2
|
||||
|
||||
## [核心内容]
|
||||
|
||||
[根据场景填充]
|
||||
|
||||
## [约束/原则]
|
||||
|
||||
- 约束1
|
||||
- 约束2
|
||||
|
||||
---
|
||||
|
||||
**最后更新**：{{DATE}}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 优化流程（Ω循环）
|
||||
|
||||
### 1. 评估维度
|
||||
|
||||
| 维度 | 问题 |
|
||||
| ---------- | ---------------------- |
|
||||
| **清晰度** | 指令是否明确无歧义？ |
|
||||
| **完整度** | 是否覆盖所有必要场景？ |
|
||||
| **简洁度** | 是否有冗余内容可删除？ |
|
||||
| **可操作** | AI 能否直接执行？ |
|
||||
|
||||
### 2. 迭代优化
|
||||
|
||||
```
|
||||
草稿 → 评估 → 修改 → 再评估 → ... → 定稿
|
||||
```
|
||||
|
||||
### 3. 验证测试
|
||||
|
||||
- 用实际场景测试提示词效果
|
||||
- 收集反馈，持续迭代
|
||||
|
||||
---
|
||||
|
||||
## 提示词模板库
|
||||
|
||||
### 标准结构
|
||||
|
||||
```markdown
|
||||
# [标题]
|
||||
|
||||
<!--
|
||||
用途：
|
||||
触发：
|
||||
-->
|
||||
|
||||
## 何时使用
|
||||
## [核心内容]
|
||||
## [约束/原则]
|
||||
|
||||
---
|
||||
|
||||
**最后更新**：{{DATE}}
|
||||
```
|
||||
|
||||
### 命名规范
|
||||
|
||||
- 文件名：`[动词]-[对象].template.md`
|
||||
- 示例：`clarify-requirement.template.md`
|
||||
|
||||
---
|
||||
|
||||
**最后更新**：{{DATE}}
|
||||
|
|
@ -1,18 +1,19 @@
|
|||
# AI 代理行为规范
|
||||
# 工作模式参考
|
||||
|
||||
## 工作模式
|
||||
<!--
|
||||
本文件定义三种工作模式，供 AI 根据任务类型选择。
|
||||
核心规则（安全红线、验证清单等）见 AGENT_RULES.md。
|
||||
-->
|
||||
|
||||
### 模式 1: 探索模式（Explore）
|
||||
## 模式 1: 探索模式（Explore）
|
||||
|
||||
**目的**：理解代码库、分析问题、收集信息
|
||||
|
||||
**行为规范**：
|
||||
**行为**：
|
||||
|
||||
- 使用搜索工具探索代码
|
||||
- 输出分析报告和发现
|
||||
- 提出问题和建议
|
||||
- 不修改任何代码
|
||||
- 不运行测试（除非明确要求）
|
||||
|
||||
**适用场景**：
|
||||
|
||||
|
|
@ -22,18 +23,15 @@
|
|||
|
||||
---
|
||||
|
||||
### 模式 2: 开发模式（Develop）
|
||||
## 模式 2: 开发模式（Develop）
|
||||
|
||||
**目的**：实现功能、修复 bug、重构代码
|
||||
|
||||
**行为规范**：
|
||||
**行为**：
|
||||
|
||||
- 先读取相关文件，理解现有逻辑
|
||||
- 进行精确修改
|
||||
- 修改后运行对应测试验证
|
||||
- 更新 `memory-bank/progress.md`
|
||||
- 不读文件就提议修改
|
||||
- 不跳过测试直接提交
|
||||
- 修改后运行测试验证
|
||||
|
||||
**适用场景**：
|
||||
|
||||
|
|
@ -43,16 +41,15 @@
|
|||
|
||||
---
|
||||
|
||||
### 模式 3: 调试模式（Debug）
|
||||
## 模式 3: 调试模式（Debug）
|
||||
|
||||
**目的**：诊断问题、对比差异、验证行为
|
||||
|
||||
**行为规范**：
|
||||
**行为**：
|
||||
|
||||
- 收集相关日志和输出
|
||||
- 分析差异原因
|
||||
- 记录待确认事项并在回复中提出，或直接修复
|
||||
- 重新验证
|
||||
- 修复后重新验证
|
||||
|
||||
**适用场景**：
|
||||
|
||||
|
|
@ -62,135 +59,4 @@
|
|||
|
||||
---
|
||||
|
||||
## 代码风格要求
|
||||
|
||||
### 通用规范
|
||||
|
||||
**命名规范**：
|
||||
|
||||
- 遵循项目现有的命名风格
|
||||
- 保持一致性
|
||||
|
||||
**缩进**：
|
||||
|
||||
- 遵循项目现有的缩进风格
|
||||
|
||||
**换行**：
|
||||
|
||||
- 遵循 `.gitattributes` 规则
|
||||
|
||||
**注释**：
|
||||
|
||||
- 只在逻辑不自明时添加注释
|
||||
- 不添加冗余注释
|
||||
|
||||
---
|
||||
|
||||
## 禁止行为清单
|
||||
|
||||
### 代码修改
|
||||
|
||||
- **不读文件就提议修改**
|
||||
|
||||
- 必须先读取文件
|
||||
- 理解现有逻辑后再提出修改建议
|
||||
|
||||
- **破坏现有架构**
|
||||
|
||||
- 不随意移动目录结构
|
||||
- 不随意重构核心模块
|
||||
|
||||
- **随意改动换行符**
|
||||
- 遵循 `.gitattributes` 规则
|
||||
- 不混用 LF 和 CRLF
|
||||
|
||||
### 测试流程
|
||||
|
||||
- **跳过测试直接提交**
|
||||
- 修改后必须运行相关测试
|
||||
- 测试失败必须分析原因
|
||||
|
||||
### Git 操作
|
||||
|
||||
- **使用 `git commit --amend`**
|
||||
|
||||
- 除非用户明确要求
|
||||
- 总是创建新提交
|
||||
|
||||
- **使用 `git push --force`**
|
||||
|
||||
- 特别是推送到 main/master 分支
|
||||
- 如果用户要求，必须警告风险
|
||||
|
||||
- **跳过 hooks**
|
||||
- 不使用 `--no-verify`
|
||||
|
||||
### 过度工程
|
||||
|
||||
- **添加未要求的功能**
|
||||
|
||||
- 只做用户要求的修改
|
||||
- 不主动重构周边代码
|
||||
|
||||
- **添加不必要的注释**
|
||||
|
||||
- 不给自明的代码添加注释
|
||||
|
||||
- **过度抽象**
|
||||
- 不为一次性操作创建工具函数
|
||||
- 不为假设的未来需求设计
|
||||
|
||||
---
|
||||
|
||||
## 决策原则
|
||||
|
||||
### 何时需要确认
|
||||
|
||||
**必须确认**：
|
||||
|
||||
- 需求有歧义，存在多种理解
|
||||
- 有多个技术方案，需要权衡
|
||||
- 可能破坏兼容性
|
||||
- 涉及架构变更
|
||||
|
||||
**可以不确认**：
|
||||
|
||||
- 明显的 bug 修复
|
||||
- 符合现有模式的小改动
|
||||
- 测试用例补充
|
||||
|
||||
### 何时记录到 decisions.md
|
||||
|
||||
**必须记录**（ADR 格式）：
|
||||
|
||||
- 影响多个模块的架构决策
|
||||
- 技术栈选择
|
||||
- 设计模式选择
|
||||
- 重要的约束条件
|
||||
|
||||
---
|
||||
|
||||
## 沟通原则
|
||||
|
||||
### 输出风格
|
||||
|
||||
- 简洁明确，避免冗长
|
||||
- 使用纯文本结构化输出，必要时用 Markdown 代码块
|
||||
- 代码块标注语言
|
||||
- 不使用 emoji（除非用户明确要求）
|
||||
- 不使用过度的赞美或验证
|
||||
|
||||
### 技术准确性
|
||||
|
||||
- 优先技术准确性，而非迎合用户
|
||||
- 发现用户理解有误时，礼貌纠正
|
||||
- 不确定时，先调查再回答
|
||||
|
||||
### 时间估算
|
||||
|
||||
- 不给出时间估算
|
||||
- 专注于任务本身，让用户自己判断时间
|
||||
|
||||
---
|
||||
|
||||
**最后更新**：{{DATE}}
|
||||
|
|
|
|||
Loading…
Reference in New Issue