Zed brand-writer 品牌语调评分细则详解：八维度 1–5 分锚定与自动把关机制

本文以 Zed 仓库中的 rubric.md 为主体，拆解这份品牌语调评分细则的完整设计：8 个评分维度各自的 5 级锚定描述、32/40 的通过门槛、分级决策规则，以及它与 SKILL.md 工作流、taboo-phrases.md 红线清单和 voice-examples.md 改写样例库如何协同工作。读完之后，你可以理解并复用一套"可打分、可复现、可机器执行"的文案质量评估方法。

一、细则的来龙去脉：brand-writer 技能的核心评分尺

rubric.md 位于 .factory/skills/brand-writer/ 目录，与以下三个文件共同组成 Zed 的品牌写作技能：

文件	角色
SKILL.md	技能入口，定义核心语调、五大消息、写作原则与五阶段工作流
rubric.md	8 项评分标准（本文主题），用于验证
taboo-phrases.md	硬性红线：AI 腔、营销腔词表与句式
voice-examples.md	10 组 before/after 改写样例与事实保留规则

SKILL.md 在 Phase 2（Gather Context）中明确把三者列为"从技能文件夹自动加载的参考文件"，其中对 rubric 的定位是"8 scoring criteria for validation"（8 项用于验证的评分标准）。也就是说，rubric 回答"这份文案得几分、过不过关"，红线清单回答"哪些出现即判死"，样例库回答"不及格的部分该怎么改"。

技能 front matter 中对该技能的自我描述是"Write clear, developer-first copy for Zed — leading with facts, grounded in craft"，rubric 的 8 个维度正是这一描述的量化展开。

二、总则：双门槛通过机制

rubric 开篇即给出全局规则（rubric.md#L1-L3）：

Score each criterion 1-5. Copy must score 4+ on ALL criteria to pass.

即每个维度独立打 1–5 分，且所有维度都必须达到 4 分或更高才算通过。结合文末的评分模板（rubric.md#L153-L169），完整规则是：

• 总分上限 8 × 5 = 40 分；
• 模板标注 "Pass threshold: 32/40 (all criteria 4+)"，即 32 分是"每项至少 4 分"这一条件的自然下限；
• 两个条件同时成立才通过：单项不低于 4 分 且 总分不低于 32/40。

从这套设计可以推断，Zed 有意用"最弱维度决定生死"来防止"高分平均、短板明显"的文案蒙混过关。例如某文案 7 项得 5 分、1 项得 3 分，总分 38/40 也依然不及格。这一"单项否决"逻辑在决策规则（见第四节）中进一步落地为分级处置。

三、八项评分维度：锚定描述与示例

rubric 对每个维度都给出一个判定问题、一张 1–5 分五级锚定表，部分维度还配了正/反例。以下按原文顺序完整介绍。

3.1 Technical Grounding（技术落地性）

判定问题："Does the copy make specific, verifiable technical claims?"（文案是否做出具体、可验证的技术声明？）

分数	锚定描述
5	Precise technical details that can be verified（specs, architecture, measurable outcomes）
4	Concrete technical claims with clear meaning
3	Mix of specific and vague technical references
2	Mostly abstract with occasional technical terms
1	No technical substance; pure marketing language

原文示例：✅ "Written in Rust with GPU-accelerated rendering at 120fps"；❌ "Blazingly fast performance that will transform your workflow"。这一维度考察的是声明是否"可被仓库证据或规格书验证"，与 Zed 本身的实现（Rust 编写、GPU 渲染管线，见 crates/gpui_wgpu 等渲染相关 crate 的目录结构）所对应的技术叙事一脉相承。

3.2 Natural Syntax（自然语序）

判定问题："Does the writing flow like natural speech from a thoughtful developer?"

分数	锚定描述
5	Varied sentence structure, natural rhythm, reads aloud smoothly
4	Mostly natural with minor rhythm issues
3	Some AI patterns visible but not dominant
2	Obvious structural patterns (parallel triplets, em dash chains)
1	Robotic cadence, formulaic construction throughout

该维度附带的红旗信号（Red flags）："Em dash overuse, 'It's not X, it's Y' constructions, triple parallel lists, sentences all same length"——四项红旗与 taboo-phrases.md 中 "AI Structural Patterns" 一节逐条对应，形成"评分维度定调、红线清单兜底"的分工。

3.3 Quiet Confidence（克制的自信）

判定问题："Does the copy state facts without hype or emotional manipulation?"

分数	锚定描述
5	Facts speak for themselves; reader draws own conclusions
4	Confident statements with minimal flourish
3	Some restraint but occasional hype creeps in
2	Frequent superlatives or emotional appeals
1	Aggressive marketing tone, telling reader how to feel

原文示例：✅ "Zed renders every frame on the GPU. You'll notice the difference when you scroll."；❌ "Experience the revolutionary speed that will absolutely transform how you code!"。5 分档的关键词是"让读者自己得出结论"，这与 SKILL.md 中"Never try to sell... let readers draw their own conclusions"的核心语调表述完全一致。

3.4 Developer Respect（对开发者的尊重）

