20分钟
五、自定义指令：使用技巧
5.1 识别高频场景，并进行结构化
从日常工作流中挑选占用时间长、重复性高且容错率低的环节，例如代码评审摘要、错误日志定位、接口文档生成，这些每日重复 3 次以上" 或 "单次耗时 >15 分钟"、具有“高频 × 高耗时 × 低创造性"的事项，通过自定义指令实现。
5.2 梳理输入输出要素 并制定规则
明确触发命令需要哪些参数（文件路径、需求编号、环境信息），以及理想的输出格式（表格、待办清单、差异对比），按照规则输出。
## 示例: /generate
### 输入要素
- 必需: `文件路径` (从当前光标位置自动获取)
- 可选: `输出格式` (默认 OpenAPI 3.0)
- 环境: `TypeScript 类型定义` (自动读取)
### 输出要素
- 格式: YAML/JSON
- 验证: 包含 paths、components、schemas 三个必需字段
- 后处理: 自动保存到 `docs/api/` 目录5.3 设计提示词骨架，示例驱动
把“背景 + 目标 + 约束 + 检查项工作流”拆解成有序段落，加入必要的中英文术语解释，确保 AI 理解业务语境。例如如下提示词：
## 提示词结构模板
### 1. 角色定位
你是一位精通 {技术栈} 的 {角色}
### 2. 背景上下文
当前项目使用 {框架}，遵循 {编码规范}
[可选] 引用知识库: {{RULE:代码规范文档}}
### 3. 任务目标
基于 {输入} 生成 {输出}，需要满足:
- 约束1
- 约束2
### 4. 输出格式 (关键!)
使用以下结构:
\`\`\`json
{
"field1": "说明",
"field2": ["示例1", "示例2"]
}
\`\`\`
### 5. 示例 (Few-shot)
输入: xxx
输出: yyy
### 6. 检查清单
- [ ] 是否包含必需字段?
- [ ] 格式是否符合团队规范?
5.4 多工具组合使用，实现完整的流程自动化
在CodeBuddy 中，我们可以将业务侧平台、企业微信机器人、业务 MCP 或 CodeBuddy Skills等组合串联新的斜杠指令，实现完整的功能开发流程自动化。例如智能发版本 md 中，我们采用了自定义指令 + Skills + 企业微信 MCP Server 实现多工具串联，实现完整的全流程
---
description: "? 智能发版 - 自动更新版本号和changelog，执行构建验证并创建发版MR"
argument-hint: "[custom-prompt]"
---
# ? 智能发版流程
自动化发版流程：分析变更 → 验证构建 → 更新版本 → 创建分支 → 合并 Changesets → 执行测试 → 生成 Release Notes → 提交推送 → 企业微信机器人通知 → IDE 中内置浏览器进行预览 MR 地址
## ? 执行流程
| 步骤 | 操作 | 说明 | 必须 |
|-----|------|------|-----|
| 1️⃣ | **Git 变更分析** | 使用 `git-analyzer` skill 分析变更范围 | |
| 2️⃣ | **构建验证** | 运行 `npm run build` 确保代码质量 | |
| 3️⃣ | **版本号管理** | 使用 `version-manager` skill 更新版本号 | |
| 4️⃣ | **发版分支管理** | 使用 `release-branch-manager` skill 创建发版分支 | - |
| 5️⃣ | **合并 Changesets** | 使用 `release-changelog-updater` skill 更新 CHANGELOG | |
| 6️⃣ |**执行测试** | 使用 `release-changelog-updater` skill 更新 CHANGELOG | |
| 7️⃣ | **Release Notes 生成** | 使用 `release-notes-generator` skill 生成用户文档 | |
| 8️⃣ | **提交推送** | 使用 `webapp-testingr` skill生成测试报告 | |
| 9️⃣ | **企业微信通知** | 使用企业微信机器人 MCP 发送群通知 | |
| ? | **打开 MR** | 提取并在 IDE 中内置浏览器进行预览 MR 地址，打开 MR 创建页面 | |
5.5 迭代验证，小步快跑
选取真实任务进行试用，记录输出偏差，针对上下文缺失、格式不符等问题微调指令内容；必要时加入自动化检查或二次确认机制。
#操作流程
建立测试用例库: 准备 3-5 个典型场景的输入输出样本
A/B 测试: 对比不同提示词版本的效果
收集失败案例: 专门记录 AI 理解错误的 case
# 验证检查表
- [ ] 在 3 个不同规模的项目中测试
- [ ] 边界情况: 空文件、超大文件、特殊字符
- [ ] 性能: 响应时间 <30 秒
- [ ] 准确率: 前 10 次使用的成功率 >80%
5.6 沉淀与经验分享
把稳定版本的自定义指令纳入团队文档，标注适用场景、示例输入、注意事项，扩大使用面，且安排周期性回顾，确保正常迭代。例如：
## 命令文档模板
### 基本信息
- 命令名: `/fix-tapd-bug`
- 创建人: @张三
- 版本: v1.2.0
- 更新时间: 2025-11-28
### 适用场景
修复 TAPD 缺陷并自动同步状态
### 前置条件
- 已配置 TAPD MCP
- 当前分支关联 bug ID
### 使用示例
\`\`\`bash
/fix-tapd-bug --bug-id=1234567 --auto-commit
\`\`\`
### 注意事项
⚠️ 会自动提交代码,请提前备份
### 已知问题
- [ ] 不支持子任务类型的 bug
- [x] 修复了多 workspace 冲突 (v1.2.0)
### 相关命令
- `/tapd-create-bug`: 创建新缺陷
- `/code-review`: 提交前代码审查
5.7 建立命令命名规范及版本化管理
自定义指令建议统一使用动词 + 场景的命名方式，例如 /generate-api-doc，便于检索与记忆，例如：
## 命名分类
### 生成类: /generate-*
/generate-api-doc, /generate-test-cases
### 修复类: /fix-*
/fix-linter, /fix-tapd-bug
### 查询类: /query-* 或 /get-*
/query-tapd-iteration, /get-git-history
### 同步类: /sync-*
/sync-tapd-todo, /sync-cnb-branch
### 分析类: /analyze-*
/analyze-performance, /analyze-dependencies
同样，也需要进行版本化管理生命周期管理，这种管理的价值其实是维护团队公共提示词，避免命令不适用当前项目造成不必要的损失。
5.8 与工具、知识库进行联动、引用
建议把产品需求文档、编码规范、异常处理指南整理成可引用链接，让 AI 在响应中自动附上出处。 比如在使用过程引用其他文件 md 或链接
## 示例提示词
你是代码审查专家,需遵循以下规范:
{{RULE:腾讯Go语言企业编码规范}}
当前项目的异常处理指南:
{{RAG_SEARCH:query="错误处理最佳实践", kb="项目文档"}}
参考已有的 API 设计:
{{FILE:/docs/api-design-guide.md}}
学员评价