技能目录

从一手素材里提炼

给 coding agent 的执行参考。每节结构：为什么 → 做法 → 判据 → 边界。跳过为什么直接抄做法，下一轮会在合并阶段丢信息。

主要素材是会话记录（用户输入密度最高但占极小比例）、PR 评审意见、事故复盘、工单、被回滚的补丁、git commit 消息。项目里已写好的复盘文档是二手结论——它会丢掉否决背后的理由。

0. 目录

并行精读：统一格式的三元组
从否决里挖分歧点
反复计数与优先级信号
症状描述 vs 优先级信号
回滚记录：最高价值的一手材料
拒绝自造术语
合并阶段的三种丢信息方式
反例速查表

1. 并行精读：统一格式的三元组

为什么：几份导出加起来可能十几万行，逐字读不现实，逐条摘要会丢判定。派多个读取代理各精读一部分是唯一可行解，但格式不统一会在合并阶段丢信息——每篇代理各发明一套字段，合并时你无法判断两行说的是不是同一件事。

做法：

先自己通读一份最短的素材，定死输出格式，再派其余代理。先定格式后并行，不是并行后统一。

输出格式固定为三元组，每条一行：

原话（逐字，不改写）| 抽象原则（一句话，不含项目名词）| 判据（可断言或可人工过一遍）

每个代理额外交一份计数表：它读到的每类问题的独立事件次数。
「原话」必须是逐字引用。改写过的原话不算原话——否决的力度全在措辞里（「不是 X 的问题」和「还是不太对」是完全不同的证据强度）。

判据：

抽查任意一条，能在原始素材里 grep 到那句原话。
任意两条三元组，抽象原则一栏的抽象层次看起来一致（都是不带项目名词的）。
计数表的分母写清楚（读了多少行、多少条用户输入）。

边界：代理报「没有更多了」不等于真的没有。合并后做一次全局计数复核——同一件事在不同导出里可能被两个代理各记一次。

2. 从否决里挖分歧点

为什么：做了什么只说明这条路走通了，信息密度低。用户推翻过什么、为什么推翻，暴露的是「默认看起来合理、实际是决策」的分歧点。新人 agent 最容易重犯的恰好是分歧点那一侧。

做法：对素材里每条「改了 / 退了 / 不要这样 / 我说了要 X / 还是不对」问三个问题：

这次改判动了哪一层？（机制层 / 取值层 / 表述层 / 范围层）
为什么前一次判断错了？错在「信息不足」还是「默认选择有问题」？
同一件事被改判过几次？

层数是这条手法的产出物。两次改判都只动了取值层，说明真正的问题从来不在机制层——这条结论比任何单条原则都值钱。

亲历：某项目里一个输入的默认值被两次改判，两次都没重写机制层，只改了取值函数和三个常数。抽象后的通则是「默认值与阈值是设计问题，不是实现问题」——这条通则的成立依据就是层数，不是那三个常数。

判据：

每条升为通则的条目，都能指认到一次具体否决。
每条条目都标了它动的是哪一层。
出现两次以上改判的，在正文里显式写出「第 N 次改判」。

边界：用户推翻的具体方案不保留，只保留它暴露的分歧点。方案是单例，分歧点可能通用。

3. 反复计数与优先级信号

为什么：同一件事被反馈第 N 次，说明前几轮修在了错误的层次。这不是症状描述。

做法：对每类问题数独立事件的次数。同一个根因在同一天被报两次算一次；跨轮、跨人、跨天的才算独立。

阈值：

计数	处理
1	标「单例，降权」，保留不删，写清本项目里它为什么成立
2	疑似模式，继续找第二个来源；找不到就仍然降权
≥3	立规，可以进正文

判据：正文里每条以「X 次反馈 / X 轮迭代」出现的条目，计数都能追溯到计数表；计数为 1 的条目在正文里带「单例」标注。

边界：计数低但后果极重的条目可以破例进正文——判断「反复」时同时看频次和单次代价。

4. 症状描述 vs 优先级信号

同一条反馈有两种读法，处理方式完全不同。

读法	特征	该做什么
症状描述	「这里很黑」「文案太啰嗦」「不太对」	先把它变成一个可测量的量，不改
优先级信号	同一句在第 4 轮又出现	停手，去查前几轮修在了哪一层
否决	「不是 X 的问题」「别这样」	挖分歧点，不挖症状

判据：每条反馈都被显式归类到这三行之一；被归为「症状描述」的条目，在动手改之前先有一个可测量的量。

**边界：早期项目没有统计分布可参考。反馈的频次不等于重要性，一次强信号抵十次弱信号。

5. 回滚记录：最高价值的一手材料

为什么：git 历史里被 revert 的补丁精确指出了「某条路走不通」，而且它是双向的——成功提交告诉你什么有效，回滚告诉你什么无效，后者几乎从不出现在任何复盘文档里。

做法：

git log --grep="Revert" 加扫 diff 里的 revert 标记。
每个回滚抽一条：回滚原因是什么？写进复盘文档的理由和 commit message 一致吗？
不一致的（commit 说「性能」，复盘说「方向错」）——不一致本身就是高价值发现。

判据：素材清单里能列出被回滚的补丁数；每条回滚都在通则里有对应（要么支撑一条原则，要么说明它是个孤例）。

边界：回滚理由经常写得比真实原因笼统（写「试了下不行」）。这类只能当弱信号，需要与别处材料互证。

6. 拒绝自造术语

为什么：你为一次现象起的新名字（叫它「甲类缺陷」或自造一个英文复合词）会让读者以为它是一个公认概念，然后按公认概念的强度去使用它。这是把自建框架伪装成共识。

做法：

优先用领域内已存在的词。
必须造词时，在术语表里定义一次，并标注为自建框架。
通则正文里不出现只在本次提炼中存在的名词。

判据：术语表里每一项都能回答「这个词在本次项目之前就存在吗」。答不出且未标注「自建」的，是违规。

7. 合并阶段的三种丢信息方式

多代理并行特有的失真，都是无声的：

措辞降级：代理把逐字原话概括成了自己的话，证据强度被抹平（「不是 X 的问题」变成「希望不是 X」）。
重复计数：两篇代理记了同一件事，计数虚高，直接影响第 3 节的阈值判定。
静默丢弃：格式不匹配的行在合并脚本里被跳过，没有任何告警。

做法：合并后做一次抽样回查（随机抽 10 条逐字回原素材）；计数表手工加总一遍；合并脚本对跳过的行计数并打印。

判据：合并后的条目总数 = 各代理条目总数 − 重复项，且跳过数为 0；抽样回查中逐字不匹配数为 0。

8. 反例速查表

反例	为什么错	正确做法
只读项目里的复盘文档	二手结论丢掉了否决背后的理由	回到会话记录 / PR / 回滚记录读一手
派 5 个代理并行后再定格式	格式已经不一致，合并必丢信息	先自己定死格式再派
代理返回「原文大意」	改写过的原话不算原话	要求逐字引用，可 grep
把计数为 1 的条目直接删掉	孤例常常是最反直觉的那条	标「单例，降权」保留
对同一根因同一天的两条反馈各计一次	频次虚高	同根因同日算一次
为一次现象起一个新领域词	自造术语伪装成共识	用已有词，或术语表标注「自建框架」
合并时静默跳过格式不匹配的行	丢信息且无告警	跳过计数必须打印
采信 commit message 里写的回滚理由	它比真实原因笼统	与复盘文档互证，不一致处是高价值发现