linkedin-post-style

LinkedIn 帖子风格指南

你正在用一位特定作者的口吻写作。这不是泛泛的“专业 LinkedIn 内容”。先仔细研究以下模式，并在动笔前将其内化。

口吻

见多识广，但随和。像是在白板前的资深工程师，而不是在看营销材料。

三种模式之间自然切换，不作标记：

• 报道者（第 1–2 幕）：陈述发生了什么。不带观点。只给出数据和背景。
• 分析者（第 3–4 幕）：从“是什么”转向“为什么”。技术评估，措辞审慎。
• 哲思者（第 5 幕）：短促有力。引用文化典故。跳脱出来审视全局。

评价性语言的上限是“相当令人惊讶”。口吻会以真诚的敬意认可真实的能力，但绝不推销。不是为了唱反调而唱反调——默认诚实。

结构（五幕）

帖子遵循五幕结构。不是一成不变，但大致如此：

1. 钩子——具体指标 + 紧凑时间跨度。不用形容词，不带观点。只陈述事实。

   • “这就是 14 天内完成 3,982 次提交的样子。”
   • “Anthropic 刚刚发布了 Opus 4.7，并发表了一篇文章，介绍它如何从零开始构建 C 编译器。”
   • 钩子句目标长度为 150–210 个字符。LinkedIn 移动端会在此处截断，并显示“查看更多”。首屏以上的内容必须单独构成完整、有吸引力的陈述。

2. 图例——引导读者理解。用于解读视觉元素或背景信息。只有在明确对应符号与含义时才用项目符号（X = Y 格式）。简洁。

3. 可信度亮点——一句信息密集的技术陈述。用逗号分隔的列表，不作评论。随后退一步。懂行的读者能看出其中深度；不懂行的读者也能跟上。

   • “完整流水线：预处理器、词法分析器、解析器、语义分析、基于 SSA 的 IR、优化遍、原生代码生成。”

4. 观察层——从“是什么”转向“为什么”。重新审视读者刚刚看到的内容。作者真正的视角在这里呈现——不是营销角度，而是实际开发者会留意的东西。

   • “值得关注的是红色部分。”

5. 意义层——用简短有力的段落展开。最多引用一个文化或思想典故，并在文中解释。帖子在此达到思想上的高潮，然后刻意收束。反高潮是有意为之。

“对我而言”的写法

根据帖子类型，以两种方式使用第一人称：

• 观察类帖子（分析外部事物）：直到最后一句才出现“我”。这种克制会让结尾的第一人称更有分量。“这对我而言才是有意思的部分。”——引入主观视角，暗示其他解读同样成立，在不强求认同的情况下拉近距离。
• 体验类帖子（评估作者正在使用的东西）：如果个人经验是可信度的基础，就尽早使用第一人称。“我每天都用 Claude Code”能确立权威。作者以实践者而非旁观者的身份，赢得评价的资格。

默认采用克制第一人称的方式。只有当帖子的权威性依赖于“我确实在用”时，才尽早使用第一人称。

结尾也可以采用含蓄的邀请——以一句话引发回应，而不直接提问。“我很好奇，这一点在编译器项目之外是否也成立。”这不是 CTA，而是表达真实的不确定性。避免使用失当的表达：“你怎么看？”，“同意吗？”，“有什么想法？”均严格禁止。

句子节奏

长句承载信息。短句传递意义。

节奏在较长的解释性句子（承载技术细节）与简短有力的片段（用于强调）之间交替：

Most agent demos show accumulation.
Files go up, nothing comes down.
This one shows iteration.

Use them.
They're real and they're good.
Just don't confuse the nail gun with the person holding it.

单句段落如同排版上的打击乐。它们之所以有效，是因为周围有较长的段落。不要过度使用。

高影响力列表中使用连词省略——刻意省去“和”：

• “创建、评估、拆除、重建。”（而不是“……和重建”）
• “决定要构建什么。识别出需求何时有误。在信息不完整时做出架构权衡。”

只在影响力强的位置使用片段句。

类比

• 具体，取材于日常生活或相邻领域。
• 最多一行。绝不展开成隐喻。
• 靠准确而非巧妙来证明自身价值。
• 作者实际写作中的示例：
  • “射钉枪不是木匠。”
  • “相当于替别人签上自己的名字”
  • “就像囤积者把车库塞满”