判定问题："Does the copy treat the reader as a peer, not a prospect?"

分数	锚定描述
5	Peer-to-peer conversation; assumes technical competence
4	Respectful with appropriate technical depth
3	Slightly patronizing or oversimplified
2	Condescending explanations or forced enthusiasm
1	Treats reader as uninformed consumer to be persuaded

原文示例：✅ "Tree-sitter provides incremental parsing, so syntax highlighting updates as you type."；❌ "Don't worry about the technical details — just know it's fast!"。5 分档要求"假设读者具备技术能力"，把读者当同侪而非待说服的消费者。

3.5 Information Priority（信息优先级）

判定问题："Is the most important information first?"

分数	锚定描述
5	Key fact or change leads; context follows naturally
4	Important info near top with minor preamble
3	Buried lede but recoverable
2	Significant buildup before substance
1	Key information buried or missing entirely

原文示例：✅ "Inline completions now stream token-by-token. Previously, you waited for the full response."；❌ "We've been thinking a lot about the developer experience, and after months of work, we're thrilled to share that..."。该维度对应 SKILL.md 写作原则第一条"Most important information first"。

3.6 Specificity（具体性）

判定问题："Are claims concrete and measurable?"

分数	锚定描述
5	Every claim is specific and verifiable
4	Mostly specific with rare abstractions
3	Mix of concrete and vague claims
2	Mostly abstract benefits
1	All claims are vague or unverifiable

原文示例：✅ "Startup time under 100ms on M1 Macs"；❌ "Lightning-fast startup that respects your time"。注意 5 分档措辞为"Every claim is specific and verifiable"——对每个声明都要求具体且可验证，标准最严。

3.7 Voice Consistency（语调一致性）

判定问题："Does the tone remain unified throughout?"

分数	锚定描述
5	Single coherent voice from start to finish
4	Minor tonal shifts that don't distract
3	Noticeable drift between sections
2	Multiple competing voices
1	Jarring tonal inconsistency

该维度附带的检查项（Check for）："Shifts between casual/formal, technical/marketing, confident/hedging"，即重点排查三种语调漂移：随意/正式之间、技术/营销之间、自信/含糊之间。

3.8 Earned Claims（声明的可挣得性）

判定问题："Are assertions supported or supportable?"

分数	锚定描述
5	Every claim can be demonstrated or verified
4	Claims are reasonable and mostly verifiable
3	Some unsupported assertions
2	Multiple unverifiable superlatives
1	Bold claims with no backing

原文示例：✅ "Built by the team behind Atom and Tree-sitter"；❌ "The most advanced editor ever created"。"Earned"（挣得的）是关键词：声明必须能够被演示或验证，而不是凭空断言。这个维度与 voice-examples.md 中 [FACT] 事实标记机制（见第六节）直接配套。

四、快速评分模板与决策规则

4.1 Quick Scoring Template

rubric 提供了固定的评分表模板（rubric.md#L153-L169），要求评估者把每项分数与备注都填入表中：

| Criterion           | Score | Notes |
|---------------------|-------|-------|
| Technical Grounding |   /5  |       |
| Natural Syntax      |   /5  |       |
| Quiet Confidence    |   /5  |       |
| Developer Respect   |   /5  |       |
| Information Priority|   /5  |       |
| Specificity         |   /5  |       |
| Voice Consistency   |   /5  |       |
| Earned Claims       |   /5  |       |
| **TOTAL**           |  /40  |       |

Pass threshold: 32/40 (all criteria 4+)

Notes 列的强制存在值得注意：只打分不留理由的评估不被这套模板认可，这保证每次评分产出可追溯的诊断记录。

4.2 Decision Rules

rubric 末尾给出四条分级处置规则（rubric.md#L173-L178）：

• All 4+： Copy passes. Minor polish optional.（全部达标即通过，润色可选）
• Any 3： Rewrite flagged sections, re-score.（任一项 3 分：重写被标记的段落并复评）
• Any 2 or below： Full reconstruction required.（任一项 2 分或更低：整篇重构）
• Multiple failures： Start fresh with new approach.（多项不合格：换思路推倒重来）

这四条规则把"分数"直接映射为"动作"：3 分对应局部手术，2 分对应整体重构，多项失败对应策略性重做。评估结果不需要额外解释就能驱动下一步工作。

五、rubric 在工作流中的落点：诊断、重构与验收

rubric 不是孤立存在的评分表，SKILL.md 的五阶段工作流在三个节点上直接消费它：

5.1 Pass 2: Diagnosis（诊断）

SKILL.md 要求在初稿完成后"Score the draft against all 8 rubric criteria"，产出与 rubric 模板同构的诊断表（Criterion / Score / Issues 三列），并同时扫描 taboo phrases、按行号标记每一处。也就是说，rubric 的 8 维表格被逐字复用为诊断输出格式。

5.2 Pass 3: Reconstruction（重构）

重构的触发条件由 rubric 阈值直接决定（SKILL.md#L154-L163）："For any criterion scoring <4 or any taboo phrase found"——任一项低于 4 分或命中红线即触发。流程是：定位具体问题、重写被标记段落、核对 [FACT] 标记是否存活、对重写段落复评，"Repeat until all criteria score 4+"。这与 rubric 的决策规则"Any 3: rewrite flagged sections, re-score"完全同构。

