1. “无中生有”凭什么成立AI参与文档生产的逻辑拆解先聊一个我经常被同行问到的问题产品还在开发中界面三天两头改需求都没冻结领导却要求同步输出软件使用指南这活儿怎么干放到一两年前我的标准回答是等。等产品稳定等UI冻结等测试用例跑完。但现在我的回答变了不用等你可以用AI辅助开发的方式把指南“无中生有”地先写出来。所谓“无中生有”不是让AI凭空编造一堆看起来像那么回事的操作步骤那是幻觉会砸招牌。真正的“无中生有”是让AI从那些散落在代码仓库、接口文档、测试用例、产品原型里的“碎片线索”中推导出一份结构完整、逻辑自洽的软件使用指南。这件事在技术传播领域完全成立因为它背后有一套非常扎实的逻辑支撑。1.1 一切“生成”都不是凭空捏造输入的三种材料先破除一个误解AI生成文档并不等于AI闭着眼睛写小说。它同样需要“食物”只是这食物的形态比较特殊通常不以“用户手册”的形式存在。我实际做项目时会把输入材料分成三类供AI消化材料类型具体来源能从里面提取什么强约束材料代码仓库、CLI命令定义、配置项Schema、数据库表结构功能边界、可操作的动作、参数取值范围、必填项半结构化材料Swagger/OpenAPI接口、自动化测试用例、PRD、原型图业务流程、异常分支、状态流转、用户角色划分弱约束材料竞品使用指南、客服工单、社区讨论、售前demo录屏用户心智模型、常见疑问、操作习惯、术语口径举个例子。你拿到一份某个内部系统的Swagger文档里面定义了一个POST /api/v1/orders接口参数有customer_id、items、payment_method返回值里有order_id和status。这三个字段本身就是线索系统一定存在一个“下单”操作场景用户必须先有客户档案必须勾选商品必须在若干支付方式里做选择下单之后订单会进入某个状态流转。把这些线索喂给AI它自然能推导出“新建订单”这个功能模块下的操作步骤甚至能推断出“支付方式不同会导致订单状态走向不同分支”这种细节。这就是无中生有的第一层含义——把工程师视角的“数据结构”翻译成用户视角的“操作流程”。1.2 技术文档的强约束属性为什么AI适合做这件事软件使用指南和文学创作有个本质区别软件的交互逻辑是强约束的。打开任何一个软件用户能做的操作不是一个无限集合而是一个有限集合——界面按钮就那么多菜单层级就那么深服务端接口就那么几个。整个软件就像一个固定了墙壁的迷宫用户能走的路径虽然组合很多但每一段路径都是预先铺好的。这就意味着只要有一个足够聪明的大脑比如AI能“看”到所有的墙壁代码逻辑、界面元素、接口定义它就能在不需要真人走完全部路线的情况下把迷宫地图画出来。AI不需要真的去点击每一个按钮它可以从路由定义、前端组件里的onClick事件、后端接口的路径参数里推断出“点了这个按钮会发生什么”。这一点和传统文档写作完全不同。传统文档是“记录”是工程师做完了、我把行为拍下来写成文字AI辅助开发模式下的文档是“推导”是让AI根据已知的规则推导出尚未被完整描述的行为。再加上规范的使用指南本身强依赖“场景化结构”和“步骤化表达”这套语言体系恰恰是AI最擅长模仿的。你给它几个同类产品的使用指南做风格参考它输出的结构通常八九不离十。1.3 无中生有的边界在哪里当然必须承认有些东西“无中生有”做不出来。AI能推导出“用户可以上传文件”但它无法推导出“该功能主要是为了支持财务月度对账时批量导入银行流水”——这是业务意图不是逻辑推导能覆盖的需要人告诉它。根据我的实践经验以下几类信息无论如何都要靠人工访谈获取别指望AI生成功能的设计初衷与业务目标为什么做这个功能性能指标与容量限制最多支持多少人同时操作、文件大小上限安全与权限设计哪些角色能用哪些功能、字段级权限如何划分已知缺陷与临时规避方案哪些地方不太好用但是有意为之客户成功案例与最佳实践系统怎么用才能发挥最大价值拿一次实际项目举例。我们用AI从代码里“无中生有”了一个工单系统的操作指南初稿整体流程写得非常完整——创建工单、派单、转办、挂起、关闭每一步都对着接口逻辑推出来了。但AI完全没写“为什么建议优先级高的工单先走人工分派而不是自动分派”因为代码里根本没有这个信息。最后还是业务方口头补充进去的。所以正确姿势是AI负责把能推导的全推导出来生成一个数量上远超人工初稿的“毛坯稿”然后技术传播人员负责把业务属性、设计意图这些“隐性知识”通过访谈和实测补进去。前者解决“写得全不全”后者解决“说得准不准”。2. 从零到一份可交付指南的完整工作流知道了原理接下来落地。我梳理一下自己在多个项目里验证过的一套工作流适用于大多数软件产品无论Web端、App端还是企业级后台系统都可以套用。2.1 第一步搜集并整理“可推断线索”这一步不能图省事把几个链接丢给AI就完事。你需要把不同来源的材料做一次清洗、分类和排序因为AI的输出质量直接取决于输入的组织方式。我的做法是建一个共享目录比如docs-sources/project-x/下面放四个子目录01-code前后端仓库的README、路由定义文件、前端页面目录结构、package.json里的脚本命令02-apiSwagger/OpenAPI导出、GraphQL Schema、Postman Collection03-tests自动化测试用例、集成测试场景、端到端测试脚本04-miscPRD摘要、原型图导出、竞品指南、客服FAQ这里有个很容易被忽略的点把代码仓库整个喂给AI用处不大AI会被大量无关代码冲淡注意力。正确做法是先自己扫一遍挑出与用户行为相关的部分比如页面路由、状态机定义、关键服务入口再让AI去解析。实测下来挑过的材料比直接丢仓库的生成质量高出一大截——因为用户能做什么、不能做什么几乎都藏在路由和状态机里。比如前端项目里的router.ts里面写着path: /orders/create、meta: { title: 新建订单, requiresAuth: true }这就是一条很清晰的线索系统有订单创建页需要登录而且导航标题叫“新建订单”。把几十条这种路由喂给AI它基本能把整个系统的功能地图搭出来。2.2 第二步把散料变成提纲这是最关键的一步材料整理好之后先别急着让AI直接写正文。先让AI输出一份详细的文档提纲然后再进入正文生成。这一步能省掉后面大量返工。怎么让提纲出得好我的提示词通常会包含这么几个要素产品的基本信息是什么、给谁用、解决什么问题已整理好的源材料清单按上面的分类列出来目标文档的章节骨架让AI知道要往哪个框架里填内容特殊要求比如默认读者是刚入职的新员工语言要口语化步骤里的按钮名称必须用原样AI输出提纲之后你一定要人工过一遍重点关注三件事主流程是否完整从用户进入系统到完成核心任务有没有断档异常分支是否覆盖如果没有权限怎么办必填项没填会提示什么网络超时怎么处理章节粒度是否一致同一层级的章节信息量差不多不要出现某章巨细无遗、另一章只有一行的情况。提纲阶段我一般会让AI至少迭代两轮。第一轮AI给出骨架我补业务背景第二轮我把补充信息塞回去让AI调整结构和取舍。这一步看起来有点笨其实是在和AI“对齐认知”后面写正文的速度反而会很快。2.3 第三步逐节生成初稿提纲定稿后有一个非常重要的执行原则不要一次性让AI生成全文。原因很实际一次性生成全文AI很容易在后面的章节里“忘记”前面章节已经说过的细节或者出现前后术语不一致的情况。另外一次性输出超过一定长度的文本AI为了保证整体连贯性往往会优先保结构而牺牲细节导致内容变得泛泛而谈。我习惯按功能模块分批生成每个模块单独一轮对话。比如一个电商后台的指南会分这样几轮第一轮账号登录、权限配置、组织架构管理第二轮商品创建、上下架、库存管理第三轮订单处理全流程第四轮数据报表与导出每一轮生成时除了给AI该模块对应的源材料还要把“已生成章节里提到的相关功能”作为背景附上去。比如第二轮生成商品管理时告诉AI“第一轮里提到了运营角色的权限范围涉及商品的增删改需要以该权限为前提”。这个方法执行下来指南的模块边界会非常清晰而且模块之间的交叉引用也不会乱。2.4 第四步用“三遍法”校验初稿全部生成之后不要急着排版发布。我在实践中总结了一个“三遍法”校验流程专治AI生成内容的隐性错误。第一遍行为倒查。拿到初稿后挑出每一段“操作步骤”人工或让AI辅助反推这些步骤对应的代码逻辑或接口定义是否存在。比如指南里写了“点击右上角的导出按钮可将当前列表导出为Excel”就去代码里搜导出按钮相关的事件绑定和导出接口。如果代码里根本没有对应实现这步就是幻觉必须删掉或标记为待验证。第二遍数字与名称核对。AI特别喜欢自己发挥小细节比如把按钮名称从“确认”悄悄写成“确定”把字段名从“客户名称”写成“公司名称”。这在学校写作业没关系在软件使用指南里是大忌——用户照着文档找不到按钮第一反应是文档错了而不是自己看漏了。所以每一个按钮名、菜单名、字段名、快捷键、弹窗文案都要对着截图或代码逐一核对。第三遍读者视角体验。最后把自己当成第一次用这个软件的新人按照指南从头操作一遍。这一步最能发现问题——你会发现“哦原来这步做完之后界面会跳到一个新页面指南里没写”“这里虽然写了要上传文件但没说文件格式要求”。体验过程记得录音录屏回头把发现的问题一次性修改。这一套流程下来“无中生有”初稿到可交付状态的时间在多数项目里只需要两三个工作日比传统模式快太多了。3. 让AI稳定输出高质量指南的提示词工程同样的AI不同人用出来效果天差地别——差别几乎全在提示词的设计上。我调研过很多团队的prompt发现“无中生有”做得好的团队提示词通常不是一段非常长的咒语而是结构清晰、分工明确的一组规则。分享几个经过大量实测验证有效的提示词设计思路。下面这些不是所谓的“万能模板”但可以当作一个高质量的起点根据项目调整使用。3.1 角色与目标的设定逻辑提示词里的角色设定很多人的写法是“你是一名资深技术文档工程师”但实测下来更有效的是给它一个双角色设定“既懂技术又懂用户”的复合视角。为什么因为纯文档工程师角色AI会倾向于输出规范但保守的文档把所有信息放到安全的位置而纯“资深用户”角色AI又会输出主观体验式的内容缺少严谨的边界约束。两者融合之后AI能自己把握一个度——知道什么时候该解释技术名词什么时候直接给操作路径。我的角色设定通常是这样一段你是一名有十年经验的技术传播顾问同时是这款产品的重度用户。你的职责是把工程师视角的技术信息转化为新用户能直接照做、无需额外解释的软件使用指南。你擅长从代码逻辑、接口定义和测试用例中反向推导用户操作路径并且清楚“哪些信息必须写出来、哪些信息留给用户自己去发现”。3.2 资料分层的注入方法前面提到过输入材料要分类整理这是提示词工程里最重要的前置动作。在提示词内部还需要再设计一下层次关系。我的做法是把资料按“主干资料”和“参考资料”分开。主干资料是AI生成时必须严格遵守的事实依据参考资料是风格参考或背景补充不强制对号入座。在提示词里留一个像下面这样的区块效果比一股脑乱塞好得多【主干资料必须依照以下资料生成内容】 - 路由定义见附件router.ts - 状态流转见附件order-status-machine.ts - 关键接口见附件order-api.yaml 【参考资料可借鉴结构与表达方式但不作为事实依据】 - 竞品指南XX系统操作手册.pdf - 历史工单客服FAQ-top50.xlsx这个区分非常重要。它让AI在生成时建立“事实边界”——主干材料里有的必须写得准确主干材料里没有的宁可写成“请以系统实际配置为准”也不要自作聪明地编造。没有这个区分AI很容易把参考资料的模块名错放到你家产品上。3.3 最有价值的追问方式多轮对话是“无中生有”的核心武器。第一轮拿到的是骨架和粗略内容第二、第三轮才是AI显现真正价值的时候。问题是大多数人不会追问只知道说“写详细一点”。这是最没用的指令。“写详细一点”之后AI会把已有的内容换个形式重新说一遍或者往里面塞一堆正确的废话。真正有用的追问应该往两个方向走一是边界穷举。让AI把每一个“用户可以做”的动作进行条件分支展开“在什么情况下这个按钮可用什么情况下不可用不可用时界面会是什么状态”比如追问“上传文件这个步骤有没有文件大小限制有没有格式限制上传失败时提示什么”这一问AI就会去检索主干材料里是否有相关定义有就写出来没有就明确标注“待确认”。二是反向验证。让AI站在“反方”立场找自己初稿的漏洞“请审阅你刚才生成的章节列出所有可能误导用户或缺少前置条件的地方并给出修订建议。”这种自我纠错式追问实测每次都能抓到至少三五个硬伤比如前置条件漏写、步骤顺序倒置、异常分支缺失等。顺便说一句追问不是让你无限循环几小时通常每个模块两到三轮就够了。再多边际收益就很低了真正要做的还是靠人工验证去兜底。3.4 一份可以直接抄的提示词模板给一个可以直接套用的模板。这个模板用在“生成单个功能模块指南”的场景效果最稳定。# 角色 你是一名技术传播顾问同时是这款产品的资深用户。 # 任务 根据以下主干资料生成“订单管理”模块的使用指南。 目标读者刚入职的运营人员能看懂中文但没有任何系统使用经验。 # 指南结构要求 1. 功能概述这个模块做什么、帮用户解决什么问题不超过100字 2. 前置条件要完成本模块操作用户在系统里必须具备什么权限、已完成什么设置 3. 操作步骤按顺序编号每一步包括入口在哪里、页面长什么样、操作了什么、结果是什么 4. 异常处理每个操作步骤可能出现的常见错误提示与解决方法 # 表达规则 - 按钮和菜单名称必须与代码中的文案保持一致禁止翻译或改写 - 步骤描述必须具体像“点击列表上方的‘新建’按钮”而不是“点击相应按钮” - 主干资料中没有的信息不要猜测写“请以系统实际界面为准” # 主干资料 [在这里粘贴路由定义、状态机定义、接口定义等材料] # 输出格式 用中文Markdown输出二级标题为“订单管理”具体内容按上述四段结构展开。这套模板的本质是预先给AI设定了“事实边界”“结构边界”“表达边界”让它的想象空间被限制在合理范围内而不是放任它自由发挥。4. 无中生有技术的验证闭环不跑通就不算写完无中生有的最大风险是写出来的东西看起来对但实际不对。所以验证环节是整个工作流里绝对不可跳过的部分。不少AI辅助生成指南的案例翻车就翻在验证环节——AI写得很流畅排版也很专业但用户照着操作就是卡住。要避免这种局面需要一套闭环验证方法。4.1 连线验证把指南当测试用例无论是“无中生有”的还是传统的指南我始终推荐一种最硬核的验证方式——拿着文档去点系统。但不同之处在于AI辅助模式下我通常把验证动作提前到“文档还没完全定稿”的阶段。做法很简单把AI生成的初稿打印出来或放在副屏上从指南的第一个步骤开始跟着点。每一步都要确认指南里说的入口和实际界面是否一致操作完之后的界面反馈是否与指南描述一致步骤与步骤之间的过渡是否顺畅有没有遗漏中间页面这一轮下来你相当于用文档做了一次手工测试而且不是测软件是测文档。凡是走不通的地方要么是软件行为与文档不符要么是文档本身缺失了信息。无论是哪一种都需要记下来回到AI对话里修正或直接人工改掉。我习惯给每个功能模块记录一个“验证结果表”字段就三个文档步骤、实际行为、处理结论一致/修正文档/提缺陷单。跑完这个表文档才算是初步可用。4.2 与工程师的“半小时访谈”校验法文档工程师最常用的资源就是开发工程师但很多人在AI辅助开发流程里反而忘了这件事——因为AI生成的文档太像真的了容易让人放松警惕。我给自己定的规矩是任何AI生成的文档在发布之前至少要跟开发工程师做一次半小时的“找茬访谈”。访谈不是让工程师通读全文而是带着下面三个问题去问“这个模块的流程你预期的核心使用路径是什么有没有你反复跟别人解释、但写不到代码里的点”——这能补上隐性知识。“哪个功能是最近重构或修改过的行为和旧版不同”——这能防止AI基于旧代码写出过时内容。“你有没有遇到过用户总是理解错的地方”——这能帮你在文档里主动设计预警信息。访谈时记得录音回头把有效信息补进文档。老实说每次半小时访谈的收获比AI生成多少轮都管用。4.3 常用佐证工具版本分支、提交记录、代码注释还有一个很容易被忽视的线索来源Git仓库本身的元数据。代码里不会直接写“用户指南”但git提交记录会。你在git log里看到一条commit message写着feat: add bulk import wizard for customer list再配合这次提交涉及的文件变更基本可以推断出“批量导入客户列表”是一个有完整向导流程的功能。这种信息对AI生成指南很有价值它可以帮你圈定功能范围避免遗漏。我的习惯是把每个功能模块对应的git log整理成一页摘要连同代码片段一起喂给AI。尤其在“无中生有”模式下代码可能不完整或分支很乱git log反而能提供一个相对稳定的功能演进脉络。另外自动化测试用例也是极好的校验素材。一个端到端测试用例通常长这样test_should_create_order_with_valid_coupon_and_receive_success_message——看到这条你就知道系统里应该存在“优惠券”这个元素用优惠券下单会返回成功提示。如果指南里没写优惠券相关内容说明文档有缺口反过来如果指南里写了优惠券但测试里根本没有相关用例那就要警惕是不是AI自己加戏。5. 实测中的翻车现场与修订技巧“无中生有”听着先进但实际落地时翻车的姿势五花八门。我挑三个最典型的案例每个都踩过坑修复过程中总结了不少经验。这些经验同样适用于所有AI辅助开发文档的场景。5.1 翻车案例一把配置项写进普通步骤里某项目AI根据后端配置Schema生成了一版“系统参数设置”的使用指南。它把所有配置项按字母顺序排列每个配置项都写了“名称、含义、取值范围、默认值”。表面上看信息非常完整问题出在表达方式上——它把“配置SMTP服务器地址”和“点击页面右上角的保存按钮”混在同一个编号列表里。新用户照着配置的时候经常分不清楚哪些是可选项、哪些是必填项哪些改了立即生效、哪些需要重启服务。这事的根因是AI看到了“一堆配置项”但没有理解“配置项之间的关系以及它们在用户操作流程中的位置”。修复思路后来固化成一条规则指南里必须把“参数配置说明”和“操作步骤”分成两个独立章节。参数配置用表格呈现参数名、说明、是否必填、默认值、生效时机。操作步骤则围绕“如何进入配置页、如何修改、如何保存发布”这些顺承动作展开。这样分层之后两类信息互相不干扰用户查参数时看表格操作时看步骤两个都很顺手。5.2 翻车案例二接口文档与产品行为不一致AI经常会优先相信接口文档因为接口文档看起来是最“硬核”的事实来源。但现实中接口文档滞后于产品行为是常态。比如一个系统的OpenAPI里还写着“单个订单最多允许添加50个商品”但前端页面早就把上限改成了200。AI基于接口文档生成指南的时候就会理直气壮地写出“一次最多添加50个商品”而实际用户添加第51个商品时点“添加”按钮毫无反应——体验极为糟糕。这个坑的启发是接口文档描述的是“契约”但不一定是“当前实现”。在AI辅助开发流程中如果发现接口文档和产品行为冲突应该以“能跑通的实际情况”为准。怎么发现冲突靠的就是前面说的连线验证。遇到这种情况我的处理方式是在文档里标注为“上限以系统实际界面提示为准”不写死具体数字同时提一个文档缺陷单给负责接口文档的同事提醒更新在内部知识库里记录这个差异防止下次其他文档再次被带偏5.3 翻车案例三流程边界缺失导致用户误操作AI特别容易默认用户是“严格按照文档顺序操作的乖宝宝”但实际用户经常跳着来或者在中途停下来离开几天再回来。有一次AI生成一份“数据导入导出”指南导入流程写得非常清晰下载模板、填写数据、上传文件、预览校验、确认导入。但缺了一个关键边界——“确认导入”之前用户可以先关闭页面离开吗后来客服经常接到电话说“我明明点了确认导入为什么第二天数据没进去”排查发现是用户在前一天填完模板后直接关掉了浏览器而系统设计里导入任务在关闭页面后并不会取消但如果用户选择的是“仅预览校验”则关闭后任务不会真正执行。AI缺少“用户可能在半路离开”的意识这是“无中生有”类AI的天然短板因为它没有真实用过产品不知道用户会有多不按套路出牌。补丁方法是在验证环节增加“中断操作”检查——每个流程尤其是多步骤流程都要问自己三个问题用户做到第N步时如果关掉页面/退出App会发生什么再回来时界面会停留在哪里数据会不会丢文档里有没有明确告诉用户“中途退出前必须完成什么”把这些检查项塞给AI做第二轮追问通常能补齐不少边界信息。但最终确认仍然要靠访谈工程师——只有他们知道系统在“半途离开”场景下真正做了什么处理。6. AI辅助文档生产对技术传播岗位的影响做技术传播的人这两年多少都有点焦虑担心AI把自己的饭碗端了。我的观察是AI确实会改变很多工作方式但它改变最大的不是“岗位是否存在”而是“岗位的能力模型”。6.1 效率提升只是表面真正的变化是生产方式传统软件使用指南的生产方式本质是“记录整理美化”。工程师做完功能文档工程师去体验、去截图、去记录然后组织成用户能看懂的形态。这套流程的重心在“采集”和“表达”。而AI辅助开发模式下生产方式变成了“推导验证判断”。AI负责把线索推导成初稿把千篇一律的“打开页面-点击按钮-填写表单”这类常规描述自动完成技术传播人员的工作重心前移变成——定义“哪些材料喂给AI、哪些信息不能靠AI猜”设计“文档的叙事结构和信息架构”甄别“AI生成的哪儿对、哪儿错、哪儿没法判断”补齐“AI永远学不会的业务意图和人际智慧”换句话说原来一天要花六小时写稿现在两小时就能生成初稿剩下的六小时都花在校准、验证和打磨上。文档工程师从“写作者”变成“质检员架构师”。6.2 对人的新要求会问、会验证、会取舍我面试过不少想转技术传播的候选人都会问一个问题“给你一份代码仓库你能在一天内整理出这个产品的功能清单吗”过去这听起来像刁难但现在这基本是基本功了。在AI辅助开发时代技术传播人员最需要练三件事第一会问问题。不是面向AI问而是面向业务和研发问。AI没法判断业务意图你得会问“这个功能的核心场景是什么”“这部分用户经常搞错什么”。问不出来文档就永远只能浮在表面。第二会做验证。AI生成的文档再像样也不过是“假设”。你得有能力把假设变成结论无论是自己实测还是找工程师确认。这个能力决定文档的可靠性——不会验证的文档工程师在AI时代会变成“AI幻觉的扩音器”写出来的东西越多风险越大。第三会取舍。AI会给你大量信息但不是每条都有必要写进指南。过滤的标准是什么我认为是“用户不做会不会出错”。比如“系统会在每日0点自动执行备份”这种信息用户知不知道不影響操作那就没必要写。反之“上传的图片不要包含敏感信息因为系统会默认公开至企业相册”这种信息直接关系到安全与隐私就必须放在显眼位置。取舍能力本质是产品感觉这个很难被AI替代。6.3 后续可以这样做一点经验扩展最后分享一个小技巧也是我最近在尝试的方向把AI辅助生成的“无中生有”指南直接反哺给AI做客服知识库或在线帮助中心的基础语料。因为AI生成的文档结构规整、术语统一稍作转换就能变成很好的FAQ数据库语料。但切记反哺之前必须确保文档已经过了完整的实测验证。用未经验证的AI生成内容去训练另一个AI等于把偏差复制粘贴后果你懂的。从我自己的实操体会来说“无中生有”这套方法最有价值的不是帮你省了多少小时而是它逼着你把技术传播的工作方式从“等别人做完”改成“先系统性地做出来再逐步修正”。这玩意儿一旦用顺手你会发现自己对产品的理解深度反而比单纯等着文档素材的时候强得多——因为你要亲自去读代码、翻Git记录、找工程师对答案这些东西过去你可能从来不会主动碰。