x-three-translations

三次翻译 — 把内部语言翻成外部语言

R — 原文 (Reading)

从内部语言到外部语言。第一次翻译:把发布改成帮助——"我们上线新功能"→"这个功能能帮你把80页报告变成3页提纲"。第二次翻译:把能力改成场景——"支持长上下文"→"一次性读完行业报告并找出竞品变化"。第三次翻译:把结论改成证据——少说"效果很好",多放真实截图、输入输出、步骤、对比。重点是"别人能拿走什么",而非"我说了什么"。

— 向阳乔木 @vista8, X爆款秘籍分享 · 三次翻译

---

I — 方法论骨架 (Interpretation)

创作者天然用"内部语言"写作——讲自己做了什么(发布)、产品有什么(能力)、结果怎么样(结论)。这些对创作者有意义，对读者毫无抓手。

三次翻译是三步视角转换，每步把焦点从"我说了什么"移向"别人能拿走什么":

1. 发布→帮助:别告诉读者你做了什么，告诉读者这件事能帮他做什么。"我们上线新功能"是发布，"帮你把80页报告变3页提纲"是帮助。
2. 能力→场景:别罗列产品能力，把它嵌入一个读者会遇到的真实任务。"支持长上下文"是能力，"一次性读完行业报告找出竞品变化"是场景。
3. 结论→证据:别只说"效果很好"，给出读者能自行验证的证据——截图、输入输出、步骤、前后对比。

三次翻译不是"把话写通顺"，而是切换信息接收方视角。判断标准:读者看完能不能直接拿走一个行动？

---

A1 — 书中的应用 (Past Application)

案例 1: 向阳乔木"公告式→帮助式"改写

• 问题: AI 产品/工具推文容易写成"我们上线了X功能"，像发布公告，读者不知道跟自己有什么关系。
• 方法论的使用: 对"我们上线新功能"做第一次翻译(发布→帮助)，改写成"这个功能能帮你把80页报告变成3页提纲"。焦点从"我们做了什么"变成"你能用它做什么"。
• 结论: 公告式表达只传递信息，帮助式表达传递行动可能性。后者才有传播力。
• 结果: 该案例被作为三次翻译的标杆示例，帮助读者理解"内部语言→外部语言"的第一次转换。向阳乔木 3861 帖数据中，带"可行动"信号(资源/步骤/入口)的帖子进入前 10% 概率显著更高。

案例 2: X 官方 Article 指南"Show, don't just tell"

• 问题: X 官方在 Article 写作指南中指出，创作者常犯的错误是只下结论("效果很好")而不给证据。
• 方法论的使用: 官方提出"Show, don't just tell"原则——对任何主张，紧跟证据(数据、个人故事、前后对比图)。这本质就是第三次翻译(结论→证据)的官方版。指南原文:"For any claim you make, follow it immediately with evidence of why it's true (stats, personal story, before/after, etc.)"。
• 结论: 官方指南与向阳乔木的三次翻译独立验证了同一原则——结论必须配证据。
• 结果: 该指南作为 X 官方 Article 写作的标准方法发布，面向所有 Premium 用户。

案例 3: "长上下文功能"的二次翻译(能力→场景)

• 问题: 用户问"怎么把'我们上线了长上下文功能'改成强推文?"
• 方法论的使用: 第二次翻译(能力→场景)——把"支持长上下文"这个能力嵌入读者真实任务:"一次性读完行业报告并找出竞品变化"。再接第三次翻译(结论→证据):放前后对比截图，展示用长上下文前后的效率差异。
• 结论: 能力是产品视角，场景是读者视角。读者不为能力付费，为解决自己的问题付费。
• 结果: 这是 V2 验证阶段构造的新问题，证明三次翻译框架能处理原始案例之外的变体。

---

A2 — 触发场景 (Future Trigger) ★

用户会在什么情境下需要这个 skill?

1. 已有初稿但读起来像公告:用户写了一条推文/产品发布文案，内容是"我们发布了X/支持Y/升级了Z"，感觉没人会转发，想改得更有吸引力。
2. 功能介绍写不吸引人:用户要把一个产品能力写成推文，但写出来像功能列表，不知道怎么让读者觉得"跟我有关"。
3. 推文发了没人理，自查原因:用户发了一条推文互动很低，怀疑是表达方式的问题(实际原因是只讲自己不讲读者)。
4. 把"效果很好"变成可信内容:用户写了"效果很好/非常强大/体验极佳"等结论性表达，需要补证据。
5. 长上下文/新功能上线的推文改写:用户要把技术性功能描述翻译成读者能感知的场景。