AI on All about Raspberry Pi

把组织当成产品来打造：AI 原生组织的 MVP 设计

Sun, 12 Apr 2026 00:00:00 +0000

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

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

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

从泛化到进化：AI Agent 的下一站

Sat, 11 Apr 2026 00:00:00 +0000

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

我问他打算怎么办。

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

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

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

AI 时代，人人都能建模了吗？

Fri, 10 Apr 2026 00:00:00 +0000

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

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

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

他愣了一下。

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

他沉默了。

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

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

让 AI 自己写 Skill：可进化 Agent 的设计原理与最佳实践

Fri, 10 Apr 2026 00:00:00 +0000

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

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

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

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

AI Native 流程的一头一尾：用户问题理解与自动验证

Thu, 09 Apr 2026 00:00:00 +0000

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

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

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

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

用「好同事」模型理解人与 AI 的协作

Sun, 05 Apr 2026 00:00:00 +0000

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

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

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

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

LLM 押注在 Coding Agent 上是正确的

Sat, 04 Apr 2026 00:00:00 +0000

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

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

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

Agent 是复杂个性化需求的最优解：解决用户自己都说不清的问题

Fri, 03 Apr 2026 00:00:00 +0000

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

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

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

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

AI 原生的思考方式：不能被 Token 解决的问题，才配叫问题

Tue, 31 Mar 2026 12:00:00 +0800

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

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

别再手动整理用户反馈了：把 VOC 变成一条自动化生产线

Tue, 31 Mar 2026 00:00:00 +0000

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

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

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

同一个生意做了四遍：从搜索到Agent，万物皆排序

Mon, 30 Mar 2026 00:00:00 +0000

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

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

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

Agent的架构之战：从Desktop到AI时代，架构决定平台的生死

Sun, 29 Mar 2026 00:00:00 +0000

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

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

AI的MaaS层最核心的能力：把一个不稳定的概率接口，变成一个可运营的服务

Sat, 28 Mar 2026 00:00:00 +0000

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

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

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

OpenClaw + Claude Code 协同：用 Sub-Agent 执行编程任务并实时同步进度

Sat, 28 Mar 2026 00:00:00 +0000

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

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

素质之外，语言和数学仍然是教育的基础，是驾驭AI的底层能力

Sat, 28 Mar 2026 00:00:00 +0000

AI时代的教育讨论，最常见的声音是：要培养批判性思维、创造力、跨学科能力、情商、沟通协作……这些当然重要。但一个危险的倾向正在蔓延——很多人把"素质教育"和"基础学科"对立起来了，好像强调语文数学就是应试教育的残余，而AI时代只需要"软实力"。

这是一个严重的误判。

语言能力和数学能力，不是AI时代要淘汰的旧能力，恰恰是驾驭AI最底层的两项基础能力。 没有它们，所谓的批判性思维、创造力、AI素养，全都是空中楼阁。

微软的组织变革：从成长性思维到像AI一样自我进化的组织

Fri, 27 Mar 2026 00:00:00 +0000

3月25日晚，微软首席人力官Amy Coleman在一份内部备忘录中，宣布对微软HR团队进行系统性调整。这不是一次普通的架构调整，而是AI时代组织进化的一次预演——微软正在把组织，从"管理系统"，升级为"计算系统"。

模型和Agent的边界：模型决定上限，Agent决定你能不能稳定拿到这个上限

Fri, 27 Mar 2026 00:00:00 +0000

每个Agent开发者都绕不过一个灵魂拷问：模型一直在进化，Agent的价值到底在哪？

GPT-5比GPT-4强，Claude 4比Claude 3强，Gemini 2比Gemini 1强。模型按周迭代、按月跨代，推理更深、上下文更长、幻觉更少。如果模型本身就在变强，我们在模型之上搭的这一层"Agent"——到底是在创造价值，还是在制造冗余？

这个问题不回答清楚，Agent开发就永远在焦虑中摇摆。

别再卷模型了：To B Agent 创业，用户反馈才是生死线

Mon, 23 Mar 2026 00:00:00 +0000

2026 年，一个事实已经无法忽视：模型训练不再是一项研究活动，而是一项系统工程。

