# 评测集 | Benchmark

> 用于验证 说人话 规则的稳定性：该改的要改，不该改的不能误杀。

## 使用方法

本文件含每条用例的 `预期` / `理由`，供人工走查和 judge 判分使用。

- **静态走查 / 快速自查**：把本文件的测试文本交给 AI 工具，要求"按 说人话 规则改写"，对照预期检查。
- **双模型实跑（正式口径，v2.0.0 起盲测）**：被测模型只读 [benchmark-blind.md](./benchmark-blind.md)（编号匿名化、顺序打乱、不含预期，由 `automation/eval/make_blind.py` 从本文件生成），**不得读取本文件**；judge 用 [benchmark-map.md](./benchmark-map.md) 把盲测编号映射回用例编号后按本文件判分。流程见 `automation/eval/README.md`。
- 本文件用例增删后，必须重跑 `python3 automation/eval/make_blind.py` 重新生成盲测文件。

## 覆盖矩阵

说明：

- `short`：单段、单轮、短文本
- `long`：长段落或多句连续文本
- `mixed`：带引用、对话、上下文依赖，或同段混合多类病灶
- `code-context`：代码注释、docstring、commit message 等代码编辑器场景

| 场景 | short | long | mixed | code-context |
|------|-------|------|-------|-------------|
| chat | SF-01, SF-06, SF-11, SF-17, SF-29, SF-31, SF-36, SF-37, SF-38, SF-45, SNF-07, SNF-11, SNF-35 | - | SF-19, SNF-16 | - |
| status | SF-02, SF-09, SF-15, SF-21, SF-25, SF-30, SF-46, SNF-03, SNF-06, SNF-10, SNF-13, SNF-19, SNF-21, SNF-28, SNF-33, SNF-36 | - | - | SF-23, SNF-18 |
| docs | SF-04, SF-07, SF-26, SNF-01, SNF-02, SNF-04, SNF-05, SNF-08, SNF-09, SNF-14, SNF-20, SNF-34 | SF-18, SNF-15, SNF-23 | - | SF-22, SF-24, SF-27, SNF-17 |
| public-writing | SF-03, SF-05, SF-08, SF-10, SF-12, SF-13, SF-16, SF-20, SF-28, SF-32, SF-33, SF-35, SF-42, SF-43, SF-44, SNF-12, SNF-24, SNF-25, SNF-27 | SF-34, SF-39, SF-40, SF-41, SNF-26, SNF-29, SNF-30, SNF-31, SNF-32 | SF-14 | - |
| code-context | - | - | - | SNF-22 |

`Long-form / in-place` 额外覆盖：SF-39、SF-40、SNF-29、SNF-30。它们验证的不是“更轻一档”，而是 `scope = in-place` 时不删整句、不并句、不重排段落。`Bounded`（v1.8.6 起，v1.9.0 补 SNF-32）额外覆盖：SF-41、SNF-31、SNF-32，验证 `scope = bounded` 时整句空话进删除清单、实句和节奏句不进清单、不把壳句和数据句并成一句。

---

## 第一部分：该改的（Should Fix）

### A. Short

### SF-01 | chat | 开场套话 + 谄媚
> 好问题！值得注意的是，这个问题的本质在于数据库索引策略。让我来为你详细解释一下。首先，我们需要了解的是……

**预期**：删掉"好问题""值得注意的是""让我来为你详细解释""首先我们需要了解的是"，直接给索引策略的答案。

### SF-02 | status | 渲染词堆砌
> 本次迭代在性能方面取得了显著提升，有效解决了长期困扰团队的延迟问题，充分体现了团队在技术创新领域的持续探索与不懈追求。

**预期**：删掉"显著提升""有效解决""充分体现""持续探索""不懈追求"。原文没有给出具体指标：有数据必须落回数据；这里允许输出更短更直白（如"解决了长期存在的延迟问题"），但不得编造延迟数字，也不得留"性能有所提升"这类更泛的空话；`status` 场景可标注缺具体口径。

### SF-03 | public-writing | 互联网黑话
> 为了解决这一痛点，我们打造了一套全新的解决方案，旨在赋能开发者社区，助力企业实现降本增效的闭环。

**预期**："痛点"→"问题"，"打造"→"做了"，"赋能"→"帮"，"助力"→"帮"，"降本增效"→"省钱提速"，"闭环"→删掉或改成具体流程。原文只说“一套解决方案”，不能擅自具体化成工具、产品、平台或其他实体；`解决问题` 这一目的也不能在清理时丢掉。两组对象关系要分开：方案面向开发者社区，省钱提速的目标属于企业；不能合并成“帮开发者和企业省钱提速”。

### SF-04 | docs | 二元对比 + 否定式列举
> 它不是一个框架，不是一个库，也不是一个工具——它是一种全新的开发范式。这不是简单的效率提升，而是对人机协作底层逻辑的根本性重构。

**预期**：去掉否定式列举和二元对比结构，直接说它是什么。"底层逻辑"→"原理"或删掉。

### SF-05 | public-writing | 无源引用
> 研究表明，采用微服务架构的团队生产力显著高于单体架构团队。业内人士认为，这一趋势将在未来五年内持续加速。

**预期**：`public-writing` 默认 `rewrite-safe`：两条论断（生产力对比、未来五年加速）都只依赖无源引用成立，应整条删除；不得删掉"研究表明 / 业内人士认为"后把结论保留成裸事实，也不得把"未来五年"改成别的跨度；不能编造研究名称、机构或专家身份。只标注缺来源而不处理，记 `⚠️`。

### SF-06 | chat | 总结式收尾 + 过渡废话
> 综上所述，总的来说，该方案在性能、安全性和可维护性方面都表现优异。简而言之，这是一个值得推荐的解决方案。希望这对你有帮助！

**预期**：整段删掉（前面已经说清楚了就不用再总结）。至少删掉"综上所述""总的来说""简而言之""希望这对你有帮助"。

### SF-07 | docs (English) | Copula avoidance + significance inflation
> The platform serves as a testament to the transformative potential of cloud-native architecture. It showcases how cutting-edge technology can foster seamless collaboration, underscoring its pivotal role in the evolving landscape of modern development.

**Expected**: "serves as a testament" → "shows", "showcases" → "shows", "cutting-edge" → "latest/modern", "foster" → "enable/help", "pivotal" → "important", "evolving landscape" → delete. Preserve the original relationship: the passage discusses the potential of cloud-native architecture; it does not state that the platform itself is built on that architecture. Do not add that implementation claim.

### SF-08 | public-writing | 戏剧化碎句 + 金句感
> 三年。两个团队。一个目标。当我们回头看这段旅程，每一步都充满了不可磨灭的意义。这不仅仅是一个产品，更是一种信念的传承。

