不知道大家有没有发现，如果用AI Agent做一款产品，不论是Web还是App也好，如果不做约束，它总是很容易做偏。

比如用户界面做得很不好看、交互不对、功能很差，又或者是做出来了，但是「AI味儿十足」，那应该怎样做才是正确的呢？目前成熟的做法是什么样的？

结论就是：不要让AI Agent“做一个产品”，而要让它在一个已经定义好的产品系统中执行任务。

目前成熟做法可以概括为：

Spec-driven development + Design system as code + Agent harness + Automated evaluation + Human gates

中文就是：

规格驱动、设计系统约束、任务分层、自动验收、关键节点人工决策。

问题通常不在模型不够聪明，而在你同时把产品经理、交互设计师、视觉设计师、前端工程师和测试工程师的决策权都交给了一个缺乏长期上下文的 Agent。

OpenAI 将这种模式概括为“人负责引导，Agent 负责执行”：人的工作从直接写代码，转向设计环境、明确意图和建立反馈循环。

一、为什么 AI Agent 很容易把产品做偏

Agent 的默认行为不是“理解你的产品”，而是：

根据当前上下文猜测你的意图；
从训练数据中寻找常见模式；
生成一个局部看起来合理的实现；
优先完成能够被代码验证的部分。

因此会出现：

功能能运行，但用户路径不合理；
页面看起来像通用 SaaS 模板；
每个页面局部成立，整体产品语言不一致；
只实现正常状态，遗漏空状态、错误状态、权限状态；
为了完成任务擅自增加功能；
看到截图后机械模仿像素，却不理解设计意图；
改一个页面时顺手重构整个系统。

代码只能告诉 Agent“以前做了什么”，不能自动告诉它“为什么这样做”。未被写进仓库的产品判断、设计评审和交互决策，对 Agent 来说实际上不存在。

所以，提示词写得更长不是根本解决方案。巨型说明文件会迅速过时、相互冲突，并挤占真正任务所需的上下文。成熟做法是让入口文件只负责导航，再按任务加载相关规范。

二、正确的角色划分

人必须负责：

产品解决什么问题；
谁是核心用户；
用户为什么使用；
信息架构；
核心用户路径；
交互模型；
视觉方向；
哪些权衡可以接受；
什么才算“做对”。

Agent 可以负责：

根据规格拆解任务；
生成备选方案；
实现已经确认的界面；
复用组件和设计令牌；
编写测试；
执行浏览器检查；
比对截图；
修复明确的违规项；
整理设计决策和文档。

Agent 不应自行决定：

改变产品定位；
重做核心导航；
发明新的交互范式；
替换视觉体系；
删除用户路径；
擅自扩大功能范围；
把“更容易实现”当成产品决策；
在没有验证真实页面时宣布 UI 已完成。

最有效的边界是：

人决定目标和不可逆的产品判断；Agent 在明确边界内寻找实现方法。 三、成熟的七阶段工作流

产品定义：先确定“做什么”

不要一开始就让 Agent 写代码。先形成一份简短但明确的产品规格：

重点不是写一份几十页 PRD，而是消除关键歧义。

GitHub 的 Spec-driven development 将规格定义为代码生成、测试和验证共同依赖的“行为契约”，而不是写完就丢弃的静态文档。

2. UX 规格：先设计行为，不要先设计页面

很多 AI 产品的错误，是把“页面列表”误认为“交互设计”。

正确做法是先定义用户流、状态矩阵、交互契约。

1. 用户流

→ 在入口用户做出什么选择 → 系统如何响应 → 用户下一步能做什么 → 成功、失败、放弃分别去哪里

状态矩阵

用户第一次看到什么？等待时显示什么，能否取消？没有数据时下一步是什么？成功后如何确认？发生错误后如何恢复？部分数据成功时怎么处理？无权限时说明什么？网络不可用时是否保留操作？删除或覆盖前如何确认？

交互契约

只有线框图，没有状态和行为说明，Agent 仍然会自行补全交互。

3. 设计系统：把“审美”转成可调用的约束

你跟AI说：“要简洁、高级、现代风、像某某产品”这不是有效规范。成熟设计系统至少包含四层。

Design tokens

颜色
字体
字号
字重
行高
间距
圆角
边框
阴影
层级
动效时长
断点
内容宽度

02. Component library

提前固定：

