UI-TARS-desktop 如何按 RFC 流程提交跨平台架构变更提案【免费下载链接】UI-TARS-desktopThe Open-Source Multimodal AI Agent Stack: Connecting Cutting-Edge AI Models and Agent Infra项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS-desktopUI-TARS-desktop 的大多数改动包括 bug 修复和文档改进可以直接走标准 pull request 流程但涉及 Windows/macOS/Linux 三端考量的重大技术变更需要按 rfcs/README.md 描述的 RFC 流程提交让设计经过系统性评审。本文的目标是完成一个具体任务把一项影响跨平台行为的架构变更提案从前期讨论、撰写草稿、提交 PR一路推进到通过审批并建立实现跟踪。以下内容全部依据仓库自带的 RFC 流程文档与模板整理。先判断变更是否需要走 RFC在动手之前先确认你的变更是否落在 RFC 的适用范围。rfcs/README.md 列出了以下类别命中任意一项即应考虑发起 RFCArchitectural modifications架构修改Native API integrations原生 API 集成Cross-platform behavior changes跨平台行为变更Major performance optimizations重大性能优化Security-sensitive implementations安全敏感实现Breaking API changes破坏性 API 变更如果你的改动只是 bug 修复或文档改进无需走这套流程直接提 PR 即可。下文针对“架构变更且涉及跨平台行为”这一类提案展开。第一步前期讨论先验证想法提交草稿之前流程要求先完成 Pre-Discussion在项目中开一个 GitHub Discussion 帖子用于 initial concept validation初步概念验证明确核心维护者并 相关平台的 platform specialists平台专家。这一步的作用是让各平台的负责人在草稿成形前就看到变更方向后面技术评审时他们才会参与。第二步制作草稿并提交 [WIP] PRDraft Submission 阶段有三步操作都在你自己的 fork 中完成Fork UI-TARS-desktop 仓库把仓库中的 rfcs/template.md 复制为rfcs/drafts/000-feature-name.md——主仓库中不存在drafts/子目录该目录随提案 PR 在你的 fork 中创建000是编号前缀feature-name需要替换为你的提案名称以 [WIP] 为前缀提交草稿 PR。模板的 frontmatter模板文件开头带有一段 YAML frontmatter--- start_date: 2025-01-28 rfc_pr: issue: ---其中start_date在模板中给出的示例值是2025-01-28rfc_pr和issue两个字段在模板里留空。文档没有进一步定义后两个字段的填写规则草稿阶段可先保留原样后续按评审意见补齐。模板正文需要填写的章节模板正文按以下章节组织每个章节都给出了填写指引括号内为模板对内容的要求Summary对提案变更的简要说明Basic example如果提案涉及 API 变更或新组件交互给出简洁的代码/用法示例不适用时省略Motivation为什么这个变更是必要的、解决什么问题聚焦客观技术理由而非主观偏好Detailed design技术规格包括架构示意图如适用、新增/修改的 API、数据流变化、生命周期影响、错误处理策略、与现有 TARS 模式的兼容性、平台考量Windows/macOS/Linux。详细程度要足以让核心维护者评估实现可行性Drawbacks关键代价包括二进制体积/性能影响、维护复杂度、安全影响、跨平台一致性风险、开发者体验影响、既有集成的迁移成本Alternatives考虑过的其他方案包括第三方方案、部分实现、替代架构模式、维持现状的分析Adoption strategy落地方式包括分阶段实现计划、向后兼容措施、弃用时间线如有、文档更新、测试要求单元测试、E2E 场景How we teach this教学与文档策略包括 API 文档更新、示例项目更新、教程集成点、错误信息指引、新功能调试模式Unresolved questions未决问题如未验证的性能假设、未定实现细节、第三方依赖风险、平台特定边缘情况、长期维护归属。标准 PR 要求同样适用草稿 PR 也是普通 PRCONTRIBUTING.md 中的一般要求同样生效从 fork 的 feature 分支推送、在 PR 中接受 CLAcommit message 遵循 Conventional Commits每次 PR 都会触发 CI 运行单元测试pnpm run test和 E2E 测试pnpm run test:e2e。第三步技术评审阶段Platform leads平台负责人从三个维度评审提案Windows compatibilityWindows 兼容性macOS security implicationsmacOS 安全影响Linux packaging impactsLinux 打包影响同时必须完成以下 checklistrfcs/README.md 原文以勾选清单形式列出Performance analysis性能分析Cross-platform testing strategy跨平台测试策略Error handling documentation错误处理文档Binary size impact二进制体积影响这些条目与模板中的 Detailed design、Drawbacks 章节要求高度对应撰写提案时就按 checklist 逐项覆盖评审阶段才有据可查。第四步最终评论期与通过条件进入 Final Comment Period 后冻结功能范围Freeze feature scope处理最后的评审意见满足审批门槛需要 2/3 的 maintainer 批准且其中至少包含一名 platform specialist。这就是提案能否进入 Accepted 状态的判定条件checklist 全部完成 达到上述审批门槛。接受之后实现跟踪提案被接受后Upon acceptance按文档要求做三件事创建 tracking issue按平台拆分任务打上目标版本 milestone 的标签指定各平台的实现负责人。实现阶段还有一组强制规则Implementation RulesRFC 作者享有实现优先级implementation priority平台特定实现必须包含对应检查Windows 需要 MSI installer 兼容性测试macOS 需要 Notarization 验证Linux 需要 Snap/Flatpak 打包检查原生模块需要二进制体积监控。状态流转如何判断提案处于哪个阶段rfcs/README.md 用一个状态图描述了提案生命周期按这张图可以判断提案现状提交 PR 后从 Draft 进入 ReviewReview 阶段通过则进入 Accepted被拒则进入 ArchivedAccepted 后开始实现进入 Implemented。需要注意的是Accepted 之后如果 30 天没有活动状态会变为 Stalled——这不是否决恢复活动后可以重新回到 Accepted。相关文件rfcs/README.mdRFC 流程的完整说明包括适用范围、生命周期、评审 checklist、实现规则和状态图rfcs/template.md提案草稿模板含 frontmatter 字段与各章节填写指引CONTRIBUTING.md标准 PR 流程要求CLA、Conventional Commits、CI 测试[WIP] 草稿 PR 同样适用。【免费下载链接】UI-TARS-desktopThe Open-Source Multimodal AI Agent Stack: Connecting Cutting-Edge AI Models and Agent Infra项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS-desktop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考