预训练需要万卡集群和 PB 级数据管线，强化学习需要奖励模型和 RLHF/DPO 的工程化流水线，推理优化涉及量化、蒸馏、speculative decoding 等一整套工具链，Agent 能力构建则横跨 function calling、长上下文、规划与工具使用的多维调优。任何一个方向的突破，如果不能在其他环节配合落地，就只是一篇论文，不是一个产品。

这意味着什么？模型本身正在变成标准化基础设施。 就像今天没有哪家 SaaS 公司拿"我们用了 PostgreSQL"当竞争优势一样，未来也不会有哪家 Agent 公司仅靠"我们微调了一个更好的模型"赢得市场。

那么 To B Agent 创业的制胜变量到底是什么？

OpenClaw使用远程浏览器——让AI读懂你的个性化互联网

Sun, 22 Mar 2026 00:00:00 +0000

AI Agent 能搜索、能总结、能写代码，但有一件事它做不好：读你的互联网。你的 Twitter Timeline、你的 YouTube 推荐、你的 Hacker News 首页——这些个性化内容藏在登录态背后，普通的 API 调用拿不到。

OpenClaw 的远程浏览器方案解决了这个问题：在一台带桌面的 Ubuntu 服务器上运行真实浏览器，保存各大网站的登录信息，然后通过网络让 AI Agent 直接操控这个浏览器。AI 看到的就是你看到的。

当钉钉变成命令行：办公协同 Skill 的 Token 交付时代

Sun, 22 Mar 2026 00:00:00 +0000

软件行业有一个永恒的矛盾：标准化产品满足不了个性化需求，定制开发又贵得离谱。每家企业都想要"适合自己的办公系统"，但 SaaS 只能给你 80% 的功能，剩下 20% 要么忍着，要么花十倍的钱去定制。

钉钉的 CLI 化开放正在改变这个游戏规则。当钉钉的消息、日历、审批、文档、通讯录等能力都可以通过命令行接口被 AI Agent 直接调用时，一个新范式浮现了：过去需要写代码、做定制、走项目的办公需求，现在可以用自然语言描述，由 AI 用 Token 来交付。

人写规则，Token做实验：从Karpathy的autoresearch看AI应用优化新范式

Sat, 21 Mar 2026 00:00:00 +0000

Karpathy 在 2026 年 3 月开源了 autoresearch，两周内收获近 5 万 Star。项目本身很简单——让 AI Agent 自动修改 LLM 训练代码、跑实验、看指标、保留好的、丢弃差的，一夜循环 100 轮。但简单的背后藏着一个深刻的范式转移：在 AI 时代，人的角色从"做实验的人"变成了"设计实验规则的人"，而试错循环本身，交给 Token 去完成。

这不只是 AI 研究的事。任何可以量化评估、快速迭代的业务场景，都可以套用这个范式。

自我进化的AI助手：OpenClaw如何用Heartbeat实现Skill自动优化

Sat, 21 Mar 2026 00:00:00 +0000

在上一篇文章中，我从 Karpathy 的 autoresearch 项目提炼了一个范式：人写规则，Token 做实验。我们用 AI 客服 Prompt 优化作为案例，验证了这个范式在业务场景中的可行性。但那个方案有一个前提——你需要预先准备评估数据集。

OpenClaw 的场景让我意识到，还有一种更彻底的可能：Agent 用自己的真实执行数据作为评估信号，在用户无感知的情况下持续自我优化。 不需要人工标注测试集，不需要离线批处理，每一次真实使用都是一条训练数据。

悟空是AI时代的淘宝：Token消费的多快好省

Fri, 20 Mar 2026 00:00:00 +0000

1962年，一位伟人为中国工业发展题写了"鼓足干劲，力争上游，多快好省地建设社会主义"。六十多年后，当我们审视AI Agent工程的核心挑战时，会发现一个惊人的对称：Agent工程的终极优化目标，本质上就是对模型Token消耗的"多快好省"。