Button
Input
Select
Dialog
Drawer
Tooltip
Table
EmptyState
ErrorState
Toast
Navigation
PageHeader
FormField

原则是：Agent 优先组合已有组件，除非规格明确证明现有组件无法满足需求。

Interaction patterns

例如：

什么时候使用 Modal，什么时候使用独立页面
删除操作是否要求输入名称
保存是自动保存还是显式保存
表单错误显示在哪里
页面跳转后滚动位置如何处理
成功反馈使用 Toast 还是页面状态
移动端导航如何折叠

04. Exemplars

为 Agent 提供：

一个做得好的表单
一个做得好的设置页
一个做得好的空状态
一个错误示例
一个修改前后对比

Vercel 的实践不是只给 Agent 一套抽象风格，而是在仓库中维护产品判断、界面质量、交互模式、文案规则、优秀案例和反面案例。明确规则应写成可观察行为，例如“危险按钮使用动词＋对象”，而不是“按钮应当清晰”。

4. 原型门槛：先确认交互，再允许写生产代码

正确顺序，不是：

一句需求 → Agent 写完整产品 → 人开始找问题；

应该是：需求规格→ 用户流→ 低保真线框→ 可点击原型→ 视觉方向→ 设计确认→ 生产实现

UI 任务至少经过结构确认和视觉确认：

结构确认：

信息优先级；
页面关系；
主次操作；
用户是否知道下一步；
是否存在不必要页面；
是否遗漏关键状态。

视觉确认：

字体层级；
内容密度；
空间关系；
色彩使用；
组件一致性；
移动端和桌面端；
是否符合产品气质。

在没确认结构和视觉之前，不应让 Agent 大规模写生产代码。

5. 任务拆解：一次只交付一个可验证结果

不要给AI简单粗暴的指令：把整个后台管理系统做完。

更成熟的任务指令是很详细的：

Task: Implement member invitation dialog

Objective

允许管理员通过邮箱邀请成员。

In scope

打开邀请弹窗
输入多个邮箱
本地格式验证
提交邀请
成功和失败反馈

Out of scope

成员权限编辑
邀请历史
重新发送邀请

Sources of truth

docs/product/member-invitation.md
docs/design/forms.md
components/Dialog
components/FormField
components/Toast

Required states

Initial
Invalid email
Submitting
Partial failure
Success
Network failure

Acceptance criteria

禁止创建新的 Dialog 组件
所有颜色和间距使用 tokens
键盘可完整操作
Escape 可以关闭，但提交期间不可关闭
375px、768px、1440px 下布局正确
Playwright 测试通过
提交桌面端和移动端截图

Stop conditions

如果规格与现有组件冲突，停止实现并报告冲突，不得自行重构设计系统。

GitHub 的规格驱动流程也是先 Specify，再 Plan，然后拆成独立可测试的 Tasks，最后逐项 Implement；每个阶段都有明确检查点。

6. 验证闭环：不能只检查代码

AI 做 UI 最常见的荒谬行为是：看完 JSX 和 CSS，就宣布“视觉效果已经符合设计”。代码审查不能证明真实界面正确。成熟验证至少有五层。

静态约束

自动检查：

禁止硬编码颜色；
禁止任意字号；
禁止直接创建重复组件；
禁止不符合架构的依赖；
禁止使用未批准的图标；
禁止不符合文案规范的按钮文字。

适合机械判断的问题必须交给 linter，而不是靠提示词提醒。

组件测试

使用 Storybook 一类的组件环境，固定检查：

默认状态；
Hover；
Focus；
Disabled；
Loading；
Error；
长文本；
极端数据；
不同 viewport。

Storybook 可以把组件 Story 直接转化为视觉和可访问性测试，并在 CI 中将违规项设为失败。

端到端测试

不要只测试 API 成功，使用真实浏览器验证：用户点击什么→ 页面出现什么→ URL 是否改变→ 数据是否保存→ 错误能否恢复

视觉回归

为关键页面保存基准截图：

reference screenshot vs. current screenshot vs. pixel diff

Playwright 支持将稳定截图保存为基准文件，并在后续测试中自动进行视觉比较。

人工体验审查

自动测试无法可靠判断：

页面是否显得廉价；
信息是否太拥挤；
操作是否符合直觉；
文案是否让人困惑；
动效是否令人烦躁；
视觉层级是否正确；
产品是否具有整体性。