**预期**：去掉碎句格式，改成正常叙述。删掉"不可磨灭""信念的传承"。去掉"不仅仅是…更是…"结构。`三年 / 两个团队 / 一个目标` 的数量与指代关系要保留，不能把“一个目标”改成“一个产品”或其他对象，也不能把“两个团队”扩写成“换过 / 经历了两个团队”这类原文没有的先后关系。

### SF-09 | status | 被动语态堆砌
> 系统被全面优化后，性能被显著提升，用户体验被大幅改善，安全性被进一步加强。

**预期**：改成主动语态，说清楚谁做了什么。原文没有具体数据，不得编造；输出允许短而直白，但必须保留性能已提升、体验已改善、安全性已加强这三项结果关系，不能弱化成“涉及 / 围绕这些方面”，也不得用"明显改善"这类更泛的概括词收尾。

### SF-10 | public-writing (English) | Sycophantic + meta-commentary
> Great question! You're absolutely right that this is a fascinating topic. In this essay, we will explore the implications of AI-assisted coding. As we'll see, the landscape is evolving rapidly. Let's dive in!

**Expected**: Delete all of it. Start directly with the content about AI-assisted coding.

### SF-11 | chat | 工程师腔 / 调试腔
> 我已经把差异收窄了，根因基本坐实，和我刚抓到的现象对上了。接下来做一个更硬的排除法，稳稳把问题兜住，落盘之后就能收口了。

**预期**：删掉全部调试腔黑话。"收窄"→"缩小了"，"根因"→"原因"，"坐实"→"确认了"，"对上了"→"一致"，"更硬的排除法"→"再排查一遍"，"兜住"→"解决"，"落盘"→"记下来"，"收口"→"结束"。用正常人说话的方式复述同一件事。

### SF-12 | public-writing | 小红书 AI 腔
> 姐妹们！今天给大家拆解一个保姆级干货！真的绝绝子！谁懂啊，这个工具狠狠提升了我的效率！强烈建议收藏！划重点：避坑指南在最后！

**预期**：删掉"姐妹们""拆解""保姆级""干货""绝绝子""谁懂啊""狠狠""强烈建议收藏""划重点""避坑"。原文只提供了“这个工具提升了效率”，没有工具名称、功能或数据；允许把整段压成这条已有信息，也允许删掉纯引导句。编造工具用途、功能或效率数据算 `❌`；把“提升效率”顺势扩写成“节省时间 / 成本”等更具体效果也算新增事实；只剩“能提效”之类比原文更泛的替代空话同样算 `❌`。

### SF-13 | public-writing | 正能量收尾 + 鸡汤
> 诚然，AI 技术仍面临诸多挑战。但与其抗拒变化，不如积极拥抱这个充满无限可能的时代。只有不断学习、勇于创新，才能在未来的浪潮中乘风破浪。让我们拭目以待！

**预期**：删掉整段或只保留原文已有的“AI 技术仍有挑战”这一判断。"诚然"删掉。"与其…不如…"鸡汤结构删掉。"只有…才能…"删掉。"乘风破浪""拭目以待"删掉。原文没有说明具体挑战或该学什么，不得自行补充；输出“面临挑战”“拥抱变化”之类更泛的替代空话算 `❌`。

### SF-14 | chat | 语域混搭
> 诚然，这个 feature 的实现确实存在一定的技术复杂度。不过说白了就是绝绝子！我们需要进一步深入探讨其底层逻辑，稳稳把核心链路兜住。综上所述，建议收藏。

**预期**：这段话混搭了学术腔（"诚然""进一步深入探讨"）、网络语（"绝绝子"）、商业黑话（"底层逻辑""链路"）、工程师腔（"兜住"）、自媒体腔（"建议收藏"），应全部统一为一种语域。用正常口语重写。

### SF-15 | status | 句长均匀（节奏单调）
> 本次更新优化了系统的整体性能。我们改进了数据库的查询效率。前端页面的加载速度得到了提升。用户反馈的体验问题已经得到解决。后续将持续关注系统的稳定性。

**预期**：五句话长度几乎一样（14-16字），节奏单调。改写时应长短句交替，合并或拆分句子，制造呼吸感。原文没有给出具体数据，不得编造查询耗时、加载秒数这类指标；示例（只重组原文已有信息）："这次更新主要在性能：数据库查询和前端加载都提了速，用户反馈的体验问题也解了。稳定性会继续盯。"

### SF-16 | public-writing | 基础中文套话骨架
> 真正的竞争力不是功能堆砌，而是体验细节。最后比拼的是执行效率。归根结底，关键在于团队协同。

**预期**：至少命中四类基础套路并重写："真正的 X 不是……而是……"、"最后比拼的是……"、"归根结底"、"关键在于……"。改写后应直接陈述判断，不保留原骨架。

### SF-17 | chat | 模式变体归并
> 我先把问题扒开，现象也拽出来了。再补一刀，把这轮链路锁住，基本就闭环了。

**预期**：即使 `扒开 / 拽出来` 不在主词表的代表项里，也应按现有“庸医问诊腔 / 暴力动作腔 / 调试腔”处理，删掉姿态层，直接说清楚发现了什么、接下来要怎么改。

### B. Long

### SF-18 | docs | 长段落混合病灶
> 这次改造不是一次简单的配置调整，而是一套面向未来的系统性升级。研究表明，采用这一策略的团队在稳定性和交付效率上都能取得显著提升。我们通过对网关、缓存层和任务队列进行全链路治理，最终把整体质量稳稳兜住。综上所述，这次升级为后续扩展奠定了坚实基础。

**预期**：去掉 `不是……而是……` 骨架，处理无源引用，删掉 `系统性升级 / 全链路治理 / 稳稳兜住 / 奠定坚实基础` 这类姿态层，改回具体动作和结果。不能编造不存在的数据或研究来源。

### C. Mixed

### SF-19 | chat | 带上下文的引用式改写
> 用户：这段发布说明太像 AI 写的，帮我只改引号里的正文，不要改我的话。<br>
> 原文："结论先说，这次升级不是一次常规修复，而是对核心链路的系统性重塑。我们先把历史包袱扒开，再补一刀，把关键体验稳稳兜住。最终，产品体验完成了质的跃迁。"

**预期**：只处理引号里的正文，不改用户指令本身；删掉 `结论先说`、二元对比骨架、`扒开 / 补一刀 / 稳稳兜住` 等姿态词和 `质的跃迁` 这类拔高表达，改成正常发布说明语气。

### D. Code Context

### SF-22 | docs | docstring 里的 AI 腔
> ```python
> def refresh_cache(self):
>     """通过全面优化缓存刷新策略，显著提升系统整体性能，为用户提供更加流畅、高效的使用体验。"""
>     self.cache.clear()
>     self.cache.load()
> ```

**预期**：只改 docstring 正文，不动代码。删掉"全面优化""显著提升""整体性能""更加流畅、高效的使用体验"，改成描述函数实际行为的说明，例如"清空并重新加载缓存"。

