智能体前端开发的陷阱：Demo版很快，系统却很脆弱

每次有新的AI模型发布，社交媒体上很快就会冒出一批one-shot前端 Demo，大家纷纷感叹效果有多惊艳。

它们确实惊艳。

但我更想聊聊Demo之后的事：当这套界面真正进入业务场景，交到真实用户手里，会发生什么？

我用智能体做前端时，反复遇到这样一种模式：第一版看起来很漂亮；第二轮prompt加入真正的业务逻辑；第三轮修一个bug；第四轮再补一个边缘情况。几轮下来，UI依然能跑，但底下的系统已经开始摇摇欲坠。

一个表单输入终于更新对了，另一个输入却无法重置。弹窗可以正常打开，上一次操作的状态却带进了下一次流程。下拉菜单在正常路径下没问题，用户来回改两次选择就坏了。一条校验规则修好了，提示信息却开始出现得太早、太晚，甚至消失。

智能体完成了我交代的任务，却没有真正理解我想要什么。

问题不在生成代码，而在验证代码

Qwen 团队最近的一篇论文 The Verification Horizon: No Silver Bullet for Coding Agent Rewards，给了我一个很有启发的视角。

论文指出，对今天的编码智能体来说，“验证比生成容易”这个老假设正在失效。模型越擅长生成复杂方案，我们就越难判断这些方案是否真的符合人的意图。无论是测试套件、评分标准、LLM评审，还是奖励模型，这些验证机制都只能近似衡量人的意图，无法等同于意图本身。（arXiv）

这也解释了我为什么经常对AI生成的前端代码感到挫败。

以前让智能体修bug时，我通常只会给它一个很窄的指令：选择X后禁用这个表单输入；审批通过后才显示这个区域；修正这条校验提示；让这张动态表单正确刷新。智能体就围绕这句话去优化，不断改代码，直到眼前的问题看起来被解决了。

但我真正想表达的，远比那一句话要多。

我说“禁用这个表单输入”，其实还意味着：不要破坏原有业务规则；让用户流程依然清楚；不要影响其他状态；保留已有行为；代码要容易维护；也别顺手埋下一个两周后才爆出来的边缘bug。

可这些完整的意图很难一次写清楚。有时候，直到错误真的出现，我自己才意识到原来还漏了这一层。

这正是前端开发对智能体格外困难的地方。前端不是一堆组件拼起来就结束了。它是用户意图、业务逻辑、视觉层级、状态流转、权限、校验、时序和异常恢复集中碰撞的地方。

代码只是产品的一部分。真正的产品，是整套交互系统。

前端代码可以完全通过测试，却栽在用户体验上

后端通常更容易验证：可以写单元测试、集成测试、API契约测试、Schema校验，也可以直接比对预期输出。前端却很难被压缩成一个简单的“通过”或“不通过”。

页面可以编译成功，表单可以提交，截图看起来也没问题，测试甚至全部是绿的，但用户体验依然通不过。

当UI承载复杂的业务逻辑时，这些问题会更明显。简单表单无非是填输入、点提交；真正的企业应用更像一棵决策树：某个区域只在特定产品类型下出现；某个输入要等另一个选项选中后才变成必填；同一个选项对一种角色可见，对另一种角色却必须隐藏；警告只在数值超过某个阈值后、提交之前出现。

每一条规则单独看都不难，真正的复杂度来自规则叠加。

AI智能体通常能处理一个条件，也常常能同时处理几个。但随着交互空间扩大，它会逐渐把UI当成一张“局部问题清单”，而不是一个由状态彼此连接起来的系统。

这时候，继续打补丁就危险了。

智能体循环很容易让人产生成就感，因为运行在继续：运行应用、发现问题、让智能体改代码、再运行一遍。对于简单场景，这套循环非常高效；但在复杂前端里，它也可能变成陷阱，因为每一次迭代都会把注意力拉向刚刚暴露出来的那个bug。

很多真正的前端bug并不会出现在首屏。它们往往要等用户走过好几个步骤、返回去修改之前的选择、提交不完整的数据，或者进入开发者没有明确测试过的状态后才会出现。API返回空数据、审批状态发生变化，或者两个业务条件同时成立时，问题也可能突然冒出来。

这些bug藏在状态与状态之间的转换里。只看静态代码，或者只截一张图，几乎什么也看不出来。

智能体还跨不过抽象这道坎

我反复看到的另一个问题是：智能体目前还不太会主动做抽象。

它能生成代码，能打补丁，也能在要求明确时重构代码。但它很少会自己停下来问一句：这段逻辑真的应该放在这里吗？

