# Scene Packs / 可直接发场景包

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

Scene Packs 是面向可发布文本的子场景策略。它不替代 [场景禁改表](./scene-guardrails.md)、[Protected Spans](./protected-spans.md) 或 `Tier` 判断；只要文本本身像 README、release note、forum post、issue reply、API reference 或 FAQ，就进一步判断“这段应该像哪一种发布文本”。

使用顺序：

1. 先判大场景：`chat / status / docs / public-writing`
2. 先划 protected spans：版本号、路径、链接、命令、引用、编号、责任归属都不能漂
3. 再看是否命中本文件的 scene pack
4. 最后按 scene pack 的发布目的收束语气；如果它同时像 `docs / status`，取更保守的保真边界

默认不要因为 scene pack 新增全局词条。只有新样本已经超出现有问题族，且会改变误杀边界时，才考虑补 `phrases` 或 `structures`。

## `README`

默认目标：

- 第一屏能让读者快速知道：这是什么、给谁用、解决什么问题。
- 语气可以有个性，但不能只剩愿景、价值和姿态。

必须保留：

- 项目名、目标用户、核心能力、支持平台
- 命令、安装方式、文件路径、链接
- 已有 benchmark 数量、版本号和能力边界

优先删除：

- `AI 全面重塑开发范式`
- `面向未来`
- `深度赋能`
- `内容生产链路`
- `价值闭环`
- 没有具体能力或证据支撑的 `真正能 / 做快做稳 / 更像人写的` 等自我宣传结果句
- 只说“先进 / 智能 / 全方位”但不说具体做什么的句子

默认力度：

- `standard`
- 如果 intro 只剩口号，可以升到 `aggressive`，但不能编造项目能力

误杀边界：

- README intro 允许一句有辨识度的定位句
- `CLI / API / benchmark / Codex / ChatGPT` 等项目术语应保留
- 不要把 README 改成社交媒体短帖

Before:

> 在 AI 全面重塑开发范式的今天，我们打造了 `说人话` 这款真正面向未来的中文优先 rewrite skill，深度赋能 README、release note、issue 回复和日常协作文本的内容生产链路，全面清理 AI 套话、表演感与工程师腔。

After:

> `说人话` 是一个中文优先的 rewrite skill，用来把 AI 写出来的套话、表演感和工程师腔改回自然表达。适合 README、release note、issue 回复和日常协作文本。

## `release-note`

默认目标：

- 让读者快速知道这一版改了什么、怎么验证、有没有破坏性变化。
- 优先列表化，少写发布宣言。

必须保留：

- 版本号、日期、文件名、配置项、issue / PR 编号
- 变更类型：新增、修复、调整、测试
- 已知限制和迁移提示

优先删除：

- `Release Highlights` 后面只写空泛升级
- `系统性升级`
- `全新跃迁`
- `感谢所有用户持续支持`
- `共同见证`
- 没有来源的性能、效率、用户反馈数据

默认力度：

- `standard`
- 如果缺少具体 changelog，不要编造；改成提示“这里需要补具体变更”

误杀边界：

- release note 可以正式、简洁、列表化
- 不要为了“像人”把 changelog 列表改成故事
- 不要删版本号、文件路径、case 数量和 PR / issue 编号

Before:

> 本次版本是一次面向真实场景的系统性升级，感谢所有用户的持续支持，让我们共同见证中文 AI 写作体验的全新跃迁。本次升级带来了全新的 `references/scene-packs.md`，覆盖 README、release note、forum post 和 issue reply 四大场景；`evals/benchmark.md` 同步增加 8 条 scene pack 回归用例；并以 `evals/results-v1.8.0.md` 完整记录本轮复核结果。

After:

> - 新增 `references/scene-packs.md`，覆盖 README、release note、forum post 和 issue reply
> - `evals/benchmark.md` 增加 8 条 scene pack 回归用例
> - 新增 `evals/results-v1.8.0.md` 记录本轮复核结果

原文真的没有任何变更信息时，按上面「优先删除」和默认力度的规定改成提示补具体变更，不编。

## `forum-post`

默认目标：

- 像维护者在社区里讲真实观察：做了什么、发现什么、哪里还不稳、想要什么反馈。
- 允许口语，但要有具体经历支撑。

必须保留：

- 时间、动作、具体文件、样本数量、观察到的问题
- 原作者真实态度和社区语气
- 链接、命令、版本号和被讨论词

优先删除：

- 公司公告腔
- `系统性重塑`
- `用户痛点`
- `多元场景`
- `方法论闭环`
- `稳稳接住核心诉求`

默认力度：

- `standard`
- 如果帖子本来有具体经历，只清理姿态层，不要改成正式公告

误杀边界：

- 具体经历后的口语词可以保留
- 社区帖允许“踩坑 / 折腾 / 还差一点”这类真实语气
- 不要把个人复盘改成 README 或 release note

