Figma 在 Schema 2025 讲清楚一件事：Agentic Coding 真正卡在“设计上下文”

很多人以为，Agentic Coding 的瓶颈在模型、在算力、在代码生成质量。但在 Schema 2025 的这场分享里，Figma 抛出了一个更刺耳的判断：真正限制 AI 写好代码的，是设计上下文是否被系统性地表达出来。这不是更快的问题，而是能不能走得更远。

一个反直觉的前提：AI 写不好代码，往往不是因为“不够聪明”

Jake 一开场就把听众的注意力从“AI 能干什么”拉回到一个更底层的问题：我们为什么要做这些工具？他的答案很不“效率至上”——“This isn’t just about moving faster. It’s about going further.”

这句话的潜台词是：如果你只是用 AI 把设计稿更快翻译成代码，那你永远只能得到“差不多正确”的结果。因为设计本身不是静态产物，而是一个持续探索“什么可能存在”的过程。AI 如果只看到最终稿，而没看到探索路径、取舍理由和系统约束，它生成的代码注定是浅的。

这也是为什么很多团队的 Agentic Coding 体验都很割裂：模型看起来很强，但一到真实项目就开始“胡写”。问题不在模型，而在你到底给了它什么上下文。

设计系统，正在从“规范文档”变成 AI 的核心语料

在分享中，一个被反复强调却容易被低估的角色是设计系统。Figma 的观点非常明确：设计系统不是为了“统一样式”，而是为了在设计到生产的整个链路中，持续承载上下文。

过去，设计系统更多服务的是人——帮助设计师和工程师对齐。但现在，它开始服务 AI。像演示中提到的高保真设计、检查设计（check designs），本质上是在把零散的设计思考，压缩成一个结构化、可被机器理解的表达。

更关键的是，这套系统并不止步于设计阶段。因为同一套系统也存在于生产环境中，它自然成为连接设计工具与代码工具的“公共语言”。当 AI 生成代码时，它不再是从零猜测，而是在一个被设计系统约束过的空间里工作。

真正的挑战：上下文一旦完整，就会“大到吓人”

当你真的试图把设计意图、系统约束、组件关系全部定义清楚，会立刻撞上一堵墙：上下文规模。

Jake 在演示中点出了这个现实问题——一旦上下文被认真对待，它会变得“massive”。而现在，这个问题被进一步放大，因为我们还希望用这些上下文去做代码生成。

这正是“上下文窗口”成为核心话题的原因。不是因为模型不支持，而是因为你需要非常清楚：哪些上下文是必须的？哪些可以被抽象？哪些应该由系统隐式提供？在 demo 中通过 MCP 估算所需上下文，其实是在提醒大家：Agentic Coding 不是一键生成，而是一场对信息密度和表达方式的精细工程。

从“不用 detach”开始，AI 正在改变实现 UI 的心智模型

一个很细节、但非常有象征意义的瞬间，是 Jake 提到“以前你得先 detach”。这句话戳中了很多设计工程混合角色的痛点。

现在的工具链，正在让人可以停留在更高层次思考 UI，而不是不断在‘设计对象’和‘实现对象’之间切换。当设计系统、设计上下文和代码生成工具连在一起时，AI 扮演的角色不再是‘抄稿员’，而是一个能理解结构的执行者。

这也是 Agentic Coding 真正让人兴奋的地方：不是少写几行代码，而是让实现过程重新围绕“意图”展开。

总结

这场分享最重要的启发在于：如果你现在就急着把 Agentic Coding 引入团队，却还没有认真对待设计系统和上下文表达，那大概率会失望。真正可持续的 AI 编码能力，来自对设计意图的系统化整理，而不是更大的模型。

对 AI 从业者和工具构建者来说，一个值得立刻行动的问题是：在你的工作流里，哪些设计决策是“只存在于人脑中”的？如果这些信息不能被结构化表达，AI 永远只能当一个聪明但盲目的执行者。下一波真正拉开差距的，不是谁的模型更新得快，而是谁先把上下文这件事做对了。

关键词： Agentic Coding， 设计上下文， 设计系统， 代码生成， 上下文窗口

事实核查备注： 需要核查：1）演讲者 Jake 的全名与职务是否为 Figma Developer Advocate；2）Schema by Figma 2025 的具体会议时间与场次；3）MCP 在演示中的完整含义与官方定义；4）视频中提到的工具名称是否为 check designs。