AI 开发工具牵引下，软通动力的一场研发组织重构

　　对一家以交付为核心的数字技术服务企业来说，AI 从来不只是"给开发者换一把更快的锤子"。

　　软通动力致力于成为全球领先的AI工厂全栈服务商，集团在职员工 8 万余人，2025 年营业收入 350.90 亿元，其中 AI 相关业务占比 52.6%，服务客户 2600 余家（含 230 多家世界及中国 500 强），2023–2025 年蝉联中国 IT 服务市场与国内 IT 咨询厂商双项第一。这样一个以交付为核心、体量又足够大的组织里，一个工具要真正产生价值，必须同时穿过三层：一线开发者愿不愿意用、项目交付流程能不能承接、组织架构会不会为它调整。

　　2025 年软通动力把这三层都动了一遍。他们在一个大型科技企业客户的交付项目中，边交付边沉淀，做出了一个 Agent 管理平台底座；把咨询部门改造成承接研发交付的 FDE 组织，让 BA 和后端工程师大规模转型为 AI 开发者；并在 8000 余名员工范围内统一了 AI 编码工具链——Qoder。

　　为什么是现在：交付型组织的三重压力

　　第一重是人效压力。规模越大，人效的每一个百分点都是真金白银。当客户预算趋紧、交付周期压缩，靠加人来堆产能的路径已经走不通。

　　对交付型组织来说，毛利改善最终要落到人效上；如果收入增长仍依赖同比例增员，规模越大，利润空间就越薄。

　　第二重是一致性压力。一家服务商同时在跑几十甚至上百个项目，技术栈不同、团队水位不同、客户规范不同。同一份交付标准，落到不同项目组手里执行出来的结果差异很大。这类问题传统靠评审和培训解决，成本高、见效慢。

　　第三重是规模杠杆。这恰恰也是机会所在。在一个十万人量级的组织里，任何一个哪怕只提升个位数百分点的动作，乘上规模之后都是可观的收益。这个算术题，是软通动力推动 AI Coding 落地最直接的商业论据。

　　"我们原来的开发模式像大禹治水，一个管理者领着无数人干活。现在有了 AI，突然从天而降几台挖掘机——这个组织该怎么迎接这个变革？所以我们要开始研究，怎么把挖掘机用好，把 AI 时代的红利拿到手。"——软通动力高层

　　场景一：一个 Agent 平台的 0→1，是怎么被 Qoder"写"出来的

　　软通动力这轮 AI 实践的起点，不是"我们要做一个 AI 平台"，而是一个具体的交付项目：客户手里有多个能力分散的 AI 产品，入口不统一、管理割裂，需要一个统一的框架把它们管起来。

　　但真正值得同行研究的，不是这个平台最后长成了什么样，而是一支十几人的混合团队，是怎么在交付压力下把一个从零开始的平台写出来的。

　　这里的关键角色是 Qoder。项目初期，团队并没有强制统一 AI 工具，允许成员自由选型；到了后期，因为协作效率和实际使用体验的差异，团队自发收敛到 Qoder 作为主力开发工具。而随着平台复杂度上升，团队的用法也从"让 AI 帮我写这段代码"，演进成了一套规格驱动（SDD, Spec-Driven Development）的工作方式。

　　阶段一：先写清楚要什么，再让 Agent 动手

　　从零搭一个平台，最容易失控的地方不是编码，而是意图传递。一句"做一个统一管理多个 Agent 的框架"，十个人能理解出十个版本；直接丢给 AI，产出的就是一堆看起来能跑、但拼不到一起的代码。

　　团队主要在模块级和接口级使用 Spec。以新增"Agent 运行状态观测"模块为例，开发前先写清数据从哪里采集、接口如何定义、异常如何处理、页面展示哪些指标，以及最终的验收标准；团队确认后，再由 Qoder 按任务清单生成代码、补充测试。这样可以减少不同成员对需求理解不一致造成的返工。

　　阶段二：复杂任务靠拆解推进，而不是一次性生成

　　平台级功能很少能被一次生成就跑通。例如在开发"统一账户与权限封装"时，任务同时涉及账户模型、权限校验、接口改造和前端适配。团队会先让 Quest 分析现有代码和依赖关系，生成分步方案，再按照"底层模型—服务接口—前端接入—测试验证"的顺序推进。每完成一步，开发人员都可以检查结果、补充约束，发现问题时也能及时回到对应环节调整。

　　阶段三：共性能力下沉时，最难的是"所有人理解同一个底座"