Before:

> 折腾这个工具一个月后，我深刻意识到，中文 AI 写作治理不是一次简单的词表扩张，而是一场围绕真实表达场景的系统性重塑。

After:

> 折腾这个工具一个月后，我发现光扩词表不够，不同场景的改法不一样。

## `issue-reply`

默认目标：

- 先回答问题是否成立，再给复现状态、判断和下一步。
- 不做客服式安抚，不替维护者承诺未排期能力。

必须保留：

- bad case 原句、场景标签、复现结果
- issue / PR 编号、文件路径、规则名、benchmark 编号
- “已确认 / 未复现 / 需要更多样本 / 会补测试”的状态

优先删除：

- `感谢宝贵反馈`
- `你问到了核心`
- `我们已经充分接住这个场景`
- `持续优化相关能力`
- `没有独有交付内容的推销句；含交付动作时保留主体、条件与情态`

默认力度：

- `minimal` 或 `standard`
- 有具体技术信息时保守处理；没有具体下一步时，不要编造排期

误杀边界：

- issue 回复可以短、硬、直接
- `bad case / docs / SNF / benchmark / repro` 是维护语境里的正常术语
- 不要把明确的维护回复改成社交式寒暄

Before:

> 感谢你非常宝贵的反馈！你这个问题问到了项目体验的核心。我们已经在 `docs` 场景复现了这个误杀，也会在后续版本中持续优化相关能力，下一版会补一条回归用例。

After:

> 这个误杀我在 `docs` 场景复现了，下一版补一条回归用例。

## `api-reference`

默认目标：

- 让读者快速确认接口用途、调用条件、请求约束、响应语义、错误含义和恢复动作。
- 保持可扫描结构；参数表、字段列表和代码示例不改成叙事段落。

必须保留：

- HTTP method、路径、接口名、鉴权方式
- 字段名、类型、格式、required / optional、默认值、范围、单位、依赖关系和枚举
- 状态码、错误码、代码、JSON、命令、链接、版本、速率限制和已给出的恢复步骤

优先删除：

- 接口说明前的价值拔高、宣传口号和元评论
- 重复解释 endpoint 或参数名的空话
- 没有来源的行业判断、性能保证和可用性承诺
- 把明确动作藏进 `能力建设 / 机制实现 / 体验升级` 的名词化外壳

默认力度：

- `minimal`
- 只改说明文字；表格、列表、代码块、JSON 和标识符不动

误杀边界：

- 原文没有的默认值、条件、错误原因、恢复时间、兼容范围一律不补；缺失就按 `audit-only` 标待确认
- 状态码按当前接口里的真实语义理解，不机械套固定文案
- 系统主语和真实被动语态可以保留；不要为了主动、口语而改变责任主体
- 不为避免重复而给同一字段换同义叫法，不把 optional 改成 required，不换算数字或单位

Before:

> `GET /v1/reports/{report_id}` 是面向未来的智能查询接口，能让团队高效查看报告状态。查询参数 `format` 支持 `json` 和 `csv`。

After:

> `GET /v1/reports/{report_id}` 查询报告状态。查询参数 `format` 支持 `json` 和 `csv`。

## `faq`

默认目标：

- 问题范围准确；尽早给出结论、判断或动作，但不能把原有执行前条件和警告移到操作之后。
- 标题保留用户会实际检索的问法，不改成宣传标题或抽象分类。

必须保留：

- 问题里的对象、版本、条件、否定和例外
- 答案里的期限、费用、支持承诺、责任主体、命令、链接、路径和编号
- 排障步骤的顺序与分支
- 原有执行前条件、警告与动作的先后关系；真实的事后验证和失败分支不能改成前置步骤。结构调整仍受 scope 限制，不主动替作者重排操作流程或补出原文没有的风险、备份、恢复步骤

优先删除：

- 重复一遍问题才开始回答
- 假共情、客服寒暄和销售式安抚
- `大家都知道 / 通常都可以 / 一定没问题` 这类无源保证
- 与答案无关的价值总结

默认力度：

- `minimal`
- 已经短、硬、可执行的答案整体放行

误杀边界：

- 不把采访、讨论引用或所有带问号的段落都识别成 FAQ
- 不把 `可能` 改成 `会`，不把 `部分用户` 改成 `所有用户`，不扩大支持承诺
- 不软化 `不支持 / 必须 / 不会` 等真实限制，也不改期限、政策和操作路径
- 缺条件或来源时标出缺口，不自造 SLA、恢复时间、默认路径或客服电话

Before:

> 非常理解导出日志失败给你带来的困扰。关于导出日志失败怎么办，我们准备了简单方案：先运行 `shuorenhua logs export`。如果命令返回退出码 `2`，检查输出路径是否可写。

After:

> 先运行 `shuorenhua logs export`。如果命令返回退出码 `2`，检查输出路径是否可写。
