一位前端工程师对 AI 时代产品-工程协作新模式的思考
一个看似不可能的数字
12 天。两个人：一名产品设计师和一名前端工程师。完整重建整个平台。
这不是原型，不是 MVP，而是对一个生产应用的全面替换——最终以一个删除了 26,000 行历史代码的 PR 画上句号。每一个页面、每一条路由、每一处交互，全部从零重建，并交付给真实用户。
在任何传统的产品开发流程中，这个时间线都是荒谬的。这种规模的项目通常需要数月时间：在 Figma 中进行数周的设计探索，多轮利益相关方评审，正式的设计交接，冲刺规划，然后是漫长而痛苦的像素级还原。而这次发生的事情，从根本上就不同。不是因为我们更努力，而是因为我们的协作方式变了。
这是我们如何交付 VM0 旗下 Zero 平台的故事，以及它让我对产品-工程协作未来的思考。
旧有的瓶颈
每位前端工程师都熟悉这套传统流程：
- 设计师在 Figma 中创建原型
- 设计评审、迭代、确认
- 附有间距、颜色、断点标注的设计规范
- 工程师将视觉规范转化为代码
- 反复拉锯："能把这个往左移 4px 吗？"
- 最后接入 API 层
- 集成测试，再次反复拉锯
瓶颈从来不在某个单一环节，而在于环节之间的间隙：等待、信息损耗、上下文切换。设计师对某个交互的心智模型，一旦被压平成静态的 Figma 画框并标上红线标注，到达工程师手中时已经失真。工程师重建的是设计师所想象的某个版本，但这不可避免地是一份有损的副本。
我们已经太习惯这种摩擦，以至于不再察觉它的存在。这就是"事情本来的运作方式"。
实验：如果设计师直接交付代码呢？
2026 年 3 月 5 日，我们的产品设计师 Ming 提交了 PR #3685：feat(platform): add zero app with shell, pages and polish。这个 PR 新增了 4,146 行可运行的 React 代码。
不是 Figma 文件，不是设计 token 导出，而是一个可以运行的应用。
这个 PR 包含一个完整的应用框架：侧边栏导航、路由结构、聊天、日程、动态、团队管理和设置等页面的骨架——全部使用我们的设计系统进行样式处理，全部可在浏览器中渲染。数据是模拟的，但 UI 是真实的。你可以执行 npm run dev，然后点击浏览每一个页面。
Ming 并非以传统意义上的方式从零手写这些代码。她使用 AI 编程工具（先是 Cursor，后来是 Claude Code）将自己的设计构想直接转化为 React 组件。AI 负责处理机械性的转译工作（JSX 结构、CSS 属性、组件组合），而 Ming 则主导那些 AI 无法做出的视觉与交互决策：布局的节奏感、信息的层级关系、过渡动画的质感。
接下来的四天里，又有三个 PR 相继合并：
| 日期 | PR | Ming 交付的内容 |
|---|---|---|
| 3月5日 | #3685 | 应用框架、侧边栏、所有页面骨架（+4,146 行） |
| 3月6日 | #3825 | 日程页面、UI 精细化（+2,650 行） |
| 3月9日 | #3993 | 引导流程、Slack 配置弹窗（+1,146 行） |
| 3月9日 | #4050 | 关于页面、浮动导航卡片 |
到 3 月 9 日，我们新平台的整个前端界面已经以可运行代码的形式存在。你最终会在生产环境中看到的每一个页面，在开发环境中都已经可以点击浏览。只是还没有真实的功能。
这时候，轮到我登场了。
我的新职责：注入灵魂
3 月 9 日，当我打开代码库时，我面对的不是将平面设计转化为代码这个老问题。代码已经在那里了。我的工作是用真实数据替换所有模拟数据，将每一个精心设计的界面连接到其背后活生生运转的后端。
这从根本上改变了我的工作方式。我不再思考像素，而是思考数据流。我不再问"这和原型图匹配吗？"，而是问"这个页面需要调用哪个 API，如果调用失败会怎样？"
以下是我第一周的工作情况：
第 1 天（3 月 9 日）： 认证与组织切换。我将 Ming 的应用框架接入 Clerk 认证系统，添加了跨域重定向，并让组织切换器真正能够切换组织。两个 PR，当天全部合并。
第 2 天（3 月 10 日）： 连接器与日程。我用真实 API 数据替换了模拟的连接器网格，将日程标签页接入实际的定时任务，并将指令编辑器连接到后端。四个 PR。
第 3 天（3 月 11 日）： 大规模接线日。团队页面接入了真实的子代理数据（+3,271 行），动态页面接入了真实日志。最重要的是：聊天页面连接到了真实的代理运行管道，用一个可工作的 AI 对话界面替换了约 1,200 行演示代码。同一天，我引入了 FeatureSwitchKey.Zero——一个功能开关，让我们能够同时运行新旧两个平台。
第 4-5 天（3 月 12-13 日）： 文件附件、会话管理、多代理聊天、设置持久化。Ming 构建的每一个页面现在都在处理真实的业务。
这种节奏几乎像音乐一样。每天早上，我从 Ming 的脚手架中选取一个页面，研究其组件结构，确定它所需的数据，构建 API 集成，处理错误状态，然后推送。到下午，又一个页面活了过来。
功能开关：平行世界
FeatureSwitchKey.Zero 功能开关值得单独说说，因为正是它让这次迁移变得安全而非鲁莽。
从 3 月 11 日起，我们的生产应用同时运行两套完整的 UI。使用旧系统的用户看到旧路由，使用新系统的内部测试人员看到 Zero。我接入的每一个页面都可以在生产环境中进行测试，而不会影响任何一个用户的工作流。
这并不是什么革命性的做法。功能开关是标准实践。但功能开关与设计即代码工作流的结合创造了一些特别的东西：我们可以验证新平台的完整用户体验（因为 Ming 构建了一个完整的、可浏览的 UI），同时逐步让每个页面具备真实功能（因为我在逐一接入它们）。在任何时候，如果出现问题，我们都可以把开关拨回去。
什么问题都没有出现。
第 12 天：完成切换
3 月 17 日，我提交了 PR #5095：refactor: remove all non-zero platform pages and feature flag。
差异统计：+456 行，-26,041 行。
切换前：旧版 VM0 平台。表格、运行 ID 和原始会话数据。
切换后：全新的 Zero。一个带有固定代理和用例卡片的对话式 AI 工作空间。
一次合并，所有历史路由全部删除。功能开关被移除。Zero 不再是一个选项，它成了唯一的模式。后续的 PR（#5155）彻底去掉了 /zero URL 前缀：原来的 /zero/chat 变成了简单的 /chat。
我为什么有信心做出这个决定？因为：
- 每个页面在功能开关下至少已运行 5 天
- 每个 API 集成都已针对生产数据进行过测试
- 新旧系统共享同一个后端，这是前端层面的替换，而非数据迁移
- 整个过程中都有真实用户在新系统上使用并提供反馈
删除这 26,000 行代码时，没有焦虑，只有如释重负。
模式的延续
最让我惊讶的不是这次迁移本身，而是我们发现的这套工作流成为了此后每个功能开发的默认模式。Ming 借助 AI 构建 UI 框架，我负责接入逻辑并扩展架构。同样的设计即代码模式，在功能层面持续复现：
权限系统（3 月 19 日 → 4 月 7 日）
Ming 提交了 PR #5467，一个使用 Sheet 组件和开关控件的权限抽屉 UI。三次提交，界面简洁。
我在同一个 PR 中添加了 13 次提交：firewall_access_requests 的数据库迁移、API 端点、集成测试、lint 修复。接下来的两周，又有 10 多个后续 PR 构建出完整的权限层：审批卡片重新设计、访问请求的 Slack 通知、用于诊断权限问题的 CLI doctor 命令，以及最终将整个概念从"防火墙"重命名为"权限"并贯穿整个代码库。
Ming 的抽屉是种子，权限系统是长成的大树。
日程系统（3 月 23 日 → 4 月 13 日）
Ming 设计了日程详情路由和日历 UX（#6155）。三次提交的干净 UI 工作。
我添加了 14 次提交：带自动生成功能的描述编辑、通知的 Slack 频道选择、未保存更改的确认弹窗、日历/列表视图统一，以及全面的测试。随后 15 个以上的后续 PR 将其扩展为一个完整的周期性任务系统，包含运行历史、时区处理和 cron 表达式支持。
Telegram 集成（4 月 27 日 → 4 月 28 日）
到这个时候，这套模式已经如此娴熟，我们在 48 小时内完成了一个完整的平台集成。Ming 构建了设置 UI（#11196）和引导流程（#11399）。我构建了多机器人 API、消息收发、文件上传/下载、富消息上下文、Ably 实时更新和端到端测试。第二天，它就向所有用户开放了。
AI 在其中扮演的角色
我想对 AI 的作用做出精确的描述，因为人们很容易对此过度夸大或过度低估。
AI 让设计师能够写代码。 Ming 是产品设计师，不是软件工程师。她的思维方式是布局、层级和交互，而不是 React hooks 和 TypeScript 泛型。AI 工具（Cursor，后来是 Claude Code）通过处理从设计意图到可运行代码的机械性转译，弥合了这一鸿沟。Ming 负责指挥，AI 负责打字。最终产出的代码由设计师主导，但工程师可以在此基础上继续构建。
AI 加速了评审循环。 在协作 PR 中，我的 AI 代理会审查 Ming 的代码，按优先级（P0/P1/P2）对问题进行分类，并直接推送修复提交。PR #5060 在 38 分钟内完成了五轮评审。PR #5467 在 20 分钟内完成了三轮。这不是"AI 取代代码评审"——我仍然会阅读每一处改动。但识别 lint 问题、缺失类型和测试缺口这类机械性工作已经被自动化了。
AI 没有做出设计决策。 每个页面的信息架构、交互模式、视觉层级——这些来自 Ming 的产品直觉，以用户研究和领域专业知识为基础。AI 可以生成一个设置页面，但它无法决定某个选项应该是开关还是下拉菜单，也无法判断何时需要确认弹窗、何时它只是多余的摩擦。
AI 没有做出架构决策。 使用功能开关进行并行部署的选择、API 层分离策略、逐页接入而非一次性全部接入的决定——这些都是工程判断。AI 帮助我更快地写代码，但排序和风险管理是人做的。
诚实的总结：AI 消除了设计与工程之间的转译层。它没有取代任何一个职能，而是移除了两者之间的间隙。
我的角色发生了什么变化
在这套工作流中生活了三个月之后，我对自己作为前端工程师的角色有了不同的认识。
我不再是视觉翻译者。 那些接收 Figma 文件、花数小时对齐间距值的日子已经过去。不是因为我在这方面更快了，而是因为这不再是我的工作。设计师的意图以代码的形式到达，而不是代码的图片。
我是架构扩展者。 我的核心价值在于接过一个可运行的 UI 界面，在其下方构建看不见的基础设施：API 集成、数据验证、错误处理、权限检查、实时更新、测试。大多数协作 PR 上的比例说明了一切：Ming 贡献 3 次 UI 提交，我贡献 13 次其他所有内容的提交。
我是质量把关者。 借助 AI 辅助的评审循环，我能够在比以前大得多的代码范围内维持代码质量。自动化评审捕捉机械性问题，我专注于架构关切、边界情况，以及确保功能真正端到端地正常工作。
我是交付策略师。 功能开关、增量接入、并行部署——功能从代码到生产的排序方式，现在是我工作的核心部分，而不是事后才考虑的事情。
数据
三个月。两个人。全程 AI 辅助。
- 914 个已合并 PR（我 679 个，Ming 235 个）
- 12 天从第一个脚手架到完整平台替换
- 48 小时完成一个完整的 Telegram 集成（我们最快的功能）
- 26,000 行在一次自信的合并中删除
- 88% 的我的 PR 和 66% 的 Ming 的 PR 带有 AI 共同作者标记
这些不是拼命工作的指标。我们两个人都没有在周末加班或通宵达旦。这种速度来自于消除了那些无效时间：交接会议、规范误解、"能把这个往左移 4px 吗"的反复拉锯。当设计意图直接流入代码，工程在原地扩展那份代码，浪费就自然减少了。
这对团队意味着什么
我并不是说每个团队都应该这样工作。这套工作流是在我们特定的背景下形成的：小团队、全新重建的机会，以及早期获得了能力强大的 AI 编程工具。你的情况可能会有所不同。
但我确实相信，其背后的转变是普遍性的：设计与工程之间的边界正在消融，而 AI 是那个溶剂。 随着 AI 工具在将意图转化为代码方面越来越强大，会有更多设计师直接交付代码。随之而来的是，工程师将花更少的时间在转译上，而将更多时间用于架构、质量和交付。
前端工程师的工作不会消失，它只是在改变形态。说实话？新的形态更有意思。
Yuma 是 VM0 的前端工程师，负责构建驱动 Zero 的平台——一个 AI 代理操作系统。他删除的历史代码之多，连他自己都不愿细数。