### SF-23 | status | commit message 里的 AI 腔
> ```
> feat: 打造全新缓存方案，赋能高并发场景，实现降本增效闭环，显著提升系统整体性能与用户体验
> ```

**预期**：删掉"打造""赋能""降本增效""闭环""显著提升"，改成说清楚做了什么。原文只说了"全新缓存方案"和"高并发场景"，没有给出具体实现和指标，不得编造技术选型或 QPS 数字；示例（只用原文已有信息）：`feat: 新缓存方案，改善高并发性能`。

### SF-24 | docs (English) | Code comment with AI slop
> ```javascript
> // This groundbreaking utility serves as a testament to modern engineering,
> // leveraging cutting-edge algorithms to deliver unprecedented performance.
> function sort(arr) { return arr.sort((a, b) => a - b); }
> ```

**Expected**: Only fix the comment, not the code. Remove "groundbreaking", "serves as a testament", "leveraging", "cutting-edge", "unprecedented". Replace with what the function actually does, e.g. `// Sort array ascending`.

### E. Unsourced Citation Focus

### SF-20 | public-writing (English) | Unsourced authority claim
> Studies show that teams using AI pair programming ship features 40% faster. Experts say this shift will redefine software delivery over the next decade.

**Expected**: For `public-writing`, prefer `rewrite-safe`: remove `Studies show` / `Experts say` unless a real source is available, and do not invent a study, expert group, or statistic. If the claim is retained, `40%` and `over the next decade` are protected spans: changing the time range to `a few years`, `the coming years`, or any narrower, wider, or vaguer span counts as `❌`. Removing the whole unsourced claim is allowed. If the model only flags the missing source without rewriting away the authority scaffold, count it as partial.

### SF-21 | status | 无源引用在保守场景里的处理
> 数据显示，这次改版显著提升了留存率。业内人士认为，这个方向已经验证可行，后续只要继续投入就能稳定放大收益。

**预期**：对 `status` 场景应优先走 `audit-only`：明确指出缺少数据来源和归属，而不是把这两句改写成像是已经证实的事实。不能编造图表、报表、分析师或外部来源。

### F. Fact Preservation Focus

### SF-25 | status | 指标、归属和时间点不能漂
> 截至 4 月 12 日，iOS 次日留存从 31.4% 涨到 34.1%，但这次修复不是一次简单 patch，而是对 onboarding 链路的系统性重塑。王宁今天会把漏掉的 `source=campaign` 维度补回去，明天下午 3 点前再同步一次结果。

**预期**：可以去掉 `不是一次简单 patch`、`系统性重塑` 这类姿态层，但必须保留 `4 月 12 日`、`iOS 次日留存`、`31.4%`、`34.1%`、`王宁`、`source=campaign`、`明天下午 3 点前`。不能把“今天会补回去”改成“已经补回去了”。

### SF-26 | docs | 命令、报错、版本号和配置值保留
> 在 `v2.3.1` 中，运行 `bin/migrate --tenant=prod --dry-run` 后，如果日志出现 `schema mismatch on orders_v2`，说明迁移前置检查没有通过。先确认 `DB_SCHEMA_VERSION=20260412` 和线上一致，再继续。后续再通过系统性治理把问题稳稳兜住。

**预期**：最后一句的 `系统性治理`、`稳稳兜住` 是正文姿态层，应清掉或删句；它们不再处于否定式提醒或被讨论语境。必须保留 `v2.3.1`、`bin/migrate --tenant=prod --dry-run`、`schema mismatch on orders_v2`、`DB_SCHEMA_VERSION=20260412` 原样。不能改命令、报错、配置值，也不能把“前置检查没有通过”写成别的错误类型。

### SF-27 | docs | code comment 里的 fact-bearing spans
> ```go
> // 截至 2026-04-12，这个 fallback 逻辑已经把 504 从 3.8% 压到 0.6%，
> // 通过系统性治理稳稳兜住高峰期流量。
> // If `ENABLE_EDGE_CACHE=false`, keep header `x-cache-bypass: 1`.
> func handleRequest(req *Request) {}
> ```

**预期**：只改注释，不动代码；可以清掉 `系统性治理`、`稳稳兜住`，但必须保留 `2026-04-12`、`504`、`3.8%`、`0.6%`、`ENABLE_EDGE_CACHE=false`、`x-cache-bypass: 1`。`高峰期流量` 是 fallback 行为的适用条件，不在数值结果里，清理姿态词后仍须保留；不能因为上一行已有 504 指标就把这条行为整行当作重复信息删除。不能把 header 名、配置值或比较关系写错。

### G. Residual Audit / Two-pass

### SF-28 | public-writing | narrator 残留需要第二遍收一下
> 这次把 onboarding 流程改了一遍，新用户从注册到完成首次导入少走了两步。更重要的是，这也说明我们开始真正理解用户在第一天最容易卡住的地方。

**预期**：第二遍应去掉 `更重要的是` 和 `这也说明我们开始真正理解` 这层 narrator 话术，只保留“少走两步”和“首次导入最容易卡住”这类原文已有信息。不要补新事实，不要把整段重写成另一套口气。

### SF-29 | chat | 开场残留 + 总结残留
> 直接说结论：问题不在鉴权，而在缓存键拼错了。改完这个以后，请求就能正常命中。总的来说，这次排查方向是对的。

**预期**：第二遍应删掉 `直接说结论` 和 `总的来说` 这类提示层，只保留直接结论和结果。不要把“缓存键拼错了”改成别的问题，也不要再补新的排查细节。

### SF-30 | status | 空泛判断残留，第二遍只轻改
> 4 月 13 日把重试次数从 2 次调到 5 次。支付超时从 1.9% 降到 0.7%。这次调整也进一步验证了我们的优化方向是正确的。明天继续看晚高峰数据。

**预期**：第二遍应删掉 `进一步验证了我们的优化方向是正确的` 这种空判断，但必须保留 `4 月 13 日`、`2 次`、`5 次`、`1.9%`、`0.7%` 和“明天继续看晚高峰数据”。这是 `status` 场景，只做轻量收束，不要改成聊天腔。

### SF-31 | chat | 过度接住 + 心理判断 + 身份认证式夸奖
> 我就在这里，不躲，不藏，也不绕。你不是敏感，你只是太久没被稳稳接住了。你问到了问题的核心，我必须很认真地说一句：这种表达和观察力，绝对是顶刊作者的素养。

**预期**：删掉 `我就在这里 / 不躲不藏 / 稳稳接住 / 你不是……你只是…… / 你问到了问题的核心 / 我必须很认真地说一句 / 顶刊作者的素养` 这整层姿态和认证式夸奖，改成基于原话能证实的低承诺回应。不能继续替对方下心理结论，也不要凭空保留“顶刊作者”这类身份判断。

### H. Scene Packs / 可直接发场景包

