上个月，一位做连锁门店的朋友给我看他的钉钉后台。
他管 7 家门店、几十号员工。没有 IT 部门，没有开发团队，不会写一行代码。
但他给我看的东西让我愣住了：门店排班系统、每日任务打卡、AI 照片核查、经营日报自动生成、工资预审流程、设备报修闭环——全部跑在钉钉上，全部是他和 AI 一起搭出来的。
我问他：「你什么时候学会写代码的？」
他说：「我不会写代码。我只是告诉 AI 我想怎么管门店，它帮我搭出来的。」
然后他说了一句让我想了很久的话：
「以前很多事情不是不会，是没有时间做。现在想到一个新的管理流程，先让 AI 帮我搭出来，再不断调整。试错成本下降了很多。」
这不是「自动化」。自动化是把已有的流程跑快。他做的是 把以前根本不存在的流程变成现实。
聊天机器人的天花板
过去一年，我见过太多企业 AI 项目。模式几乎一样：
- 接一个大模型
- 做一个聊天窗口
- 员工问问题，AI 回答
- 上线两周，没人用了
为什么？因为 AI 不知道你的组织。
它不知道谁是店长、今天谁值班、哪家门店三天没完成任务、这张照片是不是上周的旧图。它能给你很好的建议，但执行还是要你自己去打开后台、查信息、复制数据，再回来继续聊天。
整个过程始终是断开的。
我在 钉钉开放平台的第一用户不再是开发者，而是开发者的 Agent 里讨论过，Agent 需要的不是更好的模型，而是 能调用组织能力的接口。但「接口」这个词还是太轻了。
真正需要的，是一个 组织的控制面。
控制面，不是管道
网络架构里有一个经典分层：Control Plane（控制面）和 Data Plane（数据面）。控制面不传数据包，控制面定义路由规则——数据往哪走、谁能走、走到哪一跳要检查。
组织管理也是这个结构：
| 控制面 | 数据面 |
|---|---|
| 建门店、录员工、设角色 | 员工打卡、上传照片 |
| 配排班规则 | AI 按排班生成待办 |
| 设审核边界 | AI 自动核查，异常交人确认 |
| 定义任务标准和证据要求 | AI 按规则抽查 |
| 沉淀 SOP | AI 按 SOP 执行 |
控制面不干活。控制面定义「怎么干、谁能干、干到什么标准」。
我那位朋友通过钉钉工作台 CLI（DWS）做的每一件事，都是控制面行为：建组织架构、配考勤规则、设审批流、定义任务模板、搭数据看板。AI 和员工在这些规则下跑。
而且注意一个关键细节：他的流程里， 不是所有环节都交给 AI。工资预审搭好了，但「最终发薪仍由人工确认」。AI 照片核查跑起来了，但「异常项再交人工复查」。
这不是「自动化」。这是 协同控制——AI 做第一轮筛查，人做最终判断。控制面定义的不是「AI 自己干」，而是「哪些 AI 干、哪些必须人点头」。
一个真实案例：每日任务打卡是怎么改出来的
这是他用 DWS 搭的第一个功能，也是让我最直观理解「控制面」价值的案例。
以前：群消息模式
每天在门店群里发一份值班任务清单。员工完成后拍照发群。
听起来也能用。但门店一多，问题就来了：
- 群消息被刷掉，今天有没有做过几天查不到
- 照片散落在聊天记录里，统计靠人肉翻
- 照片真假没人核验，旧图重复图发现不了
- 总部不知道哪些门店长期没执行
本质问题： 工作发生在聊天里，聊天不是工作运行时。
现在：结构化运行时
AI 通过 DWS 读取门店排班，按门店、营业日、班次和任务规则，为当班员工生成待办清单。每条待办有：
- 负责人（从排班自动关联）
- 截止时间
- 任务要求
- 证据要求（必须上传现场照片，没图不算完成）
员工的操作极简：打开待办 → 完成工作 → 拍照上传 → 确认。
每条任务在数据表里留下完整记录：门店、营业日、班次、负责人、任务编号、完成状态、证据索引、AI 检查结果、人工复核结果。
然后 AI 开始参与抽查：
- 照片数量是否达标
- 是否覆盖要求的区域
- 拍摄时间是否与任务时间一致
- 是否疑似旧图或重复上传
AI 负责第一轮筛查，异常项交管理人员人工复核。
总部每天真正需要看的内容变得非常少。
关键转变
| 以前 | 现在 |
|---|---|
| 群里发通知 | 自动生成待办 |
| 群里上传照片 | 数据表统一收集 |
| 店长自己检查 | AI 先筛查，人再确认 |
| 翻聊天记录 | 查询即得结果 |
| 靠经验管理 | 数据持续沉淀 |
群从「工作场所」降级为「公告栏」——只发规则和操作指南。实际的工作流跑在结构化的待办和数据表上。
工作不是发生在聊天里，是发生在组织的结构化流程里。聊天是窗口，控制面是操作系统。
四层价值：从可读到可建设
回顾这位朋友搭的所有功能——组织架构、排班考勤、任务打卡、知识库、经营日报、工资预审、设备报修——我发现它们恰好构成四层递进：
① 可读（Readable）
AI 能读取组织的真实状态
「它知道谁是店长、今天谁值班、哪些审批已完成」
↓
② 可控（Controllable）
AI 在明确边界内行动，关键节点人确认
「没有有效图片不算完成」「异常项交人工复查」
↓
③ 可积累（Accumulable）
经验沉淀为数据、SOP、模板，不随人走
「所有数据天然留痕，月报季度分析直接使用」
↓
④ 可建设（Buildable）
想到新流程 → AI 搭建 → 调整 → 跑起来
「试错成本下降了很多」
前三层是基础设施。第四层是涌现结果。
因为组织可读了（AI 能看懂），可控了（AI 知道边界），可积累了（经验不丢失），所以 组织变得可以被 AI 持续建设。老板不需要等 IT 排期、不需要买新软件、不需要学新系统——想到一个管理流程，告诉 AI，AI 搭出来。
这才是他最后那句话的真正含义：
「管理一个组织的软件，开始可以由 AI 和人一起持续建设。」
所以如果要用一句话定义 DWS 是什么：
DWS 是老板经营数字员工团队的操作台，是组织的协同控制面，是员工和 AI 的组织工作运行时。它让组织对 AI 变得可读、可控、可积累、可重放。
前三个分句是角色定位——给谁用、管什么、跑什么。最后一句是价值主张——为什么需要它。
这不是 RPA，也不是低代码
写到这里，可能有人会问：这不就是 RPA 或者低代码平台换了个名字吗？
不是。区别在三个地方：
RPA 自动化已有流程。 它把人在电脑上的点击操作录下来重放。前提是流程已经存在、已经稳定。而这位朋友做的事情是 创造以前不存在的流程——以前不是不想管，是没有时间搭。RPA 解决不了「从 0 到 1」。
低代码需要人搭。 低代码平台降低了编程门槛，但你还是得自己拖组件、配逻辑、调参数。这位朋友不会写代码，也不想学拖拽。他的交互方式是 自然语言：「我想这样管理门店。」AI 负责理解意图、调用 DWS、搭建流程、配置规则。
最关键的区别：组织状态对 AI 可读。 RPA 操作的是 UI 元素（按钮、输入框），低代码操作的是组件和 API。DWS 让 AI 操作的是 组织本身——人员、门店、排班、审批、待办、数据表。AI 不是在模拟人的点击，是在 直接读写组织的状态。
这就是为什么他说：
「AI 不再只是聊天，而是真正能够参与组织运行。」
对产品设计者的启示
我在 两个数字员工，一个组织 里实践过数字员工的开发和部署。但那位朋友的使用方式给了我一个更大的启示：
企业 AI 产品的第一优先级，不是做更聪明的聊天窗口，而是建设组织的控制面。
具体来说：
1. 让组织对 AI 可读。 人员、部门、排班、审批、待办、数据——这些组织状态必须有结构化的、AI 可消费的接口。不是给人看的 Web 后台，是给 AI 读的 API。
2. 让控制面有边界。 AI 能做什么、不能做什么、哪些必须人确认——这些规则要显式定义，不能靠 prompt 里写一句「请不要做危险操作」。在 数字分身和数字员工的分界线 里我讨论过，数字员工需要组织身份、岗位职责、权限边界和审计 trail。控制面就是这些要素的运行时载体。
3. 让经验可积累。 每一次配置、每一个流程、每一条规则，都应该沉淀为可复用的模板。一家门店跑通的排班 + 打卡 + 核查流程，应该能原样复制到第 2 家、第 50 家。配置即模板，模板即 Skill。
4. 让 AI 能搭建，人负责判断。 这是最核心的分工。AI 负责设计流程、完成配置、建立审批、创建待办、搭数据表、配消息通知、把整个系统跑起来。人负责一件事： 判断这样管对不对。
回到那句话
我那位朋友最后说了一句总结：
「DWS 不是让 AI 学会聊天，而是让 AI 学会工作。」
我想把这句话再推一步：
让组织可编程。
「可编程」三个字包含了所有：可读是程序能读取状态，可控是程序在权限内执行，可积累是程序产生持久化数据，可建设是程序可以被持续迭代。
老板是程序员——只不过他写的不是代码，是管理逻辑。AI 是编译器加运行时。控制面是标准库。
过去几年，大家一直在讨论 AI 会不会替代工作。而他的感受是： AI 更像是给每一个管理者增加了一支新的团队。 以前很多事情不是不会，是没有时间做。现在，那些只能停留在想法里的流程，终于有机会真正落地。
他没有改变门店经营本身。真正改变的是：
管理一个组织的软件，开始可以由 AI 和人一起持续建设。
你在实际工作中，有没有类似的体验——不是 AI 帮你回答了一个问题，而是 AI 帮你搭起了一套以前根本没精力搭的管理体系？欢迎留言讨论。