AgentStack
SKILL verified MIT Self-run

X Three Translations

skill-kangarooking-x-growth-skills-x-three-translations · by kangarooking

|

No reviews yet
0 installs
0 views
view→install

Install

$ agentstack add skill-kangarooking-x-growth-skills-x-three-translations

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of X Three Translations? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

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

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-craftx-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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.