　　团队统一使用 Qoder 后，RepoWiki 主要用于梳理平台架构、模块依赖和关键调用链，方便现场与远程成员快速理解同一套代码；Rules 则用于固化接口命名、日志格式、异常处理、测试要求等项目规范。新成员加入或开发人员切换模块时，可以先通过 RepoWiki 了解整体结构，再按照 Rules 完成开发，减少口头传递和重复解释。

　　阶段四：引入开源框架重构时，先要"读懂别人的代码"

　　后期团队引入开源框架 DeepAgent 对底座做了一次重构，稳定性和产品化程度明显提升。这次重构最明显的变化，是前期阅读和定位成本得到压缩。团队先用 Qoder 梳理 DeepAgent 的目录结构、核心调用链和扩展点，再把原有底座与开源框架逐项对照，形成迁移清单，随后按模块完成替换和验证。开发人员因此可以把更多时间放在兼容性判断、业务适配和稳定性验证上，减少反复翻查代码和试错的投入。

　　于是，这个"框架"最终长成了平台——能力层沉下了记忆管理与通用任务处理，观测层提供 Token 消耗监控与 Agent 运行状态观测，管控层把账户与权限统一封装，多个 Agent 共享一套治理规则。同时组织也做了一次合并：原先产品研发与项目交付两条线因为目标趋同，由同一位负责人统管，合并成一支十几人的混合团队。

　　这一段经历里有两条方法论值得同行带走：平台不是规划出来的，是从交付里长出来的——先在真实项目里被验证过的能力，才被允许沉进底座；AI 参与的从零开发，赢在规格而不是赢在手速——把意图写清楚的那一步做扎实，后面的生成质量才有保障。

　　场景二：原型图从"客户皱眉"到"客户点头"

　　平台是在团队内部长出来的，客户看到的只是最终结果。而在需求阶段，AI 的产出要直接摆到客户面前——这里没有中间缓冲，好与不好，客户当场就有反应。

　　软通动力的 BA（业务分析师）需要在需求阶段快速产出原型图给客户看。最早他们用另一款 AI 工具来画，结果并不理想：同一个项目里不同页面风格不统一；生成结果"AI 感"过重，一眼就能看出不是设计师做的；细节粗糙，交到客户面前，反馈不佳。

　　换到 Qoder 之后，团队在提示词上做了一轮优化，输出质量出现了明显变化：视觉更规整、细节更完整、同一项目内的风格一致性明显改善，客户侧的反馈随之转正。

　　这个变化背后的关键，其实不是"哪个模型更强"，而是 AI 是否理解这家公司、这个项目的偏好——什么叫"我们家的原型该长什么样"。这也解释了为什么同样的需求，加上一层规范和上下文之后，结果会差这么多。

　　"以前客户看到原型，先问'这是 AI 做的吧？'；现在基本不会再问这个问题了，会聚焦到业务细节的讨论上。"

　　场景三：契约层与双重质量闸门，把问题拦在交付前

　　AI 提高了代码产出速度，项目质量管理也要跟着前移。软通动力先把代码提交前需要满足的要求固化到契约层，其中包括模块边界、接口约定、编码规范、测试要求和验收口径。开发人员、AI 工具和后续自动检查都遵循同一套规则。

　　第一道闸门设在本地。开发者准备提交代码时，先用 Qoder 的 Review 能力检查当前改动，重点检查明显缺陷、接口偏差、异常处理遗漏和测试覆盖不足。发现的问题直接在本地修改，确认后再提交。

　　第二道闸门设在代码提交之后。持续集成流程按照契约层执行编译、单元测试、接口契约检查和安全扫描，并判断代码是否达到项目设定的质量标准。未通过的改动退回修改，通过后进入人工审核和合并。

　　两道闸门各自解决一个问题：本地 Review 给开发者即时反馈，减少低质量代码进入团队协作流程；提交后的自动检查统一项目口径，避免不同人员采用不同标准。资深研发继续判断关键设计和复杂业务逻辑，AI 与自动化工具负责重复检查和问题定位。这样质量要求可以跟着项目长期保留，团队成员发生变化，检查标准仍然一致。

　　组织重构：当 BA 和后端都成为 AI 开发者

　　如果只看工具，这是一个提效故事。但软通动力真正走得更远的地方，是组织。

