企业官网建设流程全解析

Please describe the changes in your PR. If it is addressing an issue, please reference that as well.

【免费下载链接】pipecatOpen Source framework for voice agents, multimodal apps, and realtime AI. Maintained by Daily and the community.项目地址: https://gitcode.com/GitHub_Trending/pi/pipecat

也就是说，如果贡献者创建 PR 时没有手动填写描述，PR 描述就停留在这一行模板文本上，这正是 `/pr-description` 需要接管的情形。 ### 第三步：分析变更内容 这一步把 diff 转化为语义层面的结论，规则包括： - 理解**每个 commit 的意图**（结合 `git log main..HEAD --oneline` 的提交信息）； - 识别**破坏性变更**：API 变更、被移除的功能、行为变化； - 归类为**新功能、Bug 修复、重构或文档变更**之一或若干； - 收集 Issue 编号，来源有两个： - `--fixes` 参数（如果提供）； - commit message 中符合约定模式的文本，例如 `Fixes #123`、`Closes #456`、`Resolves #789`。 值得注意的是：从 commit message 收集时使用“Fixes / Closes / Resolves”多种模式做**输入**匹配，但输出到描述时会被统一规整（见下一节的 Fixes 规范）。 ### 第四步：生成或更新描述 描述输出为固定的四段式结构，各段有明确的包含条件。 #### Summary（必须包含） 用简短的要点说明“改了什么、为什么改”，聚焦**目的与影响**而非实现细节： ```markdown ## Summary - Added X to enable Y - Fixed bug where Z would happen - Refactored W for better maintainability

Breaking Changes（仅在有破坏性变更时包含）

记录所有影响既有用户或 API 的变更：

## Breaking Changes - `ClassName.method()` now requires a `param` argument - Removed deprecated `old_function()` - use `new_function()` instead

Testing（在验证方式不明显时包含）

说明如何验证变更有效；琐碎变更可跳过：

## Testing - Run `uv run pytest tests/test_feature.py` to verify the fix - Example usage: `uv run examples/new_feature.py`

Fixes（在提供了 Issue 或从 commit 中发现 Issue 时包含）

列出本 PR 修复的 Issue。GitHub 在 PR 合并时会依据这些引用自动关闭对应 Issue：

## Fixes - Fixes #123 - Fixes #456

技能对此有一条明确的措辞规范：统一使用 "Fixes #X" 格式，而不是 "Closes" 或 "Resolves"，并且每个 Issue 单独一行、前缀固定为 "Fixes"，以确保 GitHub 的自动关闭行为一致可预期。这与第三步中“从 commit message 匹配多种模式”形成对照——输入宽容、输出严格。

写作准则：30 秒可读、讲 why 不讲 what

技能在 Guidelines 部分给出了五条写作准则，直接决定最终描述的质量：

这些准则并非孤立要求，而是 Pipecat 仓库统一写作标准的延伸。技能的 Checklist 第一行写道：

Description documents the change for users, not the development process — the standard/prose-reviewapplies, inAGENTS.mdunder "Writing for Future Readers"

对应 AGENTS.md 的 “Writing for Future Readers” 章节，其核心原则是：为代码库的未来读者写作，而不是为当下参与协作的人写作——“留下当前时刻之外的东西”（剔除只在工作进行中才有意义的上下文），且每一句话都必须回答“代码现在做了什么”，而不是“我们当时经历了什么”。PR 描述作为面向用户和评审者的发布说明，正是这一标准的应用面；而具体执行层面，则交由 prose-review 技能做操作性检查。

完整示例：技能给出的输出样板

技能文档末尾附了一个完整的输出示例，展示了各章节如何协同：

## Summary - Added `/docstring` skill for documenting Python modules with Google-style docstrings - Skill finds classes by name and handles conflicts when multiple matches exist - Skips already-documented code to avoid unnecessary changes ## Testing /docstring ClassName ## Fixes - Fixes #123

这个示例同时体现了三条准则：Summary 三点分别讲能力、边界处理与防重复（why 与 impact）；Testing 章节只给了一条最短验证命令；描述中出现的是面向用户的行为，而不是开发过程叙事。

更新前的自检清单

技能要求在提交描述更新前逐项核对：

- [ ] Description documents the change for users, not the development process — the standard `/prose-review` applies, in `AGENTS.md` under "Writing for Future Readers" - [ ] Verified existing description needs updating (not already complete) - [ ] Summary accurately reflects the changes - [ ] Breaking changes are clearly documented (if any) - [ ] No unnecessary sections included - [ ] Description is concise and scannable

【免费下载链接】pipecatOpen Source framework for voice agents, multimodal apps, and realtime AI. Maintained by Daily and the community.项目地址: https://gitcode.com/GitHub_Trending/pi/pipecat