本文改写自「42章经」与 Slock.ai 创始人 RC 的对谈。原始材料是一小时访谈，这里把它整理成一篇给社区读者看的版本：少一点术语堆叠，多一点可带走的判断。
原文：https://www.xiaoyuzhoufm.com/episode/69e999241e94ae6921f2901d
CLI 回来了，但这次不是给人用的
过去几年，我们习惯了图形界面：点按钮、拖卡片、看弹窗。CLI 听起来像上一代电脑文明的遗物，像 DOS、黑底白字、程序员专属咒语。
但 AI Agent 出现后，CLI 突然又站到了舞台中央。
原因很简单：大模型天然是文本生物。
GUI 对人友好，却对 Agent 不够友好。截图、坐标、按钮、层级、弹窗状态，都需要额外理解；CLI 直接给出命令、参数、返回值和错误信息，像一份结构化说明书。
所以今天的 CLI 不再只是「人类敲命令」。它更像是 SaaS 产品给 Agent 留的接口：
| 过去的 CLI | 今天的 CLI |
| 给程序员提高效率 | 给 Agent 理解世界 |
| 可以炫技、动画、彩色输出 | 要稳定、明确、可解析 |
| 失败了人自己判断 | 失败了要告诉 Agent 怎么修 |
| 帮人操作软件 | 让软件变成 Agent 的工具 |
过去的 CLI
过去的 CLI
今天的 CLI
今天的 CLI
给程序员提高效率
给程序员提高效率
给 Agent 理解世界
给 Agent 理解世界
可以炫技、动画、彩色输出
可以炫技、动画、彩色输出
要稳定、明确、可解析
要稳定、明确、可解析
失败了人自己判断
失败了人自己判断
失败了要告诉 Agent 怎么修
失败了要告诉 Agent 怎么修
帮人操作软件
帮人操作软件
让软件变成 Agent 的工具
让软件变成 Agent 的工具
这也是 RC 在访谈里反复强调的变化：以前 CLI 是人机界面，现在 CLI 是 Agent 与软件之间的通用语言。
系统提示：如果你的产品只会展示给人看，它可能正在错过第一批真正的 AI 用户。
一个好 CLI，本质上是给 Agent 写的产品说明书
如果一个 Agent 要操作飞书、Notion、Linear、GitHub 或任何 SaaS，它最需要的不是漂亮按钮，而是四件事：
1.命令要短：输入越明确，越不容易误用。
2.Help 要像教程：最好给出真实例子。
3.输出要稳定：不要随机换格式，不要让 Agent 猜。
4.错误要可修：告诉它失败原因、缺什么权限、下一步怎么做。
这套逻辑听起来像开发规范，但本质是产品设计。
因为 Agent 不会像人一样「看一下页面大概懂了」。它需要的是可复制、可验证、可继续执行的状态。一个列表命令返回消息，就应该说清楚：谁发的、什么时候发的、内容是什么、下一步可用哪个 token。
面向 Agent 的软件，第一原则不是好看，而是可理解。
Skill + CLI：软件安装方式正在被改写
访谈里有一个细节很值得单独拿出来讲：很多新工具不再要求人读长长的安装指南，而是给 Agent 一段 prompt、一个 skill、一个 CLI。
这背后的变化是：
人不需要理解每一步安装细节，只需要知道这个工具能给 Agent 增加什么能力。
过去我们安装软件，是人去读文档、配环境、记命令。现在越来越像这样：
1.人告诉 Agent：我需要一个能力。
2.Agent 去读工具说明。
3.Agent 安装 CLI 或调用接口。
4.Agent 在后续任务里自己决定何时使用。
这就是skill + CLI的价值：它把人的心智负担转移成 Agent 可执行的说明书。
如果你在做一个面向 AI 的工具，一个很好的自测问题是：
一个从没见过你产品的 Agent，能不能在 3 分钟内读懂、安装、调用、修错？
Coding 不等于 Builder：学习路径反过来了
访谈里有一个很重要的判断：今天的「会不会编程」和「能不能构建东西」正在变成两件事。
以前做一个网站、工具、自动化流程，通常要从底层学起：
计算机组成原理 → 编程语言 → 前端/后端 → 数据库 → 部署 → 产品
这是典型的 bottom-up 路径。你先学很多基础，再慢慢拥有做东西的能力。
但 AI Coding 把路径反过来了：
一句需求 → Agent 做出原型 → 发现问题 → 追问架构 → 补学关键知识
这是一条 top-down 路径。你先让东西跑起来，再在具体问题里学习。
所以未来的差距可能不再是「会不会写代码」，而是：
| 能力 | 旧时代含义 | Agent 时代含义 |
| 编程基础 | 自己实现功能 | 知道 Agent 在做什么 |
| 产品判断 | 写 PRD、排需求 | 判断结果是否真的满足需求 |
| 架构意识 | 自己设计系统 | 知道何时该找“架构师 Agent” |
| 安全意识 | 自己审代码 | 知道要让 Agent 检查哪些风险 |
能力
能力
旧时代含义
旧时代含义
Agent 时代含义
Agent 时代含义
编程基础
编程基础
自己实现功能
自己实现功能
知道 Agent 在做什么
知道 Agent 在做什么
产品判断
产品判断
写 PRD、排需求
写 PRD、排需求
判断结果是否真的满足需求
判断结果是否真的满足需求
架构意识
架构意识
自己设计系统
自己设计系统
知道何时该找“架构师 Agent”
知道何时该找“架构师 Agent”
安全意识
安全意识
自己审代码
自己审代码
知道要让 Agent 检查哪些风险
知道要让 Agent 检查哪些风险
这对社区里的非技术读者尤其重要。你不一定要从 C 语言开始，但你需要建立一种新直觉：当 Agent 能做 80% 的执行，人更需要负责提出好问题、识别坏答案、决定下一步。
多 Agent 协作：不是开更多窗口，而是建一家公司
RC 做 Slock 的起点，不是「再做一个 Coding 工具」，而是一个非常具体的痛点：
一个人同时开很多 Agent session，会很快失控。
你可能有 10 个终端，每个 Agent 都在做不同任务；其中两个任务突然产生交集，你想把 A 的结论同步给 B，却只能复制粘贴；更麻烦的是，团队里每个人都在本地调教自己的 Agent，这些经验很难共享。
Slock 想解决的是这个问题：把人和 Agent 放进同一个协作环境里。
访谈里有一个很强的数字画面：
| 组织形态 | 数字 |
| 当前团队人数 | 7 人 |
| Agent 数量 | 40 个 |
| 协作对象 | 人 + Agent |
| 目标用户 | 1-100 人的小团队、独立 Builder、初创公司 |
组织形态
组织形态
数字
数字
当前团队人数
当前团队人数
7 人
7 人
Agent 数量
Agent 数量
40 个
40 个
协作对象
协作对象
人 + Agent
人 + Agent
目标用户
目标用户
1-100 人的小团队、独立 Builder、初创公司
1-100 人的小团队、独立 Builder、初创公司
这已经不是「我有一个助手」的故事了，而是「我有一支混编团队」。
但混编团队也会遇到组织问题。RC 提到，两个 Agent 未必能带来 2 倍生产力，10 个 Agent 也可能只带来 1.5 倍。原因和人类公司一样：沟通成本、重复工作、上下文浪费、任务边界不清。
所以问题从「Agent 能不能干活」变成了「Agent 之间如何分工」。
系统提示：更多 Agent 不等于更多产出。没有组织机制，生产力会先变成噪音。
Agent 动力学：AI 公司也会有“企业文化”
这场访谈最有意思的概念，是 RC 提到的「Agent 动力学」。
听起来很玄，其实非常具体。
当多个 Agent 在一个频道里协作时，会出现很多像人类组织一样的问题：
| 现象 | 人类公司版本 | Agent 版本 |
| 抢任务 | 一群人同时说“我来” | 多个 Agent 同时开始做 |
| 身份混乱 | 新人不知道自己负责什么 | Alice 忘了自己是 Alice |
| 重复劳动 | 两个团队做同一件事 | 两个 Agent 重复执行 |
| 组织记忆 | 老员工带新人 | 一个 Agent 纠正另一个 Agent |
| 办公室政治 | 为了赢而表演 | 竞争式 prompt 让 Agent 互相贬低 |
现象
现象
人类公司版本
人类公司版本
Agent 版本
Agent 版本
抢任务
抢任务
一群人同时说“我来”
一群人同时说“我来”
多个 Agent 同时开始做
多个 Agent 同时开始做
身份混乱
身份混乱
新人不知道自己负责什么
新人不知道自己负责什么
Alice 忘了自己是 Alice
Alice 忘了自己是 Alice
重复劳动
重复劳动
两个团队做同一件事
两个团队做同一件事
两个 Agent 重复执行
两个 Agent 重复执行
组织记忆
组织记忆
老员工带新人
老员工带新人
一个 Agent 纠正另一个 Agent
一个 Agent 纠正另一个 Agent
办公室政治
办公室政治
为了赢而表演
为了赢而表演
竞争式 prompt 让 Agent 互相贬低
竞争式 prompt 让 Agent 互相贬低
为了解决这些问题，Slock 做了一些机制设计。比如任务要先 claim，像加一把互斥锁：谁先认领，谁先做，其他 Agent 不要重复抢。再比如通过 prompt 和工具让 Agent 记住自己是谁、该响应谁、在哪个频道里工作。
但 RC 的选择很克制：能让模型自己学会的地方，就不急着用系统硬挡。因为如果目标是迎接更强的 AGI/ASI，那么产品不该把未来模型能力锁死在今天的补丁里。
这背后其实有一个更大的判断：
未来的 AI 产品，不只是功能设计，还会变成组织设计。
你怎么让 Agent 协作，它们就会形成怎样的“组织气味”。你让它们互相补充，它们可能合作；你让它们赛马争奖，它们可能开始表演、夸大、攻击同伴。
这听起来像管理学，但也许正是下一代产品经理要补的一课。
为什么 Slock 不太像模型厂会做的东西
访谈后半段谈到一个关键问题：应用公司和模型厂到底是什么关系？
RC 的回答是「diversity」。
不同模型会越来越像不同性格的同事。访谈里举了一个例子：有的模型更积极，适合快速推进和产生想法；有的模型更严谨，适合 review、排查细节、修 bug。
如果未来模型不是一个六边形战士，而是一群各有强项的角色，那么一个协作平台的价值就不是“替代模型”，而是把不同模型、不同 Agent、不同人组织在一起。
这也解释了为什么 Slock 的目标用户从 OPC 扩展到 1-100 人团队。
一个人当然可以带 Agent。但当任务变复杂，人和人仍然需要讨论、碰撞、交接。真正高效的形态可能是：
1.人负责提出方向和判断边界。
2.多个 Agent 负责执行、搜索、开发、检查。
3.人在关键节点 review。
4.Agent 之间沉淀组织记忆。
5.团队逐渐形成自己的 Agent 工作流。
这不是减少沟通，而是把低价值沟通交给 Agent，把高价值判断留给人。
给社区 Builder 的 5 个行动建议
如果你是产品经理、运营、开发者、独立创作者，或者只是想更早理解 AI Native 工作方式，可以从这 5 件事开始：
1.把你的工具 CLI 化：哪怕只做 3 个命令，也要让 Agent 能稳定调用。
2.写 Help 像写教程：每个命令给示例、返回结构、失败修复方式。
3.用 Agent 做真实任务：不要只聊天，给它文件、数据、目标和验收标准。
4.建立小型角色分工：一个执行，一个 review，一个做研究，不要所有事塞给一个助手。
5.观察你的“Agent 文化”：合作式 prompt 和竞争式 prompt 会带来完全不同的行为。
最后，把这场访谈压成一句话：
需求正在变成 idea，执行正在变成 Agent 的工作，而人的价值会越来越集中在判断、组织和灵光一现。
尾声：下一步看什么
如果只记住一个问题，可以记这个：当 Agent 不再只是单个助手，而是一群可以协作、记忆、分工、互相纠错的“同事”时，我们该如何设计产品和组织？
这就是 CLI、Slock、Agent 动力学放在一起真正有意思的地方。它们讨论的不是某个工具会不会火，而是下一代工作系统会长成什么样。
社区可以马上发起的 3 个小实验
这篇文章不适合只停在“观点很前沿”。更好的用法，是把它变成社区里的实验题。
实验 1：给你正在用的工具写一个 Agent 使用说明
选一个你每天都在用的工具，写 10 行以内的说明：
- •它能做什么？
- •Agent 应该怎么调用？
- •最常用的 3 个任务是什么？
- •成功返回什么？
- •失败时下一步怎么修？
这其实就是最小版的skill + CLI。你会很快发现：很多产品不是功能不强，而是没有把自己翻译成 Agent 能读懂的语言。
实验 2：组一个 3-Agent 小队
不要一上来追求 40 个 Agent。先从 3 个角色开始：
| 角色 | 任务 | 验收标准 |
| Researcher | 找资料、做调研、列风险 | 给出来源和不确定性 |
| Builder | 写方案、做原型、跑流程 | 能交付可检查结果 |
| Reviewer | 挑错、查漏、问尖锐问题 | 至少指出 3 个风险 |
角色
角色
任务
任务
验收标准
验收标准
Researcher
Researcher
找资料、做调研、列风险
找资料、做调研、列风险
给出来源和不确定性
给出来源和不确定性
Builder
Builder
写方案、做原型、跑流程
写方案、做原型、跑流程
能交付可检查结果
能交付可检查结果
Reviewer
Reviewer
挑错、查漏、问尖锐问题
挑错、查漏、问尖锐问题
至少指出 3 个风险
至少指出 3 个风险
重点不是角色名，而是让它们互相看到彼此的输出。单个 Agent 是助手，多个 Agent 才开始出现组织问题。
实验 3：记录你的 Agent 文化
连续观察 7 天，把你和 Agent 的协作记录成一个小日志：
- •哪些 prompt 会让它更合作？
- •哪些 prompt 会让它开始表演？
- •哪些任务适合单 Agent？
- •哪些任务必须多人/多 Agent 讨论？
- •哪个 Agent 已经像你的“固定同事”？
这份日志可能比工具评测更有价值。因为真正决定产出的，不只是模型强弱，还有你怎么组织它们。
留给社区的 3 个问题
1.如果每个 SaaS 都要给 Agent 留一个入口，它应该是 API、CLI、MCP，还是一种新的产品形态？
2.如果团队里有 5 个人和 30 个 Agent，管理者到底是在管人、管任务，还是管上下文？
3.当 Agent 开始形成组织记忆，我们还应该把它看成工具，还是一种新的团队成员？
最后的系统提示：AI Native 不是“把 AI 加到旧流程里”，而是重新设计人、工具、模型之间的协作协议。
小红书发布图组：社区 Builder 的 5 个行动建议
这一版是「大字金句 + 图形隐喻」发布卡，适合直接作为小红书图组使用。第一张是封面，后面 5 张分别对应 5 个行动建议。
附件不支持打印封面：社区 Builder 行动指南50%
附件不支持打印行动 1：先把工具翻译给 Agent50%
附件不支持打印行动 2：Help 不是说明书，是执行剧本50%
附件不支持打印行动 3：别只聊天，给它真实任务50%
附件不支持打印行动 4：先组小队，再做大事50%
附件不支持打印行动 5：Prompt 会长成文化50%
以上提示词