　　咨询部门开始承接研发交付。原本非研发性质的咨询组织，随着 AI 项目大量增加，如今承接了大量研发与交付工作，并推行 FDE（Forward Deployed Engineer，前置交付工程师）交付模式，把传统研发角色向 AI 工程化方向转型。FDE 的含义是让工程人员深入客户场景，与客户业务人员共同完成解决方案；全文简称统一写作 FDE。

　　过去，产品、前端、后端、测试等角色按专业分工推进，需求会在多个岗位之间依次流转。新的 FDE 团队把业务、数据和架构能力放进同一个项目单元，原有专业能力继续保留，但工作边界随之变宽——研发人员需要理解业务，咨询人员也要具备把需求做成可运行系统的能力。

　　岗位角色的重新洗牌

　　前端工程师：如果不具备全栈或 AI 开发能力，很难进入新的 AI 项目，路径是回到传统项目、或转型为 AI 开发者。

　　后端工程师与 BA：大量转为 AI 开发角色，直接参与 Agent 构建与逻辑设计。

　　新设 FDE 组织：业务 FDE、数据 FDE、架构 FDE 三类角色组成项目铁三角——业务 FDE 与客户业务人员一起定义场景和验收口径，数据治理、知识构建与模型评测交给数据 FDE，系统设计、Agent 编排与集成部署由架构 FDE 负责；其中业务与数据 FDE 驻客户现场，架构 FDE 在后场远程支撑，一名架构 FDE 可同时支撑 2–3 个现场项目。

　　测试与质量保障单独设置：不并入铁三角，独立成线覆盖整个交付过程。

　　进入机制：FDE 由存量团队转型而来，两条入口分别是行业咨询顾问（转型周期约 6–8 周）与 AI 开发工程师（约 8–10 周），统一按 L1–L4 四级认证分派项目角色。

　　推动方式是自上而下的。高层态度坚决，组织调整迅速，原有研发团队整体转入咨询体系下的 FDE 架构，公司从"职能型"组织转为"项目型 + 产品型"双线运作。团队按项目快速组合，项目中反复验证有效的做法，再被整理成平台功能和开发规范回流沉淀——项目可以更快响应客户反馈，平台也能从真实交付中继续完善。

　　这类调整在服务型企业里并不常见——它意味着承认：AI 时代的交付能力，不能只靠给老岗位换新工具，而要重新定义岗位本身。

　　"FDE 转型，就是让离客户最近的人，拥有把问题解决到底的能力。"

　　反直觉：质量岗位没有变弱，反而更重了

　　案例里最诚实的一段，来自一个被推翻的预判。

　　团队最初认为，随着自动化测试和 AI 能力普及，QA 的角色会逐渐弱化。实际情况相反：质量验证的工作量反而加重了。

　　原因在于 Agent 时代的质量问题变了形态。代码对不对，工具可以帮着看；但 Agent 的逻辑路径是否合理、模型行为是否符合预期、多轮交互中会不会跑偏，这些仍然高度依赖人的判断。

　　于是软通动力开始招募"新一代质量人员"，与传统 QA 的能力画像明显不同，需要掌握 Agent 观测、模型评测、逻辑路径验证等技能。同时，原有的 PMO 与 QA 组织结构被保留下来，在客户现场与集团层面分别设置质量管理团队，AI 工具用于让流程更精细高效，但核心决策仍由人主导。

　　安全方面，当前主要沿用成熟做法，由后端研发在底座中设置"安全门"进行控制，配合规范与人工监督。

　　给同行的四条经验

　　结合软通动力的实践，如果一家技术服务型企业也要走这条路，有四件事值得提前想清楚：

　　一，让工具从项目里被选出来，而不是从会议室里被指定。软通动力在项目初期允许自由选型，最终团队因为协作效率自发统一到 Qoder。这种"用出来的统一"，比行政命令式的统一更稳。

　　二，先在真实交付里跑通，再考虑产品化沉淀。Agent 管理平台的每一项底座能力，都是先在项目里被验证过的。

　　三，组织调整要跟上工具引入的速度。只换工具不动组织，效率提升会卡在流程和岗位职责上。

　　四，别指望质量环节会自动变轻。AI 让执行变快，但验证的复杂度上升了，质量人才画像需要提前储备。

　　结尾

　　软通动力这个案例的价值，不在于某个指标提升了多少个百分点，而在于它展示了一条更完整的路径：工具进入项目 → 能力沉淀成平台 → 流程重新设计 → 组织跟着调整 → 人才画像更新。

　　对同样以交付为核心的企业来说，这条路径比任何单点数据都更值得参考。