Claude Code 审阅 Proposal 时的常见错误

Claude Code 能帮你改 proposal，但新手最容易把“文字更顺”误以为“可以发送”。Proposal 的核心不是漂亮，而是范围清楚、承诺可兑现、风险被排除、客户能验收。只要这些没写清，再流畅的文字也会带来后续返工。

这篇适合搭配 Claude Code Proposal 审阅检查清单 和 Claude Code 低风险项目检查清单 使用。

适合谁

适合已经会用 Claude Code 写回复，但经常不确定能不能直接发的新手。你需要先学会删掉过度承诺，而不是只让文字更好看。

也适合报价前复盘。proposal 错误通常在项目前就埋下了，交付后才爆发。

不适合谁

不适合把客户敏感信息原样贴进工具，也不适合让工具代替你判断平台规则和报价责任。

不适合客户需求明显不清楚时硬写报价。信息不足时，应该先追问。

具体步骤

错误一：直接发送 AI 初稿。工具生成的内容可能很顺，但不一定符合你的真实能力和平台规则。

错误二：写过度承诺。比如“保证解决”“全部修好”“长期支持”。这些表达很容易超出小单范围。

错误三：不写未覆盖范围。生产部署、账号权限、真实数据、付款流程、长期维护都不要默认包含。

错误四：不追问客户。客户没有复现、错误原文、验收方式时，proposal 应该先问问题。

错误五：暴露敏感信息。客户日志、内部链接、账号、token 片段要脱敏。

错误六：把诊断和修复混在一起。诊断是判断原因，修复是处理明确问题，两者报价和交付不同。

修正模板

我可以先做一轮低风险诊断，确认错误原因和下一步材料。当前信息还不足以承诺完整修复。本次不包含生产部署、真实数据、账号权限或长期维护。

这段比“我可以帮你修好”更稳，也更符合新手可交付能力。

改写示例

不推荐写：“我有丰富经验，可以快速解决你的所有问题。”这句话太空，也太满。

更稳的写法是：“我可以先检查你提供的构建报错和相关配置，交付错误原因、已排除方向和下一步建议。如果确认是低风险配置问题，再继续处理一个明确修复。”

复盘问题

发送 proposal 后，如果客户后续不断追加需求，回看初稿是否写了未覆盖范围。如果客户问“你不是说能修好吗”，回看是否写了过度承诺。

每次出问题，都把原因加进下一次审阅清单。Claude Code 可以帮你改文案，但边界模板要由你维护。

错误发送示例

不推荐写：“我可以马上开始，保证帮你解决，并且后续都可以继续支持。”这句话同时包含过度承诺和长期支持暗示。

更稳的写法是：“我可以先做一次低风险诊断，确认报错原因和下一步。当前范围不包含生产部署、真实数据、账号权限和长期维护。若适合继续修复，我们再确认下一段范围。”

什么时候撤回重写

如果你发现 proposal 已经写了你做不到的内容，宁愿重写，不要勉强发送。比如承诺了部署、长期维护、固定结果、多轮修改，但你没有确认成本和权限，就应撤回重写。

好 proposal 的核心是可执行，不是显得厉害。

复盘记录

可以记录四项：客户是否误解范围，是否要求追加服务，是否追问验收方式，是否因为信息不足来回沟通。每一项都能变成下一次 proposal 的检查点。

如果反复出现同一种问题，不要怪客户没理解，先改自己的模板。

停发条件

如果 proposal 里出现“全部、保证、长期、随时、都可以”这类词，先停下来检查。它们不一定都错，但很容易暗示超出范围的承诺。

如果客户信息不足，也先停发。追问客户比发一个漂亮但虚的报价更有用。

风险提醒

不要写任何你无法验证或无法承担的结果。Proposal 是承诺入口，不是营销海报。

不要用工具生成的热情语气覆盖事实不足。事实不足就追问，别硬夸能力。

免责声明

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

CTA：发送前用 Proposal 审阅检查清单 过一遍；需要初稿时用 /tools/proposal-generator，再人工删改。