提案写得慢，常常不是文字组织能力不足，而是项目输入没有被整理。对一人公司而言，销售、交付和财务由同一个人承担，客户在通话、邮件和聊天中零散提到的目标、预算、时间与“顺便增加”的功能，若不先收敛，AI 就会用流畅表达掩盖信息缺口，甚至把尚未核算的报价写成确定承诺。

先建立一份带状态的项目 Brief

Brief 位于沟通之后、提案之前、合同之前。它不是合同，而是让提案输入可追溯、可复查的内部工作文档。至少应包含七类信息：客户与决策人、业务目标、交付物及不包含范围、验收方式、时间线、预算与计价、限制条件与风险。

每条信息都应标注状态：

• [已确认]：客户已书面确认，可写成确定表述；
• [口述]：沟通中提到但尚未书面确认，应提醒客户核实；
• [假设]：根据经验推断，不应直接写入提案；
• [待确认]：信息缺失，必须在提案中列为问题。

这一步的价值不在于增加文档，而在于区分“客户说过”和“自己以为客户说过”。尤其是预算、交付周期、验收标准和修改轮次，任何一个字段模糊，都可能在交付阶段变成争议。

让 AI 先查缺口，再起草

不要把 Brief 直接交给 AI 并要求“写一份提案”。更稳妥的流程是要求它按顺序输出：信息缺口清单、提案初稿、待确认事项。规则也要明确：只有已确认内容才能写成承诺；口述内容必须保留确认语气；假设内容只能进入待确认事项；金额、周期和修改轮次不得自行推算。

一人公司起步时，Markdown 模板已经足够。首次沟通优先确认客户目标、完成时间、决策人和预算口径；会后尽快补录，并保留信息来源。若时间极紧，至少先填客户主体、业务目标、交付物、期望时间和预算五项。

初稿生成后，还要人工完成三轮复核：逐句核对事实，逐项比对范围，最后亲自核算报价。AI 可以节省措辞和排版时间，却不能替代边界判断。真正可复用的提案系统，不是更复杂的模型，而是一份持续被项目经验修正的输入模板。