机器人已经就位，但需求由谁来提供？

Agentic Coding 为什么可能改变领域知识与决策的供给、工程角色，以及产品开发的组织方式。

升级了设备，却没有原料的工厂

设想一座工厂，多年来一直按照某个固定节奏生产。机器、工作流程和可用工时，决定了员工最多能做出多少产品。原料供应、生产计划和质量控制也围绕这个产能安排。整个系统或许并不快，但各部分还算匹配。

后来，公司投资购置了新机器人。多个工序突然可以并行，重复性工作实现了自动化，生产本身需要的人工干预也大幅减少。人们首先讨论的，自然是新机器的生产率，随后很快就会问：以后还需要多少员工？

只是，没有人调整原料供应。

新生产线的产能提高了很多，送来的可用原料却没有相应增加。机器的能力令人印象深刻，但作为一个生产系统，工厂并不会因此自动变得更高效。

每当关注当下围绕 Coding Agent 的讨论，我都会想起这个画面。我们谈论代码能生成得多快、多少任务可以并行，以及哪些工作过去需要整个开发团队完成。相比之下，我很少听到后续的问题：组织怎样才能确保，这些新增的实现能力用在了正确的问题上？

当然，软件不是流水线产品。需求也不是可互换的原料，并非从一端投进去，就会从另一端得到成品功能。在复杂产品中，对问题的理解和解决方案往往共同演进。不过，这个比喻仍然帮我看清一种可能的新瓶颈：我们让生产实现了自动化，却对领域知识和决策的供给照旧安排，仿佛它所面对的要求没有发生变化。

仅有更多实现能力，并不自动带来更高吞吐量。工厂只是比喻：需求和解决方案会通过反馈共同演进。

查看原尺寸图片

三条工作流，不等于同时进入三个新领域

在个人开发中，我正在有意识地探索，怎样合理地并行使用多个 Coding Agent。比如，我会同时推进三条不同的工作流：一个功能正在收尾；另一个功能在完善业务和视觉概念，并开始初步实现；还有一个部分，我在定义新的主题并比较不同方案。

这种安排可行，是因为这些工作对注意力的要求很不一样。功能的主要决策一旦确定，Agent 就可以相对独立地实现或修正。与此同时，我可以思考一个 UX 点子、审阅设计，或者准备下一个业务决策。我并不是想同时理解三个陌生领域，而是想合理使用有限的注意力，让 Agent 尽量少等我。

我很喜欢这种并行方式，但它不会神奇地增加我的认知容量。三个 Agent 可以同时修改代码，我却无法同时以同样的深度思考三个复杂决策，再可靠地验收三个结果。因此，选择哪些工作流并行，几乎比并行多少条更重要。

在日常工作中，我有时会遇到相反的情况。多个产品都需要维护和继续开发，却没有足够多已经澄清、排好优先级的业务需求进来。这时，我可以改善架构、偿还技术债务，或者整合现有结构。这些工作有价值，我也确实乐在其中，但它们并不会自动形成产品的业务路线图。

遇到这种情况，有时会听到一句话：“你只要把业务弄明白，不就能自己定义需求了吗？”

对我来说，真正的思维误区就从这里开始。并不是开发者不该理解业务，而是我们经常把三件事混为一谈：理解领域问题、参与设计业务解决方案，以及有权决定究竟应该采用哪些业务规则。这些工作彼此相关，却未必具有相同的前提，需要相同的专业能力，或者承担相同的责任。

八天地理信息开发，却不必成为地理信息专家

最近的一个项目让我看到，当前提具备时，事情可以做到什么程度。我需要在一个已有应用中实现相当复杂的地理信息功能，涉及几何对象、向量、地理边界、计算及其地图呈现。这并不是再做一个 CRUD 页面，背后有不少我并不熟悉的领域知识和数学关系。

地理信息本身就是一个独立的专业方向。德国经济研究所一项于 2025 年发表的研究指出，2023 年德国在“地理信息——专家级（硕士／Diplom）”这一界定很窄的职业类别中，有 1,694 名缴纳社会保险的受雇人员。这并不意味着德国只有 1,694 人能开发这类软件。它描述的是一个统计职业类别，而不是合格开发者的人数。不过，这个数字也说明，我不能把这项任务所需的领域专业知识视为理所当然。

我是软件架构师，不是地理信息专家。坦白说，项目开始时，我很怀疑我们能否按预想的方式解决这个问题。

但我们有一份质量罕见的详细需求规格说明书。它把领域层面的预期描述得非常准确，我们不必先发明地理规则，也不用根据含糊的例子猜测究竟想要什么结果。我们可以系统地对照现有实现与需求，找出差距，理解相关的数据模型和计算模型，再据此制定可执行的计划。

