全栈化浪潮带来的启示：数字员工与开发工作台的设计抉择

从产研融合、全栈化与 DRI 责任制出发，分析研发组织为何从职能交接转向端到端结果负责，并讨论数字员工与开发工作台面临的关键设计抉择。

系列：从零构建企业级 AI Agent · 第 04 篇

越来越多的组织开始讨论产研融合、全栈化和项目 DRI：产品、前端、后端、测试与运营之间的边界正在变得模糊，一个人或一个小团队被要求对更完整的结果负责。

这类变化很容易被概括成“人人都是产品经理”或“人人都要做全栈”。如果只从岗位名称理解，它似乎是在要求每个人掌握更多技能；但从组织运行方式来看，更深层的变化是：

软件研发的责任单位，正在从单一职能和局部任务，转向端到端的产品结果。

与此同时，Coding Agent、生成式 UI、自动测试和智能运维工具降低了跨角色执行的门槛。开发人员可以更快地分析需求、制作原型、补充测试和排查运行问题；产品人员也能借助 AI 完成数据分析、原型验证和简单实现。

那么，角色融合是否意味着专业分工即将消失？全栈是否会成为所有人的必备形态？当我们设计研发数字员工时，应该为每一个传统岗位分别创建一个 Agent，还是围绕端到端交付重新组织能力？开发人员工作台又应该继续按 Bug、代码、流水线等工具模块组织，还是以产品需求为中心？

本文尝试回答这些问题。

一、角色融合的本质不是“一个人做所有工作”

1.1 传统研发组织以职能分工降低专业门槛

传统软件研发经常被组织成一条职能流水线：

产品定义需求
→ 设计输出交互
→ 前端和后端分别实现
→ 测试负责验收
→ 运维负责发布
→ 运营收集反馈

这种结构的价值很清楚：每个角色可以在自己的领域形成专业深度，组织也能用相对稳定的岗位和流程管理复杂项目。

但它也产生了大量交接：需求文档交给开发，接口交给前端，代码交给测试，发布包交给运维，用户反馈再从运营回到产品。每一次交接都可能丢失上下文，并引入等待、误解和重复沟通。

当执行成本较高时，专业化带来的收益大于交接成本；当工具和自动化显著降低执行成本后，交接本身就会变得更加突出。

1.2 全栈化首先是责任范围扩大

所谓全栈，至少包含三种不同含义：

1. 技术全栈：能够跨前端、后端、数据、基础设施等技术层工作。
2. 产品全栈：能够从用户问题、产品判断一直参与到实现和效果验证。
3. 交付全栈：能够持续推进设计、开发、联调、CR、测试、发布和反馈闭环。

真正影响组织的，往往不是要求每个人成为所有技术领域的专家，而是要求一个人或一个小团队能够覆盖更长的交付链路，并对最终结果保持连续责任。

这也是 DRI 制度的核心价值。DRI 不代表一个人必须亲自完成所有任务，而是意味着项目不能在多个角色之间漂移，必须有人持续掌握目标、进展、风险和决策，并在需要时调用合适的专家与资源。GitLab 对 Engineering DRI 的描述也明确指出，DRI 负责推进和协调复杂工作，但并不等于亲自执行每一个任务。

1.3 专业分工不会消失

角色融合不意味着安全、架构、数据库、算法和基础设施等专业能力不再重要。

更可能出现的形态是：

广度成为默认能力，深度成为按需调用的专业能力。

一个端到端负责人可以理解并推进完整流程，但在高风险安全变更、复杂数据迁移或重大架构决策中，仍然需要专业人员参与甚至拥有阻断权。

因此，角色融合不是把所有岗位压缩成一个岗位，而是重新安排责任和协作方式：减少不必要的职能交接，同时保留真正有价值的专业判断。

二、为什么角色融合正在加速

2.1 AI 降低了跨领域执行成本

过去，一个后端开发想完成产品分析、前端页面和测试自动化，需要跨越多个知识和工具门槛。现在，AI 可以辅助：

• 整理用户反馈和需求背景。
• 生成交互草图与页面代码。
• 解释陌生代码和框架。
• 编写单元测试、接口测试和脚本。
• 查询日志并归纳异常模式。
• 生成发布说明和操作文档。

