UI-TARS-desktop 如何按 RFC 流程提交跨平台架构变更提案-酒店常州论坛

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-desktop

UI-TARS-desktop 的大多数改动（包括 bug 修复和文档改进）可以直接走标准 pull request 流程，但涉及 Windows/macOS/Linux 三端考量的重大技术变更，需要按 rfcs/README.md 描述的 RFC 流程提交，让设计经过系统性评审。本文的目标是完成一个具体任务：把一项影响跨平台行为的架构变更提案，从前期讨论、撰写草稿、提交 PR，一路推进到通过审批并建立实现跟踪。以下内容全部依据仓库自带的 RFC 流程文档与模板整理。

先判断变更是否需要走 RFC

在动手之前，先确认你的变更是否落在 RFC 的适用范围。rfcs/README.md 列出了以下类别，命中任意一项即应考虑发起 RFC：

Architectural 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] PR

Draft 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-28，rfc_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 也是普通 PR，CONTRIBUTING.md 中的一般要求同样生效：从 fork 的 feature 分支推送、在 PR 中接受 CLA；commit message 遵循 Conventional Commits；每次 PR 都会触发 CI 运行单元测试（pnpm run test）和 E2E 测试（pnpm run test:e2e）。

第三步：技术评审阶段

Platform leads（平台负责人）从三个维度评审提案：

Windows compatibility（Windows 兼容性）
macOS security implications（macOS 安全影响）
Linux packaging impacts（Linux 打包影响）

同时必须完成以下 checklist（rfcs/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 Rules）：

RFC 作者享有实现优先级（implementation priority）；
平台特定实现必须包含对应检查：Windows 需要 MSI installer 兼容性测试，macOS 需要 Notarization 验证，Linux 需要 Snap/Flatpak 打包检查；
原生模块需要二进制体积监控。

状态流转：如何判断提案处于哪个阶段

rfcs/README.md 用一个状态图描述了提案生命周期：

按这张图可以判断提案现状：提交 PR 后从 Draft 进入 Review；Review 阶段通过则进入 Accepted，被拒则进入 Archived；Accepted 后开始实现进入 Implemented。需要注意的是，Accepted 之后如果 30 天没有活动，状态会变为 Stalled——这不是否决，恢复活动后可以重新回到 Accepted。

企业官网建设流程全解析