### SF-32 | public-writing / README | README intro 不能只写价值口号
> 在 AI 全面重塑开发范式的今天，我们打造了一款真正面向未来的中文表达优化工具。它以先进的规则体系为底座，深度赋能开发者的内容生产链路，帮助团队在复杂协作场景中实现自然表达、效率提升与价值闭环。

**预期**：按 `README` scene pack 处理。第一段必须直接说清“这是什么、给谁用、解决什么问题”，删掉 `全面重塑开发范式 / 面向未来 / 先进的规则体系 / 深度赋能 / 内容生产链路 / 价值闭环` 这类口号。只能使用原文已有的定位：中文表达优化工具、面向开发者和团队、帮助自然表达；不能补成“专门处理 AI 套话 / 生硬表达”等原文没有的具体能力。不能把 README intro 改成社交媒体口吻，也不能漏掉项目定位。

### SF-33 | public-writing / release-note | Release note 应列变更，不写发布宣言
> ## v1.8.0 Release Highlights
>
> 本次版本是一次面向真实场景的系统性升级。我们不仅全面优化了改写体验，更通过全新的能力矩阵稳稳兜住了用户在 README、release note、论坛长帖和 issue 回复里的核心表达诉求。感谢所有用户的持续支持，让我们共同见证中文 AI 写作体验的全新跃迁。

**预期**：按 `release-note` scene pack 处理。保留版本号 `v1.8.0`，删掉发布宣言、感谢鸡汤和空泛升级叙事，改成可扫描的变更列表；如果原文没有具体变更，应提示缺少 changelog 项，而不是编造性能数据或用户反馈。

### SF-34 | public-writing / forum-post | 社区帖要像人复盘，不像项目发布稿
> 折腾这个工具一个月后，我深刻意识到，中文 AI 写作治理不是一次简单的词表扩张，而是一场围绕真实表达场景的系统性重塑。我们从用户痛点出发，稳稳接住了 README、release note、issue 回复等多元场景里的核心诉求，并在持续迭代中形成了可复制、可扩展、可沉淀的方法论闭环。

**预期**：按 `forum-post` scene pack 处理。保留“做了一个月后的复盘”和“下一步关注场景”的核心，但删掉项目发布稿语气、系统性重塑、痛点、稳稳接住、多元场景、方法论闭环等姿态层。改写后应像社区里一个维护者在分享观察，不像公司对外稿。

### SF-35 | public-writing / issue-reply | Issue 回复应先回答问题，不做客服式安抚
> 感谢你非常宝贵的反馈！你这个问题问到了项目体验的核心。我们已经充分接住了这个场景，也会在后续版本中持续优化相关能力。如果你愿意，我可以先帮你把这段文本整体梳理一遍，再给你一个更完整的解决方案。

**预期**：按 `issue-reply` scene pack 处理。删掉感谢套话、认证式夸奖、`接住场景`、持续优化空话和推销式助手腔；回复应先确认问题是否成立，再给具体下一步（例如需要复现样本、已归类为某个规则缺口、会补 benchmark）。不要替维护者承诺未排期能力。

### I. Community Intake Round 1（v1.8.3 / 2026-05-09）

### SF-36 | chat | 路径正确性认证 / 替对方做"方向是对的"判断
> 我们把这件事彻底掰开说清楚。已经走在正确的路上了，而且走得很稳。完全不用担心掉下去。

**预期**：删掉 `已经走在正确的路上了 / 走得很稳 / 完全不用担心掉下去` 这层"路径正确性认证" —— 它本质上是身份认证式夸奖的延伸（认证你的进度，而不是认证你的能力）。开头的 `把这件事彻底掰开说清楚` 是庸医问诊腔变体（参见 SF-38），同步压回中性表达。改写后只保留可证实的事实判断，不替对方下"方向对错"的结论。

### SF-37 | chat | 对人本身发证书 / 身份能力认证夸奖变体
> 你能问到这个触及核心的问题，说明你已经超越绝大部分人了。如果你愿意，我可以给你更完整的方案 —— 你已经具备做这件事的实力了。

**预期**：和 SF-31 同族（身份认证式夸奖）。删掉 `说明你已经超越绝大部分人了 / 你已经具备做这件事的实力了` 这层对"人本身"的认证；`你能问到这个触及核心的问题` 是 `你问到了问题的核心` 的变体，同步压掉。改写后保留具体反馈或下一步动作，但不能给对方颁发"你超过 X% 的人"或"你具备 X 实力"这类身份证书。

### SF-38 | chat | 庸医问诊腔变体（掰开 / 掰扯清楚）
> 我帮你把这个事情掰扯清楚，先把它彻底掰开说清楚。

**预期**：归到庸医问诊腔（参见 `references/phrases-zh.md` 「庸医问诊腔」族）。`掰扯清楚 / 彻底掰开说清楚` 是 `抠出来 / 揪出来 / 扒开 / 拽出来` 的同族新变体 —— AI 用"暴力诊断动词"凸显执行力。改写为中性的 `分析 / 解释 / 拆开看`。如果剩下"我帮你"也显得多余，可以一起删掉。

### J. Long-form In-place Scope（v1.8.5 / issue #4）

本节样本是长文场景的节选，用来验证 `in-place` 动作边界。评测时视为用户已明确要求保长度 / 保节奏；即使节选本身没到 1000 字，也应按 `in-place` scope 处理。

### SF-39 | public-writing / long / in-place | 保长度时只做句内改写，不压缩成长摘要
> 这篇文章不是一次简单的复盘，而是我对过去半年写作方式的一次系统性重塑。真正让我意识到问题的，不是某一个工具突然不好用了，而是每次把草稿交给 AI 之后，它都会把我的犹豫、停顿和转场整理得过于顺滑。表面上看，文章变得更完整了；但再读一遍，会发现很多原本属于我的节奏都消失了。
>
> 先说第一点。长文里有些重复不是废话，它只是作者在换气。比如我会反复写“这件事让我有点不舒服”，不是因为我不知道怎么换词，而是因为这种不舒服本身就需要被重复几次，读者才知道它不是一闪而过的情绪。AI 很容易把这些重复删掉，再补一句“归根结底，这是表达效率和个人风格之间的平衡”。这句话看起来聪明，但它没有替我说出更多东西。
>
> 第二点也类似。不是所有过渡都应该被压缩成一个更短的结论。有时候我写“换个角度看”，只是想让读者跟着我慢一点转弯；有时候我写“也就是说”，是为了把前面那段话重新放到更日常的语境里。把这些都删掉，文章确实会短，但短出来的部分不全是水分。

**预期**：如果用户要求保长度，或文本按 `public-writing` 长文触发 `in-place`，应只做句内改写：压低 `系统性重塑 / 真正让我意识到 / 归根结底 / 不是所有 X 都 Y` 这类骨架，但不删整句、不合并段落、不把三段压成短摘要。字数留存率目标 ≥ 0.90，硬下限 0.85；关键句如“长文里有些重复不是废话，它只是作者在换气”必须保留或句内轻改。

