Snapshot

TL;DR

Scanat 的中、日、英三语文案原本分散在设计稿、代码和多个翻译版本中，1000+ 条历史文案缺少统一标准，设计、翻译和开发也长期采用串行协作。

2024 年 7 月，在三语版本两个月后上线的时间约束下，我重新整理文案数据，明确 key 的定义与维护规则，并把设计、翻译、开发改成并行协作流程。新流程随后从 iOS 扩展到 Web，支持三语版本按计划上线，并持续使用一年多。公司后续接入 AI 后，我们又把已经稳定的 key 命名规则和日语翻译习惯沉淀为 Skill，让 Claude 可以直接从设计稿提取文案、与历史文案表比对并生成复用建议，再由产品和翻译完成最终确认。

1. Problem

主要问题

• 流程繁琐容易出错：开发做完后直接把代码里的文本发给翻译，翻译在代码里改，中间没有留痕；
• 设计图与线上不同步：设计图始终是中文版本，改一处文案要跨设计稿、代码、线上多个地方核对；
• 翻译风格不统一：早期由多个日本同事轮流翻译，谁有空谁翻，导致同一批文案风格不一致；
• 文案全部硬编码：多语言几乎无法维护，且已经积压1000多条前后不一致的文案（iOS端此前和开发做过一轮初步优化，把文案加了key，但Web端完全没有）。

约束

• 时间紧：从7月接手到8月底正式上线中英日三语版本，只有约两个月；
• 双端进度不一致：iOS已有初步的文案key改造基础，Web端要从零开始，两边需要统一到同一套标准；
• 带新人执行：流程设计的同时，需要带一位刚入职的同事一起完成落地，而不是自己单独执行。

2. Approach

这次工作的重点主要是重新明确三方的责任边界和工作依赖，让设计、翻译、开发可以围绕同一套标准并行推进。

第一步：统一数据源，并明确 key 的责任归属

我先让 iOS 导出最新文案，与已有表格逐项比对，删除废弃内容，把分散的历史版本重新整理成一份脚本文案表，并与开发约定它作为后续维护的唯一标准。

同时明确 文案 key 由设计定义。设计稿是文案第一次进入具体界面和使用场景的位置，由设计确定 key，可以让 key 与实际用途直接绑定，翻译和开发不需要再分别猜测文案的上下文。

第二步：把串行流程改成三方并行

旧流程中，开发完成后翻译才开始，翻译结束后开发再接回代码，几个环节首尾相接。我重新把流程拆开：设计先在设计稿中定义 key 和中文上下文；翻译根据设计稿把 key 与中文录入文案表，并补充日英翻译；与此同时，开发已经可以按 key 接入，不需要等待翻译全部结束。

翻译完成后，设计更新设计稿中的正式文案，开发同步最新文案表。这样三方围绕同一组 key 工作，翻译与开发的时间可以重叠。

面对 1000+ 条历史文案，我也给翻译工作排了优先级：先统一日语，再补齐英语，最后校对中文。日语是核心用户语言，也是此前多人轮流翻译后风格差异最大的一部分。

在两个月上线窗口下，我没有平均分配整理成本，优先处理对核心用户影响最大、历史差异也最严重的日语文案。

第三步：先在 iOS 跑通，再扩展到 Web

iOS 此前已经做过一轮 key 改造，而 Web 端几乎没有基础。为了避免两端同时重构带来的风险，与其同时重构两端，我选择先利用已有 key 基础的 iOS 验证规则，把流程风险和技术改造范围拆开，再与开发把同一套规则扩展到 Web。

Web 端还包含部分后端返回文案，情况比 iOS 更复杂，但经过 iOS 阶段验证后，责任边界、文案表结构和协作方式已经稳定，不需要再重新定义一套流程。

第四步：把稳定规则沉淀为 AI Skill

公司后续接入 AI 后，我们没有重新建立一套完全不同的流程，而是把已经稳定运行的规则进一步沉淀成 Skill。Skill 会学习现有文案表的 key 命名规则和团队长期形成的日语翻译习惯，用于新功能的文案整理与历史内容复用判断。

设计稿完成后，Claude 通过 Skill 直接读取设计稿中的文案，按现有文案表结构生成一份待确认文档，并先把内容分成 通用文案和业务文案。随后再与现有文案表中的中文内容比对，既识别完全重叠，也提示文字不同但含义接近的历史文案。

• **通用文案明确重叠：**直接复用已有 key、日文和英文，并在备注列标记复用来源；
• **业务文案明确重叠：**复用已有日文和英文，但 key 仍按当前业务重新建立，并在备注列说明对应关系；
• **只有含义接近：**只在备注中列出可能对应的历史文案，不自动填充 key 或日英文案，留给人工判断。

AI 完成初步整理后，产品会人工检查 key 的含义、历史内容是否真的适合复用，以及业务文案是否需要新建。确认后再把内容更新到正式文案表，最后由翻译检查日英文本。

3. Outcome

• 2024年8月底，产品按计划上线中英日三语自由切换，iOS和Web两端的多语言底层架构同步搭建完成；
• 设计、翻译、开发开始围绕统一的 key 和文案表协作，这套流程稳定运行了一年多；
• 团队扩张、分工更明确后，相关工作可以顺利移交给产品团队继续维护；
• 公司接入 AI 后，原有规则进一步沉淀为 Skill，用于设计稿文案提取、历史文案比对、分类和复用建议，原来的流程没有被推翻，而是在同一套责任边界上继续演化；
• 目前仍保留产品与翻译的人工确认，不把近似文案判断、key 语义和最终翻译质量完全交给 AI；

4. Reflection

1. 本次项目不是一次纯粹的界面设计任务，本质上是在设计一套多方协作系统。谁拥有 key 的定义权、哪些工作必须串行、哪些可以并行、如何让流程以后能够被其他团队接手，都是这次工作真正需要解决的问题。
2. 这次经历也让我更愿意主动处理设计之外、但会直接影响产品交付质量的跨职能问题。相比临时协调一次，把责任边界和协作方式固定下来，更容易形成长期稳定的工作机制。
3. AI 接入后，我更明显地感受到：一套流程如果想被自动化，前提是原本的规则足够清楚。key 的命名、通用文案与业务文案的边界、哪些情况可以复用、哪些情况必须人工确认，这些规则先被明确下来，Skill 才能真正稳定地执行重复工作。