7.1 KiB
GoodBuddy PR 宣传文章工作流
本文件用于 GoodBuddy 项目的产品宣传文章。这里的 PR 指产品传播，不指 GitHub Pull Request。 它是项目工作约定，不属于随应用分发的 Skill，不要求修改产品代码。
触发与范围
用户说“准备本轮 PR”“按上一个 tag 写发布文章”或要求重点功能宣传时，执行本流程。 默认交付文章和素材，不自动提交 Git、打版本 tag、发布版本或向外部平台发文。 版本发布操作遵循 发布手册。本流程是可选配套，不阻塞软件发布。
配套文档：
先读取仓库指引、Git 状态、桌面版本 tag 和提交历史。默认比较当前分支最近的正式桌面 tag 与当前 HEAD；明确记录基线 tag、目标提交和检查日期。Agent tag 单独核对，不混作桌面基线。 若 HEAD 已位于正式 tag，先根据用户所指的发布版本确定比较区间，不能默默换成另一轮发布。
未提交改动单列，不将设计文档、原型、计划或仅有接口的实现算作已交付能力。 保留用户工作区改动。全文不得把候选提交写成已经发布或可以下载的版本。
核查与选题
提交信息和 Release note: 是线索，实际 diff、最终代码和验证记录是事实依据。
每项候选内容记录：
- 目标用户和具体任务。
- 原有行为、本轮变化及使用入口。
- 前提、限制、持久化范围、数据流向、费用和升级兼容性中实际相关的内容。
- 对应提交、代码或文档位置，以及已有验证的范围。
将已知验证记录与本轮实际运行结果分开。定向测试通过不能写成全量通过，组件 fixture 不能写成完整应用端到端通过。发现失败如实记录，不为写文章擅自修复源码。
先选择重点 PR 或常规 PR，不按版本号大小、提交数量或凑足篇幅决定类型。 重点 PR 围绕一项能力或同一使用场景展开；常规 PR 按重要性介绍本轮变化，可以只有几段。 给出类型、推荐标题和推荐理由。维护修复可以只进入更新日志；变化不足以支撑文章时，明确建议暂不单独发文。 已有能力可以作为场景背景，但不能包装成本轮新增。
自动截图与演示
截图是工作流的实际执行步骤，不能默认把任务留给用户。 按截图步骤准备隔离环境，并遵循其中链接的项目自动化规范。 先检查现有应用启动、Electron 自动化和截图工具，复用已验证的机制。 根据选题编排一个短的真实操作过程，记录每张图片要证明的行为，再执行和截图。
优先使用对应版本的运行应用或已有构建，并使用独立演示配置与公开、虚构的测试资料。 记录应用版本或构建提交；已有构建落后于目标源码时，不能把截图标为目标版本。 不要为截图修改应用源码、产品默认配置、用户数据库或用户正在工作的会话。 确需临时自动化脚本时放在独立临时目录，不加入产品实现或分发目录。 构建与打包遵循仓库约定，不能为了截图绕过发布流程中的本地构建限制。
可用的浏览器工具可用于可访问的网页与 Web 演示；桌面应用截图使用已有 Electron 自动化能力或其他实际可用的桌面工具。不能假定网页浏览器工具能控制 Electron 应用。
截图要求：
- 使用真实界面和实际结果；不修改 DOM、伪造任务状态或拼接理想答案冒充实测。
- 产品主截图优先来自正常 UI 到真实实现的完整路径。组件 fixture 或原型只作明确标注的辅助图。
- 操作后等待页面加载、目标状态和布局稳定，再截图。逐张读取图片，检查可读性、裁切和状态。
- 避免真实客户信息、私人会话、凭据和内部地址。优先重新使用演示数据拍摄，必要脱敏须注明。
- 裁切、缩放和标注不能改变产品含义；保存原图，并区分原图与发布用图片。
- 使用统一窗口大小、主题和演示命名。图注说明操作与结果，避免只写“功能截图”。
- 调用收费模型、访问外部系统或执行写操作时，遵循当前会话已有授权及工具要求。
自动化不可用、版本不匹配或正常路径无法完成时，记录具体阻碍，继续完成独立的核查和写作。 缺少的图片写入内部待补清单，不能声称截图已完成，也不能用原型替代后隐去说明。
写作与审校
采用所选模板。重点 PR 尽早介绍能力和使用条件，围绕真实演示展开；常规 PR 直接说明变化， 有必要才解释原来的不便。没有具体背景材料时不虚设场景，不为小改动反复解释价值。
模板中的编辑提示不能变成固定话术。不要求每篇都出现“比如你正在……”“这意味着……”或 “如果你经常……可以试试”。不强行总结、升华或配平段落；常规 PR 可省略小标题。 篇幅按内容决定，图片用于说明具体变化，不为装饰而凑数。 升级风险集中放在体验入口附近，详细修复链接到完整更新日志。
不编造效率数字、用户评价、客户案例或测试结果。不使用“永不错过”“完全避免”等超出 机制范围的承诺。持久保存、当前运行期间保留、跨项目可见和跨设备同步必须准确区分。
可用时使用 deai-writing 技能审校正文；无该技能时人工检查空泛形容词、模板化转折、
机械排比和重复总结。审校不能删除必要的能力边界和升级提示。
交付与发布核对
用户指定位置时按指定位置交付，否则将本轮材料放在
docs/pr-articles/drafts/<日期>-<主题>/。目录只包含本轮文章与必要素材，不改产品代码。
最小交付：
article.md：文章标题、正文、相对路径配图和图注。assets/：实际取得的图片；如有处理，保留可区分的原图。review.md：比较区间、选题理由、事实来源、截图环境与步骤、验证范围和待补事项。
没有图片时不建空目录。文章草稿中的素材占位必须醒目标注；发布用正文不得留下占位文字。
内部验证细节和编辑备注放在 review.md，不混入面向用户的宣传正文。
交付前检查图片可读、相对路径存在、文章与图片一致、标题没有超出功能事实。 发布前再次确认对应版本可下载、下载链接有效、升级说明准确，且最终版本没有改变演示行为。 尚未发布时保持草稿状态，不编造版本号或上线时间。
最终回复提供文章和素材位置，概括推荐主题、实际截图情况及剩余阻碍。 只有得到明确发布指令后，才通过可用平台能力执行外部发布；准备文章不等于授权发布。