Figma
2 节点1 篇4 来源
【背景】随着AI编码工具的成熟，传统的设计到代码交接流程正面临重构。思科DevNet团队近期公开表示，在PubHub改版中，他们放弃了以Figma为唯一真相源的传统模式，转而采用“HTML原型+AI精化”的工作流，认为这能更有效地保留交互细节并加速迭代。这一实践与Figma在2026年Config大会上推出的Code Layers及AI Design Agent形成直接对话：后者试图通过双向GitHub同步和画布内AI代理，将Figma打造为连接设计与代码的无缝平台。
争议的核心在于“真相源”的定义。批评者指出，无论工具如何升级，若缺乏对令牌（Token）和组件命名的人工治理，AI生成的代码仍会导致设计与实现的静默漂移。目前，行业尚未就哪种工作流更具普适性达成定论，但趋势显示，静态截图式交接正在被可执行、可版本控制的代码化设计所取代。
事情怎么走到这一步
Figma在Config 2026大会上发布Code Layers（开放测试）、Design Agent及Figma Make的双向GitHub同步功能，旨在消除设计与代码间的单向导出壁垒。
figma.com ↗思科DevNet设计师Alejandro Marrufo和Casey Tong发文称，在PubHub改版实验中，发现将HTML转回Figma再改代码会导致交互细节丢失和更新缓慢，最终确立以HTML原型为单一真相源，由设计师直接使用AI编码工具进行精化的新工作流。
blogs.cisco.com ↗
还没定论的部分
- 在缺乏统一语义令牌标准的情况下，AI代理如何处理不同设计系统组件之间的命名冲突？
- 思科提出的“HTML原型即真相源”模式是否适用于需要高度品牌视觉一致性的消费级产品，还是仅适合内部工具？
- Figma的Code Layers能否真正解决“合并冲突日”时设计师推送与工程师提交同时修改同一组件的问题？