Claude Code 提示词模板库

简介

本文档是 Claude Code 提示词使用指南，收录了在实际开发中常用的提示词模板和最佳实践。通过合理使用这些模板，可以更高效地与 Claude Code 协作完成代码分析、方案设计、编码实施等各个开发阶段的工作。

核心原则

在需求分析、方案设计等非编码阶段，建议使用 "不要写代码" 指令，让 AI 先进行充分的分析和讨论，确认方案后再进入编码阶段。

需求分析阶段

模板 1.1：代码逻辑分析

用途： 理解现有代码的特定功能或逻辑

语法：

bash

@{文件路径}#{起始行}-{结束行} 解释一下{具体功能/逻辑},不要写代码

示例：

bash

示例 1（Go）：
@api/v1/user.go#L100-150 解释一下为什么使用缓存中间件而不是直接查询数据库,不要写代码

示例 2（TypeScript）：
@src/utils/dateFormatter.ts#L25-45 解释一下这里为什么要处理时区转换,不要写代码

示例 3（本项目）：
@docs/.vitepress/config.ts#L38-88 解释一下Algolia搜索配置的中文化逻辑,不要写代码

模板 1.2：需求讨论

用途： 讨论新需求的实现方案和影响范围

语法：

bash

讨论需求,不要写代码。{详细需求描述}

示例：

bash

示例 1（后端API）：
讨论需求,不要写代码。需要在用户模块中增加"用户等级"功能,包括普通用户、VIP用户、企业用户三个等级。每个等级有不同的权限和配额限制。这个功能该如何设计?是在现有user表增加字段,还是新建user_level关联表?

示例 2（前端组件）：
讨论需求,不要写代码。需要开发一个通用的表格组件,支持排序、筛选、分页、导出功能。这个组件应该如何设计API和状态管理?

示例 3（本项目）：
讨论需求,不要写代码。需要为文档站点增加"代码示例可复制"功能,并且要记录用户复制次数做统计。这个功能该如何实现?是用插件还是自定义组件?数据如何存储?

模板 1.3：可行性分析

用途： 评估模块合并、重构等操作的可行性

语法：

bash

请查询{模块A}和{模块B}代码逻辑,给出{操作}的可行性分析,不要写代码。

示例：

bash

示例 1（模块合并）：
请查询userService和authService代码逻辑,给出合并的可行性分析,不要写代码。

示例 2（数据库重构）：
请查询orders表和order_items表的关联逻辑,分析是否可以将常用字段反范式化到orders表中以提升查询性能,不要写代码。

示例 3（本项目）：
请查询docs/.vitepress/nav.ts和sidebar.ts的组织方式,分析能否将导航配置统一到一个配置文件中,不要写代码。

模板 1.4：命名评估

用途： 评估当前命名是否合理，寻求更好的命名建议

语法：

bash

{当前命名} 命名需要修改吗?不要写代码

或

bash

{描述对象},是否有更好的命名。不要写代码

示例：

bash

示例 1（类/结构体命名）：
UserActivityLog 主要记录用户的操作历史,包括登录、浏览、下载等行为,有没有更好的命名。不要写代码

示例 2（函数命名）：
getCurrentUserInfoWithPermissions 这个函数名是否过长?能否缩短同时保持清晰度?不要写代码

示例 3（变量命名）：
tempData 这个变量存储的是经过格式化的文档元数据,是否有更好的命名。不要写代码

方案设计阶段

模板 2.1：获取多方案建议

用途： 获取多种解决方案供选择

语法：

bash

有没有更好的方案。不要写代码

或

bash

请先说明{操作}建议,不要写代码

示例：

bash

示例 1（文件重构）：
@service/order.go 需要重构此文件,代码已达到500行且职责不清晰,请先说明重构建议,不要写代码

示例 2（架构优化）：
@src/api/index.ts 当前所有API都写在一个文件中,请提供更好的组织方案,不要写代码

