这次做的是一个真实售前文件任务。

客户侧有一份用户需求书模板。

项目侧有一份配置清单，也就是这次实际要建设什么。

公司内部还有一份比较完整的标准解决方案，可以作为内容素材。

任务看起来很简单：把这三份材料合在一起，写成一份用户需求书。

但真正做过售前文件的人都知道，这件事并不是复制粘贴。

模板不是这个项目的原始需求。

标准方案也不能整段搬进去。

配置清单才是本项目的边界。

所以这次我想试一下：能不能让 Codex 根据项目配置清单，结合标准方案内容，再按客户模板要求，生成一份可以继续修改的用户需求书。

这个任务难在哪里

这类文件最容易出三个问题。

第一个问题，是照着客户模板硬填。

客户模板往往只是格式参考，里面原来的章节和描述不一定适合当前项目。如果完全照搬，最后会变成“格式像需求书，内容不像这个项目”。

第二个问题，是照着标准方案硬抄。

标准方案一般内容很全，模块很多，描述也偏产品宣传。如果不筛选，很容易把本项目没有采购、没有报价、没有实施边界的内容写进去。

第三个问题，是忽略配置清单。

配置清单看起来只是报价表，但它其实决定了这个项目真正建设哪些软件、哪些硬件、哪些接口、哪些服务。

所以这次的核心逻辑不是：

模板 + 方案 = 需求书

而是

项目配置清单确定边界客户模板确定格式标准方案提供素材最后生成用户需求书

这个顺序很重要。

我是怎么让 Codex 做的

分解任务及确认需求

我没有一上来就说：

帮我写一份用户需求书。

我先让 Codex 分解任务。

大概意思是：

请先阅读需求书模板、项目配置清单和标准解决方案。模板只是章节和格式参考，不是同类项目，可以调整。配置清单是本项目建设内容，必须作为边界。标准解决方案是主要素材来源，需要提炼后改写成需求书口径。请先分解任务，我确认后再开始生成。

这一步我觉得很有必要。

因为售前文件一旦方向错了，后面写得越快，返工越多。

先让 AI 拆任务，相当于先确认“它理解的是不是我要的那件事”。

Codex 实际做了什么

确认任务后，Codex 先读了三类材料。

第一类，是客户模板。

它用来判断需求书应该有什么章节、哪些表述比较正式、哪些内容可以保留为客户模板逻辑。

第二类，是项目配置清单。

它用来确定这次项目的建设范围，比如软件系统、物联硬件、系统接口、移动端适配、实施服务等。

第三类，是标准解决方案。

它用来提取功能描述、总体架构、业务流程、运维管理、质控管理、效益分析、接口集成、实施培训和售后服务等素材。

然后它把这些内容重新组织成需求书结构。

最后生成了一份 Word 文件。

这个文件不是把标准方案复制进模板，而是换成了更接近采购需求书的表达：

• 项目概述；
• 总体建设要求；
• 软件功能需求；
• 硬件与物联建设要求；
• 接口集成要求；
• 非功能要求；
• 实施培训要求；
• 验收要求；
• 服务期限与付款方式。

这对售前来说，价值不是“AI 替我定稿”。

真正有价值的是，它把三份分散材料变成了一份结构完整、可以继续修改的需求书初稿。

生成初稿

中间还做了一次补充

第一版生成后，我又发现一个问题：

软件功能需求写得还不够厚。

如果这份文件后面要作为用户需求书使用，软件功能不能只写概括性描述，还要尽量细到可以评审、可以验收、可以让客户看懂。

所以我继续让 Codex 补充：

软件功能需求部分需要重新补充。内容尽量来源于标准解决方案。功能描述要更丰富，不能太简单。

这一次，Codex 没有重写全文，而是在原需求书里新增了更详细的软件功能清单。

它把功能拆成了几组：

• 资产台账与盘点；
• 采购、合同与验收；
• 维修养护；
• 质控管理；
• 运行监测；
• 效益分析与统计；
• 移动端现场作业。

这一步很关键。

因为很多售前文件第一版看起来完整，但真正拿给客户或领导看时，问题往往出在“功能写得太薄”。

