第09课：10个高频场景 Prompt 模板库，复制、改几个词、直接用

阅读时长约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 修复该侧重上下文还是约束——模板已经帮你把这些全部处理好了。用几次之后你自然就内化了。这些模板不是拐杖是脚手架——它帮你快速搭起骨架等你熟练了拆掉脚手架你也能写得一样好。怎么使用这些模板每个模板的结构是统一的 场景名称 适用情况什么时候用这个模板 模板正文复制这段改方括号里的内容 使用技巧怎么改效果最好 ⚠️ 常见陷阱别踩这些坑模板里的[方括号]是你需要替换的部分。没有方括号的内容可以直接用不需要改。建议你第一次用每个模板时完整看一遍模板正文的每一句话理解它在控制什么。用了两三次之后就不需要看了直接填空发送。模板1新功能开发适用情况给项目新增一个完整的功能模块——从数据库到接口到业务逻辑。模板正文在 [模块目录如 src/modules/comment/] 下新增 [功能名称如 评论管理] 功能。 功能需求 - [需求1如 用户可以对文章发表评论] - [需求2如 支持评论的回复二级评论不做更深嵌套] - [需求3如 支持评论点赞] - [需求4如 评论列表按时间倒序展示支持分页] - [业务规则如 每个用户每篇文章最多评论50条] 质量标准 - 参照 [已有模块路径如 src/modules/user/] 的代码结构和风格 - 接口设计遵循 RESTful 规范包含完整的参数校验 - 完整的单元测试覆盖正常流程和至少3个异常路径 - [其他标准如 API 文档 / Swagger 注解] 约束 - 使用项目现有的技术栈和依赖不引入新的库 - [特定约束如 第一版不支持富文本和图片评论纯文本即可] - [兼容性约束如 不影响现有的文章模块逻辑] 完成后做自查功能逐条对照需求确认 → 边界情况处理 → 代码风格一致性。使用技巧功能需求部分写业务规则而不是技术实现。写每个用户最多50条评论而不是在数据库插入前 COUNT 现有记录数参照XXX的代码结构这句话是整个模板里最省力的一句——它替代了你手动描述文件结构、命名风格、分层方式的工作如果功能复杂涉及5个以上子功能在最后加一句先给出实现方案和模块拆分我确认后再执行⚠️常见陷阱不要在需求里混入技术实现细节。用 Redis 缓存评论列表是实现细节让 Claude 自己判断要不要缓存。模板2Bug 修复适用情况线上或测试环境发现了 Bug需要定位原因并修复。模板正文修复 [模块/功能名称] 中的 [问题简述] 问题。 症状描述 - 现象[具体现象如 用户下单后支付成功但订单状态仍显示待支付] - 影响范围[谁受影响如 约3%的微信支付订单支付宝正常] - 出现时间[什么时候开始如 从本周三开始] - 频率[是否可稳定复现如 间歇性出现非必现] 排查方向供参考不限于此 - [方向1如 支付回调的处理逻辑] - [方向2如 订单状态更新的事务处理] - [方向3如 最近的代码变更本周三有一次发版] 修复要求 - 找到根本原因不只是修复表面症状 - [特殊要求如 历史受影响的数据需要写修复脚本] - 修复后必须有测试覆盖这个场景 - 不影响 [不能动的部分如 支付宝回调逻辑那边是正常的] 完成后做自查修复是否解决根因 → 有没有引入新问题 → 测试是否覆盖。使用技巧症状描述是这个模板里最重要的部分。症状越具体什么用户、什么操作、什么时间段Claude 的排查效率越高排查方向写供参考不限于此——不要限制 Claude 的排查范围你想到的方向可能不是真正原因如果有错误日志或截图直接粘贴在 prompt 里。原始错误信息比你的描述更精确⚠️常见陷阱不要预设原因。写支付回调有 bug不如写支付成功但订单状态没更新——前者已经下了结论后者只描述症状。