Claude Code 新手使用检查清单

Claude Code 能帮你更快读代码和修改文件，但新手不能把它当成最终审核人。真正可靠的工作流要包含：读上下文、确认范围、查看 diff、运行检查、写交付说明。缺少其中任何一环，都可能把一个小任务变成难以解释的返工。

建议先读 Claude Code 新手最容易犯的错误，再配合 ChatGPT、Codex 和 Claude 工作流 与 /templates 使用。

适合谁

适合刚开始用 Claude Code 辅助处理小型代码任务的新手。你可以还不熟悉大型项目，但要愿意按步骤确认，不把模型输出直接当成最终答案。

也适合准备做项目前自检的人。客户看不到你使用了什么工具，但能看到你是否按范围交付、是否能解释修改、是否保留测试证据。

不适合谁

不适合需要高权限生产操作的任务。涉及客户生产数据库、付款、密钥、真实用户隐私和安全漏洞时，不应该只靠这份清单处理。

也不适合没有测试环境的复杂任务。如果无法复现问题、无法运行项目、无法看日志，新手最好先报价为诊断，而不是直接承诺完整修复。

具体步骤

1. 是否保存客户原始需求？不要只保存模型总结后的版本。
2. 是否脱敏？客户账号、密钥、订单、后台链接、合同内容是否删除或替换。
3. 是否读仓库结构？了解框架、入口、脚本、组件位置和现有风格。
4. 是否明确目标文件？不要让工具大范围探索后直接改很多文件。
5. 是否把任务缩小到可验证范围？一个任务只解决一个主要问题。
6. 是否在修改前看 git status？确认没有无关脏改动。
7. 是否在修改后看 git diff？确认改动范围、逻辑和敏感信息。
8. 是否运行检查？根据项目选择 lint、build、测试、内容检查或页面手测。
9. 是否记录失败尝试？失败命令和错误信息有助于交付说明。
10. 是否写清未覆盖范围？例如不包含生产部署、不包含真实数据验证、不包含长期监控。

交付前自问

如果客户问“你改了哪里”，你能否用一两句话说明？如果客户问“怎么确认好了”，你能否给出测试证据？如果客户要求继续改相邻问题，你能否判断是否属于新增范围？

如果答案不清楚，就先补记录。Claude Code 可以帮你生成说明草稿，但你要把真实命令、真实文件、真实测试结果写进去。

风险提醒

不要把 .env、密钥、私有配置、客户后台截图直接交给工具处理。需要描述问题时，使用占位符和脱敏片段。任何完整凭据都不应进入聊天记录、提交记录或截图。

不要因为工具建议“顺便优化”就扩大任务。新手项目练习最稳的是小范围交付：客户要求修一个问题，你先把这个问题修清楚，再把额外建议列为后续可选项。

复盘记录

任务目标：
涉及文件：
Claude Code 帮助：
人工判断：
运行检查：
交付说明：
未覆盖范围：

保留这份记录，能帮你下次更快报价和判断风险。几次之后，你会知道哪些问题适合用工具快速处理，哪些问题必须先请人复核。

发送客户前检查

发送交付消息前，再问三件事：客户能否按我的说明复现结果？客户是否知道哪些内容不在本次范围内？如果客户把这份说明转给其他人，对方能否看懂我做了什么？

如果答案不清楚，就补一句验收步骤或未覆盖范围。很多返工不是代码问题，而是交付说明太模糊。清楚的说明能保护你，也能帮助客户更快确认。

什么时候只做诊断

如果项目不能启动、客户不给错误信息、没有测试环境、需要生产权限，建议先做诊断。诊断交付可以包括：已知信息、缺失信息、可能原因、建议客户提供的材料、是否适合继续修复。

诊断不是退缩。对新手来说，能判断“现在不能直接修”，比盲目接下高风险任务更专业。

免责声明

本文仅供学习和流程整理参考，不构成安全、法律、财务或平台合规建议。不同项目和平台规则不同，发布前需要人工复核。客户项目应遵守授权范围、脱敏记录和最小权限原则。

CTA：把这份清单复制到项目笔记里；需要交付模板时去 /templates，需要解释报错时用 /tools/error-explainer，最后以实际测试结果决定能否交付。