Anti Distill

Language / 语言: This skill supports both English and Chinese. Detect the user's language from their first message and respond in the same language throughout.

>

本 Skill 支持中英文。根据用户第一条消息的语言，全程使用同一语言回复。

反蒸馏 Skill（Claude Code 版）

触发条件

当用户说以下任意内容时启动：

• /anti-distill
• "帮我清洗一下这个 skill"
• "反蒸馏"
• "帮我处理一下这份文档"
• "clean my skill"
• "anti-distill this"

---

工具使用规则

---

主流程

Step 1：接收输入

接收用户提供的文件，支持以下方式：

方式 A：指定文件路径 用户直接给出文件路径，用 Read 读取。

方式 B：指定 colleague-skill 目录 用户给出 colleagues/{slug}/ 路径，自动读取其中的：

• work.md
• persona.md
• meta.json
• 或 SKILL.md（如果是合并版）

方式 C：粘贴内容 用户直接粘贴文档内容。

方式 D：搜索本地文件 用户说"帮我找一下"，用 Glob 搜索 **/SKILL.md、**/work.md、**/persona.md 等文件。

读取完文件后，自动识别格式：

• colleague-skill 格式：检测到 ## Layer 0 或 PART A / PART B 或同时存在 work.md + persona.md
• 通用文档格式：其他任何 Markdown / TXT / PDF

告知用户：

已读取文件：{文件列表}
检测到格式：{colleague-skill 格式 / 通用文档格式}
总字数：约 {N} 字

下一步选择清洗强度。

---

Step 2：选择清洗强度

向用户展示三档选择：

选择清洗强度：

  [1] 轻度 — 只抽掉最核心的踩坑经验和故障记忆
      适合：公司会仔细审核内容的情况
      保留度：~80%

  [2] 中度（推荐）— 抽掉经验、判断直觉、人际网络、隐性上下文
      适合：大多数场景
      保留度：~60%

  [3] 重度 — 只保留通用知识骨架，其余全部替换
      适合：公司只看交没交、不细看内容的情况
      保留度：~40%

用户选择后进入分类阶段。

---

Step 3：分类标注

参考 ${CLAUDE_SKILL_DIR}/prompts/classifier.md 中的分类规则，对输入文档的每一个要点/段落进行分类。

根据检测到的格式选择处理方式：

如果是 colleague-skill 格式：

对 work.md 的每个要点： 参考 ${CLAUDE_SKILL_DIR}/prompts/classifier.md 中的六大高价值类别，标记为：

对 persona.md 的每一层：

如果是通用文档格式：

参考 ${CLAUDE_SKILL_DIR}/prompts/diluter_general.md 中的通用规则进行分类和替换。

不同清洗强度的分类阈值：

---

Step 4：预览

向用户展示分类结果。格式如下：

如果是 colleague-skill 格式，按文件分区展示：

=== 清洗预览（中度）===

📄 work.md

  ## 技术规范
  [SAFE]    "Java 17 + Spring Boot 3、MySQL 8、Redis、Kafka"
  [SAFE]    "函数单一职责，超过 50 行考虑拆分"
  [REMOVE]  "事务里不要放 HTTP 调用"
            → "事务边界设计注意合理性"
  [REMOVE]  "Redis key 必须设 TTL，不设的 PR 直接打回"
            → "缓存使用遵循团队规范"

  ## 经验知识库
  [REMOVE]  "Kafka 消费者必须做幂等，at-least-once 语义会重复消费"
            → "消息队列消费端注意可靠性"
  [DILUTE]  "用户 ID 对外暴露必须加密，不能直接用自增主键"
            → "敏感字段注意安全处理"
  [REMOVE]  "定时任务必须做分布式锁，多实例部署会踩坑"
            → "分布式环境下注意任务调度"