这正是经验丰富的开发者仍然不可替代的地方。

初级开发者，或者表现得像初级开发者的智能体，看到一个前端bug，可能会直接在模板里再加一个条件。问题确实解决了：输入隐藏了，按钮禁用了，错误提示也挪到了正确的位置。

但有经验的开发者看到的会更多：这个判断根本不该写在模板里；同一条业务规则已经复制了三遍；组件获得的信息得太多了；状态应该被明确建模；这套表单逻辑应该可以复用。现在这个Demo能跑，但这样的结构撑不到生产环境。

能预判代码将来会乱成什么样，并不只是个人的代码风格偏好，而是一种工程判断。

我把智能体生成的Demo改造成生产级前端时，对这一点感受尤其强烈。Demo很快就搭好了，可一旦真实用户、边缘情况和业务规则进场，继续修补就越来越不奏效。每个改动单独看都合理，整体结构却越来越难推理。

智能体可以一直帮我打补丁，但它不会主动保护架构。 它不会追问表单逻辑是否应该抽出来，状态是否应该集中管理，同一条规则是否应该可复用，工作流是否应该用状态机表达，也不会提醒我这个组件是不是已经塞了太多职责。

智能体看到的是下一条指令。

有经验的开发者看到的是整个系统将要进化成什么样。

开发者不再只是写代码的人

也正因为如此，我认为前端开发者的角色不是变轻了，反而更重要了。

我们很容易把与智能体协作理解成：告诉它要做什么，然后检查它交回来的结果。对于简单功能，这也许够用。但面对复杂的表单、仪表盘、工作流，以及由业务规则驱动的动态内容，开发者不能只做一个提需求的人。

开发者还得做架构师。这里的“架构”不是什么空泛的头衔，而是一连串非常具体的决定：修到第五个bug 时，这份代码是否还看得懂？

这段逻辑该放在哪里？哪些东西应该复用？哪些条件应该变成配置，而不是继续硬编码？哪些状态属于组件本地，哪些应该放进共享Store？哪些业务规则应该从模板里抽出来？哪些行为必须通过真实的用户操作来测试？哪些地方不该让智能体随便动？

这些决定，才真正决定了AI生成的前端代码能不能活过第一个Demo。

智能体可以飞快地产出实现。但没有结构的实现，只会以机器的速度变成技术债。

模板应该描述用户看见什么，业务层应该说明规则意味着什么，状态层应该定义什么可以变化，测试则应该守住那些绝不能被破坏的行为。

这不是过度设计，而是让复杂UI继续保持可理解的基本条件。

智能体可以简化UI，却不能取代控制

当然，也有人会提出一个合理的反问：未来需要的也许不是更好的前端架构，而是更少的前端页面。

如果智能体能理解用户目标、调用API、读取账户数据、归纳选项，还能跨系统执行操作，人为什么还要面对那些复杂表单？用户并不是真的想填一张长长的转账表、争议申诉表、贷款申请或受益人设置页面。他们只是想转一笔钱、举报一笔可疑交易、申请信贷、修改账户信息，或者弄清楚下一步该做什么。

这个观点确实有道理。

以银行业务为例，智能体界面可以大幅减少这些负担。系统不必一上来就丢给用户一张充满条件分支的长表单，而是先从意图开始。用户可以说：“我想把钱转到储蓄账户”，或者“我想申诉这笔扣款”。智能体读取已有的账户信息，只追问缺失的部分，解释相关规则，再准备一份待确认的申请。

在这种模式里，表单并没有真正消失。它只是退到交互背后，变成一份结构化的数据。用户的任务也从手动录入，变成了澄清、审核和确认。

这是一个重要的变化。但交互设计并没有因此消失，界面的职责只是变了。

在银行工作流里，尤其是不能出错的场景中，复杂并不一定意味着 UI 做坏了。有时候，复杂本身就是控制机制。必填输入、转账限额、身份认证、反欺诈检查、费用披露、风险提示、确认步骤和审计记录之所以存在，是因为业务必须保证准确、安全、合规、可追溯，也必须保护客户。

一次错误输入，可能把钱转进错误的账户，给交易争议分错类，触发错误的审核流程，违反合规要求，甚至给后续运营带来风险。在这些场景里，速度不是第一优先级，控制才是。

所以，合理的方向不是让智能体取代表单，而是让智能体帮助用户更清楚地完成表单。

智能体可以读取已验证的账户信息，解释一个输入为什么必填，指出还缺什么，并准备好待确认的操作。但它不应该偷偷猜测必填信息，也不应该让每个输入看起来都同样可靠。好的智能体表单需要明确标出：这个值是系统验证过的、用户确认的、由规则推导的、智能体建议的，还是仍然缺失的。在高准确度要求的流程里，“未知”必须是一种合法状态。宁可留空，也不要自信地填错。

