我说一个判断：
软件工业流水线这件事，光靠"个人 + Agent"是凑不齐的。
过去一年，AI 编程的进步几乎都集中在一对关系上：一个人，对一个聊天框，让 AI 帮我写代码。再升级一点，是个人看板——一个人，对一块看板，让 AI 沿着泳道把需求自己跑完。
这件事我们也做过：软件工业流水线的时代真的来临了 那篇讲的是看板的 6 个工位，一个 bug、一部手机、8 分钟 那篇讲的是一个人怎么在口袋里完成需求 → 交付的闭环，全程"我自己"和"我的 Agent"。
但软件团队不是一个人，AI 工位也不只一个。真实的研发流水线上，至少同时存在三种协作——
- 人 ↔ 人：PM 提需求，开发评审需求，Reviewer 审查交付
- 人 ↔ Agent：人写下意图和验收标准，Agent 接手执行
- Agent ↔ Agent：主 Agent 拆任务，Subagent 并行执行；一个 Agent 生成需求草稿，另一个 Agent 对照验收自检
这三种协作只要少一种，工业流水线就转不起来。
所以我们这次在 auto-coder.chat 上线了组织看板——它不是"个人看板的多人版"，它是第一次把这三种协作真正同时落到同一个产品里的那块平台。
先看入口：组织管理变成了一等公民
打开 auto-coder.chat Dashboard，顶部多出一个"组织管理"。点进去之后，你会看到一整套团队协作控制台，而不是又一块看板：
页面把组织相关的所有概念全摊开了——
- 概览：组织设置、组织 ID（
org1）、描述（"只负责帅气"是我随手写的） - 成员 1 / 角色 7 / 共享实例 1 / 看板权限 1 / 邀请收件箱 0：右上角的 5 个标签，每个标签后面那个数字就是这个组织当前的"零件清单"
- 右侧的组织概览：1 名成员、7 个角色、1 个共享实例、1 块看板，"我的角色: OWNER"
这块控制台对应到上面那三种协作：
- 成员 + 角色 → 处理"人 ↔ 人"的边界
- 共享实例 + 看板权限 → 处理"人 ↔ Agent"的边界
- 7 个默认角色 + 角色矩阵 → 给"Agent ↔ Agent"留下接口（哪个 Agent 以什么身份在哪一列上岗）
这页是整篇文章的总入口，下面每一节都是它的展开。
第一步：先有组织，再谈协作
组织看板的第一步，不是建卡片，而是建组织。
弹窗里只有三项：
- 组织名称：给人看的名字，例如
Auto-Coder 团队 - 组织标识：系统内部用的 slug，例如
team-alpha，创建后不可改 - 描述（可选）：这个组织负责哪些项目或团队
底下那行小字写得很直白——
组织用于共享看板、角色权限和可用实例，创建后你会自动成为 OWNER。
也就是说，"组织"这个概念在 auto-coder.chat 里不是一个空壳，它从一出生就和看板 / 角色 / 实例三件事绑定。这是和传统 SaaS"先建组织再慢慢配"最大的不同——它一上来就告诉你，这是一条工业流水线的容器，不是一个聊天群。
第二步：默认 7 个角色，一上线就够用
组织创建之后，系统会自动 seed 7 个角色：
| 类别 | 角色 | 典型岗位 |
|---|---|---|
| 系统 | OWNER | 老板 / 项目负责人 |
| 系统 | ADMIN | 团队管理员 |
| 系统 | MEMBER | 普通成员 |
| 自定义 | DEVELOPER | 程序员 |
| 自定义 | PM | 产品 |
| 自定义 | QA | 测试 |
| 自定义 | REVIEWER | 代码审查者 / 业务把关者 |
回到组织管理顶部那条 tab，点"成员 1"——能看到自己当前是 OWNER：
注意页面上的小字：
调整成员角色，移除成员或转让 OWNER。OWNER 不能通过普通改角色接口修改。
这一行就是"人 ↔ 人"协作的边界——OWNER 是一票通过的最高位，不能被偷偷改掉，必须显式走"转让 OWNER"。其他角色可以自由调整。
后面我们会看到，这 7 个角色不是一个装饰品，而是看板权限矩阵的列——每一列代表"这个角色在哪个泳道能干什么"。
第三步：把本机实例共享给组织——让 Agent 真有地方干活
人有了，组织看板上岗的第二个前提是：得有一台机器接活。
进"共享实例"标签：
页面分成两栏，左右职责非常清楚：
- 左栏 共享实例：当前已经共享给组织的实例池，组织看板只能派任务给这里面的实例
- 右栏 你的个人实例：你账号下所有已注册的本地 / 云端实例，每条后面有一个"共享"按钮
我这边只共享了一台 allwefantasy · auto-coder.chat，由我自己提供。下面挂着 docs.auto-coder.chat、hailin.zhu.portfolio、jiaoyang.local · william-docs、infiniSynapse 等 6~7 台候选实例，没共享就不能被组织调度。
这一栏是 auto-coder.chat 组织看板和绝大部分"云端 Agent SaaS"最大的区别——
代码、密钥、工程环境永远不出本机；云端只负责调度。
实例由组织成员显式共享，组织派发任务时再次校验实例是否还在共享池，成员退出组织自动解绑。
这条规则同时撑起了三种协作：
- 人 ↔ 人：组织看板上的任何卡片，所有人都能确切知道它会跑在谁的机器上
- 人 ↔ Agent：人提的需求被派到某台真实的本地实例，Agent 在那台机器上完成代码改动
- Agent ↔ Agent：主 Agent 在共享实例上拆任务，子 Agent 在同一台或同池的另一台机器上并行执行
第四步：给组织看板绑定默认实例
实例共享完，下一步是把它绑到看板上。
切到"组织需求看板"标签，左侧能看到组织名 公司一号、我的角色 OWNER、看板列表里有一块 default：
注：这张图里只看到 4 列泳道（待规划 / 待开发 / 进行中 / 待审查），是因为视口宽度不够，"已完成"列被横向滚出去了。组织看板和个人看板一样是5 列：待规划 / 待开发 / 进行中 / 待审查 / 已完成。
default 看板标题旁边的"+ 绑定默认实例"，点开是这样：
弹窗的下拉框里只能选共享实例池里的机器——这台 allwefantasy · auto-coder.chat 是上一节我刚共享进来的那台。如果当前没人共享实例，这里就是空的。
这就锁住了一件事：
组织看板不会偷偷使用任何成员的私人实例。所有由组织派发的任务，落点必须事先经过显式共享。
第五步：看板权限矩阵——让"谁能干什么"精确到泳道
这一步是组织看板真正和"普通团队 Trello"拉开差距的地方。
进"看板权限"：
矩阵分成两层。
第一层是看板级权限——决定一个角色对整个看板能做什么：
- 查看
- 设置
- 删除
- 管理权限
- 转出
- AI 生成需求
- 批量执行
第二层是泳道级权限——决定一个角色在某一列上能做什么。我截图时选的是 default 看板 + DEVELOPER 角色，先看"待规划"和"待开发"两列：
| 动作 | 待规划 | 待开发 |
|---|---|---|
| 查看 / 查看附件 / 评论 | ✅ | ✅ |
| 创建 | ✅ | ✅ |
| 编辑自己的 / 改自己的元数据 | ✅ | ✅ |
| 编辑任意 / 改任意元数据 | ❌ | ❌ |
| 设置自己的实例 / 设置任意实例 | ❌ | ✅ / ❌ |
| 删除自己的 / 删除任意 | ✅ / ❌ | ✅ / ❌ |
| 移入 / 移出 | ❌ / ✅ | ✅ / ✅ |
| 排序 | ✅ | ✅ |
| 执行 | ❌ | ✅ |
| 取消自己的执行 / 取消任意执行 | ❌ | ❌ |
| 审查通过 / 通过并提交 / 审查拒绝 | ❌ | ❌ |
| 上传/删除自己的附件 | ✅ | ✅ |
可以读出一个非常具体的设计：
- DEVELOPER 在"待规划"里能创建、能改自己的、能把卡片移走，但不能直接执行——"待规划"还没轮到 Agent 上岗
- 一旦卡片被移到"待开发"，DEVELOPER 才有权点执行——这就是"开发评审通过，把活交给 Agent"的物理动作
- 但 DEVELOPER 没有审查权——审查交给后面 REVIEWER 这条线
类似地，PM、QA、REVIEWER 各有自己的勾选模板。一个团队可以这样切：
PM：在"待规划"创建、补描述、上传附件；不能直接执行DEVELOPER：评审"待规划"，把成熟的卡移到"待开发"，按下 Agent 执行按钮QA：在"待审查"看附件、评论、补充验收条件；不动代码REVIEWER：在"待审查"按"通过 / 通过并提交 / 拒绝"OWNER / ADMIN：管理组织、成员、实例、权限
到这一步，人和人之间的协作边界就有了一份机械化的契约——不是开会口头约定，是矩阵里的一个勾。
第六步：从组织看板提一张真实的卡
权限设好之后，回到组织看板，点右上角"新建需求"：
字段还是熟悉的几样：
- 标题
- 描述
- 验收标准（"执行完成后可用于自动校验"——这是给 Agent 看的）
- 状态 / 优先级
- 绑定实例（"可选，不选则派发时使用看板默认实例"）
- 执行方式：
Auto-Coder/Cursor/Claude Code - 标签
- 附件
但放进组织语境后，它的语义全变了——
- "绑定实例"不是随便选自己机器，而是从共享池里选
- "执行方式"不只你一个人选，团队约定可以统一走 Auto-Coder 或 Cursor
- "验收标准"既是给 Agent 看的尺子，也是给后面 QA / REVIEWER 看的契约
我现场把它填成了一张关于这篇文章本身的卡：
- 标题：组织看板演示：把多人写作流程整理成文章
- 描述：这张卡由组织成员提出，用来把移动端修 bug 文章最后提到的多人协作场景，整理成一篇面向公众号读者的图文文章。PM 负责写清楚背景，开发负责补验收标准，Agent 负责生成草稿，Reviewer 负责审查。
- 验收标准：
- 文章解释清楚组织、成员、共享实例、看板权限之间的关系
- 包含从组织看板新建需求到待审查的完整流程
- 不把代码和密钥交给云端，执行仍在被共享的本地实例上完成
- 标签：
org-board, article, demo
这张卡片就是这篇文章本身。它当然可以让我自己一句话填完，但真正多人协作的场景里，它会经过 PM 草稿 → 开发补验收 → Agent 生成初稿 → Reviewer 把关 → 通过这条完整链路。
这条流水线的三种协作，分别落在哪里
我把上面这几步用三种协作的视角再扫一遍：
协作一：人 ↔ 人
落在组织 + 成员 + 角色 + 看板权限矩阵这一组概念里。
| 这件事 | 由谁约定 |
|---|---|
| 谁能进这块组织看板？ | 组织成员名单 |
| 进来之后他是谁？ | 角色（PM / DEVELOPER / QA / REVIEWER…） |
| 他在哪一列能动什么？ | 看板权限矩阵 |
| 谁说了算？ | OWNER |
这一组不是花架子。它把"评审权 / 执行权 / 审查权"这种过去靠 Slack 互相 @ 的事情，落到了一张可勾选的矩阵上。
协作二：人 ↔ Agent
落在验收标准 + 执行方式 + 共享实例这条链上。
- 人写：验收标准——这就是 Agent 接活之前看的"工序单"
- 人选：执行方式——是 Auto-Coder 自带 Agent，还是 Cursor，或 Claude Code
- 人决定：共享实例——任务最终在哪台真实机器上跑
- Agent 干：在共享实例上完成代码改动
- Agent 自检：对着验收标准逐条勾，写出判定理由
- 人审：在"待审查"列点"通过 / 通过并提交 / 拒绝"
这是组织看板里频次最高的一条协作。
协作三：Agent ↔ Agent
这是这次组织看板上线之后第一次能放心讨论的协作形式。
具体落地方式有 3 种：
- 新建需求时的 ✦ Agent 生成需求——一个 Agent 读完项目，自动吐出 5~10 张草稿卡，标题、描述、验收标准一并写好；后面是另一个 Agent 在共享实例上把这些卡逐张执行
- Subagent 分层执行——主 Agent 用 Opus / GPT 顶级模型在共享实例上拆任务，Subagent 用 doubao-seed 这种性价比模型并行执行（详见 SubAgent Is All You Need：效果好且廉价）
- 批量执行 + 自动接力——
⚡ 自动接力开关打开后，调度器在"待开发"列里按优先级自动挑下一张卡派给 Agent，跑完进"待审查"再自动启动下一张
三件事放在一起，就是"Agent 互相之间有上下游关系"——一个 Agent 提需求、另一个 Agent 拆任务、第三批 Agent 在性价比模型上并行执行、最后一个 Agent 自校验。
它们之间共享的"协议"，正是组织看板上的这套字段：状态、泳道、验收标准、关联会话、判定理由。
一条流水线，两个工位：审阅在网页，撰写在 WinClaw
到这里，组织看板的"骨架"就讲完了——成员、角色、共享实例、权限矩阵、需求卡。
但这条流水线还少一个东西：入口。
组织看板擅长的是"看"——一眼看到 6 块看板、22 张卡、4 台在线实例、谁卡在哪一列。
它不那么擅长的是"写"——尤其在手机上、在地铁上、在开会被 @ 到的瞬间，让你掏手机点"新建需求"，对着一个长表单填标题 + 描述 + 验收标准，是反人性的。
所以我们另写了一篇专门讲这件事的配套文章：auto-coder.chat 看板适合"看"，不适合"写"——所以我们让 WinClaw 来写。
那篇文章里讲的机制是：
- 在 auto-coder.chat 设置里生成一把 API Key
- 在 WinClaw 工具市场里给
accchat（一个 Command Tool）配上这把 Key - 之后在 WinClaw 聊天框里用一句中文，就能查询看板、创建需求、整理 bug 卡——甚至直接走微信入口在地铁上提卡
这就把组织看板的协作链路补完了——
| 工位 | 走哪边 | 为什么 |
|---|---|---|
| 审阅整条流水线 | auto-coder.chat 网页 | 看板视图最直观 |
| Review 某张卡 | auto-coder.chat 网页 | 详情页有 diff、日志、附件 |
| 拖卡换列、改字段 | auto-coder.chat 网页 | 鼠标点几下就完事 |
| 新建需求 / 整理一批 bug 卡 | WinClaw + accchat | 一句中文搞定 |
| 手机上提卡 / 追问状态 | WinClaw（含微信入口） | 不需要打开网页填表单 |
| 批量"帮我 review 一下 backlog" | WinClaw + accchat | AI 给口语化总结 |
审阅走 auto-coder.chat，撰写走 WinClaw——这一对配合，让组织看板真正像一条工厂流水线：
- 看板（auto-coder.chat 组织看板）= 流水线本体——状态、泳道、权限、执行轨迹、判定证据
- WinClaw + accchat = 流水线的撰写工位——人、PM、客户支持、老板、地铁上的开发，谁都能用一句中文往里送卡
- Agent + Subagent = 流水线的执行工位——在共享实例上跑代码、写根因、自校验
- 网页 dashboard = 流水线的中央控制屏——审阅、决策、放行
这件事和过去的"AI 编程协作"有什么本质不同
我做 Auto-Coder 这两年，看过太多"团队怎么用 AI 写代码"的方案。它们大多停在两个层级：
- 第一层："给团队每人买一把 Cursor / Claude Code"——本质上还是"个人 + Agent"乘以 N。每个人各干各的，AI 之间没有协作，人之间也没有正式的工序契约。
- 第二层："给团队搭一块多人看板"——比如 Linear / Jira / Vibe Kanban。能让人共享需求，但 Agent 仍然是"某个工程师电脑前的聊天框"，没有正式上岗的位置；Agent 之间也不互相协作。
auto-coder.chat 组织看板想做的是第三层：
把人和人、人和 Agent、Agent 和 Agent 这三种协作，全部装进同一块看板里，每一种都有正式的契约和边界。
具体一点：
- 人和人之间靠角色 + 权限矩阵约定边界
- 人和 Agent 之间靠验收标准 + 共享实例约定边界
- Agent 和 Agent 之间靠泳道 + 自动接力 + Subagent 分层约定上下游
只要这三种协作都通了，软件研发就真的具备了"工业流水线"的全部要件——标准化、流水线化、可审计——而不只是"AI 帮我写代码"那种小作坊形态。
写在最后
软件工业流水线的时代真的来临了 那篇讲的是看板的 6 个工位。
一个 bug、一部手机、8 分钟 那篇讲的是一个人怎么在口袋里完成需求 → 交付的闭环。
auto-coder.chat 看板适合"看"，不适合"写" 那篇讲的是我们怎么把入口从图形表单升级成一句中文。
这一篇组织看板，是把上面这几条线真正连成一条工业流水线的关键一步：
- 角色和成员让"人 ↔ 人"有边界
- 共享实例和验收标准让"人 ↔ Agent"有契约
- 自动接力和 Subagent 让"Agent ↔ Agent"有上下游
- WinClaw + accchat 让流水线入口做到一句中文
- auto-coder.chat 网页让流水线审阅做到一目了然
下次再有人在群里 @ 你说"这个需求谁来跟"，你不需要先问"谁有空"——
打开组织看板，提一张卡，让流水线自己开始转。
体验 auto-coder.chat 组织看板：auto-coder.chat。
配套撰写入口：在 WinClaw 工具市场里安装 accchat，参考 让 WinClaw 替你写。