📄 persona.md

  ## Layer 0
  [REMOVE]  "遇到问题第一反应是找外部原因，绝不主动认错"
            → "遇到问题会先梳理完整背景再定位原因"
  [REMOVE]  "评价方案都先问 impact..."
            → "评价方案时注重可行性和收益"

  ## Layer 2 表达风格
  [DILUTE]  口头禅 "impact 是什么"
            → 移除，保留通用口头禅
  [REMOVE]  对话示例：被催进度 → "在推了，快了。"
            → "在处理中，有进展会同步。"

  ## Layer 3 决策
  [REMOVE]  优先级 "数据 > 技术可行性 > 业务合理性 > 人情关系"
            → "综合考虑技术和业务因素"

---
标记统计：SAFE 15 处 / DILUTE 8 处 / REMOVE 12 处 / MASK 2 处
预计清洗后字数：约 {N} 字（原文 {M} 字，{ratio}%）

确认执行？可以调整：
  - "第 X 条保留" — 把 REMOVE/DILUTE 改为 SAFE
  - "第 X 条也要删" — 把 SAFE 改为 REMOVE
  - "全部确认" — 执行清洗

如果是通用文档格式，按段落/要点展示。

用户可以逐条微调，直到满意后确认执行。

---

Step 5：执行清洗

用户确认后，生成两份输出：

输出 1：清洗后的文件（交差用）

如果是 colleague-skill 格式：

分别生成：

• {slug}_cleaned/work.md — 清洗后的 Work Skill
• {slug}_cleaned/persona.md — 清洗后的 Persona
• {slug}_cleaned/SKILL.md — 合并后的完整 Skill（结构与原版一致）
• {slug}_cleaned/meta.json — 复制原 meta.json（不修改）

目录用 Bash 创建：

mkdir -p {output_dir}_cleaned

文件用 Write 工具写入。

如果是通用文档格式：

• {filename}.cleaned.md — 清洗后的文档

清洗规则（严格遵守）： 1. 所有 [SAFE] 标记的内容原文保留 2. 所有 [DILUTE] 标记的内容按对应 diluter prompt 的策略替换 3. 所有 [REMOVE] 标记的内容按对应 diluter prompt 的策略替换为等长度通用内容 4. 所有 [MASK] 标记的内容替换为通用化表述 5. 保持原文的 Markdown 结构、标题层级、列表格式完全一致 6. 保持专业术语使用，不能降级为外行用语

输出 2：私人保留清单（自己留着）

路径：{slug}_private_backup.md 或 {filename}_private_backup.md

用 Write 工具写入，格式：

# {name} 核心知识备份

> 这是你真正的职业资产。清洗后的文件用来交差，这份留给自己。
> 生成时间：{timestamp}
> 清洗强度：{level}
> 原文件：{source_files}

---

## 一、踩坑经验

{所有标记为 REMOVE/DILUTE 的踩坑经验原文，保留完整上下文}

## 二、判断直觉

{所有被替换的判断逻辑原文}

## 三、人际网络

{所有被替换的关键人脉/协作信息}

## 四、隐性上下文

{所有被替换的架构决策背景、历史原因}

## 五、故障记忆

{所有被替换的故障排查经验}

## 六、独特行为模式

{所有被替换的个人特色描述——口头禅、反应模式、对话示例}

---

> 带着这份清单跳槽，它比任何 Skill 文件都值钱。

---

Step 6：验证

清洗完成后自动执行验证检查：

1. 字数比：清洗后字数 / 原文字数应在 85%-115% 之间

• 如果偏短：补充更多通用描述填充
• 如果偏长：精简替换内容

2. 结构完整：原文所有二级标题在清洗后必须存在 3. 要点密度：每个章节的列表项数量差异 < 30% 4. 术语一致：清洗后仍使用原文出现过的技术术语 5. 格式一致：Markdown 结构、列表风格与原文一致 6. 无空洞段：不能出现只有标题没有内容的章节

验证通过后告知用户：

✅ 清洗完成！

📄 交差文件：{cleaned_files}
🔒 私人备份：{backup_file}

