name: decontextualize-text
description: 将带私有背景或内部依赖的文本转为通用、无偏见的表达。在抽象方法论、跨团队知识共享、脱敏处理及准备公开文档时使用。
tags: [writing, security, privacy, generalization]
related_skills: [generate-standard-readme]
version: 1.2.0
recommended_scope: user

Skill: 去上下文化 (Decontextualize Text)

目的 (Purpose)

将带有私有背景、隐含上下文或特定环境依赖的内容，转换为通用、可复用的表达。通过移除或替换特定标识符，使内容在不同环境（跨团队、跨公司、公共领域）中均能被正确理解，同时保护组织隐私。

适用场景 (Use Cases)

• 知识泛化：将特定项目的经验总结抽象为通用的方法论或最佳实践。
• 跨团队协作：移除仅内部团队可理解的黑话、代号，使协作方能无障碍阅读文档。
• 内容脱敏：在分享案例或技术博客时，过滤掉敏感的项目名称、人员信息和内部地址。
• 发布准备：作为将内部内容同步到外部公共环境（如开源、移交）的最后清理步骤。
• 文档同步：在分叉 (Fork) 或合并 (Merge) 跨组织代码库后，清理过时的环境依赖描述。

何时使用：当需要打破“由于环境差异带来的理解阻碍”或“信息安全边界”时。

行为要求 (Behavior)

核心原则

• 保留「做什么」与「为什么」。
• 去除「是谁」「在哪」「基于什么内部条件」。
• 将专有名词替换为通用描述（如“内部系统”“某业务流程”）。
• 将隐含前提改为显式前提，或直接移除。

交互策略 (Interaction Policy)

• 疑似核对：当识别到可能具有敏感属性但无法确定其通用性的词汇（如不确定的缩写或内部服务器代号）时，必须先列出清单请用户确认，而非直接重载。
• 多选重写：针对核心逻辑，可提供 2-3 种不同抽象程度的重写方案供用户选择。

处理流程

1. 识别敏感词：扫描文本中的公司名、项目代号、内部服务器地址、人员姓名。
2. 提取核心逻辑：分析操作步骤的本质（例如“JIRA 审批”本质是“任务状态变更评审”）。
3. 通用化重写：使用中性词汇重写识别出的部分。
4. 结构对齐：确保改动后的段落结构与原文保持一致，不丢失能力边界。

输入与输出 (Input & Output)

输入 (Input)

• 包含以下一种或多种特征的文本：
• 特定组织、公司、项目、系统名称。
• 内部约定、隐含背景、默认前提。
• 仅在特定环境下成立的流程或假设。

输出 (Output)

• 通用版本：去除或替换私有上下文后的文本。
• 结构化保留：输出必须严格保留原有的逻辑层级、Markdown 格式及功能性指令。
• 可复用性：输出应达到“即插即用”的标准，无需第三方额外获取背景知识。

禁止行为 (Restrictions)

• 禁虚构：不得虚构原文中不存在的背景或能力。
• 禁推断：不得补充未明确给出的事实或结论。
• 禁注入：不得引入新的业务语义。
• 禁残留：不得保留任何可反向识别具体组织或个人的信息（如唯一性高的代数、内部流程编号、非公开术语等）。

质量检查 (Self-Check)

• [ ] 独立性：不知道原始上下文，也能完全理解内容。
• [ ] 匿名性：难以通过搜索推断其来源于哪家公司或项目。
• [ ] 一致性：核心逻辑和功能与原文完全一致。
• [ ] 合规性：符合数据脱敏规范或公共发布的隐私安全标准。

示例 (Examples)

示例 1：内部流程 → 通用表述

示例 2：系统与调用方式 → 中性描述

示例 3：多维度指令 → 抽象逻辑