Claude Code

按 28 天 1.05 亿美元粗算，Meta 的 Claude Code 支出年化约 13 亿美元；其内部替代工具用户已与 Claude Code 相当，后续迁移金额可能更大。

作者站在厂商一侧：演示仓库 tidepool 是自造的小型 Node API，三个问题都是边界清楚、靠测试就能验证的小问题，四个会话也全部成功，没有展示失败或跑偏的会话。文中 bonus credit 的领取截止日（October 7）还带有促销的紧迫感。

耗时数字的口径不统一。正文说三个会话分别运行了 61、65、72 秒，87 秒指的是从第一个会话启动到全部完成；图注里写的则是 65、62、87 秒。而且其中三分之一到一半多的时间花在从 prompt 重建仓库上，VM 冷启动和 setup 缓存未命中的时间都没有单独给出。

文章说机器不另收费，但没有给出任何一个演示会话实际消耗了多少 token 或多少额度。并行五倍消耗只是一个比例，读者无法据此估算真实成本；logger 会话为别人的 bug 做重复诊断，也耗掉了额度。

竞态修复的证据可以复现，但失败率前后对不上：原文开头说大约每四次失败一次，logger 会话重跑八次却失败了五次。推断：这可能和 logger 改动后请求路径的时序有关。文中没有解释，40 次 0 失败的样本量也有限。

「Claude Code 自身功能也用 mod 写」既是能力背书也是营销；官方教程口吻偏推广。

effort 档位名跨模型、跨 surface 都不等价：Platform 默认 high，Claude Code 默认 medium。不先固定档位就比较「Sonnet 5.5 vs Opus 5.5」，结论不成立。

/usage 显示的美元数按标价在本机计算，在订阅计费下只是工作量参考，不是实际花费。

关键证据都在图里（effort 曲线、失败归因图、分领域收益细分），正文没有给出各档位具体的 token 倍数和分领域数值。¶1 说切换 effort 不会打破 prompt cache，但没有解释机制和前提条件。

文章推荐「low 实现、high 验证」，但同时承认 effort 修不了方法错误。这意味着低档实现的方向性错误不能指望靠高档验证来发现，只能依靠中间那一步人工 review。文章没有讨论这一步漏检的代价，也没有说明高档会「替你做更多假设」时，在无人值守场景下怎么约束。

通过率只基于每个任务 5 次尝试，1/5 到 5/5 这类差距在小样本下置信区间很宽。脚注还说明 Fable 5.1 关闭了生产安全干预、安全类任务没有联网，因此与公开榜单和发布文章都对不上。示例轨迹来自单次运行，有些用的还是中间档位。

作者代表模型厂商，¶9 称这两个模型的 effort 曲线是「our best yet」，全文也在引导读者多用高档位，而高档会直接带来更多 token 计费。文中没有给出任何关于成本与收益比的讨论。

原文只讲了 Claude apps 和交互式 Claude Code 里怎么看到模型切换，没讲非交互运行（脚本调用、定时任务）里会不会切换、有没有可解析的信号，也没点名会切到哪个旧模型。

subagent 并行和 fast mode 的成本都只提了一句或完全没提。fast mode 只说了每 token 更贵，没给价格；subagent 的 token 开销完全没讲。

在 Windows 办公电脑上，Claude Code 与 Codex 的默认安全边界差距最大（前者沙箱默认关闭且原生 Windows 不支持，后者默认启用沙箱）。

有私有化部署或数据不出境要求时，模型可替换性是硬门槛：Claude Code 只能用 Claude 模型，Codex 可接本地与第三方端点。

Claude Code 云端执行 9 项中 8 项仍为预览或 Beta，依赖云端能力做规模化部署前需评估预览期功能的变更风险与服务承诺。

合规要求严格的机构，应关注策略下发失败时的默认行为（Claude Code 默认沿用缓存继续运行，Codex 默认失败即关闭），而不只是策略项有多少。

在 Claude Code 中，插件通过丰富且清晰的宿主槽位组合工程能力；在 Codex 中，插件更像一种产品化封装，让同一能力在多个 OpenAI 表面被发现、安装与治理。三者并非线性强弱，而是抽象层不同。

插件落地失败往往不是代码问题，而是卡在发现、信任、注册、激活或选择。三者的关键路径完全不同。

插件不是静态提示词包：它可能执行命令、连接远端服务、改变权限、注入模型上下文，甚至重组 agent loop。应把插件当软件供应链来管理。