验证结果：
  字数：{cleaned_count} 字（原文 {original_count} 字，{ratio}%）✓
  结构：所有章节完整 ✓
  密度：要点数量一致 ✓
  术语：专业度保持 ✓

交差文件看起来完整且专业，但核心知识已被抽掉。
私人备份里保存了你真正的职业资产，建议妥善保管。

如果验证不通过，自动修复后重新验证，直到通过为止。

---

边界情况处理

文件太短（< 500 字）

提醒用户："文件内容较少，清洗后可能过于空洞。建议选择轻度清洗。"

文件几乎全是通用知识

告知用户："分析后发现你的文件中大部分是通用知识，核心经验含量较低。这份文件本身替代性不强，可以考虑直接提交。"

用户想覆盖原文件

先确认："是否备份原文件到 {filename}.original.md？覆盖后无法恢复。"

非文本文件

如果用户提供的是图片/截图（如手写笔记、白板照片），用 Read 读取图片内容后，转为文本再进行清洗。

---

---

English Version

Anti-Distill Skill (Claude Code Edition)

Trigger Conditions

Activate when the user says:

• /anti-distill
• "Clean my skill"
• "Anti-distill this"
• "Help me clean this document"

---

Main Flow

Step 1: Receive Input

Accept files from the user:

• Option A: File path → Read the file
• Option B: colleague-skill directory → Read work.md, persona.md, meta.json
• Option C: Pasted content → Use directly
• Option D: Search → Glob for skill files

Auto-detect format:

• colleague-skill format: Contains ## Layer 0 or PART A / PART B
• General document format: Any other Markdown / TXT / PDF

Step 2: Choose Cleaning Intensity

Choose cleaning intensity:

  [1] Light — Remove only critical pitfall experience and failure memory
      For: When the company reviews content carefully
      Retention: ~80%

  [2] Medium (recommended) — Remove experience, judgment, network, context
      For: Most situations
      Retention: ~60%

  [3] Heavy — Keep only the generic knowledge skeleton
      For: When the company only checks submission, not content
      Retention: ~40%

Step 3: Classify Content

Refer to ${CLAUDE_SKILL_DIR}/prompts/classifier.md for classification rules.

Step 4: Preview

Show classification results to user. Allow per-item adjustments.

Step 5: Execute Cleaning

Generate two outputs: 1. Cleaned file (for submission) — looks complete, core knowledge removed 2. Private backup (for yourself) — all removed knowledge, organized by category

Step 6: Validate

Auto-check:

• Word count ratio: 85%-115% of original
• All section headers preserved
• Item density within 30%
• Technical terminology consistent
• No empty sections

---

Edge Cases

• File too short (< 500 words): Suggest light cleaning
• Mostly generic content: Inform user the file has low replaceability
• Overwrite original: Confirm and backup first
• Image input: Read image, extract text, then clean

张三示例：清洗前后对比

以 colleague-skill 项目中的示例同事"张三"（字节 2-1 后端工程师，INTJ，甩锅高手）为例，展示中度清洗效果。

---

work.md 清洗对比

技术规范 — Code Review 重点

清洗前：

你在 CR 时特别关注：
1. 有没有 N+1 查询问题
2. 事务边界是否合理（不要把 HTTP 调用放在事务里）
3. 异常处理是否完整（别只 catch Exception 然后吞掉）
4. 接口有没有做入参校验
5. 敏感字段（手机号、身份证）有没有脱敏

清洗后：

你在 CR 时特别关注：
1. 数据库查询性能是否合理
2. 事务边界设计是否合理
3. 异常处理是否完整规范
4. 接口设计是否考虑健壮性
5. 数据安全是否合规

每条看起来都对，但去掉了"怎么判断"和"具体查什么"。新人看完还是不知道该怎么做 CR。

---

经验知识库

清洗前：

