im-not-ai 韩语 AI 味分类候补池解析：taxonomy-candidates.md 的候补登记、实证门槛与升级机制-育师

【免费下载链接】im-not-ai

AI가 쓴 한글을 사람 글처럼 윤문하는 Claude 스킬 — Korean AI-text humanizer: detects and rewrites translationese, mechanical parallelism, and 71 other AI tells

项目地址：https://gitcode.com/gh_mirrors/im/im-not-ai

点击查看免费下载

本指南以 taxonomy-candidates.md 为主体，讲解 im-not-ai 项目中korean-ai-tell-taxonomist维护的"AI 味"模式候补池：候补如何登记、为什么必须用 2 件以上实证才能升级、pending/hold/promoted/rejected四状态如何流转，以及候补最终如何进入分类体系本阵（SSOT）并驱动下游诊断与快速规则。读完你将理解该仓库"从实盘发现新模式 → 候补积累 → 验证升级 → 生成规则文件"的完整闭环，并能自行阅读和评估候补表中的每一项。

一、文件定位：为什么候补池必须是一份"可追踪"的文件

taxonomy-candidates.md是korean-ai-tell-taxonomist这一维护型 Agent 的待办清单与升级输入。它既不是分类体系本身，也不是运行时规则，而是介于"实盘观察到的疑似新模式"与"正式纳入分类体系"之间的缓冲区。

这份文件之所以存在，源于一次真实的工程教训。候补池最初放在_workspace/taxonomy_changelog.md，但_workspace/目录是.gitignore目标——该文件虽然自称"本阵变更的单一追踪源头"，却从未被提交，于是每一轮记录只留在执行过任务的那台机器上。追踪文件必须随仓库版本化，因此候补池被迁移到现在的 taxonomy-candidates.md。

文档还澄清了一段历史：v1.3 版本记录中提到的references/pattern-candidates.md、promotion-checklist.md、sample-collection.md三个文件实际并不存在（仅存于分类体系变更历史中），本文件就是它们的替代者。在 korean-ai-tell-taxonomist 的 Agent 定义中同样明确规定：候补池与升级历史以references/taxonomy-candidates.md为正本（追踪文件），_workspace/taxonomy_changelog.md若存在仅供参考，新的升级与驳回一律写入本文件的历史小节。

与分类体系本阵的关系

本文件是"输入"，真正的"输出"是 ai-tell-taxonomy.md——10 大分类 × 85 个 AI 味模式（活跃 84 + A-17 hold）的单一事实源（SSOT）。二者的关系可以用一条流水线概括：

实盘输入 → 观察疑似新模式 → taxonomy-candidates.md（候补池） → 实证满足升级门槛 → ai-tell-taxonomy.md（本阵 SSOT） → build_quick_rules.py / build_diagnosis_rules.py 生成下游规则

二、升级规则：候补进入本阵的四道门槛

文档在"승격 규칙"（升级规则）一节给出了候补晋升本阵的完整约束，这些规则是理解整个候补池状态的前提：

1. 实证数量门槛：2 件以上不同输入

候补必须有至少 2 件来自不同输入的实证才能升级。
同一模型、同一作者连续产出的结果只算 1 件——这是 v1.3.1 Gate 1.3 的分布保护机制，防止单一来源的噪声污染本阵。README 的 v1.3 记录印证了这一机制：회차 2（外部媒体真数据）中，"결국 文头断言 9 次""X은 A가 아니라 B 否定-肯定对偶 7 次"等 3 个强候选正是因为"同一模型 + 同一记者系列"而被 hold，等待其他模型、其他作者的数据中复现后才可升级。

2. ID 分配：append-only，禁止新增大分类

候补的临时 ID（如K-1、C-8-X）在升级时改为现有大分类（A~J）下的子编号，采取 append-only 方式追加，严禁新建大分类。
文档特别说明：表中所有K-*都是临时 ID，升级时须领取现有大分类的子编号。
之所以禁止插入、只允许追加，是为了保护模式 ID 的引用稳定性——ID 是诊断（diagnostician）与润色（monolith）调用之间传递的契约，任意插入会造成 ID 漂移。这一点在 korean-ai-tell-taxonomist 定义中写得更明确："保持既有 SSOT 的条目 ID（A-1、A-2…），新条目以最低位编号 append（禁止插入——保护诊断、润色调用的 ID 交接契约稳定性）"。

