draft-in-voice

draft-in-voice — 基于记忆的代笔

**约定：**参见 conventions/brain-first.md — 语气档案和所有实质内容都来自 brain，绝不来自记忆 或即兴发挥。

**约定：**参见 conventions/quality.md，了解 引用和反向链接规则；另请参见 _brain-filing-rules.md — 语气档案是以人物为主题的页面，应归档在 people/ 下。

这是什么

以特定人物的口吻，高度忠实地代笔。语气塑造工作在上游完成：brain 中已经有经过验证的语气档案，位于 people/<slug>-voice（例如 people/alice-example-voice），而此技能是对该档案进行严格的应用。绝不要凭记忆或即兴发挥所谓的“创始人口吻”或“他们的口吻”——始终加载档案并遵守其中的硬性规则。

如果不存在经过验证的档案，就停止起草——请参见下文的创建语气档案。捏造一种口吻，还不如先问清楚。

**用户本人的口吻属于特殊情况。**如果代笔对象是用户本人，并且 harness 提供了专门的个人语气技能（带有自己的语域调整和反 AI 模式），优先使用该技能。对于其他任何拥有经过验证档案的人——同事、创始人、合作伙伴，以及用户代笔的对象——使用 draft-in-voice；如果没有专门技能，也可用于用户本人。

事实来源（每次都要先阅读）

1. 经过验证的语气档案 — gbrain get people/<slug>-voice。其中包含语气特征、量化统计数据（中位长度、措辞、节奏），以及“如何以此人口吻写作”的指示部分。**必须遵守。**如果页面缺失，或其 status 不是 validated，就停止起草并转到构建器附录。
2. 一手背景信息 — 对象的主页面（gbrain get people/<slug>），以及时间线和反向链接（gbrain timeline <slug>、 gbrain backlinks people/<slug>）：了解他们如何实际描述自己的工作、他们的起源历程和表达风格。用这些信息确定实质内容，确保内容符合他们的思考方式，而不只是听起来像他们。
3. （可选）特定主题页面 — 如果草稿涉及特定想法或公司，获取相关页面（gbrain search "<topic>"，然后执行 gbrain get <slug>），确保每项说法都准确，而非凭空编造。

硬性规则（从档案中读取）

优秀的语气档案会记录此人的不可妥协事项。遵守档案中列出的所有要求。需要提取并遵守的六个常见类别：

1. **避免使用的特征。**大多数档案都会指出最容易露馅的特征（通常是 em-dashes、惯用开场白或标点习惯）。草稿一旦触犯指定特征，就必然不合格。
2. **长度控制。**与档案中的中位长度一致。简短帖子只表达一个想法。删减。
3. **选定语域，不要混搭。**大多数人都有随意语域和陈述式／技术语域，各有不同规则（大小写、emoji、俚语、行话）。每篇草稿只选一个，绝不混搭——同一行里同时出现 emoji 和企业行话，会显得虚假。
4. **标志性表达方式。**档案会列出此人有代表性的句式——请使用。
5. **禁止使用的套话。**档案禁止的内容（hashtags、“excited to announce”、“1/n”串帖、特定流行语）一律不得出现。
6. **让表达内容体现其世界观。**实质内容应反映他们看待事物的真实方式。

流程

1. 确认对象 + 加载 people/<slug>-voice 以及 brain 中的一手资料。没有经过验证的档案 → 停止起草，并提出先创建档案（见下方附录）；不要伪造。
2. 明确语域 + 意图：如有歧义，用一句话确认：随意（聊天风格）还是陈述式（发布/技术风格）？回复默认采用随意风格，公告默认采用陈述式风格。
3. 起草 2-3 个选项，不要只给一个。每个选项都要简洁。变化的是切入角度，而不是口吻。
4. 运行口吻自检（见下文）。展示草稿前修正所有不合格之处。
5. 展示选项 + 自检结论。 仅起草——是否发布或发送由人决定，并须经过常规的审批流程。这是 Agent 必须遵守的约束，而非机械保证：绝不要把草稿直接接入发送流程。

口吻自检（展示任何草稿前运行）

根据已加载的档案评估每份草稿；修正不合格项，不要提交：

• 标志性特征检查： 档案中排名第一的标志性特征没有出现（若出现则自动不合格）。
• 长度： 符合档案规定的范围，最好接近中位数。表达一个想法。
• 语域纯粹： 只用一种语域，不要混用。
• 没有禁用的套话： 不包含档案明确禁用的内容。
• 听起来像本人，而非泛泛而谈： 放在本人真实发布的两条内容之间，读起来是否自然？如不确定，从档案来源说明中引用的语料库里找出 3 条相邻的真实样本，对比节奏。
• 内容属实： 每项事实陈述都能追溯到 brain 中的真实页面或一手事实——绝不编造指标、客户或具体信息。除非当事人已公开透露，否则私人细节必须保密。

