阅读时长：约25分钟
难度：★★☆☆☆（使用难度低，但信息密度高）
适合人群：所有已完成地基篇的开发者------不管你是否学完了核心技能篇的每一课
学完之后：面对10种最常见的开发任务，你都有一个经过打磨的 prompt 模板可以直接套用
为什么需要这一课
《Claude Code 从入门到精通》试读篇：Claude Code 是什么？你可能从第一步就用错了
《Claude Code 从入门到精通》试读篇：你的第一次 Director Mode 体验（二）
《Claude Code 从入门到精通》试读篇：写好 Prompt 的结构化思维，10组正反对比，看完直接套用（三）
《Claude Code 从入门到精通》试读篇：当 Claude 理解错了怎么办（四）
《Claude Code 从入门到精通》目标优于指令，Director Mode 第一支柱（五）
第06课：让 Claude 自己分配任务------并行 Agent 策略
《Claude Code 从入门到精通》第07课：结果验证------你最不能省的一步
第08课：CLAUDE.md，让 Claude 永远记住你的规矩
前面8课你学了认知、方法论、三大支柱、CLAUDE.md。体系完整了。
但说实话------你明天上班打开 Claude Code，面对一个具体的任务时，脑子里大概率还是会空白一秒："我该怎么组织这个 prompt？"
这很正常。从"理解方法论"到"条件反射般写出好 prompt"，中间需要大量的实践来形成肌肉记忆。
这课帮你跳过这个过程。
我把开发者最常遇到的10种任务场景，每种都打磨了一个"最终版"prompt 模板。你要做的就是：复制模板 → 把 [方括号] 里的内容替换成你自己的项目信息 → 发给 Claude。
不需要思考结构、不需要纠结四要素的比例、不需要回忆"Bug 修复该侧重上下文还是约束"------模板已经帮你把这些全部处理好了。
用几次之后，你自然就内化了。这些模板不是拐杖，是脚手架------它帮你快速搭起骨架，等你熟练了，拆掉脚手架你也能写得一样好。
怎么使用这些模板
每个模板的结构是统一的：
go
📋 场景名称
📝 适用情况（什么时候用这个模板）
📌 模板正文（复制这段，改方括号里的内容）
💡 使用技巧（怎么改效果最好）
⚠️ 常见陷阱（别踩这些坑）模板里的 [方括号] 是你需要替换的部分。 没有方括号的内容可以直接用，不需要改。
建议你第一次用每个模板时，完整看一遍模板正文的每一句话，理解它在控制什么。用了两三次之后就不需要看了，直接填空发送。
模板1：新功能开发
📝 适用情况：给项目新增一个完整的功能模块------从数据库到接口到业务逻辑。
📌 模板正文：
go
在 [模块目录，如 src/modules/comment/] 下新增 [功能名称，如 评论管理] 功能。
功能需求：
- [需求1，如 用户可以对文章发表评论]
- [需求2，如 支持评论的回复（二级评论，不做更深嵌套）]
- [需求3，如 支持评论点赞]
- [需求4，如 评论列表按时间倒序展示，支持分页]
- [业务规则，如 每个用户每篇文章最多评论50条]
质量标准：
- 参照 [已有模块路径，如 src/modules/user/] 的代码结构和风格
- 接口设计遵循 RESTful 规范，包含完整的参数校验
- 完整的单元测试，覆盖正常流程和至少3个异常路径
- [其他标准，如 API 文档 / Swagger 注解]
约束：
- 使用项目现有的技术栈和依赖，不引入新的库
- [特定约束，如 第一版不支持富文本和图片评论，纯文本即可]
- [兼容性约束，如 不影响现有的文章模块逻辑]
完成后做自查：功能逐条对照需求确认 → 边界情况处理 → 代码风格一致性。💡 使用技巧：
-
"功能需求"部分写业务规则而不是技术实现。写"每个用户最多50条评论"而不是"在数据库插入前 COUNT 现有记录数"
-
"参照XXX的代码结构"这句话是整个模板里最省力的一句------它替代了你手动描述文件结构、命名风格、分层方式的工作
-
如果功能复杂（涉及5个以上子功能），在最后加一句"先给出实现方案和模块拆分，我确认后再执行"
⚠️ 常见陷阱：不要在需求里混入技术实现细节。"用 Redis 缓存评论列表"是实现细节，让 Claude 自己判断要不要缓存。
模板2：Bug 修复
📝 适用情况：线上或测试环境发现了 Bug，需要定位原因并修复。
📌 模板正文：
go
修复 [模块/功能名称] 中的 [问题简述] 问题。
症状描述：
- 现象：[具体现象，如 用户下单后支付成功但订单状态仍显示"待支付"]
- 影响范围：[谁受影响，如 约3%的微信支付订单，支付宝正常]
- 出现时间：[什么时候开始，如 从本周三开始]
- 频率：[是否可稳定复现，如 间歇性出现，非必现]
排查方向（供参考，不限于此）：
- [方向1，如 支付回调的处理逻辑]
- [方向2，如 订单状态更新的事务处理]
- [方向3，如 最近的代码变更（本周三有一次发版）]
修复要求：
- 找到根本原因，不只是修复表面症状
- [特殊要求，如 历史受影响的数据需要写修复脚本]
- 修复后必须有测试覆盖这个场景
- 不影响 [不能动的部分，如 支付宝回调逻辑（那边是正常的）]
完成后做自查：修复是否解决根因 → 有没有引入新问题 → 测试是否覆盖。💡 使用技巧：
-
"症状描述"是这个模板里最重要的部分。症状越具体（什么用户、什么操作、什么时间段），Claude 的排查效率越高
-
"排查方向"写"供参考，不限于此"------不要限制 Claude 的排查范围，你想到的方向可能不是真正原因
-
如果有错误日志或截图，直接粘贴在 prompt 里。原始错误信息比你的描述更精确
⚠️ 常见陷阱：不要预设原因。写"支付回调有 bug"不如写"支付成功但订单状态没更新"------前者已经下了结论，后者只描述症状。