淘宝用十五年把"多快好省"刻进了中国零售的DNA——商品要多、物流要快、品质要好、价格要省。而今天的AI Agent Runtime，正在用同一套逻辑重塑Token消费——模型类型要多、响应速度要快、完成效果要好、使用成本要省。

悟空——孙悟空七十二变（多）、筋斗云十万八千里（快）、金箍棒降妖除魔（好）、一根毫毛变千猴（省）。一个优秀的Agent Runtime，就是AI时代的淘宝，Token世界的悟空。

AI时代的新代码大全：从McConnell的三大启示到Claude Skill编写指南

Wed, 18 Mar 2026 00:00:00 +0000

二十年前，Steve McConnell 的《代码大全》(Code Complete 2nd) 以其近 900 页的体量，成为软件工程领域一座难以逾越的丰碑。二十年后，它依然是无数工程师书架上的必备经典。在一场深度的访谈中，McConnell 分享了这部巨著背后的故事、对职业发展的深刻洞见，以及对 AI 时代的冷静思考。

尽管技术浪潮已更迭数代，但 McConnell 的核心思想依然闪耀着永恒的光芒。我从中提炼出三大"启示"，它们穿越了语言和工具的变迁，直指软件开发的本质。而当我读完 Anthropic 刚刚发布的 The Complete Guide to Building Skills for Claude 时，我惊讶地发现：这份 AI 时代的"新代码大全"，正是 McConnell 理念的最佳实践者。

AI Native 文档：会话即知识，过程即资产

Mon, 16 Mar 2026 00:00:00 +0000

企业每天都在产生大量知识，但绝大多数知识从未被记录下来。不是因为没有文档系统，而是因为真正的知识不在文档里，而在产生文档的过程中。

一份产品方案的最终版本只有 10 页，但写这 10 页的过程中，团队讨论了 20 个方案、否定了 15 个、在 3 个关键决策点上反复权衡。这些讨论、推理和决策——才是企业最有价值的知识。传统文档系统只保存了结论，丢掉了思考。

AI Native 文档要解决的，就是这个问题。

构建企业级Agent Runtime：从Skill到Workspace的五层架构

Mon, 16 Mar 2026 00:00:00 +0000

很多团队对 Agent 的理解还停留在"LLM + Prompt + 几个工具调用"。这种理解能跑通 Demo，但一旦进入企业级场景——多任务并行、多系统集成、多角色协作、安全审计——就会发现：Agent 系统的核心挑战不是让 LLM 更聪明，而是构建一个可扩展、可治理、可审计的运行时架构。

Agent 系统本质上在解决五个问题：用户要做什么（Agent）、谁来执行（Sub-Agent）、如何执行（Skill）、从哪里获取数据（MCP）、执行过程的状态存在哪里（Workspace）。这五个问题对应了系统的五个核心层次。

本文将这套架构完整展开。

AI Agent 架构的终局，是 Unix 哲学的回归

Sun, 15 Mar 2026 00:00:00 +0000

最近在梳理各种 AI Agent 框架和 Runtime 的架构时，我产生了一个越来越强烈的感觉：我们正在重新发明 Unix。

不是比喻。是字面意义上的重新发明。当你把今天主流的 Agent 架构摊开来看——Skill、Workspace、Tool、Pipeline、Orchestrator——你会发现，这些概念和 50 年前 Unix 的设计哲学几乎一一对应。区别只是换了一层 AI 的皮。

为 AI 重建的 IM 架构

Sun, 15 Mar 2026 00:00:00 +0000

传统 IM（即时通讯）解决的是一个简单的问题：让人和人高效地交换信息。文本、图片、文件、语音——三十年来，IM 的核心架构围绕着"谁说了什么"展开，安全靠端到端加密，权限靠静态角色控制，审计靠消息日志。这套体系服务了几十亿用户，足够成熟。

但当 AI Agent 成为 IM 中的活跃参与者——不仅接收消息，还理解意图、调用工具、执行任务、产生后果——传统 IM 的架构假设就被从根本上打破了。IM 不再只是信息传递的通道，而是 Agent 协作与执行的操作系统。

这需要一种全新的 IM 架构。

企业专属模型：让企业放心调用大模型的架构最佳实践

