Claude Code 常用命令检查清单

使用 Claude Code 接代码小单时，命令不是越多越好。你需要先判断命令的用途和风险：它是只读取信息，还是会修改文件；是在本地测试，还是会影响客户环境；是可以马上运行，还是必须先问客户授权。

建议先读 Claude Code 新手常用命令怎么整理成项目笔记，再搭配 客户问题检查清单 和 /templates 使用。

适合谁

适合已经能看懂基础命令，但还不确定哪些命令适合在客户项目里运行的新手。你需要一个固定清单，帮助自己在执行前停一下。

也适合准备写交付说明的人。命令检查清楚后，交付说明能更具体：运行了什么、发现了什么、没有覆盖什么。

不适合谁

不适合没有客户授权就处理生产环境的任务。任何涉及真实数据、密钥、后台、付款、环境变量和数据库的命令，都不能只靠清单决定。

也不适合把高风险命令包装成普通排查动作。删除、重置、迁移、部署、清空缓存这类命令，需要更严格确认。

具体步骤

1. 命令是否只读？如果只是查看文件、搜索文本、查看 git 状态，通常适合先运行。
2. 命令是否会修改文件？格式化、生成代码、安装依赖、更新 lockfile 都要标记。
3. 命令是否会联网？安装依赖、调用接口、拉取远程资源，都要确认网络和隐私风险。
4. 命令是否会影响客户环境？部署、数据库、环境变量、后台配置都要单独确认授权。
5. 命令是否可回滚？如果运行后不好恢复，就不要在小单里轻易执行。
6. 命令输出是否含敏感信息？如果含有密钥、账号、真实用户资料，要先脱敏再记录。
7. 命令失败后下一步是什么？不要因为失败就连续乱试，要先读错误原文。
8. 命令成功是否能证明问题解决？成功构建不等于业务流程一定可用，还要看验收方式。
9. 是否需要截图或日志作为交付证据？需要的话提前保存脱敏版本。
10. 是否写进任务笔记？没有记录的排查，很难向客户解释。

四类命令表

只读：查看文件、搜索关键词、查看状态
本地验证：lint、test、build、dev server
会改文件：format、generate、install、update lockfile
高风险：deploy、migration、reset、delete、env change

这张表不是让你背命令，而是让你先分风险。Claude Code 建议任何命令时，都可以先问一句：这条命令属于哪一类？

客户沟通写法

如果你需要运行本地验证命令，可以告诉客户：“我会先在本地或测试环境运行构建和基础检查，不处理真实数据，也不进入生产后台。”这句话能把权限边界讲清楚。

如果客户要求你运行高风险命令，可以回复：“这一步可能影响环境状态，需要你确认授权、备份和回滚方式。”不要让对方以为命令只是点一下。

检查后怎么分类

跑完清单后，把任务分成三类。第一类是可以继续的小范围任务，例如一个明确报错、一个配置问题、一个本地构建失败。第二类是只能先诊断的任务，例如缺少环境变量、缺少测试账号、缺少复现步骤。第三类是暂不处理的任务，例如生产数据、付款后台、数据库迁移和无法授权的环境操作。

这三类判断要写给客户看。新手最怕的是心里知道风险，但回复里没有写出来。只要回复含糊，客户就可能默认你已经接下全部结果。

命令记录示例

已运行：npm run build
环境：本地
结果：失败
关键错误：缺少 NEXT_PUBLIC_ 开头的测试配置
判断：当前不适合承诺修复，需要客户确认测试环境变量
未执行：部署、数据库、生产后台相关命令

这种记录既能帮助你继续和 Claude Code 讨论，也能直接改写成客户交付说明。它比完整复制终端输出更安全。

风险提醒

不要把命令输出原样发到公共聊天或第三方工具。日志里可能有路径、账号、token 片段或内部域名。

不要在不清楚项目状态时运行删除、重置或迁移命令。项目小项目也需要最小权限和可回滚思路。

免责声明

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

CTA：把这份检查清单放进 /templates 的任务记录里；需要向客户解释排查流程时，用 /tools/proposal-generator 起草回复。