如果你没时间看完官方 8 小时 45 分钟回放，这篇文章不把重点放在“多创建几个 Bot”，而是回答一个更大的问题：一个 AI 原生组织，如何把人、Bot、数据、产品和工程串成一套工作系统？
Day 1 展示的不是一场完美 Demo，而是一家公司如何在公开环境里搭岗位、分任务、查数据、改方向、写产品规格、做设计、交给工程，再把结果带回创始人面前。
先给结论：Bot 真正有用，不是因为它更会聊天，而是因为它进入了组织的工作回路：任务先有可衡量的完成定义；岗位有固定职责和可用工具；交付带着可检查的证据；高风险动作会停下来问人。
普通聊天做完这一轮就结束；Bot 会保留岗位、偏好和工作上下文，下一次还能接着做。但一个 Bot 仍然只是一个岗位，不是一家公司。公司要靠多个岗位之间的交接，以及人类在关键节点上的判断，才能形成系统。
先看一张地图：Day 1 的六个角度
角度
关键问题
可复用的做法
心智
Bot 到底是什么？
把它当有职责、有上下文、有交付标准的同事
组织
谁和谁协作？
CoS 接收人类目标，再协调 ops、data、design、eng
工程
怎样让执行可信？
云 agents 执行，PR、截图、测试和指标留下 proof
产品
如何避免做错东西？
先问数据，再纠错，再走 PRD、设计和工程
创始人
人类还负责什么？
卸掉追状态的注意力税，只在判断和审批处介入
主线
为什么要公开过程？
展示中间态，不把未完成伪装成完美 Demo
后面的文章先解释这套组织系统，再给一条 30 分钟的最小落地路径。依据是 2026 年 9 月 15 日 Grok Bot Galaxy Day 1 的官方文档、直播回顾和现场笔记；产品资格、界面和用量以当前账号页为准。
1. 心智：Bot 是同事，不是对话框
一个值得长期使用的 Bot，至少要能回答四个问题：
问题
合格答案
它长期负责什么？
一类会重复的工作，而不是“什么都做”
它能碰到什么？
明确的表、文档、网页、代码或云电脑
做完怎么证明？
文件、链接、截图、视频或数字
哪些动作必须停？
外发、花钱、删除、发布、改正式环境
这四个问题比“它的人格像不像同事”更重要。岗位说明负责长期规则，任务消息负责这一次的交接，证据负责证明它真的做完了。
同一账号下的 Bot 不共享记忆，但共享一台云电脑。这台电脑是远程浏览器、终端和文件空间，不是你眼前的 Mac；公开文档把 Bot 之间的共享工作目录写作 /workspace。共享文件很方便，但也意味着 Bot 之间不是安全隔离的员工账号。
2. 组织：人不应该直接管理每一个 Bot
Day 1 的关键不是“一个人配很多 Bot”，而是把不同类型的工作拆成岗位，再用一个统一入口协调它们：
角色
负责什么
典型交付
CoS
守住任务目标、拆任务、汇总结果、提醒审批
决策简报、what-shipped、待办清单
Ops
维护流程、Routine 和 playbook
可复用步骤、运行记录
Data
找数据、验证假设、保留来源
数据表、异常说明、证据链接
Design
把已验证的问题转成方案
设计稿、交互说明、演示视频
Eng
实现、测试、提交 PR 并附 proof
PR、测试结果、部署说明
Reviewer（验收岗）
按完成标准验收，指出该退回哪个岗位
通过 / 退回意见、缺失证据清单
人类
做方向判断，批准不可逆动作
取舍、审批、最终决策
这里的 CoS 可以理解为“首席幕僚”或“统一调度岗”，不一定是产品里的特殊按钮。它的作用是让创始人尽量只面对一个入口，其他 Bot 的结果通过消息、文件和 playbook 交接回来。
一个最小组织回路是：
创始人写清任务合同 → CoS 拆任务 → 专职 Bot 执行 → Reviewer 验收 → CoS 提炼 what-shipped → 人类做判断或审批。
这条线还要有回程：验收没过时，Reviewer 不自己悄悄重做，而是把工作退回 Data、Design 或 Eng，并写清哪一条验收标准没过。能退回的流程才是工作图；只能一路向前传的，只是一条容易把错误传到终点的流水线。
同一账号下的 Bot 可以共享云电脑里的文件，但不共享各自的记忆。需要另一个岗位学到某件事时，写成明确的 playbook 或结果文件，不要把整段聊天复制过去。
先写任务合同，再谈岗位分工
“每周研究竞品”是一个动作，不是一个能验收的任务。更可用的说法是：每周五下午交一页竞品变化简报，列出五个最重要的产品、价格或定位变化；每条事实附来源和日期；最后给出三条建议；未经批准不对外发送。
第一轮只要把下面七项写清，CoS 才知道什么叫完成：
字段
要回答的问题
Outcome
这轮到底要拿到什么结果？
Inputs
允许读取哪些资料、账号和工具？
Output
最终产物具体是什么文件、页面或 PR？
Frequency
这是一次性任务，还是何时重复？
Definition of Done
满足哪些可检查条件才算通过？
Constraints
哪些事绝不能做？
Approval Gates
哪些动作必须由人点头？
岗位说明再往下拆成：角色 → 输入 → 动作 → 输出 → 验收标准 → 交接对象。交接时不要只说“我找到了这些”，而要交一张卡：目标、产物、证据、状态、不确定项、阻塞，以及下一步该由谁做什么。证据跟着工作走，下一位 Bot 就不用从聊天记录里猜前因后果。
3. 工程：每个执行都要留下 proof工程场真正值得普通团队抄的，不是凌晨 3 点同时开多少个 agents，而是下面四条：让云 agents 执行具体工作。 每个 agent 都有范围、输入和交付物，不要把“帮我把项目做好”当任务。PR 必须带 proof。 证明可以是测试结果、截图、指标、复现步骤或短视频；只有一句“已完成”不算交付。夜间任务只做可回收的工作。 例如扫描仓库质量、整理模块、跑测试、清理临时文件；早上人审结果，不让无人值守流程直接做不可逆动作。紧急也走步骤。 ASAP 只能改变优先级，不能跳过来源、验证、审批和记录。工程岗位交付的不是“代码已经写了”，而是：改了什么 → 怎么验证 → 结果在哪里 → 哪些仍然没有验证。正常路径写清楚还不够。真正的 playbook 还要提前约定：来源查不到时标成未验证；两份资料冲突时把冲突并列交给 Data；工具不可用时停在阻塞点，不用编出的结论填空；Reviewer 拒收时，退回造成问题的岗位而不是让 Reviewer 把活全做掉。例外不是流程外的尴尬情况，例外才是自动化真正会遇到的工作。
4. 产品：先问数据，再允许纠错
Flylo 演示最值得复制的不是航空公司的数字，而是产品决策的顺序：
问数据 → 纠正猜测 → 写 PRD → 做设计 → 交给工程 → 用 proof 回报结果。
现场的例子是：人先猜漏斗卡在“选座”，数据 Bot 查数后指出真正的大漏点在“搜索 → 选价格”。产品 Bot 再把这个结论写成问题定义和验收标准，设计 Bot 把它变成界面方案，工程 Bot 实现并返回测试和演示证据。
如果 Bot 没接到当前数据，它没有资格推翻你的判断，最多只能给出待验证假设。你可以用周报、订单表、广告后台或 GitHub issue 做同样的测试：拿一个你已经相信的结论去问，要求它引用来源支持或反驳。
产品链上每一次交接都要保留一个可读文件：
Data 交付数据和来源链接。
Product 交付 PRD、范围和验收条件。
Design 交付设计稿、关键取舍和演示。
Eng 交付 PR、测试结果和未解决问题。
CoS 把这些压成创始人能判断的一页 what-shipped。
5. 创始人：先卸掉注意力税，再谈速度
创始人最贵的成本，往往不是亲自写代码，而是不断追问：
现在做到哪了？
谁在做？
为什么还没完成？
下一步需要我决定什么？
这个结果有什么证据？
这就是注意力税。CoS 和专职 Bot 的价值，不是替创始人做所有决定，而是把状态、证据和待决策事项整理好，让人类只在真正需要判断的地方介入。
每次 Demo 前，先让 CoS 生成一份 what-shipped：
本轮已经完成：
每项完成的证据：
仍未完成：
当前阻塞：
需要创始人决定：
下一步建议：没有 proof 的“完成”，只能写进“待验证”；没有明确决策的问题，不要用更多汇报制造速度感。
6. 主线：公开中间态，不演完美 Demo
Day 1 的开公司主线从空 GitHub 开始，产品方向也在不断改。这条线的价值不在于证明“三天已经成功”，而在于公开展示一个 AI 原生组织真实工作的样子：
猜错了什么？
哪个数据让方向改变？
哪个岗位交接失败了？
哪个动作需要人批准？
哪个结果暂时不能证明？
公开中间态不是表演失败，而是把工作系统暴露出来。读者真正能学习的不是一个完美的最终 Demo，而是组织如何处理不确定性、返工、等待和未完成。
7. 30 分钟搭一个最小工作系统
现在才开始动手。第一轮不要搭完整“公司”，只搭一个能跑通闭环的岗位。
开始前准备
能打开 Grok Bot 的账号和桌面应用。
一个不会泄露隐私的测试文件夹，里面放一份脱敏表格或 PDF。
一个明确交付物，例如“一页异常总结”。
一个暂时不需要自动发送、付款、删除或发布的任务。
如果没有 Google Drive，也可以先把文件拖进对话框。第一轮只验证：
给任务 → 读取资料 → 得到结果 → 检查证据。
第零步：写一个任务合同
别先创建五个 Bot。先挑一个昂贵、会重复、但不涉及外发或付款的结果，例如“每周一份带来源的销售异常简报”。在一张文档里写下：结果、允许读取的输入、产物、完成标准、禁止项和审批门。
第一轮不需要定时。你要先确认这个任务真能稳定验收，再考虑让它自动跑。
第一步：创建岗位
创建路径是 New → Create new agent，打开 Bot 后进 View conversation details → Agent settings，修改名称、描述和通知。下面这张是本机实际界面截图，字段名称会随版本变化。
把描述写成一份小契约：
岗位：你负责________。不是万能助手。
输入：只使用________（表 / 文档 / 网页 / 仓库）。缺少就说明。
这次要交：________（文件 / 页面 / 清单）。
怎样算完：必须附截图、链接、视频或数字；没有证据等于没做。
必须问我：外发、花钱、删除、发布、改正式环境。
保持安静：没有结果、异常或需要审批的节点，就不要主动汇报。
禁止：不要编数据；紧急也不能跳过验证；不确定先问。
要让 Grok Bot 使用 Drive，在 Bot 应用里打开 Settings → Plugins（市场），找到 Google Drive，安装后按页面提示在浏览器完成认证。不同版本的按钮名称可能略有不同；以“插件已安装”以及 Bot 对话里能提及该 connector 为准。
Grok Bot 的 connector 是应用内插件体系的一部分。它的授权和可用性受 Bot / Cursor 侧的插件设置与团队策略控制；不要把 Grok 网页、Grok Bot 和某个单独 Bot 当成三个彼此隔离的保险箱。尤其是同一账号下的 Bots 共用云电脑，连接器、浏览器登录和工作文件都应该按“同一工作环境里的共享能力”来管理。
装好后，先在脱敏文件上做一次只读测试：
在 Google Drive 找到《本周销售表》，只读分析，不修改原文件。
输出一页总结：异常行、可能原因、需要我确认的问题，并附原文件链接。
通过测试后，Bot 可以在已授权范围内按需搜索、读取或写回 Drive 文件；它不会自动把整个 Drive 变成 Bot 记忆。第一次不要接支付、客户消息或生产资料；用完不再需要的插件，应在 Bot 应用里卸载并在 Google 账号里撤销授权。
第四步：跑一条完整任务链
用一份测试销售表跑下面这条链：
在 Drive 里准备 sales-test.csv，只放脱敏数据。
让 Bot 找到它，先只读，不修改原文件。
要求输出“异常行、可能原因、需要确认的问题”，每项附来源链接或行号。
打开结果卡片检查：文件是否是这周的、数字能否回到原表、有没有把猜测写成事实。
合格后再让它另存为 sales-review.md 或 Google Doc。
这一次同时验证了连接、读取、交付和证据四件事，而不是只得到一段看起来合理的文字。
第五步：加上审批门和验收岗
打开 Settings → General → Auto-review，添加窄范围规则：
发送任何外部邮件前先询问我。
修改生产环境仪表盘前先询问我。
在 /workspace/reports 里运行 git status 可以自动执行。看到 Allowed once，理解成“只允许这一次访问”；看到 Approve Send，说明邮件仍是草稿，必须由人批准才会发送。
再把权限写成三档，避免不是太松、就是每一步都来打扰你：
级别
Bot 可以做什么
例子
绿
不问人即可做的可逆、低风险工作
搜索、阅读、整理、比较、计算、起草
黄
只在批准的内部工具和范围内做
改测试文档、写内部数据库、移动已批准文件、运行已保存 Routine
红
无论如何都要停下来问人
外发、发布、花钱、删除、联系他人、改权限、改生产环境
先给研究岗位只读资料，先给工程岗位测试环境；不要一开始连接支付、密码管理器、客户消息或生产数据库。自主权应该加快执行，不应该放大一次误操作的代价。
最后单独设一个 Reviewer。它拿着任务合同、源材料、最终产物和检查表，只回答两件事：通过，或哪条标准没过、该退回谁。它不是第二个执行 Bot；如果它每次都默默改完，真正的瓶颈和流程漏洞会被藏起来。
8. 先跑三次，再扩展
一次看起来不错的结果，常常只是任务刚好简单。不要第一次成功就设成 Routine。用同一份任务合同跑三次：
观察。 全程看一遍，记录哪里丢了上下文、重复了工作、误解了指令、意外撞上审批，或没有通过验收。
纠正。 换一个有代表性但不完全相同的输入再跑。修岗位契约、交接卡或 Routine 本身，不要只手工把这次成品修漂亮。
放行。 尽量不插手；只在红色动作、任务合同含糊，或同一个纠错循环连续三次失败时介入。
每次至少看五个数：完成率、人类介入次数、验收退回次数、到“验收通过”的时间、每个验收通过结果的成本。没有这些，所谓“自动化成功”只是在记一次顺利的演示。
把每次退回的原因写回岗位契约、playbook 或稳定记忆，工作系统才会形成：
执行 → 验收 → 纠正 → 记住 → 下一次执行得更好。
9. 什么时候值得继续扩展
一次性任务稳定后，再考虑：
重复出现的步骤，下沉成 Skill。
需要定时或事件触发的流程，做成 Routine。
目标、数据源或审批边界稳定分开，再增加第二个专职 Bot。
人类需要一个统一入口时，让 CoS 汇总结果和 what-shipped。
不要一开始就把所有人、所有数据和所有自动化塞进一个万能 Bot。先让一个最小工作系统跑通，再按真实瓶颈扩展。
最后：一份系统检查清单
每件重复任务先有一份任务合同：结果、输入、产物、完成标准、禁止项和审批门。
我能说清每个 Bot 的岗位和边界，也知道验收不通过时要退回谁。
我知道谁是统一调度入口，谁负责数据、产品、设计和工程。
每个重要交付都带 proof，而不是只有一句“已完成”。
产品结论能回到数据，PRD、设计和工程之间有文件交接。
Demo 前有一份 what-shipped，未完成项没有被隐藏。
外发、花钱、删除、发布和正式环境变更都有审批门。
绿、黄、红三档权限没有混在一起；第一轮只接最少的、以只读为主的工具。
Drive / 表格是事实和产物，Bot 记忆负责稳定偏好，S3 只是后台实现。
同一任务换不同输入连续跑过三次，再扩编、设高频 Routine 或交给夜间任务。
如果这些做不到，问题通常不是模型能力，而是组织、交接、证据或权限还没写清楚。