产品发布最棘手的阶段，往往不是写出核心功能，而是在固定期限内完成页面、文案、代码、校验和交付物的最后一公里。Stampli 面临的约束很具体：发布日期已经确定，设计资源又投入到其他工作中。团队借助 Codex 和 ChatGPT Work，把原本需要数周的发布生产压缩到数天。
这个案例的价值不只是“AI 写得更快”。更关键的变化是，团队把发布工作拆成可并行、可验证、可追踪的任务，让 AI 承担高频生产环节，人继续掌握产品判断和最终验收。
真正被压缩的是任务等待时间
传统发布流程经常形成串行队列：需求确认后等设计，设计完成后等前端，页面可用后再写文案，最后才集中检查链接、埋点和响应式表现。每次交接都会产生等待和返工。
Codex 与 ChatGPT Work 可以改变这条队列的形状。例如，在产品负责人明确目标、受众和边界后，团队可以同时推进：
- 将需求说明拆成页面、组件和内容任务；
- 根据现有代码库实现页面结构或交互；
- 起草标题、正文、FAQ 和发布说明；
- 生成测试清单，检查占位符、链接和关键状态；
- 汇总修改记录，帮助负责人快速审阅差异。
这并不意味着 AI 替代设计师或工程师。案例中的关键约束恰恰是设计资源已经被占用，因此 AI 更适合填补生产能力缺口：沿用既有品牌规则和组件体系完成组装，再由人判断结果是否准确、清晰并且可以上线。
从“聊天”升级为有边界的发布工作流
如果只给模型一句“做一个发布页面”，输出很容易偏离现有产品。更稳定的方式是把仓库规则、输入资料、验收条件和禁止事项一起交给代理。
一个发布任务至少应该定义四类上下文：
| 上下文 | 需要写清楚的内容 |
|---|---|
| 产品目标 | 面向谁、解决什么问题、期望用户采取什么动作 |
| 工程边界 | 使用哪些组件、允许修改哪些目录、怎样运行测试 |
| 品牌约束 | 语气、术语、颜色、排版以及不可使用的表达 |
| 验收标准 | 页面状态、移动端表现、链接、埋点和审批人 |
然后把工作拆成小批次。代理可以先生成页面骨架，再填充内容，最后运行检查；负责人则按差异审阅，而不是面对一个无法追踪来源的大型交付物。
可以这样实践：建立一个最小发布工作区
下面是一个可改造的伪项目示例。它不是对 Stampli 内部实现的复刻，而是把案例中的方法落到普通代码仓库中。先创建目录：
mkdir -p launch-workspace/{briefs,content,checks}
cd launch-workspace
printf '# Launch workspace\n' > README.md
在 briefs/launch.md 中准备输入。把方括号内容替换成你的真实信息：
# Launch brief
## Goal
Help [target audience] understand and try [product or feature].
## Required deliverables
- Landing-page copy
- FAQ
- Release announcement
- Engineering implementation checklist
## Constraints
- Reuse the existing component library.
- Do not invent customer quotes, metrics, prices, or capabilities.
- Mark every unsupported statement with [VERIFY].
- Keep the primary call to action consistent across all assets.
## Acceptance criteria
- No TODO or placeholder remains.
- All claims have an owner or source.
- Mobile, loading, empty, error, and success states are reviewed.
- A human approver signs off before publication.
接着可以把下面的提示词交给 ChatGPT Work 或代码代理。它要求代理先读取约束，再分阶段修改文件：
Read briefs/launch.md and inspect the existing repository before editing.
Create a short execution plan that maps each deliverable to a file and an
acceptance check. Then produce the deliverables in small batches.
Rules:
1. Reuse existing components and terminology.
2. Do not invent metrics, customer evidence, features, or approvals.
3. Add [VERIFY] after any claim that lacks evidence in the repository.
4. After each batch, list changed files and run the relevant checks.
5. Stop before publishing and provide a human-review checklist.
为了避免“生成完成”被误当成“可以发布”，可以加入一个零依赖 Python 检查器。将下面内容放入 checks/release_gate.py：
from pathlib import Path
import sys
ROOT = Path(__file__).resolve().parents[1]
SCAN_DIRS = [ROOT / 'briefs', ROOT / 'content']
BLOCKED = ('TODO', 'TBD', '[VERIFY]', 'example.com', 'lorem ipsum')
problems = []
files = []
for directory in SCAN_DIRS:
if directory.exists():
files.extend(directory.rglob('*.md'))
if not files:
problems.append('No Markdown launch artifacts found.')
for path in files:
text = path.read_text(encoding='utf-8')
for line_number, line in enumerate(text.splitlines(), start=1):
lowered = line.lower()
for token in BLOCKED:
if token.lower() in lowered:
relative = path.relative_to(ROOT)
problems.append(f'{relative}:{line_number}: unresolved {token}')
if problems:
print('\n'.join(problems))
sys.exit(1)
print(f'Release gate passed for {len(files)} Markdown files.')
运行检查：
python checks/release_gate.py
这个脚本只是一道基础门禁，却能阻止常见的占位符和待核实声明直接进入发布流程。实际项目还可以接入链接检查、视觉回归、单元测试、无障碍扫描以及分析事件校验。
人仍然负责不可外包的判断
AI 能缩短页面实现、内容起草和重复检查的时间，但不能自动获得企业内部事实。价格、客户承诺、合规表述、品牌判断和发布日期批准，仍然需要明确负责人。
在采用类似工作流时，可以使用这份上线清单：
- 输入资料是否包含唯一可信的产品事实来源；
- 代理是否只能修改约定目录，并且所有差异都能审阅；
- 自动检查是否覆盖占位符、链接、测试和关键页面状态；
- 数据、客户引语和性能数字是否经过人工核实；
- 是否保留最终人工审批，而不是让代理直接发布；
- 是否记录从任务开始到上线的实际耗时，用于判断 AI 是否真的缩短了周期。
Stampli 的案例说明，在期限固定、专业资源有限时，AI 最有价值的角色不是凭空替团队做决定，而是把已经明确的意图迅速变成可检查的交付物。要复制这种速度，团队需要的不只是更强的提示词，还需要清晰边界、小批次执行、自动门禁和明确的人类责任人。