AI

之前写过一篇用 AI 把 VOC 变成自动化流水线，讲的是整条流水线的架构——采集、分析、路由、执行。反馈不错，但也有读者指出一个关键问题：中间的部分（分类、路由）其实相对好做，真正难的是一头一尾。

“头"是用户问题理解——用户说"页面打不开”，你能不能自动搞清楚是哪个页面、什么场景、能不能复现、根因是什么？

“尾"是自动验证——修完 bug 之后，你能不能自动生成测试用例来证明"确实修好了，而且没有搞坏别的东西”？

这两个环节恰好是 AI Native 流程区别于传统自动化的核心：传统自动化靠规则，处理的是确定性问题；AI Native 靠理解和推理，处理的是模糊性问题。这篇文章就把这一头一尾拆开讲透。

想象你团队来了个新同事——聪明、勤快、知识面广，但对你们的业务一无所知。第一天上午你走过去说：“帮我整理一下那个项目的材料。” 没说哪个项目，没说给谁看，没说什么格式，没说什么时候要。

他大概率会交出一份正确但平庸的文档。你看了一眼：“这也太模板了。”

这不是他能力不行，是你没把活派清楚。

现在把"新同事"换成 AI。同样的场景，同样的结果。但大多数人的反应不是"我没说清楚"，而是"AI 不够聪明"。事实上，AI 落地的真正瓶颈不是模型能力，是任务委托能力——一项被严重低估的管理技能。

三个月前，我用 Claude Code 花了一个下午搭了一套完整的钉钉消息监控系统：自动抓取指定群的消息、按关键词分类、生成每日摘要、定时推送到我的私聊。整套流程从数据采集到定时任务，大约 500 行 TypeScript。

同样的事情，如果走公司正规 IT 流程——提需求、排期、开发、测试、上线——保守估计三个月，还不一定能排上。

这件事让我确信一个判断：LLM 厂商把重注押在 Coding Agent 上，是目前最正确的战略选择。 不是因为 Coding Agent 能替代程序员，而是因为它把"用代码解决问题"这件事的门槛，从"需要一个工程团队"降到了"需要一个能清楚描述问题的人"。

上周帮一个客户上线了一个"智能周报助手"。需求方的原话是：“帮我们的销售团队自动生成周报。”

听起来很简单。但往下聊五分钟，你会发现这句话背后藏着至少二十个未定义的决策：周报包含哪些维度？数据从哪来？不同区域的销售负责人关注点一样吗？“好的周报"到底长什么样？客户自己也说不清。

最终的解决方案不是一个固定模板的报表工具，而是一个 Agent——它能根据每个销售负责人的历史偏好、当周数据特征、团队上下文，动态决定周报的结构、重点和措辞。

这件事让我重新思考一个问题：Agent 的核心价值到底是什么？ 不是"自动化”，不是"降本"，而是——它是目前唯一能规模化解决"复杂个性化需求"的技术方案。

上周，一个做 ToB SaaS 的朋友跟我吐槽：他花了两周让 AI 帮忙写了一套完整的 CRM 后端，代码质量不错，测试覆盖率也够。但上线三天就被叫停了——因为产品方向本身就是错的，客户根本不需要这个功能。

两周的 Token 消耗，毁于一个没被认真思考过的问题。

每家公司都说"以用户为中心"，但 90% 的用户声音（Voice of Customer, VOC）最终的归宿是——躺在某个 Excel 表里，等着某个产品经理"有空的时候"去翻一翻。

问题不是团队不重视用户反馈。问题是：从原始反馈到可执行的产品动作之间，隔着太多手工活。 收集、清洗、分类、归因、优先级排序、写进 Backlog——每一步都在消耗人的精力，而人的精力是有限的。

这篇文章是一个完整的教程：如何用 AI + 自动化工具，把 VOC 变成一条可执行的生产线——从原始数据采集，到最终输出结构化的产品需求，全程自动。

如果你在过去二十年里分别做过搜索引擎、广告系统、推荐系统，再到今天做AI Agent，你可能会有一个越来越强烈的感觉：这不就是同一个生意吗？

表面上看，Google做搜索、Meta做广告、抖音做推荐、OpenAI做Agent，四个完全不同的产品形态，四个不同的技术栈，甚至四个不同的行业叙事。但如果你把外壳剥掉，盯着底层看，会发现一个令人不安的事实：这四代系统的核心逻辑，从来没有变过。

它们都在做同一件事——在信息过载的世界里，帮用户匹配到最相关的东西，然后从匹配效率的提升中抽税。

每一代平台级产品的竞争，最终都不是功能之争，而是架构之争。Windows赢了OS/2，不是因为功能更多，而是因为它的架构让第三方开发者能更容易地构建应用。iOS赢了Symbian，不是因为初期功能更强，而是因为它的架构从第一天就为触控交互和应用生态设计。Chrome赢了IE，不是因为它一开始更快，而是因为多进程架构让它在页面崩溃时不会拖垮整个浏览器。

现在，AI Agent正在成为从Desktop、Web、Mobile之后的第四代平台级产品。而历史正在重演：决定谁能赢的，不是谁的模型更强、谁的功能更多，而是谁的架构更对。

很多人对MaaS（Model as a Service）的理解停留在"套一层API"——把OpenAI的接口包一下，加个Key管理，做个用量统计，就叫MaaS了。如果这就是MaaS的全部，那它确实没什么技术含量，随便一个API Gateway就能干。

但现实是：几乎所有在生产环境跑AI应用的团队，最终都会自建或依赖一个MaaS层。 不是因为他们闲，而是因为裸调模型API在生产环境里根本撑不住。

MaaS层真正要解决的问题是：把一个概率性的、无状态的、昂贵的模型API调用，变成一个可靠的、可观测的、成本可控的服务。

你在钉钉里对 AI 助手说：“帮我写一个博客文章”，然后 Agent 回复"好的"——接下来呢？你等了 3 分钟、5 分钟、10 分钟，不知道它在干什么、进展到哪了、是不是卡住了。这是所有 Agent 系统面临的共同问题：编程类耗时任务的进度黑洞。

OpenClaw 通过 Sub-Agent 机制调用 Claude Code 执行编程任务，再借助 stream-json 输出格式和一个轻量级的监控脚本，将任务进度实时同步到钉钉。本文完整拆解这套方案的架构设计和实现细节。