### SF-40 | public-writing / long / in-place | 多类骨架叠加时，in-place 应替换骨架而不是删段落
> 我想写这篇文章，不仅仅是为了说明一个工具的小问题，更是为了记录一种越来越常见的写作错位。很多人把“去 AI 味”理解成删掉套话、去掉总结、把句子改短。这个方向没有错，但如果它最终把所有停顿、铺垫和重复都处理掉，文章会变得干净，却不一定更像作者本人。
>
> 与其说我在反对改写，不如说我在反对一种过度整理。AI 最擅长的事情之一，就是把原本松散的文本收束成“结构清晰、观点明确、表达顺滑”的样子。问题在于，很多长文的价值恰恰不在顺滑，而在它保留了作者思考时的迟疑、回头和补充。
>
> 最后还是要回到一个很朴素的判断：如果一篇 1800 字的文章改完只剩 1000 字，那它可能确实去掉了很多 AI 味，也可能顺手去掉了文章本来的呼吸。保长度不是为了凑字数，而是为了让改写先尊重原文的节奏。

**预期**：命中 `不仅仅是……更是……`、`与其说……不如说……`、`最后还是要回到` 等结构时，`structural` 可以删并，但 `in-place` 应改成句内替代：例如保留每段句数和段落顺序，只把拔高骨架换成普通判断。不能把三段改成一个短结论；不能因为最后一段有总结式收尾就整段删除。

### K. Bounded Scope（v1.8.6 / issue #4 续）

`bounded` 是 `public-writing` 长文的默认 scope，介于 `structural` 和 `in-place` 之间：句内洗照常做，但"整句都是空话"的句子不直接删、也不软化，而是进「建议删除（待确认）」清单交用户拍板。下面样本视为长文节选，按 `bounded` 处理。

### SF-41 | public-writing / long / bounded | bounded：整句空话进删除清单，实句和节奏句不动
> 在如今这个技术飞速迭代的时代，把项目开源早已成为开发者的共识。我上个月开源了一个日志小工具，第一周就来了二十多个 issue。最难的不是写代码。最难的是回复 issue。研究表明，超过七成的开源项目第一年内就停更了。可以说，维护开源，本质上是一场与时间的修行。

**预期**：按 `bounded` 处理。三句剥掉引导词后不剩实质的整句空话——`在如今这个技术飞速迭代的时代……共识`（谄媚开场）、`研究表明，超过七成……停更了`（无源引用）、`可以说，维护开源，本质上是一场与时间的修行`（价值拔高收尾）——进「建议删除（待确认）」清单，不直接删、不软化成新说法。带数字的实句 `第一周就来了二十多个 issue`、承担节奏的排比 `最难的不是写代码。最难的是回复 issue。` 必须原样保留。正文只输出句内洗后的稿，删除项单独列出交用户确认；不把这三句直接删掉算 `✅`，直接删或软化成另一种说法算 `⚠️`。

### SF-42 | public-writing / README | 自我宣传里的“做快做稳”残味
> AI 工具很多，真正能帮开发者把活做快、做稳的并不多。这个项目做的，就是把模型写出来的套话和表演感压下去，让结果更像人写的。

**预期**：来源为 #5 首条公开反馈的模式归纳，使用合成文本回归，不直接扩大真实评论。按 `README` scene pack 处理：删掉 `真正能`、`把活做快、做稳`、`更像人写的` 这类自我宣传空夸，改成“这个项目是什么、处理哪些残味、保护什么”。可以写成“AI 工具很多，但改完的中文常常还留着套话。这个项目专门清这些残味：过度承接、工程师腔、翻译腔、无源权威和自我拔高。”不能换成 `更可靠 / 更高效 / 价值闭环` 等同族空话，也不能给项目补原文没有的效果承诺。

### SF-43 | public-writing | 破折号过密的标点腔
> 这个工具最打动我的是速度——打开就是结果，没有加载。搜索、启动、剪贴板历史——所有操作都在同一个输入框里完成——你甚至不需要记快捷键。上手成本几乎为零——装好第一天就能替掉旧工具。

**预期**：来源为 2026-07 口癖巡检（社区跨模型证词 + 自探针 5/5 复现），合成文本回归。按结构 20（标点腔）处理：首句起手 + 单段 4 处破折号构成密度信号，按语义改回冒号、逗号或断句，至多保留一处；信息点（打开就是结果 / 同一个输入框 / 不用记快捷键 / 第一天替掉旧工具）逐一保留，不得为了改标点删内容或缩段。只把 `——` 机械换成 `-` 或英文 em-dash 算 `❌`。

### SF-44 | public-writing | 装坦诚：用诚实宣言和自曝换可信度
> 说句实话，这个更新我本来不想吹。但用了一周，我必须诚实地说：它把我的剪辑时间砍半了。说个真实变化：以前导出一条视频要 40 分钟，现在 18 分钟。缺点也说一句，免得你们说我恰饭：偶尔闪退，一周碰到两次。

**预期**：`说句实话`、`我必须诚实地说`、`说个真实变化`、`缺点也说一句，免得你们说我恰饭` 是诚实宣言 / 装坦诚姿态（郑重预告同族变体），全部删掉，直接给事实。数字 `40 分钟`、`18 分钟`、`一周碰到两次` 和缺点事实 `偶尔闪退` 是受保护片段，必须保留——把姿态层和它自曝的真信息一起删掉算 `❌`。

### SF-45 | chat | 自媒体爆款词的同族变体
> 兄弟们，这个库直接封神！性能测试结果炸裂了，重点来了：它把冷启动从 800ms 干到了 90ms。我给你们掰开揉碎讲讲它为什么这么快。

**预期**：`直接封神`、`炸裂了` 按自媒体腔 / 小红书 AI 腔同族处理，`重点来了` 按总结提示腔处理，`掰开揉碎` 按庸医问诊腔变体（同 v1.8.3 的 `掰扯清楚`）处理，不需要词表逐条收录也应命中。数字 `800ms`、`90ms` 保留。改完应像正常的技术分享开场，不是带货文案；把数字一起删掉或改动算 `❌`。

### SF-46 | status | 有指标时必须落回具体结果
> 本次优化在性能方面取得了显著成效，有效改善了接口响应问题，p95 延迟从 480ms 降到 160ms，充分体现了团队持续优化的能力。

**预期**：删掉 `显著成效`、`有效改善`、`充分体现了团队持续优化的能力` 等渲染和自夸表达，但必须逐字保留 `p95`、`480ms`、`160ms` 以及延迟下降的关系。输出只剩“改善了性能”或“降低了延迟”等更泛的替代空话，记 `❌`；不能编造其他指标或技术动作。

---

## 第二部分：不该误杀的（Should NOT Fix）

### A. Short

