理解先于自动化：AI 工作流真正解决什么问题？

AI 正在描绘一种非常诱人的生产方式：

白天，人负责描述目标、制定规则、验收结果；晚上，一群 Agent 自动规划任务、编写代码、生成资产、运行测试、互相 Review。第二天早晨，人打开 Dashboard，看到几十个任务已经完成，再从中挑选可以合并的成果。

在这种想象中，程序员甚至不再是「用 AI 写代码的人」，而是设计 AI 生产系统的人。

这种未来并非虚构。今天的 Agent 已经能够使用工具、修改文件、执行程序、读取测试结果，并在多轮循环中继续工作。Anthropic 将预定义代码路径中的 LLM 编排称为 Workflow，而把由模型动态决定下一步行为和工具使用方式的系统称为 Agent。¹

真正值得讨论的问题因此已经不是：

AI 能不能自动生产？

而是：

什么东西值得自动生产？谁来定义「做对了」？当生成能力变得极其廉价之后，新的瓶颈是什么？

1AI 工作流描绘了一个怎样的未来？

1.1从 Copilot 到 Agent，再到「无人生产线」

早期的 AI 编程更像一种增强型自动补全：

人思考 → 人写代码 → AI 补几行

后来，AI 开始能够接收一个完整任务：

人描述需求 → AI 修改多个文件 → 人 Review

再往前一步，Agent 获得终端、浏览器、代码执行、版本控制、测试系统等工具之后，流程开始变成：

于是自然会产生更进一步的想象：

如果一个 Agent 可以工作，那么为什么不让五个 Agent 分工？

如果五个 Agent 可以协作，为什么不让它们工作一整晚？

如果整个流程都能自动运行，为什么人还要亲自写代码？

这些问题本身都合理。

问题出现在另一种很容易发生的逻辑跳跃：

AI 能执行这件事，因此这件事应该被自动化。

二者并不是同一件事。

1.2为什么这种演示如此令人着迷？

复杂 AI Workflow 非常适合演示。

因为它天然具备几个视觉上极具说服力的特征：

• Agent 在不断运行；
• 节点之间不断传递任务；
• Dashboard 上的数字不断增长；
• Token、Task、PR、Artifact 都可以被计数；
• 一个原本需要人工操作的流程看起来开始「自己运转」。

传统工程优化往往没有这么戏剧化。

一个工程师把构建时间从 12 分钟降低到 4 分钟，可能没有任何酷炫界面。

一个原本需要五个 Agent 的任务，被重新设计后只需要一次模型调用和一个测试脚本，也不太适合做成发布会演示。

但后两者可能创造了更多真实价值。

这里需要区分两个目标：

复杂度本身不是成果。

自动化程度本身也不是成果。

1.3Workflow 与 Agent 本身没有问题

这里很容易走向另一个极端：既然复杂 Workflow 可能沦为表演，那么是不是 Agent 和自动化都没有价值？

当然不是。

Anthropic 在总结实际 Agent 项目时，给出的恰恰不是「不要使用 Agent」，而是：从最简单的方案开始，只在复杂度能够带来可测量收益时才增加复杂度。 对于固定、清晰的任务，Workflow 往往更加可预测；当任务确实需要动态决策时，Agent 才更加合适。¹

OpenAI 对 Workspace Agent 的建议也非常类似：重复、结构清晰、具有固定输出形式、由时间或事件触发，并且需要操作工具的工作尤其适合作为 Agent Workflow；对于一次性的开放思考和探索任务，普通交互反而可能更加合适。²

因此真正的问题不是：

Workflow 好不好？

而是：

这个问题为什么需要 Workflow？

2AI 降低的是执行成本，而不是判断成本

理解 AI 自动化的关键，是先拆开「生产」这件事情。

一个简化的知识工作过程可以写成：

其中：

• $S$：Specification，定义问题、目标和约束；
• $E$：Execution，真正执行生产；
• $V$：Verification，判断结果是否正确。

这不是一个严格的经济学模型，而是一个用来理解生产结构的工程抽象。

