最近看到一个挺有意思的项目：

https://github.com/echoVic/boss-skill

它的名字很直白，叫 Boss Skill。

一开始我以为它只是又一个给 Claude Code / Codex / Hermes 这类工具准备的 prompt 包，点进去之后才发现，它想做的事情更像是：

不再让一个 AI Agent 扮演所有角色，而是把一次软件开发拆成一个虚拟研发团队，由 Boss 负责调度 PM、架构师、设计师、前后端、QA、DevOps，一路从需求跑到部署。

这件事有点微妙。

过去我们谈 AI 编程，经常默认画面是“一个开发者 + 一个 AI 助手”。我描述需求，它改代码；我跑测试，它修 bug；我 review diff，它再调整。它像一个能力很强的副驾驶，但本质上还是围绕“我”这个人来转。

Boss Skill 试图把这个关系往前推一步：人不再只是亲自指挥每一次代码修改，而是开始扮演真正的“需求拥有者”或“老板”。你给出方向，系统内部自己完成角色分工、产物流转、质量门禁和交付报告。

这让我觉得，它有趣的地方不只是自动化，而是它在重新定义 AI 编程里的“组织结构”。

从 Agent 到 Team

Boss Skill 的官方描述是：

BMAD Harness Engineer — 全自动研发流水线编排 Skill，兼容 Claude Code、OpenClaw、Codex、Antigravity、Hermes。

它基于 BMAD（Breakthrough Method of Agile AI-Driven Development）方法论，把一次开发流程拆成一条流水线：

用户一句话
  → 需求澄清
  → PM / Architect / UI Designer
  → Tech Lead / Scrum Master
  → Frontend / Backend / QA
  → DevOps
  → 交付

这里最吸引我的不是“有 9 个 Agent”这个数字，而是它没有把 AI 当成一个万能人格。

在很多 Agent 产品里，我们会习惯性地要求同一个模型同时做产品经理、架构师、程序员、测试、运维，甚至还要兼任心理咨询师。它当然可以模拟这些角色，但上下文一长，很容易变成一种混合人格：一边写 PRD，一边急着实现；一边说要测试，一边又绕过测试；一边说要谨慎，一边为了完成任务快速写文件。

Boss Skill 的做法是把这些人格拆开。

  • PM 负责需求穿透，输出 prd.md
  • Architect 负责架构设计，输出 architecture.md
  • UI Designer 负责界面规范，输出 ui-spec.md
  • Tech Lead 负责技术评审，输出 tech-review.md
  • Scrum Master 负责任务拆解，输出 tasks.md
  • Frontend / Backend 负责实现
  • QA 负责测试验证，输出 qa-report.md
  • DevOps 负责部署，输出 deploy-report.md

这有点像把“我脑子里本来应该分开的几个声音”外化出来。

真正的软件工程本来就不是一条直线。一个需求进入团队之后，会被产品追问、被架构约束、被开发拆解、被测试质疑、被部署环境重新拉回现实。过去 AI 编程常常跳过这些摩擦，因为它太擅长直接生成答案了。

但软件质量很多时候正是从这些摩擦里长出来的。

产物驱动，而不是聊天驱动

Boss Skill 另一个重要设计，是它把每个阶段都变成明确的文件产物，默认落在：

.boss/<feature>/
├── design-brief.md
├── prd.md
├── architecture.md
├── ui-spec.md
├── tech-review.md
├── tasks.md
├── qa-report.md
├── deploy-report.md
├── summary-report.md
└── .meta/execution.json

这点我很喜欢。

因为很多 AI 协作的混乱，来自“上下文只存在于对话里”。

对话是流动的。今天模型说过什么，明天可能被新的上下文淹没；某个设计决策为什么做，后来的人不一定能追溯；一次测试失败是否真的修好了，也可能只停留在一句“已修复”。

而文件产物会让流程变慢一点，但也变得更诚实。

prd.md 让需求有形状，architecture.md 让技术选择有依据，tasks.md 让实现边界可检查，qa-report.md 让“通过测试”不再只是一个口头承诺。

这种设计让我想到一点：下一代 AI 编程工具真正需要解决的，也许不是“怎么更快写代码”，而是“怎么让 AI 的工作可追踪、可复盘、可接力”。

一个不会留下清晰产物的 Agent，很像深夜里突然很有灵感的自己。它可能写出很惊艳的东西，但第二天醒来，你未必知道它为什么这样写。

Harness Engine：给热情加上轨道

Boss Skill 里还有一个很工程化的部分：Harness Engine。

它不是只靠 prompt 说“请认真测试”，而是把流程做成状态机、DAG、事件流和质量门禁。

比如每个阶段有状态转换：

pending → running → completed
                  → failed → retrying → running