Sun, 15 Mar 2026 00:00:00 +0000

和企业客户聊 AI 落地，十次有九次会被问到同一个问题：“我们调用你们的大模型，数据会不会被拿去训练？”

这个问题背后的焦虑是真实的。企业的客户数据、商业机密、内部文档、代码仓库——这些是企业的核心资产。把它们发送给一个外部的大模型 API，本质上就是把家底给别人看了一遍。如果这些数据还被用来训练模型，那等于是在免费帮竞争对手提升 AI 能力。

好消息是，这个问题在 2026 年已经有了成熟的解决方案。坏消息是，大多数企业还不知道该怎么选。

企业级 Agent Runtime 的第一道防线：安全沙箱

Sun, 15 Mar 2026 00:00:00 +0000

当我们谈论企业级 AI Agent Runtime 时，第一个需要解决的问题不是"模型有多聪明"，而是"Agent 执行的代码有多安全"。一个能读写文件、执行命令、访问网络的 Agent，如果没有安全边界，就是一颗不知道什么时候会爆炸的定时炸弹。

企业级的 Agent Runtime 首先需要一个安全沙箱：文件系统隔离 + 网络访问隔离。

当 AI Agent 被拉进多个群：会话隔离与 Agent 隔离的生死线

Sun, 15 Mar 2026 00:00:00 +0000

把一个 AI Agent 拉进钉钉的多个群，是一件非常容易的事情——群管理员点一下"添加机器人"就完成了。但这也是一件极其危险的事情——如果 Agent Runtime 没有做好隔离，你可能正在制造一个企业级的安全事故。

想象这个场景：你的 AI Agent 同时服务于"核心技术架构群"和"外部合作伙伴群"。有人在合作伙伴群里问了一个问题，Agent 的回答中不小心带出了它在架构群里学到的技术方案细节。信息就这样泄露了，而且没有任何人会收到告警。

这不是假设。这是没有隔离的 Agent Runtime 的默认行为。

AI 时代的企业数字化 = 工作 Agent 化 + 知识 AI Ready 化 + 软件 CLI 化

Wed, 11 Mar 2026 00:00:00 +0000

过去两年，几乎每家企业都在谈"拥抱 AI"。但你去看看大多数企业的 AI 落地项目，会发现一个尴尬的现实：聊天机器人做了一堆，效率提升约等于零。 问题出在哪？不是 AI 不够强，而是企业的数字化基座根本不是为 AI 设计的。

我越来越确信一个判断：AI 时代的企业数字化，可以浓缩成一个公式——

企业数字化 = 工作 Agent 化 + 知识 AI Ready 化 + 软件 CLI 化

这三项缺一不可，而且顺序很重要。

Agent 执行耗时任务时如何主动汇报进度？四种方案的实战选型

Tue, 10 Mar 2026 00:00:00 +0000

你让 AI Agent 帮你跑一个需要 30 分钟的数据迁移脚本，然后就没了下文——它在干嘛？卡住了？还是已经跑完了？你不知道，因为 Agent 只会在任务彻底完成或彻底失败时才告诉你结果。

这是 Agent 系统中一个普遍的痛点：耗时任务的进度黑洞。用户发出指令后陷入等待，没有进度条，没有中间反馈，只有最终的成功或失败。在 OpenClaw 的实际使用中，我总结了四种适用于不同场景的进度上报方案，每种都有其最佳适用场景。

OpenClaw 一天发布两个版本，打破了人月神话法则吗？

Tue, 10 Mar 2026 00:00:00 +0000

OpenClaw 一天发布了两个版本。消息传开后，有人兴奋地说"AI 时代人月神话终于被打破了"，也有人冷静地问"这真的算打破了吗？"

这个问题值得认真回答。因为它触及的不是某个产品的发布节奏，而是软件工程最根本的规律之一——加人到底能不能加速交付？ 在 AI Agent 成为新型"开发者"的今天，这条规律是否需要被重新审视？

Workspace + Git + Agent：AI 时代的工作操作系统

Fri, 06 Mar 2026 00:00:00 +0000