2.1过去最昂贵的是 Execution

传统软件开发中，哪怕设计已经非常清楚，实现依然需要大量时间。

例如一个功能可能已经明确知道：

• 数据结构是什么；
• 输入是什么；
• 状态如何转换；
• UI 长什么样；
• 错误条件有哪些。

但工程师依然需要：

创建文件
写类型
调用 API
实现逻辑
处理错误
补测试
修编译错误
重构重复代码

也就是说，即使：

仍然存在大量：

AI 对软件工程最直接的改变，就是猛烈压缩这一部分。

它不会真的让 Execution Cost 变成零——模型推理、等待、上下文准备、工具调用仍然有成本——但很多过去昂贵的机械执行开始变得非常廉价。

于是：

2.2于是瓶颈开始迁移

当 Execution 大幅下降之后，剩余的两个部分反而变得更加显眼：

也就是：

我要什么？

以及：

它做出来的是不是我要的？

这就是为什么「AI 越强，人越不需要懂」并不一定成立。

对于大量复杂工作，情况甚至可能恰好相反：

AI 越能够自主执行，人越需要拥有清晰的目标和判断标准。

因为 AI 可以非常快速地把一个模糊方向展开成成千上万行代码、几十个文件和大量内容。

如果方向正确，这是巨大的杠杆。

如果方向错误，这同样是巨大的杠杆。

区别只在于杠杆把什么放大了。

3当生成能力超过选择能力

过去，很多坏想法不会造成太大问题，因为实现它们很贵。

一个开发者想到：

要不要顺便做一个排行榜？

过去意味着：

• 数据库；
• 后端接口；
• UI；
• 排名逻辑；
• 用户体系；
• 防作弊；
• 部署；
• 维护。

高昂的生产成本天然形成了一层过滤器。

而 AI 逐渐移除了这层过滤器。

今天越来越常见的情况变成：

要不要做排行榜？

AI：

可以，我已经创建数据库 Schema、API、排行榜 UI 和管理后台。

于是生产过程出现一种新的不平衡：

我们第一次开始拥有远超自身判断速度的生成能力。

因此新的稀缺资源开始从：

「谁能够做出来？」

逐渐转向：

「谁知道什么值得做？」

4为什么「自己首先要会」仍然重要？

「自己首先要会」很容易被误解成一种保守主义：

AI 写的都不可靠，所以所有东西还是应该自己写。

这并不是这里真正要表达的意思。

真正重要的不是：

每一行代码都必须亲手完成。

而是：

你必须拥有足够准确的领域模型，知道正确结果大概长什么样。

4.1Domain Model：专家脑中的隐藏结构

假设让 AI 为一把半自动手枪实现完整装填逻辑。

表面看，需求可能只有一句：

实现换弹、上膛、空仓挂机和 Slide Stop。

一个不了解枪械机制的人也完全可以把这句话交给 Coding Agent。

Agent 甚至可能在几分钟内写出一个看起来完整的系统。

真正的问题在验收阶段。

一个熟悉这个领域的人脑中存在许多没有写进需求的关系：

Magazine 中有弹
≠
Chamber 中有弹

拔掉 Magazine
≠
Chamber 自动变空

最后一发射出
→
Follower 推动机构
→
Slide 锁在后方

插入新 Magazine
≠
自动完成上膛

除此之外还有：

• 动画与逻辑状态如何同步；
• 玩家在动画中途操作怎么办；
• XR 物理交互是否允许越过状态机；
• 枪机被手动拉到一半怎么办；
• 对象销毁或重新生成时状态如何恢复；
• 网络同步时哪些状态属于 authoritative state。

这些知识共同组成一个 Domain Model。

专家之所以更容易使用 AI，不只是因为他更会写 Prompt。

而是因为：

他能够看见 AI 没做对的地方。

4.2Quality Bar 同样属于知识

「正确」并不总是二元值。

例如：

让这把枪更有重量感。

AI 可以尝试修改：

• recoil；
• camera impulse；
• animation；
• haptics；
• audio；
• muzzle flash；
• weapon sway；
• reload timing。

