pr-description

为熟悉项目但尚未阅读 issue、差异内容或开发对话的审阅者撰写拉取请求说明。先说明变更的缘由，再解释其实现方式。

如果用户要求草拟说明，请直接返回文本，不要更新 GitHub。否则，更新指定的 PR 说明。

参数

/pr-description <PR_NUMBER> [--fixes <ISSUE_NUMBERS>]

• PR_NUMBER（必需）：要描述的拉取请求。
• --fixes（可选）：此 PR 修复的问题编号，以逗号分隔，例如 123,456。

示例：

• /pr-description 3534
• /pr-description 3534 --fixes 123,456

说明

1. 收集变更信息：

   • 阅读 PR 标题、当前说明、基分支和头分支。
   • 阅读 PR 提交和差异内容。使用 PR 实际的基分支和头分支；不要假设当前检出的分支就是 PR 分支，也不要假设其基分支是 main。
   • 阅读相关 issue 详情、代码注释和可用的对话上下文，以了解问题及变更原因。
   • 收集 --fixes 中的问题编号，以及提交消息中明确提及的关闭引用。不要推断应该关闭某个相关 issue。

2. 检查现有说明。如果说明已经准确、无需借助外部上下文即可理解，并且符合此格式，请保持不变。否则，围绕最终实现重写，而不是追加更新内容。

3. 在选择项目符号前，先明确核心说明：

   • 受影响的组件有什么作用？
   • 是什么限制或需求促成了这项变更？
   • 它将有哪些不同的行为？ 只使用理解此 PR 所需的上下文。不要为了证明某项功能或重构有必要而编造问题。

4. 选择审阅者需要评估的不同关注点。通常将其整理为 3 到 6 条带标签的项目符号；小型变更可以更少。按行为或系统职责分组，而不是按文件、辅助函数或实现步骤分组。

5. 不参考差异内容，单独阅读草稿。如果仍不清楚变更的目的或行为，请补充缺失的上下文，再添加更多实现细节。

格式

先写一个开篇段落，然后列出带标签的项目符号。不要添加 Summary、Context 或 Testing 标题。仅在适用时添加 Breaking Changes 和 Fixes。

Pipecat groups streamed LLM text into sentences before sending it to TTS. This
replaces NLTK with `sentencex`, which includes its language rules and requires no
data downloads or tokenizer warm-up.

- **Streaming text.** Sentencex sometimes needs the complete word after a period
  to distinguish an abbreviation from a sentence ending. Pipecat waits for that
  word when needed, while sending sentences sooner when the ending is already clear.
- **Quoted abbreviations.** Sentencex can split after `"Dr.` before the rest of the
  quotation arrives. Pipecat rechecks these cases so it doesn't send an incomplete
  fragment to TTS.
- **TTS language.** Sentence grouping follows `Settings.language`, defaulting to
  English when unspecified. Language updates take effect before subsequent text
  is processed.

## Breaking Changes

- Sentence grouping can differ from Punkt and now follows the configured TTS language.
- Pipeline workers no longer emit tokenizer warm-up events.

开篇段落

说明组件的作用、相关限制或需求，以及变更内容。读者只看这一段就应该能理解 PR 的目的。对于小型变更，一句话就够；如果读者需要背景信息，可以写两到三句。不要强行把这三点塞进一个冗长的句子。

背景信息应与变更直接相关。替换实现时，可能需要简要说明当前实现和拟议实现有何不同，尤其是当这种差异能解释 PR 中额外处理逻辑的原因时。可以链接 issue 以辅助说明，但不能用链接代替说明。

带标签的项目符号

每条项目符号都以加粗的名词标签开头，标签用于命名类、模块、界面或行为。切勿使用 Motivation、Rationale、Background、Context 或 Tests 这类文章式标签。

先说明行为或问题。只有在有助于审阅者评估变更时，才解释实现机制。通常一到两句话就够；如果第三句能提供必要上下文或示例，简短补充也可以。不要仅为满足句子数量限制而把一个连贯的关注点拆成多条项目符号。

如果 issue、对话、提交消息或代码中说明了变更原因，请将其与相关变更一并说明。陈述变更所满足的约束，而不是论证该决策正确。相关的前后对比很有帮助；通常不必罗列曾尝试或否决的方案。

术语和示例

在使用技术术语前先介绍它，或者改用普通词语。像“lookahead”这样的标签并未说明检查的是哪些文本、文本何时到达，也没有解释为什么等待很重要。应先描述这些行为。

对于解析、排序或流式处理方面的更改，如果简短的输入／输出示例比抽象描述更能说明问题，就优先使用示例。示例不局限于新 API。内联文本足够时就使用内联文本；只有在需要展示序列或配置时，才在 PR 描述中加入一个简短的代码块，最多一个。

破坏性更改

如果更改了用户需要留意的现有行为、签名或默认值，请添加本节。说明具体影响以及所需的迁移步骤。不要为了达到字数目标而省略本节，也不要仅仅因为新增了功能，就将其标记为破坏性更改。

修复

对于此 PR 旨在关闭的问题，每条项目符号使用一个 Fixes #X。如果相关 PR 或问题有助于说明范围，可以在开头段落或相关项目符号中链接；不要单独添加“背景”部分。

长度和依据

目标是不超过 200 词，但不要为了达到这个目标而省略必要背景。优先删去重复的说法和次要的实现细节。描述长度应取决于审阅者需要了解的内容，而不是 diff 的大小。

准确描述 diff 中的实现和行为。问题陈述和原因应以问题、代码或现有讨论为依据。不要编造动机、把狭窄的观察泛化，也不要把测得的样本说成普遍的性能结论。

如果第二句能帮助读者理解第一句，可以保留。只有在它重复相同信息、没有帮助时才删去。

请勿包含：

• 声称更改正确，或回应无人提出的异议。
• 按时间顺序叙述开发过程，或逐段权衡不同方案。
• 测试数量、覆盖率数字、“所有测试均通过”、更改过的测试列表或测试命令。
• 对已更改文件逐一进行讲解。
• 警句、宣传用语，或对项目符号内容进行结尾总结。

语气

请像向不了解这项工作的队友解释更改一样写作。使用通俗的措辞、缩略表达和简短连贯的句子。在技术细节有助于澄清问题或对审阅很重要时予以保留。

避免刻意追求对称、三项并列、“不是 X，而是 Y”之类的句式，以及本可用逗号或另一个句子表达的破折号插入语。不要为了让每条项目符号的形式或长度一致，而牺牲清晰的说明。

检查清单

• 开头提供了足够的背景来说明 PR 的目的。
• 无需打开 diff，读者也能说明相关限制和新行为。
• 各项目符号涵盖不同的审阅关注点，并以行为或问题开头。
• 技术术语均有介绍；对于难以理解的边界情况，在适当时提供示例。
• 原因和更改前后的对比均有现有证据作为依据。
• 描述反映最终实现，而非开发过程。
• 在适用时，包含破坏性更改和要关闭的问题引用。
• 不包含“测试”部分、测试数量、覆盖率数字或重复总结。
• 在不隐瞒必要背景的前提下，尽量将描述控制在 200 词以内。