Solo to Team 教程：安装协作技能包，用一个人统筹多个 AI 助手

项目简介

Solo to Team · 一人成队，仓库名为 solo-to-team-skills，是一套面向“一个人总控、多个长期 AI 助手”场景的中文协作技能包。它不负责让 AI 自动组队，而是提供一套可重复执行的方法，帮助你把任务派出去、跟进回来、核对证据，再由人做最终判断。

项目当前状态为 v0.9-draft，仍会继续修改。它已经在 Codex、WorkBuddy、DeepSeek Harness、Cursor、CodeBuddy、Kimi Work、千问办公等宿主中完成有限范围的实际使用验证；Grok Bot 需要手动配置。Claude Code 已准备插件结构，但尚未纳入首发支持。

“支持”表示指定安装与调用方式已有走通记录，不表示所有任务都能稳定完成，也不表示四项技能都在每个宿主中逐一验证。

项目解决什么问题

多 AI 助手协作时，真正容易失控的往往不是模型能力，而是流程：任务发出后没人确认，执行人说“完成了”却没有证据，验收和收到成果混为一谈，或者操作说明只有作者自己看得懂。

Solo to Team 将协作过程整理为一条主线：

提目标 → 分工 → 交接 → 核对 → 判断

• 提目标：明确要做什么、成果放在哪里、什么时候交付，以及怎样才算完成。
• 分工：派工前先登记“待收”，写清执行人、接收人和到点检查人。
• 交接：分别记录“已接单”和“已收到成果”，避免把收到消息误当成完成。
• 核对：检查与当前版本对应的有效证据，修改过或失败过的部分必须重新核验。
• 判断：由人决定放行、退回还是改变方向。

四项核心技能

dispatch-accept-verify

展示名为“派出去的活要收回来”，负责分工与交接。它要求任务派出前登记“待收”，并把接单、收到成果和验收完成分开记录。只有完成验收或获得授权取消，任务才能从未完成清单中移除。

evidence-before-done

展示名为“交活前要有证据”，负责核对。它强调完成结论必须建立在与当前版本对应的证据上，例如打开成果检查、重新计算、运行命令，或者按照原步骤重新走一遍。

beginner-ops-writing

展示名为“新手操作说明”，用于编写任何不了解背景的人也能照做的步骤。核心原则包括一次写一步、对象指向唯一，并说明完成后应看到什么。登录、付款、删除、正式发送等必须本人完成的动作，只应写“请本人来”，不能设计代做办法。

ops-case-notes

展示名为“脱敏运营记录”，包含两个来自实际运转的脱敏案例，记录真实问题、改法、结果和仍未解决的限制。它适合在流程出现漏洞后作为复盘参考。

开始前的准备

首先下载或克隆仓库，确保本地存在 skills/ 目录。该目录下应包含四个技能子目录，每个目录中都有一个 SKILL.md。

git clone YOUR_REPOSITORY_URL
cd solo-to-team-skills

克隆地址应替换为项目正式公开后的实际仓库地址。若通过下载压缩包取得项目，也可以直接解压使用。

安装时请遵守以下原则：

• 复制整个 skills/技能名/ 目录，不要只复制 SKILL.md。
• dispatch-accept-verify 还依赖其目录内的模板；只复制正文会丢失登记行模板。
• 建议同时安装 dispatch-accept-verify 和 evidence-before-done。
• evidence-before-done 也可以单独使用。
• beginner-ops-writing 与 ops-case-notes 属于可选搭配，不安装也不影响主要派收流程。

选择宿主并安装

Codex

Codex 的已验证方式使用仓库自带的 .agents/plugins/marketplace.json。请先安装并登录 Codex CLI，然后在项目根目录执行：

cd /path/to/solo-to-team-skills
codex plugin marketplace add "$(pwd)"
codex plugin add solo-to-team-skills@solo-to-team-skills

如果命令返回非零状态，应停止并确认当前目录是否为包含 .agents/plugins/marketplace.json 的包根目录。安装后新开会话，或使用 codex exec 调用技能。

codex exec -s workspace-write --skip-git-repo-check -C "$(pwd)" '请使用技能 dispatch-accept-verify，写一行待收登记到 T044_dispatch_line.md'

如需撤回安装，可执行：

codex plugin remove solo-to-team-skills@solo-to-team-skills
codex plugin marketplace remove solo-to-team-skills

Cursor

把所需技能目录完整复制到用户技能目录：