但是没有：

ASSERT(GunFeelsHeavy == true);

于是工程师需要拥有某种内部标准：

现在已经够了吗？

这个标准可能来自：

• 对现实对象的理解；
• 大量玩游戏的经验；
• 动画知识；
• 声音设计经验；
• 物理反馈；
• 当前游戏的整体设计语言。

它很难被完全写进 Prompt。

但它决定了最终产品质量。

5自动化真正需要的不是 Agent，而是闭环

一个任务是否适合自动化，可以先问四个问题：

1. 我能不能把任务说清楚？
2. 我能不能低成本判断结果对不对？
3. 这件事是否值得重复自动执行？
4. 如果做错一次，代价有多高？

可以把它抽象成一个简单的启发式模型：

其中：

• $A$：Automation Fit，自动化适配度；
• $S$：Specification，任务是否容易定义；
• $V$：Verifiability，结果是否容易验证；
• $R$：Repeatability，任务是否值得重复执行；
• $F$：Failure Cost，失败造成的成本。

这个公式并不是某篇论文给出的经验定律，也不应该拿来计算一个精确分数。

它的价值在于帮助我们思考：

一个任务「AI 能做」，和它「适合无人自动运行」，之间究竟还差什么。

6Specification：你能否把问题说清楚？

比较下面两个任务：

把项目中所有旧版 FooAPI 调用迁移到新版 BarAPI，保持现有行为不变，并保证 Build 与 Test 全部通过。

以及：

让整个代码架构更加优雅。

前者拥有：

• 明确输入；
• 明确转换规则；
• 明确边界；
• 明确成功标准。

后者的问题在于，「优雅」本身没有被定义。

AI 当然仍然可以工作。

但它实际上必须开始替你决定：

什么叫优雅？

这意味着原本属于 Specification 的工作，被悄悄转移给了生产者。

如果调用者自己也不知道答案，就很难判断 Agent 的决定究竟是设计，还是随机漂移。

7Verification：你能否知道它真的完成了？

自动化最重要的资源之一不是 Prompt，而是 Ground Truth。

对于代码任务，它可能来自：

Compiler
Unit Test
Integration Test
Static Analysis
Benchmark
Runtime
Screenshot Comparison
Schema Validation

Anthropic 在介绍 Agent 设计时特别强调，Agent 在运行过程中需要不断从环境获得真实反馈，例如工具结果和代码执行结果，而不是仅依靠自己的文本推理判断进度。¹

OpenAI 当前的 Agent 文档也把 Trace、Grader、Eval、Guardrail 和人工审批作为生产 Agent 的重要组成部分：Agent 是否选择了正确工具、是否进行了错误 handoff、是否违反约束，都需要能够被观察和评估。³

于是一个很重要的原则出现了：

不要只给 Agent 更多智能，也要给它更好的现实反馈。

8Repeatability：这件事值得建立 Workflow 吗？

能够自动化，不等于值得搭建自动化系统。

例如：

把这一份 300 行配置文件迁移一次。

也许直接让一个 Agent 做完，比设计：

Parser Agent
Migration Agent
Verifier Agent
Dashboard
Persistent State
Retry Queue

划算得多。

Workflow 本身也是软件。

它也需要：

• 开发；
• 调试；
• 维护；
• 日志；
• 权限；
• 错误恢复；
• 模型升级兼容。

因此只有当任务具有足够高的重复率时，这部分基础设施成本才容易被摊薄。

这也是为什么重复、结构化、事件驱动的工作尤其适合 Agent Workflow。²

9Failure Cost：如果错了会怎样？

再比较两个动作：

自动生成一份内部会议摘要。

和：

自动删除生产数据库中的旧记录。

哪怕两个任务的 AI 成功率完全相同，它们的自动化策略也不应该一样。

失败成本越高：

• 越需要权限隔离；
• 越需要 dry-run；
• 越需要 deterministic validation；
• 越需要人工确认；
• 越需要 reversible action。