口吻档案内容不足或缺失时

不要自行发挥。应当：

• 先创建档案（见下方附录），或
• 告知用户档案缺失或内容不足，并请其提供真实样本作为依据。

拒绝在缺少记忆的情况下起草，正是此技能的核心：将以 brain 为先的原则应用于口吻。

创建口吻档案

此技能的构建部分。当缺少档案或档案未经验证导致起草被硬性拦截时，或者用户要求“创建口吻档案”时，运行此流程。

步骤 0 — 同意

确认用户获准代此人代笔，并记录授权者及授权范围（例如“推文和发布文案，不包括电子邮件”）。将同意记录在档案页面中（见下方架构）。未记录同意 → 与缺少档案时停止起草的处理方式相同，停止创建档案。

步骤 1 — 收集语料（门槛：20+ 个样本，跨度 6+ 个月）

• 仅限一手写作内容。 当事人发布的内容、文章、本人撰写的电子邮件、本人发表的演讲。绝不要使用第三方描述、媒体报道或转述——这些反映的是声誉，而非口吻。
• 最低要求：跨越 6+ 个月的 20+ 个样本。 样本太少容易过度拟合某种情绪；时间跨度太短则无法体现语域变化。未达到要求时，档案只能保存为 status: draft——这并不能解锁起草功能。
• 覆盖目标格式。 如果用户会要求撰写推文，至少 5 个样本必须是短帖；发布文案则至少需要几个陈述式语域的样本。
• 在请求上传前，先检查 brain 中已有的内容：gbrain search "<person name>"、gbrain backlinks people/<slug>，以及任何 media/ 档案。先通过常规摄取技能摄取新样本，这样档案的来源说明才能指向真实页面。

步骤 2 — 提取语言特征（架构对应六条硬性规则）

分析语料并填充全部六个类别——每个类别都会成为资料页中的一个章节：

语言特征字段	提取内容
tells_to_avoid	最明显的破绽及其他破绽：标点习惯、套话式开场、从不使用的句式。
length	按格式（推文、回复、帖子、电子邮件）统计实际字数得出的中位数和区间，而非凭感觉估算。
registers	每种不同语体（随意／声明式／技术性）及其各自规则：大小写、表情符号、俚语、术语。
signature_moves	有特色的句式、开场方式、节奏、反复出现的说法。
banned_boilerplate	有证据表明对方绝不会使用的所有内容：标签、“excited to announce”、线程编号、流行语。
worldview	对方如何看待自己的领域——立场、反复阐述的主张、关注重点。引用脑页。

步骤 3 — 编写资料页

将文件保存至 people/<slug>-voice（按照 _brain-filing-rules.md 的人物主题页规则），并通过 gbrain put people/<slug>-voice 从标准输入传入页面内容。页面顶部必须包含以下元数据块：

# Alice Example — Voice Profile

```yaml
subject: people/alice-example
status: draft            # draft | validated | stale — only `validated` unlocks drafting
profile_version: 1       # bump on every rebuild; prior versions via `gbrain history`
built_at: 2026-08-11
validated_at: null
validated_by: null
consent:
  granted_by: the user
  granted_at: 2026-08-11
  scope: "tweets + launch copy"
provenance:
  corpus_size: 26
  corpus_span: "2026-01 to 2026-08"
  sources:
    - media/x/alice-example/
    - writing/acme-example-launch-draft.md
```

## Fingerprint
### 1. Tells to avoid
### 2. Length discipline
### 3. Registers
### 4. Signature moves
### 5. Banned boilerplate
### 6. Worldview to channel

## How to write as this person
(the binding directive block the drafting half reads)

在主题人物的主页上反向链接此资料页（使用 gbrain link people/alice-example people/alice-example-voice --link-type has-voice-profile 或相应界面中的 add_link 操作）。

步骤 4 — 验证（盲测）

只有通过盲测的资料页才能标记为 status: validated：

1. 留出 5 个未用于提取语言特征的真实样本。
2. 根据资料页撰写 3 段测试文本，并与留出的真实样本混在一起。
3. 向用户（或主题人物）展示这组混合文本。如果测试文本无法被一眼识别出来，则设置 status: validated、validated_at、validated_by，且不进行任何递增。如果测试文本被识别出来，则记录暴露问题的破绽，完善语言特征，然后重复测试。