AI 并没有自动赋予使用者专业判断，但显著降低了开始执行和跨越工具边界的成本。原本必须等待另一个岗位完成的工作，一部分可以由当前负责人在 AI 辅助下直接推进。

2.2 小团队需要更短的反馈回路

软件价值并不在代码合并时产生，而是在功能到达用户并获得验证时产生。

如果需求、开发、测试和反馈分别由不同团队排队处理，即使每个局部环节都很高效，整体周期仍可能很长。DORA 将从想法到客户的工作可见性、客户反馈、小批量交付和团队自主性视为精益产品管理的重要能力；其松耦合团队实践也强调，小团队需要尽量独立地完成修改、测试和发布。

角色融合的目标不是让每个人更忙，而是缩短从问题到结果的反馈回路。

2.3 工作重心从“执行步骤”转向“组织能力”

当代码生成、测试生成和工具调用逐渐自动化后，人的价值会更多集中在：

• 判断真正需要解决的问题。
• 建立完整而可靠的上下文。
• 在多个方案之间进行权衡。
• 决定风险和授权边界。
• 验证结果是否满足业务目标。
• 在不确定情况下组织协作。

软件研发越来越像是对人员、Agent、工具和企业系统的组合与调度。能够连续理解目标并组织这些能力的人，会比只完成某个局部操作的人拥有更大的杠杆。

三、角色融合不等于取消流程

角色边界变得模糊，不代表研发流程失去意义。

一项产品需求仍然可能经历：

需求规划
→ 方案设计
→ 开发
→ 联调
→ Code Review
→ 提测
→ 测试
→ 待发布
→ 发布
→ 效果观察

变化的是，同一个人或同一个小团队可以覆盖更多阶段，不再需要每经过一个阶段就把全部上下文交给另一个职能部门。

流程在这里承担三类职责：

• 表达阶段：当前工作进行到哪里。
• 设置门禁：进入下一阶段需要什么检查和证据。
• 协调参与者：当前由谁执行、等待谁反馈、谁拥有最终责任。

Agent 可以在阶段内部动态决定如何完成任务，但不能因此取消组织的权限、质量和审计要求。

例如，Agent 可以自行决定如何完成联调：先检查接口契约、启动依赖服务、构造请求还是查询日志。但“联调是否完成”不应只由模型口头宣布，而应由接口验证结果、关键场景记录和未解决阻断项等证据共同决定。

因此，角色越融合，越需要一套清晰而轻量的工作状态来避免责任和信息重新变得模糊。

四、研发数字员工不能只是 Coding Agent

如果研发岗位正在从局部编码走向端到端交付，那么研发数字员工也不能只被定义为“能够修改代码的 Agent”。

Coding Agent 擅长：

• 阅读和修改代码。
• 执行命令与测试。
• 分析编译和测试失败。
• 生成 Diff 与提交说明。

研发数字员工则需要在更长的时间范围内持续工作：

• 理解产品需求和验收标准。
• 参与技术方案设计。
• 拆分开发任务。
• 调用 Coding Agent 完成代码修改。
• 支持前后端或跨服务联调。
• 创建 Draft PR/MR 并响应 CR 意见。
• 处理测试阶段 Bug。
• 跟踪构建、部署与测试结果。
• 在飞书群等协作入口接收任务并反馈进展。
• 在等待外部事件后恢复原任务。

二者的关系更接近员工与专业工具：

研发数字员工
├── 持续身份与项目职责
├── 产品需求上下文
├── 任务、状态和时间线
├── 需求与方案能力
├── 联调、测试与协作能力
├── 企业系统工具
└── Coding Agent

开发数字员工的第一个闭环可以是处理测试 Bug，但它不能因此被建模成一个“修 Bug 机器人”。Bug 只是产品需求在测试阶段产生的子工作，完整上下文仍然属于产品需求。

五、不要照搬组织架构创建一组割裂的 Agent

一种直观设计是：产品 Agent 负责需求，开发 Agent 负责编码，测试 Agent 负责测试，运维 Agent 负责发布。

这种结构看似对应现有组织，实际上可能把人工流程中的交接问题重新复制到数字系统中：