5.3 Phase 5: Validation（验收）

最终交付物必须附完整 scorecard（SKILL.md#L182-L211），示例中给出 37/40 的总评、"✅ All criteria 4+ / ✅ Zero taboo phrases / ✅ All facts preserved"三项通过条件，以及逐项核对的 "Facts Verified" 清单（如 - [FACT: Rust] ✓）。"All criteria 4+" 这一验收语正是 rubric 总则原文的复述。

此外，SKILL.md 的 Review 模式（/brand-writer --review "paste copy"）把整套机制反向开放为审查工具：加载参考文件、对既有文案按 8 维打分、列出带行号的 taboo 命中、输出 "Verdict: ❌ Does not pass (3 criteria below threshold)" 式结论，并在任一维度低于 4 分时提供基于 voice-examples.md 改写模式的重写建议。

对于高权重内容（首页、发布公告、产品页），SKILL.md 还建议追加 Phase 4：把通过 rubric 的草稿再送进同仓库的 humanizer 技能，按 Wikipedia 的 "Signs of AI writing" 指南扫描 24 种 AI 写作模式——因为 rubric 管的是"品牌维度是否达标"，而 humanizer 专门捕捉残存的 AI 痕迹，两者互补。

六、三件套的分工：软分数、硬红线与事实保留

理解 rubric 的关键，是看清它与另外两个文件的边界：

1. rubric.md（软分数）：8 个维度、1–5 分锚定，处理"程度问题"。比如 em dash 用得"不算主导"是 3 分而非直接判死，留给重构流程修正。
2. taboo-phrases.md（硬红线）：taboo-phrases.md#L180-L195 的 "Quick Reference" 定义了即时否决项（instant red flags, auto-fail）：任何感叹号、"We're excited/thrilled"、"Revolutionary/game-changing"、单段 2 个以上 em dash、"It's not X, it's Y" 句式。红线与分数是两套独立判据——即使 8 维全 5 分，命中红线同样不能交付。
3. voice-examples.md（改写参照）：10 组带打分的 before/after 样例（如 "Hype to Specifics"、"Em Dash Chains to Natural Flow"）作为诊断与重构的校准基准，并规定 [FACT] 标记的事实保留规则：技术规格、专有名词、版本号、快捷键、URL、来源归属、日期、引语"Never Change"，重构后必须与原稿 [FACT] 清单做 diff 核对。

这套"分数定程度、红线定生死、样例定改法、FACT 定底线"的组合，与 rubric 中 Earned Claims、Specificity 两个维度形成闭环：声明要可验证（rubric），验证载体就是 [FACT] 标记（voice-examples + SKILL 验收清单）。

七、设计要点与可复用性

从 rubric.md 的实现结构看，有四点做法值得在做品牌/内容质量把关的团队中参考：

• 锚定描述而非形容词：每个维度的 1–5 分各配一条可观察的行为描述（如 5 分 = "Every claim is specific and verifiable"，1 分 = "All claims are vague or unverifiable"），使不同评估者在同一稿上的分歧被压缩到最低。
• 维度覆盖三类问题：内容层（Technical Grounding、Specificity、Earned Claims、Information Priority）、风格层（Natural Syntax、Voice Consistency）、态度层（Quiet Confidence、Developer Respect）。三者缺任何一类，"像人话"或"讲事实"就无法独立度量。
• 双门槛 + 分级处置："全部 4+ 且 32/40"配合 3 分局部重写、2 分整体重构、多项失败换思路的决策表，让评分直接产出动作，而不是停留在一张分数表上。
• 软分数与硬红线分离：把"程度不足"（可修）和"性质错误"（一票否决）放进两个文件，避免红线混入量表后被平均化稀释。

需要说明的适用前提：这份 rubric 是为 Zed 的品牌语调定制的——其 8 个维度的定义隐含了 Zed 的价值观（事实优先、开发者同侪、克制自信，见 SKILL.md 的 Core Voice 一节）。如果要迁移到别的品牌，应当保留其表格结构与门槛机制，但把每个维度的判定问题和锚定描述替换为该品牌自己的标准，而不是照抄维度名称。

八、快速核对清单

最后用 rubric 自身的逻辑做一个"元自检"，读者评估任何一份品牌文案（包括本文所在的仓库文档）时可直接套用：

1. 逐维打 1–5 分并填写 Notes，合计不得超过 40 分；
2. 检查是否所有维度 ≥ 4 且总分 ≥ 32，任一不满足即不通过；
3. 对照 taboo-phrases.md 的 auto-fail 清单逐行扫描，按行号记录命中；
4. 3 分项做段落级重写并复评，2 分项整体重构，多项失败换方案重来；
5. 用 [FACT] 标记核对所有事实声明在重写后仍然存活。

以上步骤均可在 rubric.md、SKILL.md、taboo-phrases.md 与 voice-examples.md 四个文件中找到原文依据，无需任何外部资料。