上周五晚上，我在公司用 Claude Code 调了一个小时的部署脚本，Agent 帮我定位了问题、改了三个文件、跑通了测试。周六早上我打开家里的笔记本，想继续收尾——打开终端，Claude Code 启动，干干净净，什么都不记得。
我得重新描述问题、重新贴日志、重新解释上下文。那种感觉，就像你跟一个同事讨论了一下午方案，第二天他失忆了。
这不是某个工具的 bug。这是当前所有 AI Agent 的共同困境：Agent 的记忆被钉死在了设备上。
[Read More]把组织当成产品来打造：AI 原生组织的 MVP 设计
组织不是「管」出来的，是「设计」出来的——以钉钉团队为例，拆解组织 MVP 的第一个可用版本
去年底，钉钉内部发生了一件事。一个做智能客服的产品经理发现，他给企业客户做的 AI 解决方案，从需求确认到方案交付平均要 14 天。他拉了一下链路：客户提需求给销售（1 天）→ 销售转给解决方案团队（等 2 天）→ 解决方案写 PRD 转给产品（等 1 天）→ 产品评审排期（等 3 天）→ 技术实现（5 天）→ 交付验收（2 天）。14 天里，真正在"干活"的时间不到 5 天，剩下 9 天全是等待——等人、等审批、等排期、等信息同步。
他跑去找他的主管说：“我们给客户做 AI 提效工具，但我们自己的组织效率，比客户还低。”
这句话刺痛了人。但更刺痛的是——这不是钉钉一家的问题，这是几乎所有想做 AI 转型的公司都会撞上的墙。不是不知道终局应该长什么样，而是不知道第一个可用版本怎么做——像做产品一样，先跑起来，再迭代。
[Read More]从泛化到进化：AI Agent 的下一站
泛化是空间维度的适应能力，进化是时间维度的适应能力
前几天跟一个做 Agent 平台的朋友聊天，他说了一句让我印象很深的话：“我们花了半年调 prompt，好不容易让 Agent 在电商客服场景跑到了 90 分。结果客户说要扩到金融场景，我们一测——40 分都不到。”
我问他打算怎么办。
他苦笑：“重新调呗。再花半年。”
这个对话浓缩了当前 AI Agent 面临的最核心矛盾：我们造出了能力惊人但本质上是"静态"的系统。它在训练过的分布上表现惊艳，换个分布就翻车；它部署的那一刻就被冻结，遇到新场景只能等人类手动干预、重新训练。
这让我开始思考两个看似不同、实则紧密相连的问题：泛化（Generalization） 和 进化（Evolution）。
[Read More]AI 时代，人人都能建模了吗？
工具民主化了，但建模思维没有
上周有个做运营的朋友拿着一个 AI 帮他建的销量预测模型来找我，特别兴奋：“你看，R² = 0.89，是不是挺准的？”
我看了一眼，模型确实跑得不错。历史数据拟合得很好，特征工程也挺合理——用了过去 30 天的销量趋势、星期几、是否节假日。
我问他：“下周要下一整周的雨，你的模型知道吗？”
他愣了一下。
我又问：“竞品下周搞 618 预热大促，你的模型考虑了吗？你们市场部刚换了投放渠道，从抖音换到了小红书，这个变量在哪？”
他沉默了。
模型没有错。R² = 0.89 是真的。但这个模型不知道自己不知道什么。更要命的是，用这个模型的人也不知道。
这就是我今天想聊的事：AI 让建模的门槛低了，但这不等于人人都能建好模。
[Read More]让 AI 自己写 Skill：可进化 Agent 的设计原理与最佳实践
Why procedural memory beats static prompts, and how to build skills that improve over time.
今天下午我做了一件听起来有点奇怪的事——让 AI 读完了我自己的 174 篇博客，提炼出写作风格，写成了一份可执行的配置文件，然后告诉它：“以后每次写文章就按这个标准来，写完还要自己更新它。”
它真的照做了。不仅生成了一份包含六大风格特征、两种文章模板、四个薄弱环节和改进路线图的 Skill 文档，还自动附加了一条"进化协议"——每次使用完毕后检查是否需要更新。
这不是 prompt engineering，也不是 RAG。这是给 Agent 建程序性记忆（Procedural Memory）。
很多人给 AI 配了知识库、写了几百行 system prompt，但用起来总觉得"不长进"。问题不在于模型，而在于记忆的结构。静态 prompt 是一次性指令，而可进化的 Skill 是活的——它会随着使用自动迭代、越用越准、越用越像你自己。
[Read More]AI Native 流程的一头一尾：用户问题理解与自动验证
VOC 自动解决流程中，最难也最关键的两个环节
之前写过一篇用 AI 把 VOC 变成自动化流水线，讲的是整条流水线的架构——采集、分析、路由、执行。反馈不错，但也有读者指出一个关键问题：中间的部分（分类、路由）其实相对好做，真正难的是一头一尾。
“头"是用户问题理解——用户说"页面打不开”，你能不能自动搞清楚是哪个页面、什么场景、能不能复现、根因是什么？
“尾"是自动验证——修完 bug 之后，你能不能自动生成测试用例来证明"确实修好了，而且没有搞坏别的东西”？
这两个环节恰好是 AI Native 流程区别于传统自动化的核心：传统自动化靠规则，处理的是确定性问题；AI Native 靠理解和推理，处理的是模糊性问题。这篇文章就把这一头一尾拆开讲透。
[Read More]用「好同事」模型理解人与 AI 的协作
AI 落地的真正瓶颈不是技术，是你会不会派活
想象你团队来了个新同事——聪明、勤快、知识面广，但对你们的业务一无所知。第一天上午你走过去说：“帮我整理一下那个项目的材料。” 没说哪个项目，没说给谁看，没说什么格式，没说什么时候要。
他大概率会交出一份正确但平庸的文档。你看了一眼：“这也太模板了。”
这不是他能力不行，是你没把活派清楚。
现在把"新同事"换成 AI。同样的场景，同样的结果。但大多数人的反应不是"我没说清楚"，而是"AI 不够聪明"。事实上，AI 落地的真正瓶颈不是模型能力，是任务委托能力——一项被严重低估的管理技能。
[Read More]LLM 押注在 Coding Agent 上是正确的
当每个人都能写代码，IT 系统的瓶颈不再是技术，而是想象力
三个月前，我用 Claude Code 花了一个下午搭了一套完整的钉钉消息监控系统：自动抓取指定群的消息、按关键词分类、生成每日摘要、定时推送到我的私聊。整套流程从数据采集到定时任务，大约 500 行 TypeScript。
同样的事情，如果走公司正规 IT 流程——提需求、排期、开发、测试、上线——保守估计三个月，还不一定能排上。
这件事让我确信一个判断：LLM 厂商把重注押在 Coding Agent 上，是目前最正确的战略选择。 不是因为 Coding Agent 能替代程序员，而是因为它把"用代码解决问题"这件事的门槛，从"需要一个工程团队"降到了"需要一个能清楚描述问题的人"。
[Read More]Agent 是复杂个性化需求的最优解：解决用户自己都说不清的问题
为什么传统软件解决不了的需求，Agent 能解决？因为它不需要你先想清楚
上周帮一个客户上线了一个"智能周报助手"。需求方的原话是：“帮我们的销售团队自动生成周报。”
听起来很简单。但往下聊五分钟，你会发现这句话背后藏着至少二十个未定义的决策：周报包含哪些维度？数据从哪来？不同区域的销售负责人关注点一样吗？“好的周报"到底长什么样？客户自己也说不清。
最终的解决方案不是一个固定模板的报表工具，而是一个 Agent——它能根据每个销售负责人的历史偏好、当周数据特征、团队上下文，动态决定周报的结构、重点和措辞。
这件事让我重新思考一个问题：Agent 的核心价值到底是什么？ 不是"自动化”，不是"降本"，而是——它是目前唯一能规模化解决"复杂个性化需求"的技术方案。
[Read More]当 10 万个定时任务同时敲门：MaaS 平台调度优化实战
从整点风暴到分布式调度——平台视角的六个关键策略
上周五下午 3 点，告警群炸了：MaaS 层的 GPU 推理集群 QPS 在 60 秒内从 1200 飙到 18000，p99 延迟从 800ms 打到 45 秒，大量请求 429。
排查发现原因很"朴素"——大约 3 万个 OpenClaw 实例的定时任务都跑在整点。每个实例可能只有 1-3 个 cron job（数据摘要、定时巡检、报表生成），但所有人的 cron 都写着 0 * * * * 或 0 0 * * *。三万乘以三，就是整点瞬间涌来的近十万个 LLM 推理请求。
这不是应用层的 bug，而是平台设计的缺陷。当你的平台承载成千上万个租户的定时任务时，“整点风暴"不是意外——它是必然。问题是：作为平台设计者，你该怎么办？
[Read More]