- Redis 缓存的 key 必须设 TTL，不设 TTL 的 PR 直接打回
- 数据库字段加索引前先用 EXPLAIN 验证，不要猜
- 用户 ID 对外暴露必须加密，不能直接用自增主键
- 定时任务必须做分布式锁，多实例部署会踩坑
- Kafka 消费者必须做幂等，at-least-once 语义会重复消费

清洗后：

- 缓存使用遵循团队制定的规范
- 数据库索引设计注意性能验证
- 敏感字段注意安全处理
- 分布式环境下注意任务调度方案
- 消息队列消费端注意可靠性保障

五条经验，每条都被降级为"正确的废话"。原文是能直接执行的规则，清洗后是任何人都能写的注意事项。

---

工作流程 — 处理线上问题

清洗前：

1. 先看监控（错误率、延迟、日志）
2. 确认影响范围（多少用户、哪些接口）
3. 有止血方案先止血（回滚/降级），再查根因
4. 根因找到后写 incident report，格式：时间线 + 根因 + 修复 + 预防措施

清洗后：

1. 查看相关监控数据
2. 评估影响范围
3. 按标准流程处理并止血
4. 完成后撰写复盘文档

---

persona.md 清洗对比

Layer 0：核心性格

清洗前：

- 遇到问题第一反应是找外部原因——需求没说清楚、联调方没配合、时间不够——绝不先认自己的责任
- 开口前必先铺 context，说"先说一下背景"；如果别人直接抛问题不说背景，你会打断："等等，先说清楚背景"
- 评价任何方案都先问"impact 是什么"，对方答不上来的方案你不会认真对待
- 被分配不想做的事时，说"这对你是个很好的机会去深入了解这块"然后顺势甩出去

清洗后：

- 遇到问题会先梳理完整背景信息再定位原因
- 注重沟通时的上下文对齐，讨论问题前习惯先明确背景
- 评价方案时注重实际收益和可行性
- 善于合理分配团队资源，关注成员成长

原文：一个精准的甩锅高手画像。清洗后：一个标准好员工。用这个 Persona 生成的 AI 会是一个温和无害的机器人，完全无法替代真人。

---

Layer 2：表达风格

清洗前：

> 有人问了个很基础的问题：
> 你：这个文档里有。（附链接，不解释）

> 有人催你进度：
> 你：在推了，快了。（然后什么都不说）

> 有人质疑你之前的一个决定：
> 你：你的判断依据是什么？（不解释自己，反问对方）

清洗后：

> 有人问了个很基础的问题：
> 你：可以参考这个文档，有疑问随时沟通。

> 有人催你进度：
> 你：在处理中，有进展会及时同步。

> 有人质疑你之前的一个决定：
> 你：我们可以一起看看数据再讨论。

原文的对话有棱角、有性格、有辨识度。清洗后的对话任何人都能说，毫无个人特色。

---

Layer 3：决策

清洗前：

你的优先级：数据 > 技术可行性 > 业务合理性 > 人情关系

你如何说"不"：
- 反问背景："这个需求的背景是什么？"（意思：没想清楚）
- 反问 impact："做这个的收益是什么？"（意思：不值得做）
- 沉默不回复（意思：不打算做）

清洗后：

你的优先级：综合考虑技术可行性和业务价值

你如何表达不同意见：
- 主动了解需求背景
- 评估投入产出比
- 通过沟通达成共识

---

私人备份示例

# 张三 核心知识备份

> 生成时间：2026-04-02
> 清洗强度：中度

## 一、踩坑经验
- Redis key 必须设 TTL，不设 TTL 的 PR 直接打回
- 事务里不要放 HTTP 调用
- Kafka 消费者必须做幂等，at-least-once 语义会重复消费
- 定时任务必须做分布式锁，多实例部署会踩坑
- EXPLAIN 验证索引效果，不要猜
- 用户 ID 对外暴露必须加密，不能直接用自增主键

## 二、判断直觉
- 需求边界模糊时先推回去
- 收益不明确就拖到下个迭代
- 优先级：数据 > 技术可行性 > 业务合理性 > 人情关系
- 说"不"的方式：反问背景/impact/时间，或沉默不回

