本文复盘一次内部低代码平台智能助手的阶段性验证。
目标很直接：用户在聊天入口里发送设计图、切图链接，或者一段文字描述，Agent 理解需求后调用低代码平台能力，生成页面或配置页链接。
早期简单场景可以跑通：
- 一张图的规则页可以生成页面结果；
- 单组件需求可以匹配组件并生成可编辑配置；
- 熟悉平台的人可以通过补充组件描述，让 Agent 生成页面骨架。
但真实需求一复杂，问题也很快暴露出来：
- 组件一多，生成结果开始不稳定；
- 对话轮次一多，Agent 可能丢掉前面已经修改过的组件；
- 遇到需要追问的场景时，系统可能把“追问内容”当成最终结果保存，反而丢掉前面已经生成出的有效结果；
- 每次改 Prompt、组件描述或工具调用逻辑之后，缺少稳定的回归验证方式。
这次实践给我们的结论是：
低代码页面生成不是一次性的文本生成任务，而是一个带状态、带工具调用、带平台约束的工程流程。
所以它真正难的不是“让模型生成一次页面”，而是让生成结果能被平台理解、能继续编辑、能多轮修改、能追问补齐信息，并且每次调整后都能验证是否真的变好了。
1. 生成链路：它不是让 AI 自由画页面
低代码平台的核心资产不是一张空白画布，而是一批已经沉淀好的组件、参数、规则和配置能力。
所以这个 Agent 的定位不是“让 AI 随便画一个看起来差不多的页面”，而是给低代码平台增加一个自然语言入口。
整体链路可以简化成这样：
这个定位决定了后面所有工程取舍。
如果只是做 Demo，生成一个视觉上接近的页面就够了。但进入低代码平台之后，生成结果必须满足几个条件：
- 只能使用平台真实存在的组件；
- 组件参数要符合平台约束；
- 生成出的页面配置要能被编辑器继续打开和修改；
- 复杂场景里缺少信息时，要能正确追问；
- 多轮修改时，不能把上一轮已经确认的组件改丢；
- 后续要有测试样例验证生成质量。
换句话说，AI 的价值不是绕过低代码平台，而是更低成本地调用平台已有能力。
2. 第一阶段能跑通什么，边界在哪里
第一阶段验证里，比较稳定的场景集中在三类。
2.1 一张图的规则页
用户给出图片和描述后，Agent 根据输入生成对应页面。
这类页面结构相对固定，组件数量少，平台侧可选组件也比较明确，所以更容易生成可预览结果。
2.2 单组件页面
比如只需要一个弹窗组件、头图组件或者某个业务组件时，Agent 根据用户补充的少量参数，可以匹配组件并生成初始配置。
这个场景的关键是：任务边界足够窄。
它不需要同时判断很多组件之间的顺序、参数依赖和页面结构，所以更适合作为早期验证场景。
2.3 熟悉平台的人辅助生成骨架
如果使用者本身熟悉低代码平台，能明确告诉 Agent 页面里有哪些组件、每个组件承担什么功能，它就更容易先生成页面骨架，再由人工继续核改。
这个场景很适合内部提效，但它也提醒我们：当前能力还不是“无门槛自动生成复杂页面”，而是“在边界清楚的前提下，帮助人更快生成初版”。
可以把当前适用边界先收敛成一张表：
| 场景 | 当前适配度 | 原因 |
|---|---|---|
| 单图规则页 | 较高 | 结构固定，组件少 |
| 单组件页面 | 较高 | 任务边界清晰，参数较少 |
| 熟悉平台的人生成骨架 | 中等偏高 | 人能补充组件和参数上下文 |
| 多组件复杂页面 | 不稳定 | 组件选择、顺序、参数约束同时变复杂 |
| 长对话持续修改 | 不稳定 | 容易丢失已确认组件或误判任务边界 |
这一步判断很重要。很多 AI 项目早期最容易犯的错误，就是把 Demo 场景里的顺畅，误判成真实场景里的稳定。
3. 复杂需求上来后，问题从“生成”变成“状态管理”
真正的问题出现在复杂页面里。
真实页面通常不是单组件。一个活动页可能同时包含头图、规则、按钮、跳转、状态展示、弹窗、列表、业务卡片和各种配置参数。
组件一多，Agent 需要处理的就不只是“选一个组件填几个参数”，而是：
- 哪些组件可以满足需求；
- 多个组件之间是什么顺序；
- 哪些参数必填，哪些可以默认；
- 缺少信息时应该追问什么；
- 用户补充信息后，应该更新哪个组件；
- 新一轮输入是在改当前页面，还是开始一个新页面。
这时问题就从“能不能生成”变成了“状态能不能管住”。
3.1 坑一：追问时丢掉了已有中间结果
一次复杂需求里，用户希望生成一个包含头图、轮播视频图，以及两行两个主播的页面。
Agent 能理解大致方向，但落到实际配置时，还需要继续追问视频链接、封面图、主播数据、跳转信息等内容。
追问本身是合理的。
真正的问题在于，早期追问流程没有处理好：系统会把追问内容直接保存，反而没有保留前面已经搜索或生成出的有效结果，导致页面里的组件不正确。
从聊天视角看，这只是“问用户补充一个信息”。但从工程视角看，追问背后对应的是一个未完成任务、一部分页面结构，以及已经拿到的中间结果。
如果系统没有把这些状态保存住，追问就会变成覆盖。
后续修复后，追问时可以继续保留上下文，至少不会因为一次补充信息就把前面的有效结果丢掉。
3.2 坑二：多轮修改时丢弃已确认组件
页面生成不是一次性对话。
用户很可能会连续说：
- 把头图换成另一张；
- 第二个组件参数调一下；
- 增加一个按钮；
- 按钮跳转到另一个页面；
- 再补一个弹窗。
如果前一轮刚确认的组件，下一轮因为一句新指令被覆盖掉，用户很快就会失去信任。
这个问题不能简单归因于“模型没理解”。更准确地说，是系统没有把当前页面结构、已确认组件、待补参数和本轮修改目标建模清楚。
3.3 坑三：任务结束判断不稳定
还有一个容易被低估的问题：一个页面需求什么时候算结束？
用户下一句话到底是在补充同一个页面，还是开始了一个新页面？
如果完全交给模型自动判断，实际效果会不稳定。当前更稳妥的方式，是通过手动结束会话来显式标记任务边界，避免系统误把不同页面认成同一个任务，或者把同一个任务拆成多个页面。
这类设计看起来不够“智能”，但在工程早期更可靠。
4. 四个必须收紧的工程边界
踩坑之后，我们发现问题不只是模型能力。
模型当然会影响理解和生成效果，但内部 Agent 要进入业务工具，必须先把工程边界收紧。
4.1 组件边界：不能让模型想象不存在的组件
低代码平台不是自由画布。
Agent 不能为了满足用户描述，想象一个平台里不存在的组件，也不能随意创造平台不支持的参数。
所以组件描述不能只写“这个组件是做什么的”，还需要补充：
- 适用场景；
- 不适用场景；
- 必填参数；
- 参数约束；
- 示例输入；
- 示例输出；
- 缺信息时的追问方式；
- 不支持时的返回策略。
组件说明对 Agent 来说不是普通文档，而是它选择工具、生成配置和处理异常时的重要依据。
4.2 上下文边界：页面生成需要任务状态
普通聊天可以模糊一点，但页面配置不行。
一个页面生成任务里，至少要记录：
- 当前页面包含哪些组件；
- 每个组件是否已确认；
- 哪些参数还缺失；
- 本轮用户输入作用于哪个组件；
- 当前任务是否已经结束；
- 下一轮是继续编辑还是新建页面。
如果没有任务状态，Agent 很容易在多轮对话里“看起来很努力”，但实际上把页面越改越乱。
4.3 工具调用边界：中间结果、追问和最终保存要分开
Agent 调用平台能力时，工具返回结果、用户追问、异常信息和最终保存结果应该有清晰流转。
尤其是追问场景，系统需要保留已经拿到的有效结果，而不是因为缺少某个参数，就把追问内容覆盖成最终结果。
一个更稳的流程应该接近这样：
识别需求
-> 匹配组件
-> 生成部分配置
-> 判断缺失参数
-> 保存中间状态
-> 向用户追问
-> 合并补充信息
-> 再次生成 / 更新配置
-> 最终保存
这里的关键不是流程图多漂亮，而是“中间状态”和“最终结果”不能混在一起。
4.4 验证边界：不能靠感觉判断这次变好了
页面生成不能只靠肉眼看一眼，也不能每次出问题都靠人工读日志、贴上下文、让代码 Agent 猜哪里错。
一旦日志变长、上下文变复杂，这种排查方式会非常低效。
更需要补上的是可回归验证机制。至少要覆盖几类样例：
- 简单单图生成；
- 单组件参数生成；
- 多组件页面骨架生成；
- 多轮修改不丢组件；
- 追问后继续保留原有效结果；
- 手动结束会话后不再误关联上一页；
- 不支持组件时能正确拒绝或继续追问。
这样每次调整组件描述、工具调用逻辑或模型策略时，团队才知道它到底变好了，还是只是这一次碰巧跑通。
5. 一套更适合落地的迭代路径
这次验证之后，我们没有继续盲目扩大需求范围，而是先把问题收窄。
5.1 先做高频组件，不追求全组件覆盖
低代码平台里的组件很多，但真实高频使用的往往只是其中一部分。
早期与其追求全量覆盖，不如先把高频组件的描述、参数、示例和限制条件写清楚。
这一步的目标不是“看起来支持很多”，而是让最常见的场景先稳定下来。
5.2 把组件经验翻译成 Agent 能执行的规则
很多平台经验原本存在于研发、运营或熟练使用者脑子里。
比如：
- 哪个组件适合规则页；
- 哪个组件适合活动入口；
- 哪些参数不能同时出现；
- 缺少跳转信息时应该先问什么；
- 哪些复杂需求只能先生成骨架，不能承诺全自动完成。
这些经验如果不显式写出来，Agent 只能靠模型推理去猜。
真正要做的是把这些经验翻译成结构化的组件能力说明和测试样例。
5.3 业务侧和平台侧分工要清楚
业务 Agent 接入平台时，业务侧和平台侧的边界要先分清。
低代码平台侧更应该关注：
- 高频组件；
- 组件能力说明；
- 页面生成样例；
- 失败样例；
- 人工核改边界。
通用 Agent 平台更适合承接：
- 会话状态；
- 工具注册；
- 日志分析；
- 执行环境；
- 权限审计；
- 失败恢复；
- 回归验证。
这样业务侧不用每次都从零搭一套 Agent 服务，而是把精力放回自己的业务能力描述、组件边界和验证样例上。
6. 可复用 Checklist
如果你也在做“Agent + 内部业务工具”或“AI + 低代码平台”，可以先用这份检查清单过一遍。
6.1 组件和能力描述
- 组件是否有明确适用场景？
- 是否写清了不适用场景？
- 必填参数和可选参数是否区分清楚？
- 参数之间是否有约束说明？
- 是否提供了标准示例和反例？
- 不支持的需求应该拒绝，还是继续追问？
6.2 多轮对话和状态管理
- 当前任务是否有唯一上下文？
- 页面里已确认的组件是否被保存？
- 本轮修改作用在哪个组件上？
- 缺失参数是否有单独状态？
- 用户什么时候结束当前页面任务？
- 新任务和旧任务如何隔离？
6.3 工具调用和结果保存
- 工具返回结果是否和用户追问分开？
- 中间结果是否会被追问内容覆盖？
- 异常信息是否可追踪？
- 最终保存前是否有必要校验？
- 失败后是否能恢复到上一个有效状态？
6.4 质量验证
- 是否有固定测试样例？
- 是否能对比生成配置差异？
- 是否记录失败原因分类？
- 是否能复现多轮修改问题？
- 是否能验证一次改动对多个场景的影响？
7. 总结：从能跑到可用，差的是工程闭环
如果只看第一次生成页面，AI 低代码页面生成很容易让人兴奋：图片丢进去，页面出来；一句话过去，配置页链接回来。
但工程团队真正要关心的是：
- 复杂一点还能不能生成；
- 多轮修改会不会破坏已有结果；
- 缺信息时能不能正确追问；
- 工具调用异常能不能恢复；
- 生成结果能不能回到平台继续编辑；
- 每次调整后有没有回归验证。
所以这次探索给我们的结论不是“AI 已经可以完全替代页面搭建”，而是更接近工程落地的一句话：
内部 Agent 想要真正可用，不能只追求模型更强，还要让业务规则、状态管理、工具调用和验证闭环一起成熟。
低代码平台里，组件和配置本身就是工程资产。AI 的价值不是绕开这些资产，而是更低成本地理解、调用，并把结果重新放回平台流程里。
先从高频组件开始，把简单页面做稳；再用测试和日志把问题收集回来，逐步扩大能力边界。这条路没有一次 Demo 那么漂亮，但它更接近真实工程落地。
花椒技术交流群
还在孤军研究 AI 工程化、AI 编程、Agent 落地，没人同行交流、没人拆解实战？
这里汇聚一线技术从业者，专注代码评审、企业内部 AI 助手真实实战落地。
想紧跟 AI 前沿动态、交流工程落地经验、少走踩坑弯路，欢迎直接加入「花椒技术交流群」。
群内专属福利拉满：每日精选研发向 AI 行业日报、文章独家延伸资料、文中未展开的技术细节，全部同步共享。
如果群过期关注公众号 花椒技术，私信回复「交流群」获取最新入群二维码。