3. 严重度调整：需要 3 件以上反证

一旦某个模式的严重度（S1 决定性 / S2 强 / S3 弱）被设定，调整它是非常保守的——需要3 件以上反证。学术锚点（academic anchor）的判定依据见 scholarship.md。

4. quick 编排是独立标准：升级 ≠ quick: true

这是最容易误解的一条规则。候补即使升级进入本阵，也不自动获得quick: true——新条目的默认值是false。能否进入 fast（light）路径的快速规则册，取决于 ai-tell-taxonomy.md 前言中定义的两条独立标准：

任务匹配校准中 AI 密度 > 人类密度（依据tests/baselines/2026-08-29-task-matched-calibration.json，优于 24 对的2026-08-23校准）；
触发可能性——超过文档阈值的文档真实存在；无法触发的规则每次调用都只会徒增成本。

正因为quick判定独立于升级，taxonomy-candidates.md中hold状态的C-8-META等条目即使未来升级，仍需单独评估 quick 编排资格。

状态机：四态流转

状态	含义
`pending`	已有 1 件实证，等待第 2 件及以上实证
`hold`	实证不足或判定保留（分布未达标、反证存在、待重评条件触发）
`promoted`	已反映进 taxonomy 本阵，并记录版本
`rejected`	被驳回（并入现有模式、实证反证等）

三、候补清单逐项解读：13 个在册候补

截至文件最新记录，候补池共 13 项（promoted 0 项）。以下保留原表核心信息并逐项展开说明其技术内涵：

临时 ID	模式	实证来源	状态	下一步
K-1	列举分隔符过度替换——把多语节短语列举整体替换为间隔号（·），导致条目边界崩塌（"지역 안과 내원·정밀검사 결과·재검·추적"）	afternoon-platform`2026-09-22-001/02_detection.json`、`04_fidelity_audit.json`· Claude strict	pending	升级时领取 C 或 J 的子编号。处方候选：间隔号仅用于单词·短名词列举，2 语节以上短语保持逗号
C-11-X	C-11（连接语尾后逗号）的例外条件——主语切换的从句边界、朗读无停顿 60 字+ 时保留逗号或句号切分	上述 run（公开发言、朗读区）	pending	探讨在 playbook 的 C-11 配方中补充例外条件
C-11-RL	C-11 run-length 回归——删除逗号导致无停顿区间 41→56 字（未达 60 字阈值而未被检测到），增幅本身即信号	z-beyond 冷读 2026-09-22`naturalness-reviewer`	pending	metric 候选`run_delta`（润色前后最长无停顿区间增长率）+30% WARN
C-8-X	"A가 아니라 B" 否定-肯定对偶重复（14 次）——C-8 变种	afternoon 2026-09-22-001（GPT-优势签名）	hold	与 v1.3.1 轮 2 hold 3 件同族。C-8 已吸收 2 次+ 阈值与 C-14，需 gap 分析后判定是否重复
J-3/C-6-X	"加粗标签— 说明" 破折号定义公式（6 次）	afternoon 2026-09-22-001	pending	位于 J-3（破折号）与 C-6 之间——gap 分析后领取子编号
C-1-R	列举凝聚崩塌（反效果）——移除 C-1 后，若在预告句中新增修辞性数词（"세 가지"），数字承诺保留但履行标识消失	z-beyond 冷读 2026-09-22（fast → fidelity 移交 → naturalness S2）	pending	处方候选：修辞数词放入预告句时，至少保留 1 个条目标识（`도`·`역시`）
D-X-meta	元话语开头·结算（"이 글에서는 …알아보겠습니다"）——普适性未判定	z-beyond PRODUCTION_SPEC_v2 §2 T10（10 篇+ 实测）	pending	还需其他项目的 1 件实证（当前只是本项目规则）
E-2-X	言说动词终结偏重（"봅니다/살핍니다/설명합니다" 100% 终结）——E-2 变种	z-beyond YTR-0037/38 2026-08-25	pending	与 E-2 是否合并的 gap 分析
H-X-head	移除 T10 后文头关键词偏重——元话语开头移除后，主题词开头句比例 36→50%	z-beyond 冷读 2026-09-22	hold	metric 候选`head_repeat_ratio`——仅 WARN、禁止自动修改（动摇文头会引回 H-1/A-16）
C-8-META	C-8 共现例外——否定对偶若与 ①对立隐喻（点/线、工具/武器等把比喻词架在 A·B 轴上）或 ②汉字·英文并记同句重叠，则未达 2 次阈值也触发。处方分两阶段（先移除并记，再把比喻词替换为所指对象以解构隐喻轴）	#56（@eungwonkim）2026-07 精读模式实战遭遇，`점(點)/선(線)`实事故	pending	不触碰阈值（v2.6.1 n=532 附注：勿降至 1 次），只加条件性子句。还需 1 件实证
D-COLLOC	不存在的说法——搭配混杂造词（混搭不搭配的搭配创造的表达）	#60（@nhleeclaw）提交，`[S1 · estimated]`无实测	hold	与主 D-8（分裂句公式）编号冲突，需分配 D-15+。赋予严重度前必须做对照语料实测——S1 是"决定性信号"的主张
F-TAUTO	同义反复并列叙述（把相同含义并排两次）	#60（@nhleeclaw）提交，`[S2 · estimated]`无实测	hold	F-6 被 #141 预定为「实务未用汉字造词」→ 需分配 F-9+。需实测
A-17	'-들' 复数后缀过度（NMT 原文轮次）	v2.0 轮次（学术依据强，我方数据阳性 0）	hold	重评条件：在 NMT 原文轮次获得阳性。已登记本阵但处于 hold——在全 85 模式中位于活跃 84 之外

