Puck AI:把“生成页面”改成“只组装你允许的组件”

Puck AI:把“生成页面”改成“只组装你允许的组件”

Puck AI 把页面生成约束为组件数据,再用业务上下文与服务端工具接入真实规则和数据,保留人工修改与发布边界。

Puck 是一款面向 React 应用的可嵌入视觉编辑器。开发者把自己的组件、字段和渲染方式交给 Puck,团队成员或终端用户便能在宿主产品里搭建页面;Puck AI 再根据品牌、业务规则和数据生成页面。生成结果以 JSON 保存,页面可以交回编辑器继续修改,也可以直接交给渲染器展示。12
很多 AI 页面工具把“生成”理解成写出一段界面代码。Puck 选了另一条路:让模型在宿主产品已经拥有的组件里做组合。这个决定把 AI 的创意范围收窄了,却把页面的可编辑性、品牌一致性和上线边界留在开发者手里。对做 AI 产品的人来说,Puck 值得看的地方,正是它如何把生成任务改写成一组可以检查的数据操作。

亮点一:模型交付组件数据,前端继续掌握页面骨架

Puck 的核心配置先回答三个问题:页面允许使用哪些组件,每个组件怎样渲染,用户选中组件后能填写哪些字段。开发者通过 components 定义组件,通过 render 描述呈现方式,再通过 fields 暴露可编辑输入。用户拖入一个标题组件后,编辑器生成的结果会落成一份包含 typeprops 的 JSON 数据。3
这个数据模型带来一个很具体的边界:模型可以决定页面里放哪个已注册组件、组件字段填什么值,模型的输出仍然要经过宿主产品认可的结构。渲染函数、字段类型和默认属性由开发者定义,页面数据再交给编辑器或渲染器处理。Puck AI 的官方说明把这种方式称为由预定义 React 组件构成页面,重点落在可控、可复用的产物上。4
真正有设计含量的地方,出现在组件配置里的几个小开关。
  • instructions 可以附着在组件或字段上。开发者可以告诉模型标题组件应当放在前面,也可以规定某个字段采用特定写法。规则跟着组件走,页面生成时便能复用同一套局部判断。5
  • schema 把自定义字段的内部数据形状写出来。模型遇到自定义字段、外部字段或用户字段时,仍然能按照 JSON Schema 生成可识别的数据。5
  • requiredexclude 分别控制哪些字段必须出现、哪些字段永远交给人工或其他流程处理。图片地址这类字段还可以关闭流式生成,减少预览阶段出现半截值的情况。5
普通的提示词只能告诉模型“请做一个价格页”。Puck 的配置则把这句话拆成了更接近产品实现的约束:价格页能用哪些区块,区块有哪些字段,哪些信息必须存在,哪些组件完全不参加生成。模型负责组合,组件库负责守住产品边界。
这套设计解决了 AI 页面生成里一个常见的错位:视觉稿看起来完成,开发团队却要重新拆结构、换组件、补数据。Puck 直接把生成结果放进宿主产品的数据模型,人工可以在编辑器里继续拖拽和修改,开发者也能沿用自己的渲染代码。2
代价同样清楚。组件库、字段名和 JSON Schema 设计得越含糊,模型能做的组合就越含糊;组件库没有覆盖的页面能力,也不会因为提示词写得更长就自动出现。Puck 把生成质量的一部分前移到了组件设计阶段。

亮点二:把“懂业务”拆成上下文和工具

Puck 把业务知识分成两种输入。第一种是 context,用来告诉模型品牌、受众、语气和业务规则;第二种是 tool,让模型通过宿主服务器查询真实系统。官方文档分别给出了 contextpuckHandler()generate()tool() 的接入方式。67
两者的分工很重要。context 负责解释“页面应该服务谁、遵循什么规则”;工具负责回答“这次页面生成需要从系统拿到什么”。例如,SaaS 产品可以把品牌颜色、目标客户和文案语气放进上下文,再提供一个查询价格数据的服务端工具。模型据此组合价格区块,价格本身仍然来自产品自己的系统。
Puck 的工具设计还有一处细节:工具函数在服务器上执行,agent 只能收到服务器返回的值。工具可以先运行,把结果作为整页生成的前置资料;工具也可以通过 bind 绑定到某个字段,让字段严格使用指定工具的返回值。7
这个分工把“模型知道什么”和“模型能做什么”分开了。业务上下文可以约束表达与结构,服务端工具可以约束数据来源和系统动作。产品团队因此能把权限检查、数据库查询和外部副作用留在自己的后端,而不是把一串系统访问能力藏进提示词里。

把这套方法落到一个价格页

下面的例子只展示接入顺序,页面里的组件名称和业务字段需要换成你自己的配置。Puck 官方文档支持从自然语言提示和 Puck config 生成页面,也支持把已有页面数据交回 generate() 更新。2
  1. 先定义页面骨架。HeroPricingGridFAQ 这类真实存在的 React 组件注册进 components,为每个组件写清 fieldsrenderdefaultProps。组件配置决定模型可以组合的页面语言。3
  2. 再把局部判断写进配置。PricingGrid 的字段补充 instructions,说明价格层级的顺序和展示条件;把内部结构复杂的字段补上 schema;把必须出现的字段标记为 required,把人工审核字段设为 exclude5
  3. 把稳定规则放进业务上下文。puckHandler() 或一次性的 generate() 请求里传入品牌、目标客户和文案语气。上下文描述业务规则,组件配置描述页面规则,两种规则各自放在最靠近它们的位置。6
  4. 让服务端工具提供价格数据。tool() 定义查询接口,写清工具用途与输入 schema;需要整页先拿到数据时使用 preload,需要某个字段严格接收工具结果时使用 bind。服务端先完成查询与权限处理,再把结果交给 agent。7
  5. 让人检查结构,再决定发布。 generate() 返回的页面数据可以交给 Puck 编辑器修改,也可以交给渲染器直接展示。先检查价格、区块顺序和文案,再把 JSON 存进自己的后端;这个检查点把生成和发布分开。2
这条路径的可复核结果很明确:组件类型来自自己的配置,必填字段有值,价格字段来自服务端工具,生成结果仍然能在编辑器里修改。读者可以逐项检查 JSON 数据,而不是只凭页面截图判断 AI 是否“做得像”。

结尾:先限制输出单位,再谈生成自由度

Puck AI 的关键选择,是把页面生成从“模型写一段任意界面代码”改成“模型提交一份由组件和字段组成的数据”。instructionsschemarequiredexclude 负责缩小局部自由度;context 与服务端 tool 负责把业务规则和真实数据接进生成链路;编辑器则给人工保留修改位置。
这个原则适合已经拥有 React 组件、业务数据和发布流程的团队。产品设计者可以先问三个问题:模型的输出是否落在自己的数据模型里,真实数据是否经过自己的服务端边界,用户是否能在发布前接管结果。Puck 给出的答案,是把这三个检查点直接做成配置、接口和编辑器流程。

This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.

Related content

More from this channel