过去一年，我越来越确信一个判断：AI 时代真正的工作操作系统，不是某个 App，不是某个平台，而是 Workspace + Git + Agent 这个三位一体的组合。

为什么？因为 AI Agent 的一切——输入、输出、系统提示词、上下文、执行过程、临时生成的代码、图片、文档，甚至应用程序本身——本质上都是文件。既然 everything is file，那么管理这些文件的方式，就决定了你驾驭 AI 的效率和上限。

Attention is All You Need：专注力才是人和大模型共同的底层算法

Thu, 05 Mar 2026 00:00:00 +0000

2017 年，Google 发表了那篇改变世界的论文——“Attention Is All You Need”。八位作者可能没想到，这篇论文不仅催生了 GPT、Claude、Gemini 等一系列大模型，也在某种意义上揭示了一个关于人类自身的深刻隐喻：不论是大模型还是人，决定产出质量的底层机制都是注意力（Attention）。

专注力是人做事质量和效率的基础。这不是心灵鸡汤，而是一个可以从技术原理出发、严肃论证的观点。

让 Agent 更准确地完成任务，关键不在模型，而在环境

Thu, 05 Mar 2026 00:00:00 +0000

做了一年多 AI Agent 开发，我逐渐形成了一个核心观点：让 Agent 更准确更高质量地完成任务，最关键的不是换一个更强的模型，而是给它一个正确的执行环境。

具体来说，这个"正确的执行环境"包含四个要素：干净的执行环境、充足且正确的上下文、允许自我探索的空间、以及学会使用工具解决问题的能力。

以前人给 AI 造工具，现在 AI 自己造工具

Wed, 04 Mar 2026 00:00:00 +0000

做 AI Agent 开发这一年多来，我经历了一个认知上的转变：以前的默认思路是"我要给 AI 准备好一切工具，让它去调用"；而现在，越来越多的场景让我意识到——AI 为了完成任务，会自己造工具。这不是一个隐喻，而是一个正在发生的技术事实。

大模型 Tool Use 准确率可达 99%，但前提是工具足够简单

Mon, 02 Mar 2026 00:00:00 +0000

最近在做 Agent 开发时，我发现一个有意思的现象：大模型调用工具的准确率其实可以非常高，达到 99% 甚至更高——但这有一个关键前提：工具本身要足够简单。这也解释了一个行业趋势：越来越多的平台服务在做 Tools 化时，选择的路径是写 CLI，而不是暴露复杂的 SDK 或 REST API。

Agent 设计最佳实践：Memory

Sat, 28 Feb 2026 00:00:00 +0000

想象这样一个场景：你花了半小时向 AI 助手解释你的项目架构、编码偏好和团队规范，得到了一次满意的协作体验。第二天再打开对话——它全忘了。你又得从头来一遍。这不是 AI 不够聪明的问题，而是记忆架构缺失的问题。OpenClaw 的 Memory 系统试图从根本上解决这个痛点：让 AI Agent 拥有持久、可检索、可自维护的记忆能力。

Agent 设计最佳实践：OpenClaw 的 Heartbeat 设计

Sat, 28 Feb 2026 00:00:00 +0000

绝大多数 AI 助手都是被动的——用户不说话，它就沉默。这在"问答"场景下没问题，但如果你想让 AI 助手真正成为助手，它需要主动意识：定期检查收件箱有没有紧急邮件、日历上有没有即将到来的会议、GitHub 上有没有需要关注的 PR。OpenClaw 的 Heartbeat（心跳）机制正是为此设计的。本文将深入解析这一设计的工程细节和最佳实践。

高质量数据越多，大模型表现越优秀

Fri, 27 Feb 2026 00:00:00 +0000

最近和几个做 AI 的朋友聊天，发现一个有趣的现象：很多人对大模型的信仰是"因为相信所以看见"——相信 AGI 会来，相信 scaling law 会继续有效，相信未来的模型会更强大。

但我的观点恰恰相反：AI 信仰应该建立在"因为看见所以相信"。而我们能看见什么？最直观的就是——高质量数据越多，大模型表现越优秀。这不是信仰，是已经被反复验证的事实。

AI时代的个人生产力公式：思考深度 × 资源调度广度