值得注意的细节

K-1 是"过度修复"的典型：间隔号（·）本适用于单词或短名词列举，把它套用到多语节短语会让条目边界模糊，这个候补反过来约束润色行为不要制造新的 AI 味。
C-11-RL 提出的是"增量即信号"思想：run_delta指标衡量润色前后最长无停顿区间的增长率——即使增幅未跨过 60 字阈值（未被检出），"越改越长"这个方向本身就是值得 WARN 的信号。
H-X-head 明确禁止自动修复：移除元话语开头后主题词开头句比例上升，但若去动摇文头，会把 H-1（文头连接词）和 A-16（代词）的问题引回来，因此该指标只用于告警。
C-8-META 的"阈值不可动"原则：v2.6.1 基于 n=532 的人语料实测发现 2 次+ 阈值是保护"确实有多用修辞的真人作者"的防线，因此候补只允许以条件性子句方式补充，不能为迁就新现象降低阈值。
D-COLLOC 与 F-TAUTO 的"estimated"警示：两者均无实测数据，严重度只是估算，文档明确要求"赋予严重度前必须做对照语料实测"，这正是"实证驱动"原则在候补管理中的体现。
A-17 是"本阵内 hold"的特殊案例：它已经登记在 ai-tell-taxonomy.md（学术锚点强、但外部轮次与 v1.6 输入均为 0 阳性），所以它"位于活跃 84 之外"。其验证用指标deul_overuse_rate（'-들' 滥用率）在 prepare_monolith_input.py 中作为 v2.0 计数型指标持续测量（_V2_COUNT_METRICS中标注A-17 hold），等待 NMT 原文轮次提供阳性证据后由 v2.1 起重新评估。

四、升级与驳回历史：追踪文件的诞生记

文档"승격·기각 이력"（升级·驳回历史）记录了文件的两次关键写入：

2026-09-24（首次）

文件作为追踪文件新设，首批登记 10 件候补（promoted 0）。这批候补由原提案 #149（@snubhretina）提出——该 PR 因面向已被废弃的.claude/skills/布局而无法合并，但其中的想法本身值得保留，于是迁入现行路径。

2026-09-24（第二次）

从已关闭的 PR 中抢救 3 个候选：C-8-META（#56）、D-COLLOC、F-TAUTO（#60）。三个 PR 都因面向废弃的.claude/skills/布局而无法合并，但想法本身有保留价值，于是转移至此。至此候补池累计 13 件（promoted 0）。

从下一轮起，taxonomist 将读取这份表格（而非_workspace/taxonomy_changelog.md）继续工作。