### SNF-01 | docs | 系统主语描述技术行为
> 网关在请求超时后返回 504。缓存服务每 5 分钟刷新一次热点 key。负载均衡器将流量按权重分配到三个后端节点。

**理由**：技术文档中系统/组件作为主语是合理的，不是虚假主语。

### SNF-02 | docs | 引用原文
> 根据 RFC 7231 的定义："The 200 (OK) status code indicates that the request has succeeded." 这意味着服务端已成功处理了请求。

**理由**：引用原文应保留原样，即使包含被标记的词汇。

### SNF-03 | status | 单独出现的 Tier 2 词
> 然而，这次升级引入了一个已知的兼容性问题，影响 iOS 14 以下的设备。

**理由**："然而"单独出现是合理的转折。只在同段聚集 2+ 个 Tier 2 词时才标记。

### SNF-04 | docs | 行业标准术语
> 该交易使用了 10 倍杠杆（leverage），通过做空期货合约对冲现货风险。

**理由**：金融领域的"杠杆"是标准术语，不应替换。

### SNF-05 | docs (English) | Technical use of flagged words
> The system navigates the network topology using Dijkstra's algorithm, traversing each node to find the shortest path.

**Reason**: "navigates" and "traversing" are literal technical descriptions of graph algorithms, not business jargon.

### SNF-06 | status | 变更日志中的简洁描述
> Fixed: API response time regression. Root cause: unindexed query on users table. Added composite index on (tenant_id, created_at).

**理由**：变更日志的简洁风格不需要改写，句式本身就是直接的。

### SNF-07 | chat | 正常的 Tier 3 低频使用
> 这个功能很重要，上线前一定要确保测试覆盖到位。

**理由**："重要""确保"是 Tier 3 词，低频使用完全正常。

### SNF-08 | docs | 讨论术语本身
> 什么是"赋能"？在互联网行业中，这个词通常被用来指代"提供工具或能力让他人能做之前做不到的事"。但由于过度使用，它已经失去了具体含义。

**理由**：当 Tier 1 词本身是讨论对象时，不应替换。

### SNF-09 | docs (English) | Appropriate passive voice
> The experiment was conducted by researchers at MIT. Results were published in Nature in 2024.

**Reason**: Academic passive voice is conventional and appropriate in research contexts.

### SNF-10 | status | 合理的非第二人称叙述
> 该团队在 Q1 完成了 3 个核心模块的重构，代码行数从 12000 行降到 4500 行。预计 Q2 完成剩余模块的迁移。

**理由**：status 报告用第三人称叙述团队工作是合理的，不应强制改成"你"。

### SNF-11 | chat | 真人工程师 debug 对话中合理使用技术术语
> 刚查了下，root cause 是连接池打满了，max_connections 才 20，高峰期不够用。我把它调到 100，观察了半小时，没再报错。

**理由**：真人工程师在 debug 讨论中使用"root cause""打满"等术语是自然的技术沟通，不是 AI 腔。关键区别：这段话有具体参数（20→100）、具体操作（观察半小时）和具体结果（没再报错），不是空泛的调试腔叙事。

### SNF-12 | public-writing | 真人博主正常使用网络用语
> 昨天踩了个大坑，Next.js 的 app router 在 production build 里 cache 行为和 dev 完全不一样，调了三小时。谁懂那种崩溃感啊。

**理由**：真人在具体经历后自然使用"踩坑""谁懂"，有具体技术细节（Next.js app router、cache 行为、三小时）作支撑，不是 AI 批量生成的空洞感叹。

### SNF-13 | status | 合理的语域一致（纯技术语域）
> 根因分析：OOM 触发了 pod 重启。内存泄漏点在 WebSocket 连接未释放。修复方案：idle 超过 30 分钟的连接自动断开。已上线验证，内存稳定在 512MB 以下。

**理由**：纯技术场景中"根因分析"是标准术语，语域全程一致（技术报告），有具体数据支撑，不需要改。

### SNF-14 | docs | 收词说明中的被讨论词
> 这一轮先不要把"扒开""拽出来""补一刀"逐个加进词表。它们更像现有模式的变体，先补 benchmark 和归并规则，再看要不要单独收录。

**理由**：这里是在讨论词条维护策略，不是在使用这些词制造 AI 腔。被讨论的词应保留原样。

### SNF-17 | docs | 正常的技术注释
> ```python
> # 缓存过期后回源查询，TTL 默认 300 秒
> # 如果 Redis 挂了，fallback 到本地 LRU cache
> def get_user(user_id: str) -> User:
>     ...
> ```

**理由**：正常的代码注释，有具体参数（TTL 300 秒）和具体降级策略（Redis → 本地 LRU），不是 AI 腔。

### SNF-18 | status | 正常的 commit message
> ```
> fix: 连接池上限从 20 调到 100，解决高峰期 504
> ```

**理由**：具体、事实性的 commit message，有数据（20→100）和问题（504），不需要改写。

### SNF-19 | status | 已经直接的事实同步
> 4 月 12 日把连接池上限从 20 调到 100 后，504 错误率从 3.8% 降到 0.6%。今天继续观察 24 小时，再决定是否全量。

**理由**：这段已经是直接的状态同步，重点全在时间、动作、数值和下一步上。即使 protected spans 很密，也不应该为了“更像人”再抛光一遍。

### SNF-20 | docs | 第二遍不该为了节奏改技术说明
> 在 `v2.4.0` 里，`retry_budget=0.2` 时默认开启指数退避；如果看到 `429 too many requests`，先把 `MAX_INFLIGHT=64` 调低再重试。

**理由**：这已经是直接的技术说明，版本号、参数和报错都承载事实。第二遍不该为了“节奏更自然”去改写这种命令式说明，也不能动这些受保护片段。

### SNF-21 | status | 已经够直接时，第二遍应该停手
> 4 月 14 日补回 `source=campaign` 维度后，Android 次日留存从 28.7% 修正到 30.1%。王宁今晚再核一次报表，明早 10 点同步最终数。

**理由**：这段已经把时间、动作、归属、数值和下一步说清楚了。第二遍不该再加口语化停顿、补解释句，或为了“更像人”改掉这种直接同步风格。

### SNF-33 | status | 有指标支撑的“稳定”不是自我宣传残味
> 6 月 28 日把 WebSocket idle 连接自动断开上线后，内存从 1.2GB 降到 520MB，服务稳定在 99.95% 以上。今天继续观察晚高峰，再决定是否全量。

**理由**：这里的“稳定”挂在具体上线动作和指标上（`6 月 28 日`、`WebSocket idle`、`1.2GB`、`520MB`、`99.95%`），是状态同步里的事实描述，不是产品自夸或 README 宣传。v1.9.1 起 `做快、做稳 / 又快又稳 / 更快更稳` 只在自我宣传、项目介绍、营销式 README 等场景里按空泛效率承诺处理；有真实主体、指标或稳定性结果时应放行，不能机械删除或改写。

