国际化文案键审计Skill（i18n-key-audit）：一键揪出“表面翻译了、实际还是会坏”的多语言问题
核心结论速览
- 这是一款面向国际化（i18n / l10n）改造的审计型 AI 技能，核心目标不是“把中文翻成英文”，而是找出表面翻译完成、实际一上线就出问题的隐藏缺陷。
- 它按六步工作流推进：扫描硬编码 → 键命名规范 → 占位符与复数 → 格式与布局 → 缺失与冗余 → 门禁与流程，最终输出结构化的可执行修复清单。
- 覆盖的问题类型非常“实战”：硬编码按钮文案、
text1这类垃圾键名、{count}与{0}混用、阿拉伯语六种复数形态、日期数字货币格式、德语俄语文本膨胀 30% 以上、RTL 镜像布局。 - 产出物是标准化报告：结论（可发布 / 需修复后发布）、硬编码清单表、键问题表、格式与布局建议、CI 门禁建议，可直接转成工单分派给前端、后端或翻译团队。
- 适合新功能上线前评审、接入第二语言时的排障、翻译团队反馈占位符对不上的定责，以及为团队制定文案键规范与 CI 检查规则。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 中文名 | 国际化文案键审计Skill |
| 英文名 | i18n-key-audit |
| 技能ID | 2119810153572892673 |
| 技能类型 | 代码与工程规范审计类 AI 技能 |
| 适用载体 | Web、App、桌面端、多语言 API 项目 |
它解决什么问题
做过国际化的团队几乎都踩过同一类坑：语言包看起来已经 100% 翻译完成，切换到日语后按钮文字溢出被截断；切到阿拉伯语后整页布局错位、箭头方向反了；翻译团队反馈“这句里的 {count} 在译文里少了一个”；错误提示、空状态、无障碍标签这些角落里的文案压根没进语言包。这些问题不属于“翻译质量”范畴，翻译人员也无能为力，它们本质上是工程实现层面的国际化缺陷。
这个技能要做的，就是用一套固定的检查清单把这些缺陷系统性地扫出来，而不是靠人肉回忆“上次好像哪里漏了”。
安装思路与步骤（一键安装）
AI 技能提升开发效率的核心逻辑是：把专业审计方法论固化成一个可被 AI 反复调用的“技能包”，安装一次，之后在任意对话里说一句“帮我做国际化审计”就能自动加载整套检查流程与参考规范，不用每次手工粘贴几百字的提示词。
安装步骤（具体命令、入口地址与是否收费，以官方说明为准）：
- 确认前提：你已经在使用支持“技能（Skill）”机制的 AI 客户端或开发环境；本地项目有可访问的源码目录与语言包文件（JSON、YAML、properties 等）。
- 打开技能入口：进入客户端的技能市场 / 技能管理页，或使用官方提供的技能安装入口。
- 检索技能：用英文名
i18n-key-audit或中文名“国际化文案键审计”搜索，也可以通过技能ID2119810153572892673精确定位。 - 执行安装：点击安装 / 添加，等待技能被加载到可用技能列表中。若为文件形式分发，按官方说明将技能目录放入指定的技能目录下。
- 验证是否生效：新开一个对话，输入类似“请用 i18n-key-audit 技能检查一下我的国际化文案键”，观察返回内容是否包含该技能特有的六步工作流、检查清单与输出模板（含硬编码清单表、键问题表）。如果返回的是泛泛而谈的建议，说明技能未被正确加载，需要回到第 3 步检查。
安装完成后建议先在一个小模块上试跑一次，确认输出格式符合团队预期，再推广到全项目。
该技能的主要功能和特点
能做什么
- 硬编码扫描：识别模板、组件、脚本中的可见字符串，覆盖提示、错误、校验信息、空状态、按钮、标题、无障碍标签，还会检查图片中的文字、PDF 模板、邮件模板，以及后端返回给前端的文案。
- 键命名规范审查：按
模块.页面.元素的结构、全小写、点分隔、语义化原则检查键名，明确点出button_text_2、text1、直接用“确定”当键名这类反例。 - 占位符一致性校验：检查同一语义的占位符是否一处
{count}、一处{0}；译文中的占位符数量与含义是否与源语言一致。 - 复数与性别变体检查：按目标语言的实际规则处理，例如英语两种复数形态、阿拉伯语六种形态，而不是所有语言套用同一份复数模板。
- 格式与布局审计：日期、数字、货币、姓名顺序、地址顺序、电话号码格式是否按 locale 格式化；文本膨胀是否留足空间；RTL 语言的镜像布局与图标方向是否适配（数字仍需保持 LTR）。
- 缺失与冗余分析：目标语言缺少源语言的键、语言包里存在但代码未使用的冗余键、空译文与“复制英文冒充翻译”的占位译文、键顺序不一致导致的 diff 噪声。
- 门禁与流程建议：给出 CI 检查项（键齐全、占位符匹配、无新增硬编码）、伪本地化测试、多语言截图回归、翻译平台双向同步等工程化建议。
和普通工具比强在哪
- 普通静态扫描工具通常只回答“有没有硬编码”，这个技能会继续追问“键名是否语义化”“复数是否按语言处理”“长文案在按钮里会不会截断”，覆盖的是发布风险而不只是代码风格。
- 它不是通用翻译能力，明确声明不适用于纯文案润色和翻译质量评价（后者需要母语审校），边界清晰，避免给出不专业的结论。
- 输出是结构化的修复清单表格加可勾选的检查清单，天然适合转成工单、写进 PR 描述、配置成 CI 门禁项。
如何使用该技能？
第 1 步：准备四类输入
按技能要求，尽量一次性把材料给全，材料越完整结论越准：
- 源码与语言包（JSON、YAML、properties 等格式均可）。
- 目标语言清单，并明确是否包含 RTL 语言（如阿拉伯语、希伯来语）。
- 团队现有的键命名约定（没有就说明现状，让技能同时给出规范建议）。
- 设计稿或界面截图（用于评估文本膨胀对按钮、卡片布局的影响）。
第 2 步：发起调用
在对话中直接描述任务即可，示例：
请用 i18n-key-audit 技能审计这个项目的国际化实现。项目是 React Web 应用，语言包在
src/locales/目录下，包含 zh-CN、en-US、ja-JP、ar-SA 四个语言。我们目前的键名比较混乱，没有统一约定。设计稿见附件。
第 3 步：读懂输出结构
技能会按固定模板给出结果，重点关注四块：
- 结论：一句话判断“可发布”还是“需修复后发布”。
- 硬编码清单：以“文件 / 行 / 文案 / 建议键”四列表格列出所有未走语言包的可见文案，这是最容易直接转工单的部分。
- 键问题：以“键 / 问题 / 影响语言 / 修复”四列表格列出命名不规范、占位符不一致、复数处理错误等问题。
- 格式与布局 + 门禁建议：给出日期数字货币的格式化改造点、RTL 适配点、文本膨胀风险点，以及建议加入 CI 的检查项。
第 4 步：对照检查清单收尾
技能内置了一份十项检查清单（无硬编码、键命名统一、键集合一致、占位符一致、复数与性别变体、locale 格式化、RTL 适配、长文案不截断、伪本地化与截图回归通过、CI 门禁已配置）。修复完成后逐项对照勾选，作为上线前的验收依据。
第 5 步：落入流程
把硬编码清单和键问题表拆成任务分派；把门禁建议中的检查项配置到 CI；把新增的键规范沉淀进团队文档，之后的评审直接引用。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 国际化文案键审计Skill（本技能） | AI 驱动的国际化全链路审计助手 | 硬编码扫描、键规范审查、占位符与复数校验、格式布局与 RTL 检查、缺失冗余分析、CI 门禁建议 | 需在支持技能机制的 AI 客户端中安装，按官方说明操作；使用时需提供源码与语言包 | 上线前评审、接入新语言排障、制定键规范 | 优势：覆盖“代码 + 语言包 + 布局 + 流程”多层问题，输出可直接执行的修复清单，方法论开箱即用；不足：依赖输入材料的完整性，不评估翻译质量本身 |
| 通用国际化静态检查工具（如键提取与 ESLint 类插件） | 代码层自动化扫描 | 提取待翻译字符串、检测硬编码、生成语言包骨架 | 需接入构建流程与配置规则，学习成本中等 | 日常开发中的持续检查 | 优势：可自动化、可进 CI，误报可控；不足：通常不判断键名是否语义化、不覆盖布局膨胀与 RTL 体验问题 |
| 翻译管理平台（TMS 类产品） | 翻译协作与语言包托管 | 翻译工作流、多人协作、版本同步、部分质量校验 | 需开通账号并接入同步流程，团队协作成本较高 | 多语言版本频繁迭代的中大型团队 | 优势：流程规范、协作效率高；不足：偏“译中与译后管理”，对源码硬编码与前端布局问题介入有限 |
| 人工评审 / 母语审校 | 人的经验判断 | 语言自然度、文化适配、术语一致性 | 依赖专家资源，成本与周期较高 | 品牌文案、合规敏感内容 | 优势：质量上限最高；不足：难以穷举工程细节，成本高，无法高频执行 |
结论：这几类方案并非替代关系。静态工具负责日常守门，翻译平台负责协作流程，母语审校负责质量上限，而本技能更像是上线前的“全科体检医生”，把散落在各环节的国际化风险集中盘一遍，并输出统一的修复口径。
该技能的典型应用场景与实际体验情况
场景一：新功能上线前的国际化体检
角色：前端负责人。痛点：新功能开发时赶进度，文案直接写在组件里，等到要发海外版本才发现语言包里缺了一大半。使用方式：把新功能的源码目录与语言包交给技能，要求输出“需修复后发布”的结论与硬编码清单。实际体验：结论判断非常直接，硬编码清单落到文件与行号，转工单几乎零成本；需注意提供完整的目标语言清单，否则“影响语言”一列会不够精确。
场景二：接入第二种语言时的排障
角色：全栈开发。痛点：上线日语版本后，翻译团队反馈“占位符对不上”，前端又找不到具体是哪个键。使用方式：把多语言语言包一起交给技能，让它做键集合与占位符一致性比对。实际体验：能把 {count} 与 {0} 混用、译文缺占位符这类问题一次性列全，比人工逐个文件比对快得多；建议同时提供现有键命名约定，便于技能区分“历史遗留”与“新引入”的问题。
场景三：RTL 与文本膨胀的布局风险预判
角色：UI 设计师与客户端开发。痛点：阿拉伯语版本布局错乱、德语长单词把按钮撑破，但设计稿只有中文和英文版本。使用方式：提供设计稿与目标语言清单（含 RTL），让技能评估镜像布局、图标方向与长文案截断风险。实际体验：能明确提示“数字仍需保持 LTR”“德语俄语通常比英语长 30% 以上”这类容易忽略的点，把问题前移到设计阶段；注意它做的是风险提示，最终仍要靠伪本地化与多语言截图回归验证。
场景四：为团队制定文案键规范并接入 CI
角色：技术负责人 / 架构师。痛点：各模块键名风格混乱，text1、button_text_2 随处可见，评审靠个人习惯。使用方式：让技能基于现有代码给出键规范建议与门禁清单，再配置到 CI。实际体验：反模式部分（中文直接当键名、字符串拼接造句、只翻主流程漏掉错误与空状态、用 toUpperCase() 处理土耳其语等特殊语言）非常贴近真实踩坑记录，直接可以作为团队规范的第一版；落地时建议分批推进，先卡“新增硬编码”再治理存量。
上手难度小结：整体门槛低，会用自然语言描述项目情况即可，无需学习新命令；真正的成本在于准备输入材料，材料越全，报告的可用度越高。
该技能能为用户带来的价值
- 把隐性风险变成显性清单：国际化问题最大的成本是“上线后才被发现”。技能把硬编码、键缺失、占位符不一致、布局溢出、RTL 错位这些风险提前到发布前暴露，直接减少海外版本的回滚与热修。
- 显著压缩审计时间：人工做一次全项目国际化走查往往需要数小时甚至数天，还要靠记忆确认“上次是不是查过空状态”。技能按固定六步流程一次跑完，并可重复执行，把审计从“项目制”变成“例行制”。
- 降低国际化门槛：团队第一次做多语言时，往往不知道要考虑复数的语言差异、文本膨胀、RTL 镜像。技能内置的检查清单与参考规范相当于一份随叫随到的专家方法论，让没有国际化经验的团队也能按图施工。
- 统一多方协作口径：硬编码清单、键问题表是前端、后端、翻译团队都能看懂的统一语言。谁的问题、影响哪些语言、怎么修，一行一行写清楚，减少“这不是翻译的问题吗”这类扯皮。
- 沉淀长期可复用的工程资产：键命名规范、CI 门禁项、伪本地化与截图回归流程一旦建立，会成为团队长期受益的基础设施，随着语言数量增加，边际收益反而更高。
常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？
A：在支持技能机制的 AI 客户端中，用英文名 i18n-key-audit、中文名“国际化文案键审计”或技能ID 2119810153572892673 检索后安装即可。具体安装命令、入口位置与是否收费，以官方说明为准。安装后建议先用一个小模块试跑，确认能输出六步工作流与结构化报告，再推广使用。
Q2：它能直接帮我把中文翻译成英文吗？
A：不能，也不建议这样用。该技能的定位是审计与规范，明确声明不适用于纯文案润色与翻译质量评价（后者需要母语审校）。它能做的是找出哪些文案没有进入语言包、哪些键命名有问题、哪些占位符不一致、哪些格式没有按 locale 处理，然后把问题清单交给你和翻译团队去修。
Q3：我的项目是后端接口返回文案，前端没有语言包，适用吗？
A：适用。技能的第 1 步扫描范围就包含“后端返回给前端的文案”，同时也覆盖图片中的文字、PDF 模板与邮件模板。只要你能提供源码与相关的文案资源，它就能给出硬编码清单与改造建议。
Q4：适合谁用？小团队有必要吗？
A：最适合三类人：要做海外版本的前端/客户端开发、负责上线质量的技术负责人、以及需要制定国际化规范并接入 CI 的架构师。小团队反而更值得用——没有专职国际化同学时，这套清单相当于把专家经验前置到开发流程里，成本远低于上线后返工。
Q5：和静态检查工具、翻译管理平台怎么选？
A：三者互补，不是二选一。日常开发用静态检查工具做 CI 门禁守住增量；需要全链路体检、制定规范、排查“翻译了却还是坏”的疑难问题时用本技能；翻译协作与语言包托管交给翻译管理平台。如果团队刚开始做国际化，建议先用本技能跑一次全量审计，把家底摸清、规范定下来，再上工具与平台。