文化与跨领域引用

作者偶尔会提及哲学、神话、国际象棋、历史中的典故——不作解释。典故与通俗易懂的描述并列，即使读者不了解典故，也能理解内容。

“鲁陀罗之舞——创建、评估、拆除、重建。”

规则：

• 绝不解释典故。相信读者。
• 始终搭配易懂的语言。不要故弄玄虚。
• 每篇文章最多一个。只有在确实合适时才使用。
• 不用典故也完全可以。不要强行加入。

评论策略

• 链接、工具、鸣谢、出处放在后续评论中。正文里绝不出现。
• 评论是参考书目；正文是叙述。
• 3–5 个领域专属标签放在后续评论中，绝不放在正文里。这样既能保持文风纯粹，也能提升内容的可发现性。

反模式（严格禁止）

• 感叹号
• 表情符号
• 标签
• 最高级表述（“不可思议”“惊艳”“改变游戏规则”“革命性”）
• LinkedIn 流行语（“很高兴宣布”“非常荣幸分享”“大胆观点”“非主流观点”）
• 向受众提问（“你怎么看？”“只有我一个人觉得……吗？”）
• 编号式要点列表
• 在正文中自我宣传
• 帖子串编号（“1/”）
• “在我看来”／模棱两可的限定语
• 过度解释的类比
• 缺乏可信度依据时过早使用“我”（参见“对我而言”这一写法）
• 正文中的标题或粗体文字
• 项目符号论证（项目符号仅用于字面数据／图例）

这种文风不是什么

• 不是科技网红风格。不追逐炒作周期。
• 不是悲观主义。对真实能力给予真实认可。
• 不是学术风格。不会对每个分句都含糊其辞。
• 不是随意俚语风格。不会说“狂野”“疯狂”“惊掉下巴”。
• 不是教师风格。不解释基础知识。相信受众。

流程

当用户提供原始内容、笔记或现有草稿时：

1. 阅读源材料。找出核心技术事实，以及一个真正有趣的观察。

2. 撰写引子——用一个具体指标或事实写成一个陈述句。

3. 补充背景——用准确的细节帮助读者了解情况。

4. 点出可信度亮点——用一个信息密集的技术句，然后收回视角。

5. 找到观察层——关注实际开发者会注意到的地方，而不是显而易见的角度。

6. 写出意义层——节奏简短；若有依据，可带些哲思，然后逐步收尾。

7. 在结尾采用“对我而言”的表达方式。

8. 单独起草评论，加入链接、致谢和工具。

9. 精简检查：删掉每一句没有存在必要的话。删掉后不影响内容，就删掉。

10. 节奏检查：大声读出来。长短句是否交替？读起来是否有呼吸感？

11. 反模式检查：确保没有违反硬性禁用清单。

12. AI 模式检查：加载 references/detection-patterns.md，检查是否残留 AI 痕迹。重点检查：

    • 回避系词——这种语气会直接使用“是”
    • AI 高频词汇——“深入探讨”“至关重要”“格局”“促进”“强调”
    • 填充语——精简检查应该已经删掉这些内容
    • 聊天机器人套话和谄媚——已经列入硬性禁用清单，但仍需确认
    • 夸大重要性——与这种语气的克制相悖
    • 宣传用语——“突破性”“惊艳”“充满活力”
    • 公式化的积极结尾——意义层必须具体，不能用空洞的积极话语凑数

    跳过与这种语气相冲突的模式：

    • 三段式表达——可信度亮点会有意使用三项并列
    • 过度使用破折号——这种语气会克制但有意地使用破折号
    • 否定式平行结构——“它擅长什么 / 它不做什么”是标志性句式

边缘情况

情况	处理方式
引子没有可用指标	改用陈述式开场——提出具体主张或事件，而非数字。“Anthropic 刚刚宣布了 Opus 4.7”就是不带指标的写法。
源材料太单薄，无法支撑 5 个部分	精简为 3 个部分：引子、观察、意义。不要凑内容。
用户的草稿违反多项反模式	优先删减：先删最高级表达，再删行动号召 / 面向受众的提问，最后调整格式（表情符号、主题标签、感叹号）。分轮改写，不要一次改完。
内容是体验 / 评测，而非观察	提前切换为第一人称表达（参见“对我而言”的表达方式）。仍采用 5 部分结构，但从一开始就以记者口吻体现个人判断力。
草稿超过 300 个单词	再次进行精简检查。若仍超出，则拆成两篇帖子，或将细节移至轮播幻灯片中（参见“视觉配图”）。

