AI 生成 Proposal 发布前检查清单

AI 生成 proposal 很快，但发出去之前必须检查。新手最容易犯的错误，是把 AI 写出的流畅英文当成最终回复。真正有效的 proposal 要具体回应客户需求、说明你能做什么、问清必要信息，并且不泄露客户资料、不承诺无法验证的结果。

这份清单适合在发送前最后过一遍。建议先读 ChatGPT 和 Claude 写 Proposal 有什么区别，再搭配 /tools/proposal-generator、/templates 和 第一次 AI 工具实践检查清单 使用。

适合谁

适合已经用 ChatGPT、Claude 或其他工具生成了 proposal 草稿，准备投递给客户的新手。你可能只是想让英文更自然，但仍需要人工确认内容是否真实、范围是否稳妥。

也适合准备建立固定投标流程的人。清单会提醒你不要只检查语法，还要检查客户需求、交付边界、平台规则和隐私安全。

不适合谁

不适合想批量复制同一份 proposal 的人。客户需求不同，平台规则不同，项目风险也不同。完全通用的回复通常很空泛，也容易让客户觉得你没有认真读需求。

也不适合用 AI 编造经历的人。没有真实案例时，可以写练习项目和可展示作品，不能把不存在的客户结果写进 proposal。

具体步骤

1. 是否回应了客户具体问题？第一段最好提到客户任务里的关键词，而不是只写自我介绍。
2. 是否写清可交付范围？例如诊断、修改、文档、测试记录，而不是笼统说“我能完成”。
3. 是否删除过度承诺？避免保证成交、保证增长、保证平台通过、保证复杂系统完全稳定。
4. 是否提出必要问题？链接、截图、环境、素材、验收标准、截止时间至少确认关键几项。
5. 是否真实描述能力？不会的部分不要包装成会，可以写“我会先确认范围再报价”。
6. 是否检查平台规则？不要诱导客户跳开平台正常流程，也不要写不符合平台要求的沟通方式。
7. 是否完成隐私脱敏？客户资料、截图、账号、合同、密钥和未授权素材不应进入草稿。
8. 是否语气自然？删掉过度模板化、夸张热情和明显 AI 腔的句子。
9. 是否包含下一步？告诉客户你需要什么信息，或你会如何开始。
10. 是否人工通读一遍？发送前自己读出声，确认每一句都能负责。

快速修改模板

AI 初稿问题：
- 太空泛：
- 过度承诺：
- 没有回应客户细节：
- 没有追问必要信息：

人工修改后：
- 客户问题：
- 我的可交付范围：
- 需要客户确认：
- 验收方式：

这个模板能帮你从“AI 写得像英文”转成“客户看得懂、范围清楚、可继续沟通”的 proposal。

风险提醒

不要把客户完整需求、合同、账号截图或敏感材料复制给多个 AI 工具，只为了得到更漂亮的回复。写 proposal 往往只需要脱敏后的任务摘要和关键约束。

不要为了提高中标概率就夸大能力。第一次项目更重要的是建立可信记录。一个诚实、具体、范围清楚的 proposal，长期看比夸张模板更有价值。

发送前自问

如果客户马上回复“你具体怎么做”，你能不能解释？如果客户要求你立刻报价，你是否已经知道范围？如果客户把这份 proposal 当成承诺，你是否愿意承担里面每一句话？

如果答案不确定，就先不要发送。回到需求，删掉不确定承诺，补上必要问题。proposal 的速度可以快，但边界不能糊。

发送后记录

发送后建议记录四项：客户类型、项目关键词、你使用的 proposal 结构、客户是否回复。不要只保存 AI 初稿，因为初稿通常不是最终发送版本。保存人工修改后的版本，才方便复盘。

如果客户没有回复，也不一定说明工具不好。可能是预算、竞争、平台排序、客户状态或项目本身不合适。复盘时重点看自己能控制的部分：是否具体、是否真实、是否问了必要问题、是否让客户容易继续对话。

常见修改方向

如果 proposal 太长，删掉泛泛自我介绍，保留客户问题、可交付范围和必要问题。如果 proposal 太像模板，在第一段加入客户需求里的具体词。如果 proposal 太强势，把“我会完成全部”改成“我会先确认范围，再处理约定部分”。

如果 proposal 太弱，只说“我可以试试”，客户也很难信任。更稳的写法是：我可以处理某个明确范围，并会用某种方式验证结果。新手不需要夸大，但要让客户看到你有流程。

免责声明

本文仅供学习和写作流程参考，不构成职业、财务、法律或平台合规建议。不同平台规则和客户要求可能变化，发布前需要人工复核。AI 生成内容必须经过人工检查，发送者需自行承担沟通和交付责任。

CTA：发送前先用这份清单检查，再用 /tools/proposal-generator 生成备选版本；需要固定问题清单时去 /templates，最后人工改到真实项目范围。