技能提升网“导出后只有表头，没有数据。”这个问题刚答完，又被另一位客服问了一次。翻到已关闭工单，处理结果只写着“已解决”，具体操作还埋在十几轮聊天中。
将对话原样复制到帮助中心，读者仍然不知道自己是否适用，也不知道做完后怎样判断成功。
值得沉淀的是已经确认的条件、处理办法和失败出口。下面延续虚构工单 T204，演示怎样把处理记录整理成一篇客户能照着判断的帮助文档；产品版本和参数都是教学设定。
“已解决”后面，需要找到什么证据
为演示后续整理，假设 T204 已完成排查：虚构系统 v2.3 的某个导出模块在特定条件下，选择超过 7 天的数据范围会返回只有表头的文件；相关人员确认，按不超过 7 天分段导出可以暂时完成业务。客户已确认拿到需要的数据，但产品缺陷尚未永久修复。
这些条件需要来自实际处理记录，不能因为工单被关闭就自行补齐。真实创作时应拿到现象、版本、账号权限、复现条件、已确认办法、验证结果和确认人。如果只有“试试缩小范围”，还不够把它写成已验证的解决方案。
还要区分工单状态与产品状态。客户通过临时办法恢复工作，工单可能关闭；对应缺陷仍然可能在修复中。帮助文档应说明“临时处理办法”，不能写成“问题已经彻底修复”。
按客户搜的症状组织文章
kb-article 是 Anthropic 客服工作流中的帮助文档 Skill，适合从已解决工单、重复咨询和已确认临时办法生成文档草稿。原始说明要求辨认问题、方案、适用对象和文章类型，并补充来源与维护信息。
提供脱敏后的完整处理记录和已有帮助文档，先判断是补充旧文章还是新建。若没有连接知识库，搜索重复内容需要人工补做；不能因输入中没提供旧文章，就宣称知识库里没有相似内容。
本例标题可以定为“导出文件只有表头，没有数据时如何排查”，文首直接限定示例版本与受影响模块。客户往往描述看见的结果，不会搜索研发内部的缺陷编号；缺陷编号保留在内部维护记录里即可。
先排除不适用的情况，再给出操作
同样是“只有表头”，可能只是筛选范围本来没有记录，也可能是权限下不可见，未必就是 T204 的问题。文档第一步应让读者检查列表是否存在需要导出的数据；如果没有，先核对日期、筛选和权限。
只有列表有数据、版本和模块符合本例条件、时间范围又超过 7 天时，才进入已确认的临时处理分支。范围已经不超过 7 天仍失败，就应停止反复套用，转人工调查。不能给所有失败者同一条“缩小范围重试”的建议。
以下是一段可以放进示例帮助文档的操作说明，适用条件仅限上述虚构系统：
确认列表中存在目标记录，并记下本次起止日期。将日期范围拆为连续、不重叠且每段不超过 7 天的区间，分别导出。核对每份文件都有所需数据行，并检查全部区间覆盖原范围。若日期控件同时包含首尾两天，应避免相邻区间重复同一天；具体边界以系统实际定义为准。符合这些条件仍只有表头时，请记录发生时间、筛选范围、账号角色和可公开的错误提示，联系人工支持。
真实文档应使用产品实际页面名称和按钮文案。如果没有经过界面核验，就不要生成一串看起来像真的菜单路径；本例故意只描述必要操作，不伪装成某款产品的教程。
每个动作都要有一个成功标志
“点击导出”不是这段操作的终点。读者需要看到文件包含预期数据行，还要核对日期区间没有重叠或缺口。涉及分页、权限、汇总或去重时，数量核对依据应与产品规则一致，不能单凭页面上一个总数就判定导出完整。
验收文档时，可以找一位未参与处理的人，分别阅读“空列表”“超过 7 天”“7 天以内仍失败”三种案例，让他指出下一步和停止条件。再由熟悉产品的人确认版本、参数、临时办法和成功标准。这是发布前应完成的读者测试，不应写成本文已经对真实用户做过验证。
公开正文和内部证据各留什么
将公开文档记为 KB018，内部维护记录关联 T204，并保留原始证据、确认人和修订历史。对外正文只留下排查所需的症状、适用版本、操作条件、成功标志和联系支持需要提供的信息。
客户编号、完整报表、调试日志及内部讨论不必随文章公开。需要截图时使用脱敏且经过核验的真实页面，不让 AI 生成一个并不存在的操作界面；即便图片只是示意，也必须明确标注并与文字对应。
产品修复以后，旧办法不能无人负责
给 KB018 指定维护人，并把对应缺陷的状态变化列为更新触发条件。正式修复发布后，核验新版本是否仍需分段导出，再决定保留旧版本提示、更新步骤或归档过时内容。仅修改“更新时间”而不检查步骤，没有解决文档失效的问题。
衡量这篇帮助文档是否有用，可以观察后续同类咨询是否仍卡在某一步、客服是否还要补充同一段解释，以及读者能否准确判断不适用条件。没有实际数据前，不承诺减少多少工单。
现在就从一条处理记录完整、重复出现、解决条件明确的工单开始。先确认那条处理办法在什么情况下成立，再让 kb-article 组织文稿。读者需要的是能判断、能操作、失败后知道找谁的说明。
