Zed 品牌写作 Skill 深度解析:十条 Voice 转换范例与 [FACT] 事实保全机制

本文围绕 Zed 仓库中 .factory/skills/brand-writer/voice-examples.md 这一校准文档展开。它收录了 10 组“改写前/改写后”的 Zed 品牌文案转换范例、一套 [FACT] 事实保全规则和一张转换模式速查表,是 brand-writer Skill 在做文案诊断与重构时的核心参照。读完后你将掌握:如何用“事实标记 + 打分诊断 + 重构验证”的三段式流程产出技术可信的开发者文案,以及如何把这些方法论迁移到自己的写作与 AI 辅助工作流中。

一、voice-examples.md 在整个 brand-writer Skill 中的位置

Zed 仓库在 .factory/skills/ 下维护了一组面向 AI Agent 的写作技能。其中 brand-writer 技能由三个参考文件和一个主文件组成:

文件	职责
SKILL.md	技能主文件:定义 Zed 品牌语调(“thoughtful, technically grounded, and quietly confident”)、写作五原则、五阶段工作流和 Review 模式
rubric.md	8 项评分标准(每项 1–5 分),全部 4 分及以上才算通过
taboo-phrases.md	必须清除的 hype 词、AI 句式结构、空热情话术与禁用手写标点
voice-examples.md	本文主角:10 组 before/after 转换范例 + 事实保全规则,作为“诊断与重构”的校准基准

SKILL.md 的 Phase 2(Gather Context)明确要求自动加载这三个参考文件,而 Phase 3 的 Pass 3(Reconstruction)规定:凡是某项标准评分低于 4 或命中禁忌短语,就要“应用 voice-examples.md 中的转换模式”来重写。换句话说,voice-examples.md 不是示例合集,而是诊断规则的可执行映射表——每条转换范例都示范了“病灶 → 处方”的完整过程。

与之配合的还有 humanizer/SKILL.md:brand-writer 的 Phase 4 建议对高风险内容(主页、发布公告、产品页)再过一遍 humanizer 技能,扫描 24 种“AI 写作痕迹”模式并做终审。两个技能形成“品牌合规 + 去 AI 味”的双层质检。

二、单条转换范例的解剖:Before 带评分,After 带评分,Notes 给处方

每条范例都遵循同一个三段式结构:

1. Before(附单项失分):一段问题文案,标注它在某项 rubric 标准上的低分,例如 Score: 2/5 Technical Grounding;
2. After(附高分):重写后的文案,同一项标准得分 4–5;
3. Transformation notes:逐条列出“哪个词/哪个结构被替换成什么”,使转换过程可复现、可迁移。

这种结构的关键设计在于:它不只告诉你“这样写更好”,而是把改写动作拆解为最小单元(删掉哪个词、补上哪个机制、加上哪个快捷键),让 Agent 或人类写作者都能照着执行。下面按原文顺序完整梳理 10 条范例。

三、十条转换范例全解

1. Hype to Specifics(空泛吹嘘 → 可验证的具体指标)

Before(2/5 Technical Grounding):

Zed delivers blazingly fast performance that will revolutionize your coding experience. Our cutting-edge technology ensures you never wait again.

After(5/5):

Zed is written in Rust with GPU-accelerated rendering. Keystrokes register in under 8ms. Scrolling stays at 120fps even in large files.

转换要点:

• “blazingly fast” → 具体延迟数字;
• “revolutionize” → 整词删除;
• “cutting-edge technology” → 真实技术栈(Rust + GPU 渲染);
• “never wait again” → 可度量的陈述。

值得注意的是,这条 After 文案并非凭空杜撰。从仓库源码结构看,“written in Rust”与整个工作区一致——根目录 Cargo.toml 定义的 workspace 全部是 Rust crate;“GPU-accelerated rendering”则对应自研 UI 框架 GPUI,crates/gpui/README.md 开篇即描述其为 “a hybrid immediate and retained mode, GPU accelerated, UI framework”,并说明 macOS 上通过 Metal 渲染(Linux 侧另有 crates/gpui_wgpu 的 wgpu 实现)。“8ms 延迟、120fps”属于文案层的表述,仓库中未提供对应的基准测试数据,应理解为该范例示范“具体化”手法的样张数字,而非可从仓库复现的实测结论。

