# Positive Style Contract

> 本文件是解释、示例与操作细则；行为合同的单源是 `SKILL.md`，两处表述不一致时以 `SKILL.md` 为准。

> 目标不是只把 AI 套话删干净，而是把文本拉回当前场景里“像具体人在说这件事”的状态。

这份文档定义的是正向目标，不是新的 house style，也不是 voice 拟合协议。

它解决的问题是：

- 删完套话后，文本还是太平、太匀、太像“被清理过的 AI”
- 为了“更自然”乱加情绪、乱补细节，反而把文本写假了
- 不同场景都被抹成同一种“聪明、顺滑、会总结”的口气

使用顺序：

1. 先按 `SKILL.md` 判场景，确认主语域和禁改边界
2. 先看 [Protected Spans](./protected-spans.md)，把不能漂的内容圈出来
3. 再判 `Tier` 和档位
4. 再用这份正向合同判断“改成什么样才算更像人”

## 1. Anti-goals

这份合同不追求：

- 不强行口语化
- 不硬造个人 voice
- 不把每句都抛光得很顺
- 不靠金句、反问句、碎句或抒情句制造“人味”
- 不为了更具体而补原文没有的事实

## 2. Positive targets

改写后的文本，优先往下面这 5 个方向靠：

### 2.1 具体动作优先于抽象拔高

优先写谁做了什么、改了什么、看到什么，不用“能力提升”“价值释放”“底层重构”这类空壳抬句势。

更好：

> 把缓存从本地 LRU 换成 Redis，峰值时不再把应用内存打满。

不够好：

> 完成缓存层升级，显著提升系统稳定性与整体韧性。

### 2.1.1 清理后的落点

删掉姿态层之后，句子要落在原文已经给出的信息上，而不是换成另一句更泛的空话。优先级固定为三档：

1. 原文有数字、动作、对象或明确结论：清掉渲染词，但把这些信息保留下来。
2. 原文没有具体指标或事实：允许输出更短、更直白；不要用“能提效”“有改进”“降低了延迟”“面临挑战”这类泛化句填空。
3. `status / docs` 需要具体依据才能成立、而原文又没给时：标注“原文缺具体依据”，不要补数字、功能、来源或技术选型。

抽象信息也不能擅自“具体化”。原文只说“提升效率”，不能改成“省时间”“降低成本”或“提高产量”；原文只说“仍有挑战”，不能自行补成技术难题、合规风险或学习清单。删掉鸡汤和劝导骨架后，也不要用“值得尝试”“继续学习”这类新劝导填回去。

反例：

> 原文：这次调整显著改善了查询性能，主查询从 800ms 降到 120ms。
>
> ❌ 这次调整改善了性能。
>
> ✅ 这次调整把主查询从 800ms 降到 120ms。

如果原文只有“显著改善了查询性能”，没有指标，就可以写成“这次调整改善了查询性能”，并在 `status / docs` 场景提示缺具体指标或依据；不能自行补出延迟、模块或百分比。

无源引用还有一条额外边界：如果具体数字或预测本身没有来源，不能删掉 `40%` 后把同一句降格成“会更快”，也不能把 `未来十年` 改成“未来几年”。`rewrite-safe` 要么删除整条无法独立成立的论断，要么只保留原文中不依赖该来源也能成立的信息；保守场景则退回 `audit-only` 标注缺来源。

### 2.2 真主语和真动作优先于姿态层

优先保留承载事实的主语和动作，少写“我们需要深入思考”“接下来稳稳兜住”这种姿态层。

更好：

> 我先核对了两个异常分支，确认都是同一类超时。

不够好：

> 我们已经把关键现象对上，接下来会进一步把核心链路稳稳兜住。

### 2.3 节奏可以自然，不要整段一样齐

自然表达允许有轻微不对称：有的句子短一点，有的句子稍微展开一点。不要把每句都写成同长度、同抬手、同落点。

长文里，适度重复不一定是废话。它可能承担转场、停顿、强调或情绪缓冲。判断一处重复该不该删，先看删掉后段落衔接是否突兀；如果突兀，优先保留节奏，只处理句内的模板词和拔高词。

bounded scope 下，这条边界落在删除清单上：承担节奏的重复和转场不进清单；进清单的必须是剥掉引导词后什么都不剩的整句空话。

更好：

> 数据库这轮先快了。主查询从 800ms 降到 120ms，前端首屏也跟着从 2 秒降到 0.4 秒。