示例 3（性能优化）：
@docs/.vitepress/theme/index.ts 页面加载较慢,请分析并提供优化方案,不要写代码

模板 2.2：方案对比

用途： 验证特定方案的合理性

语法：

bash

{方案描述},是否合适?不要写代码

或

bash

{字段/设计} 是否可明确?先说明,不要写代码

示例：

bash

示例 1（数据库设计）：
在user表中增加platform字段（web/mobile/desktop）和device_type字段（ios/android/windows）是否合适?还是应该用单独的session表记录?先说明,不要写代码

示例 2（API设计）：
使用RESTful风格 GET /api/users/:id/orders 获取用户订单,还是使用GraphQL一次查询所有需要的数据,哪种方案更合适?先说明,不要写代码

示例 3（状态管理）：
使用Vuex进行全局状态管理,还是用Pinia更合适?考虑到项目是Vue 3,先说明,不要写代码

模板 2.3：优缺点分析

用途： 分析技术选择的利弊

语法：

bash

{具体技术选择},说明优缺点,先不写代码

示例：

bash

示例 1（并发控制）：
从缓存取值时不需要加锁,直接读取,说明这种方案的优缺点,先不写代码

示例 2（存储方案）：
使用localStorage存储用户配置而不是每次从服务器获取,说明优缺点,先不写代码

示例 3（渲染策略）：
VitePress文档使用SSG（静态站点生成）而不是SSR（服务端渲染）,说明优缺点,先不写代码

模板 2.4：设计说明

用途： 在修改前先获取详细的设计说明

语法：

bash

先进行{操作}说明,不要写代码

示例：

bash

示例 1（数据库模型）：
@models/User.ts#L10-35 需要给User模型增加以下字段:avatar(头像URL)、bio(个人简介)、preferences(用户偏好设置,JSON类型)。同时将email字段改为唯一索引。先进行修改说明,不要写代码

示例 2（配置文件）：
@config/database.js 需要增加读写分离配置,支持主库写入,从库读取。先进行修改说明,不要写代码

示例 3（本项目）：
@docs/.vitepress/sidebar.ts 需要将PostgreSQL函数文档按功能分类重新组织,将250+函数归类到10个大类下。先进行修改说明,不要写代码

需求确认阶段

模板 3.1：需求复述

用途： 让 AI 复述需求，确保理解一致

语法：

bash

先复述{需求描述},不要写代码

或

bash

