我们组的运营小姐姐，上个月自己搭了三个智能体：活动话术生成、用户问答、文案合规检查。全程没找开发。我作为前端，从一开始的「这能行？」到后来发现——我的活儿没少，但变了样。这篇讲讲非技术同学搭智能体时，前端该怎么搭手。
背景：她为啥能自己搭
她用的是个零代码搭智能体的平台，搭一个智能体就是填角色设定、传知识库文档、点几下配置。这些活儿恰恰是运营的强项——她比谁都懂用户怎么问、话术该什么调性。让她写prompt的体验，比她跟我描述一遍需求、我再翻译成prompt，准多了。
所以第一个认知转变：prompt和知识库这层，运营自己来比前端来更对。我别抢。
我接手的是「最后一公里」
她搭好的智能体，平台给个API。但API不等于产品。运营不会前端，落地页、嵌入站内、移动端适配、错误兜底，这些是我的活儿。我们的分工自然变成：
- 她：定义智能体干什么、说什么、用什么知识
- 我：把API变成用户真正用得上的界面
几个具体的配合点
一是约定好返回结构。 我请她在搭的时候，让智能体固定返回JSON——别返回大段自然语言让我去正则抠。她在平台的输出设置里加了结构约束，我前端拿到的就是干净字段，省了我一堆解析脏活。这个约定一立，配合顺畅一大半。
二是帮她想边界。 运营不太会想「网络断了怎么办」「用户输入空的怎么办」。我列了一张异常清单给她，哪些情况该让智能体回固定话术、哪些该我前端拦住。比如输入为空我直接前端挡掉，根本不发请求。
三是给她一个改了能立刻看效果的预览页。 我做了个内部小页面，她在平台改完智能体重新发布，刷新这个页面就能看真实前端里的效果，不用等我。她调话术的迭代速度一下子起来了。
一个真实的摩擦
有次她把智能体的回答改得很长，我的对话气泡布局直接被撑变形。我俩对了一下：不是谁的错，是我没跟她说清「回答最好控制在多长，超了我这边样式会崩」。后来我把这类前端约束提前告诉她，写进我们共用的一张约定文档里。
这事让我明白，运营和前端不是「她提需求我实现」，是两个人对着同一个产品的不同层，得有共同语言。
我的活儿其实更值钱了
以前大量时间花在「理解需求、拼prompt、调模型」这种来回拉扯上。现在这部分她自己消化了，我能专心打磨界面、性能、体验——前端真正该发力的地方。
如果你们团队也在让运营、产品这些非技术同学上手搭智能体，讯飞这类MaaS平台是个好的协作底座：他们管智能体的「脑子」，前端管「脸面」，各自发挥所长，比一个人从头扛到尾快得多。
