Stampli 把 243 小时发布工作压到 77 小时：真正值得学的不是“AI 帮市场部写稿”，而是把产品事实做成共享工作流
OpenAI 昨天公开了一个 Stampli 案例。
最容易被拿来做标题的数据是：
预计生产工作：
243 小时
使用 Codex + ChatGPT Work 后：
约 77 小时
减少：
约 68%
另外一个指标：
从原型到上线：
约 6 周
OpenAI 给出的整体速度提升是：
3.16× faster launch to production
这些数字都很好看。
但如果只把它理解成：
AI 帮市场部写得更快
我觉得低估了这个案例。
真正值得抄的是：Stampli 把产品上下文、会议纪要、决策和 Messaging Guidelines 连成了一个共享系统，再让 Codex 和 ChatGPT Work 从这套相对稳定的事实源里生产不同资产。
换句话说，它解决的不是单篇文案，而是发布项目里最烦人的一件事：
同一产品事实
如何在十几个渠道里保持一致
243 小时里不只是“写七篇文章”
Deep Finance 发布涉及：
7 篇系列 Blog
Launch Email
Webinar
Supporting Deck
Social Creative
Paid Creative
PR Release
产品网页
Sales Enablement
产品开发、定位、设计、传播、销售支持和运营都在并行。
设计资源和外部承包商当时又已经被其他优先级占用。
所以真正的工作量是：
同一套产品信息
被转换成不同渠道资产
并且必须一直同步
这是 Agent 很适合做的任务，因为里面有大量重复的上下文搬运、格式转换和一致性检查。
发布项目最痛苦的不是“写不出来”，而是事实漂移
产品经理下午改了一句话：
功能 A 不在首发范围
晚上你可能发现：
Blog 已经改了
Deck 没改
销售材料没改
Webinar 讲稿还写着
网页已经排期
这就是 Content Drift。
AI 真正有价值的地方，不是重新生成一篇文章，而是能追踪：
哪一个事实变了
哪些 Artifact 依赖它
哪些内容需要重新检查
我更愿意把发布系统画成一张 Artifact Graph
源头：
Product Decisions
Feature Scope
Pricing
Positioning
Approved Claims
Customer Proof
下游：
Blog
Email
Web
Deck
Sales
Social
PR
每个 Artifact 保存依赖关系。
例如：
{
"artifact": "launch-email-v8",
"depends_on": [
"feature-scope-v12",
"positioning-v6",
"pricing-v4"
]
}
当：
feature-scope-v13
发布以后，系统立即知道：
哪些内容需要重新评估
这比让 AI 每次重新读几十份文档可靠得多。
Marketing Agent 真正该治理的是 Claim，不是文风
公开内容最危险的问题通常不是：
写得不够漂亮
而是：
写了一个产品并不支持的能力
或者：
把内部计划写成已经上线
所以我会单独维护：
public enum ClaimStatus {
DRAFT,
VERIFIED,
APPROVED_FOR_EXTERNAL,
EXPIRED,
REVOKED
}
内容 Agent 只能引用：
APPROVED_FOR_EXTERNAL
的 Claim。
这比 Prompt 里一句：
请不要编造事实
强得多。
一个最小 Claim Registry
{
"claim_id": "deep-finance-real-time-analysis",
"status": "APPROVED_FOR_EXTERNAL",
"source": "product-spec-v18",
"owner": "product-marketing",
"expires_at": "2026-10-01"
}
产品事实变了以后：
撤销 Claim
下游所有依赖它的 Artifact 自动进入：
NEEDS_REVIEW
这才是生产内容系统。
ChatGPT Work + Codex 的价值，其实是“持续工作空间”
这个案例不是一次性 Prompt。
发布周期持续六周。
真正重要的是上下文可以持续存在：
会议纪要
产品决策
已有资产
修改历史
Messaging Guidelines
如果每次新建对话都要重新解释：
产品是谁
目标客户是谁
能说什么
不能说什么
品牌语气是什么
AI 节省的时间会很快被上下文准备吃掉。
所以复杂业务更需要：
Project Workspace
而不是单次 Chat。
OpenAI 还披露了一个很有意思的数据：每周数百件内容
Stampli 团队目前每周会用 ChatGPT Work 生产：
数百件内容
这个规模已经不是“偶尔用一下”。
当一个团队进入数百件/周，平台必须开始考虑：
Owner
版本
审批
重复
内容追踪
成本
产出越多，如果治理没跟上，管理负担反而会越大。
我会给内容 Artifact 建状态机
DRAFT
↓
AI_REVIEWED
↓
HUMAN_REVIEW
↓
APPROVED
↓
PUBLISHED
↓
SUPERSEDED
公开内容不允许模型直接：
DRAFT → PUBLISHED
OpenAI 的案例明确说，Stampli 对所有 customer-facing 内容仍保留完整人工 Review 和最终 Approval。
这个边界非常合理。
人工 Review 为什么不会把 68% 的效率全吃掉
因为：
从零生产
和：
审核
不是一个成本。
从零做需要：
- 收集资料；
- 搭结构；
- 写第一版；
- 变不同渠道；
- 统一表达；
- 修改格式；
- 检查事实。
Review 只需要重点看：
关键 Claim
产品判断
语气
风险
最终批准
如果 Agent 提前完成大量机械步骤，人只处理 Decision Density 高的节点，审核依然可以很快。
Decision Density 是我觉得 Work Agent 很重要的指标
可以粗略定义：
需要人真正判断的节点数
/
全部执行步骤
例如一个 Launch Deck 可能包含：
60 个编辑步骤
真正需要人的可能只有：
这个定位用不用
这个客户案例能不能公开
这个数字是否批准
封面选 A 还是 B
Agent 的目标不是消灭人。
而是把：
60 个机械动作
压缩成：
4 个关键决定
UI 也应该围绕“需要我决定什么”设计
而不是让人翻几十屏生成历史。
例如：
Pending Decisions
[1] Pricing claim
Source changed
Needs approval
[2] Customer quote
Legal approval missing
[3] Launch date
Product spec conflict
这比告诉用户：
Agent 已生成 17 个文件
更有价值。
内容 Eval 不能只用 LLM Judge
可以先用确定性检查：
所有数字都有 Source
所有 Claim 都已批准
产品名称一致
发布日期一致
URL 有效
Forbidden Term 不存在
再让 Judge 评：
清晰度
重复
叙事
风格
先规则，后语义。
一个很实用的 Gate：
release-content-gate:
verified-claims-only: true
all-numbers-have-source: true
product-name-consistent: true
launch-date-consistent: true
human-final-approval: required
68% 的时间节省不能直接理解成“68% 裁员”
243 小时到 77 小时，说明生产工作被大量压缩。
但这不代表：
原来三个人
以后只要一个人
更合理的结果是：
同一个团队
可以更快发布
做更多实验
有时间分析结果
把人力放到策略
OpenAI 的案例也明确强调：
making more room for strategy
这比简单讨论减少人力健康得多。
如果要复制 Stampli，我不会先买工具
第一步应该先整理：
Product Facts
Approved Claims
Positioning
Audience
Launch Scope
Brand Rules
如果这些源头本来就乱：
AI 只会更快地产生不一致
自动化的前提是：
你知道什么是真实源头
一个最小发布目录
launch/
├── source/
│ ├── product-facts.yaml
│ ├── claims.yaml
│ ├── positioning.md
│ └── messaging.md
├── artifacts/
│ ├── blog/
│ ├── email/
│ ├── web/
│ └── sales/
└── approvals/
每个 Artifact 都保存依赖 Manifest。
这样源头事实变化后，系统可以自动计算影响面。
Stampli 这个案例最有价值的地方，不是 AI 能写营销文案。
而是它把发布过程从：
很多人重复搬运上下文
变成：
共享上下文
→ 多 Artifact 生产
→ 人只处理关键审核和批准
243 小时压到约 77 小时，真正减少的是重复上下文搬运、重复制作和跨渠道同步。
所以如果企业想复制这种效率，最先要问的不是：
哪个模型文案最好？
而是：
我们的产品事实、Claim、决策和审批，能不能先变成一个 AI 可读取、可追踪的系统？
更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：
https://www.zyentor.com/