配置清单只能告诉你买什么。

标准方案才能帮你把“买什么”展开成“具体要实现什么”。

生成优化稿

这次花了多久

我按 Codex 线程记录算了一下。

这次主要分三段：

第一段，读取材料并拆解任务，大约 1 分 30 秒。

第二段，正式生成第一版需求书，大约 14 分 36 秒。

第三段，根据反馈加厚软件功能需求，大约 10 分 32 秒。

三段加起来，Codex 实际处理时间约：

26 分 37 秒。

如果从第一次开始拆解任务，到最终软件功能补充版完成，中间包含确认和追加反馈，整个过程跨度约：

31 分 36 秒。

这个时间不能理解成“半小时就能得到最终定稿”。

更准确的说法是：

半小时左右，可以把一堆材料推进到一份结构完整、内容较厚、可继续修改的用户需求书初稿。

如果成熟售前自己做，要多久

我判断，成熟售前自己做这类文件，预估 3 小时是合理的。

但这个 3 小时有前提：

• 已经熟悉业务；
• 手上有现成标准方案；
• 客户模板不复杂；
• 配置清单边界比较清楚；
• 目标是可用初稿，不是最终定稿。

如果从零理解业务、重新消化方案、反复调整格式，3 小时会偏紧。

如果只是把材料整成一份比较像样的初稿，成熟售前 3 小时可以做到。

我的判断是：

人工成熟售前约 3 小时，Codex 这次约 30 分钟，把起稿时间压缩到了原来的六分之一到七分之一左右。

但最终审核、口径把关、客户敏感信息处理，还是要人来做。

这次对话还可以怎么优化

这次对话整体是有效的。

但如果下次再做同类任务，我会把第一句话再写得更清楚。

可以直接这样说：

请基于以下三类材料生成用户需求书：1. 项目配置清单：作为建设范围和功能边界，清单里没有的内容不要扩展成正式采购需求；2. 客户需求书模板：作为章节、格式和表达风格参考，但可以根据本项目重构目录；3. 标准解决方案：作为功能、架构、实施、服务等内容素材，不能整段照搬，需要改写成客户需求口径。请先输出任务拆解和拟定目录，我确认后再生成 Word。生成后请检查：1. 是否覆盖配置清单；2. 是否存在模板占位符；3. 是否有明显超出本项目边界的内容；4. 软件功能需求是否足够细；5. 是否形成可交付的 Word 文件。

这段提示词的重点，不是写得更长。

而是把三类材料的角色讲清楚。

配置清单管边界。

客户模板管格式。

标准方案管素材。

AI 一旦理解这三个关系，生成的文件就会稳很多。

哪些地方必须人工把关

这类需求书，AI 可以帮忙写初稿，但不能替售前负责人做最终判断。

尤其是这些内容必须人工看：

• 配置清单是否完整；
• 标准方案里的功能是不是本项目真的包含；
• 接口、硬件、服务期限是否和商务报价一致；
• 验收条款是否能承诺；
• 付款方式是否符合项目实际；
• 客户名称、项目名称、金额、联系人等敏感信息是否准确；
• 有没有把产品宣传语写成了客户强制需求。

AI 最大的作用，是让你更快进入“检查状态”。

不是让你跳过检查。

这件事给我的启发

这次实操让我更确定一个方法：

以后做售前需求书、技术方案、采购响应文件，不要直接让 AI 写正文。

先把材料分成三类：

第一，边界材料。

比如配置清单、报价清单、招标参数、客户明确要求。

第二，格式材料。

比如客户模板、历史文件、公司标准模板。

第三，素材材料。

比如标准解决方案、产品白皮书、培训资料、案例材料。

然后再让 AI 按这个顺序处理。

边界先定住。

格式再套住。

素材最后进入正文。

这样生成出来的东西，才不会又空又泛，也不会把不该承诺的内容写进去。

对售前来说，AI 不是一个“万能写手”。

更像一个可以快速处理材料、搭结构、生成初稿的工作助手。

它不能替你负责。

但它能帮你把原来 3 小时才进入修改状态的任务，压缩到 30 分钟左右。

这已经很有价值了。