实际结果让我意外：规划两天，Agent 实现两天，评审 两天，验收两天。在这个总计八个工作日的过程中，验收时只发现了一个较小的渲染问题。

为了说明这次实现的规模：最终形成了近 5,000 行领域实现代码，以及约 10,000 行测试代码。尤其让我印象深刻的是，大约 800 个从业务需求出发设计的测试，让我们得以检查已描述的要求以及众多相关场景。这些都是根据个人实践取整后的大致数字，并非精确的科学测量值。

代码量本身不是质量指标，测试再多也不能保证业务上的正确性。不过，对我而言，这个规模足以说明技术实现的工作量。精确的规格说明为我们提供了基础，使我们能够系统地建模复杂问题，借助 Agent 实现，再通过大量具有业务依据的测试检查结果。由具备领域知识的人进行验收，仍然不可或缺。

我明确不想把它包装成生产率基准。编写规格说明书的投入，不包含在这八天之内。项目也并非从零开始：已有应用使我们能够把需求与现状进行比较。我同样没有做过受控对照，去测量不使用 Coding Agent 完成同样的工作究竟需要多久。

不过，这个时间分布仍然值得关注。八天中，只有两天用于 Agent 实现，其余六天用在规划、评审 和验收上。领域规格说明是事先已经完成的投入。真正的工程工作，是把它转化为可靠的解决方案，而不是顺便从头学会地理信息这门学科。

对我来说，这次经历有力地说明了合理分工可以多么有效，但这仍然是个人经验。只要所需的领域知识以可理解的规则、约束和可验证的预期呈现，经验丰富的工程师就不必精通每一门专业。不过，他必须看得出规格说明的边界在哪里，哪些技术问题还没有解决，以及何时需要真正的领域专家再次作出决定。

观察到的分配为 2 + 2 + 2 + 2 个工作日。不包含编写规格说明书的投入；单次实践经验，并非基准测试。取整后的大致规模：近 5,000 行领域实现代码、约 10,000 行测试代码，以及约 800 个从业务需求出发设计的测试。验收时发现一个较小的渲染问题。代码量和测试数量不保证业务上的正确性。

查看原尺寸图片

“你只要……”

这句话里还藏着第二个问题，如今我甚至觉得它更重要。事情很少始于组织明确要求每个开发者精通所有学科。期待往往是一步步增长的，而且每一步听起来都很合理。

你只要再多了解一点业务。你只要调整一下流水线。你只要顺手处理一下部署。当然，安全也应该从一开始就考虑进去。UX 你也可以参与。既然已经做到这里了，Kubernetes 或许也可以一起看看。

单独来看，每一个要求都可能合理。但加在一起，就构成了一份几乎没有人能完全满足的能力清单。软件工程本身已经包含许多独立的知识领域。前端、后端、分布式系统、数据库、平台工程、云基础设施、安全、可观测性、测试自动化和软件架构，并不能无限叠加到同一个人的专家能力上。每当我觉得自己对工程已经理解得差不多了，Kubernetes 又会从某个角落冒出来，提醒我还有东西要学。

现在，还要让每个开发者都成为领域专家吗？

我认识一些对业务流程充满热情的人。他们喜欢与用户合作，希望理解业务规则，最擅长的工作就在工程与产品的交界处。我们当然应该支持他们。另一些人主要热爱软件工程，想解决复杂的技术问题、设计系统、理解算法、建立清晰的抽象。他们也应该能沿着自己喜欢的方向成长。

对于两者都热爱的人，我反而格外谨慎。这种组合当然没有错，对团队也可能极其有价值。但恰恰是这些人，容易因为好奇、因为能做、因为想帮忙，也因为起初确实运转良好，而不断接下更多工作。组织很快就会学会：下一个悬而未决的问题，还是去找同一个人。

到某个时候，所有决定都必须经过他。原本格外积极的投入，变成了单点故障。热情也可能在大家意识到失衡之前，就已经变成了过载。

也许是我身为父亲的一面在说话。我无意剥夺任何人学习新事物、突破自身边界的乐趣。但学习意愿不是无限资源，对两门专业都感兴趣，也不等于同意长期独自承担两者的全部责任。

因此，我理解的跨职能，是团队共同具备完成工作所需的能力，而不是每个人都必须什么都会。这也是 Scrum Guide 对跨职能团队的基本理解。自管理不会消除不同角色的责任，更不会消除一个人长期能够承担的极限。

规格说明不能替代协作

读完我的 GIS 例子，很容易以为我想回到业务部门与 IT 之间的传统交接：业务人员写出完美的规格说明书，需求随后消失在开发团队里，几个月后再带着结果回来。

