Claude Code 项目前怎么判断范围

Claude Code 能提高代码阅读和修改效率，但不能把所有代码需求都变成适合新手的小单。项目前要先判断四件事：问题能否复现、权限是否安全、修改范围是否清楚、测试证据是否能提供。如果这四点不清楚，最好先做诊断，不要直接承诺修复。

适合谁

适合准备承接小型前端 bug、配置问题、部署失败、文档整理、轻量脚本修改的新手。这些任务通常能在本地或测试环境复现，也能通过构建、截图、日志或交付说明验收。

也适合已经能使用 Claude Code 读仓库，但还不确定如何报价的人。项目范围越清楚，工具越能发挥作用；范围越模糊，工具越容易把你带进无关改动。

不适合客户要求你直接处理生产数据库、支付、密钥、真实用户数据、管理员后台或安全漏洞的情况。这类任务需要明确授权、专业复核和更严格流程。

也不适合客户没有提供任何复现信息，却要求你保证修好的情况。没有错误信息、触发路径、运行环境和验收标准，就只能先诊断，不能承诺结果。

第一步，确认问题是否可复现。让客户提供触发路径、截图、错误信息、预期结果和实际结果。如果无法复现，先把交付定义为“诊断报告”。

第二步，确认权限边界。客户是否需要你接触账号、密钥、生产环境或私有数据？如果需要，优先建议使用测试环境、脱敏日志、临时权限和客户自行操作。

第三步，确认修改范围。写清本次只处理哪个页面、哪个报错、哪个配置或哪个组件。不包含新功能、重构、长期维护和无关问题。

第四步，确认测试方式。修完后用什么证明？本地构建、lint、页面截图、测试数据、部署预览、客户验收步骤，都可以成为证据。

第五步，确认交付说明。交付时要写清做了什么、怎么验证、哪些事项需要客户自己确认。不要只发一句“已修复”。

适合新手的范围包括：修一个明确报错、调整一个页面样式、解释一段构建失败、整理一份安装步骤、补充一段配置说明、在测试环境验证一个小流程。这些任务都可以被拆成步骤，并留下证据。

不建议新手一开始接“重做整个系统”“优化全部性能”“接管线上部署”“解决所有安全问题”这类任务。范围越大，风险越不适合用第一次项目来练。

不要因为有 Claude Code 就低估责任。客户项目出问题时，客户不会接受“工具建议这样做”作为解释。你需要能说明自己的判断、修改和测试。

不要把客户资料复制到多个工具里求稳。真正的稳来自脱敏、最小权限、测试环境和可复查记录，而不是让更多模型看同一份敏感材料。

信息不完整时，可以先报诊断范围。例如“我先检查错误信息、项目结构和复现条件，交付一份排查记录；确认是小范围问题后，再报价修复”。这样可以避免客户把一个复杂系统问题压缩成一个低价小单。

如果已经确认是小范围修复，可以把报价写成“一个明确问题、一次交付说明、一次小修改”。不要把长期维护、生产部署、账号授权、性能优化和新增功能都默认包含进去。

为了判断是否适合我处理，请先确认：
1. 这个问题在哪个页面或命令下出现？
2. 是否有错误截图或日志？
3. 本地、测试环境和线上是否都能复现？
4. 是否涉及密钥、付款、生产数据或管理员权限？
5. 你希望怎样验收完成结果？

如果客户能回答这些问题，任务通常更容易判断。如果客户无法提供，你可以先做诊断，而不是直接承诺修复。

本文仅供学习和项目流程参考，不构成安全、法律、财务或平台合规建议。Claude Code 功能、平台规则和客户项目要求可能变化，发布前需要人工复核。项目前请确认授权范围、测试方式和交付边界。

CTA：回复客户前，先用 /tools/proposal-generator 起草范围说明，再用 /templates 的需求确认表补齐复现信息、权限边界和验收方式。