OpenAI 当前的 Agent 文档将这类机制直接设计为 Human-in-the-loop Approval：模型可以判断需要执行动作，但对于敏感或具有副作用的操作，流程可以在真正执行之前暂停，由人批准或拒绝。⁴

真正成熟的自动化不是：

人完全消失。

而是：

人只出现在最值得出现的位置。

10哪些任务适合交给 AI 自动执行？

把前面的四个因素放到一起，可以粗略得到三类任务。

10.1确定性任务：机器最舒服的区域

例如：

• API Migration；
• Build；
• Lint；
• Formatting；
• Unit Test Generation；
• Static Analysis；
• Asset Validation；
• 批量格式转换；
• 数据清洗；
• 机械式重构；
• 文档同步；
• Localization 初稿；
• 大量候选方案搜索。

这类任务共同的特点不是「简单」。

有些甚至非常复杂。

真正重要的是：

它们存在便宜而可靠的评价函数。

Agent 可以不断执行：

只要评价函数足够可靠，Agent 就拥有了一个可以自行迭代的闭环。

11半开放任务：人与 AI 的高价值协作区

很多软件工程和游戏开发工作属于这一类：

• Gameplay Feature；
• 系统架构重构；
• Shader；
• Editor Tool；
• AI NPC；
• Animation System；
• UI；
• 性能优化；
• 技术方案设计。

这些任务通常可以明确一部分要求，但无法穷举全部质量标准。

比较好的流程往往是：

这里 AI 依然可以完成绝大多数代码。

关键只是：

不要把反馈周期拉得太长。

12开放式问题：判断本身就是工作

最不适合简单无人化的，往往是这种问题：

游戏的核心乐趣是什么？

这个角色应该是什么感觉？

这个功能到底该不该存在？

为什么现在的枪不好玩？

这个世界观应该表达什么？

为什么这个动画虽然正确，却没有力量感？

这些问题困难的地方不是实现。

而是：

我们甚至还没有找到正确的评价函数。

当评价标准都在探索之中时，把整个过程自动化，实际上只是把「寻找方向」也交给模型。

AI 可以很好地帮助探索。

但「探索」和「生产」不是同一种自动化问题。

13游戏开发为什么尤其难以完全自动化？

游戏开发是观察这个问题非常好的领域，因为游戏中存在大量无法被简单 Unit Test 捕获的质量。

一个普通业务系统可能能够判断：

用户能不能登录？
订单金额算对了吗？
API 是否返回正确字段？

而游戏还需要判断：

这把枪爽不爽？
角色移动有没有重量？
镜头晃动是不是过头了？
这个关卡节奏是不是太拖？
NPC 看起来聪不聪明？
动画是不是“差一点意思”？
这个功能虽然能用，但它真的有必要吗？

编译器可以告诉你：

代码是否合法。

测试可以告诉你：

某个状态转换是否符合预期。

Profiler 可以告诉你：

一帧用了多少毫秒。

但不存在：

ASSERT(GameIsFun());

13.1游戏质量存在大量隐式评价函数

一个游戏功能最终体验，可以粗略想象成：

而且函数 $f$ 本身往往都没有被明确写出来。

它存在于设计者、玩家和整个作品语境之中。

这意味着游戏开发特别依赖：

短反馈循环。

改一点
→ 玩一下
→ 感受
→ 理解问题
→ 再改一点

如果把反馈推迟八小时：

模糊目标
→ AI 自动工作八小时
→ 生成大量资产与代码
→ 第二天第一次实际试玩

那么任何最初的方向偏差都可能已经传播到了几十个后续决定。

14「让 AI 跑一晚上」什么时候真的有意义？

让 Agent 在无人值守状态下工作，本身完全没有问题。

真正的问题是：

它这一晚上到底在搜索一个什么空间？

14.1好的 Overnight Agent：在明确空间中搜索

例如：

在不改变输出结果的前提下，把这个算法优化到 benchmark 低于 4 ms。

或者：

修复所有失败测试，但不得修改测试本身。

或者：

尝试不同参数组合，找出满足误差要求的候选方案。

