把产品文案当 design system 治理，一套系统贯穿 Figma、代码与 PR
How to build content systems for AI product workflows with Ditto | Config 2026 · Jessica
全片 20 分钟·真正值得盯屏约 11 分钟·3 个必看点
- 0:12 – 5:22听
问题定义：AI 让文案失控在哪
从流程变化讲起：过去 spec→设计→交付是线性的，现在文案在每个 PR 里由更多人和 agent 在几秒内产出。功能越来越容易做，产品的差异转而落在「它怎么说话」上。
难题从来不是 AI 能不能写文案，而是在这种生成速度和体量下，如何让全部文案仍然正确、一致、符合品牌。
这一段基本是讲者站着讲观点，画面只是配合的标题页，通勤或做别的事时听完不损失信息▶ 跳到 0:12讲者 · Jessica - 5:25 – 7:56看
原材料就在你的生产代码库里
切到现场操作：拿一个示例金融应用的代码库做扫描，抽出全部界面字符串，补一点业务上下文后自动打标、分组、抽取彼此关系，生成一套文本组件库。
产品的全部语言其实已经散落在线上代码里，内容系统应该从这些真实上线内容长出来，而不是另起一份理想稿。
屏幕上能看到条数统计、自动分组结果和从代码里带出来的西班牙语翻译一项项出现，光听讲不到这些细节▶ 跳到 5:25讲者 · Jo - 7:56 – 12:26略
自动推出的写作规范，可被反馈塑造
在库的基础上，系统根据代码里的实际用语反推出一份完整写作规范，讲者演示如何按界面元素类型重新打标、用反馈一点点把规范改成团队自己的样子。
规范不是一次性写死的文档，而是从真实用语推断出的初稿，再靠团队反馈持续修正。
主要在翻看一页页生成好的规范条目和标签，内容偏静态文本，快速拖动看看结构和几个条目的写法就够▶ 跳到 7:56讲者 · Jo - 12:26 – 13:16看
场景一：Figma 里设计时就纠偏
插件同时连着内容系统和当前设计稿，设计师改 onboarding 流程时，它把稿子里的文案与系统逐条比对，当场标出术语不一致并给出可一键接受的替换。
治理要发生在工作真正进行的地方，而不是事后审查；改动直接落回设计稿才算闭环。
整段的说服力全在那次比对提示和一键替换后设计稿的变化上，只听描述会以为它只是个检查清单▶ 跳到 12:26讲者 · Jo - 13:16 – 15:08看
场景二：把规则嵌进代码给 agent 用
用一条 pull 命令把内容系统装进代码库，每个设计系统组件的视觉定义文件旁边多出一个文件，专门写这个组件里的文案该怎么写。随后让 Claude Code 加一个国际转账功能。
对 agent 来说上下文多不等于好——把规则切开、放在对应组件旁边，它才能只取当下这个任务需要的那几条。
需要看文件树里规则文件和组件文件并排的位置关系，以及生成结果中货币格式和复用组件的具体样子，这些都在屏幕上▶ 跳到 13:16讲者 · Jo - 15:08 – 16:03看
场景三：合并前的最后一道关
PR 一打开，机器人自动把改动里出现的所有文案与内容系统比对，在 GitHub 评审区留下评论和建议，例如换用库里已有的那句支付成功提示。
在代码合并上线之前拦下措辞偏差，让审查文案变成日常代码评审的一部分。
重点是 GitHub 评论的形式和建议的具体措辞，这决定了它在真实评审流程里是否好用，值得看清截图▶ 跳到 15:08讲者 · Jo - 16:03 – 18:08看
反馈闭环：拒绝也是养料
在 Figma 里驳回一条「使用缩写」的建议，并写明理由——涉及授权同意的语言更严肃、不该用缩写。这条拒绝被系统吸收，全团队的这类反馈会持续累积。
拒绝建议时留下的理由，比接受建议更能让系统贴近团队真实判断。
能看到拒绝时填写理由的那个输入环节，正是这套系统与普通静态规范的分界，值得看一眼交互长什么样▶ 跳到 16:03讲者 · Jo - 18:08 – 20:12看
效果可见，改一处全域生效
规范页面按条目展示每条规则被引用、采用和被拒绝的频率，可以据此直接改规则；把偏好术语从 live 改成 active 后，Figma、Claude Code、PR 三处立刻一起改口。收尾抛出全场论点。
做得好的团队不会是生成文案最多的那些，而是底层有一套系统保证所有内容都对的那些。
改一个词然后三个工具同时跟着变，这个连续画面是全场结论的证据，看比听有效得多▶ 跳到 18:08讲者 · Jo