W3C 也明确指出，自动工具不能单独判断一个产品是否真正可访问，仍然需要有经验的人工评估。

7. 把每次纠偏变成系统资产

你是不是每次 Agent 做错，你就骂它一遍，Agent 改好下次还是会再犯；正确方法是：Agent 做错→ 判断错误类型→ 写入对应规则→ 添加好坏示例→ 能机械检查的加入 linter→ 能自动复现的加入 eval→ 后续任务自动继承

Vercel 目前采用的也是“规则、linter、eval、人工评审”组合：机械规则自动执行，需要产品判断的内容保留为指导和案例，新的标准必须经过证据和人工接受后才能进入系统。

四、推荐的仓库结构

不需要一开始做得非常复杂，但应形成明确的单一事实源：

repository/
├── AGENTS.md
├── ARCHITECTURE.md
│
├── docs/
│   ├── product/
│   │   ├── product-brief.md
│   │   ├── principles.md
│   │   ├── terminology.md
│   │   └── features/
│   │       └── feature-name.md
│   │
│   ├── ux/
│   │   ├── information-architecture.md
│   │   ├── user-flows/
│   │   ├── interaction-patterns.md
│   │   └── state-matrix.md
│   │
│   ├── design/
│   │   ├── foundations.md
│   │   ├── tokens.md
│   │   ├── components.md
│   │   ├── responsive.md
│   │   ├── accessibility.md
│   │   ├── copy.md
│   │   └── exemplars/
│   │
│   ├── decisions/
│   │   └── ADR-0001-*.md
│   │
│   └── plans/
│       ├── active/
│       └── completed/
│
├── src/
│   ├── design-system/
│   ├── components/
│   └── features/
│
├── tests/
│   ├── component/
│   ├── e2e/
│   ├── visual/
│   └── accessibility/
│
└── tooling/
    ├── lint-rules/
    └── evals/

AGENTS.md 不要塞入全部规则，它只负责：

Agent entry point

UI 相关任务：

阅读 docs/product 对应功能规格
阅读 docs/ux 对应流程和状态
阅读 docs/design 相关规范
优先复用 src/design-system
完成后执行指定测试
提交截图和验证报告

禁止：

未经要求调整全局设计系统
擅自扩大功能范围
只检查源代码而不打开真实页面
在规格冲突时自行决定

OpenAI 的实践也是让短 AGENTS.md 充当目录，将产品规格、设计文档、执行计划、质量标准和参考资料放在结构化目录中，并通过 CI 检查文档和结构是否发生漂移。

五、用单 Agent 还是多 Agent ？

先把单 Agent 的约束系统做对，再考虑多 Agent。

多 Agent 本身不会提高产品质量。没有共享规格时，它只会让错误更快扩散：

产品 Agent 发明需求；
设计 Agent 发明视觉；
前端 Agent再次解释设计；
测试 Agent只检查功能；
最终每个 Agent 都“完成了任务”，但产品是错的。

它们必须共享同一套：

产品规格；
设计系统；
任务定义；
验收标准；
决策记录；
测试结果。

六、真正成熟的核心是把“品味”部分编码化

视觉做不好，往往是你说的很抽象，例如：页面要高级、简洁、有呼吸感。别说AI理解不了，人都无法理解。应该这样说：

正文最大阅读宽度为 680px
页面一级操作不得超过一个
同一区域最多使用三个字号层级
默认页面不使用装饰性渐变
主色只用于可交互元素和当前状态
卡片不同时使用边框和阴影
表单标签始终位于输入框上方
移动端主要操作位于拇指可达区域
空状态必须解释原因并提供下一步
所有列表项在长文本下仍保持对齐

前者是审美愿望，后者才是 Agent 可以执行、测试和复查的产品标准。

七、最低可行版本

刚开始不必建设庞大体系。先建立以下八项：

一份 product-brief.md；
一份核心用户流；
一份状态矩阵；
一套设计 tokens；
10～20 个基础组件；
一份 UI 任务模板；
Playwright 关键路径与截图测试；
每次人工纠偏后更新规则或案例。

这套完成后，Agent 才从“随机生成代码的工具”变成“受治理的产品执行系统”。

最关键的判断是不要追求更聪明的 Agent，先追求一个让普通 Agent 也不容易做错的环境。

最后一句忠告：Vibe Coding 只是一种快速探索方式，不是一套完整的产品开发方法。所以，没有产品思维，还是不要入这个坑。

✳