组建 AI 临时混合小队打破职能壁垒，让开发速度真正起飞

在公司部署 AI 时，组织结构上的摩擦往往比技术本身的难度更大。为释放 AI 的效能，需组建包含开发、产品与设计人员的临时混合小组（Temp Squads），使非技术人员借助 AI 直接编写代码。

传统职能划分为何成为 AI 应用的障碍

在管理一家拉美领先金融科技公司的 DevEx 团队期间，需维护数百个每日处理数亿请求的分布式服务。转向 AI-first 策略后，出现了一个反常情况：尽管 AI 显著降低了编程门槛，产品或设计人员仍无法直接修改代码。

AI 无法直接消除交付瓶颈的原因

这背后存在两个核心问题。

一是组织内部隐性知识的壁垒。AI 尽管精通 Python，却对公司的特定 CI/CD 流水线、Git 规范、语义化版本控制及部署流程一无所知。

二是流程僵化。传统汇报机制、需求评审和 Backlog 管理是为「纯人工开发」设计的。当代码产出速度提升 10 倍，而流程耗时不变时，最终仍需开发者手动完成。

组织变革的实施步骤

这套方案不宜强制推行，否则会被视为制造混乱。可在经理允许下进行个人实验，证明可行性后再推广。若团队抵触强烈，可先在窄范围内验证一个 Feature，以成果说服人。

为达成高频交付，开发流程被彻底改造，其中最核心的改动是移除「任务拆解」环节。

重新设计业务需求的流转路径

移除任务拆解能否加速交付

在新流程中，业务侧（Business Plan）仍主导目标和方向，但不再强制提供预技术分析或详尽的任务拆解。

目前仅接收两种输入格式：

• Feature Request（功能请求）
• RFC（Request for Comments，征求意见稿）

业务方仅需说明「期望达成的目标」，无需在文档中详述执行步骤。在 AI 时代，技术实现路径可在临时小队内部快速试错，不必在需求阶段锁定，以免限制 AI 优化方案的空间。

构建临时混合小队的协作模式

Temp Squads 如何重塑跨职能协作

Temp Squads 的核心在于「跨职能」与「临时性」。它不是固定部门，而是为特定目标组建、任务完成后立即解散的敏捷单元。

其人员构成非常清晰：一名产品经理、一名设计师和一名开发者。

开发者的角色也会转变，从唯一的「代码执行者」变为「代码审核员」和「架构引导者」。PM 和设计师则在 AI 辅助下直接尝试修改配置项或简单 UI 逻辑，无需再通过提 Ticket 等待排期。

这种模式最直接的效率提升来自减少沟通成本。以往修改文案或按钮颜色，需经历写 Ticket、开发者排期、开发、测试、上线。现在由 PM 使用 AI 生成代码，开发者点击 Approve 即可合并。

实施过程中的风险与成本

这种模式对成员的综合能力要求很高，并非零成本。

非技术人员编写代码有哪些潜在问题

认知成本：非技术人员需要学习公司内部部署流程和基础 Git 操作，初期会消耗学习时间。

代码质量风险：非专业开发者编写代码可能产生低级 Bug 或造成风格不统一，因此必须建立严格的 Code Review 机制，由开发者把关，确保稳定性。

心理阻力：部分开发者可能认为自己的地盘被侵占，或者审核 AI 代码过于繁琐。这需要管理层引导，让开发者认识到自身价值已从「写代码」转向「设计系统」。

一个开发者带领一名 PM 和一名设计师的混合模式，在处理中小型功能迭代时速度极快。大型架构调整仍需纯技术团队参与，而在日常功能优化和快速实验中，Temp Squads 是目前最能发挥 AI 效能的组织形式。