• 每个 Agent 只持有局部上下文。
• 状态需要在多个 Agent 之间重复同步。
• 出现问题时难以判断谁继续负责。
• 多个 Agent 可能分别优化自己的局部目标。

在项目早期，更适合的形态是一个持续参与需求交付的开发数字员工，在内部按任务调用不同能力：

开发数字员工
├── 需求理解能力
├── 技术方案能力
├── 编码能力
├── 联调能力
├── CR 处理能力
├── 测试与修复能力
└── 发布观察能力

当安全审查、架构评审、测试设计等领域确实需要独立专业深度时，再引入专业数字员工或专业审查 Agent。

换句话说：

先形成一个端到端执行者，再按真实协作需要引入专业协作者。

这与 Anthropic 对 Agent 架构的建议也是一致的：从能够解决问题的简单、可组合方案开始，只在任务复杂度确实需要时增加多 Agent 和复杂编排。

六、工作台应该从“工具集合”转向“需求驾驶舱”

如果工作台仍然按照 Bug、代码、流水线、消息等工具分类组织，开发人员和数字员工仍然需要自己完成上下文拼装。

更合理的中心对象是产品需求：

ProductRequirement
├── 目标、范围与验收标准
├── 技术方案
├── DevelopmentTask
├── 联调状态
├── Commit 与 PR/MR
├── Bug
├── 构建、部署和测试结果
├── 发布状态
└── 时间线、证据与决策

其中：

• ProductRequirement 是研发全流程的主对象。
• DevelopmentTask 是需求的实现拆分。
• Bug 是测试阶段发现的缺陷，拥有独立状态机。
• Run、Artifact、Evidence 和 Approval 记录执行过程、产物、证据和人工检查点。

需求驾驶舱应该直接回答：

• 需求当前处于哪个阶段？
• 谁是 DRI，谁是当前执行者？
• 当前阻塞是什么？
• 下一步应该做什么？
• 数字员工正在执行什么？
• 哪些动作需要人工批准？
• 当前结论由哪些证据支持？
• 是否存在阻止测试通过或发布的 Bug？

这比再增加一个 AI 输入框更接近真实研发工作的需要。

七、能力可以融合，责任与权限不能混在一起

一个数字员工可以同时拥有需求理解、编码、联调和测试能力，但它是否可以执行某个动作，必须由任务上下文、授权和风险共同决定。

需求中的角色至少应该区分：

• DRI：对需求交付结果持续负责。
• Executor：当前实际执行某项任务的人或数字员工。
• Reviewer：提供代码、方案或质量审查。
• Approver：对高风险动作进行批准。
• Specialist：在安全、架构、数据等领域提供专业判断。

一个典型状态可能是：

需求 DRI：张三
当前阶段：联调
当前执行者：开发数字员工
专业协作者：支付平台负责人
待人工处理：确认接口兼容方案

在企业采用早期，数字员工可以承担大量执行工作，但最终责任仍应明确落在人类 DRI 或组织角色上。

同样，能力融合不能自动扩大权限。一个研发数字员工可以读需求、分析代码、运行测试和创建 Draft PR，但合并代码、更新关键业务状态、发布生产等动作仍然需要满足门禁或经过审批。

角色融合真正要求的是更细的动作级授权，而不是一个笼统的“允许 Agent 工作”。

八、Workflow 与 Agent 应该如何配合

角色融合之后，Workflow 的价值不是模拟部门之间的工单流转，而是为端到端工作提供可靠底座。

可以把两者的边界概括为：

确定性流程
├── 阶段与合法状态
├── 权限与审批
├── 进入条件和质量门禁
├── 等待、重试和恢复
└── 证据与审计

Agent
├── 理解需求和反馈
├── 规划阶段内任务
├── 选择工具
├── 分析异常
├── 生成方案与代码
└── 根据结果调整行动

稳定的研发主流程仍然可以是：

方案设计 → 开发 → 联调 → CR → 提测 → 测试 → 发布

Agent 在每个阶段内部处理无法预先穷举的具体问题；确定性程序负责判断是否满足进入下一阶段的条件。

这使工作台既不会退化成僵硬的流程画布，也不会把所有真实副作用交给不受约束的模型。