这段历史揭示了这个仓库的一个独特实践：即使 PR 因技术债（旧目录布局）无法合并，其中的模式发现也不会被丢弃，而是被降级保存为候补——这保证了从实盘观察中获得的知识不因工程重构而流失。

五、源码级佐证：候补如何驱动下游产物

候补升级进入本阵后，会产生一系列连锁反应，这些都可以在仓库源码中找到确凿证据：

1. taxonomist 的产出协议

korean-ai-tell-taxonomist.md 规定：taxonomy（SSOT）更新后，必须同时重新生成两个下游产物——python3 scripts/build_quick_rules.py与python3 scripts/build_diagnosis_rules.py。只跑一个会被 CI 的--check拦截（两者都是漂移检查对象）。这正是候补升级"写进本阵 ≠ 任务完成"的工程含义。

2. 规则文件是生成物，不是手写物

build_quick_rules.py：读取 ai-tell-taxonomy.md 中每个模式条目末尾的_quick: true · quick_pattern: … · quick_fix: …_元数据，只抽取quick: true（表层信号可检测的 S1/S2）模式，与固定的 header/footer 模板拼装成 quick-rules.md。文件头注释明确记载了动机：手写同步曾造成 3 处 ID 漂移（D-3·G-1/G-2·J-3 指向了错误的模式），而 ID 是诊断→润色调用间的契约，漂移即运行时 bug。此外它还内置fast 令牌预算守卫（目标 50 条 ±20%，上限 60），--check会阻止超限提交——这解释了为什么候补的新条目默认quick: false：快速规则册有硬性规模上限，新增必须靠"先降级旧条目"来腾出预算。
build_diagnosis_rules.py：同样从 SSOT 生成，但全模式收录（包括quick: false的文档级模式），产出诊断专用精简索引 diagnosis-rules.md，把诊断调用的输入从 74.8KB 的 taxonomy 全文压缩到约 13KB（约 83% 削减），并自校验"全 ID 收录、零空签名"。

3. 测试层的守护

tests/test_agent_inventory.py 会校验 SKILL.md 声明的 Agent 数量与agents/目录实物一致，并确认被点名的运行时 Agent（humanize-monolith、humanize-diagnostician、humanize-finalizer）与维护型 Agent（korean-ai-tell-taxonomist）确实存在——如果候补管理流程中有人改动了 Agent 清单而忘记同步文档，CI 会直接失败。

六、实操要点：如何阅读与维护这份文件

如果你要为仓库贡献新的模式候选，或想评估现有候选，遵循以下流程：

登记：新观察到的疑似模式以临时 ID（K-*或{大分类}-{序号}-X等）追加到 taxonomy-candidates.md 的候选表格，如实填写实证来源（run ID / 文件路径 / 模型），状态记为pending（1 件实证）。
补证：在同一模型同一作者的连续产出中复现只算 1 件——必须在不同输入中获得第 2 件实证，才能讨论升级。
gap 分析：与现有模式做差异分析（文档中反复出现"gap 分析后判断重复性/领取子编号"），若与既有模式同族则建议合并（如 C-8-X 与 C-8 的关系），而非新增条目。
升级：满足 2 件实证 → 领取现有大分类的 append-only 子编号 → 写入 ai-tell-taxonomy.md → 更新本文件历史小节（promoted + 版本记录）。
重新生成下游：运行python3 scripts/build_quick_rules.py与python3 scripts/build_diagnosis_rules.py（或依赖 CI--check提示），并确认quick: true条数仍在预算上限（60）内。
严重度慎动：已有严重度需要调整时，必须积累 3 件以上反证；estimated标记的候补（如 D-COLLOC、F-TAUTO）在实测对照语料之前不得正式定级。

结语：一份追踪文件背后的工程哲学

taxonomy-candidates.md表面上只是一张候选表和两行历史记录，但它承载着 im-not-ai 项目分类体系可持续运转的三条支柱：实证驱动（无实证不升级、estimated 须实测）、ID 稳定性（append-only、禁新大分类、下游规则自动生成防漂移）、防过度修复（新候选约束的不只是"去掉 AI 味"，还包括润色行为本身不得制造新的 AI 味，如 K-1 的间隔号滥用、C-11-RL 的无声停顿增长）。理解这份文件，也就理解了为什么这个仓库的 85 模式分类体系能在真实使用中不断自我演进而不失控。