它们形成了完整闭环：

这种任务即使运行几个小时也可能很有价值。

因为 Agent 不是单纯「做更多」。

它是在：

有反馈地搜索。

15坏的 Overnight Agent：自己定义问题，再证明自己成功

另一种结构则危险得多：

例如：

一晚上帮我把这个游戏变得更好玩。

这不是因为 AI 不够聪明。

而是因为整个闭环缺乏独立的 Ground Truth。

生产者、评审者、成功标准全部来自同一个认知系统。

AI 完全可能得到一个内部非常自洽的结论：

已成功显著提升游戏体验。

但第二天人真正打开游戏：

这到底做了些什么？

16为什么延迟反馈会放大错误？

假设一次决定存在微小偏差。

如果下一步立即获得反馈：

Decision
→ Reality
→ Correction

偏差传播距离很短。

而如果在第一次真实反馈之前进行了十层依赖：

错误假设
→ 架构
→ API
→ Gameplay
→ UI
→ Test
→ Documentation

后续每一层都可能建立在最开始那个错误假设之上。

可以把它粗略理解为：

因此优秀的 Agent 系统通常不是单纯追求：

Autonomy 越长越好。

而是追求：

在尽可能长的自主执行过程中，保持足够密集的真实反馈。

17Benchmark 的「长任务能力」不等于可以放心托管

Agent 能够独立完成越来越长的软件任务，是一个真实而重要的趋势。

METR 使用「Task-Completion Time Horizon」来衡量：在人类需要某段时间完成的一类任务中，Agent 达到某个成功率时对应的任务长度。到 2026 年，他们已经测到 Frontier Agent 能处理明显比早期长得多的软件任务。⁵

但 METR 自己也特别提醒，不能把这个指标解读成：

「50% Time Horizon 是 5 小时，所以所有五小时以内的任务都可以放心交给 AI。」

原因包括：

• 不同领域的能力差异可以非常大；
• benchmark 与真实工作在上下文、任务清晰程度和「脏乱程度」上存在差异；
• 50% 成功率对很多真实生产任务远远不够；
• 对高可靠性、难验证的任务，实际需要的成功概率可能高得多；
• 自动化的真实收益还必须扣除提示、等待、检查、返工和人工接管的时间。⁵

这揭示了一个很重要的区别：

Capability 不等于 Delegability。

Agent 有能力完成一个任务，并不意味着这个任务已经适合无人托管。

18「AI 提升生产力」也不是一个脱离场景的问题

2025 年，METR 曾对 16 名熟悉自己大型开源仓库的经验开发者进行随机对照实验：在当时主要使用 Cursor 与 Claude 3.5/3.7 Sonnet 的条件下，允许使用 AI 的任务平均完成时间反而增加了约 19%。值得注意的是，开发者本人此前预计 AI 会让他们更快。⁶

这个结果很容易被误读成：

AI 编程没有生产力。

但研究团队自己明确反对这种泛化。

这项实验研究的是一个非常具体的场景：

• 2025 年早期工具；
• 经验丰富的开发者；
• 自己已经非常熟悉的成熟仓库；
• 平均约两小时的真实 Issue。

它不能直接代表其他人群、其他工具或未来模型。

到了 2026 年，METR 尝试用更新 AI 工具继续进行类似实验时，又发现新的实验设计受到明显选择偏差影响：越来越多开发者不愿意参加「禁止使用 AI」的任务，因此研究团队认为新数据不足以可靠估计当前 AI 对开发效率的真实提升幅度。⁷

这里真正值得留下的结论不是某个固定百分比。

而是：

真实生产力必须在真实工作流里测量，不能从 Demo、Token 数量、Benchmark 分数或者主观感觉直接推导。

19Workflow 为什么容易变成 Workflow Theater？

可以把一种常见现象称为：

Workflow Theater

这不是一个严格的学术术语，而是一种工程上的描述：

流程本身看起来非常先进，但流程创造的价值没有得到同等程度的验证。

19.1可展示性和价值并不是同一个变量

