方案草稿生成

这项能力到底在做什么

方案草稿生成，简单说，就是把客户需求、业务背景、现有资料和历史经验快速整理成一份可讨论的方案初稿。

很多团队并不是不会写方案，而是每次起稿都很慢。
常见情况通常是这样：

需求记录散在会议纪要和聊天里
不知道先从哪种结构起
老方案很多，但找不到最适合的参考
客户催得很急，第一版总要赶

方案草稿生成真正解决的，不是替团队直接定稿，而是把“从空白页到第一版可讨论材料”这段最费时间的过程先拉起来。

它通常接收什么输入

这项能力接进来的，通常是一组和项目方案有关的信息。

常见输入包括：

客户需求记录
业务目标
当前问题描述
产品或服务资料
历史案例参考
行业背景信息

一起带进来的上下文，常见还有这些：

方案用途
客户行业
交付边界
输出格式要求
语言要求
内部模板要求

这些上下文很关键。因为方案草稿不是把资料拼在一起，而是要知道：

这份方案是为了售前沟通、投标，还是内部评审
客户最关心哪几个问题
哪些内容必须先写
哪些内容只需要先留框架

它能输出什么结果

方案草稿生成最后交出去的，不应该只是几段零散文字，而应该是一份能进入讨论和修改的初稿结果。

常见输出包括：

输出项	说明
目录结构	方案的章节框架
核心章节草稿	现状、目标、方案思路、实施建议等
待补充项	哪些部分还缺资料
风险提示	哪些边界还不清楚
表达建议	哪些内容适合更商务、哪些适合更技术
版本说明	这是面向谁、用于什么场景的初稿

这样下游拿到的，就不是一个空文档，而是一份可以直接继续完善的方案起点。

它在内部是怎么跑起来的

方案草稿生成真正难的地方，不是会不会写，而是怎么在资料不完全整齐的情况下先搭出一个靠谱框架。
它在内部通常会经过下面这条链。

1. 先理解这次方案的目标

系统先判断这份方案是做什么用的，以及谁会看。

2. 再整理客户问题和目标

会把零散需求收拢成更清楚的几个核心问题和目标方向。

3. 再匹配适合的结构

不同方案场景，结构不一样。
系统会先决定这份方案更适合怎样的章节顺序。

4. 再填入核心章节草稿

比如：

项目背景
现状问题
目标设计
方案思路
实施路径

5. 再标记待补充和边界不清处

初稿不怕不完整，怕的是装作完整。
系统会把缺口和风险标出来。

6. 最后输出可继续修改的草稿版本

这样顾问、销售、管理层都能更快进入讨论。

详细内部流程图

flowchart TB
    A[输入客户需求、资料和历史案例] --> B[识别方案目标、使用场景和阅读对象]
    B --> C[整理客户问题、目标和关键边界]
    C --> D[匹配适合的方案结构]
    D --> E[生成目录和核心章节草稿]
    E --> F[标记待补充项和风险提示]
    F --> G[输出可讨论的方案初稿]
    G --> H[交给顾问、销售和管理层继续修改]

它最后会把什么交给下游流程

方案草稿生成真正交给下游的，不只是文字，而是一份可继续推进的方案初稿。

常见会交出去这些内容：

方案目录
核心章节草稿
待补充内容清单
边界风险提示
版本说明
修改建议

这样后面的流程才能继续做：

顾问细化方案
商务报价衔接
合同边界确认
内部评审
客户沟通

它怎么接入业务才真正有价值

方案草稿生成最怕的，不是生成不出来，而是生成出来以后和真实业务脱节。

真正常见、也最有价值的接法，一般有下面几种：

1. 接在需求整理后面

客户需求一旦清楚，就可以先快速起一版。

2. 接在资料检索后面

先把可用资料找齐，草稿会更稳。

3. 接在商务和合同补充前面

先有初稿，再补商务和边界，效率通常更高。

4. 接在高频出方案团队里

方案需求越多，这项能力越容易产生价值。

什么情况下必须转人工

方案草稿生成虽然很适合自动化，但下面这些情况最好让人工主导：

客户需求非常复杂且变化快
涉及重大投标或战略项目
交付边界高度敏感
行业专业门槛很高
初稿将直接对外发送
系统缺少关键背景信息

真正稳的企业做法，不是让系统直接代替顾问，而是让系统先把起稿速度拉起来，把关键判断留给人。

为什么这项能力站得住

方案草稿生成之所以在企业里很有价值，是因为很多交付和售前团队最缺的不是写作能力，而是起稿时间。
谁能更快拿出一版可讨论材料，谁就更容易占据主动。

1. 它先解决的是“从零开始太慢”

这一点在高频方案团队里非常关键。

2. 它能明显提升首稿效率

只要首稿更快，后续评审和修改就会更从容。

3. 它特别适合资料多、模板多的场景

资料越多，越需要一层快速整理能力。

4. 它边界清楚，适合人工定稿

系统先起草，人再定稿。
这种配合方式很实用。