一个按钮，为什么需要多个工作环节
“给后台加一个导出按钮。”
这句话看起来很小。真正开始做，你会遇到一串问题：导出全部数据还是当前筛选？普通成员能不能用？没有数据怎么办？请求失败时，用户看到什么？前端拿到的字段和后端返回的字段一致吗？
把这些问题一直追加在同一个聊天里，需求讨论、接口实现和测试结果很容易挤在一起。分别开几个聊天又会带来新的工作：你要不停转述背景，把一个会话的决定搬给另一个会话。
Onevium 的 Team 适合处理这种有明确分工、需要持续跟进的工作。它由负责人会话和真实成员会话组成。负责人组织任务，成员处理各自部分并回报；你可以打开每个成员会话，查看它做了什么。
这篇文章用一个虚构 SaaS 的“客户导出中心”说明怎样安排一支队伍。读完后，你会有一份可以调整后使用的任务提示词、一张分工表，以及判断整体工作是否完成的方法。
本文的业务案例与协作过程均为虚构教学材料，尚未在演示项目完整跑通，不代表真实客户成果。操作入口依据 Onevium 1.1.23 的 Team 文档。
先给一个能验收的目标
业务负责人希望管理员能把当前筛选的客户列表导出为 CSV，交给运营人员处理。第一版只做这件事。
下表列出本案例的业务选择。你们可能需要别的权限或字段，先改清楚再交给 Team。具体账号、路由、文件位置和测试命令由实际项目决定。
| 问题 | 本例的决定 |
|---|---|
| 谁能导出 | 管理员；普通成员不能通过界面或直接请求导出 |
| 导出什么 | 当前筛选结果，列为记录编号、演示名称、状态 |
| 没有匹配结果 | 显示没有匹配记录的提示，不生成 CSV 文件 |
| 请求失败 | 保留当前筛选条件，显示可理解的错误与重试入口 |
| 数据从哪里来 | 本地合成数据，包含管理员和普通成员两类演示账号 |
| 这轮交付什么 | 可运行的本地功能、检查结果和未解决事项 |
用四个会话分工，先看依赖
负责人会话负责把目标保持在同一条线上。四名成员各有一项可检查的交付，下面的分工表和概念流程图展示了它们之间的依赖。
“四名成员”是讲解这个需求的选择。第一次试用可以缩小到两名成员，例如一名实现、一名检查。成员越多，任务书、结果复核和模型用量也会增加。
这里有两个适合并行的时机。首先，成员1整理约定时，其他成员可以只读定位模块和准备检查；其次，约定明确以后，服务端和界面可以分别实施，验收成员准备独立测试。真实的端到端验收要等两边可以一起运行。
| 成员 | 负责什么 | 交付什么 | 需要等什么 |
|---|---|---|---|
| 1：行为与接口约定 | 梳理角色权限、筛选含义、CSV 字段与错误行为 | 一份其他成员共同遵循的约定 | 业务决策明确 |
| 2：服务端 | 数据筛选、权限校验、导出响应 | 实现和相关检查结果 | 接口约定确认 |
| 3：界面与交互 | 导出入口、加载/空数据/失败状态 | 可操作页面和桌面、手机证据 | 接口约定确认 |
| 4：独立验收 | 从需求设计检查，复核最终行为 | 复现步骤、结果、缺陷和剩余风险 | 可先准备用例，实际联调要等实现 |
- 01行为与接口先确认共同约定
- 02服务端实现筛选与权限
- 03界面完成操作与状态
- 04独立验收准备检查，复核结果
在 Onevium 中从 @Team 开始
打开一个普通项目会话，在输入框输入 @，选择扩展能力中的 队伍（Team），然后补充任务并发送。
开始前，核对当前会话能够加载匹配版本的 team Skill，且“设置 → 工具 → 会话（Sessions）”中的工具可用。只看到 Team 标签，还不能证明 Skill 已准备好。缺少来源或工具时，先按 Team 文档补齐条件。这里使用的是 Onevium 会话队伍，不需要把上游 Claude CLI 的实验性 Agent Teams 开关当作总开关。
发送任务后，先审阅负责人提出的成员、文件、交付与验收标准。方案合理后，再回复“按已确认方案启动第一阶段”。负责人依据协议逐个创建真实子会话并发送任务；确认成员确实建立、首条任务已送达，再从会话树或 Team 卡片打开查看。
下面的提示词先请求方案，把三个阶段的启动条件、文件边界与本地交付要求交代清楚。
先确认能加载 team Skill，并能使用创建成员会话、会话通信和队伍报告工具。
我要在当前演示项目增加“客户导出中心”。先检查项目现状，给出 Team 方案，等我确认后开始。
目标：管理员将当前筛选的客户列表导出为 CSV。
本例字段：记录编号、演示名称、状态。
普通成员不能通过页面或直接请求导出。
无匹配数据时有明确提示且不生成 CSV；失败后保留筛选条件并可以重试。
使用本地合成数据，不操作真实客户账号或外部收件人。
建议分工：
1. 行为与接口约定：明确权限、数据字段、空状态和错误行为。
2. 服务端：按确认后的约定实现接口和权限检查。
3. 界面：按同一约定实现页面、状态反馈和窄屏布局。
4. 验收：先写独立检查清单，功能可运行后检查真实结果。
先检查已有修改，列出真实文件路径和每个成员唯一负责的写入范围。
共享类型、配置和公共文件只指定一名写入者；有依赖的工作顺序进行。
负责人维护共同计划、接口决定、成员任务书和验收结论。
每阶段结束汇总结果，等我确认再进入下一阶段。
请把工作限制在三个阶段：确认约定；并行实现；集成验收。
列出各阶段输入、交付、启动条件、成员模型与用量估算。
测试和启动命令以项目现有说明为准，找不到时明确列出缺口。
本轮只在本地完成，不提交、推送、部署或发送推广内容。让其他会话有同一份约定可读
Team 协议把共同计划和成员任务书放在项目内的 .claude/sdd/team-<slug>/。负责人维护 team.md，成员任务书说明目标与负责范围；成员报告也预期保存在这里，验收时要核对实际文件。
对本例来说，有用的共同约定包括：筛选条件怎样传递、三个 CSV 字段叫什么、权限不足怎样响应，以及空数据是否生成文件。把这些决定集中在一份约定里，并在任务书中指向它。
成员之间不会自动获得彼此完整的聊天记录。需要背景时，把约定、相关文件和关键结论放进任务书或负责人发送的消息。一个成员把字段改了，其他成员并不会仅凭“在同一支 Team”就自动知道。
文件归属也要明确。前后端共享的类型文件交给一名成员写，其余成员只读或提出修改请求。Team 会话树不创建独立文件副本，分工指令也不是文件系统锁；负责人仍要检查最终差异。
自动协作在一次接口变更中怎样发生
假设服务端成员发现：旧接口里的 status 字段含义与页面展示不一致，需要先确认导出使用哪个值。
Onevium 的会话工具能向目标成员发送消息。成员空闲时，消息可以启动下一轮；忙碌时会尝试进入当前轮，无法插入时排队。负责人应查看真实投递结果，避免重复创建成员或反复发送同一条任务。
这能减少你亲自搬运每个技术细节的工作。业务选择仍需要人决定，成员的判断也仍需检查。当前 Team 协议以负责人协调为主，不能把它描述成一个全员自由聊天、自己决定所有目标的团队。
我们希望看到这样的过程。以下是教学示意，不是产品运行记录：
- 发现： 服务端成员把发现、影响和需要决定的问题报告给负责人。
- 决定： 负责人核对原约定，把业务含义说明白；若需要你决定，明确提出这个问题。
- 传达： 约定更新后，负责人将变更和新文件位置发给界面成员与验收成员。
- 调整： 界面成员调整展示，验收成员补充相应检查，再分别回报。
- 核对： 负责人确认各方使用的是同一版约定，继续安排下一步。
从四份“完成”收拢成一个可以验收的结果
每名成员结束本阶段工作时，应通过 report_team_result 结构化汇报结果、改动文件、检查证据和未满足的验收项。负责人核对实际报告、消息和文件差异，再把问题交回负责成员修正。“已报告”不等于报告文件、投递和验收都已完成。
检查要落在同一个候选版本上。验收之后又修改了相关文件，就需要复查受影响的路径，不能沿用之前的成功结论。
对导出中心，至少检查下面列出的实际路径。
| 检查 | 要看到什么 |
|---|---|
| 管理员导出筛选结果 | 下载内容与合成数据的预期行和字段一致，没有漏掉筛选条件 |
| 普通成员直接请求接口 | 被服务端拒绝，没有只靠隐藏按钮限制权限 |
| 没有匹配数据 | 页面给出没有匹配记录的提示，不生成 CSV 文件 |
| 请求失败后重试 | 错误可理解，筛选条件保留，重试行为符合约定 |
| 手机与键盘 | 操作入口可见，焦点可用，提示不被裁掉 |
把交付证据和未完成事项一起留下
队伍记录中的 reported 表示成员已回报、仍待核实；verified 表示负责人已记录验证结论，卡片的已验证计数据此更新。成员空闲、计数增加或一句“已完成”，都需要结合具体证据理解。
负责人最后可以用下面的格式交付，方括号都必须由实际证据填入。
交付范围：[这次实现的行为]
候选版本：[本次文件快照或已有提交标识]
已通过：[检查项、环境、结果证据]
待处理：[问题、负责成员、下一步]
未验证：[缺少环境、数据或权限的路径]
成员报告：[报告位置和最终差异]
生产状态：本轮未提交、未部署为什么这对小团队有商业价值
同一个人做多个部分，往往要反复切换上下文。用了多个会话以后，如果没人协调，也会把节省的时间花在补背景和对齐接口上。
Team 提供了一个可持续查看和接续的组织方式：接口约定有负责人，界面问题有对应成员，验收缺口可以带着证据回到原任务。独立工作有机会同时推进，发现阻塞时也比较容易定位下一步。
试点时，可以记录人工转述次数、澄清轮数、依赖等待时间、验收后的返工以及模型用量。与相近复杂度的任务比较，才能判断是否值得继续扩大。不能用“四个会话”直接换算成“四倍效率”。
Anthropic 的 AI-native SDLC playbook 讨论了贯穿研发阶段的协作与验证，也把并行会话和独立检查放进工作方式中。这里的具体应用，是把一项需求组织为可跟进的 Onevium 会话队伍；本文的业务案例、任务提示词和分工方案为独立设计。
功能验收后，继续交给一支内容队伍
开发成果还可以成为教程和推广的输入。先整理一份真实功能清单：哪些用户能用、已经验证什么、有哪些限制，以及允许公开哪些截图。
然后在另一个负责人会话里，针对同一个导出中心组织内容工作：教程成员负责步骤，演示成员负责录屏脚本，推广成员负责文章与社交草稿。这个负责人只接收已经核实的事实和可公开素材，避免把内部研发讨论原样交给对外文案。
在另一个负责人会话中发送下面的任务，只以已验证事实和可公开素材准备本地内容草稿。
请先给出一支内容 Team 的计划，等我确认后启动。
输入：我提供的已验证功能清单、可公开演示素材和目标读者说明。
目的：帮助第一次接触导出中心的管理员理解用途并完成一次操作。
成员1整理操作教程，成员2整理演示脚本，成员3整理博客摘要与社交文案草稿。
各自写入独立文件，只有负责人维护共同事实清单与最终整合稿。
每个功能主张都要对应输入里的证据；缺少证据时标为待核实。
从用户的问题开始，说明实际步骤和适用条件，不编造客户或效果数字。
只生成本地草稿，不发帖、不发送邮件、不发布网站。延伸阅读
这套安排把提出需求、分工实现、核对结果和准备传播连起来。想先看研发全流程，可以阅读已有的 AI 原生研发实践；实际开始时，对照 Team 文档核对入口、条件和排错步骤。