维护

• **过时：**如果最新的语料样本距今超过约 12 个月，或者此人的公开表达风格明显发生变化，则将状态标记为 status: stale 并刷新资料页——过时资料页与缺失资料页一样，都会阻止起草。
• **版本控制：**每次重建都要递增 profile_version 并重新进行盲测。gbrain history people/<slug>-voice 是审计记录。

契约

此技能保证：

• 路由与 frontmatter 中的规范触发条件相匹配。
• 如果 people/<slug>-voice 中没有 status: validated 的语言风格资料页，绝不会继续起草；资料页缺失、处于草稿状态或已过时，都会立即停止并转入构建器。
• 每次请求提供 2-3 个起草选项，展示前均经过语言风格自检。
• 输出仅包含草稿——发布／发送仍由人工通过需审批的流程决定。
• 此技能唯一执行的脑库写入，是按照 writes_to: 的要求，在 people/ 下创建语言风格资料页（及其反向链接）。
• 保留隐私约定：示例中不出现真实姓名，不包含特定分支的文件系统路径字面量，不引用上游分支；草稿绝不泄露主题人物尚未公开的私人信息。

输出格式

**起草模式：**提供 2-3 个带标签的选项，每个选项注明语体和长度，之后附上该选项的自检结论（通过，或说明已修正的内容）。不发布、不发送，也不写入脑库。

Option A (casual, 92 chars): ...
Option B (casual, 140 chars): ...
Option C (statement, 210 chars): ...

Self-check: A pass · B pass (trimmed to band) · C pass

**构建器模式：**提供符合上述架构的 people/<slug>-voice 页面（元数据块 + 六个语言特征章节 + 指令块），并附上一行语料规模、时间跨度和验证状态报告。

发生错误时

遇到任何 gbrain 错误 code、退出代码、[AGENT] 块或 notice 块时，请遵循Agent 操作员协议。本技能的具体处理方式如下：

• 语音档案中没有记录同意，或 status: draft：本技能按设计会拒绝起草。请询问用户确认是谁授权代笔，以及授权范围是什么。
• 档案页面返回 page_not_found，或语料库搜索结果为空且带有降级 notice：不要依据通用知识起草；请告知用户语音记忆缺失，或搜索仅基于关键词。
• 保存档案时返回 revision_conflict：重新读取并合并；档案具有约束力，因此切勿基于旧版本覆盖。

反模式

• 凭记忆随手模仿语气。 没有经过验证的档案 → 不起草。绝不例外。
• 把 draft/stale 档案视为足够可靠。 只有 validated 才允许起草。
• 混用语域。 每篇草稿只用一种语域；混用会显得虚假。
• 虚构内容。 不得编造指标、客户或具体信息——每项说法都必须能追溯到大脑页面。
• 自动发布。 将草稿接入发送／发布流程，会绕过确保代笔安全的人工审核环节。
• 根据他人撰写的、关于该人物的文字来建立其风格指纹。 语料库只能包含第一方内容。
• 跳过同意。 未记录授权就进行代笔，是冒充，而非协助。
• 只提供一篇草稿，而不是 2-3 篇。 只有一个选项会让用户无法权衡语气与切入角度。

去重（明确界限）

• voice-note-ingest（skills/voice-note-ingest/SKILL.md）——将用户的音频摄取到大脑页面中，并保留原话；它捕捉的是作为内容的声音。draft-in-voice 则根据档案，以某个人的文字语气创作新内容。两者唯一的交集就是“声音”一词。若要将语音备忘录改写成帖子，应先通过 voice-note-ingest 捕捉内容，再通过 draft-in-voice 按对应语域改写。
• reports／briefing（skills/reports/SKILL.md、skills/briefing/SKILL.md）——生成以 Agent 语气撰写的大脑内容摘要。draft-in-voice 则生成供人类以自己名义发布的个人语气内容。如果没有模仿任何人的风格指纹，就不属于本技能的范围。
• Harness 级的人性化处理技能——去除任何文本中通用的 AI 痕迹。draft-in-voice 针对的是经过验证的档案中某个特定人物的风格指纹；没有指定对象、只要求“让这段文字听起来不那么像 AI”的情况不属于本技能的范围。
• media-ingest（skills/media-ingest/SKILL.md）——为构建者附录收集语料时，应通过常规摄取技能处理；本技能读取处理后的页面，不负责批量摄取。