当产品文档随着不断撰写越来越多之后, 最大的问题并非是不存在信息资料, 而是信息资料呈现出分散的状态, 版本处于混乱的情况, 并且接口说明与业务说明之间相互不匹配。在新人接手的时候, 常常需要在多个文档间反复地进行跳转。
Claude能够首先去阅读产品说明这般的内容、需求文档以及历史变更方面的情况, 进而整理得出业务的结构；Codex随后要将接口的说明、字段相关的表格、使用的示例以及有待确认的项目整理成为开发过程中更方便使用的格式。
适合人群如下, 一是产品经理, 二是技术负责人, 三是售前团队, 四是开发团队, 五是需要维护产品文档的人。
文中的API Key全都要用 `sk-xxxxxxxx` 进行占位, 真实的配置, 实实在在的密钥以及后台数据仅仅是在自己的账号里运用, 不要将其公开到文章, 不要公开到截图, 不要公开到群聊, 也不要公开到代码仓库。
文章目录
1. 产品文档整理先找版本冲突
2. Claude 负责理解业务逻辑
3. Codex 负责生成接口说明和示例
4. 接入模型前，后台信息应该怎么准备
5. 从一个样板跑通到批量处理的流程
6. 交付或发布前怎么检查质量
1、产品文档整理先找版本冲突
着手进行产品文档整理的时候, 要先去查找版本冲突, 其关键之处并非是让人工智能替自己毫无依据地施展, 而是要将原本杂乱无章的材料梳理成能够进行检查、可以重复使用、能够加以扩展的工作流程。实际上, 那些能够长期得以运用的自动化流程, 起先都并非是完全自动化的, 而是开始先运行成功一个小型的样板, 进而再将这个样板转变成为固定的模板, 就是这样。
先建立资料清单
列出需求文档, 还要列出接口文档, 接着列出FAQ, 再列出更新记录, 最后列出客户反馈, 并且得标记出更新时间以及负责人。要是资料来源不清楚的话, 那后面整理出来的内容也是不可信的。
把冲突内容单独标记
假使存在两个文档, 针对同一个功能, 其说法不一样, 那么不要让AI采取直接二选一的做法。要先进行标记冲突的操作, 之后再由负责人予以确认。
于实际业务当中, 头一步最好莫要去追求数量, 先挑选一个当下正在做的项目, 将其相关资料、目标、输出格式以及验收标准明确记录清楚, 随后再让模型介入参与, 似这般能够迅速 discern, 哪些环节适配 Claude, 哪些环节契合 Codex, 哪些环节硬性要求保留人工予以确认。
2、Claude 负责理解业务逻辑
处理理解、归纳、改写以及长文本拆解, Claude实则更具适配性。它能够针对一堆原始材料, 先行整理为结构化内容, 而后把复杂表达变换成更契合业务场景的表述方式。在这个阶段, 切莫急于径直使它生成最终成果, 而是要先让它输出中间结果。
给 Claude 明确材料和边界
要是输入的材料处于特别杂乱的状况, 那么输出随之也会变得杂乱起来。提出建议在提示词内清晰说明四件事情: 资料的来源, 目标读者, 输出的格式, 禁止进行编造。特别是当涉及到产品、价格、服务以及承诺的时候, 务必要要求其标记“需要人工确认”的相关内容。
示例指令
请去阅读下面所呈现的产品资料, 将功能模块、用户流程、接口依赖以及文档冲突点给整理出来, 千万不要擅自去补全那些不存在依据的字段。
生成结果呈现出来以后, 首先安排人工查看三点, 其一是有没有重复的内容, 其二是有无编造的信息, 其三是是否切实符合当下的业务场景。经过这一步骤之后, 才进入批量整理环节。
3、Codex 负责生成接口说明和示例
Codex能够将经过确认的内容, 整编成字段表、请求示例、响应示例、错误说明以及变更记录, 之后, 开发团队拿到它时, 接入会变得更加容易。
固定字段比自由发挥更重要
将批量任务每次输出格式都不一样视为最为惧怕的情况, 提出固定字段的建议, 接着让 Codex 生成表格, 再生成文件, 然后生成目录, 最后生成脚本, 在字段固定完成之后, 后续导入平台工作会更为顺畅, 交给同事也会更为顺手, 进行复盘同样更为顺利。
先输出草稿，不要直接替你发布
Codex 可协助你去读文件, 还能整理内容并生成脚本, 然而外部发布、权限变更、扣费、删除以及批量发送这些情况, 都应当保留人工确认。越是需长期使用的流程, 越是要把具有风险的动作单独提取出来。
API密钥页：确认文档生成工具调用凭证
4、接入模型前开云手机入口app下载开云真人app,开云真人app地址，后台信息应该怎么准备
不管你使用Claude, 还是Codex, 亦或是脚本, 又都或者表格工具, 甚至是内部系统, 最终都得让工具稳定调用模型, 这里既不要凭借记忆进行配置, 也不能去复制别人文章里的密钥示例, 正确的做法是打开自己的后台, 确认API Key, 确认模型权限, 确认分组, 确认通道状态, 确认配置片段。
API Key 不是登录密码
程序调用模型的凭证乃 API By Key, 一般仅展示一回。复制之后需妥善予以保存, 切莫将完整的 Key 置入公开的截图或者文章之中。教程里只需留存 `sk-xxxxxxxx` 这般的占位符便可以了。
后台截图要放在对应步骤
图文教程之中的截图, 应当对当前步骤作出解释, 而并非统一堆放在文章末尾之处。讲述接入准备之际, 放置密钥页；讲述复制配置之时, 放置使用密钥弹窗；讲述批量任务复盘之际, 放置用量记录页。只有如此, 读者方可明白每张图对应哪一个操作。
5、从一个样板跑通到批量处理的流程
下面是一套适合小白照着做的流程，不需要一次做到很复杂。
第一步：建立资料清单
第二步：Claude 找出业务结构
将材料交付给Claude, 让其进行第一轮的理解, 同时展开拆解, 要求该Claude标记出不确定的信息, 并且须避免把猜测当作事实来写。
第三步：人工确认冲突信息
由人去实行查验边界以及敏感信息的操作, 进而对哪些内容能够予以公开, 哪些内容仅能用以内部使用来进行确定。
第四步：Codex 生成接口说明
让Codex将那经过确认的内容, 整理成表格, 或者变成文件夹结构, 亦或是弄成固定模板, 以此方便后续进行批量复用。
第五步：把变更记录持续更新
于发布之后, 或者交付之后, 记录所得结果, 其中涵盖阅读情况, 转化情形, 问题反馈内容, 调用量数值, 以及需调整之处。
6、交付或发布前怎么检查质量
在发布之前, 起码得检查四样情形, 标题是不是契合真实需要, 正文有没有完整架构, 图片是不是插在了对应地方, 参考链接是不是仅出现一回, 不能仅仅去看文章可不可以发出去, 还得看读者能不能依照着做。
检查内容是否可执行
若一段内容只是一味地提及所谓提升效率、降低成本之类的表述, 却并未明明白白地告知读者究竟该如何去准备材料, 如何依样复制配置, 如何细致检查结果, 那么这样的内容, 就势必要重新撰写, 且每个步骤都得切实去落脚到具体的动作上才行。
检查图片是否真实可见
任何一张图片, 都务必在平台编辑器之中呈现出正常的状态, 绝不能够是本地路径的形式, 绝不能够出现 404 的情况, 绝不能够全部堆积于文章的末尾之处。真实的后台截图, 必须要与正文的步骤相互对应, 图注同样也要对其用途作出说明。
检查是否适合复用
将此次的提示词记录下来, 把字段表记下来, 记下截图位置开云app官方入口网站，记录发布平台, 记录审核结果。下次做同类内容之际, 能够依据这套流程持续优化之便, 而非一切从初始开始去行动。
最后的总结是: 关于产品文档过多如何进行整理这件事情, 真正具备价值的地方并非是一次产出诸多内容。而是要将业务材料、模型理解、自动整理、后台接入以及质量复盘连接成为一条稳固定型的流程。先去成功运行一个样板, 之后再逐步实现批量化, 如此一来, 所产生的效果相较于直接一味追求全自动会更加稳健。
教程文档参考：https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg
标签： 产品文档 AI工具 Claude Codex 自动化流程
还木有评论哦，快来抢沙发吧~