mkdir -p ~/.cursor/skills/
cp -R skills/dispatch-accept-verify ~/.cursor/skills/
cp -R skills/evidence-before-done ~/.cursor/skills/

随后在 Cursor Agent 中按技能名调用。也可以使用 cursor agent --print 形式的 CLI。对新建工作区进行非交互运行时，宿主可能要求使用 --trust；该参数表示信任工作区，并非关闭安全机制。

WorkBuddy 与 CodeBuddy

这两个产品名称相近，但不是同一个宿主，安装目录不能混用。

• WorkBuddy：复制到 ~/.workbuddy/skills/ 或项目内的 .workbuddy/skills/，也可以在界面上传包含 SKILL.md 的技能目录或 zip。
• CodeBuddy：复制到 ~/.codebuddy/skills/ 或项目内的 .codebuddy/skills/，然后在界面或 CLI 中按名称调用。

相关官方说明可参考 WorkBuddy Skills 文档 与 CodeBuddy Skills 文档。

DeepSeek Harness

将技能完整复制到项目的 .dsh/skills/、用户目录 ~/.dsh/skills/，或 .agents/skills/，然后重新打开或刷新 Harness。项目明确说明，dsh plugin add 不是安装这些技能正文的方式。

使用前需要自行准备 DeepSeek 账号或 API，本项目不提供密钥。具体机制可参考 DeepSeek Harness Skills 文档。

Kimi Work

README 中实际验证的是 Kimi Work 桌面端，而不是 Kimi Code CLI。在 macOS 验证环境中，技能目录为：

~/Library/Application Support/kimi-desktop/daimon-share/daimon/skills/

复制完成后，在 Kimi Work 界面输入 / 选择技能。该路径来自社区实践，官方还可能提供 zip、Markdown、链接或商店安装方式，应以 Kimi Skills 官方页面 的当前说明为准。

千问办公 QwenWork

把技能目录复制到：

~/.qwenworkcn/skills/

随后在桌面端使用 / 选择技能，或在对话中直接点名。千问办公与通义灵码不是同一产品，不应套用同一安装目录。可参考 QwenWork Skills 文档。

Grok Bot

Grok Bot 不采用本地目录安装。打开某项技能的 SKILL.md，在对话中要求将正文保存为私有技能，并使用文件开头的 name 与 description。四项技能需要分别保存。

保存 dispatch-accept-verify 时，还要把它的登记行模板一并贴入私有技能。此方式只针对具有私有技能保存能力的 Grok Bot，不代表其他 Grok 产品可以采用相同配置。

Claude Code

仓库已经提供 .claude-plugin/plugin.json 与 marketplace 结构，但当前仍处于“结构已备、走通待补”的状态，因此不能视为首发支持。若自行尝试，应以 Claude Code 官方插件文档 的当前安装方式为准。

第一次运行：从小任务开始

不要一开始就把复杂项目交给多个助手。先选择一件结果容易检查的小任务，例如根据给定输入整理一份会议记录。项目提供了 examples/ 主示例和 examples/walkthrough-meeting-notes/ 完整跟做材料，可用于练习“给定输入、生成成果、检查证据、人工验收、退回修订”。

步骤一：写清目标

向助手说明任务内容、成果位置、交付时间和完成标准。提示词可以采用以下结构：

请使用 dispatch-accept-verify 管理这项任务。
任务：根据给定输入整理会议记录。
成果位置：指定的工作区文件。
交付时间：约定时间。
完成标准：内容与输入一致，必要字段齐全，并可由我打开检查。
请先生成一行“待收”登记。

步骤二：登记“待收”

派工之前先创建登记行，至少明确任务状态、谁在执行、谁负责接收、谁到点检查、成果放在哪里，以及何时交付。建议直接复制仓库中的 templates/task-register-line.md，不要自行猜测完整字段。

步骤三：分别记录接单与成果

执行助手确认接受任务后，记录“已接单”。成果文件真正返回后，再记录“已收到成果”。两种状态不能合并，因为“有人答应做”不等于“成果已经交付”。

步骤四：用证据核对

调用 evidence-before-done，要求助手为完成结论提供与当前版本对应的证据。

请使用 evidence-before-done 核对当前成果。
打开最终文件，对照原要求逐项检查。
如有修改过或失败过的部分，请重新核验。
请列出证据、未满足项和建议结论，不要直接替我放行。

证据可以来自打开文件后的内容检查、命令输出、重新计算结果，或按照原操作步骤重走一遍。若成果在核验后又被修改，受影响的部分应重新检查；没有变化的部分可以复用上次核验结果。

