提示词模板

这些模板尽量保持工具无关，可以在 Agent 工具中按需调整文件引用、权限确认和输出格式。

快速提问

解释 <模块/文件/函数> 的作用和执行流程。

请重点说明：

- 输入从哪里来
- 中间经过哪些关键步骤
- 输出或副作用是什么
- 哪些地方容易出错

不要修改代码。

功能开发

目标：
在 <页面/模块> 中新增 <功能>。

背景：

- <为什么需要这个功能>
- <已有设计、接口、Issue 或用户反馈>

范围：

- 优先修改 <允许修改的目录或文件>
- 可以补充相关测试
- 不修改 <禁止修改的目录、接口或公共模块>

要求：

- <功能要求 1>
- <功能要求 2>
- 保持现有风格、状态管理和错误处理方式

验收标准：

- <可验证结果 1>
- <可验证结果 2>
- 相关 lint、测试或构建通过

输出：

- 修改内容
- 验证结果
- 未覆盖风险

Bug 修复

目标：
修复 <问题现象>。

已知信息：

- <复现步骤>
- <错误日志或截图>
- <最近相关改动>

要求：

- 先定位根因，再做最小范围修改
- 不改变无关行为
- 不通过删除断言、跳过测试或吞掉错误来规避问题
- 添加或更新回归测试

输出：

- 根因
- 修改内容
- 验证结果
- 仍需人工确认的风险

代码审查

审查 <分支/目录/文件/最近改动>。

重点检查：

- 逻辑错误和行为回归
- 权限、安全和数据泄露风险
- 错误处理和边界条件
- 类型、并发、缓存或状态一致性问题
- 测试覆盖不足

要求：

- 不直接修改代码
- 按严重程度输出问题
- 每个问题说明影响、位置、原因和建议
- 没有发现问题时明确说明剩余风险

重构

目标：
重构 <模块/文件> 中的 <重复逻辑/复杂逻辑/历史包袱>。

边界：

- 不改变用户可见行为
- 不修改公共 API 契约
- 保持现有兼容性要求
- 优先沿用项目已有模式

请先给出简短方案和风险点，再实施修改。

完成后输出：

- 重构思路
- 修改内容
- 验证结果
- 可能需要继续观察的地方

调研与方案

调研 <问题/方案/技术选型>。

请覆盖：

- 当前项目现状
- 可选方案
- 各方案的优缺点和适用条件
- 推荐方案及原因
- 实施步骤和风险

要求：

- 先不要修改代码
- 区分事实、推断和建议
- 如需要外部信息，说明来源和时效性

文档改写

重写 <文档/章节>，让它更清晰、更通用。

要求：

- 不强绑定某个具体工具或平台
- 可以举例，但例子不能替代原则
- 先讲概念，再讲适用场景、使用方式和边界
- 保持现有文档站的语气和 Markdown 风格
- 删除重复、过时或容易误导的描述

翻译与命名

角色：专业 IT 翻译和代码命名助手。严格遵守以下规则：

1. 只输出最终结果，不要输出解释、开场白或结尾。
2. 如果输入是中文技术描述，请提供自然、地道的英文表达。
3. 如果输入明显用于变量、函数或字段命名，请优先输出 `camelCase`，并给出 1-2 个备选。
4. 如果输入是英文，请翻译成流畅中文；API、Hook、Component、SDK 等常见技术词可保留英文。
5. 如果输入是代码片段，只翻译注释和用户可见文案，不改变代码逻辑。