Claude Code 小项目任务检查清单

小项目不是“看起来很小”，而是目标明确、权限低、可复现、可验证、可验收。用 Claude Code 项目前，先用清单判断任务是否真的适合新手。清单过不了，就先做诊断或暂不承接。

建议先读 哪些小项目任务适合用 Claude Code 辅助项目，再搭配 Claude Code 项目客户问题检查清单 和 /templates 使用。

适合谁

适合准备接页面小改、报错诊断、配置说明、文件检查、交付文档这类低风险任务的新手。

也适合报价前复核。客户说“很简单”不算证据，清单过关才算小任务。

不适合谁

不适合生产事故、真实数据、付款流程、账号权限、数据库、长期维护、全站重构和安全事件。

也不适合客户拒绝补充复现步骤、错误原文、测试环境和验收方式的任务。

具体步骤

1. 任务目标是否只有一个？如果有多个目标，先拆分。
2. 是否有复现步骤？没有复现，只能先诊断。
3. 是否有错误原文或截图？截图需要脱敏，最好有可复制文字。
4. 是否低权限？不碰生产数据、后台、付款和管理员权限。
5. 是否有测试环境？本地、测试、预览、生产要分清。
6. 是否能验证？lint、build、页面预览、截图或客户手动流程。
7. 是否能写交付说明？做了什么、没做什么、怎么验收。
8. 是否排除长期维护？小单不是持续值守。
9. 是否会影响多个模块？影响大就不再是小项目。
10. 是否需要客户补材料？缺材料时先收集，不急报价。

判断结果

如果十项里大部分清楚，可以进入小范围报价。如果关键项缺失，比如复现、权限、验收不清楚，就先做诊断。如果涉及高权限或生产影响，就不要按普通小单处理。

判断结果要写给客户看。比如：“当前信息适合先做诊断，还不足以承诺完整修复。”这比直接报价更稳。

客户确认模板

我可以先判断这个任务是否适合小范围处理。请确认：
- 一个明确目标
- 复现步骤或错误原文
- 当前环境
- 是否涉及账号、付款、真实数据或管理员权限
- 修完后怎样验收

这个模板能把“帮我看看”变成可判断范围。

交付记录模板

任务目标：
处理范围：
验证结果：
未覆盖范围：
客户验收：
后续建议：

即使是小任务，也要留下交付记录。记录越清楚，后续追加需求越容易重新确认。

报价前最后判断

报价前用一句话描述任务。如果这句话写不出来，说明范围还不清楚。例如“修复 /pricing 页面按钮跳转错误”是小任务；“优化网站体验”不是小任务。

再看是否能写出验收方式。如果验收方式只能写“你看看”，说明还需要继续问客户。能写成“打开哪个页面、运行哪个命令、看到什么结果”，才适合继续。

追加需求处理

客户追加第二个问题时，不要直接塞进原单。可以回复：“这个属于新的目标，我可以继续处理，但需要重新确认范围和验收方式。”语气可以温和，边界要清楚。

这样不会显得计较，反而能让客户知道你的服务是按明确交付来组织的。

可接和不可接示例

可接示例：修改一个页面按钮文案、解释一个构建错误、补一段 README 安装说明、检查一个 GitHub 文件的明显逻辑问题。这些任务目标单一，容易验证。

不可接示例：修好整个网站、提升所有页面性能、长期盯线上错误、接管客户账号、处理真实订单数据。这些范围太大，也超出普通小单的权限边界。

最小交付标准

每个小任务至少要交付三样东西：处理结果、验证方式、未覆盖范围。缺少任何一项，都容易让客户继续追问。

如果你只做诊断，处理结果就是诊断结论；如果做了修改，处理结果就是修改摘要。两者不要混写。

风险提醒

不要把小项目写成“包修所有问题”。一个小任务只覆盖一个明确目标。

不要把客户的主观判断当成技术范围。客户说简单，不代表权限、测试和交付都简单。

免责声明

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

CTA：报价前把这份清单放进 /templates；需要客户确认话术时，用 /tools/proposal-generator 起草后人工复核。