那是误解。好的规格说明不一定很长，也不必在开始实现前就彻底定稿。尤其是复杂需求，常常要通过共同建模、提问、原型和初步结果，才能真正被理解。在我们的地理信息项目中，也需要先核对现状、找出差距。它之所以可行，是因为有一个可靠的参照，而不是所有可能的问题都已经一劳永逸地得到解答。

需求工程描述的，正是这种跨学科协作。ISO/IEC/IEEE 29148:2018 涉及系统整个生命周期内的需求获取、分析、验证、确认、沟通和管理。标准也区分了两个问题：需求本身是否表达规范，以及它们是否真正描述了利益相关者想要的系统。此外，还要区分后续的技术验证，即实现的系统是否满足其规定的需求。

我并不因此主张增加官僚流程。恰恰相反，实现越快，简短、精确且可验证的决策就越有价值。一条明确的规则、一组好的示例数据、清楚的验收标准，或者一位能及时联系到的业务联系人，可能比充满未决表述的厚重文档有用得多。

开发者应该理解领域关系，发现矛盾，积极参与寻找解决方案。但作出业务决定的正当权限，必须留在有能力、也有权让决定生效的人和角色那里。理解医学数据模型，并不会让开发者有资格作出医学专业判断。测试通过，也不能把预先给错的业务规则变成正确规则。

所以，协作应该更紧密，而不是把双方隔得更开。我批评的是另一种现象：当组织缺少业务责任的承担者时，这份责任往往会悄悄转移给眼下能够实现功能的人。

Coding Agent 改变了怎样的供给关系

为什么这个老问题偏偏在现在更紧迫？因为技术实现可以加速，业务澄清却不会自动按同样的比例加速。

Agent 可以从一段描述推导出看似合理的数据模型、用户界面、服务、测试，以及跨多个文件的完整变更。这令人赞叹，在很多情况下也确实非常有用。但它也可能补上从未经有权负责的人确认过的业务假设。技术上的一致性，并不等于业务上的授权。

研究开始为这种区分提供初步线索。Fang 等人于 2026 年发表的预印本 ClarifyCodeBench，以包含六个模型的交互式基准，考察 LLM 能否主动识别含糊的需求，并通过追问进行澄清。结果提示，代码生成能力强，并不自动意味着需求澄清能力强。增加推理投入对识别歧义的改善有限，尤其在多种不明确之处同时出现时。

同样发表于 2026 年的 SpecBench，由 Hamblin 等人研究一种相关但不同的能力：让 Agent 在 Kubernetes、React、Rust、TVM 和 vLLM 的真实 RFC 设计提案中，识别遗漏、矛盾和错误假设。受评估的最佳 Agent 达到了 44.4% 的准确率。这不是 Product Ownership 的普遍错误率，也不能说明未来模型不会做得更好。它只表明，审查规格说明本身仍是一项有难度的独立任务，不能从一次良好的编码结果推定这项能力。

当然，AI 也可以改善上游的知识与决策供给。我自己就用它梳理业务问题、比较不同 UX 方案、暴露不明确之处，并把已经澄清的决定转化为具体实现任务。真正值得关注的边界，不是“AI 可以实现”与“AI 不能处理需求”，而是提出方案与有权确认方案在业务上成立之间的区别。

DORA 2025 报告把 AI 描述为组织既有优势与弱点的放大器。这与我的观察相符，却不能证明使用 Coding Agent 的企业必然会让 Product Ownership 成为新瓶颈。再往前推的这一步，正是我的假设。

与其数 Product Owner，不如看决策能力

过去，一位 Product Owner 能支持几名开发者，甚至不止一个团队，取决于成熟度、产品和复杂性。技术一侧需要完成的实现工作越多，准备新需求、协调既有决定的时间窗口也就越大。

如果 Coding Agent 显著压缩了一部分实现时间，业务准备与技术实现之间的平衡就可能变化。我最初的直觉是，在某些情境下，过去大约一位 Product Owner 对十名开发者的比例，可能需要变得紧密得多。但我不会据此推出一比一或一比三的新目标比例。毕竟，Product Owner 并不等于需求工程、UX、领域专业知识和验收工作的总和。

我更关心的是，每条同时活跃的工作流能获得多少决策能力。组织能及时回答多少业务问题？能有依据地评估多少 UX 概念？有多少需求已经具体到可以实现，并在之后按照可验证的预期验收？从提出问题到得到有约束力的答复，需要等待多久？

如果开发团队因为没有澄清好的需求，主要在自己寻找任务，这并不自动意味着开发者失职。同样，增加 Coding Agent 也不会自动填补这个空缺。只有先明确究竟要创造什么价值，更多产能才可能带来额外价值。

