技能提升网产品团队只改了一个字段名，客服第二天却发现，旧名称同时藏在帮助中心截图、培训练习题和标准回复里。更麻烦的是，字段背后的判断条件也跟着变了。
AI可以建立引用关系和候选影响矩阵，不能看到同一个词就批量替换。每一处命中都要判断它是名称、规则、示例还是历史记录。
把变更说明写成可追踪的原子项
本轮输入限定为变更后的规则说明、帮助文档、培训材料、客服标准话术。每份资料先记录来源、时间和版本；关键资料缺失时，把缺口写进清单，不用相似记录补齐。
搜索旧词之外还要追条件和示例
| 步骤 | 具体做法 |
|---|---|
| 拆变更 | 记录旧值、新值、生效日、条件变化和不变部分。 |
| 建立内容清单 | 列出帮助页、培训稿、客服话术、截图和所有者。 |
| 搜索影响 | 同时查旧名称、字段定义、条件表达、示例数字和截图。 |
| 分配更新 | 标明改名、重写、重拍截图、无需改和待确认。 |
同一命中为何会有不同改法
| 情况 | 判断依据 | 处理 |
|---|---|---|
| 直接改名 | 语义不变且只出现旧标签 | 替换后复核上下文 |
| 逻辑重写 | 判断条件或流程变化 | 重写步骤与示例 |
| 截图更新 | 界面字段已经改变 | 安排重新截取 |
| 保留历史 | 明确描述旧版本行为 | 加版本标识，不替换 |
这一步真正要作出的决定是哪些下游内容受到影响，哪些只需改名，哪些流程和示例必须重写。无法回到原始证据的结论只能标为待确认，不能进入正式交付。
用一个字段变化做全链路试跑
挑一个字段改名且规则阈值也变化的例子，确保文字、流程图、截图和客服模板都进入检查。
试跑后还要从判定正常的结果中抽查，若发现漏检，就修正规则并重跑受影响范围。最终验收目标是跨文档影响矩阵和更新责任清单。
跨文档检查指令示例
你正在协助负责产品变更落地的产品运营或知识管理人员。触发情况是核心业务规则或字段定义已更新，但多个下游文档仍引用旧名称和旧判断条件。只读取变更后的规则说明、帮助文档、培训材料、客服标准话术。需要判断哪些下游内容受到影响，哪些只需改名，哪些流程和示例必须重写。交付跨文档影响矩阵和更新责任清单。每条结论标出来源位置、版本和待确认人。第一轮只生成预览，不发送、不删除、不写回正式系统。
产品变更影响检查的输出先保存在预览区。经办人逐条关闭异常并记录修改理由，高风险动作由有权限的人执行。
交付前最后检查产品变更影响检查
- 变更项已拆成名称和逻辑
- 影响清单覆盖全部内容类型
- 历史说明没有被误改
- 每个更新项有负责人和截止日
如果继续自动处理可能导致客户和内部团队继续按旧规则操作，造成解释冲突和重复工单，就停止在当前步骤并指定接管人。批量替换前必须预览，正式发布由各内容所有者批准。
文档同步可组合哪些Skill
Notion Skill负责搜索知识页面中的旧字段与旧规则，输入是变更说明和知识空间，输出受影响帮助文档；PPTX Skill负责读取培训演示材料中的相关页面，输入是培训材料，输出受影响页面和备注；文档一致性校对助手负责比较多份材料中的术语、条件和示例，输入是帮助文档、培训材料和客服话术，输出跨文档影响矩阵。产品变更影响检查的能力之间通过带来源的中间表交接，不把未核实判断直接传给下一步。
产品变更影响检查的Skill边界是：只访问明确共享给集成的内容，写入前确认目标页面、字段和状态；多版本合并要先保留原稿并记录页面来源，自动合并不能代替内容冲突裁决；擅长发现内部不一致，不能单独证明事实真实；行业标准状态需要最新权威来源复核