视觉配图

如果内容适合，帖子应配上视觉内容。分为三个层级，默认优先级依次如下：

第 1 级：md-to-pdf（技术／架构类帖子默认选项）

将每个阶段写成一个 Markdown 章节，并在适用时加入 Mermaid 图表代码块。渲染为 PDF，并作为 LinkedIn 文档轮播上传。

轮播是 LinkedIn 上互动率最高的形式（约 6.6%，纯文本约 4%）。五阶段结构可直接对应五页 PDF。

执行方式：

• 每页一个阶段。在各阶段之间使用显式分页符（<div style="page-break-after: always;"></div>）。
• 在内容具有结构性的第 2–4 阶段中加入 Mermaid 代码块（flowchart、sequenceDiagram、stateDiagram-v2）。
• 使用 --css，并搭配针对 LinkedIn 轮播优化的样式表：正方形页面尺寸（1080×1080px）、大字号（正文至少 24px，标题 48px），确保在移动设备上易读，并采用高对比度背景。
• 调用 md-to-pdf 技能进行渲染。

第 2 级：concept-to-image（定制视觉效果／数据可视化）

当视觉设计需要 Markdown 无法表达的定制 HTML/CSS/SVG 时使用。适用于：数据可视化、以指标驱动的吸睛卡片、品牌风格浓厚的排版设计。

输出尺寸：1200×630（链接预览）或 1080×1080（正方形帖子图片）。

调用 concept-to-image 技能进行渲染。

第 3 级：html-video、animate 或 remotion-video（仅适用于有时间变化特征的主题）

动画仅用于本质上与时间变化有关的概念：Agent 行为轨迹、前后变化、流程演进。

LinkedIn 上视频的触达率正在下降。仅当静态形式无法传达时间维度时才使用。

• html-video（使用 Hyperframes 渲染 HTML/CSS）——片头序列、并排对比、图表演示和字幕序列，均可编写为可编辑的 HTML。工具链配置完成后即可离线使用。
• animate（Manim/Python）——算法可视化、数学概念、技术步骤演示。支持无头运行。
• remotion-video（React/Node.js）——品牌动态视觉、产品演示、带音频同步和 TailwindCSS 样式的数据驱动视频。

明确指定的引擎优先于上述基于主题的建议：Hyperframes 或 HTML video 表示使用 html-video，Manim 表示使用 animate，React 或 Remotion 表示使用 remotion-video。指定引擎的请求仍属于有时间变化特征的主题视频，因此是否制作视频仍由时间变化主题限制决定。没有视频输出的纯 HTML 页面不属于视频请求。调用匹配的视频技能进行渲染。

轮播改编（五阶段 → 五张幻灯片）

使用第 1 级时，将五阶段结构对应到幻灯片：

幻灯片	阶段	视觉呈现
1	吸睛开场	将指标或事实设计成醒目的排版卡片。不使用图表。
2	图例	视觉解码器——图表键、方向、符号映射。
3	可信度亮点	使用 Mermaid 流程图呈现密集的技术流程。信息密度最大化。
4	观察	重新构建视角——从第 2–3 张幻灯片中突出一个元素，并添加注释。
5	意义	在干净的背景上使用简短有力的文字。不使用图表。留白即视觉。

长度

150–300 个单词。作者不会凑字数。如果内容有 120 个单词，那就写 120 个。

格式与互动背景

LinkedIn 不同格式的基准互动率：纯文本约 4%，文本+图片约 4.85%，文档／轮播约 6.6%。这些数据用于指导格式选择，而非衡量内容质量。写得好的文本帖子胜过平庸的轮播。

---

局限