例如下面这个 Dashboard：

Agents Running        12
Tasks Completed      486
Tokens Used        9.4 M
Files Generated      327
Pull Requests         28
Automation Rate      91%

每个数字都是真的。

但这些数字没有回答：

产品变好了吗？

甚至没有回答：

人真的节省时间了吗？

19.2为什么组织容易奖励这种东西？

因为过程指标通常比结果指标更容易观察。

「今天跑了 300 个 Agent Task」非常容易量化。

而：

这套架构是不是比原来更容易维护？

可能要几个月之后才能知道。

这个 Gameplay Feature 到底有没有让游戏更有趣？

甚至很难形成统一数字。

于是组织很容易出现一种代理指标替代：

真实目标
↓
寻找可测量指标
↓
指标越来越重要
↓
团队开始优化指标
↓
指标与原始目标逐渐分离

这不是 AI 独有的问题。

但 AI 极高的生成速度，使这种现象更加明显。

19.3Dashboard 并不是问题

这里也不应该反过来把 Dashboard、Tracing 或 Metrics 当成坏东西。

恰恰相反，真正的 Agent 系统非常需要：

• Trace；
• Eval；
• Cost；
• Latency；
• Failure Rate；
• Human Escalation Rate；
• Regression Tracking。

OpenAI 当前的 Agent Eval 工具就是为了分析整个执行 Trace 中模型选择了什么工具、什么时候 Handoff、哪里违反规则，而不仅仅观察最终一句输出。³

真正的问题是：

测量过程，是为了改善结果；还是结果已经被「可展示的过程」替代？

20AI Slop：当生产本身不再稀缺

「AI Slop」通常被用来描述大量低价值、低判断密度、批量生成的 AI 内容。

在软件和游戏开发里，它不一定表现为垃圾文字或垃圾图片。

它还可能表现为：

• 没有人需要的后台管理系统；
• 为了「完整」而添加的排行榜；
• 不服务核心体验的每日任务；
• 多余的抽象层；
• 自动生成但没有人真正理解的测试；
• 看似专业却没有实际用途的文档；
• 为了使用 Multi-Agent 而制造出的 Agent 组织结构。

问题并不是这些功能本身一定不好。

问题是它们非常容易回答：

「还能做什么？」

却没有回答：

「为什么要做？」

20.1AI 非常擅长扩张

给 AI 一个系统，它很容易想到：

Analytics
Achievements
Leaderboard
Admin Panel
Cloud Sync
Recommendation
Daily Task
Notification
Plugin System
AI Assistant

每一个都能够解释出合理用途。

而优秀产品往往依赖另一种能力：

删掉那些单独看都合理、但整体并不需要的东西。

当生产成本不断降低，这种删减能力反而会更加重要。

21为什么成熟的 AI 工程可能反而更简单？

AI 行业很容易产生一种直觉：

Prompt
<
Workflow
<
Agent
<
Multi-Agent
<
Autonomous Organization

仿佛架构层级越高，就代表技术越先进。

实际上，它们更像是不同工具。

21.1Agent 越多，不代表系统越先进

每增加一个 Agent，都引入新的系统边界：

• Context 如何传递？
• 谁拥有最终状态？
• 两个 Agent 意见不同怎么办？
• 谁判断 Handoff？
• 错误如何传播？
• Trace 如何重建？
• 权限如何划分？
• Token 与延迟如何增长？
• 谁拥有最终责任？

因此 Multi-Agent 不只是：

它还增加了：

如果任务原本一个 Agent 就能可靠完成，增加三个 Agent 并不会自动带来更好的系统。

Anthropic 的建议非常明确：成功不在于构建最复杂的系统，而在于选择适合问题的系统；只有当额外复杂度能够被证明改善结果时才应该加入。¹

OpenAI 当前 Agents SDK 的设计文档也直接建议从一个职责清晰的 Agent 开始，只有在确实需要独立职责、不同指令、不同工具或不同审批策略时，才增加更多 Agent。⁸

21.2一个成熟系统可能非常朴素

