今天提到 Bard，很多人会先想到谷歌曾使用过的 AI 产品名称。但在 Claire Stapleton 的故事里，这个名字首先连接的不是模型、参数或对话框，而是一名在谷歌工作十二年、负责为组织书写和表达的人。
她 2007 年以传播助理身份加入谷歌，后来成为公司内部极有辨识度的声音。这个故事值得技术团队关注，因为它揭示了一个常被忽略的问题：当公司迅速扩张时，组织不仅需要代码、制度和会议，还需要有人把抽象价值观写成员工能够理解、质疑和记住的语言。
TGIF 不只是一场全员会议
谷歌每周五举行的员工大会叫 TGIF。按照来源摘要中的描述，拉里·佩奇和谢尔盖·布林会在台上回答员工问题，全球办公室同步参与，现场气氛混合了布道会、科技展示和单口喜剧。
从工程管理角度看，TGIF 的价值不只是“管理层定期露面”。它同时承担了几种功能：
- 让员工直接看到决策者如何解释公司方向；
- 让分散在不同办公室的人共享同一套组织叙事；
- 通过公开提问暴露管理层与一线员工之间的信息差；
- 用固定节奏建立一种可以预测的沟通机制。
这里最难复制的并不是每周五开会，而是会议中的信任。员工是否敢提出尖锐问题？问题是否会被筛掉？管理层给出的回答能否被内部引用和追踪？如果这些条件不存在，全员会很容易退化成一场制作精良的单向直播。
Claire 的作用也因此显得关键。她不是用代码构建产品，而是在帮助组织形成一套可以被共同理解的语言。技术公司经常把这类工作归入“软性事务”，但一次模糊的内部表达可能制造数周的猜测；一段准确、有人味的文字则能明确边界、承认矛盾，并告诉员工公司究竟准备做什么。
同一个名字，两种截然不同的“声音”
来源标题把 Claire 与后来被谷歌用于 AI 的 Bard 放在一起，这种对照本身就很有意味。
人的声音来自经历、关系和具体处境。它知道一次组织调整会落到哪些团队身上，也知道某句话在管理者和普通员工耳中可能产生完全不同的含义。AI 的声音则来自模型生成：它可以稳定、高速地组织语言，却不天然承担组织责任，也没有亲历公司内部事件。
因此，把生成式 AI 引入内部传播时，关键问题不应只是“它写得像不像人”，而应该包括：
- 谁为文字中的事实负责；
- 哪些敏感内容不能进入外部模型；
- AI 改写是否抹掉了原作者的异议和语气；
- 员工能否知道一段信息经过了机器生成或润色；
- 发布后由谁接收追问并推动行动。
AI 可以帮助整理会议纪要、压缩长文和生成多个版本，但它不能自动获得 Claire 那样的组织位置。辨识度并不来自华丽措辞，而来自长期参与、持续判断以及对所写内容承担后果。
可以这样实践：给内部传播建立可审计流程
下面是一个可复制改造的伪项目示例。它不是谷歌 TGIF 的真实配置，而是假设团队要为全员问答会建立一条包含 AI 辅助、人工审核和问题追踪的工作流。
将以下内容保存为 internal-comms.yaml，再按公司的岗位名称、数据分级和审批规则修改：
version: 1
meeting:
name: weekly-all-hands
cadence: weekly
question_submission:
anonymous_allowed: true
voting_enabled: true
rejection_requires_reason: true
content_policy:
data_classes_allowed_for_ai:
- public
- internal-non-sensitive
forbidden_for_external_ai:
- employee-personal-data
- unreleased-financial-data
- security-incidents
- legal-investigations
ai_assistance:
enabled: true
permitted_tasks:
- summarize-transcript
- group-duplicate-questions
- draft-language-variants
prohibited_tasks:
- invent-management-answers
- remove-critical-questions
- publish-without-review
disclosure_required: true
review:
fact_owner_required: true
human_editor_required: true
final_approver: communications-director
follow_up:
publish_unanswered_questions: true
assign_owner: true
due_days: 7
retain_decision_log_days: 365
这份配置的重点不是 YAML 本身，而是把容易停留在口头上的承诺变成检查项。团队可以在 CI 中验证关键规则，避免有人无意中关闭人工审核。下面的 Python 脚本可以直接运行；执行前安装 PyYAML：
python -m pip install pyyaml
python validate_comms.py internal-comms.yaml
validate_comms.py 内容如下：
import sys
from pathlib import Path
import yaml
def require(condition: bool, message: str) -> None:
if not condition:
raise ValueError(message)
def main(path: str) -> None:
config = yaml.safe_load(Path(path).read_text(encoding="utf-8"))
ai = config["ai_assistance"]
review = config["review"]
follow_up = config["follow_up"]
require(review["human_editor_required"], "AI 内容必须经过人工编辑")
require(review["fact_owner_required"], "每次发布必须指定事实负责人")
require(ai["disclosure_required"], "必须披露 AI 辅助使用情况")
require("publish-without-review" in ai["prohibited_tasks"],
"必须明确禁止 AI 未经审核直接发布")
require(follow_up["publish_unanswered_questions"],
"未回答的问题必须进入公开追踪列表")
print("internal communication policy: OK")
if __name__ == "__main__":
if len(sys.argv) != 2:
raise SystemExit("usage: python validate_comms.py internal-comms.yaml")
main(sys.argv[1])
这种机制不会自动创造信任，但能防止团队把“有人会审核”“之后会回答”当成没有负责人的口头约定。
引入 AI 之前，先决定谁来承担声音的后果
Claire Stapleton 的经历提醒技术团队，组织声音不是一个可以随时替换的文案接口。它由长期关系、编辑判断、公开提问和责任机制共同构成。
准备在内部传播中使用 AI 时，可以先检查四件事：敏感数据是否分级，事实是否有明确负责人，机器参与是否可见，未回答的问题是否能够继续追踪。效率指标也不应只看生成速度，还要观察纠错次数、员工追问、承诺完成率和问题被拒绝的原因。
Bard 可以成为一个产品名，也可以让人想起语言、叙事和表达本身。但一家公司的真实声音，最终不取决于它采用了哪个模型，而取决于它允许谁说话、愿意回答什么，以及谁会为这些回答负责。