提案写得慢，问题通常不在措辞，而在输入。客户提到的预算口径、上线时间、验收人，以及那句"这个小功能顺便也加上吧"，散落在聊天记录和记忆里。直接丢给 AI，它不会指出缺什么，只会用流畅措辞把空缺补齐。项目 Brief 模板要做的，是用固定字段把口头沟通装进可复查的格子。

每个字段对应提案里的一句话或一个价格

字段不求多，求的是每一个都能影响某个判断。

第一层定义对象与目标。客户与项目背景记录主体名称、行业、对接人及其决策权限、还有谁参与决策，决定提案写给谁、审批链有多长；业务目标记录要解决的问题、成功如何衡量、有无硬性指标。缺了后者，提案容易退化成功能罗列。

第二层定义交付承诺。范围与交付物写清交付哪几项、各自形式与数量、明确不包含什么——"顺便做一下"若没落进"不包含"，就会在交付期变成免费加班；验收方式记录谁来验收、以什么标准、周期多长、几轮修改包含在内；时间线记录期望完成时间、关键节点，以及客户侧需要配合的事项与时间。最后一项最常被漏掉：客户自己延迟，违约压力却在你这一侧。

第三层定义商务边界。预算与计价记录客户的预算区间或口径、计价单位、付款节奏，报价结构与预期错位的根源多在此；限制条件与风险记录技术栈约束、既有系统、合规与保密要求、排他条款，这类硬约束拖到交付后才发现，就没有回旋余地。

真正让 AI 可控的是状态列

比字段本身更关键的是每个字段后的状态标记：已确认、口述、假设、待确认。它把"客户说过"和"我以为客户说过"分开。没有它，AI 会把推断写成承诺，甚至把尚未核算的报价写进正文；有了它，就可以要求 AI 只用已确认内容做确定性表述，把口述内容写成待确认语气，把假设转入待确认事项。

承载格式按项目数量选。单项目手工填写，Markdown 表格最灵活；字段固定、要接自动校验，JSON 或 YAML 更合适，代价是手写容易出差错；多项目并行、需要检索历史报价，才值得搭表单或数据库。

字段也不是一次设计完整的。连续几个项目都在验收环节扯皮，就把验收拆成验收人、验收标准、修改轮次、验收周期。空白模板加一份脱敏示范，比从零设计快得多。