很多强大的开发流程最终可能只是：

没有十二个 Agent。

没有复杂 Dashboard。

没有角色扮演式的：

CEO Agent
CTO Agent
Product Manager Agent
Senior Engineer Agent
Reviewer Agent

只有：

• 一个足够强的模型；
• 足够好的上下文；
• 几个真正需要的工具；
• 一个可靠的环境反馈；
• 一个知道自己想要什么的人。

这已经可以产生极大的杠杆。

22先找到正确流程，再自动化稳定部分

这其实并不是 AI 时代才出现的原则。

工业自动化长期以来都遵循类似逻辑。

工厂并不是：

我们不知道汽车怎么制造，所以搭建一座无人厂，让机器自己想办法。

而是：

理解生产过程
↓
拆解生产步骤
↓
建立质量标准
↓
稳定工艺
↓
自动化重复部分
↓
持续监控和改进

AI 真正改变的是：

可自动化的范围突然扩大了。

过去只有高度确定性的机械步骤容易自动化。

现在，一部分包含自然语言、视觉理解、代码生成和动态决策的认知工作也开始进入自动化范围。

但是：

可自动化边界扩大

并不意味着：

自动化的基本原则消失。

23从 AI-first 到 Intent-first

很多团队会说：

我们要做 AI-first。

如果它表示：

在每一个工作环节主动思考 AI 能否降低成本，

这是有价值的。

但如果它逐渐变成：

我们必须尽可能使用 AI、Agent 和 Workflow，

逻辑就反过来了。

更合理的顺序应该是：

也就是：

Intent-first，AI-amplified。

24人应该保留什么？

可以粗略把职责划分成三层。

24.1Why：主要由人负责

为什么要做？

它解决什么问题？

它值得存在吗？

这个功能服务整个产品的什么目标？

这是最难外包出去的一层。

因为它涉及：

• 价值选择；
• 产品方向；
• 审美；
• 风险偏好；
• 对用户的理解；
• 对现实环境的判断。

24.2What：人与 AI 共同探索

产品应该长什么样？

系统应该有哪些约束？

哪些方案值得尝试？

AI 在这里非常强。

它可以：

• 提供候选方案；
• 找反例；
• 搜索资料；
• 比较 trade-off；
• 建立原型；
• 快速尝试多个方向。

但是最终仍然需要 Quality Bar。

24.3How：AI 可以承担越来越多

真正的执行层正在被快速压缩：

• 写代码；
• 查资料；
• 修改接口；
• 写测试；
• 重构；
• 生成文档；
• 执行命令；
• 搜索实现；
• 修复错误；
• 尝试方案；
• 批量处理。

这正是 AI 最强大的地方。

于是未来优秀开发者的工作可能越来越不像：

每一分钟都在亲手输入代码。

而更像：

定义问题、建立环境、设计反馈、判断结果，并在关键位置亲自介入。

25在建立 AI Workflow 之前，可以先问这几个问题

如果一个任务准备被做成自动化 Workflow，可以先回答：

最后一个问题尤其重要。

因为它把讨论重新拉回：

Intent。

26Automation follows understanding

AI 正在创造一种非常特殊的生产环境。

过去人类长期面对的问题是：

想法很多，但生产能力有限。

而 AI 开始把这个问题反过来：

生产能力越来越接近无限，但注意力、判断力和品味依然有限。

因此未来真正有价值的能力，可能不仅仅是：

会不会使用 AI。

甚至也不仅仅是：

会不会设计 Agent Workflow。

而是：

能否理解自己正在做什么，知道为什么做，知道什么叫做好，并且知道什么时候应该停止生产。

这也是「理解先于自动化」真正想表达的东西。

AI 可以让一个正确流程变得极其高效。

也可以让一个错误流程以前所未有的速度扩张。

真正决定二者区别的，不是 Agent 数量，不是 Token 数量，也不是自动化百分比。

而是生产系统背后是否存在一个清晰的意图、可靠的反馈和能够做出判断的人。

当生产不再稀缺，真正稀缺的是知道什么值得生产。