用 AI 做产品说明书与用户手册

新买的空气炸锅，第一次用之前翻说明书，目录写着「第一章 产品概述、第二章 功能模块、第三章 技术参数」。想找的是「第一次怎么预热」，翻到第四页才看到一行小字。这类手册不是写得不用心，是组织方式错了：它按产品的结构写，用户按自己的任务找。用 AI 重写手册，价值就在于把这个顺序倒过来。

手册没人看，问题出在目录

按功能分章的手册，回答的是「我们有什么」。用户要的答案是「我要做某件事，该按哪里」。两种逻辑对不上，结果就是手册印得挺厚，客服电话照样响。

判断一本手册的组织方式对不对，看目录就行：目录里全是名词（功能模块、参数说明、接口定义），那是产品视角；目录里是动作（第一次开机怎么设置、怎么连手机、卡住了怎么办），那是用户视角。前者适合研发内部存档，后者才是给用户看的。

这个转换恰好是语言模型擅长的：它见过大量「用户问什么、答案长什么样」的配对，能把一串功能名反推成一串任务。前提是你把功能清单和真实用户场景一起给它。

功能清单改成任务清单：五步重排

改造的顺序比想象中固定，五步：

第二步最容易走过场。判断一条任务是不是真任务有个笨办法：念给一个没用过这产品的人听，他能不能立刻知道要做什么。「设置网络」不算任务，「连上家里的 WiFi」算。

一步一动作，一句话一个结果

步骤的写法有三条硬要求。一步只做一件事，别在「点击设置」后面接上「选择网络、输入密码、保存」；动词开头，写「点击右上角的齿轮」而不是「右上角有一个设置按钮」；说清结果，每步末尾告诉用户应该看到什么，看不到就是出了问题。

这三条看着琐碎，实际决定了手册能不能用。用户照着做的时候，是在找「我这一步做对了吗」的确认信号，没有确认信号，他就会怀疑自己，然后去打客服电话。

段落长度也有讲究。一步写成一整段，用户会跳过；拆成两行加一个加粗的动作词，完成率明显不同。手机上看手册的人尤其如此，屏幕小，一段超过四行就不想读。

界面名称和前提条件，只能回产品里核

模型不知道你的按钮叫什么。它会按行业惯例写「点击保存」，而你的产品里那个按钮可能叫「完成」，位置在左下角。这类错误最伤，因为用户会以为是自己的问题。

前提条件也常被漏掉：需不需要登录、要不要先绑定设备、免费版有没有这个功能、从旧版本升上来要不要迁移数据。模型默认这些都不存在，因为它看不到你的产品逻辑。核对时按顺序问三句：这一步之前必须满足什么、这一步之后状态变成什么、什么情况下这一步根本不会出现。

如果产品有知识库或者帮助中心，把这些内容作为检索来源交给模型，比让它凭空写稳得多——这就是RAG 的思路，先取回真实文档，再组织语言。

它写得出手册，替代不了走一遍

先把它写不出的部分划出来。第一，它不知道你的产品实际长什么样，界面、流程、限制都得你提供。第二，它判断不了哪些功能值得写——刚上线的小功能和一个每天被用一百次的功能，在它眼里分量一样。第三，它不会替你发现产品本身的设计问题：如果某个操作需要五步，模型能把这五步写清楚，但为什么需要五步，只有走一遍的人才会问。

还有一个更隐蔽的风险：模型会顺手补上产品里没有的能力。你给它一份功能清单，它可能写出「支持批量导入」这种听起来合理、实际没做的功能。这类内容进了手册，等于给客服埋雷。防范办法是在提示词里写死一条：只使用我提供的功能，不确定的地方标注出来让我确认。相关机制和AI 幻觉同源，不是它想骗你，是它在补全模式。

多语言版本要格外小心。术语翻译不一致、单位换算错、截图还是旧版界面，这三类问题在翻译版里出现得最多，而它们恰恰是海外用户第一次接触产品时看到的。

好手册的标准只有一条

用户照着做，能不能把这件事做成。所有关于排版、语气、配图的讨论，都排在这条后面。

验证方法也简单：找一个没用过产品的人，给他手册和一个任务，看他卡在哪。卡住的地方就是手册要改的地方，而不是你觉得写得不够漂亮的地方。这一步花的时间，比让 AI 再改三版都值。

写提示词时也一样，把「用户是谁、他要完成什么」放在最前面，格式要求放后面。这类结构和通用的提示词写法一致：任务越具体，产出越可用。

速查：手册改造的检查项

• 目录里是动作还是名词，一眼就能看出视角对不对
• 每条任务念给外行听，他能立刻知道要做什么
• 一步一个动作，动词开头，写清做完看到什么
• 界面名称、前提条件、版本差异，逐条回产品核对
• 找一个新人照着手册做一遍，卡住的地方就是要改的地方