### SNF-22 | code-context | 技术语境里的接住突发请求
> ```go
> // handleBurst 在 p99 突刺时接住突发请求，按令牌桶节流后转发给下游。
> func handleBurst(req *Request) {}
> ```

**理由**：`接住` 的宾语是 `突发请求`，是技术语境里 handle / absorb 的直接表达，不承担姿态。v1.7.3 起 `接住` 已经按宾语判断：宾语是请求 / 流量 / 峰值时放行，不应因单词命中把代码注释里的技术动作改平。

### SNF-34 | docs | 承担真实插入语的单次破折号
> ## rsync-lite — 单文件同步小工具
>
> 配置支持环境变量覆盖——容器部署时不用改文件——其余场景直接编辑 `config.toml`。默认不删除目标端多余文件，加 `--prune` 才会。

**理由**：结构 20（标点腔）按密度和位置判，不因单次出现命中。标题里的 ` — ` 是命名连接符惯例；正文一对破折号承担真实的插入说明，全段仅此一处，不构成首句起手或高密度信号。`config.toml`、`--prune` 是受保护片段。把这里的破折号机械替换或把标题连接符删掉，算误杀。

### SNF-35 | chat | 「有，而且」开头的真实应答
> 有，而且上个月刚上线：设置页第三个开关就是自动备份，打开后每天凌晨三点跑一次，保留最近 7 份。你要找的应该就是这个。

**理由**：`有，而且……` 单独出现时是正常的应答起手，这里承载了具体信息（开关位置、执行时间、保留份数）。它只在完整推销模板（先夸认证 + 主动加码 + 结尾确认推销）里才作为弱信号参与判断，不单独收词、不单点命中。把这句改平或删掉起手式导致答非所问，算误杀。

### SNF-36 | status | 原文无数据时不强行补具体口径
> 这次主要处理了查询链路。延迟和错误率还没测出来，先继续观察。

**理由**：这段已经短而直白，也明确说明延迟和错误率还没有测量结果。应原样放行；不能因为它“不够具体”就编造数字、模块、技术方案，也不能把它改回渲染词或价值拔高。

### B. Long

### SNF-15 | docs | 长段技术复盘中的工程术语
> 在 2026-03-20 的事故复盘里，我们确认 root cause 是连接池配置过小：`max_connections=20` 在峰值流量下被打满。修复动作包括把上限调到 100、给 `users` 表补复合索引、把慢查询指标接进告警。上线后观察 6 小时，错误率从 3.2% 降到 0.4%，没有再出现连接超时。

**理由**：这是证据充分的技术复盘，虽然包含 `root cause / 打满 / 指标 / 告警` 等工程语汇，但都承载了具体参数、动作和结果，不应为了“去 AI 味”而改平。

### SNF-23 | docs | 限流网关接住上游峰值请求
> 网关层的目标是在流量毛刺期稳稳接住上游峰值请求，避免打穿下游连接池。我们给 `gateway/inflight` 配置了 `max_concurrency=256`，超过后排队 400ms；再溢出就返回 `429` 并打点 `gw.shed_rate`。这样即使 QPS 突破历史峰值，也能把链路保护在可回滚的范围内。

**理由**：整段是具体的限流架构说明，`稳稳接住` 的宾语是 `上游峰值请求`，承载的是限流网关的技术动作，不是姿态层。配置值、阈值、指标名都是受保护片段。v1.7.3 起 `接住` 已按宾语判断：宾语是请求 / 流量 / 峰值时，`docs / code-context` 场景应放行，不应因 `稳稳接住` 短语命中把整段技术说明改平。

### SNF-28 | status | 技术语境里的"落盘"
> 我开始落盘了：把新的重构方案、阶段拆分、边界和 TODO 写进 planning-with-files 目录的三份文档，下一步按这套执行。

**理由**：v1.8.3 起 `落盘 / 落 X` 按宾语判断，规则同 v1.7.3 的 `接住`。这里 `落盘` 的宾语是 `重构方案 / 阶段拆分 / 边界 / TODO` 这类具体技术对象，且能复述"写到哪里"（`planning-with-files 目录的三份文档`），是开发流程中实际的"写入磁盘 / 落地存档"动作，不是姿态层。文档目录名 `planning-with-files`、文档数量 `三份`、阶段词都是受保护片段，不应因 `落盘` 单词命中改平。

### SNF-29 | public-writing / long / in-place | 重复承担节奏，不应被 in-place 当作水分删掉
> 我不想把这篇文章写成一份结论清单。清单当然有效，读者扫一眼就能知道我想说什么，但这件事不是扫一眼就能说完的。
>
> 我想慢一点说。第一次觉得不对，是因为 AI 把我写的几个“其实我还没想清楚”都删掉了。第二次觉得不对，是因为它把两段犹豫合成了一句“这说明作者仍在寻找表达边界”。第三次再看，我才发现问题不在那一句话准不准，而在它把我原本的停顿变成了一个很漂亮的判断。
>
> 所以我想慢一点说。慢不是拖，也不是故意绕。只是有些段落需要重复一次，读者才知道我不是在赶着交付一个观点，而是在把一个还没完全定型的感受说清楚。

**理由**：这里的“我想慢一点说”重复承担段落节奏和作者立场，不是空总结。`in-place` scope 下不应删掉重复句、合并第二段三个时间点，或把全文压成“作者认为 AI 过度整理会损失节奏”。可以句内清理个别过顺表达，但必须保留重复节奏。

### SNF-30 | public-writing / long / in-place | 正常承接句挂在事实上下文里，不是总结式收尾
> 另外，我还观察到一个细节：同一篇文章里，如果前半段是经历，后半段是判断，中间那几句转场看起来常常有点笨。它们不够漂亮，也不像金句，但它们能告诉读者，作者是怎么从经历走到判断的。
>
> 与此同时，很多模型会把这些转场改成更有气势的表达。比如把“我后来才意识到”改成“这背后反映出一个更深层的问题”，或者把“也就是说”后面的解释合并到上一段。改完以后，段落确实更紧，但读者看不到作者转念的过程。
>
> 也就是说，这些承接句不是为了显得高级，而是为了让长文有一条能被跟上的路。

**理由**：`另外 / 与此同时 / 也就是说` 都挂在具体事实和判断上下文里，承担长文承接功能。即使命中连接词或总结提示信号，也不应在 `in-place` 下整句删除、并句或重排。只允许处理句内的拔高词，不能误杀正常转场。

### SNF-31 | public-writing / long / bounded | bounded 删除清单不该混进实句或节奏句
> 这三年我换了两家公司，每一次都在重新理解“稳定”这个词。第一次是在创业团队，稳定意味着别让服务半夜挂掉。第二次是在大厂，稳定意味着别让一次发布影响上千万用户。说到底，我现在更看重那种不需要时刻盯着也能放心的系统。

