把单语站扩成多市场，大部分是机械活——但每一步都有自己的雷。hreflang 被讨论得最多；本地化信号（日期、地址、电话）和货币（符号、小数位、位置）出错时同样吃掉排名。这篇用 AI 在 90 分钟内规划一个新 locale 的上线清单，覆盖 hreflang、本地化、货币，每条都带验证命令。产出是一份能直接转工程任务的 markdown 计划。
这篇讲什么
为新增一个 locale 做规划。AI 出三份清单：hreflang 设置（sitemap、head、x-default）、本地化（数字、日期、电话、地址）、货币（显示、换算、结算）。每条都打 P0 / P1 / P2 标签 + 一个验证步骤。产出不是通用清单——它是按你的 stack 和现有配置形塑出来的。
这篇适合谁看
要上第二第三 locale 的内容站和产品站、要复审”勉强能跑”的现有多 locale 配置的 SEO 经理、被一句”加日语”丢过来没有范围的工程师。已经上第 4 个 locale 的成熟站可以跳过——你自己的 runbook 比 AI 推理强。
什么时候适合用
每次新 locale 上线前、locale 重命名后（zh → zh-CN）、某市场流量在但表现差时（多半是货币或地址格式问题）、季度性审计现有 locale。这篇 hreflang 部分只覆盖框架——深挖看 AI hreflang 检查实操。
开始前准备
- 把现有 locale 清单清楚：用哪些 lang code、URL 模式（子域 / 子目录 / ccTLD）、内容集合在哪、用什么 CMS。每个都会影响新 locale 的方案。
- 新 locale 的 lang code 提前定。zh 和 zh-CN 混用是多 locale 项目里最常见的 bug。
- 现有每个 locale 各开一个线上页面到浏览器 dev tools。AI 做范围检查需要”当前已经做对了什么”的 baseline。
- 列出目标市场的预期：货币、小数分隔符、地址格式、电话格式、纸张尺寸、一周从星期几起。规划前先列清。
具体步骤
- 用一段话把 stack 和 locale 介绍给 AI：URL 模式、现有 locale、hreflang 策略、内容集合布局、用了什么 i18n 库或 CMS。
- 要三份分组清单：hreflang、本地化、货币。强制分组——铺平的列表会漏掉类别。
- 让 AI 每条标 P0（阻塞上线）、P1（30 天内）、P2（锦上添花）。
- 每条加一个验证步骤：curl 命令、view-source 检查、对渲染后 HTML 的正则、或截图目标。没有验证的条目会很快烂掉。
- 每条 P0 都过一遍是否适用于你的 stack。Astro SSG 不需要 locale middleware，Next.js 多数情况要。不适用的删掉。
- 货币方面，按页面类型定一条规则：商品页可能需要实时换算，内容页”仅显示”够用。混在一起范围就崩。
- 把方案存成
INTL_LAUNCH_<locale>.md，每个 locale 一个文件提交。后来人需要这个 locale 特有的上下文。
第一次实操怎么跑
- 只规划一个 locale，不要规划整套多 locale 上线。挑市场需求最清楚那个。
- 把这一个 locale 端到端走一遍。时间预算：stack 描述 prompt 10 分钟、AI 范围 5 分钟、人工剔 30 分钟、整理 30 分钟、验证命令 15 分钟。共 90 分钟。
- 把对话存档。下一个 locale 的规划从这份输出当模板开始，省一小时。
- 把 AI 幻觉记进项目日志——常见的有：给你根本没有的 AMP 页建议 hreflang、推荐已经下线的换汇 API。
完成后检查
- 每条 P0 都有验证命令、URL 模式、或截图目标。“验证 hreflang 存在”不可验证，
curl -s URL | grep hreflang可验证。 - 没有引用你 stack 不支持的特性。“用 Next.js middleware 做 locale”在你是 Astro 时就是错的。
- 本地化清单至少要覆盖：日期格式、数字分隔符、电话格式、地址格式、一周起始日。少一个就是软上线缺陷。
- 货币清单区分”仅显示”和”实时换算”。两者验证方式不同。
- hreflang 条目同时核 sitemap 和 head。两边冲突时 Google 干脆都不信。
怎么复用这套流程
- 每个新 locale 提交一份
INTL_LAUNCH_<locale>.md。放docs/里，从 README 引用。 - 季度审计就是对同一个 locale 重生成清单，跟已提交的方案 diff。
- 维护”错过的 locale code”日志。每出一个真 bug 就加成下次规划 prompt 的约束。
- 三次 locale 上线后，你的 prompt 已经比通用清单准——值得花时间打磨。
建议的操作流程
stack 和现有 locale 描述 → AI 出三份分组清单（hreflang / 本地化 / 货币）→ 优先级标 P0 / P1 / P2 → 每条加验证步骤 → 人工剔不适用项 → 提交为 INTL_LAUNCH_<locale>.md → 季度重生成并 diff 做审计。
容易踩的坑
- 把 hreflang 当成全部工作。它最容易做对，做对后增益最小。
- 跳过货币显示测试。EUR 页上挂 USD 格式的价格，对当地用户看就是坏站。
- 硬编码日期格式。
MM/DD/YYYY在非美 locale 看着就像乱码——用平台的 locale-aware formatter。 - 每个 locale 都翻译 URL slug。某些市场更偏好英文 slug（开发者工具尤其），一刀切翻译是假一致。
- 上线但没在该 locale 的 Search Console 验证。否则你都不知道有没有被索引。
- 把 locale 和语言混为一谈。
en-GB和en-US同语言不同 locale，货币和日期都不一样。
FAQ
- 新 locale 该用子目录还是子域？: 默认子目录；只有该 locale 有独立团队或内容范围明显不同才用子域。
- 要不要用 ccTLD？: 地理信号最强，但维护贵。只在你有该国独立业务策略时用。
- 要请翻译还是 AI 翻译够？: 内容站营销文案 AI 可以做第一轮。产品 UI 要请母语审校。转化率跟”本地感”文案强相关。
- 货币换算怎么处理？: 内容站做”页面级仅显示换算”够用。结算时的实时换算必须接活的汇率源。
- 新 locale 被 Google 完全索引要多久？: 第一次有意义的抓取要 4-12 周。立刻交 sitemap 并在 Search Console 验证 locale 能缩短。
- 新 locale 跟原 locale 共享站内链图吗？: 共享。新 locale 镜像 EN 链图，用 translationKey 维持 hreflang 配对。