上个月，一位做连锁门店的朋友给我看他的钉钉后台。
他管 7 家门店、几十号员工。没有 IT 部门，没有开发团队，不会写一行代码。
但他给我看的东西让我愣住了：门店排班系统、每日任务打卡、AI 照片核查、经营日报自动生成、工资预审流程、设备报修闭环——全部跑在钉钉上，全部是他和 AI 一起搭出来的。
我问他：「你什么时候学会写代码的？」
他说：「我不会写代码。我只是告诉 AI 我想怎么管门店，它帮我搭出来的。」
然后他说了一句让我想了很久的话：
「以前很多事情不是不会，是没有时间做。现在想到一个新的管理流程，先让 AI 帮我搭出来，再不断调整。试错成本下降了很多。」
这不是「自动化」。自动化是把已有的流程跑快。他做的是 把以前根本不存在的流程变成现实。
上周我让一个 Coding Agent 帮我用飞书发一条群消息。
它读完了 lark-cli im --help，看到了 messages 子命令，继续往下翻——发现 messages 下面只有 delete、forward、urgent_app 这些操作。 没有 send。
Agent 懵了。发消息这么基础的操作，怎么可能没有？
它又去翻了 raw API 路径 lark-cli api POST /open-apis/im/v1/messages，拼了一大坨 JSON body，调通了。但这条路绕过了 CLI 的所有设计——参数校验、身份管理、错误处理——全部自己来。
后来我告诉它：你应该用 lark-cli im +send。这个 +send 是一个 shortcut——飞书 CLI 为高频操作预置的语义快捷方式，比 raw API 路径短得多，也比它好用得多。
Agent 不知道有这回事，因为 --help 的输出里没有明显标记 shortcut 的存在。
同样的事情也发生在钉钉上。我让另一个 Agent 用 DWS 给同事发一条消息，它调了 dws chat message send，参数都对了，返回结果是：
{"success": true, "result": {"openTaskId": "..."}}
Agent 认为发送成功了，继续下一步。但十分钟后我打开钉钉——消息根本没到。
Agent 不知道发生了什么。success: true 告诉它「成功了」，但现实是消息石沉大海。后来排查发现是 PAT 权限不够——API 返回了「成功」，但实际投递被权限系统拦截了。
对人类来说，打开手机看一眼就知道没收到。但对 Agent 来说，success: true 就是真理——它没有能力验证现实，只能信任返回值。
这就是「API 友好」和「模型友好」之间的鸿沟。
昨晚我用 OpenCode 在钉钉上写一个会议通知 Agent。需求很简单：查日历找到明天的会议，给参会人发一条钉钉消息。
OpenCode 读完了 DWS CLI 的 help 文档，开始生成调用代码。它要发消息，看到了三个命令：dws chat message send、dws chat message send-by-bot、dws chat message send-by-webhook。它选了 send，传了 --group 和 --text，没传 --title。
返回了一个错误：「发群服务窗会话消息失败」。
OpenCode 懵了。我也懵了。什么「服务窗」？我在发群消息，跟服务窗有什么关系？
后来我翻了 dws chat message send --help，在最底下发现了一行小字：
--title是消息标题，群聊与单聊都必填（API 强制要求；缺失时返回误导性的「发群服务窗会话消息失败」）。
平台团队知道这个错误信息是误导性的，他们选择在 help 文档里标注「误导性」，而不是修复 API 的返回。
但这还没完。OpenCode 继续工作，又遇到了第二个问题：send 命令有三个互斥的目标参数——--group（群聊）、--user（userId）、--open-dingtalk-id（openDingTalkId）。help 文档说「三者只能选其一」，但没有解释什么时候该用哪个。userId 和 openDingTalkId 的区别是什么？Agent 无从推理——它只能猜，猜错了再换。
这整个过程花了十几分钟。但这十几分钟本来不应该存在。
这不是假设场景，这是 DWS 今天的真实状态。