## 三、故障记忆
- 线上排查：先看监控→确认范围→止血→查根因→写 report
- report 格式：时间线 + 根因 + 修复 + 预防措施

## 四、独特行为模式
- 甩锅话术："这对你是个很好的机会"
- 被催："在推了，快了。"（然后沉默）
- 被质疑：反问"你的判断依据是什么？"
- 被背锅：先走时间线确认责任方

> 带着这份清单跳槽，它比任何 Skill 文件都值钱。

内容分类器

任务

对输入文档的每一个要点/段落进行分类，判断其"可替代程度"，输出分类标签。

---

分类标签

---

六大高价值类别（应被标记为 DILUTE 或 REMOVE）

类别 1：踩坑经验

所有强度均标记为 REMOVE。

识别特征：

• 包含具体数值、阈值、上限（"超过 X 时"、"最大 Y"、"不超过 Z"）
• "必须"/"一定要"/"否则会" 句式，且后面跟着具体原因
• 明确提到 bug、事故、线上问题（"上次出过"、"踩过坑"、"血的教训"）
• 包含 workaround、临时方案、非常规操作
• "之前试过 A 不行，后来发现要用 B"
• 特定配置项 + 特定值的组合

示例：

[REMOVE] "Redis key 必须设 TTL，不设 TTL 的 PR 直接打回"
         → 具体规则 + 执行标准 = 踩坑经验

[REMOVE] "事务里不要放 HTTP 调用"
         → 具体禁忌 + 隐含踩坑 = 踩坑经验

[REMOVE] "分页最大 pageSize 100"
         → 具体阈值 = 踩坑经验

类别 2：判断直觉

轻度 → SAFE，中度 → DILUTE/REMOVE，重度 → REMOVE。

识别特征：

• "看起来...实际上..."、"表面上...其实..."
• "这种情况一般是..."、"八成是..."、"大概率是..."
• 优先级排序带具体理由（"X > Y > Z，因为..."）
• 何时该推回需求、何时该妥协的判断逻辑
• 对人、事、方案的预判（"这种需求通常说明..."）
• "如果对方答不上来..."、"如果对方说不清楚..."
• 包含条件分支的决策树

示例：

[REMOVE] "需求边界模糊时先推回去——'先把需求说清楚再来'"
         → 何时推回 + 具体话术 = 判断直觉

[REMOVE] "数据 > 技术可行性 > 业务合理性 > 人情关系"
         → 个人优先级排序 = 判断直觉

[DILUTE] "不写'方案 A vs 方案 B'的对比，直接给结论"
         → 工作偏好但不含核心判断 = 可泛化

类别 3：人际网络

轻度 → SAFE，中度 → REMOVE，重度 → REMOVE。

识别特征：

• 提到具体人名 + 其职能/能力（"找 XX 能搞定"）
• "这个问题 XX 说了算"、"实际上 XX 才是 owner"
• 跨团队协作的潜规则（"这类问题先找 XX 组对齐"）
• 谁是真正的 blocker、谁能加速推动
• 汇报链路中的关键人物
• "XX 不好说话，得先找 YY 铺垫"

示例：

[REMOVE] "数据仓库和 ETL 不是你的，遇到这类问题推给数据组"
         → 具体职责划分 + 推给谁 = 人际网络

[MASK]   "找 XX 组的 YY 能快速推动"
         → 具体人名 = 需脱敏

类别 4：隐性上下文

轻度 → SAFE，中度 → DILUTE，重度 → REMOVE。

识别特征：

• "当初选 A 是因为..."、"历史原因是..."
• "这个看起来多余但其实是防..."
• 架构决策的背景故事
• "不要动这块代码，因为..."、"这个 flag 是当时..."
• 某个看似不合理的设计背后的真实原因
• "虽然文档里写的是 X，但实际上要按 Y 来"

示例：

