Claude Code 小项目常见错误

新手用 Claude Code 接小项目时，最容易犯的错是把“客户说简单”当成“任务真的简单”。工具能帮你读代码，但不能替你承担模糊范围、高权限风险和无验收交付。小项目要小在范围上，不是小在客户的感觉上。

这篇适合搭配 Claude Code 小项目任务检查清单 和 Claude Code 交付说明检查清单 使用。

适合谁

适合已经开始接页面小改、报错诊断、配置解释、文档整理的小单，但经常被客户追加需求的新手。

也适合准备建立报价模板的人。先知道常见错误，报价时就能少踩坑。

不适合谁

不适合高风险生产任务。涉及真实数据、付款、账号权限、数据库、安全事件时，不能按普通小项目处理。

也不适合客户不给复现、不给环境、不给验收，却要求你保证结果的任务。

具体步骤

错误一：把模糊需求当小项目。客户说“帮我优化一下”，这不是范围。要先拆成一个明确目标。

错误二：不问权限。页面小改可能背后牵涉登录、接口、数据库、付款。权限不清，就不要接完整修复。

错误三：没有验收方式。没有验收，小项目会变成“你再看看”。验收动作必须提前写。

错误四：把诊断写成修复。你只是确认可能原因，就不要写“已修好”。诊断和修复要分开。

错误五：顺手改太多。Claude Code 可能建议多个优化点，但本次只处理客户确认的目标。

错误六：接成长期维护。客户后续一直问新问题，不代表都包含在原单里。

修正模板

这个任务可以先拆成一个小范围诊断。请确认一个明确目标、复现步骤、当前环境、权限边界和验收方式。确认后我再判断是否适合小范围修复。

这段话能把节奏从“马上修”拉回“先确认”。

改写示例

不推荐写：“这个我可以全都帮你看看。”这句话听起来热心，但边界很危险。

更稳的写法是：“我可以先处理一个明确问题，例如 /pricing 页面按钮跳转异常。本次不包含全站检查、生产部署和长期维护；如果还有其他问题，我们可以单独确认。”

这段话不会吓跑客户，反而让任务更清楚。

复盘问题

每次返工后，问自己：一开始有没有写清目标？有没有问权限？有没有写未覆盖范围？客户追加的内容是否其实是新需求？

把答案写进下一次模板。小项目的能力，很多时候来自这些复盘，而不是来自一次性写很多代码。

什么时候暂停

如果客户的需求从一个页面变成多个页面，从一个报错变成整个项目，从文档整理变成长期维护，就先暂停。暂停不是拒绝，而是重新确认范围。

可以回复：“这个已经超出本次小任务范围，我可以先整理新的范围和报价。”这种表达比沉默加班更专业，也更能保护交付质量。

交付前自检

发交付说明前，问自己三件事：客户能否看懂我做了什么？客户能否按步骤验收？客户能否知道哪些内容没有做？如果三件事有一件不清楚，就继续改说明。

Claude Code 可以帮你生成总结，但最终发给客户的版本要由你删减和确认。

错误报价示例

不推荐写：“我可以帮你把这个项目处理好。”这句话没有范围，也没有验收标准。客户听起来舒服，但后续会把很多问题都算进来。

更稳的报价是：“本次先诊断一个构建报错，交付错误原因、已运行检查、下一步建议；不包含生产部署、环境变量修改和长期维护。”这句话把结果和边界都放在明面上。

客户催促时怎么回

客户越急，越要先问清楚。可以回复：“我可以尽快看，但需要先确认复现步骤和权限边界，否则容易误判。”这不是拖慢，而是避免无效修复。

如果客户不愿补信息，就只适合做有限诊断，不适合承诺修复。

风险提醒

不要因为 Claude Code 给了很多建议，就全部加入本次交付。建议可以记录，范围必须确认。

不要承诺收入、效果或长期结果。你能承诺的是本次范围内的诊断、修改和验证。

免责声明

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

CTA：接小单前先用 小项目任务检查清单 过一遍；需要客户版回复时，用 /tools/proposal-generator 起草后人工复核。