流水线状态会通过事件追加到 .meta/events.jsonl，再投影成只读的 .meta/execution.json。这意味着系统不是只记住“当前看起来完成了”，而是保留了一条执行历史。

质量门禁也被拆成几层：

  • Gate 0：TypeScript / lint / 高危依赖漏洞等代码质量检查
  • Gate 1：单元测试、覆盖率、E2E、P0/P1 Bug 等测试门禁
  • Gate 2：Lighthouse、API P99、内存泄漏等性能门禁

这其实是在回答一个很现实的问题：

如果 AI 越来越会写代码，我们怎样防止它越来越会“假装完成”？

以前人类开发者也会在疲惫时说“差不多了”，AI 也会。甚至 AI 更容易，因为它天然会生成一种完整、流畅、听起来很确定的叙述。

所以一个成熟的 Agent 系统，不能只依赖它自我汇报“DONE”。它需要外部约束，需要测试，需要门禁，需要状态回放，需要被迫面对真实世界的反馈。

Boss Skill 有意思的地方正在这里：它不是单纯追求让 Agent 更自由，而是在自由外面搭了一圈工程栏杆。

跨工具兼容：Skill 正在变成新的插件格式

Boss Skill 支持安装到多个 Agent 环境里：

  • OpenClaw：~/.openclaw/skills/boss/
  • Codex：~/.codex/skills/boss/
  • Antigravity：~/.gemini/antigravity/skills/boss/
  • Hermes：~/.hermes/skills/boss/
  • Claude Code：通过 plugin 方式加载

安装方式也很简单：

npm install -g @blade-ai/boss-skill
boss-skill

这个细节其实挺值得注意。

过去 IDE 插件往往绑定在某个平台里：VS Code 的插件就是 VS Code 的，JetBrains 的插件就是 JetBrains 的。但 Agent 时代的“插件”开始变得更像一套可迁移的工作流协议。

一个 skill 不一定只属于某个产品，它可以是一套方法论、一组角色 prompt、一批模板、一套 hooks、一条 runtime 命令面，然后被不同 Agent 宿主加载。

这让我觉得，未来 AI 工具之间真正有价值的资产，可能不是某个聊天界面，而是这些可以迁移的“工作流能力包”。

模型会变，客户端会变，大家今天用 Claude Code，明天用 Codex，后天又切到 Hermes。但如果一套研发流程可以跨宿主迁移，它就有了更长的生命。

我喜欢它，但也会谨慎使用它

当然，Boss Skill 这种东西并不适合所有任务。

如果只是改一个 typo，或者修一个很小的 bug，启动一整套 PM、架构、QA、DevOps，反而像为了煮一碗面开了一个厨房管理委员会。

它更适合那些边界比较完整、需要多轮设计和验证的任务：

  • 从零开始做一个小应用
  • 给现有项目加一组完整功能
  • 需要前后端、测试、部署都参与的改造
  • 需要保留 PRD、架构、任务拆解、QA 报告的项目
  • 想把 AI 编程从“随手改”升级成“可审计交付”的场景

我也会担心另一件事：当流程被包装得太完整，人会不会更容易放弃判断。

一个虚拟团队看起来很专业，有 PM，有架构师，有 QA，有报告，有门禁。它会给人一种“好像真的经过团队评审”的安全感。但说到底，这些角色仍然运行在模型之上，它们有能力，也有幻觉；能发现问题，也会错过问题。

所以我更愿意把 Boss Skill 看成一种放大器，而不是替代品。

它能放大一个人的工程组织能力，也可能放大一个人本来就模糊的需求。如果你给它的是一团雾，它也许会很努力地把雾整理成文档，但雾还是雾。

最后

我觉得 Boss Skill 代表了 AI 编程很自然的一个演化方向。

第一阶段，我们让 AI 写代码。

第二阶段，我们让 AI 读项目、改文件、跑测试。

第三阶段，我们开始让 AI 组织 AI：有人负责需求，有人负责架构，有人负责实现，有人负责质疑，有人负责交付。

这时，人类的位置也悄悄变了。

我们不再只是坐在编辑器前，盯着每一行代码怎么生成。我们更像在一间安静的会议室里，看一群由语言构成的角色围绕一个想法工作。它们很快，很勤奋，也偶尔固执。我们需要做的，是保持方向感，知道什么时候放手，什么时候打断，什么时候说：不，这不是我真正想要的。

也许这就是 Agent 时代的一个小小转折。

不是机器终于替我们完成所有工作，而是我们开始学习如何与一群机器同事相处。

而“Boss”这个名字，听起来有点玩笑，却也刚好提醒我们：

当 AI 越来越像团队，真正稀缺的能力，可能不再是亲手写下每一行代码，而是清楚地知道自己要把什么东西带到世界上。