Claude Code Proposal 审阅检查清单

发送 proposal 前，先检查它是不是清楚、克制、可交付。Claude Code 可以帮你找逻辑漏洞，但不能替你判断平台规则、客户授权和真实交付能力。清单的目标是减少过度承诺和范围不清。

建议先读 用 Claude Code 审阅项目 Proposal 时要看什么，再搭配 Claude Code 低风险项目检查清单 和 /tools/proposal-generator 使用。

适合谁

适合已经写好 proposal 初稿，准备发送给客户的新手。你需要在发送前确认范围、风险、验收和语气。

也适合客户需求不清楚时使用。清单会提醒你先追问，而不是直接报价完整修复。

不适合谁

不适合把客户原始敏感信息直接放进工具审阅。客户内容、账号、日志和平台消息都要先脱敏。

也不适合用来包装夸张承诺。proposal 应该帮助客户理解范围，而不是制造不现实期待。

具体步骤

1. 是否复述客户问题？开头要说明你理解的是哪个问题。
2. 是否只承诺一个明确范围？不要写“全部解决”。
3. 是否写清交付物？诊断、修改、说明、截图、测试结果要分清。
4. 是否写清未覆盖范围？生产、账号、付款、真实数据、长期维护默认排除。
5. 是否有验证方式？build、lint、截图、测试环境或客户手动验收。
6. 是否需要追问？信息不足时先问，不直接报价。
7. 是否去掉敏感信息？日志、token、账号、内部链接要脱敏。
8. 是否避免夸张表达？不要写固定结果、无限返工或不现实承诺。
9. 是否符合平台沟通边界？不要引导客户绕开平台规则。
10. 是否由人工复核？工具建议不能直接发送。

审阅结果分类

可以发送：范围清楚、低权限、验证方式明确、无敏感信息、无夸大承诺。

需要修改：范围不清、语气太满、缺少验收、缺少未覆盖范围。

暂不发送：客户信息不足、涉及敏感权限、平台规则不清、需要注册或授权操作。

可复制审阅提示

请审阅这段 proposal，重点找：
- 范围不清
- 过度承诺
- 缺少验收方式
- 敏感信息
- 需要追问客户的地方
不要新增夸张承诺或平台外沟通建议。

审阅后只采纳你能兑现的建议。不要为了显得专业而增加自己做不到的服务。

发送前最后一遍

发送前问自己三件事：客户能否看懂我做什么？客户能否知道不包含什么？客户能否按步骤验收？如果三件事不清楚，继续改。

还要看语气是否像一个可交付的人，而不是像广告。简单、具体、边界清楚，通常比长篇自夸更有效。

修改记录模板

原 proposal 问题：
必须修改：
可选优化：
需要追问客户：
最终保留承诺：
未覆盖范围：

这份记录不一定发给客户，但能帮助你复盘。下次再写 proposal，就知道自己最容易漏哪一项。

客户追问模板

为了避免范围不清，我需要先确认：复现步骤、错误原文、当前环境、是否涉及账号或真实数据、以及你希望怎样验收。确认后我再给出诊断或修复范围。

信息不足时，追问比报价更专业。

验收边界

Proposal 里也可以写验收边界。比如“诊断交付为错误原因和下一步建议”，或者“修复交付为一个明确问题的修改摘要和本地验证结果”。客户知道验收什么，后面就不容易扩成无限支持。

如果你无法写出验收边界，说明 proposal 还不能发。

复核例子

不清楚的写法是：“我可以帮你看看并优化项目。”清楚的写法是：“我可以先诊断你提供的一个构建报错，交付可能原因和下一步材料，不包含生产部署和长期维护。”

发送前把自己的 proposal 改成第二种句式。它不华丽，但客户能判断是否要继续。

风险提醒

不要让 Claude Code 替你决定报价和责任边界。工具能改文字，不能承担后果。

不要用 proposal 承诺收益、排名、长期稳定或所有问题都解决。只写本次范围内可验证内容。

免责声明

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

CTA：发送前用这份清单复核；需要初稿时用 /tools/proposal-generator，需要范围模板时去 /templates。