# 场景禁改表

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

先判场景，再判断哪些内容不能乱动。去模板感不等于把所有文本都改成一个口气。

只要环境里能读 `references/`，默认先用 [Protected Spans](./protected-spans.md) 划出不能漂的片段，再按这里的场景禁改项收窄改写范围。

本文件只定义大场景边界。README、release note、forum post、issue reply 这类更细的发布场景，即使初判像 `docs` 或 `status`，也要补看 [Scene Packs](./scene-packs.md)，同时保留这里更保守的事实和术语边界。

## `chat`

目标：

- 自然、直接、有回应感

默认档位：

- `minimal`

无源引用默认策略：

- `rewrite-safe`

不要乱动：

- 不要为了“去 AI 味”把回复改得更硬
- 不要凭空拔高语气或补价值判断
- 不要把简单回应改成总结陈词
- 不要替对方做心理分析、关系诊断或空泛安抚

优先保留：

- 对话节奏
- 具体回应关系
- 合理的口语停顿
- 用户明确要求保留的原话或引用片段

## `status`

目标：

- 事实密度高，读完知道进展、问题、下一步

默认档位：

- `minimal` 或 `standard`

无源引用默认策略：

- `audit-only`

不要乱动：

- 不要删时间线
- 不要删责任归属
- 不要把风险说轻
- 不要为了“更像人”牺牲汇报效率

优先保留：

- 时间、动作、结果、风险、阻塞点
- 数字、日期、范围和责任归属

## `docs`

目标：

- 可检索、可复现、可引用

默认档位：

- `minimal`

无源引用默认策略：

- `audit-only`

不要乱动：

- 不要破坏术语稳定性
- 不要改掉检索词、命令、接口名、字段名
- 不要为了口语化牺牲系统主语和命令式说明
- 不要把正式说明改成闲聊体

优先保留：

- 术语
- 系统行为主语
- 步骤顺序
- 限定条件
- 命令、路径、参数、字段、报错和状态码

## `public-writing`

目标：

- 语域统一，有判断但不端着

默认档位：

- `standard`

无源引用默认策略：

- `rewrite-safe`

不要乱动：

- 不要为了节奏制造夸张判断
- 不要把克制文风改成自媒体吆喝腔
- 不要硬造金句
- 不要把正式公告改成社媒评论

优先保留：

- 作者原有立场
- 正常的正式度
- 必要的修辞节奏
- 已有事实、归属和可核对引用

长文补充：

- 中文长文（约 1000 字以上）默认优先 `bounded` scope，尤其是观点文、复盘文、评论文和带段落节奏的公开文本：句内洗实句、整句空话进「建议删除（待确认）」清单交用户拍板，不并句不重排
- 用户明确要求“完全原样 / 一句都别删 / 严格保句数”，或反馈 `bounded` 仍删多了时，再切到更严格的 `in-place`（整句空话也不删，只句内降调）
- 用户 prompt 含 `保长度 / 别缩水 / 字数 / 节奏 / 别删 / 尽量原样` 这类信号时，即使原文没到 1000 字，也按长文处理
- `bounded / in-place` 下都不把整段压成短摘要；先保段落节奏和承担转场的重复，区别只在整句空话是“进删除清单”还是“留着只做句内降调”
- 标点腔（[结构反模式](./structures.md) 第 20 条）是**句内动作**：破折号按语义改回冒号、逗号或断句，**不进「建议删除（待确认）」清单**；同段的整句空话仍照常进清单。两类动作分开走，不因为同一段里都有就混成一种处理

## 混合场景处理

如果一段文本同时命中多个场景：

1. 先判主要用途
2. 先划 protected spans，再以主场景的禁改项为上限
3. 只清理次场景里明显突兀的词，不追求绝对纯化
