夜雨聆风事情是这样的。最近接了一个挺典型的活儿，写一份技术方案类的标书，而且是那种注定走形式那种，做过的朋友大概知道我说的是什么，单出就是消耗时间。你要写项目背景、建设目标、总体架构、功能建设内容、实施计划、服务保障、合理化建议，一路写下来，每个章节都得正式、饱满、像那么回事。
而且这次手上的材料特别少。大概就是一个目录，三页左右的基础文字，再加上一份系统建设功能清单。目录告诉你这份标书要写哪些章节，功能清单告诉你系统大概有哪些模块和功能点。就这么点东西，最后做出来是多少呢，大概200页，25万字。
如果放在以前，这种活儿就只能硬写。看目录、看功能清单、理解项目边界，然后一章一章往下补。功能建设内容要写，项目背景要写，重难点分析要写，实施计划也要写。正常写下来，三四天很正常，中间那种持续组织正式语言的疲劳感，做过的人都懂。
这次我用了AI，但我得先把话说在前面，我不是让AI帮我「自动写标书」，也不是搞了一个多么高级的AI工作流。
坦率的讲，真实情况比这朴素得多。就是我本来就知道这份标书怎么写，也知道手上有什么材料，也清楚最终要交出什么样的东西。AI在这个过程里，主要就是帮我生成文字、扩写内容、补全段落。真正控制方向、判断质量、往里塞上下文的人，还是我自己。
你可以理解为，我把AI的能力嵌入到了原来写标书的过程里。不是让它替我思考，而是让它帮我干那些我知道怎么干、但特别耗时间的部分。
我觉得这个区别挺重要的。
很多人可能对用AI写东西有一个误解，觉得应该是丢一句话进去，然后AI就能输出一份完整的文档。说真的，我自己也试过，效果很一般。因为AI并不知道这个项目到底长什么样，不知道甲方到底关注什么，不知道哪些内容要展开写、哪些点到为止就行，也不知道这份文档最终要拿去干嘛。
你只给它一句「帮我写一份技术方案」，它大概率只能给你一堆正确的废话。真正好用的方式，是你先把自己脑子里的东西理清楚了，然后一段一段地喂给它。
回到这次写标书这块，说一下我具体是怎么做的。
我没有一上来就从第一章开始写。标书里最核心的部分其实是功能建设内容。原因很简单，其他所有章节，项目背景也好、建设目标也好、重难点分析也好、合理化建议也好，都可以从功能内容里反推出来。
所以我先把功能部分写扎实。
但功能部分本身也很多，一次性全丢给AI，它容易失控，写着写着就开始自由发挥了。我的做法是按子系统拆。一个模块开一个对话，每次只让AI处理一个相对清晰的小范围。
这样做的好处是，AI的注意力会集中很多。它不会一会儿写平台架构，一会儿写运维保障，一会儿又跳到接口安全。每次只处理一个小范围，输出质量明显就稳了。
功能部分写完以后，整份标书就有了骨架。这个感觉还挺明显的。
因为接下来再写项目背景、建设目标、重难点分析、实施计划这些，就不用凭空编了。这些内容必须和功能建设内容互相呼应，而功能内容已经在那儿了，等于给了AI一个锚点。
比如功能里有统一报表与可视化分析，重难点里就可以写报表性能与展示一致性。功能里有多系统接口和数据同步，重难点里就可以写跨平台集成。功能里有指标配置、规则管理、告警阈值，合理化建议里就可以写公共能力复用和数据标准建设。
这时候AI的价值就出来了。它可以快速从已经写好的功能章节里提取关键信息，然后把这些东西转换成正式的标书语言。写出来的内容至少不会和前面的建设内容脱节。
不过有一点我得说，AI第一次生成的内容，通常只能算初稿。说实话也正常，它又不是真的理解这个项目。它会有几个常见问题，有些地方太泛了，有些地方写得太深，有些地方像教材里抄出来的，还有些地方和项目的实际功能贴得不紧。
所以我会继续追问它。
比如「这块不要写太深，这只是投标文件里的重难点分析」。再比如「这部分要依据功能清单来写，内容更落地一点」。再比如「这一段要像技术方案，少写概念，多写建设措施」。
每校准一次，它就更贴近你想要的风格和深度。你会发现AI写长文档真正好用的地方，不在于一次性生成全文，而在于它可以接受你不断校准。
整个过程其实就是一个很典型的人机配合。
人负责上下文和判断，AI负责文字产能。你提供结构和材料，它帮你扩写成正式文本。你检查完觉得不行，它帮你改。觉得还不行，再改。不是说你丢进去就不用管了，而是你每做完一块，都得回来看一眼，该补的补，该删的删，该让它重写的就让它重写。
可能有人会想，那你为啥不一开始就把整个项目的上下文全部给AI讲清楚呢，这样它不就能一次性写到位了吗。
说真的我也想过，但实际操作下来发现，这个成本太高了。这种标书里有大量隐性信息，甲方的偏好、行业的一些惯例、某些章节到底该写多深该写多浅，这些东西很难通过一段提示词就讲明白。你真要把所有上下文都塞进去，光组织这些信息就得花很长时间。
so，它不适合做成那种标准化的、端到端的自动流程。更适合的方式就是一段一段地协作，你做一块，AI做一块，你检查，再继续往下推。
说到这里，我想聊聊为什么我觉得这件事对B端产品经理来说特别有感触。
我是真的觉得，做B端的人，日常工作里有太多这种文档活儿了。技术方案、需求文档、汇报材料、验收材料、会议纪要、投标文件、功能说明、实施计划。
这些东西有一个共同特点，结构明确、篇幅很长、表达正式、内容必须贴合业务。它们不一定有多难，但特别耗人。
我自己的感受是，难点不在于你不知道该写什么，而在于你要持续输出大量正式的、完整的、看起来很专业的文字。写到后面人是真的会麻，不是写不出来，就是持续组织正式语言这件事本身，真的很累。
你想想看，B端产品经理有一个特别尴尬的处境。懂业务的人不想写，觉得这些东西写起来太烦太重复。但写材料的人呢，往往又不够懂业务，写出来的东西不够贴。
这中间就有一大块地带是被浪费掉的。AI其实刚好可以把这块地带吃掉一大块。但前提是，你得知道自己要什么。
你要清楚输入是什么。比如这次的输入就是目录和功能清单，目录决定了文档结构，功能清单决定了内容边界。你也要清楚输出是什么。最终要交出一份技术方案类的标书，正式、完整、能撑起200页的篇幅，内容必须和系统建设对应。你还要知道每一步怎么检查。AI写出来的东西，哪些可用、哪些是废话、哪些太泛、哪些写偏了，这些都得靠你自己判断。
不能把脑子也交出去。
我自己也还在摸索这个过程。说实话，一开始让AI写标书的时候，也踩了不少坑。比如有一次我把好几个模块的功能清单一股脑全丢给AI，想着让它一次性把功能建设内容全部生成出来。结果出来的东西，前面还像那么回事，写到后面就开始不断重复，颗粒度忽粗忽细，有些功能点直接被漏掉了。后来才慢慢摸出来，一次处理一个小范围，效果要好得多。
这个过程确实有一个学习曲线。不是说你会用AI对话就够了，你还得慢慢找到一个适合自己的节奏，知道什么时候该给AI更多上下文，什么时候该让它少发挥，什么时候该自己动手改而不是让它继续生成。
不过一旦跑通了，效率提升是很明显的。
以前写这种材料，人的精力全被文字消耗掉了。写一段项目背景，写一段建设目标，写一段功能说明，写一段保障措施。每个章节都得正式、都得饱满、都得看起来专业。连续写几天人是真的会疲。
现在AI能把这部分工作承担掉一大块。人从主写手，变成了结构设计者、上下文提供者和质量审核者。
想想其实这个变化还挺大的。以前你坐在电脑前，从早写到晚，一字一句地敲。现在你的工作更像是在组织一条小型生产线，目录是框架，功能清单是原材料，提示词是加工参数，分章节对话是加工工序，最终的Word文档是交付成品。
你不再是工人，你更像是生产线的管理者。
这次25万字标书给我最大的感受就是，AI最先改变的，可能不是什么高大上的业务场景，而是我们每天都在做的文档工作。
尤其是那些你明明知道怎么做，但特别耗时间、特别耗精力的活儿。这类工作，AI真的能帮上忙。但也就只是「帮忙」。你是那个知道方向的人，AI是那个帮你提速的工具。这个关系搞反了，出来的东西一定不行。
反正我自己的经验是这样。也不知道对大家有没有用，但该说的都说了，希望能帮到正在被文档折磨的B端朋友们。