不要让三个宿主各自复制同一套业务逻辑。把确定性逻辑放在版本化服务或 MCP，流程与提示层放在各宿主 Skill，宿主特有治理放在 Hooks，DeepSeek 只在确实需要替换 runtime seam 时承担控制面。

价格弹性在编码场景里被模型质量差距压平了。这个含义对企业采购的影响是：把编码工具当作可比价商品去谈，很难谈出结果，预算模型需要按用量增长而不是按席位来做。

中间层的定价权取决于它是否持有客户拿不到的东西。其意义在于：只做模型分发的产品，涨价窗口正在关闭，估值逻辑要转向自有模型、路由效率和成本管控这些可计量的省钱能力。

替代方案已经进入可评估阶段，但还没进入可执行阶段。启示是：今年的成本控制得靠内部路由和用量治理拿，明年才可能靠换供应商拿，两条路线要分开排期。

「over 80%」「no measurable loss」只限于 Anthropic 内部的 coding evaluations。评测集、指标、样本量和置信区间都没有公开。「测不出损失」不等于「没有损失」，还取决于评测的灵敏度。而且内容创作、品牌合规这类任务不在这些评测的覆盖范围里。

TodoWrite 描述从约 9,100 字符缩成一句话，原文只给了前后对比图，没有给出行为层面的对比数据（例如任务列表的使用率、状态错误率）。

文章推荐 auto-memory 代替手写记忆，但没有谈记忆的质量控制：错误记忆如何发现和清除，记忆膨胀如何治理。

文章没有讨论上下文结构变化对 prompt cache 命中率和成本的影响（比如精简系统提示、deferred loading、按需加载技能）。

AI 的回报正从大厂 PoC 下沉到中小企业的成本表；传统 SaaS 订阅面临被"vibe coding"替代的边际压力。

三条示例 prompt 有一个共同句式:让 Claude 生成 可反应的选项谱系 (4 个设计方向、10 个介入点),人只负责说「哪个有共鸣」。这把「表达品味」降维成「挑选品味」——后者人人都会。

「一次一个」是关键交互设计:并列十个问题会让人敷衍作答,逐题追问才会逼出真实决策。配套工件第 6 号把访谈产出物化成「决策表 + 可直接粘贴的实现 prompt」。

「跨语言移植语义」是模型的舒适区,而人恰恰最难用自然语言精确描述语义。配套工件第 7 号给出安全带:移植前先让 Claude 输出「语义对照图」——匹配的代码摘录、坑点注记、边界情况表——证明它真读懂了参照物。

「那部分我信你」是一次显式的信任分层:人的注意力只花在高变动面上。配套工件第 8 号把这份计划做成可交互:被标记的 schema 选择带可切换的备选项,机械工作折叠在底部。

agent 的「即兴决策」是最大的黑箱。偏离日志把黑箱变成组织记忆:每一次意外都沉淀为下一次 prompt 的已知条件。

注意素材清单正是前面各技巧的产出物——原型(02)、计划/spec(05)、笔记(06)在这里二次变现。「Lead with the demo」是传播学判断:先让人看见东西动起来,再谈实现细节。

当产出速度超过理解速度,「人是否真懂」成为新的质量门禁。这对代码评审如此,对任何需要人签字负责的 AI 产出(审计、风控、研究)同样成立。

文中八则技巧的载体几乎全是 HTML:设计方向、计划、笔记、报告、测验。可交互的单文件工件,是人机之间带宽最高的「反应界面」——这与「HTML deck 优先」的交付思路互为印证。

"blindspot pass"、"implementation-notes.md"、"quiz me" 这类固定词是人机之间的 API。团队统一用词,技巧才能从个人习惯变成可复制的流程资产。

「这一轮学到的,就是下一轮的地图」——把 agent 的每次即兴决策记入 Deviations,积累起来就是团队专属的疆域知识库,比任何通用最佳实践都值钱。

测验门禁的适用面远超代码:任何需要人签字负责的 AI 产出——审计底稿、风险报告、研究交付——都可以要求「满分通过理解测验」再放行。

这篇文章的价值不在于“多开几个 subagent”，而在于把 Agent 能力从单窗口执行，推进到可编排、可验证、可复用、可恢复的任务级工作系统。

Dynamic Workflows 的本质：让 Claude Code 从“执行任务”变成“先为任务设计执行系统”。