因此，解决方案未必是为每个 Agent 招聘一位 Product Owner。缺的可能是业务分析师、UX 能力、真正的领域专家、能够作出决定的产品负责人，也可能只是一个清楚的产品任务。即使角色分工再合理，如果找不到能对业务矛盾作出最终决定的人，也无济于事。

有时，正确的决定确实是不再生成更多代码。好的产品组织并不以让所有 Agent 始终满负荷运行为目标，而是交付正确的变更，避免那些不该做的变更。

箭头连接不同职责，并把新认识反馈到需求。实现之前可能出现的瓶颈仍是假设，不能据此推出固定人员比例，也不意味着瀑布流程。

查看原尺寸图片

工厂比喻背后的假设

根据这些经历，我提出一个尚未得到直接证据支持的假设：Coding Agent 对技术实现的加速越明显，产品组织的整体吞吐量，就越可能依赖于它能否提供经业务确认的需求，以及及时的决策。

其结果并不必然是在某个岗位增加人手，也可能是重新分配工作：更有意识地开展产品探索，更专业地进行需求工程，更好地做技术建模，更早获取 UX 反馈，并明确业务验收的安排。AI 同样可以支持这些活动，缓解其中一部分瓶颈。组织最终需要更多还是更少的人，只能结合具体情境判断。

对我来说，这里还有第二个维度，与人有关。如果一位热情的开发者已经负责前端、后端、架构和部署，实现所节省的时间不该自动成为理由，让他再承担所有业务决策、UX 问题和合规证明。否则，我们虽然把生产线自动化了，却把它的全部依赖集中到了一个人身上。

也许，让不同专业的人有效协作，会成为 Agentic Work 最重要的成功因素之一。领域专家提供本学科的深度，软件工程师把这种深度转化为模型和可靠的系统，Coding Agent 则承担那些结果能够被充分限定并验证的工作。所有参与者通过必要的反馈持续连接。

这不是回到瀑布模型，而是尝试组织好整个价值流，不让速度以责任不清为代价。

结语：工厂必须作为整体运转

地理信息项目让我意外，是因为它展示了经验丰富的工程能力，在良好规格说明和 Agent 支持下可以走多远，而技术实现者不必同时成为该领域的专业科学工作者。工作中需求不足的经历，则让我看到另一面：如果业务上还不清楚下一步该做什么，再出色的技术产能也可能无从发挥。

因此，我们不该把讨论局限在 Coding Agent 将来能替代多少开发者。我们同样需要研究，哪些前提会因此变得更重要，以及 Product Ownership、业务人员、需求工程、UX、架构和实现之间的工作分配将怎样变化。

我们也要小心，不要把愿意跨出自身专业范围的人，当作填补所有组织空缺的万能解法。跨职能团队可以具备广泛能力，单个开发者却不必同时是医生、地理信息专家、UX 设计师、平台工程师和软件架构师。

Coding Agent 的新能力令我印象深刻。也正因此，我不愿只用它生成下一次实现有多快来衡量成功。我越来越关心的是，组织能多可靠地把领域知识、有约束力的决定和良好的工程工作，转化为真正做对了事情的软件。

机器人已经就位。也许，我们终于该谈谈供给、生产计划和质量控制了。

来源与说明

本文区分个人实践经验（GIS 项目：规划两天、Agent 实现两天、评审 两天、验收两天；一个较小的渲染问题）、相关研究，以及明确保持开放的组织假设。八天不包含编写领域规格说明书的投入，也不是比较性生产率研究。

Burstedde, Alexander 与 Tiedemann, Jurek（2025）：Kompetenzbarometer – Fachkräftesituation in Digitalisierungsberufen bis 2028。德国经济研究所，表 3-1（2023 年受雇人员：地理信息——专家级，1,694 人）。研究报告。

ISO/IEC/IEEE 29148:2018：Systems and software engineering – Life cycle processes – Requirements engineering。标准。

Fang, Zheng 等（2026）：ClarifyCodeBench: Evaluating LLMs on Clarifying Ambiguous Requirements for Code Generation。预印本。

Hamblin, Grant 等（2026）：SpecBench: Evaluating Specification-Level Reasoning for Software Engineering LLM Agents。预印本。

DORA / Google Cloud（2025）：State of AI-assisted Software Development。

Schwaber, Ken 与 Sutherland, Jeff（2020）：The Scrum Guide。

系列延伸阅读：提示词工程，始于提示词之前 · 生成很便宜，验证很昂贵 · Agentic Work 的经济学 · 软件工程从来不只是写代码 · AI 正在加速我们走向“大泥球”——一个假设。