Wed, 25 Feb 2026 00:00:00 +0000

最近我一直在思考一个问题：在 AI 时代，个人生产力的本质到底是什么？经过大半年高强度使用各类 AI 工具的实践，我得出了一个公式：

个人生产力 = 思考深度 × 资源调度广度

这不是一个数学公式，而是一个思维框架。它帮我重新理解了"人应该做什么"和"AI 应该做什么"这个根本问题。

OpenClaw 架构解析：如何构建一个有记忆、有灵魂的个人 AI 助手

Wed, 25 Feb 2026 00:00:00 +0000

大多数 AI 助手是无状态的——你关掉窗口，它就忘了你是谁。OpenClaw 试图解决一个更本质的问题：能不能让 AI 助手像一个真正的助手一样，记住你、理解你、主动帮你？ 经过几周的实际使用，我想分享一下 OpenClaw 的架构设计和背后的思考。

任何省 Token 的做法都不是大模型的最佳实践

Wed, 25 Feb 2026 00:00:00 +0000

最近看到很多文章在教人如何"省 Token"——压缩 prompt、缩短上下文、用更小的模型替代、砍掉 system prompt……这些技巧看似精明，但我越来越确信一个观点：任何以省 Token 为目标的做法，都不是大模型的最佳实践。

这不是因为我不在乎成本。恰恰相反，正是因为我在乎投入产出比，所以我认为"省 Token"是一个错误的优化方向。

Manus、Lovable、Dify、Coze 的本质：为大模型开发 Skills 的工具

Sun, 22 Feb 2026 00:00:00 +0000

2025 年以来，AI 应用层出现了一波令人眼花缭乱的平台：Manus 主打通用 AI Agent，Lovable 专注 AI 驱动的应用生成，Dify 提供 LLM 应用编排框架，Coze（扣子）让用户可以可视化地构建 AI Bot。它们看起来各有侧重，产品形态也不尽相同，但如果你退后一步观察，会发现它们在做的事情本质上是一样的——为大模型开发 Skills。

Claude Code 时代的工程师新范式：几个月掌握别人十年的经验

Sat, 21 Feb 2026 00:00:00 +0000

软件工程师正在经历一场静悄悄的范式革命。过去，一个工程师要成为团队中的技术骨干，往往需要五到十年的摸爬滚打——踩过无数坑，读过海量源码，在生产环境的故障中积累经验。但现在，一个善于使用 Claude Code 的工程师，可以在几个月内走完别人多年的路。这不是夸张，而是正在发生的事实。

通过桌面录屏实现自动化 RPA 的最佳实践

Mon, 09 Feb 2026 00:00:00 +0000

传统的 RPA（Robotic Process Automation）工具通常需要手动编写脚本或使用可视化编排工具，学习成本高且维护困难。随着多模态 AI 的发展，一种新的范式正在兴起：通过录制用户的桌面操作，让 AI 自动理解并复现这些操作。这种方式大大降低了自动化的门槛，让业务人员也能快速构建自动化流程。

Clawdbot：运行在你自己设备上的个人AI助手

Tue, 27 Jan 2026 00:00:00 +0000

在AI助手日益普及的今天，我们往往需要依赖云端服务来使用这些智能工具。但如果你想要一个完全由自己控制、运行在本地的AI助手呢？今天要介绍的 Clawdbot 就是这样一个开源项目——一个真正属于你的个人AI助手。

如何对会议纪要 Agent 进行 Benchmark？完整指南与实践

Wed, 07 Jan 2026 00:00:00 +0000

在 AI Agent 应用日益普及的今天,会议纪要生成是最常见的落地场景之一。然而,如何科学地评估一个会议纪要 Agent 的性能,却是许多开发者面临的难题。本文将详细介绍如何构建一个完整的 benchmark 体系,包括评估维度设计、数据集准备、指标计算和自动化测试流程。

Agent强化学习的最佳实践：并行任务处理与性能优化

Sat, 03 Jan 2026 00:00:00 +0000

