拓展附加资源-Claude Code高质量提示词模板

ClaudeCode高质量提示词模板包需求拆解/Bug修复/重构/文档/审查/项目接手进阶版商品定位这不是“几句prompt清单”，而是：一套适合ClaudeCode场景的结构化工作模板使用说明这套模板的正确用法不是“原样无脑复制”，而是：把你的项目背景替换进去把你的目标文件/模块/报错信息替换进去明确告诉ClaudeCode：先分析还是先执行输出要不要分步骤改动边界在哪里是否允许重构如果任务复杂，优先用“计划→确认→执行”的模板，而不是直接让它动手这套模板的核心目标是：降低ClaudeCode跑偏概率降低上下文污染降低“大改特改”风险让输出更像真正的工程协作结果一、需求理解与任务拆解类模板1：把模糊需求改写成可执行开发任务适用场景你脑子里有想法，但不会表达成开发需求想先让ClaudeCode帮你把事情讲清楚不想它一上来乱写代码提示词我现在有一个比较模糊的需求，请你先不要写代码，也不要直接开始修改项目。我希望你先把这个需求改写成一份可执行的开发任务说明，要求尽量像一个认真工程师接需求后的梳理结果，而不是泛泛总结。请按下面结构输出：需求目标这个需求最终要解决什么问题用户视角下的预期结果是什么当前已知信息从我的描述里你已经能确定的事实有哪些哪些约束已经明确缺失信息要顺利开发，还缺哪些关键条件哪些问题如果不补充，后续实现容易跑偏建议的功能边界这个需求的最小版本应该包含什么什么内容不建议一开始就做进去涉及模块或文件（如果你能初步判断）这个需求可能会影响哪些模块哪些位置值得优先查看推荐执行顺序如果要做这件事，最合理的步骤是什么请尽量分成3–6个小步骤潜在风险哪些地方容易误解哪些地方容易改坏现有逻辑最后，请给我一版：一句话简版任务描述适合直接进入开发的正式版任务描述我的原始需求如下：【把你的需求贴在这里】模板2：把一个大任务拆成子任务清单适用场景功能不小你不想ClaudeCode一口气做完想分阶段推进提示词我需要你把下面这个任务拆成工程上可执行的子任务清单。先不要直接改代码，我现在需要的是一个靠谱的拆解方案。请按下面格式输出：对每一个子任务，都写清楚：子任务名称子任务目标为什么需要这个子任务预计涉及的文件或模块依赖关系这个任务是否依赖前面的任务是否可以并行风险等级低/中/高建议执行顺序完成标志怎样才算这个子任务真正完成最后请补充两部分：A.最小可用路径（MVP）如果我只想先做出一个能跑的版本，最少应该做哪几个子任务？B.完整版路径如果我想把它做完整，你建议的完整顺序是什么？任务描述如下：【贴需求】模板3：识别需求缺口，先问清楚再动手适用场景你知道自己描述得不完整想防止ClaudeCode硬脑补提示词在开始实现之前，我希望你扮演一个非常谨慎的工程师，先检查这个需求里有哪些地方描述不够完整。请你不要直接写代码。先做“需求缺口分析”。请按下面结构输出：你已经明确理解的部分有歧义的部分缺失但关键的信息如果不补充，最可能导致什么错误你建议我先回答的5个最关键问题如果你认为某些地方可以先采用默认方案，请额外列出：默认假设是什么为什么这么假设这种假设的风险是什么需求如下：【贴需求】二、计划与执行控制类模板4：先出计划，不允许直接改代码适用场景复杂任务你想看ClaudeCode的思路是否靠谱你不想它冲动开改提示词现在不要直接修改代码，也不要生成最终实现。请你先基于当前项目和这个需求，做一份执行计划。我希望这份计划像是你真正要自己动手开发前写出来的工作说明，而不是泛泛几句话。请按下面结构输出：任务理解用你自己的话复述需求说清楚目标和约束建议查看的文件/模块哪些文件最值得先读为什么执行步骤请按先后顺序列出每步要说明做什么、为什么、预期产出是什么改动范围预估这次改动会大概影响多少文件哪些地方最敏感潜在风险哪些改动可能破坏旧逻辑哪些边界情况需要提前考虑最小改动方案如果要尽量保守，应该怎么做更优雅但更复杂的方案如果要兼顾长期维护，是否有更好的做法代价是什么推荐方案你最终建议我选哪一个理由是什么等我确认后，你再开始执行。需求如下：【贴需求】模板5：只允许最小必要改动适用场景修bug小需求你很怕它“顺手优化一大片”提示词请你严格遵守“最小必要改动”原则来处理这个任务。要求如下：不要重构无关代码不要调整命名风格不要清理你觉得“不顺眼”的部分不要顺手做额外优化不要改动和当前需求无关的文件只解决当前明确的问题执行前，请你先输出：你认为必须修改的最小文件范围你认为可以完全不碰的部分你打算怎么保证改动尽量小完成后你会怎么验证没有误伤其他逻辑我更看重：稳范围小风险可控而不是“顺便做得更漂亮”。任务如下：【贴需求或问题】模板6：先做MVP，不追求完美适用场景你要先跑通不想陷进细节适合做第一版功能提示词这次我不需要一个完美版本，我需要的是一个最小可用版本（MVP）。请你按“MVP优先”的原则来处理：要求：优先完成核心功能闭环先让主要路径跑通不要一开始处理所有边缘情况不要为了完美结构而过度设计可以接受未来再补优化请输出：MVP版本包含什么MVP明确不处理什么为什么这样划分实现步骤未来如果要升级，最自然的演进方向是什么然后再开始实现。需求如下：【贴需求】三、Bug排查与修复类模板7：先定位根因，再修bug适用场景报错现象复杂你不想它头痛医头提示词我现在遇到一个bug。先不要直接改代码，也不要急着给修复方案。我希望你先做根因分析，把问题真正定位清楚。请按下面结构输出：问题现象复述你理解的bug是什么触发条件是什么可能原因列表请按可能性从高到低列出3–5个原因每个原因都说明为什么你会怀疑它每个原因对应的排查位置要看哪些文件要看哪些变量/逻辑要关注什么数据流最可能的根因给出你当前最怀疑的点说明理由最小修复方案如果这个根因成立，最小修复应该怎么做验证方法修完后怎么确认问题真的解决了还要防什么回归风险问题描述/报错信息如下：【贴报错或现象】模板8：按“复现→定位→修复→验证”流程处理适用场景你想让ClaudeCode的处理过程更像工程师不希望它直接跳到修复提示词请你按照下面这个工程流程处理问题，不要跳步：第一步：复现说明你理解的复现路径如果无法复现，请指出缺什么信息第二步：定位找出最可能出问题的模块、函数或代码段说明定位依据第三步：修复给出最小必要修复方案不要大范围重构第四步：验证列出验证修复是否生效的方法说明还需要检查哪些相关路径输出要尽量像“真实问题处理记录”，不是只给我一句修复建议。问题如下：【贴现象】模板9：只修这个bug，不顺手做工程洁癖适用场景你知道ClaudeCode容易“越修越大”提示词本次目标只有一个：修掉当前这个bug。请你严格遵守以下约束：不要顺手重构不要顺手改命名不要顺手清理历史代码不要顺手优化无关逻辑只修和当前bug直接相关的问题修复后请你输出：根因定位具体改动为什么这些改动足够解决问题哪些地方我可以明确知道你没有动还有没有残余风险问题如下：【贴bug】四、代码生成与实现类模板10：按现有项目风格实现，不要AI味太重适用场景你怕生成出来一看就是AI写的你要和旧项目保持一致提示词请在实现这个功能前，先理解当前项目已有的代码风格和结构模式。我不希望你生成一眼看上去“AI味很重”的代码，也不希望你引入和现有项目气质不一致的写法。请遵守：尽量沿用现有命名风格尽量沿用现有目录和模块组织方式尽量沿用已有封装层次如果项目里已经有类似写法，优先复用其思路不要为了“更现代”而硬塞新模式执行时请先输出：你观察到的项目风格你准备参考哪些已有文件你会如何避免生成感太强的实现你打算怎么把改动控制在现有风格里然后再开始实现。需求如下：【贴需求】模板11：给我一个“能直接落地”的实现版本适用场景你不想要概念方案你要直接能用的东西提示词请不要只给我高层思路，我需要的是一个基于当前项目实际结构、可以直接落地执行的实现方案。要求：明确改哪些文件明确加什么逻辑明确为什么这么改如果有多个方案，先给最稳妥、最容易落地的那个不要停留在概念层请输出：推荐实现方案为什么它最适合当前项目涉及文件清单每个文件具体改动点实现代码验证步骤需求如下：【贴需求】模板12：生成“保守版本”和“长期版本”两种方案适用场景你既想赶时间，也想知道长期最优解提示词请针对这个需求，同时给我两种方案：方案A：保守落地版特点：改动最少风险最低最快可上线方案B：长期更优版特点：更清晰更好维护结构更合理但改动可能更大对于每个方案，请都说明：思路涉及文件主要改动优点风险你更推荐哪一个需求如下：【贴需求】五、重构与优化类模板13：重构但不能改变外部行为适用场景代码太乱你想收敛结构又怕改坏功能提示词请对这段代码/这个模块做重构，但必须严格遵守一个原则：外部行为保持不变也就是说：输入输出行为不能变现有业务逻辑不能变对外接口不能变只是让内部结构更清晰、更易读、更易维护请按下面结构输出：当前代码存在的问题重复可读性差逻辑耦合难维护等你建议的重构方向为什么不会影响外部行为重构后代码重构后我应该重点验证哪些点代码如下：【贴代码】模板14：识别代码坏味道并排序适用场景接手旧项目想知道哪里值得优先动提示词请你以代码审查者的视角，帮我识别这段代码/这个模块里的典型坏味道（codesmells）。要求：不只是列名词要结合具体代码位置说明要按“最值得优先处理”的顺序排序请按下面结构输出：坏味道名称具体体现在哪里为什么这是问题短期不改的后果最小改进建议优先级（高/中/低）代码如下：【贴代码】模板15：值不值得做性能优化适用场景你不确定优化有没有必要不想白折腾提示词请帮我分析这段实现是否真的值得做性能优化。我不想为了“理论更优”而做无意义的改动，所以请你务实一点。请输出：当前实现主要在做什么可能的性能瓶颈在哪里这些瓶颈在什么场景下才会明显如果现在不优化，实际风险是什么如果要优化，最划算的一步是什么不建议优化的理由（如果你认为不值得）代码如下：【贴代码】六、文档、解释与接手类模板16：给我讲懂这段代码，不要空讲适用场景学项目接手项目自己写的代码过几天看不懂提示词请你把这段代码/这个模块讲清楚，但不要只给我抽象解释。我希望你像一个认真带新人上手项目的人来讲。请按下面结构输出：这段代码整体的职责关键函数/类分别负责什么数据或调用流程是怎么走的最核心的控制逻辑在哪里哪些地方最容易误解如果我要改它，最该先看哪里有哪些隐藏风险或依赖代码如下：【贴代码】模板17：生成项目接手导览适用场景新接手代码库需要快速上手提示词我现在需要快速接手这个项目。请你基于当前代码库，生成一份“项目接手导览”。要求输出：项目整体是做什么的目录结构总览最关键的入口文件核心模块之间的关系如果我是新接手者，最应该先看哪几个文件项目当前可能最脆弱的部分最容易踩坑的地方建议的上手顺序写法尽量偏“内部交接文档”，而不是面向外行的科普文。模板18：生成一份可交付的技术说明文档适用场景写README给别人接手给自己留文档提示词请基于当前实现，为这个模块/功能生成一份能交给别人看的技术说明文档。要求包含：模块作用主要组成输入输出关键流程使用方式注意事项常见问题后续维护建议风格要求：简洁专业可交接不写空话七、测试与审查类模板19：帮我列完整测试清单适用场景功能做完不知道怎么测才稳提示词请针对这次需求/改动，帮我设计一份尽量完整但实用的测试清单。不要只写“测试正常情况”，要把边界条件也考虑进去。请输出：正常路径测试边界条件测试异常输入测试回归风险检查与其他模块的联动检查最容易漏测的点如果时间不够，最少必须测哪几项需求或改动如下：【贴内容】模板20：站在严格审查者角度挑错适用场景你想让ClaudeCode自己审自己很适合上线前最后一道检查提示词请你切换到“严格代码审查者”的视角，审查这次实现。不要客气，不要只说优点，重点帮我挑问题。请重点检查：逻辑漏洞边界遗漏风格不一致不必要复杂度未来维护风险潜在副作用请按下面结构输出：总体评价