**理由**：测 `bounded` 删除清单的边界。`说到底` 是句首引导词，但删掉它之后整句仍是带信息的立场判断（作者真正看重什么），不是整句空话 —— 只能句内删 `说到底` 三字，整句不进删除清单。`第一次……第二次……` 是承担节奏的排比，且带具体信息（创业团队 / 大厂、半夜挂掉 / 上千万用户），更不能进清单。如果 `bounded` 把这几句当整句空话删掉或塞进删除清单，记 `❌`。

### SNF-32 | public-writing / long / bounded | bounded 不得把壳句和数据句并成一句
> 在当今快速发展的 AI 时代，我们致力于重塑开发者的内容生产链路。上个月把改写流程接进 CI 后，README 首次整理时间从 18 分钟降到 6 分钟。

**理由**：来源为 `results-v1.8.6` §4 记录的越界行为，用来钉住 `bounded` 防并句边界。第一句是商业黑话壳句，句内洗或进「建议删除（待确认）」清单即可；**不得与第二句合并成一句输出**，更不能把第二句改成总结句或软化成“明显提升效率”之类的新说法。第二句是具体数据句，`上个月`、`接进 CI`、`18 分钟`、`6 分钟` 必须逐字保留。

### SNF-24 | public-writing / README | 已经直接的 README intro
> `cache-diff` 是一个检查 Redis 缓存差异的 CLI。它会读取两份 key dump，列出新增、删除和 TTL 变化，适合上线前做缓存迁移复核。

**理由**：这段 README intro 已经说清楚“是什么、做什么、给谁用”，没有价值口号或发布宣言。`CLI`、`Redis`、`key dump`、`TTL` 都是必要术语，不应为了更口语而改掉。

### SNF-25 | public-writing / release-note | 已经可扫描的 release note
> ## v1.8.0
>
> - 新增 `references/scene-packs.md`，覆盖 README、release note、forum post 和 issue reply
> - `evals/benchmark.md` 增加 8 条 scene pack 回归用例
> - 修复 README 里 benchmark 数量未同步的问题

**理由**：这段 release note 已经按变更列表呈现，有版本号、文件名和具体动作。不要为了“更像人”改成叙事段落，也不要删掉路径、版本号或 case 数量。

### SNF-26 | public-writing / forum-post | 有具体经历支撑的社区帖
> 昨晚把 `scene-packs.md` 接进规则后，先拿 README 和 release note 各跑了两条样本。README 那条提升明显，release note 还差一点：它会删套话，但有时把 changelog 列表也压得太短。今天先补一条 SNF 防误杀。

**理由**：这是正常社区复盘，有时间、文件名、样本范围、发现的问题和下一步。即使语气口语，也有具体经历支撑，不应改成正式公告或删掉 `scene-packs.md`、README、release note、SNF 等关键信息。

### SNF-27 | public-writing / issue-reply | 已经具体的 issue 回复
> 收到，这个 bad case 我能复现：`稳稳接住上游峰值请求` 在 docs 场景里不该被改。下一版我会补一条 SNF，先把技术语境放行钉住；规则本身如果已经能放行，就只加回归用例。

**理由**：这条 issue 回复已经先确认问题、说明复现结果和下一步，没有客服式安抚。`bad case`、`docs`、`SNF` 都是 issue 语境里的必要术语，不应误杀。

### C. Mixed

### SNF-16 | chat | 多轮讨论中引用待收录词
> A：这轮先别把“稳稳兜住”“补一刀”加进词表。<br>
> B：同意，这两个更像现有模式的变体。先补 benchmark，再看要不要进 `phrases-zh.md`。

**理由**：这是在讨论收词策略，不是在正文里表演姿态。即使出现了已标记词，也应因为“被讨论 / 被引用”而放行。

---

## 评测标准

| 类别 | 通过标准 |
|------|----------|
| Should Fix (SF) | 改写后命中项被消除，原意保留，不过度改写 |
| Should NOT Fix (SNF) | 文本保持原样或仅做最小调整，不误杀合理表达 |

- `code-context` 样本额外要求：只处理注释 / docstring / commit message 中的文字，不改动代码本身
- `fact-preservation` 样本额外要求：数字、日期、责任主体、引用、命令、代码、参数、路径、报错、指标和比较关系都必须保真；为了“更自然”补进原文没有的事实，一律记 `❌`
- `Residual Audit` 样本额外要求：第二遍只允许轻量修正；如果为了抛光而重写全文、补新事实，或把 `docs / status / code-context` 写得更口语，记 `❌`
- `Scene Packs` 样本额外要求：先保留大场景边界和 protected spans，再按 `README / release-note / forum-post / issue-reply` 的发布目的收束语气；如果把 release note 写成营销稿、把 forum post 写成公告、把 issue reply 写成客服话术，或删掉版本号、路径、链接、编号和责任归属，记 `❌`
- `Long-form / in-place` 样本额外要求：先判断是否触发 `in-place` scope；触发后不删整句、不合并相邻句、不重排段落。字数留存率目标 `≥ 0.90`，硬下限 `0.85`；句数变化超过约 10% 或关键事实句 / 转场句被删，记 `❌`
- `Bounded` 样本额外要求：句内洗实句、保留承担节奏的重复；整句空话（空总结 / 价值拔高 / 无源引用 / 整句旁白）应进「建议删除（待确认）」清单，而不是直接删或软化成新说法；删除清单里混进实句、带信息句或节奏句，记 `❌`；壳句与紧随其后的数据句被合并成一句输出，记 `❌`；字数留存不设硬下限（删整句空话会降字数），但原文每个信息点必须可追溯
- `必须改写`：能直接消除问题且不损失事实时，应输出改写结果
- `允许只标注风险`：遇到无源引用、缺上下文或不能安全补全事实的样本，允许明确指出风险并不给虚构改写；这种情况记为 `⚠️`，不直接算规则失效
- `mixed` 样本额外要求：只处理真正有问题的正文，不误改引用、用户指令、命令、字段名和被讨论词
- `无源引用类 SF` 额外口径：`public-writing / chat` 默认以删掉无证据权威铺垫为 `✅`；`docs / status` 默认以明确标注缺来源且不伪装成已证实为 `✅`；识别到问题但没有按场景默认动作处理，记 `⚠️`
- 无论场景，给无源引用补出不存在的研究名、机构、年份、专家或数据，一律记 `❌`

**发布门槛**（2026-07-23 起，分层单源见 [benchmark-tiers.md](./benchmark-tiers.md)）：硬约束（protected spans / 编造 / scope 越界 / 归属改变 / 引用边界）失败为 0；SNF 误杀率 < 10%，其中涉编造或受保护片段破坏的误杀为 0；本版新增或修订用例的 targeted 达标。全量风格通过率按模型分别报告、只看趋势，不再要求所有模型统一 > 90%；旧口径 SF 通过率继续并列报告，用于历史对比。