惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

G
Google Developers Blog
D
Docker
Stack Overflow Blog
Stack Overflow Blog
GbyAI
GbyAI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Google DeepMind News
Google DeepMind News
M
MIT News - Artificial intelligence
H
Help Net Security
T
Tailwind CSS Blog
Engineering at Meta
Engineering at Meta
L
LangChain Blog
MongoDB | Blog
MongoDB | Blog
腾讯CDC
H
Hackread – Cybersecurity News, Data Breaches, AI and More
S
SegmentFault 最新的问题
博客园 - 司徒正美
C
Check Point Blog
B
Blog
Y
Y Combinator Blog
Microsoft Azure Blog
Microsoft Azure Blog
P
Proofpoint News Feed
F
Fortinet All Blogs
美团技术团队
D
DataBreaches.Net

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
当设计师亲自下场训练AI:它开始先“看页面”,再写文案
58UXD · 2026-02-05 · via 人人都是产品经理

出海业务中,英文文案创作常因文化差异成为设计师的痛点。语义助手通过“先看页面再写文案”的创新设计,让AI真正理解界面上下文与业务规范。本文深度解析如何通过图片解析、RAG技术和提示词优化,打造一个能替代专业文案设计师的AI产品。

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

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

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

01 懂用户

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

第一点就是:文案看着不错,用着别扭

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

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

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

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

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

能。答案就是:图片。

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

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

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

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

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

拿到图之后,AI会先做分析。

分析什么?

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

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

除了提取UI文案,它还需要理解:

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

那如果是多张图呢?就还要加一层:

  • 判断这些图是不是同一个流程?
  • 是什么流程?顺序是什么?
  • 上下文怎么衔接?

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

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

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

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

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

但支持多图,也意味着输入情况会非常复杂:

  • 用户可能不传图、传文字截图、传错图或者噪音图;
  • 传一张UI图、或者标记过的UI图、或者一部分截图;
  • 或者多张互不相关图、或者多张相关但乱序的图……

各种排列组合都会出现。

那么我们要做一个合格的系统,就必须对各种情况都全部的去兼容。

这块我们用MECE的方式去搭工作流:各分支互相独立、覆盖完全,保证每种输入都能走到正确路径,尽量不漏不翻车。

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

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

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

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

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

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

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

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

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

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

02 懂业务

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

03 去AI味儿

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

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

我们做的事很简单:让它别像AI,像人。

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

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

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

04 写在最后

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

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

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

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

作者:韩筱婷 刘春明

本文由人人都是产品经理作者【58UXD】,微信公众号:【58UXD】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。