判断标准很简单：如果任务需要并行、对抗、重复、隔离或可恢复状态，用 workflow；如果只是一次性执行，用默认 harness。

Dynamic Workflows 不是 Claude Code 的一个功能更新，而是一个信号：下一阶段 Agent 产品的竞争重点，会从“模型能不能做”转向“系统能不能组织模型做”。

真正稀缺的能力不是无限上下文，而是任务结构设计：什么时候分流，什么时候并行，什么时候验证，什么时候循环，什么时候停止。

九类分类来自 Anthropic 内部编目，编目方法、样本量和归类标准都没有说明。「横跨多类的技能会让 agent 困惑」是定性观察，没有给证据。

「验证技能对质量的影响最可测」既没有给指标定义，也没有基线和提升幅度，没法判断「最」是相对什么说的。

全文没有讲安全。技能可以带可执行脚本和 hooks，从 marketplace 安装等于引入别人写的代码，但文章没有提签名、审核、权限边界和供应链风险。

上下文成本只用一句「增加一点」带过，没有量化清单的 token 占用，也没说技能数量的上限、description 会不会被截断。另外，技能依赖靠按名引用，被依赖的技能没装时会怎样失败，文章也没写。

它把 Claude Code 的失败模式拆成三类：缺上下文、越权行动、忘记历史。这个框架有实践价值；但 65%→94% 与年度节省金额缺少可核验实验依据，应作为传播话术而非证明。

真正可落地的版本不是处处审批，而是按风险设权限门。

coding agent 需要权限模型。模型越能干，越不能让它依靠善意边界自由发挥。

团队需要把隐性历史变成可审计资产，但也要防止记忆文件无限膨胀。

这些数字适合提示问题严重性，不足以证明因果收益。落地时应用团队自己的指标复盘。

「100 行以上就不读」「HTML 被阅读的概率高得多」都是作者个人感受，没有数据。¶76 用 Opus 4.7 的 1MM 上下文说明 token 增量「不明显」，这是上下文占用的口径，不是计费口径，也没算输出变长带来的延迟。

文章没讲怎么验证 HTML 本身是否正确：交互脚本可能不执行，或只在部分环境下能用。

文章没谈分享和托管的安全与合规：HTML 可以带脚本，上传链接相当于对外发布，可能被缓存或索引。

¶28-¶29 说把一组 HTML 交给实现或验证会话能带来更全面的上下文，但没有和「交 Markdown 计划」做过对照；HTML 里的样式和脚本对下游模型来说可能是噪声。

代价一侧几乎没展开：system-reminder 注入对输出质量的影响只用一句话带过（¶6）；defer_loading 会多一次 tool search 往返，模型也可能选错或漏选工具；压缩摘要会丢信息。文中都没给数据。

命中率高直接关系到厂商自己的算力成本和订阅限额，所以「别中途切到便宜模型」这条建议也同时增加了大模型的用量。文中只举了一个对 Opus 有利的例子，没有给出对话长度和问题难度在什么范围内切换反而更省的临界点。

「缺失率差几个百分点就会明显影响成本」没有给基线命中率，也没有给分母口径（按请求算还是按 token 算）。图中缓存读取是原价十分之一，但文中完全没提缓存写入的溢价和缓存过期时间，这两项会改变长间隔场景（比如每周跑一次的任务）的计算。

文章没有讨论 effort 或 thinking 档位的改变会不会打断缓存，而 L-001 方案是否可行正取决于这一点。

全文只有定性判断（如 Claude seemed to like calling this tool、outputs worked well），没有成功率、轮次、token 成本等量化证据。作者是 Anthropic 员工，文章本身也在推广 Claude Code，结尾还有产品引导。

「只支持少数能力剖面相近的模型」对产品方合理，但对第三方开发者等于默认模型锁定；文章也没有讨论多模型或降级场景下工具集该怎么处理。

文章没有讨论自检索的代价。Grep 多轮搜索带来的延迟、token 成本，子代理的额外调用费用，都没有和 RAG 对比。也没有说明删除或替换工具之前用什么评测判断「旧工具已经成为束缚」，只说要多实验。

「约二十个工具」「每五轮提醒」「一年内从不会自建上下文到能多层嵌套检索」都是描述性说法，没有基线、没有测量口径。「Opus 4.5 更擅长用子代理」也没有给出评测依据。