不够好：

> 本次更新优化了数据库性能。我们提升了页面加载速度。用户反馈的问题也得到了解决。

上面「更好」里的数字，只有手里真有这些数据时才能写。原文没有数据的，只调句长和句序制造节奏，不要为了节奏编数。

### 2.4 允许普通句子存在

不是每句都要“像结论”。如果一句普通事实句已经够用，就不要再补“这说明了什么”“本质上意味着什么”。

长文里的普通承接句也可以存在。`另外`、`与此同时`、`也就是说`、`换个角度看` 这类连接，如果后面接的是具体事实、经验或判断，不要直接归到总结式收尾或 narrator 腔。先保住它的承接作用，再看句内有没有空泛修饰需要压低。

更好：

> 这次先把权限边界补上，避免游客也能看到内部页面。

不够好：

> 这不仅仅是一次权限修复，更体现了我们对产品边界和安全性的深度思考。

### 2.5 统一语域，不装另一种人

`chat` 可以自然，但别端着；`docs` 可以专业，但别演洞见；`public-writing` 可以有判断，但别像公告或喊单。

### 2.6 有边界比硬演理解更自然

可以温和，但别替对方做心理判断，也别把“我现在完全懂你了”演成内容本身。

更好：

> 我在听。如果你愿意，可以继续说。

不够好：

> 你不是敏感，你只是太久没被稳稳接住了。我必须认真地说一句：你比大多数人都清醒。

## 3. Scene calibration

### `chat`

目标：

- 像在回应对方，不像在发表说明
- 可以口语，但不要谄媚、教学腔、总结腔，也不要替对方下心理结论

更好的迹象：

- 直接回答
- 有回应关系
- 有一点自然停顿，但不拖

### `status`

目标：

- 读完能知道进展、问题和下一步
- 重点是时间线和结果，不是“完成了一次重要升级”

更好的迹象：

- 动作和结果分得清
- 风险没被写轻
- 如果有数字、结论、归属，能一眼找到

### `docs`

目标：

- 读起来像说明文，不像宣传文
- 专业词能保留，句子只做必要收束

更好的迹象：

- 可检索词还在
- 句子更直，但术语没散
- 不为了“更像人”把正式说明改成闲聊

### `public-writing`

目标：

- 有判断，但判断来自事实和经验，不来自空抬
- 可以有节奏，但不要吆喝、喊口号、假装深刻

更好的迹象：

- 能看出作者到底想说什么
- 少用“时代”“变革”“真正的 X”这类泛大词
- 保留必要修辞，但不把段落写成海报文案

## 4. Cleaner vs more human

下面这几组不是“唯一正确答案”，而是展示差别在哪里。

### A. `status`

原文：

> 本次优化显著提升了系统整体性能，并有效改善了用户体验。

清理后但还偏 AI：

> 这次优化提升了系统性能，也改善了用户体验。

更像人：

> 这次主要改了查询链路。首页接口从 800ms 降到 120ms，之前那批卡顿反馈也少了很多。

差别：

- 第一版只是把夸张词削弱了
- 第二版把“提升了什么”说具体了

### B. `docs`

原文：

> 该能力不是一个简单的配置选项，而是一套面向未来的系统性机制。

清理后但还偏 AI：

> 该能力不是简单的配置选项，而是一套系统机制。

更像人：

> 这不是单个配置项。它会一起改缓存策略、重试逻辑和超时设置。

差别：

- 第一版还保留了拔高骨架
- 第二版直接解释它具体会动到什么

### C. `public-writing`

原文：

> 真正的竞争力不是功能堆砌，而是体验细节。

清理后但还偏 AI：

> 竞争力不在功能堆砌，在体验细节。

更像人：

> 功能补得再快，如果延迟高、引导乱、错误提示看不懂，用户还是不会留下来。

差别：

- 第一版只是把句子缩短
- 第二版把判断落回具体体验

## 5. Final check

提交改写前，再问自己这 5 件事：

1. 这段是在说事，还是还在演“我很会总结”
2. 关键判断有没有落到动作、结果、例子或条件上
3. 句子是不是顺了，但没被抹成同一种腔
4. 当前场景下，正式度有没有被改坏
5. 如果要“更像人”就必须补新事实，那这一步应该停住

如果删完以后只剩空架子，不要补口号，优先补事实句。