用 Claude Code 审阅项目 Proposal 时要看什么

Proposal 不是越热情越好，也不是让 Claude Code 帮你堆一段漂亮话就能发。真正要审的是：客户问题有没有被理解，服务范围有没有写清，风险有没有排除，交付和验收是否具体，语气是否符合平台规则。Claude Code 可以帮你检查逻辑，但最终承诺必须由你负责。

这篇适合搭配 Claude Code 低风险项目检查清单、Claude Code 小项目任务检查清单、Claude Code 交付说明检查清单 和 /tools/proposal-generator 使用。

适合谁

适合已经写好 proposal 初稿，但不确定是否清楚、克制、可交付的新手。你可以让 Claude Code 帮你检查结构和风险，但不要让它替你承诺结果。

也适合客户需求模糊时使用。与其直接报价，不如先让工具帮你列出缺失信息和需要追问的问题。

不适合谁

不适合把客户隐私、平台站内消息、账号信息或敏感项目细节原样贴进工具。需要审阅时，应先脱敏。

也不适合让工具生成夸张承诺、固定收益、无限返工、长期维护或违反平台规则的沟通内容。proposal 应该写清本次范围，不是包装能力。

具体步骤

第一，检查客户问题是否被复述。proposal 开头应该能说明你理解了哪个具体问题，而不是泛泛说“我很有经验”。

第二，检查服务范围。写清本次做什么，例如诊断一个报错、检查一个文件、处理一个页面问题，而不是写“帮你解决所有问题”。

第三，检查未覆盖范围。生产部署、真实数据、账号权限、付款流程、长期维护、新增需求，都不要默认包含。

第四，检查验证方式。客户需要知道你会怎样确认结果，例如本地 build、脱敏日志、截图、测试环境验收或交付说明。

第五，检查追问问题。如果客户信息不足，proposal 不应该直接报价完整修复，而应该先提出需要补充的材料。

第六，检查语气。语气要具体、稳、低承诺，不要写“保证”“最快”“一定解决”这类难以兑现的话。

可复制审阅 Prompt

请帮我审阅这段项目 proposal。不要添加夸大承诺，不要建议平台外交易。
请检查：
1. 是否复述了客户问题
2. 是否写清服务范围
3. 是否写清未覆盖范围
4. 是否有验证或验收方式
5. 是否需要追问客户
6. 是否有过度承诺或敏感信息

把客户内容脱敏后再放入 prompt。审阅结果只能作为修改建议，最终发送前仍要人工复核。

proposal 改写示例

不推荐写：“我可以快速帮你全部修好。”这句话范围过大，也没有验收。

更稳的写法是：“我可以先诊断你提供的构建报错，整理可能原因和下一步材料；如果确认是低风险配置问题，再继续处理一个明确修复。此范围不包含生产部署和真实数据处理。”

审阅输出怎么用

Claude Code 的审阅输出可以分成三类：必须修改、可选优化、需要人工判断。必须修改通常是敏感信息、过度承诺和范围不清；可选优化是措辞更简洁；人工判断是报价、平台规则和客户关系。

不要把所有建议都塞进 proposal。proposal 越长，客户越难抓重点。保留能证明你理解问题和能交付的内容即可。

什么时候先不发送

如果客户需求缺少复现步骤、错误原文、测试环境或验收方式，就先不发送完整报价。可以发一段追问：“为了避免范围不清，我需要先确认这些材料。”

如果 proposal 里出现账号、真实数据、付款、生产部署或平台规则不确定内容，也先暂停。先确认边界，再发送。

复盘字段怎么留

每次发送 proposal 后，记录客户是否回复、是否追加需求、是否误解范围、是否要求你做原本没有写的内容。下一次审阅时，把这些问题提前写进未覆盖范围。

这份复盘比单纯改文案更有价值。它会告诉你自己的 proposal 是哪里不清楚，而不是只告诉你哪里不够好听。

风险提醒

不要把 Claude Code 生成的 proposal 原样发送。工具可能忽略平台规则、客户上下文或你的真实能力。

不要把 proposal 写成结果保证。项目沟通应基于当前信息和可验证范围，而不是绝对承诺。

免责声明

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

CTA：写 proposal 前先用 /templates 补齐范围；需要初稿时用 /tools/proposal-generator，再用本文清单人工复核。