Claude Code Proposal 审阅哪些适合写进项目范围

Proposal 审阅可以成为低风险服务，但范围要写清楚。适合写进范围的是结构检查、范围检查、风险提示、追问问题、语气修改和交付建议。不适合默认承诺的是成交结果、收益、平台外沟通、无限修改和客户项目成功。

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

适合谁

适合想帮自己或客户复核 proposal 的新手。你可以检查文案是否清楚、范围是否合理、风险是否写明，但不能承诺 proposal 一定带来结果。

也适合把 proposal 审阅做成小服务的人。它低权限、低技术风险，但仍然需要平台规则和人工复核。

不适合谁

不适合承诺成交、承诺收益、承诺排名、承诺客户一定回复的服务。proposal 审阅只能改进表达，不能控制客户决策。

也不适合处理未脱敏的客户资料、平台消息、账号信息和敏感项目细节。

具体步骤

第一，基础范围可以包含结构检查。看 proposal 是否有客户问题、服务范围、验证方式、下一步。

第二，基础范围可以包含风险检查。找出过度承诺、敏感信息、平台规则风险和未覆盖范围缺失。

第三，基础范围可以包含追问问题。客户信息不足时，列出需要补充的材料，而不是硬写报价。

第四，基础范围可以包含语气修改。让表达更具体、更克制、更容易理解。

第五，不包含成交承诺、平台外沟通建议、无限修改、客户项目实际交付和长期运营结果。

报价范围示例

本次包含：
- 审阅一段 proposal 初稿
- 检查范围、风险和验收表达
- 提出修改建议
- 给出一版更清楚的回复草稿

不包含：
- 承诺成交
- 承诺收益
- 平台外沟通建议
- 无限修改
- 客户项目实际交付

这段可以直接放进服务描述，避免客户误解 proposal 审阅的价值边界。

交付物怎么写

交付物可以是一份审阅意见、一版修改稿、一组追问问题和一段风险提醒。交付时要说明“这是文案和范围审阅，不代表结果保证”。

如果客户要求你代发、代聊、代管账号或处理平台规则相关事项，就要暂停并重新确认边界。新手不应接收账号控制权。

客户确认话术

我可以帮你审阅 proposal 的结构、范围和风险表达。本次不承诺成交结果，不处理账号或平台外沟通，也不代替你发送。最终内容需要你人工确认后再使用。

这句话适合放在服务开始前，既专业又安全。

服务档位怎么拆

基础档可以只做审阅意见：指出范围不清、过度承诺、缺少验收和需要追问的问题。标准档可以给一版修改稿。进阶档可以整理一套可复用 proposal 模板。

不管哪一档，都不应包含成交承诺、账号代管、代发消息或平台规则规避。服务越清楚，客户越容易理解它的价值。

交付记录怎么写

交付时可以写：“已完成 proposal 审阅，指出三处范围风险、两处需要追问客户的问题，并提供一版低承诺修改稿。最终发送前仍需你按平台规则人工确认。”

这类记录让审阅服务有明确产出，而不是只说“我帮你润色了”。

追加服务边界

如果客户要求多轮修改、代写完整模板库、陪聊客户、代发消息或分析平台规则，这些都属于追加服务。可以继续做范围讨论，但不能默认包含在一次 proposal 审阅里。

追加服务也要写清交付物。比如只交付模板，不承诺成交；只交付风险建议，不代替法律或平台规则判断。

风险提醒

不要把 proposal 审阅服务包装成“提高收入保证”。它只能帮助表达更清楚，不能保证客户选择你。

不要让工具替你判断平台规则。平台规则变化时，需要人工复核。

免责声明

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

CTA：做 proposal 审阅前用 /templates 写清服务范围；需要初稿时用 /tools/proposal-generator，再人工复核。