你用做需求的方式做 AI-first，所以它不 work
Anthropic 的工程师做过一个实验：让一个 Agent 独立跑一个任务，20 分钟、花 $9，产出"看着对但一用就崩"的东西。然后加上完整的 harness——规划器、生成器、审查器——跑 6 小时、花 $200，产出"真正能用"的东西。
同一个任务，$9 和 $200，20 分钟和 6 小时。22 倍的差距。
如果你把 AI-first workflow 当成软件工程在做——拆需求、估工期、定里程碑——这个数字会彻底颠覆你的预期。但如果你把它当成算法工程，22 倍一点都不意外。因为算法工程本来就是这个样子。
不是软件工程
我们平时做需求开发，核心假设是三件事：
终点明确。 Jira ticket 写了验收标准，做到了就算完。
产出可预测。 做一个登录页，你知道做完大概长什么样。
工期可估。 两周三周五是可能估不准，但至少能估。
AI-first workflow 这三条全不成立。
"好用"的标准会随着真实使用不断移动——所以终点不是明确的，它漂移。从"跑通"到"真的好用"中间有一条很宽的沟——所以产出不可预测，你不知道什么时候能跨过去。优化效果的工作量没有人能提前告诉你——所以工期不可估，不是能力问题，是这类工程的内在属性。
这不是类比。这是同一个类型的系统。ML 模型调参、搜索排序优化、推荐系统迭代——这些算法工程项目全都有模糊终点、不可预测产出和不可估工期的特征。AI-first workflow 继承了这些属性，因为它的核心机制——行为概率化、效果场景依赖的 Agent——和 ML 模型是同一类系统。
把算法工程当软件工程来管，就像拿尺子量温度。工具没错，量的东西不对。
验证负担才是核心指标
Agent 做执行，人做验证——这是 AI-first 的目标态。但大多数人忽略了一个陷阱：
如果 Agent 产出不够稳定，人验证的认知负担会超过自己直接做。
不是"稍微累一点"，是更累。Agent 写了一段代码，你不能只看"功能对不对"——你得想"它有没有我没考虑到的边界情况""这个实现方式在什么条件下会崩""测试覆盖的场景够不够"。每个问题都在消耗你的认知资源。当你审查完第五个 Agent PR，你比直接写代码还累。
Fiona Fung 在 Code with Claude 2026 上说得直白：Claude Code 团队的瓶颈已经不是代码生成了，是验证、审查、跨职能协作和安全。她的原话："人类怎么审查所有这些代码？维护成本怎么算？"
所以评估一个 Agent workflow 是否可用，关键问题不是"Agent 能不能完成任务"，而是**"人看到产出之后，验证的速度和置信度如何"**。这是核心可用性指标。验证快且自信，workflow 可用。验证慢且犹豫，workflow 不可用——不管 Agent 交得多快。
这个指标的核心在于它把"自信"推到了比"速度"更关键的位置。速度仪表盘上数字再好看，只要人在验证环节犹豫、不确定、反复检查，整个 workflow 的效率就被拖垮了。Augment Code 的实测很说明问题：PR 量激增之后，审查瓶颈迅速出现——审查者要么敷衍签字（橡皮图章效应），要么认真审但耗尽精力，理解力逐步流失，最终团队不敢部署自己的代码。这条链从速度始，到瘫痪终。验证负担就是整条链的量化形态。
非线性：前 70% 是幻觉
回到那个 22 倍的实验。$9 的产出和 $200 的产出，表面上差的是"完善程度"。实际上差的是从原型到产品的完整跨越。
AI-first workflow 一个特别坑的地方：前 70% 进展极快，后面每 10% 可能要花几倍的时间。这不是谁的问题，是这类工程的结构性属性。
原因在于长尾。前 70% 覆盖的是 Agent 本来就擅长处理的场景——常见的、模式清晰的、训练数据充分的情况。后 30% 是长尾：不常见的失败情况、场景依赖的边界问题、需要特定上下文才能正确处理的任务。每解决一个长尾问题，需要更精细的 harness 设计、更精确的上下文工程、更严密的验证基础设施。难度指数上升。
这解释了为什么 vibe coding 产出 demo 但产不出产品。Demo 在曲线的 70% 位置——那里又快又便宜。产品在剩下的 30%——那里又慢又贵。Vibe coding 不是错的，它是一个高效的 70% 策略。错误在于期望它产出 100%。
这也意味着用时间节点做阶段判断是错的。你不能说"两个月做到 90%"，因为你不知道后 30% 需要多久。应该用效果门槛：定义"什么样的效果算够用"，达到了就进下一步，在一个方向上停滞太久就换方向，而不是硬推。
先解决自己的问题
上面说的非线性和验证负担，在不同场景下的表现差异很大。这也是为什么"先解决自己的局部问题"不是权宜之计，而是认识论上正确的策略。
解决自己的问题时，反馈最直接，你知道哪里不对，复杂度最小（不用考虑安全性、文档、他人使用），所以跑得快、学得快。只有局部问题解决好了，再考虑推广和通用化。
但有一个经常被忽略的关键前提：做局部探索时必须记录前提假设。
为什么？因为推广的时候，你需要知道哪些东西是场景特有的、不能直接搬的。局部方案里嵌了很多隐含假设——"我们团队的代码风格是这样的""这个项目用的是这种框架""用户行为模式是这种"。这些假设在局部场景下不可见，因为它们就是你的日常。但换一个场景，它们可能全都不成立。
这里有一个和 Agent 委派同构的问题。每次向 Agent 委派任务，本质上是一次有损压缩——人的隐性知识变成机器可读的显式指令，丢弃是必然的。推广也一样：把局部方案搬到新场景，是一种跨场景的有损压缩。如果没把假设显式化，压缩就丢掉了最关键的信息——那些"在我们这里理所当然但在你们那里可能不成立"的东西。
推广时，假设是头等公民
传统软件工程里，假设隐含在架构中——不需要单独文档化，它自然地从代码结构里体现。算法工程不一样。ML 系统里关于数据分布、特征重要性、模型行为的假设必须显式记录，因为这些假设决定了系统在什么条件下能用、什么条件下会崩。
AI-first workflow 需要同样的纪律。关于 Agent 行为的假设（它能推断什么 vs 必须明确指定什么）、上下文需求的假设（Agent 成功需要哪些信息可用）、失败模式的假设（什么条件下输出不可靠）——这些必须作为一等制品记录。
没有这个纪律，局部方案推广就变成了一场赌局：运气好，假设刚好在新场景也成立；运气不好，方案静默失败，而且失败的模式和局部场景完全不同，因为失败的原因正是那些被搬过来但不再成立的假设。
还有一个我觉得挺微妙的反馈循环：越依赖 Agent，团队对"够不够好"的判断力越弱。直觉来自实践——你反复做某类事情，才会对"这个效果行不行"有感觉。Agent 接管了实践机会，判断力的供养就断了。这个循环和前面说的人跟人之间的知识传递还不一样。人与人之间，知识差距会随时间闭合——初级开发者跟资深者并肩工作，慢慢学到后者的直觉。但 Agent 每次调用都从你给的规格开始，你永远在 onboarding。所以判断力的流失不是线性的消退，而是每次换人都要重新积累——只是这次"人"是 Agent，它不会积累。
可能需要一种不依赖团队直觉的效果门槛定义方式——也许来自用户行为数据而非内部评估。但我对这个还不确定。
一句话总结
AI-first workflow 不是做需求——它是算法工程：终点漂移、产出不可预测、工期不可估。验证负担是它的核心可用性指标，非线性是它的进度规律，假设文档是它的推广前提。用做需求的方式做 AI-first，22 倍的代价差会反复出现，每次都像意外——但它从来都不是意外。