在2026年的AI应用场景中，Agent系统已经成为解决复杂任务的核心技术。无论是代码生成助手、自动化运维系统，还是智能客服机器人，如何让Agent高效地处理多个任务并从经验中学习，直接决定了系统的实用性和用户体验。本文将深入探讨Agent强化学习的工程实践，重点解决一个关键问题：如何让Agent并行处理任务以提升性能？

NotebookLM的核心能力与构建之道

Sat, 03 Jan 2026 00:00:00 +0000

当Google在2023年推出NotebookLM时，它重新定义了我们与知识交互的方式。这款AI驱动的笔记应用不仅仅是一个文档管理工具，更是一个能够理解、总结、对话和创作的智能助手。那么，NotebookLM究竟具备哪些关键能力？我们如何构建类似的系统？本文将深入剖析其核心技术架构。

智谱开源Slime：企业AI应用的强化学习利器

Sat, 03 Jan 2026 00:00:00 +0000

当企业决策者在考虑如何让AI真正产生业务价值时，一个核心挑战始终存在：如何让AI系统持续学习和优化，而不是停留在"静态模型"阶段？ 智谱AI开源的Slime框架，正是为解决这一痛点而生的强化学习后训练系统。

如果说预训练模型是AI的"基础教育"，那么强化学习就是让AI在真实业务场景中"实战成长"的关键。Slime不仅仅是又一个开源框架，它代表着企业级AI应用从"能用"到"好用"的范式转变。

Claude Code自动修正生成代码的原理解析：Agent Loop最佳实践

Wed, 24 Dec 2025 00:00:00 +0000

在AI辅助编程的时代，Claude Code等智能代码助手已经成为开发者的得力助手。但你是否好奇过：为什么Claude Code能够自动发现并修正生成代码中的错误？这背后的"Agent Loop"机制究竟是如何工作的？本文将深入剖析Claude Code的自动修正原理，并分享Agent Loop的最佳实践。

如何用 AI 将个人网站转化为专业的 Google 求职简历

Tue, 23 Dec 2025 00:00:00 +0000

在科技行业求职，特别是向 Google 这样的顶级科技公司投递简历时，如何将个人网站上丰富的项目经验、技术博客和开源贡献转化为一份专业、精准的简历是关键。传统方式需要手动整理、提炼和格式化，既费时又容易遗漏重点。本文将介绍如何利用 AI 工具，特别是大语言模型（LLM），智能地将个人网站内容转化为符合 Google 招聘标准的专业简历。

多模态AI驱动的B2B订单归一化：从非标准文档到MES系统的智能工作流

Sat, 20 Dec 2025 00:00:00 +0000

传统制造企业在数字化转型过程中，面临着一个普遍而棘手的问题：来自不同客户的订单文档格式千差万别，有PDF、Excel、Word、扫描件、甚至手写订单。这些非标准化的订单数据需要人工录入MES（制造执行系统）才能启动生产流程，不仅效率低下，而且容易出错。

随着GPT-4V、Claude 3.5 Sonnet等多模态大模型的成熟，我们终于有了一个优雅的解决方案：结合视觉识别能力、自然语言理解和代码生成能力，构建一个智能的订单归一化工作流。在这个工作流中，AI Agent承担大部分繁重工作，人类只需在关键节点进行验证和确认，实现真正的人机协作自动化。

小学标准化试卷AI批改Agent最佳工程实践

Sat, 20 Dec 2025 00:00:00 +0000

在教育科技领域,AI自动批改试卷已经从概念走向现实应用。本文通过一个小学标准化试卷高准确度批改的Agent实践案例,系统性地总结了如何将传统行业数据转化为AI-Ready格式的工程范式,为类似场景提供可复用的方法论。

构建高质量订单文档分类器：智能导流到专业Agent

Sat, 20 Dec 2025 00:00:00 +0000

在现代企业的订单处理流程中，不同类型的订单文档往往需要不同的处理逻辑和专业知识。传统的人工分类方式效率低下且容易出错，而基于规则的自动化系统又难以应对复杂多变的业务场景。本文将介绍如何利用大语言模型（LLM）构建一个高质量的订单文档分类器，实现智能路由到专业Agent的完整解决方案。

API、MCP和Skills：三个概念的本质区别