<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Enterprise on All about Raspberry Pi</title><link>https://hugozhu.site/tags/enterprise/</link><description>Recent content in Enterprise on All about Raspberry Pi</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 31 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://hugozhu.site/tags/enterprise/index.xml" rel="self" type="application/rss+xml"/><item><title>别再手动整理用户反馈了：把 VOC 变成一条自动化生产线</title><link>https://hugozhu.site/post/2026/164-voc-to-automated-pipeline/</link><pubDate>Tue, 31 Mar 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/164-voc-to-automated-pipeline/</guid><description>&lt;p&gt;每家公司都说&amp;quot;以用户为中心&amp;quot;，但 90% 的用户声音（Voice of Customer, VOC）最终的归宿是——躺在某个 Excel 表里，等着某个产品经理&amp;quot;有空的时候&amp;quot;去翻一翻。&lt;/p&gt;
&lt;p&gt;问题不是团队不重视用户反馈。问题是：&lt;strong&gt;从原始反馈到可执行的产品动作之间，隔着太多手工活。&lt;/strong&gt; 收集、清洗、分类、归因、优先级排序、写进 Backlog——每一步都在消耗人的精力，而人的精力是有限的。&lt;/p&gt;
&lt;p&gt;这篇文章是一个完整的教程：&lt;strong&gt;如何用 AI + 自动化工具，把 VOC 变成一条可执行的生产线&lt;/strong&gt;——从原始数据采集，到最终输出结构化的产品需求，全程自动。&lt;/p&gt;</description></item><item><title>别用同一把尺子量所有 Agent：按行业和岗位设计评测体系才是正经事</title><link>https://hugozhu.site/post/2026/165-agent-eval-by-industry-and-role/</link><pubDate>Tue, 31 Mar 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/165-agent-eval-by-industry-and-role/</guid><description>&lt;p&gt;上个月参加一个 Agent 产品的内部评审，产品经理拿出一张 benchmark 表格：准确率 92%、响应时间 1.2 秒、幻觉率 3%。数字很漂亮，领导很满意。&lt;/p&gt;
&lt;p&gt;然后我问了一个问题：&lt;strong&gt;&amp;ldquo;这个 92% 的准确率，是在什么任务上测的？&amp;rdquo;&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;回答是一组通用 QA 数据集。&lt;/p&gt;
&lt;p&gt;我又问：&lt;strong&gt;&amp;ldquo;你的目标用户是电商运营，你有没有用电商运营真实工作场景的任务来测？&amp;rdquo;&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;会议室安静了五秒钟。&lt;/p&gt;
&lt;p&gt;这就是今天 Agent 评测的核心矛盾：&lt;strong&gt;我们在用&amp;quot;通用考试&amp;quot;的成绩来预测&amp;quot;专业岗位&amp;quot;的表现。&lt;/strong&gt; 这就像用高考数学成绩来判断一个人能不能当好外科医生——逻辑上不成立，但大家都在这么干。&lt;/p&gt;</description></item><item><title>企业级 AI 必须设计成出错后可以追责到人</title><link>https://hugozhu.site/post/2026/161-enterprise-ai-accountability-by-design/</link><pubDate>Sun, 29 Mar 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/161-enterprise-ai-accountability-by-design/</guid><description>&lt;p&gt;上周一个真实案例：某电商公司的 AI Agent 自动调整了 2000 个 SKU 的定价策略，导致部分商品以成本价以下售出，一天亏了 80 万。复盘会上，所有人面面相觑——&lt;/p&gt;
&lt;p&gt;运营说：&amp;ldquo;我没动过，是 AI 自动调的。&amp;rdquo;
技术说：&amp;ldquo;模型输出没问题，是数据源有异常。&amp;rdquo;
数据团队说：&amp;ldquo;数据是实时抓取的，跟我们无关。&amp;rdquo;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;没有一个人为这 80 万负责。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;这不是个例。当 AI 从&amp;quot;辅助工具&amp;quot;升级为&amp;quot;执行主体&amp;quot;，一个被企业严重低估的问题出现了：&lt;strong&gt;出了事，找谁？&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>To B Agent 失败的根本原因：不是能力问题，是没有把 Agent 变成默认路径</title><link>https://hugozhu.site/post/2026/154-tob-agent-failure-not-capability-but-closed-loop/</link><pubDate>Thu, 26 Mar 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/154-tob-agent-failure-not-capability-but-closed-loop/</guid><description>&lt;p&gt;回顾过去两年，无数 To B Agent 项目的墓碑上都刻着同一句话：&lt;strong&gt;&amp;ldquo;技术很好，但业务没用起来。&amp;rdquo;&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;技术团队困惑——模型能力明明够了，准确率也达标了，为什么运营就是不用？是培训不够？是界面不好？是 Prompt 没调好？&lt;/p&gt;
&lt;p&gt;都不是。&lt;strong&gt;真正的原因是：你给了运营&amp;quot;用不用随便&amp;quot;的选择权。而只要有选择权，理性人就会选择不用。&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>别再卷模型了：To B Agent 创业，用户反馈才是生死线</title><link>https://hugozhu.site/post/2026/151-tob-agent-user-feedback-loop/</link><pubDate>Mon, 23 Mar 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/151-tob-agent-user-feedback-loop/</guid><description>&lt;p&gt;2026 年，一个事实已经无法忽视：&lt;strong&gt;模型训练不再是一项研究活动，而是一项系统工程。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;预训练需要万卡集群和 PB 级数据管线，强化学习需要奖励模型和 RLHF/DPO 的工程化流水线，推理优化涉及量化、蒸馏、speculative decoding 等一整套工具链，Agent 能力构建则横跨 function calling、长上下文、规划与工具使用的多维调优。任何一个方向的突破，如果不能在其他环节配合落地，就只是一篇论文，不是一个产品。&lt;/p&gt;
&lt;p&gt;这意味着什么？&lt;strong&gt;模型本身正在变成标准化基础设施。&lt;/strong&gt; 就像今天没有哪家 SaaS 公司拿&amp;quot;我们用了 PostgreSQL&amp;quot;当竞争优势一样，未来也不会有哪家 Agent 公司仅靠&amp;quot;我们微调了一个更好的模型&amp;quot;赢得市场。&lt;/p&gt;
&lt;p&gt;那么 To B Agent 创业的制胜变量到底是什么？&lt;/p&gt;</description></item><item><title>当钉钉变成命令行：办公协同 Skill 的 Token 交付时代</title><link>https://hugozhu.site/post/2026/150-dingtalk-cli-office-skills-token-era/</link><pubDate>Sun, 22 Mar 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/150-dingtalk-cli-office-skills-token-era/</guid><description>&lt;p&gt;软件行业有一个永恒的矛盾：&lt;strong&gt;标准化产品满足不了个性化需求，定制开发又贵得离谱&lt;/strong&gt;。每家企业都想要&amp;quot;适合自己的办公系统&amp;quot;，但 SaaS 只能给你 80% 的功能，剩下 20% 要么忍着，要么花十倍的钱去定制。&lt;/p&gt;
&lt;p&gt;钉钉的 CLI 化开放正在改变这个游戏规则。当钉钉的消息、日历、审批、文档、通讯录等能力都可以通过命令行接口被 AI Agent 直接调用时，一个新范式浮现了：&lt;strong&gt;过去需要写代码、做定制、走项目的办公需求，现在可以用自然语言描述，由 AI 用 Token 来交付。&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>AI Native 文档：会话即知识，过程即资产</title><link>https://hugozhu.site/post/2026/144-ai-native-document-conversation-as-knowledge/</link><pubDate>Mon, 16 Mar 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/144-ai-native-document-conversation-as-knowledge/</guid><description>&lt;p&gt;企业每天都在产生大量知识，但绝大多数知识从未被记录下来。不是因为没有文档系统，而是因为&lt;strong&gt;真正的知识不在文档里，而在产生文档的过程中&lt;/strong&gt;。&lt;/p&gt;
&lt;p&gt;一份产品方案的最终版本只有 10 页，但写这 10 页的过程中，团队讨论了 20 个方案、否定了 15 个、在 3 个关键决策点上反复权衡。这些讨论、推理和决策——才是企业最有价值的知识。传统文档系统只保存了结论，丢掉了思考。&lt;/p&gt;
&lt;p&gt;AI Native 文档要解决的，就是这个问题。&lt;/p&gt;</description></item><item><title>构建企业级Agent Runtime：从Skill到Workspace的五层架构</title><link>https://hugozhu.site/post/2026/143-enterprise-agent-runtime-five-layer-architecture/</link><pubDate>Mon, 16 Mar 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/143-enterprise-agent-runtime-five-layer-architecture/</guid><description>&lt;p&gt;很多团队对 Agent 的理解还停留在&amp;quot;LLM + Prompt + 几个工具调用&amp;quot;。这种理解能跑通 Demo，但一旦进入企业级场景——多任务并行、多系统集成、多角色协作、安全审计——就会发现：&lt;strong&gt;Agent 系统的核心挑战不是让 LLM 更聪明，而是构建一个可扩展、可治理、可审计的运行时架构。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Agent 系统本质上在解决五个问题：用户要做什么（Agent）、谁来执行（Sub-Agent）、如何执行（Skill）、从哪里获取数据（MCP）、执行过程的状态存在哪里（Workspace）。这五个问题对应了系统的五个核心层次。&lt;/p&gt;
&lt;p&gt;本文将这套架构完整展开。&lt;/p&gt;</description></item><item><title>为 AI 重建的 IM 架构</title><link>https://hugozhu.site/post/2026/142-im-architecture-rebuilt-for-ai/</link><pubDate>Sun, 15 Mar 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/142-im-architecture-rebuilt-for-ai/</guid><description>&lt;p&gt;传统 IM（即时通讯）解决的是一个简单的问题：&lt;strong&gt;让人和人高效地交换信息&lt;/strong&gt;。文本、图片、文件、语音——三十年来，IM 的核心架构围绕着&amp;quot;谁说了什么&amp;quot;展开，安全靠端到端加密，权限靠静态角色控制，审计靠消息日志。这套体系服务了几十亿用户，足够成熟。&lt;/p&gt;
&lt;p&gt;但当 AI Agent 成为 IM 中的活跃参与者——不仅接收消息，还理解意图、调用工具、执行任务、产生后果——传统 IM 的架构假设就被从根本上打破了。&lt;strong&gt;IM 不再只是信息传递的通道，而是 Agent 协作与执行的操作系统。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;这需要一种全新的 IM 架构。&lt;/p&gt;</description></item><item><title>企业专属模型：让企业放心调用大模型的架构最佳实践</title><link>https://hugozhu.site/post/2026/141-enterprise-dedicated-model-architecture/</link><pubDate>Sun, 15 Mar 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/141-enterprise-dedicated-model-architecture/</guid><description>&lt;p&gt;和企业客户聊 AI 落地，十次有九次会被问到同一个问题：&lt;strong&gt;&amp;ldquo;我们调用你们的大模型，数据会不会被拿去训练？&amp;rdquo;&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;这个问题背后的焦虑是真实的。企业的客户数据、商业机密、内部文档、代码仓库——这些是企业的核心资产。把它们发送给一个外部的大模型 API，本质上就是把家底给别人看了一遍。如果这些数据还被用来训练模型，那等于是在免费帮竞争对手提升 AI 能力。&lt;/p&gt;
&lt;p&gt;好消息是，这个问题在 2026 年已经有了成熟的解决方案。坏消息是，大多数企业还不知道该怎么选。&lt;/p&gt;</description></item><item><title>AI 时代的企业数字化 = 工作 Agent 化 + 知识 AI Ready 化 + 软件 CLI 化</title><link>https://hugozhu.site/post/2026/137-enterprise-digitalization-in-ai-era/</link><pubDate>Wed, 11 Mar 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/137-enterprise-digitalization-in-ai-era/</guid><description>&lt;p&gt;过去两年，几乎每家企业都在谈&amp;quot;拥抱 AI&amp;quot;。但你去看看大多数企业的 AI 落地项目，会发现一个尴尬的现实：&lt;strong&gt;聊天机器人做了一堆，效率提升约等于零。&lt;/strong&gt; 问题出在哪？不是 AI 不够强，而是企业的数字化基座根本不是为 AI 设计的。&lt;/p&gt;
&lt;p&gt;我越来越确信一个判断：AI 时代的企业数字化，可以浓缩成一个公式——&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;企业数字化 = 工作 Agent 化 + 知识 AI Ready 化 + 软件 CLI 化&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;这三项缺一不可，而且顺序很重要。&lt;/p&gt;</description></item></channel></rss>