工作流也必须区分草稿和提交：智能体起草，用户审核，系统验证，最后才提交。在资金真正转出、申诉正式提交或账户信息被修改之前，用户应该清楚地知道接下来会发生什么、信息来自哪里、系统应用了哪些规则，以及自己正在批准什么。

UI可以少一些手工操作，但不能少了问责和控制。

智能体也许能减少复杂的人机界面，却不会让背后的复杂逻辑消失。 在企业环境里，控制往往就藏在这些逻辑中。设计真正要做的，不是用一段友好的对话把复杂性遮住，而是把它讲清楚、做得可验证，同时尽量减轻用户的负担。

更合理的前端智能体工作流

智能体对前端开发当然很有用。但我不认为我们应该把用户体验或业务控制交给一轮轮prompt来决定。

我们的工作方式需要一些改变。

编码之前，先让智能体帮忙梳理交互模型：列出状态表、用户流程、边缘情况和验收标准。然后认真审查，因为这里最需要的是人的判断。

编码过程中，给智能体清楚的架构边界：业务规则放在哪里，状态由谁管理，哪些部分必须复用，哪些文件和既有行为不能随意改动。

处理业务规则时，不要把所有判断都塞进模板。把规则提取成有名字的函数、selector、service、配置对象或共享规则层。一条有名字的规则，更容易测试、复用、解释，也更容易治理。

处理状态时，不要让一个组件变成工作流状态、校验条件、权限规则和显示开关的垃圾场。复杂交互需要明确的状态模型，而不是越堆越多的布尔值。

面对高准确度输入，UI 应该围绕数据来源来设计：哪些信息来自源系统，哪些由用户填写，哪些由规则推导，哪些只是智能体的建议，还有哪些尚未补齐。

修bug时，要求智能体说明行为上的影响：改了什么？哪些行为保持不变？考虑了哪些边缘情况？新增或更新了哪些测试？

每次修复之后，重新跑一遍完整的交互检查清单，而不只是验证刚才失败的那个场景。不要只问“这个bug消失了吗？”，更要问“整个系统还自洽吗？”

这样做看起来比一路prompt下去慢，但一定比打了二十轮补丁后再收拾一套脆弱的UI快。更重要的是，在企业环境中，它也比让智能体把不确定性悄悄藏起来安全得多。

真正的生产力提升，不是十分钟做出第一个Demo。而是从Demo走到生产的过程中，始终没有丢掉用户意图、业务逻辑和控制。

真正的能力，是设计好这个循环

Qwen的论文认为，随着模型能力提升，没有任何固定的奖励函数可以永远有效。验证必须和生成一起演进。（arXiv）

对前端团队来说，我会把它翻译成一个更实际的结论：没有哪一条prompt能承载完整的产品意图，也没有哪一套智能体循环能取代架构判断。

前端开发者的角色没有消失，只是在改变。

我们不再需要亲手敲下每一行代码。我们要做的，是设计出让好代码得以产生的结构，把模糊的人类意图变成明确的状态、规则、契约、可复用模块、数据来源和可验证的交互。

智能体也许会减少一部分复杂的人机界面，但不会消除背后的复杂逻辑。在企业环境中，控制往往就存在于这些逻辑里。

真正的问题不是能不能把界面做得更简单，而是能不能让复杂性变得更清楚、更可验证，同时不再给用户增加不必要的负担。

好的智能体UI不应该把业务规则藏在友好的对话后面，而应该让规则更容易理解。它需要告诉用户：智能体知道什么、推断了什么、从可信系统中读取了什么，还有什么仍然需要人来确认。

速度当然有价值。但在真正的企业生产流程里，速度并不总是最重要的。有时，更重要的是确切知道系统为什么要问这个问题、输入来自哪里，以及最终是谁批准了它。

这就是为什么前端架构仍然重要。智能体可以协助工作流，但围绕它的控制结构，仍然必须由开发者来设计。

也许这才是今天智能体循环真正的局限：它会迭代，却不总知道什么必须保持稳定；它会打补丁，却不总知道什么时候应该推倒重来；它能完成最新的指令，却不总能守住背后更完整的意图。

守住这些，仍然是我们的工作。

我们不只是告诉智能体要构建什么，还要把系统设计好，让它能够帮上忙，却不会一点点破坏我们想要保护的体验、逻辑和控制。

参考资料

• The Verification Horizon: No Silver Bullet for Coding Agent Rewards