讲稿
这个演示稿用于说明一个开发型 Agent 产品应该怎样讲清楚自己的价值。
我不希望它变成“AI 写代码很快”的表演，而是把重点放在工程流程：任务输入、上下文读取、变更执行、验证反馈，以及最后如何把结果交还给人。
演示节奏.
前半段展示一个小型变更如何被拆开；后半段展示浏览器检查、测试结果和最终说明如何构成可信交付。
用数字和对比讲清流程.
抽象地说“工程化”没有说服力，所以这一段我用一次真实的小改动作为标尺，把四个阶段的体量摆出来。
6个
改动文件
含 2 个测试
14处
读取上下文
文件 + 终端 + 浏览器
9项
跑过的检查
lint 与单测各半
一次中等改动的体量画像
体量之外，更值得看的是时间花在哪里。把四个阶段的耗时并排比一下，就会发现真正费时的从来不是“写代码”，而是读上下文和验证。
不是每个任务都该走同一条流。按风险和可验证性分一下类，就知道哪些能放手、哪些必须人盯着。
高风险 · 高可验证有测试兜底，放手改，验证收尾。
高风险 · 低可验证先补可观测性，别急着动。
低风险 · 高可验证自动化首选，批量交给 Agent。
低风险 · 低可验证文档与重命名，人快速过目即可。
分类之后是选模型——任务的难度决定该配哪一档，而不是一律用最贵的。
模型定价截至 2026-06
| 模型 | 输入 | 缓存命中 | 输出 | 上下文 |
|---|---|---|---|---|
codex-mini低风险批量 | 2.0 | 0.5 | 8.0 | 256K |
codex-std日常改动 | 9.0 | 2.2 | 36.0 | 512K |
codex-pro跨文件重构 | 22.0 | 5.5 | 88.0 | 1M |
¥ / 百万 token · 按任务难度配模型
模型在迭代，这条流也在迭代，下面是它走到今天的几个节点。
- 2026-02只读上下文先看懂再说
- 2026-04可回放证据链终端 + 浏览器入流
- 2026-06验证式交付当前
流程能力的演进
一句话收住这一段。
整条流串起来，就是把一个任务一路推到一个可验证的变更。