过去一年发生了一件奇怪的事。
AI 在构建软件方面变得异常出色。
然而，产品却开始感觉越来越同质化。
这听起来有些反常。
模型变得更智能了。Agent 变得更强大了。上下文窗口呈爆炸式增长。开发者变得前所未有的高效。
但如果你最近花时间浏览过 Product Hunt、独立开发者发布的产品或 AI 创业公司的演示，你很可能也注意到了同样的模式。
不同的创始人。
不同的产品。
不同的行业。
但界面却开始有种奇怪的相似感。
同样的卡片。
同样的仪表板。
同样的布局。
同样的视觉层级。
同样的“AI 生成的 SaaS”美学。
代码能跑通。
但前端却让人记不住。
我认为，这是因为大多数开发者都在关注一个已经不存在的问题——
生成代码。
如今，生成代码很容易。
但生成一个真正有设计感的前端要难得多。
大多数现代 AI 工作流已经类似这样：
Claude Code 负责规划。
Cursor 负责实现。
发布。
重复。
说实话，这已经足够强大，能以比以往更快的速度构建产品。
Claude Code 已成为我进行架构推理、拆解系统、思考该构建什么的首选工具。
Cursor 依然是将这些想法转化为可用软件的最佳环境之一。
这两个工具本身都不是问题。
事实上，正是它们让软件创建变得如此迅速。
问题出在代码生成之后。
那时，前端质量变成了一个完全不同的挑战。
我查看的产品越多，就越意识到一个工作产品与一个优秀产品之间的差距，很少再是功能上的差距了。
而是打磨。
是一致性。
是设计决策。
是上下文。
正是因为这个原因，我开始对前端原生工作流产生兴趣。
当我第一次看到这个工作流的可视化呈现时，它完美地捕捉了我对现代 AI 开发的新思考方式。
Claude 帮我思考。
Cursor 帮我构建。
但在“可用的软件”和“可上线的产品”之间，仍然缺少一层。
而这正是 Kombai 试图解决的问题。
不是要取代任何一个工具。
而是去填补它们都未曾设计去填补的空白。
解释这个问题最简单的方式，就是问一个简单的问题：
为什么 AI 生成的前端看起来还是 AI 生成的？
并非所有都是这样。
但足够多的情况下，你通常能在几秒钟内辨别出来。
很少是因为代码差。
问题通常要深得多。
大多数 AI 工具理解提示词。
前端工程师理解系统。
这个区别看似微小。
实则不然。
一个资深前端工程师看到一个按钮时，不会只想到：
“那是一个按钮。”
他们会想：
这是哪个组件？
它使用了哪个设计令牌？
这个组件其他地方是否已经存在？
它符合字体层级吗？
它属于设计系统吗？
这个模式可复用吗？
这些问题创造了一致性。
而一致性创造了质量。
优秀的前端不是组件的集合。
而是决策的集合。
而这些决策会随着时间的推移不断积累。
这就是我认为大多数 AI 工作流目前崩溃的地方。
生成的版本通常能运行。
可上线的版本则显得有设计感。
生成的版本完成了功能。
可上线的版本建立了信任。
而这两种结果之间的差距，通常不是更多的代码。
而是更多的上下文。
- 设计模式：从界面开始，而非实现
我用 AI 工具构建的每一个前端项目，开始的方式都一样：提示词 → 代码 → 刷新 → 重复。
Kombai 的设计模式彻底颠覆了这一点。
你不是从实现开始，而是从界面本身开始。你在一个无限画布上工作——勾勒布局、迭代组件、调整视觉决策——AI 内置了真正的创意品味。
输出看起来不像默认的 Tailwind 模板。不像 shadcn 模板。它像是被设计过的。
为什么这很重要：这些设计与你的代码库并非脱节。它们就在你的仓库里。
这引出了下一个真正让我惊讶的事情。
- 四向同步，改变一切
大多数 AI 工作流在设计和代码之间有一道硬墙。
你在某个地方设计（Figma、v0 等等）。你在另一个地方实现（Cursor、Claude Code）。然后你永远活在第二层里，通过编辑文件和刷新浏览器来做更改。
Kombai 打破了这堵墙——而且是四个方向。
你的设计、代码和渲染后的 UI 都一起存在于你的仓库和 IDE 中。你可以编辑其中任何一个。其余部分一键更新。
以下是它在实际中的具体含义：
画布上的设计 → 仓库中的代码
你的画布和设计以代码形式创建，并存在于你的仓库中。因此你可以直接在提示词中使用 @ 引用它们，将它们的上下文拉入任何任务，并直接从中生成生产级代码。想从设计中的一个元素创建新组件？让 Agent 指向它。想更新令牌以匹配新设计？一个提示词就行。
仓库中的代码 → 画布上的设计
Kombai 的设计模式时刻拥有你仓库的完整上下文。所以你也可以反过来——使用现有代码生成新设计。想创建产品轮播图的变体？让它将该组件复制到画布并生成创意版本。想设计代码库中已存在的 modal 的最大化状态？它已经知道 modal 长什么样。
浏览器中编辑渲染后的 UI → 仓库中的代码
在 Kombai 浏览器中打开你运行中应用的任何部分。可视化编辑文本、样式和布局——就像在设计工具中一样。然后一键将这些编辑发送给 Agent，它会将其实现到你的实际代码中。
不再需要在浏览器、检查器和代码编辑器之间切换上下文。你看到它，修复它，就完成了。
浏览器中渲染后的 UI → 画布上的设计
使用网页捕获功能，将你实时 UI 的任何部分直接发送到你的设计画布。适用于在 localhost 上运行的页面以及仓库外部的 URL。然后你可以对它们进行迭代、生成变体，或通过在提示词中引用来获取灵感。
这不是演示技巧。它是前端工作的一种根本不同的心智模型。
不再是“代码 → 刷新 → 检查 → 重复”，而是在同一真相的三种视图之间工作——你可以从其中任何一个进入和退出。
反馈循环大幅缩短。当你每天要做出几十个前端决策时，这种优势会迅速累积。
- 能真正复用你现有系统的生产级代码
Kombai 内部最有趣的想法之一听起来很简单，但内涵深刻。
它在生成任何东西之前先理解你的技术栈。
大多数 AI 生成的前端错在哪里？
它们会在已有组件时生成新组件。它们会在设计系统已有令牌时创建新令牌。它们会一点一点地、不知不觉地增加不一致性——直到代码库感觉像是五个不同团队做出来的。
Kombai 首先查看你现有的组件、钩子和令牌。然后复用已经存在的东西。
一个资深前端工程师不只是写新代码。他们会问：这个已经存在了吗？我应该复用某个东西吗？这符合我们已建立的模式吗？
这就是 Kombai 试图编码的思维方式。
这个视觉比任何营销页面都更能说明问题。
大多数 AI 工具看到的是指令。
Kombai 试图理解这些指令所处的环境。
随着项目规模变大，这种差异会越来越有价值。
因为现在没人再为生成一个组件而挣扎了。
挑战在于生成第一百个组件时，不破坏一致性。
挑战在于添加新功能时，不慢慢降低设计系统的质量。
挑战在于快速前进的同时，保持前端质量。
这就是上下文开始成为竞争优势的地方。
我现在运行的全栈
以下是这三个工具如何分工的：
Claude Code → 架构、规划、推理该构建什么以及为什么。
Cursor → 实现，将计划转化为可工作的软件。
Kombai → 设计、前端打磨，以及随着项目扩展保持界面一致。
每一层都有明确的职责。没有哪个试图取代其他。
过去一年我最大的领悟是，未来可能不属于单一的 AI 工具。
它属于 AI 工具栈。
专门化的工具解决专门化的问题。每一层做它真正被设计来做的事情。
Claude Code 不会试图成为 Figma。Cursor 不会试图成为一个设计系统。Kombai 也不会试图成为一个通用编码助手。
最强的工作流发生在每一层都有明确职责的时候。
一个工具帮你推理。
一个工具帮你实现。
一个工具帮你打磨。
而合在一起，输出会显著优于任何一个单独工作的工具。
这张图完美地抓住了这个区别。
构建和打磨是不同的技能。
构建让软件跑起来。
打磨让用户信任它。
构建创造功能。
打磨创造体验。
构建让用户尝试产品。
打磨让用户回来。
多年来，打磨成本高昂，因为它需要高度专业化的前端人才。
AI 正在开始改变这一点。
不是通过取代前端工程师。
而是通过让前端上下文更容易获取。
这正是 Kombai 吸引我的原因。
不是因为它生成代码。
现在每个 AI 工具都能生成代码。
不是因为它取代 Cursor。
它没有。
不是因为它取代 Claude Code。
它不应该。
有趣的是，它专注于软件开发中大多数 AI 工具很大程度上忽视的一层：
前端上下文。
而当 AI 生成的软件成为默认时，上下文可能成为整个工作流中最有价值的资产之一。
如果要用一句话总结我当前的工作流，那就是：
Claude Code 帮我思考。
Cursor 帮我构建。
Kombai 让前端感觉有设计感。
而目前软件领域最大的变化，不是 AI 越来越擅长写代码。
而是我们终于意识到，代码从来都不是全部工作。
产品是系统。
界面是系统。
设计是系统。
前端质量是系统。
而未来几年获胜的工具，可能不是那些生成最多代码的。
而是那些理解最多上下文的。
这就是我越来越关注前端原生工作流的原因。
不是因为它取代了栈中的其他部分。
而是因为它让整个栈更好地协同工作。
而在一个人人都会生成软件的世界里，这种差异可能比以往任何时候都重要。
现在尝试 Kombai：https://kombai.com/
