# 轻量 eval：真实样本测试基准

> 能拿高 star 的去 AI 味工具有个共性：不靠自说自话，拿真实样本反复测。这份基准是给本 skill 的"考卷"。
> 用法：把每条「原文」喂给走完整流程的 skill，对照「期望诊断」和「验收点」检查。改过 skill 之后重跑一遍，看有没有退步。
> 判分原则：**诊断对不对（哪个坐标空了）比改得好不好更重要**——诊断对了，改法才稳。
>
> 版本：v2（6 条样本，含 3 条反向防误杀）。新增样本时标注场景和加入日期。

---

## 样本 1 · 公众号开头（场景：自媒体）

**原文**
> 在当今这个信息爆炸的时代，不可否认，高效阅读已成为现代人的核心竞争力。众所周知，那些善于筛选信息的人，往往能在职场中占据先机。

**期望诊断**
- 说话人空（没有"我"、没有任何只有这个作者会说的话）
- 听众空（"众所周知""不可否认"假设了不存在的共识，对谁都成立）
- 赌注空（全是正确的废话，没有非说不可的一句）

**验收点**
- [ ] 三个坐标都被点出来，不是只说"这句是套话"
- [ ] 改后出现一个具体的说话人（带经历或立场）
- [ ] 删掉了"在当今时代"这类背景铺垫
- [ ] **无内容源不得虚构填充**：原文没有真实材料时，不许替作者编经历/数据/案例。正确产物是"诊断 + 改写形状（带占位）+ 向作者要料"，不是一篇编出来的范文

**常见改错 A**：只把"在当今这个信息爆炸的时代"删了，剩下的句子还是悬浮的中立口吻——说话人坐标仍然空着。
**常见改错 B**：为了"改好看"，替这个不存在的作者编了一段亲身经历（如"我收藏了几百篇却没回看"）。这是把空坐标换成假坐标，违反红线。

---

## 样本 2 · release note（场景：技术文档，测"别硬塞个人腔"）

**原文**
> 🚀 激动人心的更新来啦！我们倾注心血，只为给您带来前所未有的极致体验，让效率飞起来！

**期望诊断**
- 说话人塞错了（硬凹一个兴奋的推销员，而文档的说话人该是"系统/规范"）
- 听众空（来查 release note 的人只想知道"改了什么、影响我吗"）
- 赌注偏了（赌营销，不是帮人判断要不要升级）

**验收点**
- [ ] 识别出这是"说话人塞错"，不是"说话人空"
- [ ] 改后是非个人的、信息式的变更说明
- [ ] **没有**为了"像人"加第一人称闲聊（这是本条的关键陷阱）
- [ ] 保留版本号、功能名等可检索信息

**常见改错**：把推销腔换成另一种亲切的第一人称（"我这次给大家加了……"）——同样是塞错了说话人，技术文档的坐标该非个人。

---

## 样本 3 · 工作汇报（场景：职场，测"赌注空"）

**原文**
> 本周持续推进了数据同步模块的优化，有效提升了整体性能，为后续工作奠定了坚实基础，团队协作顺畅。

**期望诊断**
- 赌注空（上级读完不知道做了什么、有没有风险、要不要介入），用"持续推进/有效提升/坚实基础"大词填满
- 说话人偏虚（"团队协作顺畅"是表态不是说事）

**验收点**
- [ ] 主诊断落在"赌注空"，而不是逐个数大词
- [ ] 改后能让上级一眼看到：做了什么、结果、下一步、需要 ta 知道的风险
- [ ] 没有编造原文没有的具体数字（如果原文没给数字，改后也不能凭空造）

**常见改错**：把大词换成稍小的词（"提升性能"→"改善性能"），赌注依然空——读者还是不知道具体发生了什么。

---

## 样本 4 · 接口说明（场景：技术文档，测误杀防护 / 期望"基本不改"）

**原文**
> 该接口在并发请求超过阈值时返回 429，客户端需实现指数退避后重试。

**期望诊断**
- 三个坐标都在且都合法非个人：说话人=接口规范，听众=接入方开发者，赌注=让对方正确处理限流
- 这不是 AI 味，是合格的技术写作

**验收点**
- [ ] 判定为"坐标都不空"，**建议不改**或仅做极小润色
- [ ] 保留 429、指数退避、阈值等术语，一个不漂
- [ ] 不因为句子"读起来工整、像 AI"就强行口语化

**常见改错**：把它"humanize"成"如果请求太多，接口会拒绝你，记得等一会儿再试"——破坏了术语精度和责任主体。这条专门测过度改写。

---

## 样本 5 · 维护公告（场景：职场通知，测"只轻改、别改成口语"）

**原文**
> 为保障系统稳定性，我们将于今晚 23:00–23:30 对支付服务进行例行维护。维护期间，部分用户可能出现短时下单失败的情况。维护完成后将自动恢复，无需额外操作。

**期望诊断**
- 三个坐标都在：说话人=发公告的服务方（非个人，合法）、听众=可能受影响的用户、赌注=让用户知道何时受影响、要不要操作
- 这是合格的公告语体，不是 AI 味

**验收点**
- [ ] 判为"坐标都在"，**最多只去一点模板措辞**（如"出现……的情况"可收成"出现……"），不大改
- [ ] **不**改成聊天式提醒或自媒体腔（"宝子们今晚系统要修啦～"）
- [ ] 保留时间、影响范围、是否需操作

**常见改错**：为了"像人"把公告改成口语贴，破坏了正式通知该有的语域。公告的听众要的是清楚，不是亲切。

---

## 样本 6 · 带证据的真人 debug（场景：协作沟通，测"别删技术证据当口头禅")

**原文**
> 刚查了下，root cause 是连接池打满了，max_connections 才 20，高峰期不够用。我把它调到 100，观察了半小时，没再报错。

**期望诊断**
- 三个坐标都满：说话人=查问题的本人（有"我"、敢下结论）、听众=同组要跟进的人、赌注=说清根因和已验证的修复
- 信息密集，是正常工程沟通，不是表演性调试腔

**验收点**
- [ ] 判为"坐标都满，建议不改"
- [ ] 保留 root cause、max_connections、20→100、观察了半小时 等关键证据
- [ ] **不**把 root cause、连接池当成"工程师腔"误杀掉

**常见改错**：把"root cause""连接池打满"当口头禅删掉或换成模糊说法（"大概是某个配置不太对"）——这恰恰删掉了让说话人坐标成立的证据。有具体参数和结果的技术句，是真人在场最强的信号，不是 AI 味。

---

## 怎么用这份基准

1. 逐条把「原文」交给 skill，要求走完整流程（定坐标 → 诊断 → 改 / 或判定不改）。
2. 对照「期望诊断」看坐标判断对不对；对照「验收点」逐项打勾。
3. 样本 2、4、5、6 是反向测试——测的是"会不会改过头/误杀"，比正向样本更能暴露问题。一个去 AI 味工具的下限，就看它会不会把好文本改坏。
4. 全部通过才算这一版 skill 站得住。任一条退步，回去查是规则改坏了还是诊断逻辑漂了。