九、如何衡量研发数字员工的价值

如果数字员工的目标是端到端交付，就不能只用代码生成量、模型调用次数或自动修改文件数衡量价值。

更有意义的指标包括：

• 需求从开始到发布的周期是否缩短。
• 等待和跨角色交接时间是否减少。
• 联调和 CR 阶段的阻塞是否更早暴露。
• Bug 从发现到已修复、验证和关闭的时间是否缩短。
• 变更失败率和返工是否增加。
• 数字员工有多少行动需要人工接管。
• 人工接管是否发生在真正需要判断的节点。
• 需求状态、风险和证据是否更加透明。

角色融合的目的不是让一个人承担更多孤立任务，而是提高价值流动效率。数字员工也应该以相同标准接受评估。

十、从第一个闭环走向企业数字员工

研发数字员工可以按照以下路径逐步演进：

第一阶段：建立正确的工作模型

• 以产品需求作为主对象。
• 区分开发任务与 Bug。
• 明确设计、开发、联调、CR、测试和发布阶段。
• 建立 DRI、执行者、审查者和审批者边界。

第二阶段：连接真实研发系统

• 读取云效项目和测试 Bug。
• 关联需求、代码仓库和测试环境。
• 汇聚 PR、CI、部署和回归证据。

第三阶段：完成第一个主动式闭环

测试 Bug
→ 分析上下文
→ 修改代码
→ 自测与联调
→ 创建 Draft PR
→ 跟踪 CR、CI 和部署
→ 标记已修复
→ 等待回归结果

第四阶段：进入团队协作

• 加入飞书项目群。
• 接收任务、Bug 反馈和补充信息。
• 主动反馈进度、风险和等待事项。
• 在外部事件到达后恢复长期任务。

第五阶段：扩展端到端能力

• 需求分析和验收标准生成。
• 技术方案设计和任务拆分。
• 发布观察和线上问题处理。
• 根据用户和运营反馈推动下一轮迭代。

最终目标不是制造一个无边界的通用 Agent，而是形成一个围绕产品需求持续工作、能够跨越研发多个阶段，并在权限和流程约束下交付结果的企业数字员工。

十一、总结：围绕结果重新组织人、Agent 与工具

产研融合和全栈化并不意味着每个人都要成为所有领域的专家，也不意味着传统专业能力失去价值。

它们反映的是三个更深层的变化：

1. 责任从局部职能转向端到端结果。
2. AI 降低了跨领域执行和工具切换的成本。
3. 专业能力从固定交接节点，逐渐变成可以按需调用的协作资源。

对于研发数字员工，这意味着它不能只是 Coding Agent，也不应被拆成一组互相交接的岗位机器人。它需要围绕产品需求持续工作，在设计、开发、联调、CR、测试和发布之间保持上下文，并在需要时调用专业工具和专业协作者。

对于开发人员工作台，这意味着系统中心不能是聊天会话，也不能只是 Bug、代码和流水线的工具集合，而应该是产品需求及其完整交付上下文。

更准确的目标是：

用产品需求承载端到端上下文，用 Workflow 表达阶段、门禁和责任，用 Agent 处理阶段内的不确定性，用专业工具完成具体执行，并让人类 DRI 对最终结果保持清晰责任。

角色融合带来的真正机会，不是让一个人或一个 Agent 做完所有事情，而是重新围绕结果组织人、数字员工、流程与工具。

下一篇将回到系统实现，讨论如何把产品需求、开发任务、Bug、联调阶段和统一工作引用落成可演进的领域模型。

参考资料

1. GitLab Handbook：Directly Responsible Individuals — DRI 的责任、决策权以及与协作者之间的关系。
2. GitLab Handbook：Engineering DRI for Large-Scale Initiatives — Engineering DRI 如何拆解工作、跟踪进度、管理风险并调用专业协作者。
3. DORA：Visibility of work in the value stream — 从业务想法到客户价值的工作可见性。
4. DORA：Loosely coupled teams — 团队自主交付、技术架构与组织结构之间的关系。
5. DORA：Working in small batches — 跨职能团队、小批量工作与交付效率。
6. Anthropic：Building effective agents — Workflow、Agent、工具使用和从简单架构开始的设计原则。