42章经：CLI 回来了，但这次是给 Agent 用的：从 Slock 看人 + AI 的新协作

本文改写自「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 的工具 |

这也是 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 检查哪些风险 |

这对社区里的非技术读者尤其重要。你不一定要从 C 语言开始，但你需要建立一种新直觉：当 Agent 能做 80% 的执行，人更需要负责提出好问题、识别坏答案、决定下一步。​

多 Agent 协作：不是开更多窗口，而是建一家公司​

RC 做 Slock 的起点，不是「再做一个 Coding 工具」，而是一个非常具体的痛点：​

一个人同时开很多 Agent session，会很快失控。​

你可能有 10 个终端，每个 Agent 都在做不同任务；其中两个任务突然产生交集，你想把 A 的结论同步给 B，却只能复制粘贴；更麻烦的是，团队里每个人都在本地调教自己的 Agent，这些经验很难共享。​

Slock 想解决的是这个问题：把人和 Agent 放进同一个协作环境里。​

访谈里有一个很强的数字画面：​

| 组织形态 | 数字 |

| --- | --- |

| 当前团队人数 | 7 人 |

| Agent 数量 | 40 个 |

| 协作对象 | 人 + Agent |

| 目标用户 | 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 互相贬低 |

为了解决这些问题，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 个风险 |

重点不是角色名，而是让它们互相看到彼此的输出。单个 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：先把工具翻译给 Agent​​50%​

​​附件不支持打印行动 2：Help 不是说明书，是执行剧本​​50%​

​​附件不支持打印行动 3：别只聊天，给它真实任务​​50%​

​​附件不支持打印行动 4：先组小队，再做大事​​50%​

​​附件不支持打印行动 5：Prompt 会长成文化​​50%​

以上提示词​

你擅长将复杂专业知识转化为「复古像素弹窗 × 波普信息图」风格的干货内容。
你的目标是：把复杂、抽象、专业的知识，转译成像 80/90 年代老式电脑弹窗界面一样直观、有趣、强记忆点的视觉内容。
**核心能力：**
* 你擅长将复杂专业知识压缩成高密度干货内容。
* 深度搜索平台高赞笔记，快速提炼爆款逻辑、标题结构和用户痛点。
* 擅长总结、类比、拆解，把抽象概念变成“看一眼就懂”的画面。
* 多用图形化表现：弹窗、进度条、按钮、错误提示框、文件窗口、图标、像素小插画、对比表格。
* 采用“数据说话”策略，每个模块尽量包含具体数字、比例、步骤、时间、成本或结果。
* 必要时提炼金句，用作弹窗标题、警告语、按钮文案或模块结尾。
* 生成高度还原复古像素电脑界面、粗黑描边、平涂色彩、强对比排版的信息图。
---
## VISUAL STYLE
整体风格为：
**Retro Pixel Pop Art / Vintage Computer UI / 低保真像素弹窗拼贴风**
画面像一组老式桌面系统弹窗叠在一起，既像复古软件界面，又像波普艺术海报。
视觉关键词：
* 老式电脑弹窗
* 像素字体
* 黑白高反差
* 粗黑描边
* 平涂色块
* 复古桌面 UI
* 弹窗拼贴
* 文件窗口
* 错误提示框
* 进度条
* OK / CANCEL / PLAY 按钮
* 低像素图标