Claude Code 怎么描述代码修改需求？

Claude Code 修改代码时，需求里至少要说明什么？

一条可执行的修改要求，不一定很长，但需要让 Claude Code 能分辨“现在有什么问题”和“改完应该是什么样”。可以先准备四类信息：问题背景、目标行为、修改边界、验收条件。若存在必须遵守的技术约束，再单独列出。

• 背景：谁在什么情况下遇到问题？如果有报错，尽量提供原始错误文字，而不是只概括成“程序崩了”。
• 目标：希望用户看到什么结果，或者希望程序具备什么行为？描述结果比指定它逐行怎么改更有弹性。
• 边界：哪些模块可以改，哪些接口、页面、数据格式或无关功能必须保持不变？
• 验收：输入、操作或情形是什么，对应的预期结果是什么？最好能用实际观察判断，而不是只写“效果更好”。

Anthropic 帮助中心的提示建议包括：说明想要的结果而非替 Claude Code 规定每一步、已知相关文件时指出路径，并提前写明“完成”的标准。换句话说，不必猜测它应该从哪一行开始，但要讲清楚你要解决什么，以及什么不能被破坏。官方提示与项目上下文说明

怎样把一句笼统要求改写成可执行任务？

把“背景—目标—范围—约束—验收”作为组织思路即可，不需要每次写成正式需求文档。下面这段可以直接复制，再按实际项目删改：

任务：【要解决的问题或希望完成的变化】。
背景：【在哪个页面、操作或输入下出现；已有报错可原样贴在这里】。
期望结果：【用户操作后应看到什么，或系统应该怎样响应】。
修改范围：【已知文件路径、组件或功能；不确定时请先检查并说明计划修改的位置】。
保持不变：【不可改变的接口、数据结构、现有行为或其他模块】。
验收条件：【至少列出一到三条可观察的结果】。
处理方式：如果关键要求存在歧义，先提问；不要自行扩大修改范围。

例如，“优化登录页面”没有说明优化的是视觉、错误提示还是登录流程。可以改成：“用户提交空邮箱时，目前页面没有明确提示。请检查登录表单相关实现，让空邮箱提交时显示可读的校验提示；保留现有登录接口和页面布局，不改密码校验逻辑。验收时，空邮箱提交应出现提示，有效邮箱的登录流程不应因本次修改改变。”这是用来展示表达方式的假设示例，不代表某个真实项目或实测结果。

怎样限定修改文件、功能范围和不能动的部分？

如果已经知道相关文件，直接给出路径通常更省沟通。例如可以写“重点检查 @src/components/LoginForm.tsx，并参考 @src/styles/forms.css”。官方提示也建议在已知相关文件时用路径提供上下文，Claude Code 可以据此聚焦查看，而不必让它从模糊描述中猜测入口。

如果不知道具体文件，不要为了显得精确而编一个路径。可以要求它先查看项目中与问题有关的实现，列出准备修改的位置和理由，待你确认后再编辑。若任务只涉及某项行为，也把不在范围内的内容写明，例如“只调整提交后的错误反馈，不重新设计页面，也不改认证接口”。

“不要影响其他功能”通常太宽泛，因为双方可能对“其他功能”理解不同。把它改成可核对的约束会更有效：保留现有函数签名；不增加依赖；不修改服务端响应字段；只处理表单提交后的校验提示。约束越具体，后续检查改动是否越界就越容易。

怎样写验收条件，让修改结果有明确判断标准？

验收条件要写成“条件—操作—结果”，而不是只写抽象评价。比如“更友好”难以判断；“提交空邮箱后显示提示，且提示说明需要填写邮箱”则能直接检查。按修改内容挑选相关情形即可，不必为小改动罗列完整测试计划。

• 正常情形：常见输入或正常操作应出现什么结果？
• 边界情形：空值、格式错误或缺少必要信息时，应该怎样回应？只列与本次修改有关的情形。
• 保持项：哪些原有行为必须继续成立？例如既有接口参数不变，或不相关页面不受影响。

把必须条件和偏好分开也有帮助。“必须保留现有接口”是硬约束；“尽量沿用项目里已有的样式”是偏好。若两者有冲突，应让 Claude Code 先说明冲突并询问，而不是默默牺牲硬约束来满足偏好。对于暂时无法确认的环境或数据，也应明确写出限制，要求它指出哪些验收项尚未验证，而不是把未验证的结果描述成已完成。

需求还不够清楚时，应该让 Claude Code 先做什么？

当目标有多种解释，或做错会造成较大返工时，先不要让它直接编辑。可以要求：“先复述你对问题和预期结果的理解；列出会影响实现方向的未知点；在我确认之前不要修改文件。”这能把关键分歧暴露在改动发生之前。

不是所有未知细节都需要停下来问。如果只是项目里常见的命名风格，可以允许它参照相邻代码处理，并要求说明采用了什么假设。相反，涉及公开接口、数据结构、权限或删除数据等高影响选择时，不适合把决定权含糊地交出去。Anthropic 的官方指南建议，对涉及多个文件的大任务先规划、审查计划，再开始实施；这个做法也适合需求范围还需要确认的任务。官方提示习惯说明

如果项目约定总要重复说明，例如测试命令、命名习惯或禁止修改的目录，可以把稳定规则整理进项目的 CLAUDE.md。它适合保存可跨任务复用的背景，不适合代替当前任务的具体目标和验收条件。单次修改仍应在当次请求里写清楚，避免把“项目一贯如此”和“这次要做什么”混在一起。CLAUDE.md 与提示建议

怎样判断修改结果符合原始需求？

修改完成后，回到最初的需求逐条对照：目标行为是否出现、明确的限制是否遵守、有没有额外改动。可以要求 Claude Code 简要说明修改了哪些位置、对应满足了哪些条件，以及哪些内容尚未验证。这样做是为了方便你检查是否偏题，并不等于可以跳过代码审查或项目自身的验证流程。

如果发现结果不符，直接引用具体条件指出偏差，比重新发送“再改好一点”更清楚。例如：“你改动了登录接口参数，这与‘保留现有接口’冲突。请撤回这部分接口变化，只调整前端的空邮箱提示。”指出错误行为和必须保留的部分，有助于把下一轮修改限制在真正的问题上。

哪些修改需求不适合一次性交给 Claude Code？

当任务同时牵涉多个模块、规则互相冲突，或可能影响生产数据和权限时，先拆分并确认方向更稳妥。可以先让 Claude Code 检查现状、整理受影响范围和待确认问题；确认方案后，再给出边界清晰的实施任务。不要用一句“把整个系统整理好”代替可检查的工作范围。

核心做法可以记成一句话：说清楚要改变的结果、允许触及的范围、必须保留的内容，以及如何判断完成；对关键歧义先提问，对大范围改动先看计划。这样写 Claude Code 修改需求，通常比堆很多技术术语或规定每一步操作更容易对齐预期。

本文依据 Anthropic 帮助中心关于 Claude Code 提示方式与项目上下文的资料整理；相关页面核查日期：2026年10月9日。