软件工程3.0时代

2026-07-13

导读：去哪儿的 3000+ 自动化任务、75% 全公司出码率，正是建立在这套系统之上的

当你指挥一个 AI 去写代码时，它可能写出来；当你同时指挥五个 AI 去写代码时，它们可能各自一套想法，最后代码乱成一团。去哪儿旅行的经验告诉我们：多智能体协同的真正难点，不在于让 AI 多聪明，而在于如何让它们在同一套规则下"听话"执行。而这套规则，就叫 SKILL（技能）。

为什么需要 SKILL？一个真实的困境

想象你是一个团队负责人，手里有 Claude、Codex、Cursor 三个 AI 助手。你需要它们协作完成一个复杂需求：

需求拆解
代码生成
编译测试
线上部署
日志分析

问题来了：

谁负责第一步？谁负责第二步？
如果第二步失败了，怎么自动回流到第一步重新拆解？
如果代码编译不过，AI 怎么知道该读日志还是改代码？
最后的交付物是什么？如何验证质量？

这不是 AI 智能不够的问题，这是流程没规则的问题。

SKILL 到底是什么？

SKILL 就是一个"工作指令包"——它不是提示词，而是能被平台反复调用、有明确输入输出、能自动判断下一步的"能力积木"。

拿 JDK 自动升级举例（去哪儿真实场景）：

SKILL: "JDK升级"

├─ 输入：应用代码、源版本(Java 11)、目标版本(Java 21)

├─ 规则处理：OpenRewrite 批量替换 API

├─ AI 处理：处理规则无法解决的编译错误

├─ 验证：编译通过、测试通过

└─ 输出：可合并的升级分支、完整 diff、质量报告

去哪儿的平台用这个 SKILL 升级了211 个应用，93% 编译通过率。如果没有 SKILL 框架，每个应用都得手工协调多个 AI，效率根本上不来。

SKILL 怎么开发？三层递进

第一层：编排层——auto_dev（自动开发的"大脑"）

auto_dev不替代编码，而是治理AI的行动序列：

when: 需求来了

do:

1. 读取需求文档 → 理解背景

2. 触发代码生成 SKILL → AI 写代码

3. 触发编译 SKILL → 验证能否编译

if 编译失败:

→ 读日志，修改代码，重试

4. 触发部署 SKILL → 上真实环境

5. 触发测试 SKILL → 运行 E2E 测试

until 目标达成或人工确认

这个 SKILL 的核心是证据驱动——每一步都根据上一步的结果（成功 or 失败）决定下一步。

第二层：执行层——Noah能力族（真实环境的"手脚"）

auto_dev 是大脑，Noah 是执行者。它负责：

部署：把代码真的部署到测试环境

日志分析：编译失败了？自动抓日志，告诉 AI 哪里错了

热发：小改动不用全部署，直接热更新快速验证

数据库操作：连接 MySQL/Redis，让 AI 能查数据、改配置

关键是：AI 不再停留在"改完代码就完事"，而是能进入真实环境、获得反馈、自动修复。

第三层：业务域层——航班、交易、前端等专属技能包

flight/auto_coding SKILL：航班搜索场景的自动编程

├─ 包含：需求表达模板、编码规范、常见坑点

├─ TDD：定义验收标准

├─ CR：代码审查规则

└─ 性能分析：特有的监控指标

这个 SKILL 只对航班团队开放，保证模型不会乱套。

SKILL 如何规模化？关键是"治理"

1. 从私有到标准：小范围试错，然后全公司推广

去哪儿现在有 50+ 个沉淀的 SKILL，都是这么"养"出来的。

2. 种子上下文：让技能"懂得"你的任务背景

传统 SKILL 的问题：只看当前输入，没有全局感知。

比如，code_review SKILL 收到一段代码，它不知道：

这是新功能还是 bug 修复？
这个功能的验收标准是什么？
前面哪个步骤已经成功了？

种子上下文解决这个问题——在执行 SKILL 前，注入：

任务类型（新功能/修复/升级）
目标和约束
进度状态（已完成第 2 步/第 3 步）
上下游依赖

有了这些信息，SKILL 的决策质量能提升30%+。

3. 统一网关：让平台"看得见" SKILL 的执行

Skills Gateway 的核心职责：

① 统一分发

- 版本管理：skill-v1.2.0 / skill-v1.2.1

- 灰度：先让 10% 的团队用新版本

② 统一执行

- 记录谁、在什么场景、什么时间调用了这个 SKILL

- SKILL 失败了吗？什么原因？

- 多久才完成的？

③ 统一观测

-技能命中率：这个 SKILL 成功解决了多少个需求？

-复用率：被多少个团队使用？

- 失效点：什么条件下容易失败？

这样，你就能看到每个 SKILL 的"生命周期"——什么时候可以升版本、什么时候该优化、什么时候该下线。

实战：一个完整的 SKILL 开发清单

想开发一个新的 SKILL？按这个清单走：

多智能体协同的"配方"

有了 SKILL 框架，多 AI 协同就变成了编排问题而不是沟通问题：

这套流程，去哪儿用150 人黑客松验证过了——1 天内完成复杂需求，平均出码率 90%+。

总结："为 AI 编制规则"而不是"让 AI 自由发挥"

最大的误区是：多 AI 就是给多个模型的提示词，让它们自由协作。

实际上：多 AI 协同的天花板，就是你给它们建立的"规则系统"的水位。

SKILL 就是这个"规则系统"的具体形态——

输入/输出清晰 → AI 不会乱
失败可拦截 → 不会一错再错
过程可观测 → 你看得见发生了什么
可复用可迭代 → 从个人工具变成团队资产

当你的 SKILL 库足够丰富、治理足够严谨，多智能体协同就不再是"黑盒子"，而是"清晰的流水线"。去哪儿的 3000+ 自动化任务、75% 全公司出码率，正是建立在这套系统之上的。

【声明】内容源于网络

软件工程3.0时代

由于大模型（LLM）正在改变着千行百业，软件工程（SE）更是首当其冲，迎来软件工程3.0新时代：模型驱动研发、模型驱动运维。本公众号将致力于研究SE3.0时代的软件研发新范式、理论与方法，介绍SE3.0时代的工具与实践。

内容 612

粉丝 0

软件工程3.0时代由于大模型（LLM）正在改变着千行百业，软件工程（SE）更是首当其冲，迎来软件工程3.0新时代：模型驱动研发、模型驱动运维。本公众号将致力于研究SE3.0时代的软件研发新范式、理论与方法，介绍SE3.0时代的工具与实践。

总阅读3.4k

粉丝0

内容612

如何为多智能体开发SKILLs？