# 边界案例集

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

这些例子不是展示“怎么改得更狠”，而是展示“什么时候该轻改、什么时候不该误杀”。

## 1. 技术状态更新

### 原文

这次排查基本把范围收窄到缓存层了。昨天已经把主链路日志补齐，今天会继续把两个异常分支对上，看看是不是同一类失效路径。如果这个判断成立，修复应该能比较快落下去。

### 推荐改法

这次排查基本已经定位到缓存层。昨天补齐了主链路日志，今天会继续核对两个异常分支，确认是不是同一类失效路径。如果判断成立，修复会比较快。

### 为什么这样改

- 去掉了表演性的工程师腔：`收窄`、`对上`、`落下去`
- 保留了状态同步最重要的三件事：当前判断、已做动作、下一步

### 不该改的点

- 不要删掉“缓存层”“异常分支”“失效路径”这些专业信息
- 不要把它改成泛泛的“问题已经比较清楚了”

## 2. 官方公告风

### 原文

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

### 推荐改法

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

### 为什么这样改

- 这里只做轻改，去掉一点模板化措辞
- 正式公告风本来就是目标语域，不应该强行改口语

### 不该改的点

- 不要把“为保障系统稳定性”硬删掉
- 不要改成聊天式提醒或自媒体语气

## 3. 正常 PRD 腔

### 原文

当用户首次进入工作台且没有历史项目时，页面展示空状态卡片，引导其创建第一个项目。该卡片在用户创建成功后立即消失，后续不再展示。

### 推荐改法

当用户首次进入工作台且没有历史项目时，页面展示空状态卡片，引导其创建第一个项目。用户创建成功后，卡片立即消失，后续不再展示。

### 为什么这样改

- 原文本身就是正常产品语体，不需要“大手术”
- 只把第二句收得更直接一点

### 不该改的点

- 不要为了“像人”把条件句拆坏
- 不要把“空状态卡片”之类的产品术语换成口语

## 4. 已经较口语的文本

### 原文

这版我先不继续抠细节了，核心问题其实已经看出来了。后面先把流程走通，再看哪里真的影响体验。

### 推荐改法

这版我先不继续抠细节了，核心问题已经比较清楚。后面先把流程走通，再看哪些地方真的影响体验。

### 为什么这样改

- 只轻微顺一下，不把口语感抹掉
- 原文本来就自然，过度矫正反而会更假

### 不该改的点

- 不要硬改成汇报腔
- 不要加“本质上”“归根到底”之类的总结句

## 5. 文档段落中的系统主语

### 原文

系统在检测到配置变更后会重新加载规则；如果新规则校验失败，则继续使用上一版配置，并在日志中记录错误原因。

### 推荐改法

系统在检测到配置变更后会重新加载规则；如果新规则校验失败，则继续使用上一版配置，并在日志中记录错误原因。

### 为什么这样改

- 不改。这里的系统主语、条件关系和日志说明都合理
- 去 AI 味不是反对抽象主语，更不是把文档写散

### 不该改的点

- 不要把“系统”硬改成人
- 不要把条件从句改成口语解释

## 6. 英文图算法里的字面动词

### 原文

The system navigates the network topology using Dijkstra's algorithm, traversing each node to find the shortest path.

### 推荐改法

The system navigates the network topology using Dijkstra's algorithm, traversing each node to find the shortest path.

### 为什么这样改

- 不改。这里的 `navigates` 和 `traversing` 是字面技术动作，不是商业黑话
- 去 AI 味不应该把算法描述改得更含糊

### 不该改的点

- 不要把 `navigates` 机械替换成 `handles`
- 不要把算法路径搜索写散

## 7. 学术语体中的正常被动

### 原文

The experiment was conducted by researchers at MIT. Results were published in Nature in 2024.

### 推荐改法

The experiment was conducted by researchers at MIT. Results were published in Nature in 2024.

### 为什么这样改

- 不改。这里是标准学术语体，信息也没有被被动语态掩盖
- 去 AI 味不是强制把所有英文句子都改成主动语态

### 不该改的点

