Hugo Zhu's Blog

上周我让 AI Agent 帮我写博客。它干得不错——风格、结构、代码规范都对。因为我之前花了一个下午，让它读完我的 174 篇旧文，把写作风格提炼成了一份可执行的 Skill 文件。

第二天我让它再写一篇，它又对了。第三天，还是对的。到第四天，我发现了一件有意思的事：它自己改了 Skill 文件。它在"反模式"列表里新增了一条——“不要用’随着 AI 的发展’开头”——这是前几次我手动纠正过的，但我从来没有明确要求它把这个规则写进去。

那一刻我意识到，这个 Agent 已经不是在"执行指令"了。它在积累经验。

但紧接着我遇到了下一个问题：它记住了"怎么写文章"，却不记得"上次写了什么"。我让它写一篇关于 Agent 进化的文章，它洋洋洒洒写了 800 行——和三天前那篇重复了 60%。技能在进化，记忆在归零，知识没有沉淀。三条腿，只长了一条。

这个经历让我重新审视了一个问题：我们到底需要怎样的知识架构，才能让 Agent 真正"越用越强"？不是靠更大的上下文窗口，不是靠更贵的模型，而是一套程序化的记忆、知识与技能管理系统。

Karpathy 和社区最近的两个项目——让 Agent 一晚自主迭代 100 次实验的 autoresearch，和把任意文件夹变成可查询知识图谱的 graphify（25k+ stars）——也在指向同一个方向。

上周五晚上，我在公司用 Claude Code 调了一个小时的部署脚本，Agent 帮我定位了问题、改了三个文件、跑通了测试。周六早上我打开家里的笔记本，想继续收尾——打开终端，Claude Code 启动，干干净净，什么都不记得。

我得重新描述问题、重新贴日志、重新解释上下文。那种感觉，就像你跟一个同事讨论了一下午方案，第二天他失忆了。

这不是某个工具的 bug。这是当前所有 AI Agent 的共同困境：Agent 的记忆被钉死在了设备上。

去年底，钉钉内部发生了一件事。一个做智能客服的产品经理发现，他给企业客户做的 AI 解决方案，从需求确认到方案交付平均要 14 天。他拉了一下链路：客户提需求给销售（1 天）→ 销售转给解决方案团队（等 2 天）→ 解决方案写 PRD 转给产品（等 1 天）→ 产品评审排期（等 3 天）→ 技术实现（5 天）→ 交付验收（2 天）。14 天里，真正在"干活"的时间不到 5 天，剩下 9 天全是等待——等人、等审批、等排期、等信息同步。

他跑去找他的主管说：“我们给客户做 AI 提效工具，但我们自己的组织效率，比客户还低。”

这句话刺痛了人。但更刺痛的是——这不是钉钉一家的问题，这是几乎所有想做 AI 转型的公司都会撞上的墙。不是不知道终局应该长什么样，而是不知道第一个可用版本怎么做——像做产品一样，先跑起来，再迭代。

前几天跟一个做 Agent 平台的朋友聊天，他说了一句让我印象很深的话：“我们花了半年调 prompt，好不容易让 Agent 在电商客服场景跑到了 90 分。结果客户说要扩到金融场景，我们一测——40 分都不到。”

我问他打算怎么办。

他苦笑：“重新调呗。再花半年。”

这个对话浓缩了当前 AI Agent 面临的最核心矛盾：我们造出了能力惊人但本质上是"静态"的系统。它在训练过的分布上表现惊艳，换个分布就翻车；它部署的那一刻就被冻结，遇到新场景只能等人类手动干预、重新训练。

这让我开始思考两个看似不同、实则紧密相连的问题：泛化（Generalization） 和 进化（Evolution）。

上周有个做运营的朋友拿着一个 AI 帮他建的销量预测模型来找我，特别兴奋：“你看，R² = 0.89，是不是挺准的？”

我看了一眼，模型确实跑得不错。历史数据拟合得很好，特征工程也挺合理——用了过去 30 天的销量趋势、星期几、是否节假日。

我问他：“下周要下一整周的雨，你的模型知道吗？”

他愣了一下。

我又问：“竞品下周搞 618 预热大促，你的模型考虑了吗？你们市场部刚换了投放渠道，从抖音换到了小红书，这个变量在哪？”

他沉默了。

模型没有错。R² = 0.89 是真的。但这个模型不知道自己不知道什么。更要命的是，用这个模型的人也不知道。

这就是我今天想聊的事：AI 让建模的门槛低了，但这不等于人人都能建好模。

今天下午我做了一件听起来有点奇怪的事——让 AI 读完了我自己的 174 篇博客，提炼出写作风格，写成了一份可执行的配置文件，然后告诉它：“以后每次写文章就按这个标准来，写完还要自己更新它。”

它真的照做了。不仅生成了一份包含六大风格特征、两种文章模板、四个薄弱环节和改进路线图的 Skill 文档，还自动附加了一条"进化协议"——每次使用完毕后检查是否需要更新。

这不是 prompt engineering，也不是 RAG。这是给 Agent 建程序性记忆（Procedural Memory）。

很多人给 AI 配了知识库、写了几百行 system prompt，但用起来总觉得"不长进"。问题不在于模型，而在于记忆的结构。静态 prompt 是一次性指令，而可进化的 Skill 是活的——它会随着使用自动迭代、越用越准、越用越像你自己。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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