你有没有过这种经历？
一个需求过来，你拉上产品经理和几个技术骨干坐下来聊。第一轮讨论下来方向有了，但总觉得哪里不对。过两天有人说"我再想想"，回来之后推翻了一半的结论。又拉了一轮会，这回对齐了，但发现竞品已经换了个打法，得重新想。如此反复，两三周过去了，你手上没有任何可交付的东西，但对"到底要做什么"总算有了踏实的感觉。
然后你把定稿的方案交给研发团队。接下来的节奏完全变了：需求拆解、排期、开发、联调、测试、上线。每一天都有明确的产出，每一步都有清晰的验收标准。两周后，东西上去了。
同样是"做需求"，前面那段和后面那段的工作节奏根本不是一个物种。前面是水——流动、不确定、随时改道；后面是冰——固定、明确、按结构走。
大部分人看 agent demo 的时候，看到的是 agent 产出的惊艳效果：几分钟出一个完整原型，又快又好。这给人的感觉是"有了 agent，一个人就能搞定产品了"。但这个推理有一个隐藏的错位：agent 展现惊人能力的那个场景，处在第一阶段——快速产出供人选择和推翻的东西。而真正卡住的不是产出，是把产出变成可靠产品的那段路。
两条河的分水岭
让我们把这两段工作拆开来看。
第一段：从想法到定稿（Idea → Demo）。 核心问题是"做什么"。没有人知道答案，所以需要调研、讨论、返工、推翻重来。这段工作的本质是探索——每获得一个新信息，之前的决策可能就要推翻。工作节奏高度非线性：可能三天毫无进展，也可能一顿饭的功夫全想通了。Agent 在这段工作里分裂成两面：产出上极强——你给个方向，demo 立刻出来；判断上帮不上忙——它不能替你决定方向对不对。人主导判断，agent 负责快速产出供人选择。
第二段：从定稿到上线（Demo → Product）。 核心问题是"怎么做"。目标已经确定，剩下的工作是把它变成可交付的产品。这段工作的本质是执行——步骤可以预先规划，质量可以标准化，进度可以度量。但奇怪的是，agent 在这里反而卡住了。
| 想法→定稿 | 定稿→上线 | |
|---|---|---|
| 核心问题 | 做什么 | 怎么做 |
| 确定性 | 低，随时可能推翻 | 高，方向已定 |
| 工作模式 | 探索，试错 | 执行，收敛 |
| Agent 表现 | 产出极强，判断帮不上 | 每步都能做，整体不可靠 |
| 人的角色 | 判断者（决定方向） | 审核者（确认结果） |
这两段工作有什么本质区别？直觉上，第二段应该更容易——目标确定了，步骤明确了，agent 每一步也都能做。那为什么第一阶段反而更顺利？
为什么第一阶段沉淀不出标准流程
很多人会想："既然第一阶段这么混乱，我们能不能把它也标准化？"
不能。不是能力不够，是标准化在这里是成本而不是收益。
假设你试图给"需求探索"阶段定义一个标准工作流：第一步调研行业，第二步竞品分析，第三步技术可行性评估，第四步出方案。听起来合理吧？
然后实际情况来了：调研到一半发现方向错了，得重来。重来之后竞品分析不用做了，因为压根不是那个赛道。技术可行性倒是评估完了，但方案一评审就被产品否了——因为之前理解错了用户场景。你精心设计的工作流，在第一个变化面前就废了。
问题不在于你的工作流设计得不好。问题在于探索阶段的核心特征就是不确定性，而标准流程的前提是确定性。你无法为一个"不知道下一步干什么"的过程定义"下一步干什么"。
这不意味着第一阶段完全无章可循。它有自己的元工作流——怎么调研、怎么讨论、怎么决策、怎么评审——这些是相对稳定的。但"做什么产品"这个业务工作流，在探索完成之前，就是定不下来。
所以第一阶段也许不适合套用固定流程，而是用动态的、可迭代的方式，人主导，agent 辅助。这里的"动态"不是说没有流程，而是流程本身可以快速迭代。Claude Code 2026年5月推出的 dynamic workflow 是一个有意思的实践：Claude 会针对你描述的任务写一个 JavaScript 编排脚本，由 runtime 执行，脚本里包含步骤、循环、分支和中间结果。你跑一次，看哪里不对，改脚本，再跑。流程在试错中快速演进——不是"没有流程"，是"流程还在长骨头"。
为什么更强的阶段反而更难
一个反直觉的观察：第一阶段不确定，agent 反而跑得好；第二阶段目标明确，agent 反而跑不好。
让我试着从两个阶段的差异推导原因。
差异一：人介入的时机不同。 第一阶段，人全程在旁边——每一步产出都需要人判断"这个方向对不对"，人对 agent 的输出是即时响应的。agent 写了个方案，人立刻说"不对，重来"或者"可以，继续"。第二阶段呢？人不再逐步引导了。目标定了，人的角色从"每步陪着"变成了"最后看结果"。中间的过程，agent 自己走。
这意味着：第一阶段 agent 的好表现，可能不完全是因为它自己强——而是因为有人在每一步做纠偏。人的实时判断补上了 agent 的不可靠性。到了第二阶段，这个纠偏机制撤掉了，agent 就暴露了本来面目。
差异二：对可靠性的要求不同。 第一阶段的输出是半成品——方案可以推翻，demo 可以重来。一次产出不对，再生成一个就是了，成本很低。第二阶段的输出是交付物——代码要跑在生产环境，测试要覆盖边界条件，文档要通过评审。不是"大概对"就行，是每一步都必须做到位。
这两个差异叠加在一起，可能解释了为什么 agent 在第二阶段失灵：第一阶段可以容忍不可靠，因为人在实时纠偏，且试错成本低；第二阶段既没有实时纠偏，又不能容忍不可靠，agent 的固有不确定性就变成了致命问题。
如果这个推导是对的，那第二阶段的挑战不是"agent 能力不够"——每一步它确实都能做——而是：没有一种机制保证它按顺序做完所有步骤，且每一步都达标。
稳定的工作流可能是这个缺失的机制
这个推测让我想到一个问题：如果 agent 的核心困难是"不按步骤来"，那什么机制能让它按步骤来？
一个自然的答案是工作流——把"先做什么后做什么"提前定义好，让 agent 不需要自己判断执行顺序。但第一阶段的经验告诉我们，工作流不是什么时候都有效的：在探索期，强行定义步骤反而是成本。那为什么第二阶段就不同了？
因为第二阶段的目标是稳定的。步骤定义完了不需要推翻，因为"做什么"已经定了。这时候工作流从成本变成了投资——每一条步骤定义都会被反复使用，每一次执行都不需要重新判断顺序。
一个 10 步的开发任务，在没有工作流的情况下，agent 可能只完成 2 步就"决定"自己做完了。不是它做不了——它在 demo 里每一个步骤都能做。但在没有约束的情况下，它就是会跳步、混关、忘记之前的约定。这不是 bug，更像是 agency 的固有属性：有自主判断能力的执行者，就会做出自主判断，包括"我觉得这一步不需要做"。
如果用一个确定性的工作流来编排——步骤是预设的，顺序是固定的，跳过是不允许的——那 agent 不需要判断"该不该做这一步"，只需要执行。跳步的选项被系统性地移除了，可靠性就可能随之提升。
这只是推测，不是结论。"稳定工作流是第二阶段的关键缺失"这个假设需要实际验证：有工作流约束的 agent 和没有工作流约束的 agent，在同样的第二阶段任务上，可靠性的差距到底有多大？目前我没有看到严格的对照数据。但从经验上看，团队里那些"先写好流程再让 agent 执行"的做法，确实比"给 agent 一个目标让它自由发挥"的结果要可控得多。
两个阶段之间的信号
那么，怎么知道什么时候从第一阶段切换到第二阶段？
信号是：需求文档的变更频率从"每次会议都改"降到了"偶尔调整细节"。
这个信号说明探索收敛了——"做什么"有了稳定答案，剩下的就是"怎么做"。如果上面的推测成立，这时候固化工作流可能从成本变成了收益：每条流程定义都会被反复使用，因为目标不会再轻易推翻。
反过来，如果需求还在频繁变动，强行上稳定流程，每变动一次就得改一次流程定义，流程维护成本可能就超过了它提供的可靠性收益。
这个切换点不是时间线上的一个切点——不是"第三周切换"——而是一个可以被观察到的相变信号。关注需求稳定性，而不是日历。
从探索到执行：一种可能的路径
如果接受上面的推测——第二阶段需要稳定的、确定性的工作流——那下一个问题是：工作流从哪来？
一种可能是从第一阶段的探索中派生出来。不是事先设计好的，而是被验证过的实践沉淀下来的。大致过程：
- 让 agent 写编排脚本试跑──Claude Code 的 dynamic workflow 就是这个模式：针对你的任务，Claude 写一个 JavaScript 编排脚本，由 runtime 执行，编排几十个 subagent 协同工作。你跑一次，看结果，发现哪里不对
- 迭代脚本──改步骤、改分支逻辑、改中间结果的传递方式，再跑。每次运行都会把脚本存到文件里，你可以 diff 两次运行的脚本看变化
- 把验证过的脚本冻结为可复用命令──当脚本稳定下来，跑出来的结果反复符合预期，按
/workflows选中这次运行，按S保存。脚本变成项目级（.claude/workflows/）或用户级的 slash command，下次直接/<workflow名>执行，不需要再让 Claude 重新设计编排逻辑
Claude Code 的这个路径，看起来像是"先派生再固化"：脚本在动态运行中被迭代验证（派生），验证过的脚本保存为确定性命令（固化）。注意这不是从"建议"变成"强制"——脚本从一开始就是程序化执行的，不是建议性的。变化的是脚本的成熟度：从"试错中的草稿"变成"验证过的定稿"。
这种路径是否真的比"先写工作流再让 agent 执行"更有效？直觉上是的——因为你无法事先设计出你还没见识过的模式。第一阶段的混乱不是需要被消除的噪音，它可能包含了你设计第二阶段工作流所需的全部信号。但这还没有被充分验证。
最大的错觉：一条流水线走到底
回到开头的问题。"一个人加 agent 就能搞定产品"——这个判断可能是对的，但前提是你得意识到"搞定产品"穿过了两个结构不同的阶段。
第一阶段，agent 的产出速度掩盖了判断力的缺席——人在旁边拍板，所以产出看起来总是对的。这容易让人产生一种感觉：agent 这么强，接下来应该也这么顺吧？但到了第二阶段，人不再逐步引导了，agent 的能力没有变弱，但没有实时纠偏的条件下，不确定性就暴露出来了。
我的推测是：这两个阶段需要不同的"让 agent 可靠"的机制。第一阶段靠人的实时判断；第二阶段可能需要某种确定性的约束——工作流是当前能想到的最自然的候选。但这是假设，不是结论。实际哪种约束最有效，多大程度的工作流定义是必要的，可能还需要在实践中摸索。
两条河的分水岭，大概就是"想清楚要做什么"的那个瞬间。在这之前，你需要人的判断力来驾驭 agent 的产出能力；在这之后，你需要某种系统化的约束来释放 agent 的执行能力。两者都需要 agent，但可能需要完全不同的工作方式。
把这两段混成一条流水线，你得到的可能不会是更高效的线——而是一条在第一阶段被流程卡死、在第二阶段又缺乏约束的线。
两条河，两条航道。别把它们挖成一条。
参考文献
- Anthropic Research. Building Effective Agents. https://www.anthropic.com/research/building-effective-agents — 论述 workflow 从 dynamic 到 static 的演进路径；composable patterns 作为 agent 可靠性基础设施
- WeZZard (@realWeZZard). X/Twitter post (2026-06-04). https://x.com/realWeZZard/status/2062105579649380748 — 触发本文讨论的推文；关于 demo 与 product 之间结构性差异的实践观察
- Breunig, D. (2026). Two Beliefs About Coding Agents. — "personal software vs capital-P Products" 区分；demo 环境消除失败条件的论述
- Anthropic. Claude Code Dynamic Workflows (2026-05-28, v2.1.154). https://docs.anthropic.com/en/docs/claude-code/workflows — dynamic workflow 核心机制：Claude 写 JavaScript 编排脚本，runtime 执行，脚本可迭代修改，验证后可保存为 slash command 复用