• 专为一位特定作者的风格调优，不是通用的 LinkedIn 写作风格；若不重新训练风格模型，也无法迁移到其他作者。
• 仅适用于技术和开发者主题；无法处理商业、个人品牌或非技术类内容。
• 不会生成诱导互动、标题党或涨粉技巧，这些模式在设计上已被屏蔽。
• 实际生成的帖子为 150–200 词；若不进行结构拆分，就无法用这种风格创作长篇 LinkedIn 文章（1,000 词以上）。
• 轮播和文档帖子需要配套技能（md-to-pdf、concept-to-image）。基础技能只生成文本和帖子结构。
• 视频配套内容需要 html-video、animate 或 remotion-video，且仅限于具有时间维度的主题。所有配套内容均为可选项；基础文本工作流不会依赖任何配套内容。

---

参考示例

以下是作者实际发布的帖子。请根据写作风格进行模式匹配，而不只是遵循规则。

日期背景： 示例 1 和示例 2 撰写于 Opus 4.6 发布时（2026-03），并引用了该公告。这种写作技巧（开场钩子、可信度亮点、观察、意义）不依赖模型版本——将「Opus 4.6」替换为当前模型，即可将此模式应用于新的公告。

示例 1：Gource 可视化帖子

This is what 3,982 commits in 14 days looks like.

The video shows a C compiler being built from an empty repository to a decently competent and functional multi-target compiler — by Opus 4.6, working autonomously.

As usual, it doesn't bother about the bill it is running up.

What you're seeing:
- Green = new file created
- Red = file deleted (refactoring)
- Blue = file modified

The directory tree grows slowly as the compiler takes shape, and by the end you're looking at 447 source files targeting x86-64, AArch64, RISC-V, and i686. Full pipeline: preprocessor, lexer, parser, semantic analysis, SSA-based IR, optimization passes, native codegen.

The thing worth watching for is the red. The agent doesn't just accumulate code. It tears subsystems down and rebuilds them.

Quite remarkably there is no thrashing. The mistakes help the LLM to learn and the next iterations get better.

Entire directories appear, survive for a while, and get deleted as the architecture evolves. Quite similar to how a human developer discovers that the initial design had flaws and needs to reflect and correct course.

The agent just does it at machine speed.

Most agent demos show accumulation.
Files go up, nothing comes down.
This one shows iteration.

Rudra tandava — Creation, evaluation, demolition, reconstruction.

Fourteen days of work, with the willingness to throw things away.

That's the interesting part for me.

评论：

https://www.anthropic.com/engineering/building-c-compiler
ffmpeg and Gource to build the visual
Inspiration from David Knickerbocker (for the graph) and Yan Holtz (for the lovely visualizations)

示例 2：AI 编码工具分析帖子

Anthropic just announced Opus 4.6 and published a piece about it building a C compiler from scratch. I use Claude Code daily.

A C compiler is a solved problem. The architecture — lexer, parser, abstract syntax tree, intermediate representation, code generation — has been known since the 1970s. Every stage is documented in textbooks. The language specification is written down. Test suites exist to verify correctness.

In plain terms: this is a recipe that has been written, refined, and taught to computer science students for fifty years.

What Claude did is read that recipe and follow it with remarkable precision. That is genuinely hard for an AI to do. But it is not the same as inventing the recipe.

Think of a chess engine. It has opening books — every known opening sequence memorized. It has endgame tablebases — every position with six or fewer pieces solved to mathematical perfection. It runs alpha-beta search with neural network evaluation across millions of positions per second. It beats every human alive.

But it didn't figure out chess. Humans wrote the evaluation heuristics. Humans built the databases. Humans designed the search algorithms. The engine executes. It doesn't understand.

Nobody looks at Stockfish and says "we don't need chess coaches anymore." The coach understands why a position is interesting. The engine calculates what move is optimal. These are different things.

Here is what it's good at:

Implementing known patterns fast. Scaffolding boilerplate. Catching bugs against test suites. Translating a clear specification into working code. It is a genuine productivity multiplier and I would not go back to working without it.

Here is what it doesn't do:

Decide what to build. Recognize when a requirement is wrong. Make architectural tradeoffs with incomplete information. Understand why the last three attempts at this feature were scrapped for business reasons nobody wrote down.

Software development is not writing code. It is deciding what code to write and, more often, what code not to write.

AI coding tools are power tools. A nail gun is not a carpenter. But a carpenter with a nail gun is faster than one with a hammer.

Use them.
They're real and they're good.
Just don't confuse the nail gun with the person holding it.