[Image #1]{图片说明},先复述一下图片中的逻辑,不要写代码

示例：

bash

示例 1（需求文档）：
先复述需求:需要实现一个用户权限管理系统,包括角色管理、权限分配、权限验证三个模块,不要写代码

示例 2（图片需求）：
[Image #1]这是产品原型图,展示了文章编辑器的UI和交互流程。需要实现富文本编辑、图片上传、自动保存草稿功能。先复述一下图片中的功能需求和交互逻辑,不要写代码

示例 3（口头需求）：
先复述需求:用户希望在文档页面增加"目录导航跟随滚动高亮"和"一键回到顶部"功能,不要写代码

模板 3.2：制定任务计划

用途： 在明确方案后，让 AI 制定详细的实施计划

语法：

bash

制定todo,不要写代码

编码实施阶段

模板 4.1：开始编码（简单任务）

用途： 在方案明确后启动简单的编码任务

语法：

bash

采用方案{X},开始修改

或

bash

采用方案{X},进行编码吧

示例：

bash

示例 1：采用方案2,开始实现用户登录功能吧
示例 2：使用方案B（基于Redis的缓存方案）开始修改
示例 3：采用方案1（组件化拆分）,进行重构吧

模板 4.2：开始编码（复杂任务，需深度思考）

用途： 处理需要深度思考的复杂编码任务

语法：

bash

/think 根据{描述},开始写代码吧

示例：

bash

示例 1：/think 根据支付系统集成逻辑,需要对接三方API并处理回调,开始写代码吧
示例 2：/think 实现一个复杂的数据转换管道,包括清洗、验证、转换、存储四个步骤,开始写代码吧
示例 3：/think 设计并实现文档搜索功能,需要支持全文检索和高亮显示,开始写代码吧

模板 4.3：开始编码（需遵循代码规范）

用途： 确保生成的代码遵循项目规范

语法：

bash

开始,需要使用CLAUDE.md文件中记录的代码风格

或

bash

{任务描述},参考{参考文件}的编码方式

示例：

bash

示例 1（Go）：@service/user.go 在service层使用结构体方法而不是独立函数,遵循CLAUDE.md中的编码规范
示例 2（TypeScript）：@src/utils/validator.ts 参考@src/utils/formatter.ts的编码风格来实现
示例 3（Python）：@app/services/email.py 遵循项目的异步编程模式,使用async/await

模板 4.4：读取参考代码后编码

用途： 基于已有模块的编码风格进行开发

语法：

bash

请读取{模块}相关编码方式,需要将{目标模块}的代码根据{参考模块}编码方式进行修改,请先说明修改建议,不要写代码。

示例：

bash

示例 1（Go）：
请读取user模块相关编码方式,需要将product模块的代码根据user模块编码方式进行重构,请先说明修改建议,不要写代码

示例 2（Vue）：
请读取@components/Table组件的实现方式,需要将@components/List组件参考Table的API设计进行改造,请先说明修改建议,不要写代码

示例 3（文档）：
请读取docs/database/postgreSQL/ref/ascii.md的文档格式,需要将新增的数学函数文档按这个格式编写,请先说明格式要点,不要写代码

代码修改阶段

模板 5.1：精确修改（带代码引用）

用途： 对特定行号范围的代码进行精确修改

语法：

bash

@{文件路径}#{行号范围} {具体修改指令}

示例：

bash

示例 1：@config/constants.ts#L50-60 将这些常量的命名改为SCREAMING_SNAKE_CASE
示例 2：@api/user.ts#L120-135 这段验证逻辑提取到一个独立的validator函数中
示例 3：@docs/.vitepress/nav.ts#L15-25 调整导航菜单的顺序,将AI相关内容提前

模板 5.2：多文件修改

用途： 同时引用和修改多个文件

语法：

bash

@{文件1} @{文件2} {修改说明}

示例：

bash

示例 1：
@api/order.ts @services/order.ts 分析这两个文件的订单处理逻辑,看看能否统一处理流程,不要写代码

示例 2：
@models/User.ts @models/Profile.ts 这两个模型之间的关联关系是否合理?是否应该合并?不要写代码

示例 3：
@docs/.vitepress/config.ts @docs/.vitepress/theme/index.ts 检查这两个文件的主题配置是否有冲突,不要写代码

模板 5.3：重命名操作

用途： 批量重命名变量、函数或结构体

语法：

bash

/repeat 将{旧名称}更名为{新名称}

示例：

bash

示例 1：/repeat 将UserService更名为UserRepository
示例 2：/repeat 将fetchData重命名为loadUserData
示例 3：/repeat 将所有的handler后缀改为controller后缀

模板 5.4：字段修改

用途： 修改结构体字段名称

语法：

bash

{字段A} 修改为{字段B}

示例：

bash

示例 1：userName字段改为username,保持小写
示例 2：isActive改为status,使用枚举值 'active' | 'inactive' | 'suspended'
示例 3：createdAt改为created_at,与数据库字段命名保持一致

模板 5.5：逻辑调整

用途： 调整业务逻辑实现

语法：

bash

{描述问题},{修改要求}

示例：

bash

示例 1：去掉硬编码的userId,改为从context中获取当前登录用户
示例 2：登录成功后应该记录登录日志,现在缺少这个逻辑
示例 3：文件上传前需要先验证文件类型和大小,当前缺少验证

代码优化阶段

模板 6.1：代码整理

用途： 重构混乱的代码，提高可读性

语法：

bash

@{文件路径}#{行号} 代码有点乱,{优化要求}

示例：

bash

示例 1：@services/payment.ts#L80-200 代码有点乱,将支付逻辑按支付方式拆分成多个函数
示例 2：@utils/dataProcess.js#L30-120 这段代码嵌套太深,使用early return重构
示例 3：@docs/.vitepress/sidebar.ts#L100-500 侧边栏配置太长,按文档类型拆分到独立文件

模板 6.2：统一风格

用途： 按照参考模块的风格重构代码

语法：

bash

请读取{参考模块}代码结构,需要将{目标模块}代码根据{参考模块}进行重构,先给出重构说明,不要写代码。

示例：

bash

示例 1（Go）：
请读取product模块代码结构,需要将order模块代码参考product模块的分层设计进行重构,先给出重构说明,不要写代码

示例 2（React）：
请读取@components/Button组件的代码风格,需要将@components/Input组件统一风格,先给出重构说明,不要写代码

示例 3（文档）：
请读取docs/database/postgreSQL/目录结构,需要将docs/database/mongodb/按相同结构重组,先给出重构说明,不要写代码

模板 6.3：提取常量

用途： 将魔法数字或字符串提取为常量

语法：

bash

@{文件路径}#{行号} 将 {描述}提取出来 做为一个常量

示例：

bash

示例 1：@config/routes.ts#L20-50 将这些路由路径字符串提取为常量
示例 2：@utils/validator.ts#L15-30 将正则表达式提取为命名常量
示例 3：@docs/.vitepress/config.ts#L40-45 将Algolia的appId等配置提取到环境变量

模板 6.4：缩短命名

用途： 评估命名是否可以更简洁

语法：

bash

名称是否有缩短的空间,不要写代码

特定技术场景

模板 7.1：Model 层调整

用途： 将函数改为结构体方法（Go 语言 Model 层）

语法：

bash

@models/{文件}.go 在model层使用结构体方法而不是独立函数

示例：

bash

示例 1（Go - Active Record模式）：
@models/User.go 在User模型中使用方法而不是独立函数,例如user.Save()而不是SaveUser(user)

示例 2（TypeScript - Class模式）：
@models/Article.ts 将文章相关的方法都定义为Article类的方法

示例 3（Python - ORM模式）：
@models/product.py 使用SQLAlchemy的声明式基类,将查询方法定义为类方法

模板 7.2：业务逻辑分层

用途： 规范 API 层和 Service 层的职责分离

语法：

bash

@api/{文件} 将业务逻辑从controller层移到service层

示例：

bash

示例 1（Express.js）：
@routes/user.js 将所有业务逻辑从路由处理器中提取到@services/userService.js

示例 2（Go Gin）：
@api/v1/order.go 控制器只负责参数验证和响应,业务逻辑全部放到service层

示例 3（FastAPI）：
@api/endpoints/auth.py 认证逻辑应该在service层实现,API层只做参数校验和响应包装

模板 7.3：添加缓存

用途： 为数据访问添加缓存层

语法：

bash

@{文件路径} 需要使用缓存

或

bash

@service/{文件}.go 在此处增加{功能描述}函数,{缓存策略}

示例：

bash

示例 1（Redis）：
@services/user.ts 增加getUserById函数,先从Redis缓存读取,缓存不存在时查询数据库并写入缓存

示例 2（内存缓存）：
@utils/configLoader.js 配置文件读取后缓存在内存中,使用LRU策略管理缓存大小

示例 3（本项目）：
@docs/.vitepress/theme/index.ts 导航数据可以缓存到sessionStorage,避免每次都解析配置

模板 7.4：路由调整

用途： 调整路由结构，保持其他文件不变

语法：

bash

@router/{文件}.go {路由调整要求},不要修改其他文件

示例：

bash

示例 1（Express）：
@routes/index.js 将用户相关路由独立到@routes/user.js,保持其他路由文件不变

示例 2（Vue Router）：
@router/index.ts 将管理后台的路由单独拆分到@router/admin.ts

示例 3（FastAPI）：
@api/main.py 将支付相关的路由独立到@api/routers/payment.py,不要修改其他路由文件

模板 7.5：向后兼容处理

用途： 在修改时保留旧接口以兼容旧版本

语法：

bash

{操作描述},同时需要保留原{描述}以便向后兼容。

示例：

bash

示例 1（API版本化）：
实现 /api/v2/users 新接口,同时保留 /api/v1/users 旧接口以便向后兼容

示例 2（函数重构）：
重构getUserInfo函数,同时保留原来的getUser作为别名以保持向后兼容

示例 3（配置迁移）：
使用新的配置格式,但继续支持旧配置文件的读取,确保平滑迁移

模板 7.6：不兼容处理

用途： 明确不需要向后兼容

语法：

bash

{操作描述},不需要向后兼容处理

或

bash

不向后兼容: {具体说明}

文档生成场景

模板 8.1：生成 API 文档

用途： 基于代码生成 API 文档

语法：

bash

@api/v1/{文件}.go 读取文件中的代码,生成可以导入{工具名}的接口文档

示例：

bash

示例 1（Swagger/OpenAPI）：
@api/v1/user.go 读取文件中的代码,生成OpenAPI 3.0格式的接口文档

示例 2（Postman）：
@routes/order.js 分析这些路由,生成Postman Collection格式的JSON文档

示例 3（Markdown）：
@controllers/*.ts 读取所有控制器,生成Markdown格式的API文档,包括请求参数、响应格式、示例代码

模板 8.2：建立代码规范

用途： 提取项目代码风格并记录到 CLAUDE.md

语法：

bash

读取{模块}相关代码,将代码风格记录到CLAUDE.md文件中,后续代码都要使用这种风格。

详细版：

bash

请读取项目中与 {模块} 模块相关的代码文件,分析其中的代码风格(包括命名规范、注释风格、结构组织、函数粒度、错误处理方式等),并将分析结果整理成 CLAUDE.md 文件,用于团队代码风格规范。从现在起,所有生成或修改的代码都必须遵循该风格规范。

示例：

bash

示例 1（Go项目）：
读取services/user相关代码,分析其错误处理、日志记录、命名规范等编码风格,记录到CLAUDE.md文件中

示例 2（React项目）：
读取components/Button组件代码,分析其Props定义、事件处理、样式组织等规范,记录到CLAUDE.md中

示例 3（本文档项目）：
读取docs/database/postgreSQL/ref/目录下的函数文档,分析其Markdown格式规范和代码示例风格,记录到CLAUDE.md

数据处理场景

模板 9.1：CSV 数据处理

用途： 处理和转换 CSV 数据

语法：

bash

@{文件}.csv {处理要求};先复述需求,不要写代码。

示例：

bash

示例 1（数据分类）：
@data/products.csv 将商品按价格区间分为:低价(0-100)、中价(100-500)、高价(500+),在CSV中添加"价格区间"列;先复述需求,不要写代码

示例 2（数据清洗）：
@data/users.csv 清理重复数据、补充缺失的邮箱字段、统一日期格式为YYYY-MM-DD;先复述需求,不要写代码

示例 3（数据转换）：
@data/sales.csv 将销售数据按月份汇总,计算每个月的总销售额和平均客单价,生成新的月度统计CSV;先复述需求,不要写代码

上下文管理

模板 10.1：清理上下文

用途： 清理对话历史，开始新任务

语法：

bash

/clear

使用场景：

任务切换前
上下文过长时
开始新功能模块前

模板 10.2：多文件批量操作

用途： 对多个文件执行相同的操作

语法：

bash

/repeat @{文件1} @{文件2} @{文件3} {操作描述}

示例：

bash

示例 1（批量重构）：
/repeat @models/User.ts @services/userService.ts @controllers/userController.ts @routes/user.ts 将这些文件中的findUser方法统一改名为getUserById

示例 2（批量添加注释）：
/repeat @utils/*.ts 为所有工具函数添加JSDoc注释,说明参数类型、返回值、使用示例

示例 3（批量代码分析）：
/repeat @docs/database/**/README.md 检查所有数据库相关文档的目录结构是否一致,给出标准化建议

确认与纠正

模板 11.1：简单确认

用途： 快速确认 AI 的理解或建议

语法：

bash

ok
sure
对

模板 11.2：确认并补充

用途： 确认的同时补充额外信息

语法：

bash

对,{补充说明}

示例：

bash

示例 1：对,但还需要增加权限验证逻辑,确保普通用户不能访问管理员接口
示例 2：正确,同时需要添加日志记录,方便后续问题排查
示例 3：对,此外还要考虑并发情况,加上乐观锁防止数据冲突

模板 11.3：纠正错误

用途： 纠正 AI 的理解偏差

语法：

bash

{错误描述},{正确要求}

示例：

bash

示例 1（字段保留）：
userId字段不能去掉,它用于关联用户表

示例 2（数据补充）：
还缺少"已取消"状态,订单状态应该包括:待支付、已支付、已发货、已完成、已取消

示例 3（逻辑纠正）：
这个逻辑有误,用户删除操作应该是软删除而不是物理删除,需要保留数据用于审计,先说明修改方案,不要写代码

最佳实践工作流

以下是一个完整的开发流程示例：

步骤 1：需求分析

bash

示例：
@services/auth.ts 解释一下JWT token的刷新机制,不要写代码

步骤 2：方案讨论

bash

示例：
讨论需求,不要写代码。需要实现用户头像上传功能,支持裁剪、压缩,存储到OSS。该如何设计?
有没有更好的方案,不要写代码

步骤 3：需求确认

bash

示例：
先复述需求:实现文章收藏功能,用户可以收藏文章,查看收藏列表,取消收藏。需要统计文章被收藏次数,不要写代码

步骤 4：制定计划

bash

示例：
制定todo,不要写代码
（AI会生成：1.设计数据库表 2.实现收藏API 3.实现列表查询 4.前端页面集成 5.编写测试）

步骤 5：开始实施

bash

示例：
采用方案2（使用中间表favorites存储收藏关系）,开始编码吧。需要使用CLAUDE.md文件中记录的代码风格

步骤 6：阶段确认

bash

ok （AI完成一个todo后,确认继续下一个）
或
对,数据库设计没问题,继续实现API吧

步骤 7：清理上下文（切换任务时）

bash

/clear
（在开始新功能或任务前清理上下文）

快捷命令速查

命令	用途	示例
`@文件路径`	引用文件	`@api/v1/user.go`
`@文件#L行号`	引用具体行	`@api/v1/user.go#L100-120`
`/think`	深度思考	`/think 根据需求设计架构`
`/clear`	清理上下文	`/clear`
`/repeat`	重复操作	`/repeat 将A重命名为B`
`不要写代码`	仅分析	`分析可行性,不要写代码`
`先说明`	先规划	`先说明修改方案,不要写代码`

使用建议

收藏此模板库，根据实际场景灵活组合使用
在非编码阶段充分讨论，确保方案正确后再开始编码
定期使用 /clear 清理上下文，保持对话焦点清晰
善用 CLAUDE.md 记录项目代码规范，确保代码风格一致

Claude Code 提示词模板库 ​

简介 ​

需求分析阶段 ​

模板 1.1：代码逻辑分析 ​

模板 1.2：需求讨论 ​

模板 1.3：可行性分析 ​

模板 1.4：命名评估 ​

方案设计阶段 ​

模板 2.1：获取多方案建议 ​

模板 2.2：方案对比 ​

模板 2.3：优缺点分析 ​

模板 2.4：设计说明 ​

需求确认阶段 ​

模板 3.1：需求复述 ​

模板 3.2：制定任务计划 ​

编码实施阶段 ​

模板 4.1：开始编码（简单任务） ​

模板 4.2：开始编码（复杂任务，需深度思考） ​

模板 4.3：开始编码（需遵循代码规范） ​

模板 4.4：读取参考代码后编码 ​

代码修改阶段 ​

模板 5.1：精确修改（带代码引用） ​

模板 5.2：多文件修改 ​

模板 5.3：重命名操作 ​

模板 5.4：字段修改 ​

模板 5.5：逻辑调整 ​

代码优化阶段 ​

模板 6.1：代码整理 ​

模板 6.2：统一风格 ​

模板 6.3：提取常量 ​

模板 6.4：缩短命名 ​

特定技术场景 ​

模板 7.1：Model 层调整 ​

模板 7.2：业务逻辑分层 ​

模板 7.3：添加缓存 ​

模板 7.4：路由调整 ​

模板 7.5：向后兼容处理 ​

模板 7.6：不兼容处理 ​

文档生成场景 ​

模板 8.1：生成 API 文档 ​

模板 8.2：建立代码规范 ​

数据处理场景 ​

模板 9.1：CSV 数据处理 ​

上下文管理 ​

模板 10.1：清理上下文 ​

模板 10.2：多文件批量操作 ​

确认与纠正 ​

模板 11.1：简单确认 ​

模板 11.2：确认并补充 ​

模板 11.3：纠正错误 ​

最佳实践工作流 ​

步骤 1：需求分析 ​

步骤 2：方案讨论 ​

步骤 3：需求确认 ​

步骤 4：制定计划 ​

步骤 5：开始实施 ​

步骤 6：阶段确认 ​

步骤 7：清理上下文（切换任务时） ​

快捷命令速查 ​

Claude Code 提示词模板库

简介

需求分析阶段

模板 1.1：代码逻辑分析

模板 1.2：需求讨论

模板 1.3：可行性分析

模板 1.4：命名评估

方案设计阶段

模板 2.1：获取多方案建议

模板 2.2：方案对比

模板 2.3：优缺点分析

模板 2.4：设计说明

需求确认阶段

模板 3.1：需求复述

模板 3.2：制定任务计划

编码实施阶段

模板 4.1：开始编码（简单任务）

模板 4.2：开始编码（复杂任务，需深度思考）

模板 4.3：开始编码（需遵循代码规范）

模板 4.4：读取参考代码后编码

代码修改阶段

模板 5.1：精确修改（带代码引用）

模板 5.2：多文件修改

模板 5.3：重命名操作

模板 5.4：字段修改

模板 5.5：逻辑调整

代码优化阶段

模板 6.1：代码整理

模板 6.2：统一风格

模板 6.3：提取常量

模板 6.4：缩短命名

特定技术场景

模板 7.1：Model 层调整

模板 7.2：业务逻辑分层

模板 7.3：添加缓存

模板 7.4：路由调整

模板 7.5：向后兼容处理

模板 7.6：不兼容处理

文档生成场景

模板 8.1：生成 API 文档

模板 8.2：建立代码规范

数据处理场景

模板 9.1：CSV 数据处理

上下文管理

模板 10.1：清理上下文

模板 10.2：多文件批量操作

确认与纠正

模板 11.1：简单确认

模板 11.2：确认并补充

模板 11.3：纠正错误

最佳实践工作流

步骤 1：需求分析

步骤 2：方案讨论

步骤 3：需求确认

步骤 4：制定计划

步骤 5：开始实施

步骤 6：阶段确认

步骤 7：清理上下文（切换任务时）

快捷命令速查