写提案：行业标准方法论，以及 AI 该在哪一步介入
金字塔原理、SCQA、Shipley 的 Win Theme 与 Color Team 评审——先把这套语言讲清楚，再谈哪几个环节值得交给 AI。最该 AI 化的不是写初稿。
提案是研究咨询行业最费人的一件事，也是最容易被误判为「AI 能一键搞定」的一件事。
实际情况：AI 在提案上最有价值的环节，不是写初稿。
要说清楚为什么，得先把这门手艺本身讲明白。
一、一份完整提案的标准结构
拆解主流咨询公司的提案模板，通常是 6–8 章：
| 章节 | 作用 |
|---|---|
| 执行摘要 / Cover Letter | 一页讲完「我们懂你」+「我们的答案」 |
| 对客户需求的理解 | 复述客户处境、目标、成功标准 |
| 建议方案与方法 | 工作流、模块、分析框架、初始假设 |
| 团队与资质 | 角色配置、简历、同类项目案例 |
| 时间表、交付物与工作计划 | 甘特图、里程碑、交付清单 |
| 报价与商务条款 | 费用结构、付款节点、可选模块 |
| 风险与应对 / 前提假设 | 风险登记表 |
| 附录 | 详细简历、补充案例、合规文件 |
中间三章是核心：对需求的理解、建议方案、团队资质。评审真正在这三章上分高下。
篇幅上，从三五页的信函式提案到几十页的完整 deck 都有，公共部门的标书可以更长。
二、四套叙事方法论
这四套是顶级咨询公司提案叙事的地基。它们不是排版技巧，是决定评审读到第几页的东西。
金字塔原理（Pyramid Principle）
顶端先抛核心论点，下层用彼此独立、穷尽无遗漏（MECE）的支撑论点承接，证据垫底。
这是执行摘要的标准骨架。先给结论，再给理由——不是先铺陈再揭晓。
SCQA：情境 → 冲突 → 问题 → 答案
Situation → Complication → Question → Answer.
「对客户需求的理解」那一章的标准叙事结构：先描述客户所处的情境，点出打破平衡的变化，把它转成一个明确的问题，然后给出你的答案。
它的作用是把客户带进问题里，而不是直接推销你的方案。
假设驱动（Hypothesis-driven）
在提案阶段就提出初始假设，向客户展示**「我们已经开始解题了」**，而不是「等合同签了我们再开始想」。
这一条的差异感极强。两份提案，一份说「我们将通过三阶段研究得出结论」，另一份说「我们的初步判断是 X，本项目将验证或推翻它」——后者传递的专业度完全不同。
结论先行（Answer-First）
不藏底牌。把建议前置，让评审在第一页就看到你的判断。
这是和「学术报告式」叙事最大的区别。 学术报告是「方法 → 发现 → 结论」，提案是「结论 → 依据 → 方法」。很多研究背景的人写提案时会不自觉切回学术顺序，这是最常见的失分点。
三、Shipley 与 APMP：这个行业的通用语言
无论咨询还是其他 B2B 投标，这套术语是事实标准。不懂这套语言，连讨论提案质量都缺词。
Capture Planning：比 RFP 更早
Shipley 方法论里一个广为引用的判断是：相当比例的客户在 RFP 发出之前，心里已经有了倾向的供应商。
推论很直接：你的工作必须早于 RFP。 等标书发出来才开始动，你已经在跟一个可能早就存在的偏好赛跑。
Win Themes：锚定评审标准，不是罗列自身优势
Win Theme 必须锚定客户的评审标准，贯穿全文，并且能被评分员在打分表上「勾选」到。
「我们有 30 年经验」不是 Win Theme——它没有对应客户任何一条评分项。「我们在你们最关心的 X 维度上有 Y 能力，因此能解决 Z」才是。
Discriminators：在客户在意的维度上做出差异
差异化必须发生在客户在意的维度上。「我们团队经验丰富」这类通用语不构成差异——因为竞争对手也这么写，评分员无法据此区分。
Ghosting：暗示竞品的短板，不点名
在提案中植入对竞争对手弱点的暗示。比如强调「本地团队全程在场」，暗指某些竞品依赖远程交付——不直接点名，让评审自己得出结论。
四、Color Team：分阶段评审
Shipley 提出的按颜色分阶段评审机制，是提案质量保障的核心动作：
| 评审 | 时点 | 检查什么 |
|---|---|---|
| Pink Team | 完成约 20–25% | 合规与大纲——RFP 的每一条要求都覆盖到了吗 |
| Red Team | 完成约 70–80% | 以评审视角检验说服力、Win Theme 一致性、应答完整性 |
| Gold Team | 接近定稿 | 高管批准与最终 Go / No-go |
| Green Team | 独立进行 | 定价策略专审，与内容审查分开 |
| White Glove | 提交前 | 最后的排版与合规扫描 |
注意 Green Team 是独立的。 定价审查和内容审查混在一起时，人会不自觉地用「方案很好」来正当化一个不合理的报价。
五、AI 该在哪一步介入
现在回到开头那句话。把上面的流程摊开看，AI 的性价比不是平均分布的。
最高价值：Red Team 自评
这是最该交给 AI 的环节，成本最低、质量提升最大。
Red Team 的本质是「换一双眼睛，站在评审的位置上挑毛病」。而这恰恰是团队内部最难做到的——写的人有认知盲区，同事碍于情面。
你现在是这份提案的评审委员，不是作者。 评审标准如下： <criteria> [粘贴 RFP 里的评分标准，逐条] </criteria> 提案全文： <proposal> [粘贴] </proposal> 请逐条做三件事： 1. 这条标准在提案里由哪一段回应？引用原文。找不到就明确说「未回应」。 2. 如果你是评分员，这一条给几分（满分对照上面的标准），为什么。 3. 最容易被竞争对手比下去的是哪一条？ 不要夸奖，不要总结优点。只找问题。
复制为纯文本，换行与缩进原样保留，可直接粘贴进对话框。
最后那句是关键。 不加的话，输出会有一半是「这份提案结构清晰、逻辑严谨」这类无用的肯定。
高价值：合规矩阵生成
把 RFP 逐条拆成一张「要求 → 提案中的位置 → 是否已回应」的对照表。
这件事纯机械、极耗时、且漏一条可能直接废标。让 AI 做初版，人来核对，比人从头做快得多也稳得多。
把下面这份 RFP 拆成合规矩阵。 逐条列出每一项要求（包括埋在正文里的隐性要求），输出为表格： | 编号 | 原文要求 | 类型（强制/加分/信息） | 提案中的对应章节 | 状态 | 原文里没有明说但实际构成要求的，在「原文要求」里标注「[隐含]」。 宁可多列，不要漏。
复制为纯文本，换行与缩进原样保留，可直接粘贴进对话框。
高价值：知识复用与检索
团队做过的同类项目、案例、简历、方法描述——大量时间消耗在「找上次那份东西在哪」。
把这些放进一个 Project（或本地目录）作为可检索的素材库，是投入产出比最高的一次性动作。
中等价值：个性化改写
同一套方法描述，针对不同客户的行业语境调整措辞。AI 做得不错，但必须人工过一遍术语——客户内部的叫法是模型不知道的。
低价值，甚至负价值：直接写初稿
这是最多人尝试、也最容易失望的用法。
原因不在于写得不好，而在于：一份没有 Capture 信息、没有 Win Theme、不知道评审标准的初稿，写得再流畅也是错的。而它的「流畅」会掩盖这一点，让人误以为只差润色。
顺序应该反过来：先定 Win Theme 和评审标准，再让 AI 在这个框架内产出内容。
六、一个务实的起点
不必一上来就重构整个流程。按这个顺序试：
- 下一份提案交出去之前，先让 AI 做一次 Red Team 自评。 一次调用，可能捞出两三个真问题
- 下一份 RFP 拿到手，先让它生成合规矩阵。 你会发现有隐性要求被漏掉
- 把团队的历史案例和方法描述整理进一个 Project。 一次投入，之后每份提案都受益
三件事都不需要改变现有工作流，只是在既有节点上插入一步。
而这三件事的共同点是：它们都发生在「写」之前或之后，不是替代「写」本身。