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

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. 长上下文/新功能上线的推文改写:用户要把技术性功能描述翻译成读者能感知的场景。

语言信号 (用户的话里出现这些就应激活)

• "这条推文读起来像公告 / 像新闻稿 / 像产品更新说明"
• "怎么把'我们上线了X'改成强推文 / 改得吸引人"
• "功能介绍怎么写 / 怎么把功能写得有人看"
• "效果很好但是没人理 / 为什么没人转发"
• "这段太像自嗨了 / 太像在自说自话"
• "announcement tone / feature list / show don't tell / translate to reader value"
• "how to make this less like a product announcement"

与相邻 skill 的区分

• 与 x-four-saves 的区别:四省模型评估"这条值不值得发"(估值)，三次翻译改写"已决定发但表达方式不对"(改写)。四省是发之前的筛选，翻译是筛选之后的表达优化。
• 与 x-five-piece-checklist 的区别:五件套检查内容是否完备(五要素齐全)，三次翻译专注其中"价值承诺"和"证据"两件的语言质量。五件套是结构检查，翻译是语言转换。
• 与 x-short-content-craft 的区别:短内容工坊是从零起草(Hook-Body-CTA 结构选择)，三次翻译是对已有初稿做视角转换。前者解决"怎么写"，后者解决"写出来像公告怎么办"。
• 与 x-content-archetypes 的区别:四类原型决定"发什么类型的内容"，三次翻译决定"同一类型的内容怎么把语言从内部翻到外部"。

E — 可执行步骤 (Execution)

当 skill 被激活后，agent 应按以下步骤执行:

1. 识别公告式表达(内部语言)

- 扫描用户提供的初稿，标记三类内部语言信号:发布式("我们发布/上线/升级了")、能力式("支持X/具备Y功能")、结论式("效果很好/非常强大")。 - 完成标准:每类至少标记 1 处(若存在)，或明确告知用户"当前初稿没有公告式表达，不需要三次翻译"。 - 判停条件:若初稿中不存在任何公告式表达，跳到步骤 4 直接输出"初稿已是外部语言，无需翻译"。

1. 逐句做三次翻译

- 对每个标记点做对应翻译: - 发布→帮助:问"这件事能帮读者做什么?"，把"我们做了X"改写成"这能帮你做Y"。 - 能力→场景:问"读者在什么真实任务中会用到这个能力?"，把功能描述嵌入具体任务。 - 结论→证据:问"读者怎么自行验证这个结论?"，用截图/数字/步骤/前后对比替换"效果很好"。 - 完成标准:每个标记点都有对应的翻译结果，翻译后内容以"读者能拿走什么"为焦点。

1. 验证翻译质量并输出改写结果

- 对翻译后的内容做自检:读者看完能否直接拿走一个行动或一个可验证的证据?若不能，回步骤 2 重译。 - 输出:原文 → 翻译后对照(标明每次翻译的类型)，并给出最终改写版本。 - 完成标准:输出包含对照表 + 最终版本，且最终版本中无残留的公告式表达。

1. (可选)给出翻译未覆盖的建议

- 若发现初稿除了语言问题还有结构问题(如缺 Hook/CTA)，提示用户可进一步使用 x-short-content-craft 或 x-five-piece-checklist。 - 完成标准:仅提示，不越界执行其他 skill 的工作。

B — 边界 (Boundary) ★

不要在以下情况使用此 skill

• 从零起草新内容时:三次翻译是对已有初稿的改写工具，不是起草工具。从零开始应使用 x-short-content-craft 选类型和结构。
• 内容本身已是外部语言时:如果初稿已经以读者视角写作(有场景、有证据、有帮助式表达)，不需要翻译。强行翻译会过度修饰。
• 纯信息查询/新闻播报:有些内容天然是公告(如官方新闻稿、版本更新日志)，不需要翻译成帮助式表达——其目的就是传递事实。

作者在书中警告的失败模式

• ce18(低质量 Quote"太强了好牛逼"):低质量 Quote 只有感叹词无实质内容，本质上是没做第三次翻译(结论→证据)——只说"太强了"(结论)但不给任何增量证据(截图/步骤/对比)。被读者视为蹭流量，遭到举报拉黑。Quote 的增值在于补充增量观点，无增量的 Quote 等同于寄生噪声。

作者的盲点 / 时代局限

• 三次翻译的案例多来自 AI/产研赛道(工具推荐、功能发布)，在其他赛道(如纯故事型、情绪型内容)中第三次翻译(结论→证据)不一定适用——故事型内容的力量在于共鸣而非证据。
• 向阳乔木的经验基于个人 3.4G 数据，存在过拟合风险——不是所有"公告式表达"都需要翻译，有些领域的受众确实需要官方语调(如 B2B、企业客户)。

容易混淆的邻近方法论

• "通俗化表达":三次翻译不是把专业术语翻译成大白话(那是降维)，而是切换信息接收方视角(从创作者到读者)。两者可以同时做，但不是一回事。
• "Show don't tell":这是第三次翻译(结论→证据)的子集，只覆盖三次翻译中的一步。三次翻译还包括发布→帮助、能力→场景两次视角转换。

相关 skills

• composes-with x-five-piece-checklist: 三次翻译改写语言质量,五件套检查结构完备性,两者配合——翻译完用五件套验证证据是否满足"三个可"。

审计信息

• 验证通过: V1 ✓ / V2 ✓ / V3 ✓
• **测试通过率: 待测 (详见 test-prompts.json)
• 蒸馏时间: 2026-07-14