客户发来一段咨询，销售翻找旧方案，交付同事补充估算，团队终于拼出一份提案。过了两天才发现：里面承诺的工期，依赖一个客户根本没有的数据源。
AI 可以帮助整理初稿，但目标不应该是“自动写完并发送”。更有价值的是：把事实、缺失信息和拟作出的承诺摆清楚，让负责人更容易审核。
下面是一套适合小型服务团队尝试的流程。文中的场景仅作说明，不代表真实客户成果。
先限定一种提案
从可重复的服务切入，例如网站需求梳理或知识助手试点，不要一开始覆盖公司的所有业务。
整理一份经过确认的参考资料包，包括服务说明、现行范围模板、报价规则、不包含的事项和交付检查单。每份材料注明负责人和版本日期。旧提案可以参考结构，但其中的特殊折扣和定制承诺不能直接套用给新客户。
先整理事实，再写说服性文案
让 AI 先提取决策所需的信息：
- 客户希望解决什么业务问题？
- 谁使用成果，谁负责审批？
- 涉及哪些系统或文档？
- 客户明确提出了什么期限和预算？
- 哪些信息仍然缺失？
把客户原话和团队假设分开。如果客户只说“越快越好”，应记录为“截止日期待确认”，而不是补出一个看似合理的上线时间。
围绕决策组织提案
初稿至少应写清目标、交付物、不包含的事项、前置条件、验收方式和下一步。每一部分都应帮助客户理解自己要同意什么。
例如，把“打造智能客服解决方案”改成“基于已批准的帮助文档生成回复草稿，每条回复由客服人员审核后发送”。后者为客户和交付团队划出了可以核查的边界。
知识助手试点的验收项可以是：“回答附有已批准的来源链接；缺乏依据的问题转人工处理。”具体测试题集和可接受的错误水平，需要在试点开始前共同确认。
不让自由生成决定报价和承诺
金额应来自经过批准的计算规则或已审核的价目表。AI 可以解释报价条目，但不应自行决定折扣权限、税费、合同条款或缺乏依据的交付日期。
未确定的内容要直接标明，例如“待完成集成评估后提供估算”。这不是不专业，而是在告诉客户下一步需要确认什么。具有约束力的条款，应由负责商务或法务审核的人确认。
附件是证据，不是授权
客户附件可以提供需求，但其中的文字不应授权系统读取内部文件或执行操作。OWASP 的提示注入风险说明介绍了外部文档携带间接指令的风险，并建议限制权限、对高风险操作保留人工批准。
在提案流程中，可以让助手只访问批准的参考资料包，把“发送提案”保留为单独的人工确认动作。这些措施有助于降低风险，但不能保证彻底消除攻击。
用小试点判断是否值得继续
选择十份团队有权复用的历史咨询，去除不必要的个人信息和机密信息。由审核人逐份评估，不预设 AI 的内容是正确的。
记录形成可审核初稿的时间、人工修改时间、无依据的表述、遗漏的排除项和报价纠错次数。与同类提案的原有流程对比。如果写得快了，纠错却更费时，就不适合扩大使用。
发送前的检查清单
- 每个事实能否追溯到客户需求或批准的资料？
- 假设和待确认问题是否清楚？
- 交付负责人是否认可范围与前置条件？
- 报价和条款是否经过独立核查？
- 发送人是否有权作出这些承诺？
真正值得追求的不是多写几页，而是减少重复拼装、说清承诺，并保留能发现高成本错误的审核流程。
想梳理适合团队的提案起草试点，可以查看我们的 AI 产品与智能体服务，或发送邮件。
