想让 Claude 写出更贴合需求的代码，不要只说“帮我做个程序”，而要交代它解决什么问题、接收什么输入、应该产生什么结果，以及运行环境和不能违反的限制。再补上可检查的验收条件，并说明要完整代码还是局部修改。本文提供一套可按任务取舍的提问结构，帮助初学者把想法变成清楚的编程要求。
向 Claude 提问写代码，先说清哪几件事？
编程提示词不必很长，但要让 Claude 能区分“要做什么”和“做到什么程度”。Anthropic 官方提示指南的检索摘要支持几个通用做法：给出明确指令、补充相关背景，并说明希望得到的输出形式。这些是写提示词的参考原则，不是每项任务都必须填满的固定清单。本文提到的模板和示例均为编辑示例。
- 目标：要解决的具体问题是什么？说明用户会怎样使用它，而不只是写“做一个工具”。
- 输入和输出：程序接收什么数据，最终显示、保存或返回什么？给一个例子通常比抽象描述更清晰。
- 环境与限制：指定语言、运行方式、已有框架或兼容要求；如果没有特别要求，也可以明确让 Claude 选简单方案并说明假设。
- 验收条件：列出必须实现的行为、边界情况，以及哪些现有功能不能被改变。
- 交付形式：要求完整文件、代码片段或补丁，并视需要索取运行命令、依赖说明和测试用例。
简单任务可以只写目标、输入输出和交付形式；涉及旧项目、业务规则或多种异常情况时，再补充技术约束和验收标准。不要为了显得专业而罗列无关背景，重点是提供会影响实现的内容。
怎样把一句模糊需求改成可执行的编程提示？
比如，“帮我写个记账程序”没有说明用户要如何记账、数据要保存在哪里，也没有定义错误输入如何处理。Claude 只能自行补全这些空白，结果可能与你的设想不同。可以改成下面这样：
请用 Python 写一个命令行记账小工具，供个人在本地记录日常开支。用户可以新增一条记录，也可以查看全部记录。每条记录包含日期、金额、分类和备注；金额必须大于 0，日期格式不正确时应提示用户重新输入。查看记录时按日期从新到旧排列。请先给出完整代码，再列出运行命令和 3 个自测用例。如果数据保存方式有多种选择，请先说明你的假设。
这个例子把需求拆成了目标、使用场景、字段、操作、校验规则、排序方式和交付内容。验收条件也能帮助你判断结果：新增有效金额后能否看到记录？输入负数时会不会被接受？日期顺序是否正确？把期望结果写成可观察的行为，通常比“代码要完善”“写得好一点”更有用。
如果你还没想好某个细节，不必装作已经决定。可以补一句：“如果需求中有会影响实现的重要信息缺失，请先列出需要确认的问题；其余部分请说明你采用的假设。”这是给 Claude 的一种可选指令，并不代表每次都必须先问答澄清。
要 Claude 修改现有代码，应该贴哪些上下文？
修改旧代码时，重点不是把整个项目一股脑贴进去，而是提供足以理解任务的部分：相关函数或文件、它从哪里被调用、目前发生什么，以及改完后希望出现什么行为。如果问题涉及目录结构或依赖，再补充对应信息；无关文件通常不会让修改更准确。
例如，不要只说“把这个功能改好”。可以写：“下面的函数负责筛选订单，目前会把已取消订单也计入结果。我希望只统计状态为 paid 的订单；其他状态的处理和函数参数保持不变。请只修改这个函数，先指出你对现有逻辑的理解，再给出修改后的代码。”这样的说法明确了现状、变化目标和修改范围，减少顺手重写其他部分的可能。
如果 Claude 看不到项目中的其他文件，就不要默认它知道项目的架构或约定。可以把关键调用方式、相关类型定义或必要的目录树贴出来；如果材料不足，要求它先指出缺少什么。提供内容前，应删除 API 密钥、访问令牌、密码、真实个人资料等敏感信息。不要把秘密配置直接复制进聊天记录；需要展示配置格式时，用无效占位符替代真实值。
复杂功能一次问完，还是分几轮让 Claude 写？
小型、边界清楚的脚本可以一次提出完整需求；如果任务涉及多个文件、既有项目结构或多条业务规则，更适合分轮推进。Anthropic 提示指南的检索摘要也支持将较长任务增量处理，并用测试或指定检查标准核对结果，但这不等于模型已经实际运行了你的项目。
- 先确定需求：说明目标和约束，请 Claude 复述关键规则、列出不确定点。对于重要的业务规则，先确认再动代码。
- 再约定方案：让它说明准备修改哪些模块、输入输出如何衔接。发现方案与你的项目不符时，在写代码前纠正。
- 按模块实现：一次处理一个清晰的功能，要求遵守前面确认的接口和规则。每轮都说明本轮要交付什么。
- 最后对照标准检查：提供测试条件或具体用例，要求它逐项说明覆盖情况。代码是否通过测试，仍需看实际运行结果，不能把文字说明当作执行证明。
为避免分轮后前后不一致，可以把确认过的关键约定简短地带入后续提示，例如“继续使用前面确定的函数签名和数据格式，不要改动其他模块”。如果任务很小，刻意分成很多轮反而会增加沟通成本；分步的价值在于减少复杂需求中的误解和返工。
怎样让 Claude 按你需要的形式交付代码？
“给我代码”可能得到一个片段，也可能得到完整示例。若你需要可以复制运行的结果，就把交付要求写具体：要哪些文件、是否需要完整代码、是否允许只给差异、注释需要解释什么。还可以要求列出依赖、运行命令、关键假设和自测用例，但这些内容要按实际需要选择。
下面是一份可直接改写的模板。它不是官方规定格式，也不必每次照抄全部栏目：
请帮我用【语言或框架】实现【具体目标】。使用场景是【谁在什么情况下使用】。输入为【输入示例】，期望输出为【输出示例】。必须满足【规则和边界情况】；不要改动【现有接口、文件或功能】。当前相关代码或结构是：【粘贴必要内容】。请交付【完整代码／指定文件／局部补丁】，并说明【运行方法、依赖或测试用例】。如果缺少的信息会影响实现，请先列出需要确认的问题；否则请说明你采用的假设。
模板里最值得优先保留的是目标、输入输出和限制。比如只是写一个一次性的小脚本，项目结构和接口要求可能并不重要；要给现有系统增加功能时，接口、依赖和不可改动范围就更关键。把每项填成能核对的事实，比写“请仔细完成”更容易得到有用结果。
Claude 没按要求回答，下一句该怎么追问？
追问时指出具体哪条要求没有满足，并说明预期与实际差异。比如：“你输出的版本仍然允许金额为负数，而需求要求金额必须大于 0。请只修改输入校验部分，并保留其他函数和字段不变。”这比“写错了，重写”更容易把修改范围说清楚。
如果你还不确定问题出在哪里，可以让 Claude 先列出它对需求的理解、采用的假设和未覆盖的验收条件，再决定是否修改。若回答涉及修改很多无关内容，可以明确要求只处理某个函数或文件。若它误解了输入格式，直接补一组输入和预期输出，往往比重复原来的抽象要求更有效。
最后，生成代码不等于代码已经适合你的环境。根据任务在本地运行、检查边界输入并执行测试；测试失败时，再把相关报错、复现步骤和必要代码作为下一轮上下文。模型的说明和自查可以帮助定位问题，但不能代替实际验证。
截至 2026 年 10 月 9 日核查的 Anthropic 官方提示指南检索摘要支持明确指令、提供背景、指定输出形式，以及对复杂任务分步推进并按检查标准核验。该日期是本文资料核查日期，并非指南的发布日期；摘要不是网页全文，也不能据此推断所有 Claude 产品或编程任务都遵循同一套固定公式。