过去一两年，设计师能用的 AI 工具越来越多。
Figma Make、Claude Design、v0、Lovable、Framer AI，往代码方向还有 Cursor、Claude Code、Codex，再加上 MCP、内部组件生成器，以及最近很受关注的 DeepSeek Harness。
这些工具各有擅长：生成页面、读取设计系统、修改代码、跑原型、做校验、接入开发流程。
但工具越多，一个问题反而越来越明显：
设计团队下一阶段缺的，可能不是另一个更强的 AI 工具，而是一套能把这些能力组织起来的生产系统。
因为真正进入产品生产后，问题已经不只是“AI 能不能做出页面”，而是：
它读了哪套设计系统，用了哪些真实组件？
哪些是业务规则，哪些是模型自己判断的？
哪些结果可以自动执行，哪些必须由人确认？
出错以后能不能恢复？修改后怎么验证没有破坏原有状态？
最后，怎么把结果交给设计和工程一起审查？
这些问题，本质上已经不是生成能力的问题，而是生产流程治理的问题。
这也是为什么，我开始关注 AI Design Harness。
02
Harness 到底是什么？
先把 Harness 这个词说简单一点。
在软件工程里，Harness 原本可以理解为一套“运行支架”：它自己不直接完成业务，而是负责把代码、工具、数据、配置和运行环境组织起来，让一个任务可以被稳定地执行、观察、检查和复现。
到了 Agent 时代，这个概念变得更重要了。
因为一个真正能工作的 Agent，并不只是“一个更聪明的模型”。
DeepSeek Harness 官方直接给出了一个很直观的公式：
Agent = Model + Harness
模型负责理解、推理和做决定；Harness 则负责给模型提供环境、工具和运行机制，让它不只是回答一次问题，而是能在真实任务里持续工作。DeepSeek 对 Harness 的定义也很直接：让 Agent 能理解环境、使用工具，并在真实场景中持续运行。
这也是 DeepSeek Harness 最值得关注的地方。
在它的架构里，Model、Tool、Skill、Session、Sandbox、Storage、Loop、Scheduling，甚至 UI，都可以作为插件被替换和组合。换句话说，Agent 不再被固定在某一种模型、某几个工具或者某一套工作流里，而更像运行在一个可以配置的“工作环境”中。
同时，它还强调另一件事：
Every run is traceable--每一次运行都有迹可循。
模型看到了什么、调用了什么工具、工具返回了什么、上下文什么时候被注入、子 Agent 如何被调度，都会进入 Session 日志。基于这套记录，一次任务可以继续执行、分叉尝试、搜索历史，甚至回放整个过程。
如果把这套思路放到设计场景里，可以得到这样一个启发。
今天很多 AI 设计工具的工作方式还是：
给一句 Prompt → 生成一个页面 → 人来判断好不好。
但真正进入产品生产以后，仅仅“能生成”远远不够。
一个 Agent 更理想的工作方式应该是：
它知道应该读哪套设计系统，能调用哪些真实组件，哪些业务规则不能违反；知道改完以后该怎么检查，失败以后怎么恢复，也知道哪些决定可以自己做，哪些必须交给设计师或工程师确认。
换句话说，我们真正需要的不只是一个会设计页面的 Agent，而是一套约束 Agent 如何工作的环境。
这套环境，可以暂且叫做：
AI Design Harness。
它不是另一个 Figma，也不是再造一个 AI 设计软件。
它更像是设计团队自己的 AI 设计生产运行环境：
把设计系统、业务规则、Agent、工具、沙箱、校验、过程记录和人工审批组织在一起，让 AI 不只是“生成结果”，而是在一条可控、可检查、可恢复的流程里完成设计工作。
03
有了 Harness，AI 做设计会有什么不同？
用一个具体例子，会更容易理解 Harness 到底解决什么问题。
假设今天的任务是：
“优化客户管理页，让它更好用。”
如果直接把这句话交给一个 AI UI 工具，几分钟后你大概率就能得到一个“看起来更好”的页面：
表格更整齐了，按钮更现代了，信息层级也更清楚了。
但真正进入产品开发时，问题才刚刚开始。
因为 AI 可能并不知道：
停用客户还能不能编辑？没有查看权限的人，是看到提示页，还是完全看不到数据？
删除客户失败以后，原来的数据要不要保留？哪些状态的客户可以批量操作？
“请求失败”和“暂无客户”是不是两种不同状态？危险操作应该使用哪一种确认弹窗？
按钮、表格、弹窗应该调用哪套现有组件？颜色、间距又该使用哪些 Token？
这些看起来不像“设计问题”，但恰恰决定了一个页面能不能真正上线。
AI 很容易把页面做得更像一个产品，却不一定知道这个产品到底是怎么运行的。
这时候，Harness 的作用就体现出来了。
有了 Harness，AI 不再是一上来就“自由发挥”，而是按照一套完整流程工作，如图所示。
这样一来，AI 做的事情就不再只是：
“我帮你重新设计了一个页面。”
而更像：
“我按照你们的设计系统和业务规则修改了页面，测试了关键状态，发现了哪些问题、修复了哪些问题，以及哪些地方还需要你来决定，都有记录。”
这才是 Harness 真正带来的变化。
它不是让 AI 生成得更快，而是让 AI 从“会做页面”，进入“能够参与真实产品生产”的状态。
04
为什么现在设计团队开始需要关注 Harness？
看到这里，可能会有一个问题：
为什么以前设计团队不太讨论 Harness，现在却开始值得关注？
因为过去的 AI 更像一个“生成工具”——你给它一句 Prompt，它给你一个结果。
但现在，AI 正在慢慢进入真实生产环境：它开始读取设计系统、调用组件、修改代码、写回设计文件、自动执行任务，甚至根据置信度决定“自己执行”还是“交给人确认”。
几个最近的行业变化，正在同时指向这个方向。
| ① Agent 从“单次回答”走向“可运行的工作环境” | ||
| ② 设计系统开始变成 Agent 的“工作上下文” | /design-sync 使用真实组件；团队项目还可以继承组织级 Design System。 |
|
| ③ 设计文件和代码之间的边界越来越薄 | ||
| ④ AI 自动化开始加入“理由、置信度和人工审批” |
把这四个变化放在一起看，会发现一条很清晰的趋势：
AI 正从“帮人生成一个结果”，走向“在真实生产环境中持续执行任务”。
一旦 Agent 开始真正进入生产，团队要解决的问题自然就会从：
“它能不能做出来？”
变成：
“它依据什么做？能做多少？怎么检查？做错了怎么办？什么时候必须交给人？”
这正是 Harness 开始变得重要的原因。
所以，AI Design Harness 并不是凭空创造出来的新概念。
它更像是把 Agent 基础设施领域已经发生的变化，翻译到设计生产里：
AI 工具负责提供能力，Harness 负责决定这些能力如何被安全、稳定地使用。
05
一套 AI Design Harness，需要哪些部分？
它不一定要从一个大平台开始，完全可以先用现有工具拼起来。
1. 上下文与规则
例如：Design.md、AGENTS.md、rules.json
告诉 Agent：用户是谁、业务规则是什么、有哪些权限、页面有哪些状态、什么情况下可以操作、最后按什么标准验收。
重点不是写“简洁、高级”这类原则，而是写成 Agent 真正能执行的规则。
2. 设计系统
例如：Figma Library、Figma MCP、Storybook、组件库、Design Token
让 AI 尽量调用团队已有的组件和 Token，而不是每次重新生成一套“差不多”的 UI。
3. 生成与修改工具
例如：Claude Design、Figma Make、v0、Cursor、Claude Code、Codex
这一层就是执行者：负责生成页面、修改设计或代码。
也是今天最不缺的一层。
4. 运行环境
例如：Vite、Next.js、Storybook、Playwright、Mock Service Worker
让 AI 不只是看静态页面，而是能真实运行产品，并测试 Loading、Error、无权限、超时等不同状态。
5. 校验与证据
例如：Playwright、axe-core、视觉回归测试、自定义规则脚本
不只是告诉你“页面没问题”，而是明确：
哪条规则通过了、哪里失败了、证据是什么、修改后有没有重新验证。
6. 编排与人工接管
这是 Harness 最关键的一层。
它决定整个流程怎么走：
什么时候读上下文、什么时候生成、失败后重试还是回滚；哪些问题可以自动修，哪些必须交给设计师或工程师确认；最后如何保存记录并进入工程审查。
所以，一套 AI Design Harness 并不是某一个软件。
从这个6层架构图来看，它更像是把：
上下文 + 设计系统 + Agent + 运行环境 + 校验 + 证据 + 人工确认
串成一条完整的 AI 设计生产链。
06
不用一步到位：从最小 Harness 开始
AI Design Harness 不需要一开始就做成一个复杂平台。
更现实的方式，是从一条最小可用链路开始，再逐步补齐能力。
| 最小版本 | ||
| 团队版本 | ||
| 更完整的版本 |
对个人设计师来说，最小版本其实就已经有价值：
让 AI 改完页面以后，不是直接交付，而是先按规则检查一遍，并留下证据。
团队成熟以后，再逐步接入设计系统、组件库、审批机制和多 Agent 协作。
所以真正值得思考的，并不是：
“我们什么时候要做一个 Harness 平台？”
而是：
“我们今天反复交给 AI 的工作里，哪些判断已经足够明确，可以沉淀成规则，让机器稳定执行？”
Harness 往往不是从“搭平台”开始的。
它是从把一次次重复的人工判断，变成可执行、可复用的生产规则开始的。
07
Harness 会改变设计团队沉淀什么，也会改变设计师负责什么
如果 AI Design Harness 真正进入团队，变化的不只是工具和流程，也会改变设计团队长期沉淀的资产。
过去，设计团队主要沉淀的是“给人使用”的资产；未来，还会逐渐增加一批“给 Agent 使用”的资产。
也就是说，设计团队的核心资产，会从：
可复用的界面资产
进一步扩展到：
可复用的生产能力。
但这并不意味着，设计团队以后都要自己开发 AI 平台，也不意味着设计师都要开始写代码。
Harness 的目标恰恰不是让 AI 更自由，而是让它在更明确的边界里工作。
真正重要的变化是：
过去很多存在于设计师经验里的判断，开始需要被表达成 Agent 能理解、能执行、也能被验证的规则。
而设计师依然要负责那些最关键、也最难自动化的判断：
什么体验才是正确的？
哪些规则可以交给 Agent 自动执行？
哪些风险不能让 Agent 自己判断？
哪些地方必须由人确认，并承担最终责任？
所以，Harness 并不会削弱设计师的角色。
相反，它会让设计师从“亲自完成每一次设计”，逐渐更多地参与到：
定义标准、制定规则、审查证据和管理 AI 的工作边界。
写在最后
未来，设计团队管理的可能不只是设计语言、组件库和规范，还要开始管理 Agent 的上下文、能力边界、自动化权限、验证方式，以及人什么时候重新介入。
今天大家讨论 AI 设计，仍然很关注“谁生成得更快、更漂亮、更接近生产代码”。但当生成能力逐渐成为基础设施，真正决定 AI 能不能进入团队生产的，可能是另一套能力：
可控、可验证、可恢复、可追踪、可审查。
所以，设计团队未来真正需要的，可能不是再多一个 AI 工具，而是一套属于自己的 AI Design Harness。
让 AI 能做事，也知道边界；能自动化，也始终保留人的判断。
AI 设计的下一阶段，不只是让模型设计得更快，而是让设计团队学会如何和 Agent 一起工作。