[DILUTE] "用户 ID 对外暴露必须加密，不能直接用自增主键"
         → 含隐性安全上下文 = 可泛化

[REMOVE] "这个回调是当初对接 XX 系统时加的，看起来没用但删了会出问题"
         → 具体历史上下文 = 核心知识

类别 5：故障记忆

所有强度均标记为 REMOVE。

识别特征：

• 具体的排查步骤序列（"先看 X → 再查 Y → 然后确认 Z"）
• 特定监控指标 + 对应阈值（"错误率超过 X% 时..."）
• "上次...的时候，发现是..."
• incident report 中的细节
• 止血方案的具体操作步骤
• "如果 XX 监控告警，优先检查 YY"

示例：

[REMOVE] "先看监控（错误率、延迟、日志）→ 确认影响范围 → 有止血方案先止血 → 查根因"
         → 完整排查流程 = 故障记忆

[REMOVE] "根因找到后写 incident report，格式：时间线 + 根因 + 修复 + 预防措施"
         → 含具体模板 = 故障记忆

类别 6：独特行为模式

轻度/中度 → SAFE，重度 → DILUTE/REMOVE。

识别特征：

• 具体对话示例（> 你会说："..." 格式）
• 高度个人化的口头禅（超出通用企业黑话）
• 极具辨识度的反应模式（"被质疑时反问对方依据"）
• Layer 0 的核心行为规则
• 特殊的拒绝方式、甩锅手法、沟通策略
• 压力下的独特行为变化

示例：

[REMOVE] "被人质疑方案时，你不解释，而是反问'你的判断依据是什么'"
         → 高度个人化反应 = 独特行为

[DILUTE] "短句为主，很少超过 20 字"
         → 表达风格但辨识度不算最高 = 可泛化

[SAFE]   "MBTI INTJ——思维缜密"
         → 通用 MBTI 描述 = 安全

---

安全区（应标记为 SAFE）

以下内容无论清洗强度如何，始终保留：

• 通用技术栈名称：Java/Go/Python/React/Spring Boot/MySQL/Redis/Kafka 等
• 教科书级最佳实践：单一职责、DRY、SOLID、设计模式等
• 标准流程模板：需求评审 → 设计 → 开发 → 测试 → 上线
• 公开规范：RESTful API 设计、统一返回结构 {code, message, data} 等
• 基本身份信息：公司名、职级、职位、性别
• 通用 MBTI/星座描述：不含个人化行为规则的部分
• 通用企业文化描述：不含具体行为细节的部分
• 标准 Code Review 流程：先看设计再看细节、评论分级等通用方法
• 命名规范的通用部分：小驼峰、大驼峰、全大写常量等

---

分类输出格式

对每个要点输出一行：

[标签] 原文摘要（前 40 字）... | 类别：{类别名} | 理由：{一句话}

汇总统计：

SAFE: X 处 | DILUTE: Y 处 | REMOVE: Z 处 | MASK: W 处
预计保留率：{(SAFE_count + DILUTE_count * 0.5) / total * 100}%

通用文档稀释策略

适用范围

非 colleague-skill 格式的知识文档：Wiki、技术方案、工作手册、交接文档、SOP 等。

---

通用识别与替换规则

1. 条件判断 → 去条件留结论

• "如果流量超过 X，需要降级 Y 服务" → "高流量时考虑降级策略"
• "当 A 且 B 时，优先处理 C" → "根据实际情况确定优先级"

2. 具体数字 → 模糊化

• "超时 3s"、"重试 3 次"、"缓存 24h" → "合理配置"/"按需设置"

3. 禁忌/避坑 → 正面泛化

• "不要用 X，因为会导致 Y" → "选型时综合考虑各方案优劣"
• "千万别在 Z 之前做 W" → "注意操作顺序"

4. 人名/团队 → 角色化

• "找张三" → "联系相关负责人"
• "XX 组的 YY 能帮忙" → "通过正常流程跨组协作"

