懂业务还能懂用户！大厂设计师教你打造落地级 AI Agent

一、全文速览图

25年我们业务出海后，大家遇到一个现实问题：写英文文案，不是简单地中翻英，而要考虑语境和文化。本土设计师很难跨越文化差异，一次就写出合适的英文文案。所以出海团队往往要配一个 copywriter（文案设计师）。

我们做语义助手的目标，就是把这种能力产品化、流程化——让 AI 成为、甚至部分替代 copywriter。

那我们是怎么做的？接下来我从三个方面跟大家唠唠：懂用户、懂业务、去AI味儿。

二、懂用户

刚开始，设计师们也尝试过用 GPT 这类通用 AI 写文案，但总会卡在两点。

第一点就是：文案看着不错，用着别扭。

语法没问题，表达也流畅，但一放进真实界面，就和产品气质“对不上”。

问题出在哪？——AI只知道要写页面中的一句话，却看不见“这个页面在干嘛”。

文案好不好，必须放在具体上下文里看，脱离背景的文案，往往只是“语言正确”，但“用法不对”。

但让设计师通过提示词把背景写清楚，既费劲又不稳定。

所以我们当时就在想：能不能不让设计师写提示词？能不能从别的地方拿到上下文？

能。答案就是：图片。

大家看下语义助手的样子：有一个很大的图片上传框。

用户可以直接扔图，一键生成。

重点是：支持一次扔多张图——玄机就在这里。

除了上传要改文案的界面图，还可以把前后相关界面一起扔进来。

这样AI拿到的就不是“一个页面”，而是一个流程的上下文。

拿到图之后，AI会先做分析。分析什么？

一句话：不只是识别文案，而是理解界面。

翻译成人话就是：它先搞清楚这个页面在干嘛，再决定怎么写。

除了提取UI文案，它还需要理解：

1. 文案在哪个位置、承担什么功能？
2. 这个页面属于什么结构/类型？
3. 页面整体在流程里做什么事？

那如果是多张图呢？就还要加一层：

1. 判断这些图是不是同一个流程？
2. 是什么流程？顺序是什么？
3. 上下文怎么衔接？

为了实现这套理解，我们引入了 schema，让大模型强制返回结构化 JSON。

说白了就是：强制AI先把页面“拆成固定的表格结构”，再去写文案。

这样就实现一个很直观的效果：

只要一传图，大模型就知道这是哪个业务、哪个流程、处在什么环节。

这比靠提示词描述可靠太多。

但支持多图，也意味着输入情况会非常复杂：用户可能不传图、传文字截图、传错图或者噪音图；传一张UI图、或者标记过的UI图、或者一部分截图；或者多张互不相关图、或者多张相关但乱序的图……各种排列组合都会出现。

那么我们要做一个合格的系统，就必须对各种情况都全部的去兼容。这块我们用MECE的方式去搭工作流：各分支互相独立、覆盖完全，保证每种输入都能走到正确路径，尽量不漏不翻车。

我们拿一个非常“刁钻的例子测试过：

要改的是 toast 弹窗里的文案。用户上传了：一张toast截图、一张文字截图（需求）、一张无关噪音图、一张相关表单页面。

神奇的是，AI准确识别出了哪张是噪音图、哪张是有效图，也读懂了文字截图里的要求。

更重要的是：它清楚地知道任务是只改 toast 文案——审题正确，没有乱改其他地方。

这件事在人类实习生身上都不一定稳定发生，但AI做到了。

我们用「用图提问」这个设计，不仅让用户更省事，也解决了上下文问题，并且支持批量提问走查，效率提升非常明显。

此外，如果用户要写提示词，我们也提供了提问模板，直接填就行，省掉大量通用废话。

回答，也不是只输出“文案正文”，而是一整套交付物：包括文案、写作要点、术语用法、注意事项、参考文献，方便快速核对、快速选用。

到这里，AI已经能“看懂页面”，但它还不一定“说对话”。

真正难的是第二件事：懂业务。

三、懂业务

通用AI的第二个卡点是：文案需要严格遵循语义规范、贴合业务场景。但使用通用AI，即使给了它资料和要求，也有可能不执行、瞎执行。

很自然地，我们想起来——加知识库。

但深入用下来会发现一个很现实的情况：很多问题就算不加知识库，大模型也能答得像模像样。

看起来效果很好，其实只是模型本来就会，知识库并没发挥作用。

更坑的是：如果只是简单把知识库“挂上去”，效果就会时灵时不灵；甚至有时候还不如直接用通用AI。

所以关键不是“有没有知识库”，而是：知识库能不能每次都强制生效，又能答得好？

要做到这一点，就得把知识库变成“硬规则”。

通过 RAG 机制，流程变成：先把需求转成规范关键词，再强制检索最相关规范，并强制说明“为什么选这些规范”。

说白了就是：AI写之前，必须先翻一遍“公司文案说明书”。

这样拿到的就是最相关、最精确的规范知识。

接下来，把规范片段和业务背景一起写成大模型必须执行的“硬规则”。

比如前面解析图片提取的类型和元素，本质上都来自我们根据业务背景推导出的一个字段池，提前写进系统提示词里。

也就是说它不是临时猜，而是按规则体系在跑。

到这里，它已经不仅“看懂页面”，还“知道该怎么说话”。

但还有最后一个问题——它听起来还是像AI。

四、去AI味儿

AI写作最大的问题，其实不是对错，而是“味道”。

太长、太客套、太模板化，一眼就是 AI。

我们做的事很简单：让它别像AI，像人。

我们对工作流里 7 类关键大模型节点做系统优化：提示词、参数、格式，前后调试30多次，形成 2w+ 字提示体系。

再通过 AB 测试，反复验证模型选型、知识片段数量、创造性参数的影响，逐步锁定关键因子。

此外，还做了双语识别、答案反馈闭环、权限保护知识资产等设计。

最后

通过“懂用户、懂业务、去AI味儿”三个维度的打磨，我们把语义助手做成了一个真正能落地的产品化 Agent。

它不只是翻译工具，而是理解上下文、遵循规范、输出专业结果的 AI copywriter。

最重要的是：它让设计师不再需要配专职文案，也能高效、准确完成出海业务的英文文案工作。

这就是我们想做的事——用AI产品化专业能力，让更多人能做原本做不了或做不好的事。

欢迎关注「58UXD」的微信公众号：