提案写得慢，通常不是写作能力的问题，而是输入不够。客户在通话里提到的预算口径、上线时间、验收人、以及那句“这个小功能顺便也加上吧”，散落在聊天记录、邮件和你的记忆里。把这些零散信息直接丢给 AI，它不会告诉你哪里缺信息，而是用流畅的措辞把空缺补齐——包括把一份你还没核算过的报价写进正文。

解决办法不是换一个更聪明的模型，而是在调用 AI 之前先补一道工序：把沟通信息整理成一份结构化、带状态标记的项目 Brief。它是一份内部工作文档，服务于提案起草和范围管理，不替代合同，也不承诺任何成交结果。

这份 Brief 解决的是哪一步工作

适用对象是同时承担销售、交付和财务的一人公司或自由职业者。典型场景是：客户初步沟通完，你需要在几小时内回一份提案，但信息只存在于刚才那通电话里。

Brief 在这条链路里的位置很明确：沟通之后、写提案之前、签合同之前。它承担三件事——把散落信息收敛到一处、暴露信息缺口、给 AI 一份不会随意发挥的输入。合同负责约定权责和违约，Brief 不承担这个职能；如果客户对某些条款敏感，仍需要在正式合同里单独确认。

七个字段，把沟通信息装进固定格子

字段不求多，求每个字段都能影响提案里的某一句话或某一个价格。下面这套结构可以直接抄。

字段	要记录什么	缺失时最容易出问题的地方
客户与项目背景	客户主体名称、所在行业、对接人及其决策权限、还有谁参与决策	提案写给错的决策人，或低估审批链长度
业务目标	客户想解决的问题、成功怎么衡量、有没有硬性指标	提案变成功能罗列，客户看不出和自己目标的关系
范围与交付物	交付哪几项、各自的形式与数量、明确不包含什么	“顺便做一下”累积成免费加班
验收方式	谁来验收、以什么标准、验收周期多长、几轮修改包含在内	交付后陷入无限修改
时间线	客户期望的完成时间、关键节点、客户侧需要配合的事项与时间	客户自己延迟导致你违约
预算与计价	客户给出的预算区间或口径、你的计价单位、付款节奏	报价结构与客户预期错位
限制条件与风险	技术栈约束、既有系统、合规与保密要求、排他条款	交付后才发现无法满足的硬约束

真正让 AI 变可靠的是最后加的一列：信息状态。每个字段都标上 [已确认]（客户书面确认过）、[口述]（电话里说过，未书面确认）、[假设]（你根据经验推断）、[待确认]（还不知道）。这一列把“客户说过”和“我以为客户说过”分开，后面 AI 生成的提案才不会把推断写成承诺。

用什么格式承载 Brief

三种常见承载方式各有代价，按你当前的项目数量选就行。

• Markdown 表格：适合单个项目、人工填写、随时整段粘贴给 AI。改动最灵活，字段一多容易出现错位。
• JSON 或 YAML：适合字段固定、后续要接自动化脚本的场景。结构严格、便于程序校验，代价是手写容易因为缩进或标点出错。
• 在线表单或数据库：适合多项目并行、需要检索历史报价和交付记录的场景。有字段校验和视图，代价是初期需要花时间搭建并长期维护。

一人公司起步阶段，先维护一份 Markdown 空白模板就够了。等历史项目多到需要按行业或客户类型检索时，再迁移到数据库形态，迁移时把字段名保持不变即可。

从沟通到 Brief：填写顺序与最小版本

填写顺序建议按客户说话的自然顺序，不要按表格顺序。首次沟通时依次问清四件事：客户想达成什么、希望什么时候完成、内部谁说了算、预算大概什么量级。剩下的交付细节在第二次沟通补齐。

会后十到十五分钟内填写，趁记忆还新。每条信息后面补上来源，例如“预算 20 万以内——电话口述，未书面确认”。同一字段出现矛盾说法时，两个版本都留下并标 [待确认]，不要自己挑一个。

时间特别紧的时候，一份最小可用 Brief 至少要包含五项：客户主体与对接人、业务目标、交付物清单、期望时间、预算口径。这五项缺任何一项，提案都只能靠猜。

把 Brief 交给 AI：先要缺口清单，再要初稿

关键技巧是不要让 AI 直接写提案。先让它检查输入是否完整，再动笔。下面这段提示词可以直接改用。

你是一名项目提案起草助手，我将提供一份项目 Brief。
Brief 中每个字段带有状态标记：[已确认] / [口述] / [假设] / [待确认]。

请遵守以下规则：
1. 只有 [已确认] 的内容才能写成确定性表述。
2. [口述] 的内容写成“我们目前的理解是……，请在回复中确认”。
3. [假设] 的内容不得写入提案正文，一律转入“待确认事项”。
4. 金额、周期、修改轮次只引用 Brief 中 [已确认] 的原值，
   不得自行推算总价、折扣或额外赠送项。
5. 输出分三部分，顺序固定：
   ① 信息缺口清单（缺什么、为什么影响提案）
   ② 提案初稿
   ③ 待确认事项清单

Brief 如下：
<把填写好的 Brief 粘贴到这里>

先看第一部分。缺口清单里如果出现“验收标准缺失”“客户侧配合时间未定”这类条目，说明 Brief 还没填完，此时先补信息比继续改提案更省时间。第二部分才是初稿，它的价值是省掉排版和措辞的时间，不是省掉判断。

三步复核：事实、范围、报价

AI 生成的初稿不能直接发出去，需要按固定顺序过一遍。

事实复核

逐句对照 Brief，凡是 Brief 里没有的数字、案例、资质描述，一律删掉或改成待确认。特别留意 AI 补充的“我们曾为同类客户提供过类似服务”这类句子——它可能凭空生成；如果确有类似经验，也应该由你亲手写进去，并写清是哪一类经验。

范围复核

把提案里的交付物清单和 Brief 的“交付物”“不包含”两栏并排比对。重点抓三类偏差：AI 自行推断出的附加交付项、被悄悄删掉的客户明确要求、以及“包含但不限于”这类无法界定边界的措辞。边界模糊的句子在交付阶段会直接变成争议。

报价复核

报价必须由你本人核算，AI 只负责把已确认的计价方式原样搬进文档。核对四件事：计价单位是否和 Brief 一致、是否注明税费口径、付款节奏是否与里程碑挂钩、超出范围的部分如何计费。任何 AI 算出来的总价都当作参考值，不作为对外数字。

让模板真正可复用

单个项目用一次不叫模板。要复用，需要做两件小事。

一是保留一份空白模板和一份填写示范。示范最好用你已经交付完的项目，把客户信息脱敏后再存档，新项目开始时复制示范文件改字段，比对着空白表格填更快。

二是定期把重复出现的问题沉淀回模板。比如连续三个项目都在“验收方式”上扯皮，就在模板里把这一栏拆成“验收人”“验收标准”“修改轮次”“验收周期”四行。模板的字段是被项目打磨出来的，不是一开始就设计完整的。

最后回到边界：Brief 让提案的输入更完整，让信息缺口更早暴露，但它不替代合同条款，也不保证客户一定签单。它真正稳定提供的，是每次提案前那份可复查、可追溯、能交给 AI 而不会被随意发挥的输入。这份输入积累得越久，你在报价和范围判断上的偏差就越小。