Locofy: design-to-code agents

Hey PH 👋

我们真的非常感激 Locofy 从早期就获得的社区支持——我们能走到今天，很大程度上离不开这个社区。

这次我们带着一个焕然一新的 Locofy 回来了：更偏向开发者、更现代化，而且真正为现在人们实际交付前端的方式而打造。

以前，Locofy 非常以设计师为中心、面向企业。过去两年里，我们不断从初创开发者、自由职业者那里听到反馈说工作流不够灵活、门槛太高——所以我们有意识地做了转变。

现在 Locofy 支持：

* Figma → 利用专有的设计感知模型 + LLM 生成像素级精确的前端代码
* 专为开发者构建的智能体工作流（直接在 CLI、Cursor、Claude Code 或其他 Copilot 中使用 Locofy）
* 自服务套餐，对个人和小团队灵活且实惠

为什么 Locofy 要放在 Figma 和 Cursor/Claude 之间，而不是直接用它们配合 Figma？

因为 AI 编码智能体在逻辑和迭代上非常出色，但在 UI 精准度和理解 Figma 结构上仍然吃力。这会导致布局错乱、间距不一致，以及大量手动清理工作。

Locofy 的解决方案是：先将设计意图转化为结构化的、生产级的前端代码，作为 Figma 和 Cursor/Claude Code 等工具之间缺失的前端层——这样 Cursor 和 Claude 就可以专注于它们最擅长的事：在扎实的 UI 基础之上构建功能、逻辑和产品流程。

这次发布其实是我们在修正方向，真正按照现在前端开发的实际方式来做。

感谢一路陪伴的每一位 🙌

很自豪看到这个产品已经走了这么远。衷心祝贺团队发布，并祝愿你们在未来的旅程中一切顺利！🚀

恭喜发布。把“智能体在 UI 精度上挣扎”这个说法点得很准。有一个架构问题：这个方案需要以 Figma 源文件为基础吗？还是说你正在编辑一个已经在运行的应用、没有设计文件可读时，它也能帮上忙？很好奇边界在哪里，因为很多智能体处理 UI 的场景，面对的是从来没进过 Figma 的界面。

把 Figma 的 AST 转换为地道的 React 组件是个难题。大多数工具吐出来的是一堆嵌套的 div，维护起来很痛苦。我们在从设计稿构建 UI 时也遇到过这个麻烦。智能体能否理解共享状态和组件边界，还是生成后仍然需要手动清理？

恭喜发布！很期待看看设计感知模型在面对现实世界里乱七八糟的 Figma 文件时表现如何，而不仅仅是整洁的设计系统。

设计到代码的智能体方向很有道理，尤其是它能保持设计意图可见，而不仅仅是生成文件。我想了解，当 Figma 源文件不断变化时，团队如何审查生成的代码。