- 不要把学术摘要硬改成口语句
- 不要为了“更直接”删掉发表来源

## 8. 具备具体证据的真人 debug 对话

### 原文

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

### 推荐改法

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

### 为什么这样改

- 不改。这里有具体参数、操作和结果，是正常工程沟通，不是表演性调试腔
- 这类对话的关键是信息密度，不是强行去口头技术词

### 不该改的点

- 不要把 `root cause` 机械改成更书面或更口语的词
- 不要删掉 `20 -> 100` 和 `观察了半小时` 这些关键证据

## 9. 混合场景：技术博客嵌事故复盘

### 原文

> 上个月我们把网关从 Nginx 换到了 Envoy。这篇文章聊聊为什么换、踩了什么坑。
>
> 值得注意的是，在当今云原生快速发展的时代，选择一个真正赋能团队的网关方案已经成为不容忽视的关键议题。
>
> 切换当天出了一次事故。事故复盘如下：
>
> 根因：Envoy 默认连接超时 15 秒，我们的长连接服务需要 300 秒。流量切过去后，长连接全断了，触发上游大面积重连。修复动作：`idle_timeout` 从 15s 改到 300s，灰度验证 2 小时后全量。错误率从 12% 降到 0.1%。
>
> 综上所述，这次迁移充分体现了团队在技术创新领域的持续探索与不懈追求。未来可期！

### 场景判断

1. **判主场景**：整篇是对外技术博客 → 主场景 `public-writing`，默认档位 `standard`
2. **识别次场景**：中间嵌了一段事故复盘 → 局部 `docs` 语域
3. **以主场景禁改项为上限**：`public-writing` 不硬造金句、不改成吆喝腔

### 推荐改法

> 上个月我们把网关从 Nginx 换到了 Envoy。这篇文章聊聊为什么换、踩了什么坑。
>
> 切换当天出了一次事故。事故复盘如下：
>
> 根因：Envoy 默认连接超时 15 秒，我们的长连接服务需要 300 秒。流量切过去后，长连接全断了，触发上游大面积重连。修复动作：`idle_timeout` 从 15s 改到 300s，灰度验证 2 小时后全量。错误率从 12% 降到 0.1%。

### 为什么这样改

- **第二段整段删掉**：命中开场套话（`值得注意的是`）、商业黑话（`赋能`）、空洞拔高（`关键议题`），属于 `public-writing` 主场景下的 `standard` 改写范围
- **复盘段原样保留**：虽然"根因"是 Tier 1 词，但这里是事故复盘的标准术语（误杀防护 #6），有具体参数和数据支撑，属于次场景 `docs` 的保护范围
- **末段整段删掉**：总结式收尾 + 正能量收尾（`综上所述` `充分体现` `持续探索` `不懈追求` `未来可期`），全是 Tier 1 命中

### 不该改的点

- 不要把复盘段里的"根因"改成"原因"——这里是技术复盘语域，不是日常聊天
- 不要把复盘段的格式打散——简洁的"根因 → 修复 → 结果"结构在 `docs` 语域下是对的
- 不要为了语域统一把博客开头也改成复盘腔

## 10. 技术语境里的“接住请求”

### 原文

网关在压测里接住了峰值 2.4 万 QPS，请求超时率稳定在 0.3% 以下；超过阈值的流量会自动走降级，不再继续打满下游连接池。

### 推荐改法

网关在压测里接住了峰值 2.4 万 QPS，请求超时率稳定在 0.3% 以下；超过阈值的流量会自动走降级，不再继续打满下游连接池。

### 为什么这样改

- 不改。这里的 `接住` 对应的是技术承接能力，宾语是 `峰值 2.4 万 QPS`，还有具体指标、系统行为和降级边界
- 这种写法和“稳稳地接住你 / 所有人”不是一回事，不能因为字面重合就一起打掉

### 不该改的点

- 不要把 `接住了峰值 2.4 万 QPS` 机械改成空泛的“性能很好”
- 不要删掉 `0.3%`、`降级`、`下游连接池` 这些承载判断依据的技术信息