2. Marketing to Technical(哄小孩式营销 → 技术机制)

Before(2/5 Developer Respect):

Don't worry about the complicated stuff — Zed handles it all for you! Just focus on what you do best: writing amazing code.

After(5/5):

Zed runs language servers in separate processes with automatic crash recovery. If a language server fails, you keep editing while it restarts.

转换要点:

• 删除居高临下的口吻(“don't worry”);
• 删除过度热情词(“amazing”);
• 补上技术机制(独立进程 + 自动崩溃恢复);
• 把读者当作能理解细节的同行。

After 描述的语言服务器行为,在仓库中能找到对应实现层次:crates/lsp 提供 LSP 协议支持,crates/language 与 crates/language_core 承载语言/语法核心逻辑,语言服务器客户端的生命周期管理则位于 project 层(crates/project)。这正是范例要示范的“用机制代替安抚”的写法。

3. Abstract to Concrete(抽象口号 → 具体交互)

Before(2/5 Specificity):

Zed provides a seamless collaborative experience that brings your team together in powerful new ways.

After(5/5):

Share your workspace with cmd+shift+c. Collaborators see your cursor, selections, and edits in real time. Voice chat is built in — no separate call needed.

转换要点:

• “seamless” → 真实的 UX 流程;
• “powerful new ways” → 具体功能(光标、选区、编辑实时可见 + 内置语音);
• 增加键盘快捷键,给读者一个具体入口;
• 描述协作实际呈现的画面。

这里有一个值得注意的事实边界:范例中的 cmd+shift+c 是文案校准样张,不是当前仓库的权威键位。从源码结构看,当前的默认 keymap(assets/keymaps/default-macos.json、assets/keymaps/default-linux.json)中 cmd-shift-c / ctrl-shift-c 已映射到 collab_panel::ToggleFocus 等动作。这恰好呼应了该文档“事实保全”规则的精神:发布真实文案前,快捷键这类 FACT 必须对照 assets/keymaps 逐一核实。

4. Em Dash Chains to Natural Flow(破折号连环 → 自然句流)

Before(2/5 Natural Syntax):

Zed is fast — really fast — and built for the way developers actually work — not how tools think they should work.

After(5/5):

Zed is built for speed. We optimized for the workflows developers actually use: jumping between files, searching across projects, editing multiple cursors at once.

转换要点:

• 移除全部破折号(呼应 taboo-phrases.md 中“每段最多一个 em dash”的硬规则);
• 拆成两句清晰的话;
• 抽象断言 → 具体工作流举例(跨文件跳转、全项目搜索、多光标编辑);
• “really fast”直接删除——show, don't tell。

5. Enthusiasm to Confidence(情绪宣泄 → 平静自信)

Before(1/5 Quiet Confidence):

We're thrilled to announce Zed 1.0! After years of hard work, we can't wait for you to experience what we've built. You're going to love it!

After(5/5):

Zed 1.0 is available today. This release includes GPU text rendering, multi-buffer editing, and native collaboration. Download it at zed.dev.

转换要点:

• 删除全部情绪语言:“thrilled”“can't wait”“You're going to love it”全部清除;
• 用发布实质内容(三项具体能力 + 下载入口)替代情绪。

6. "It's Not X, It's Y" Fix(否定式排比 → 正向陈述)

Before(2/5 Natural Syntax):

Zed isn't just an editor — it's a complete development environment. It's not about features — it's about flow. And it's not slow — it's instant.

After(5/5):

Zed combines editing, debugging, collaboration, and AI assistance in one application. Everything runs in the same process, so switching between tasks has no context-switch overhead.

转换要点:

• 消除所有 “it's not X, it's Y” 结构;
• 用正向陈述替代否定式修辞;
• 补充技术理由(同一应用内完成切换,省去上下文切换成本);
• 三个碎片句合并为一个完整句。

该句式在 taboo-phrases.md 中被列为“AI 结构性模式”,并给出独立对照示例:❌ “It's not just an editor — it's a complete development environment.” → ✅ “Zed combines editing, collaboration, and AI assistance in one workspace.”

7. Vague Benefits to Specific Outcomes(模糊收益 → 具体交互结果)

Before(2/5 Specificity):

Zed's AI integration enhances your productivity and streamlines your workflow, helping you code smarter and ship faster.

After(5/5):

Zed runs AI completions inline as you type. Suggestions appear in 200ms. Accept with Tab, reject by continuing to type. The model runs locally or connects to your preferred API.

转换要点:

• “enhances productivity” → 具体 UX(内联补全、Tab 接受、继续输入即拒绝);
• “streamlines workflow” → 真实交互模型;
• “code smarter” 删除(无信息量);
• 补充技术选项(本地模型 vs API)。

仓库中 AI 补全能力的实现确实横跨多个 crate(如 crates/edit_prediction、crates/edit_prediction_ui),而“本地或 API 二选一”与 crates/language_models 下同时维护 cloud 与本地模型集成的源码结构相吻合。

8. Social Media Cleanup(社媒刷屏体 → 信息密度)

Before(1/5 across multiple criteria):

🚀 Big news! Zed just dropped MASSIVE updates! Multi-file editing, insane AI features, and SO much more. This is a game-changer, folks! Try it now! 🔥

After(4/5):

Zed 0.150: Multi-buffer editing is here. Edit across files in a single view. AI completions now stream inline. Full changelog at zed.dev/releases.

转换要点:

• 移除全部 emoji;
• 移除感叹号(对应禁忌规则“零感叹号”);
• “MASSIVE” → 具体功能列表;
• “game-changer” 删除;
• “SO much more” → 指向 changelog 的链接;
• 增加版本号以提升精度。

9. Feature Announcement(铺垫式官宣 → 结论先行)

Before(2/5 Information Priority):

We've been listening to your feedback, and after months of development, our incredible team has built something truly special. Today, we're excited to finally share our new terminal integration!

After(5/5):

Zed now includes a built-in terminal. Open it with `ctrl+``. Terminals run in splits alongside your editor panes and share the same working directory as your project.

转换要点:

• 新闻本身开头,而不是先讲开发故事;
• 删除情绪铺垫;
• 给出打开方式的快捷键;
• 描述真实行为(split 布局、共享工作目录)。

“结论先行”正对应 rubric.md 中 Information Priority 标准的 5 分定义:“Key fact or change leads; context follows naturally”。

10. Philosophy Statement(信仰宣言 → 可验证立场)

Before(3/5 Quiet Confidence):

At Zed, we believe that developers deserve better tools. We're passionate about creating the best possible coding experience because we know how frustrating slow, bloated editors can be.

After(5/5):

Developer tools should be fast, understandable, and collaborative. We built Zed to meet that standard. It's open source so you can verify our work and extend it.

转换要点:

• “We believe” → 直接陈述;
• “passionate about” 删除;
• “best possible” → 具体标准(快、可理解、可协作);
• “frustrating, slow, bloated” 的拉踩式对比删除;
• 增加具体论据:开源,可验证、可扩展。

开源这一点在仓库中有直接证据:根目录同时存在 LICENSE-APACHE 与 LICENSE-GPL,README.md 亦以 “Code at the speed of thought” 与 Atom/Tree-sitter 团队署名自述——即范例 After 中 “built by the team behind Atom and Tree-sitter” 这一归因的出处。

四、Fact Preservation Rules:[FACT] 标记与事实保全

十条范例解决的是“怎么写”,Fact Preservation Rules 解决的是“什么不能动”。改写会重排语言,但事实必须无损通过改写,文档给出了一套可机械执行的流程。

4.1 诊断阶段打 [FACT] 标记

在给文案做诊断(诊断 = 按 rubric 打分 + 定位病灶)时,先把所有事实性论断用 [FACT] 标签括起来:

Zed is written in [FACT: Rust] with [FACT: GPU-accelerated rendering].
It was built by [FACT: the team behind Atom and Tree-sitter].

这与 SKILL.md Pass 1 的要求一致:初稿阶段即标记技术规格、专有名词、版本号与日期、快捷键与 URL、归因与引用五类事实。

4.2 Never Change:八类永不改动的内容

类别	示例
技术规格	“120fps”“8ms latency”“Rust”
专有名词	“Tree-sitter”“Anthropic”“Claude”
版本号	“Zed 1.0”“v0.150”
键盘快捷键	“cmd+shift+c”“ctrl+`”
URL	“zed.dev/releases”
归因	“built by the team behind Atom”
日期	“available today”“released January 2024”
引用	任何具名引述

这张表划定了改写的操作边界:修辞可以重写,上表内容只能原样保留或整体移除,不允许“顺便”改写。

4.3 验证步骤:对 [FACT] 标记做 diff

重构完成后,将成稿与原始 [FACT] 标记逐条对照:

1. 列出原文中的全部事实;
2. 确认每条事实都出现在最终文案中;
3. 若某条事实被移除,必须说明理由(例如与新文段范围无关);
4. 若某条事实被改动,直接判为错误。

4.4 验证示例

带标记的原文:

Zed is [FACT: written in Rust] with [FACT: GPU-accelerated rendering at 120fps]. Built by [FACT: the team behind Atom and Tree-sitter].

重构结果:

Zed renders every frame on the GPU at 120fps. The Rust codebase prioritizes memory safety without garbage collection pauses. The same engineers who built Atom and Tree-sitter lead development.

验证结果:

• “Rust” 保留;
• “GPU-accelerated” 保留;
• “120fps” 保留;
• “team behind Atom and Tree-sitter” 保留;
• 判定:Pass。

示例还展示了一个微妙点:重构允许事实换一种“说法”(“written in Rust” → “The Rust codebase”),但标记的实体本身必须可追溯。这套“标记 → 改写 → diff 验证”的闭环,本质上把“不丢失事实”这个抽象要求变成了一次可执行的核对操作,对使用 LLM 批量改写文案的场景尤其有价值。

五、Transformation Patterns Summary:八类病灶与处方速查

文档末尾给出了一张模式级速查表,把十条范例抽象为可复用的映射规则:

问题(Problem)	处方(Solution)
Hype words(吹嘘词)	Replace with measurements(换成度量值)
Em dash chains(破折号连环)	Split into sentences(拆句)
"It's not X, it's Y"	State positively what it is(正向陈述)
Enthusiasm(空热情)	Delete; add substance(删除并补充实质内容)
Vague benefits(模糊收益)	Name specific features(点出具体功能)
Buried lede(导语埋没)	Lead with the news(新闻先行)
Rhetorical questions(设问开头)	Make declarative statements(改为陈述句)
Abstract claims(抽象断言)	Add mechanism or measurement(补机制或度量)

这张表与 taboo-phrases.md 的“Detection Checklist”互为表里:后者负责“检测”(哪些词、哪些标点、哪些结构触发扣分甚至一票否决,如出现感叹号或“We're excited/thrilled”直接 auto-fail),前者负责“处方”(检测出问题之后如何改写)。配合 rubric.md 的 8 项标准与“任何一项 4 分以下即重写”的决策规则,三者构成完整的“检测—评分—改写—复验”循环。

六、这套机制为什么值得借鉴

回到源码层面,这套文案流程与 Zed 的代码哲学是同构的:

• 可验证性优先。rubric.md 中 Earned Claims 标准要求“每个断言都能被演示或验证”,而 voice-examples 的范例文案大多锚定仓库中真实存在的技术事实——Rust 技术栈(Cargo.toml)、GPUI 的 GPU 渲染(crates/gpui/README.md)、多缓冲区与语言服务器架构(crates/lsp、crates/project)、开源双许可证(LICENSE-APACHE、LICENSE-GPL)。
• 把模糊要求变成可执行操作。“事实不能丢”通过 [FACT] 标记 + 4 步 diff 验证落地;“语气要平静”通过 8 项 1–5 分 rubric 与禁忌词表落地;“像人写的”通过 humanizer 技能的 24 模式扫描落地。
• 校准样本比规则清单更能迁移。10 条范例的价值不在结论,而在每条 Transformation notes 展示的“最小改写动作”。从源码结构看,这正是 brand-writer Skill 让 Agent 在重构阶段“照着做”而不是“悟着改”的原因。

对于维护开源项目或技术产品的团队,可以直接复用三层资产:一份带评分的 before/after 校准集(对应 voice-examples.md 的 10 条结构)、一张八类病灶处方表、以及一套 [FACT] 标记与验证流程。把项目真实的技术事实(构建语言、渲染管线、进程模型、快捷键、许可证)作为 FACT 素材注入,即可得到一套可机械执行、可回归检查的品牌写作工作流。