步骤五：由人验收

根据证据决定放行、退回或改变方向。只有人工确认验收通过后，才记录“已验收”。如果不符合要求，应写清退回原因并让执行助手修订，然后再次获取证据。

“已收到成果”不是“已验收”。只有证据与当前成果相符，并由人做出放行判断，任务才算真正完成。

零基础用户的推荐学习顺序

1. 先阅读 examples/ 中的主示例。
2. 跟随 examples/walkthrough-meeting-notes/ 完成一次包含退回修订的小任务。
3. 只学习一个模板：templates/task-register-line.md。
4. 先用记事本或表格练习“待收 → 已接单 → 已收到成果 → 已验收”。
5. 熟悉方法后，再把技能安装到一个支持的 Agent 宿主中按名调用。

这套方法本身不依赖复杂编程能力。只要能够写清任务、安排执行人并检查结果，就可以先从共享记录开始。

进阶用法

把登记字段接入现有看板

如果你已经使用任务系统、电子表格或项目看板，可以将登记行字段接入现有流程。重点不是使用哪种工具，而是确保待收任务一眼可见，并将接单、收到成果和验收完成作为不同状态。

为多助手划清职责

技能包负责提供流程和写法，宿主负责开会话、运行命令、读写文件，以及可能存在的定时提醒或跨助手消息能力。人则负责设定目标、决定优先级、批准危险动作并做最终判断。

在搭建流程时，可以依次检查：

• 宿主能否同时开启多个会话或子助手。
• 宿主能否跨助手发送消息。
• 宿主是否有定时提醒或叫醒能力。
• 如果没有自动提醒，由谁按时人工检查。
• 最终验收和危险动作由谁本人确认。

只重新核验受影响部分

成果修订后，不一定需要无差别重做全部检查。可以复用未变化部分的上一轮证据，但所有修改过、失败过或受修改影响的部分必须重新核验。这能在保持可信度的同时减少重复工作。

用 beginner-ops-writing 编写人工步骤

遇到登录、付款、本人确认等必须人工执行的环节，可以调用 beginner-ops-writing，将步骤拆成一次一个动作，并写清操作对象与预期结果。涉及危险动作时，只提示“请本人来”，不要让助手尝试绕过人工授权。

用 ops-case-notes 做复盘

出现漏接、漏验或重复踩坑时，再查阅 ops-case-notes。记录复盘时应保留方法层面的信息：真实问题、采取的改法、实际结果和仍未解决的限制，同时去除私人联系方式、凭据、内部路径和机器信息。

必须了解的自动化边界

本包插件清单中的 hooks: {} 表示它不提供自动叫醒。安装技能只代表助手能够按照这套方法工作，不代表系统会自动派工、定时催办、跨会话传递消息或自动回执。

• 宿主有定时能力时，可以用宿主能力执行到点检查。
• 宿主没有定时能力时，需要由人按时查看。
• 跨助手通知、群聊和共享文件读写取决于宿主。
• 花钱、登录、付款确认、正式发出和删除等动作必须由人批准。
• 收下、退回或改变方向，最终决定始终由人做出。

README 提到的约十分钟只是设计目标之一，不能写成已经验证的保证。现有 Cursor CLI 测量是在宿主已安装登录、仓库已取得、提示词预先准备好的条件下，从复制技能到输出登记行约 29.6 秒；它不代表陌生用户从零安装宿主并完成整项任务所需的总时间。

如何判断安装真的成功

项目给出了两条硬标准：

1. 能装能调：完成取得、安装或配置，并能按技能名调用，产出可检查的登记行。
2. 能完成一件实际小任务：从目标、分工和交接走到证据核对与人工判断，留下真实成果、证据和验收结论。

当前八家宿主各有一例有限任务的验收记录，但这不构成稳定性证明，也不能证明所有任务都能完成。项目尚未通过对照实验确认全队错误率下降或催办次数减少，因此使用时应保留人工监督。

结语

Solo to Team 的价值不在于制造一个完全自动化的 AI 团队，而在于提供一套清晰、可检查、可迁移的协作方法。先安装 dispatch-accept-verify 与 evidence-before-done，用一件小任务练习“待收、接单、收到成果、证据核对、人工验收”，再逐步接入多个助手和现有看板。无论使用哪种宿主，都应坚持同一原则：助手负责执行和提供证据，人负责目标、授权与最终判断。