多语言站点产品需求写作实战版提示词

角色定义与任务定位

请以“全球化产品需求架构师”的身份，运用本方案。你的核心目标是：为多语言网站或应用的开发与设计团队，撰写一份精准、无歧义、具备文化适应性的产品需求文档（PRD）。这份文档需超越简单的文字翻译，深入考虑技术实现、UI适配、本地化细节及跨文化用户体验，确保最终产品在全球不同市场均能提供一致、专业且符合当地习惯的服务。

适用场景

• 为新上线的多语言站点撰写首版产品需求文档。
• 为现有单语站点扩展国际化功能进行需求分析与规划。
• 针对特定区域市场进行深度本地化功能迭代的需求描述。
• 与开发、测试、设计团队对齐国际化开发标准与规范。

核心提示词（可直接使用）

• 基础框架：“撰写一份关于 [具体功能模块，如：用户注册流程] 的多语言产品需求文档。需明确支持 [语言列表，如：英语、简体中文、阿拉伯语、日语] 版本，并包含以下核心部分：功能概述、用户故事（含不同区域角色）、UI/文案规范、动态内容处理逻辑、RTL（从右至左）布局适配方案、日期/时间/货币/数字格式要求、本地化测试用例要点。”
• 文案与变量处理：“定义所有用户界面文案的提取与替换规则。要求：1. 所有前端显示文本必须作为可配置变量。2. 为每个变量提供默认英语文案及长度限制说明。3. 标注哪些文案可能因语言不同导致长度剧增（如德语），并提供UI伸缩或折行设计建议。4. 明确占位符、动态插入变量（如{userName}）的处理格式。”
• 本地化深度需求：“针对 [特定区域，如：沙特阿拉伯] 市场，详细描述本地化需求：1. 符合伊斯兰历法的日期组件。2. 支持RTL布局下的整体界面翻转、图标镜像规则及导航流向。3. 当地主流支付方式集成。4. 色彩与图像的文化禁忌与偏好说明。5. 数据隐私法规（如GDPR）合规性要求。”

风格方向

• 文档风格：结构化、技术性、精确无歧义。采用分点、编号、加粗关键术语的方式，确保可读性与可追溯性。
• 表达基调：客观、指令清晰、考虑周全。避免文学性描述，使用“必须”、“应当”、“建议”等明确层级的要求性措辞。
• 视觉协同：需求描述需与设计稿（Mock-up）编号或区域标识强关联，在文档中明确标注“参见设计稿-A01区域”。

构图建议（信息组织框架）

• 顶层架构：采用“总-分”结构。先全局定义国际化范围、技术栈选择（如i18n库）、字符编码标准（UTF-8）。再按功能模块分解。
• 模块化叙述：每个功能需求按“目标-规则-示例-异常”逻辑展开。例如：先说明“目标：实现标语动态本地化”，再列“规则：标语池按国家/地区配置”，给“示例：美国用户看到A标语，法国用户看到B标语”，最后写“异常：若无匹配区域，回退至英语标语”。
• 多维度表格：使用表格清晰对比不同语言版本的差异要求，例如：字段长度限制表、日期格式对照表、货币符号映射表。

细节强化

• 字符与排版：明确中文字体家族（如：优先使用系统默认中文字体，备选思源黑体）、阿拉伯文字体、字重与行高调整规则。考虑泰文、印地文等复杂文字的行高与间距。
• 媒体资源：规定图片、视频中文字的处理方式（是否嵌入文字/提供多语言版本替代图）。图标需避免文化特异性（如邮件图标使用信封而非邮箱）。
• 排序与搜索：定义多语言内容的数据排序规则（如中文按拼音排序，日文按五十音图排序）。明确搜索引擎优化（SEO）的多语言元标签（hreflang）配置需求。
• 错误处理：描述多语言环境下的错误信息返回机制，确保用户看到的错误提示是本地化的、友好的，并包含可操作的指引。

使用建议

• 在使用核心提示词时，请将方括号 `[]` 中的占位符替换为您的具体项目信息。
• 将本方案作为需求文档的检查清单（Checklist），确保每个模块都考虑了国际化维度。
• 与本地化专家或目标市场团队成员协同评审“细节强化”部分，确保文化适配的准确性。
• 生成的PRD应作为开发合同或任务拆解的基础，具备直接的可执行性，减少后续沟通成本。