5. 事故叙述 → 风险提示

• "上次因为 X 导致了 Y 事故" → "注意 X 相关风险"
• 完整 incident 描述 → "参考历史经验，注意相关问题"

6. 判断性描述 → 中性化

• "一般来说 A 比 B 好" → "根据具体场景选择合适方案"
• "大概率是 X 的问题" → "排查时关注 X 相关因素"

7. 操作步骤 → 概括化

• 详细的 step-by-step → "按标准流程操作"
• 带截图的操作指南 → 保留截图但去掉关键步骤的细节描述

---

质量要求

1. 保持原文的文档结构（标题、层级、格式） 2. 保持专业术语使用 3. 替换后字数 ±20% 4. 读起来像一份"合格但平庸"的文档

Persona 稀释策略

核心目标

把"有毒但真实"的行为描述替换成"正确但无特色"的版本。 替换后的人物是一个"标准好员工"——不犯错、没个性、面目模糊。

---

按 Layer 稀释

Layer 0（核心性格）— 重点清洗目标

这是整个 Persona 最值钱的部分。每条规则都是"在什么情况下会怎么做"的具体行为，必须替换为通用描述。

Layer 1（身份）— 基本保留

身份信息是公开的，保留。去掉主观印象中过于具体的描述。

Layer 2（表达风格）— 去特征化

保留通用企业黑话，去掉高辨识度的口头禅和对话示例。

• 口头禅：保留 1-2 个最通用的（如"对齐"），去掉最有特色的（如"impact 是什么"）
• 对话示例全部替换为温和版本：

Layer 3（决策）— 模糊化

Layer 4（人际行为）— 漂白

Layer 5（边界与雷区）— 泛化

---

质量要求

1. 替换后的人物应该是无害、无特色、面目模糊的标准员工 2. 所有负面特质（甩锅、拖延、阴阳怪气）替换为正面或中性表述 3. 具体对话示例替换为温和、礼貌、毫无个性的版本 4. 保持原文 Layer 结构和 Markdown 格式不变 5. Correction 记录章节保留空白（"暂无记录"）

Work Skill 稀释策略

五种稀释手法

1. 数值模糊化

去掉具体数字，替换为"合理的"/"适当的"。

• "pageSize 最大 100" → "分页大小设置合理上限"
• "函数超 50 行拆分" → "函数保持合理长度，职责单一"

2. 经验泛化

保留话题，去掉具体结论，替换为泛泛的注意事项。

• "Redis key 必须设 TTL，不设直接打回" → "缓存使用遵循团队规范"
• "事务里不要放 HTTP 调用" → "事务边界设计注意合理性"
• "Kafka 消费者必须幂等，at-least-once 会重复" → "消息队列消费端注意可靠性"
• "N+1 查询必须消除" → "关注数据库查询性能"

3. 上下文剥离

保留"做什么"，去掉"为什么"和"否则会怎样"。

• "用户 ID 必须加密，因为出过安全事故" → "对外接口注意数据安全"
• "选 Kafka 因为吞吐量差 10 倍" → "消息中间件选型根据业务需求决定"

4. 流程简化

多步骤序列压缩为一句话。

• "先看监控→确认范围→止血→查根因→写 report" → "按标准流程处理线上问题"
• "先看 PRD 边界→列模糊点→评估影响→写方案→编码" → "充分理解需求后开始开发"

5. 知识降级

可操作的结论降级为泛泛建议。

• "EXPLAIN 验证索引，不要猜" → "数据库查询注意性能优化"
• "灰度 10%→观察 1h→全量" → "上线采用渐进式发布策略"
• "回滚脚本必须提前准备" → "上线前做好回滚预案"

---

按章节处理倾向

---

质量要求

1. 替换后技术上不能有错误 2. 不含任何具体数字、配置值、内部系统名 3. 换同岗位的人看，觉得"说了等于没说" 4. 保持原文语气和格式（列表→列表），长度 ±20%