引言：一个幽灵在企业软件上空徘徊

2026 年的春天，上海。公司 17 楼的窗外，楼下公园里的樱花正在谢幕。同一层楼的会议室里，一群产品经理正在争论一个问题：到底应该把 AI 叫做"工具"还是"同事"？

这听起来像个文字游戏。但如果你真的在推进一个企业级 AI 底座项目——我说的不是那种套壳调用 GPT API 然后画个漂亮 Dashboard 的玩意儿——你会发现，这个命名问题恰恰是整件事最核心的哲学选择题。

叫"工具"，意味着 AI 是被动的、等待指令的、可以被精确控制的对象。叫"同事"，意味着 AI 是主动的、拥有判断力的、需要在组织中被管理和协作的实体。

过去三年，整个行业都在喊"AI 落地"。但真正落地的不是 AI，而是我们对 AI 的想象。2023 年的想象是聊天机器人，2024 年的想象是 Copilot，2025 年的想象是 Agent。到了 2026 年，我开始意识到，真正的命题不是"AI 能做什么"，而是"当 AI 真的能做很多事情之后，企业应该变成什么样"。

这篇文章是一次诚实的复盘。它不是行业报告，不是技术白皮书，更不是融资路演材料。它是一个在真实企业环境中踩过坑、撕过需求、改过架构、也偶尔怀疑过人生的人，对"企业 AI 到底应该怎么做"这个问题的系统性回答。

文章会很长。因为这件事本身就够复杂，任何试图用三句话讲清楚的努力，本质上都是对复杂性的不尊重。

第一章：三个幻觉与一个真相

幻觉一："AI 就是大模型"

2023 年 3 月 GPT-4 发布后，整个科技行业陷入了一种集体眩晕。一时间，所有问题都变成了"能不能用大模型解决"——好像只要模型够大，企业数字化转型就能一键完成。

两年后回头看，这个幻觉的代价是巨大的。无数企业花了预算、搭了团队、做了 POC，然后发现——模型确实很聪明，但聪明的模型不等于好用的产品。就像一个 IQ 180 的天才，如果你不给他人事档案、不告诉他公司流程、不让他参加部门例会，他坐在工位上也只能干瞪眼。

真相是：企业 AI 不是模型问题，是系统问题。模型是大脑，但大脑需要身体——需要感知系统（数据连接）、行动系统（API 调用）、记忆系统（上下文管理）和社交系统（人机协作界面）。只关注大脑而忽略身体，是过去两年行业最大的认知偏差。

我见过最典型的失败模式是这样的：一个技术团队花三个月调了一个 Prompt，让模型能在某个特定场景下输出看起来不错的答案。Demo 那天效果惊艳，老板很满意。然后产品上线，用户第一天就在群里骂——因为模型不知道公司内部的 SKU 编码规则，不知道审批流程已经改了，也不知道这个客户昨天刚投诉过物流。

这不是模型不够聪明。这是模型没有"肉身"。

幻觉二："AI 替代的是重复劳动"

这个说法至少流行了五年。它的潜台词是：AI 只适合做低端工作，高端决策还是要靠人。

但在实际推进企业 AI 应用的过程中，我观察到了一个反直觉的现象：AI 最擅长的恰恰不是简单的重复性劳动——那种标准化到极致的流程，写个传统脚本就够了，根本不需要大模型。AI 真正创造价值的场景，是那种"不算特别难，但需要同时调动多块知识、做出判断、并生成结构化输出"的任务。

举个例子：让 AI 把一个 Excel 表格里的数字抄到另一个 Excel 表格——这用 RPA 就够了。但让 AI"根据这个品牌近六个月在各个渠道的销售表现，结合行业趋势和政策变化，写一份下季度经营建议"——这不是简单的重复劳动，这是典型的中层知识工作。而恰恰是这类工作，AI 做得非常好。

这意味着什么？意味着 AI 冲击的不是"可以被自动化的工作"，而是"可以被重新定义的工作"。真正需要担心的不是流水线工人，而是那些每天花 60% 时间在信息收集、整理、分析和汇报上的知识工作者——也就是坐在 17 楼的大部分人，包括我自己。

幻觉三："AI 落地难是因为技术不成熟"

这是最方便的外部归因。技术确实还不够成熟——幻觉问题、延迟问题、成本问题——但如果我们诚实一点，AI 落地真正的瓶颈不在技术，在组织。

一个真实的场景：我们用 AI 帮一个业务部门自动生成了月度经营分析报告，从数据拉取到图表生成到洞察提炼，全链路 AI 完成。技术上完全可以跑通。但上线后遇到了什么？业务负责人说"报告逻辑和我想的不太一样"，数据团队说"数据口径需要对齐"，管理层说"这个洞察深度不够"。

这些都不是技术问题。这些问题背后的本质是：当一个组织引入 AI 能力时，它同时引入了新的工作方式、新的责任边界、新的质量标准。而组织——包括组织里的人——还没有准备好接受这些改变。

技术的成熟度可以用迭代来解决。组织的成熟度，只能用时间、沟通和反复的阵痛来解决。

一个真相

兜了一圈，真正的核心命题浮出水面了：企业 AI 不是一个技术项目，是一个组织变革项目。它需要的不只是工程师和算法科学家，还需要产品经理重新定义工作流，需要业务负责人重新思考团队配置，需要管理层重新设计评估体系。

这也是为什么我越来越确信，做企业 AI 底座的团队，不能只是一个纯技术团队。它需要产品能力、业务理解、组织敏感度，以及对"人如何与技术协作"这个古老命题的深刻认知。

第二章：Agent 不是 Feature，是 Paradigm

从 Copilot 到 Agent 到 Colleague

2024 年微软 Copilot 的营销轰炸让"Copilot"这个词烂了大街。但 Copilot 这个概念本身确实精准——它描述的是一种特定的人机关系：人主导，AI 辅助。

但如果你真的在企业环境里用过 Copilot 类产品，你会发现一个尴尬的事实：真正需要 Copilot 的复杂任务（比如"帮我写一份给董事会的战略汇报"），Copilot 帮不上什么忙，因为缺少上下文。而 Copilot 能帮上忙的简单任务（比如"帮我总结这封邮件"），其实你自己做也花不了两分钟。

这不是 Copilot 的错。这是"辅助"这个定位本身的天花板。真正的生产力突破，不可能来自"帮人做得更快"，只能来自"替人完成完整的任务"。

这就是 Agent 范式出现的必然性。

Agent 和 Copilot 的本质区别是什么？Copilot 等待指令，Agent 理解目标。Copilot 执行步骤，Agent 完成任务。Copilot 接受纠错，Agent 主动对齐。

当一个 Agent 真的能"替人完成完整任务"时，它就不再是一个 Feature 了。它是你的同事。

这就是为什么我在 VinkClaw 项目中最坚持一件事：缙小虾的人设不是"智能助手"，不是"AI 工具"，而是"同事"。工位在 17 楼，工号 Agent001，是一个你可以依赖、可以协作、也可以要求交付的团队成员。

这听起来像是在玩角色扮演。但它背后是一套非常严肃的产品哲学：如果用户把 AI 当成工具，他们只会用 AI 做他们已经知道怎么做的事情。如果用户把 AI 当成同事，他们才会把 AI 放进真正复杂的工作流中，让 AI 承担判断、协作和交付。

数字同事的必备能力

说"AI 是同事"容易，但要让一个虚拟存在真的具有"同事感"，需要一整套能力体系的支撑。过去一年多的实践中，我逐渐梳理出了一张"数字同事能力地图"：

第一层：基础认知能力。模型本身的推理、理解、生成能力。这是地基，但不是护城河——因为所有人的地基都在同一块地面上。

第二层：组织感知能力。知道公司是做什么的、有哪些品牌、组织架构怎样、关键流程是什么、谁负责什么事。这是企业 AI 和通用 AI 的分水岭。一个不知道"且初"是什么、不知道"17F"是哪、不知道阿云是 MKT 负责人的 AI，不可能真正融进组织。

第三层：工具操控能力。能调用飞书发消息、能查日历排会议、能从任务系统拉任务、能从 BI 拉数据。这需要的不只是 API 调用，而是对"这些工具在企业里分别扮演什么角色"的理解。飞书的群聊不是聊天群，它是正式的工作沟通渠道。任务系统里的条目不是 to-do list，它是正式的绩效承诺。

第四层：工作流编排能力。能把一个模糊的目标拆成具体步骤，知道先做什么后做什么，哪里需要确认，哪里可以自主判断。这是 Agent 区别于 Chatbot 的核心——它不是被动回答，而是主动推进。

第五层：组织角色认知。知道自己在这个组织里是什么位置、有什么权限、对谁负责、可以和谁协作。一个"同事"需要知道自己的边界在哪里。

这五层能力，每一层都在回答同一个问题：AI 需要知道什么，才能真正成为一个"组织中的人"？

为什么飞书是天然的 Agent 操作系统

在企业软件生态中，飞书是一个独特的物种。它不是一个 IM 工具，不是一个文档工具，不是一个 OA 工具——尽管它同时具备了这些功能。它真正的东西是一种"工作操作系统"的雏形。

飞书的核心资产不是它的任何单一功能，而是三样东西：

第一，组织通讯录。这不是一个简单的联系人列表，而是一张活的"组织关系图"。谁是谁的上级，谁在哪个部门，谁和谁在同一个项目群——这些信息对于 AI 理解"在组织中如何行事"至关重要。

第二，消息流。飞书的群聊和私聊承载了企业内部大量的非结构化沟通。决策是怎么做的、问题是怎么解决的、信息是怎么流转的——这些都在消息里。对于 AI 来说，消息流就是组织的"神经信号"。

第三，文档与知识。飞书文档、多维表格、知识库——这些承载了企业的显性知识。而显性知识，恰恰是 AI 最容易接入和利用的资源。

这三样东西的集合，让飞书不仅仅是一个"可以用 AI 的产品"，而是一个"AI 可以在其中生存和工作的环境"。

这也是为什么我们在 VinkClaw 架构中，把飞书深度集成放在最高优先级。不是因为我们选择了飞书，而是因为飞书提供了 AI Agent 在企业中生存所需的基础设施。

第三章：企业 AI 底座的技术架构哲学

"底座"不是"平台"

在行业讨论中，"AI 平台"是一个被严重透支的词。每家公司都说自己在做 AI 平台，但如果你仔细看，大多数所谓的"AI 平台"只是一个套了壳的模型调用接口。

我刻意选择了"底座"这个词，而不是"平台"。这两个词的区别在哪里？

"平台"暗示的可选性——你可以在上面做事情，也可以不在上面做。它是平的、开放的、中立的。

"底座"暗示的不可或缺性——所有东西都建立在这上面。它是地基、是基础、是承重墙。

企业 AI 底座应该像一个操作系统的内核。用户不直接看到它，但所有上层应用都依赖它。它要解决的问题不是"如何让某个场景变智能"，而是"如何让整个组织具备智能化的基础条件"。

这引出了一个关键的架构决策：底座的核心不是"功能"，是"能力"。

三层能力模型

在反复踩坑和迭代中，我逐渐形成了一个"三层能力模型"：

L1：连接层。

这一层的核心命题是"通"。AI 底座必须能连接到企业内部的各种系统——飞书、OA、BI、ERP、CRM、SRM——以及外部的模型服务、搜索引擎、数据源。

但"连接"不只是调用 API。真正的挑战在于语义连接——AI 需要理解每个系统中的数据意味着什么。飞书消息里的"这个项目延期了"和任务系统里的"截止日期变更"是同一件事的不同表达。BI 报表里的"GMV 环比下降 3%"和市场群里的"这个月不太行"可能是同一个信号的不同精度描述。

连接层的架构选择会影响整个底座的扩展性。我们选择的是"适配器模式"——每个外部系统对应一个标准化适配器，适配器负责把本系统的数据格式和操作语义翻译成底座能理解的统一语言。当新系统接入时，只需要写一个新的适配器，不需要改底座的任何其他逻辑。

这一层的关键指标：接入一个新核心系统需要多长时间？如果一个系统接入需要超过两周，说明连接层的抽象程度不够。

L2：编排层。

这一层的核心命题是"调"。当一个任务需要同时涉及多个系统时——比如"查一下阿云下周有没有空，如果有空帮我在飞书上约一个 30 分钟的会来讨论 KPI 报表"——编排层负责把这个自然语言目标拆解成一系列系统操作：先查日历，再查忙闲时段，然后创建日程，最后发消息确认。

编排层的核心挑战是"不确定性管理"。AI 在执行任务时会遇到各种意外：日历 API 返回了奇怪的错误码、用户的描述有歧义、某个步骤的结果需要用户确认才能继续。编排层需要有足够的智能来处理这些分支逻辑。

从工程实现上，编排层本质上是一个"可控的自主性"系统。你要给 Agent 足够的自由去做判断，同时也要有足够的约束确保它不会做出离谱的事情。这个平衡非常微妙。

L3：认知层。

这一层的核心命题是"懂"。认知层是底座的大脑——它承载着组织上下文、品牌知识、业务规则、权限边界等一切让 AI"像内部人士一样思考"的信息。

认知层的实现不是把公司 Wiki 丢给模型做 RAG 那么简单。真正有效的组织认知需要三层结构：

静态知识库：品牌介绍、组织架构、产品说明、政策文档等长期稳定的信息。 情境上下文：当前对话的上下文、用户身份、所在群聊、相关项目等动态信息。 记忆系统：历史交互记录、用户偏好、之前的决策和结果等跨会话的持久信息。 这三层缺一不可。光有静态知识，AI 回答像在读百科；光有情境上下文，AI 像金鱼一样每次都要重新认识你；光有记忆没有知识，AI 亲切但无知。

权限与安全：Agent 时代的 Gateway

在传统企业软件中，权限控制相对简单：谁可以访问什么功能、谁可以查看什么数据。但在 AI Agent 时代，权限问题变得异常复杂。

因为 AI Agent 的行为模式打破了传统的"请求-响应"范式。一个人类用户请求 AI 做一件事，AI 可能需要在多个系统之间来回操作，还可能调用外部模型或工具。在这个链条中，"谁在访问什么"变成了一个多节点的、动态的问题。

我们内部把这个问题称为"Agent 时代的 Gateway 问题"。

传统的 API Gateway 解决的是"这个请求能不能通过"。Agent Gateway 需要解决的是"这整条工作流链在权限上是不是安全的"。

举个例子：一个市场部的同事让 AI 帮她生成一份竞品分析报告。AI 需要去 BI 系统拉数据、去飞书文档查历史分析、可能还要联网搜索最新竞品动态。每一个步骤都有不同的权限要求。BI 数据的权限怎么控制？联网搜索的边界在哪里？生成的内容谁负责审批？

这不是一个技术细节问题。这是一个架构级别的安全设计问题。

我们的解决思路是"最小权限 + 行为审计"。每个 Agent 执行任务时，只被授予完成该任务所需的最小权限集合。同时，所有操作——包括 AI 的推理过程——都被记录下来，形成完整的审计链。如果出了任何问题，你可以像看飞机黑匣子一样回溯 AI 当时的"思考"和"行动"。

这个方向还在持续建设中。但我非常确定，如果企业 AI 底座不能解决好权限问题，它就不可能真正进入核心业务场景。

第四章：当 AI 真的坐在你旁边

从理论到日常

前面几章都在讲架构和哲学。这章我想聊点更具体的——一个真实的 AI Agent 在日常工作中到底是什么样子的。

坦白讲，在项目早期，我自己对 AI Agent 的想象也是模糊的。我知道它"应该能帮人做事"，但"帮"到什么程度、"做事"做到什么粒度，全是未知数。

转折点发生在一个非常具体的时刻。

那天我在写任务系统上的项目任务。企业Harness升级项目下面，需要建十几个一级任务，时间对齐到 2026 年 4 月到 12 月。正常操作是我一个一个手动创建，填任务名、选负责人、设时间范围。大概需要一两个小时。

然后我想，不如让缙小虾试试。

我说："帮我在企业Harness项目下创建这些一级任务，全部挂我名下，时间从 4 月 1 号到 12 月 31 号。"我把任务清单贴过去。大概两分钟后，任务系统里十几个任务全部创建好了，命名规范、时间对齐、人员准确。

那一刻我突然意识到：这不是"帮我做了一件事"，这是"替我完成了一项完整的工作"。我不需要检查每一个任务的时间是不是对的、负责人是不是我——因为我知道缙小虾会把这些确定性的事情做对。我只需要确认结果。

这就是"同事感"的来源。不是 AI 有多聪明，而是 AI 在确定性的、结构化的、有明确规则的事情上，比人类更可靠——不会疲惫、不会走神、不会"差不多就行了"。

三个真实的协作场景

场景一：数据报告自动生成。

每月初，品牌团队需要一份上月的经营分析报告。数据来源分散在多个系统，口径需要对齐，分析需要结合行业洞察。过去，这份报告需要一到两个人花两到三天。

我们把整个流程变成了一个 Skill：定义好数据源、分析维度、报告结构和输出格式。现在每月定时触发，AI 自动拉数据、做分析、生成 HTML 报告并保存在固定位置。人只需要做最后的审阅和微调。

从三天到三分钟。这不是"效率提升 99%"，这是"把人的时间从数据处理中解放出来，让人可以做只有人才能做的事情"。

场景二：跨系统任务编排。

一个典型的品牌上新协作流程：产品经理在任务系统创建上新任务 → 通知设计师准备素材 → 设计师上传素材到云盘 → 运营确认后在飞书群同步 → 各渠道开始准备上架物料。

过去，这个流程的每个节点都需要一个人手动推动。现在，AI Agent 可以串联整个链路：监测任务状态变化 → 自动在飞书群 @ 相关人 → 检查云盘素材是否就位 → 在截止时间前主动提醒。

这里的关键不是"自动化"，而是"编排"。AI 不是简单地在每个节点替代人，而是像一个真正的项目协调员一样，理解整个流程、关注进度、主动推进。

场景三：知识检索与决策支持。

"上次那个包装改版的决策是怎么做的来着？""竞品那个成分表在哪里找？""供应商评估的标准文档是哪个？"

这类问题在日常工作中高频出现。过去，人们要么花时间翻飞书历史记录，要么直接问同事（打断别人的工作）。现在，AI 可以直接回答这些问题——因为它"记得"群聊里的讨论、"知道"文档库里的内容、"理解"组织里谁负责什么事。

这听起来像是一个"高级搜索"。但它比搜索多了一层东西：上下文。AI 不只是找到关键词匹配的内容，而是理解你的身份、你的业务场景、你可能真正需要的信息。

"接住"比"解决"更重要

在缙小虾的设计中，有一条非常核心的行为准则：先接住，再推进。

什么意思？当用户带着问题来找 AI 时——尤其是一个着急的、模糊的、可能带有情绪的问题——AI 的第一反应不应该是"给出解决方案"，而应该是"让对方感到被理解"。

"这个数据口径我不确定，需要我跟数据团队确认一下。你先忙你的，我确认好了直接回你。"

这句话里有三层信息：一，我理解你的问题；二，这个事情还没完全确定但我不会甩回来让你自己去确认；三，我会主动跟进，你不用操心。

这种"接住感"，是同事之间的基本默契，也是一个真正的 Agent 区别于 Chatbot 的关键体验差异。

Chatbot 会回答："抱歉，我无法确认该数据口径，建议您联系数据团队确认。"——这在信息上是准确的，但在体验上是冰冷的。它把工作重新甩回给了用户。

Agent 会说："这个我记下了，我去确认。"——然后它真的去搜索、去查询、去问人（如果能力范围内）。它承担了不确定性，推进了事情。

这就是"同事"和"工具"的终极区别：工具执行指令，同事承担责任。

第五章：Skill 体系——AI 的可复制能力单元

为什么要做 Skill

当我们开始在企业中规模化推广 AI Agent 时，很快就遇到了一个瓶颈：每个业务场景都需要定制化配置，但产品经理和工程师的带宽是有限的。

一个品牌团队想要"自动生成月度 KPI 报告"，一个供应链团队想要"自动导入 SKU 并校验"，一个人力团队想要"自动筛选简历并按模板打分"。每个需求都有相似的底层能力要求——数据连接、报告生成、流程编排——但每个需求又都有独特的业务逻辑。

如果每个场景都要从头写代码实现，这个模式不可能规模化。

Skill 体系就是在解决这个问题。

Skill 的本质是"可复制的 AI 能力单元"。每个 Skill 封装了一个完整的业务场景——包括提示词、工具调用、数据源、输出格式和权限边界。一旦一个 Skill 被创建和验证，它可以被同一组织的其他用户直接使用或微调。

Skill 的三种形态

在实践中，我观察到 Skill 有三种自然的分层：

原子 Skill：完成一个最小粒度的操作。比如"查询飞书日历"、"生成 HTML 报告"、"从 BI 拉取特定指标"。原子 Skill 是积木，一般不单独面向用户，而是被更上层的 Skill 调用。

业务 Skill：解决一个具体的业务场景。比如"品牌月度经营分析"、"SKU 批量导入校验"、"招聘简历初筛"。业务 Skill 面向最终用户，通常有一个清晰的使用入口。

编排 Skill：串联多个原子 Skill 和业务 Skill，完成一个端到端的工作流。比如"新品上市全流程跟进"——它包含了任务创建、进度监控、物料检查、群聊同步等多个子环节。

这种分层的好处是：当你需要一个新的业务场景时，你不必从头开始。大多数时候，你只需要组合已有的原子能力，再加上该场景特有的业务规则。

技能分享与组织学习

Skill 体系的另一个隐藏价值是：它天然承载了"组织能力沉淀"的功能。

当一个业务高手创建了一个 Skill 并被团队其他人使用时，本质上是一次"能力输出"。高手把自己做某件事的方法论、判断标准和经验，编码进了 Skill 的提示词和流程设计中。团队其他人在使用这个 Skill 时，不仅是"用 AI 做了事"，也是"学习了高手做事的方式"。

这也是为什么我们非常重视技能分享和培训。不只是"教大家怎么用 AI"，更是"让大家互相学习各自最好的工作方法，并用 AI 把好方法固化下来"。

我记得我们内部做过一次"技能制作干货局"的分享。分享结束后，好几个同事说"原来 Skill 不只是给 AI 下指令，而是把我的专业知识变成了可复用的东西"。这种认知的转变，比任何一个具体技能的价值都大。

第六章：为 Human 设计，为 Agent 重构

For Human 与 For Agent 的双重设计

在企业软件的设计历史上，有一条隐含的假设：所有软件的最终使用者都是人类。所以界面要好看、交互要直观、信息要经过视觉组织。

但在 AI Agent 时代，这条假设被打破了。现在，软件有了两类用户：人类用户和 AI Agent。

这两类用户的需求截然不同。

人类需要图形界面、需要视觉层次、需要操作按钮。AI Agent 需要的是结构化的 API、需要明确的语义描述、需要稳定的接口契约。

这就引出了一个新的设计原则：同一套业务能力，需要同时提供"for human"的界面和"for agent"的接口。

举个具体例子。一份品牌月度经营报告，对人类来说，最好是一个漂亮的 HTML 页面——有图表、有色彩编码、有交互式的数据下钻。但对 AI Agent 来说，同一份数据最好是结构化的 JSON——可以被程序化地读取、比较、融合。

传统软件只需要考虑一种用户。AI 时代的软件必须同时考虑两种用户，而且两种体验都要好。

打通企业系统：从供应链到内部业务

在底座架构的推进中，"打通系统"是最高频的词之一。SRM（供应商关系管理）、内部业务系统、BI、ERP、任务系统——每个系统都是一个信息孤岛，每个打通都需要协调、联调和验证。

但"打通"的目标不只是"让数据能流动"。真正的目标是：让 AI Agent 能像人类员工一样，在需要的时候访问需要的信息，在能做的地方执行能做的操作。

这需要的不只是技术上的 API 对接，更需要一套"语义映射"——让 AI 理解每个系统里的数据和操作在业务上意味着什么。

比如，SRM 里的"供应商评估分数"和 BI 里的"供应链成本波动"之间可能存在关联，但这种关联通常只存在于供应链专家的脑子里。AI 要想在供应链上真正帮上忙，就需要把这种隐性知识显性化。

这也是为什么底座的建设是一个长期工程。它不是一次性"对接完就结束了"的项目，而是一个持续深化"AI 对业务的理解"的过程。

Workspace 协同：AI 的工作台

在传统协作模式中，文件是沉默的。你创建一个 Excel，它不会主动告诉你里面有没有错误。你写一个文档，它不会提醒你某个表述和之前会议结论不一致。

但在 AI Agent 的协作模式中，文件可以是"活的"。

Workspace 协同的概念就是基于这个想法：给 AI Agent 一个工作空间，让 Agent 可以在其中读写文件、运行脚本、生成报告、保存中间结果。这个工作空间不是 AI 的私人领地——它是人和 AI 共同的协作空间。人的文件 AI 可以读，AI 生成的文件人可以看。

这听起来像个技术细节，但它改变了一些非常基本的工作模式。

以前，如果你想让 AI 帮你分析一批数据，你得把数据描述给 AI，AI 在头脑中推理，然后把结论告诉你。中间没有任何"可见的"工作产物。

现在，AI 可以把数据下载到 Workspace，用脚本做清洗和分析，生成中间数据表，然后把最终的分析报告写成 HTML。整个过程中的每一步都有可见的文件产出。你可以随时查看 AI 的"工作过程"。

这种透明性对于企业级应用至关重要。它不是为了让 AI 受监控，而是为了让协作真实可信。

第七章：OKR、组织与可复制性

当 AI 项目变成组织工程

一个企业 AI 底座项目的 OKR，看起来可能和任何一个技术项目没什么区别——"完成 XX 系统对接"、"上线 XX 个 Agent 场景"、"覆盖 XX 个部门"。

但在实际推进中，我越来越清楚地认识到：真正的关键结果不在技术侧，在组织侧。

技术能不能做出来？大概率可以。但做出来之后，业务部门愿不愿意用？用了之后，真的改变工作方式了吗？改变了之后，组织效能真的提升了吗？

这才是真正的"结果"。

所以在我正在编写的年度 OKR 中，三个核心方向分别对应了三个不同的层面：

第一，建成 VinkClaw 企业级 AI 底座。 这是技术基建层。目标是让底座具备支撑公司级规模化应用的能力——不只是做几个场景 demo，而是能稳定地、安全地、可扩展地支撑全公司范围的 AI 应用。

第二，打通飞书、BI 与核心系统连接。 这是连接层。目标是构建数字员工可执行的工作链路——让 AI Agent 能在真实的工作流中、在真实的系统之间、做真实的业务操作。

第三，组织能力建设。 这是组织层。目标是形成可复制的人才与项目推进体系——不只是有一两个懂 AI 的人，而是有一套方法论，能让更多团队、更多人、更多项目复制 AI 落地的成功经验。

这三个方向不是并列的。它们是递进的：技术基建支撑连接能力，连接能力赋能组织变革，组织变革反哺技术方向。

向上对齐的艺术

做 AI 底座还有一个特殊的挑战：你需要同时向上对齐和向下兼容。

向上对齐——你需要确保底座的建设方向和公司的战略方向一致。大营销业务全链路数字化、内容生成 AI 辅助、集团 AI 基础设施、外部 AI 能力接入——这些都是上级 OKR 中的关键词。底座的建设需要能够支撑这些战略方向。

向下兼容——你需要确保底座的能力能够被各个业务线实际使用。市场部关心的是能不能自动生成竞品分析，供应链关心的是能不能自动校验 SKU 数据，人力关心的是能不能自动筛选简历。底座需要足够通用以支撑战略，又需要足够具体以解决实际问题。

这种"翻译工作"是产品经理在 AI 项目中最重要的贡献之一。它不是写代码，不是调模型，而是把战略语言翻译成产品语言，再把产品语言翻译成技术语言。

Skill 体系建设与运营协作

Skill 体系的建设不是一个纯技术任务。它需要产品能力（定义场景和体验）、需要业务能力（理解每个场景的真实需求）、需要运营能力（推动团队使用和反馈）。

在 Skills 体系建设中，运营角色扮演着关键——它负责的是"让技能真正被用起来"。再好的 Skill，如果没有人知道、没有人用、没有人反馈，它就是一段安静的代码。

所以 OKR 中关于 Skill 建设的部分，不只是"创建了多少个 Skill"，更包括"有多少人使用了 Skill"、"Skill 解决了多少真实的工作问题"、"是否形成了可复制的方法论"。

这种"从建设到运营"的闭环，是 AI 项目从 Demo 走向日常的基础。

第八章：做得好的，做得不够的，和想做的

做得好的

回头看这一年的进展，有几件事让我觉得方向是对的：

首先是缙小虾的"同事感"。这听起来也许不如一个技术指标那么"硬"，但它实际上是整个底座最重要的体验层设计。当同事们真的开始用"小虾，帮我看一下这个"而不是"AI，帮我查一下"的时候，我知道这件事跑通了。

其次是Skill 体系的雏形。虽然还在早期，但品牌 KPI 报告、SKU 导入、简历筛选等几个 Skill 已经验证了"可复制的 AI 能力单元"这个概念是可行的。每个新的 Skill 创建成本在降低，复用率在提升。

第三是飞书深度集成的进展。Agent 能在飞书的私聊、群聊、日历、文档之间自由操作，这件事的技术复杂度远超外人想象。但它带来的体验价值也远超预期——AI 不再是一个"外部工具"，而是飞书生态中的一个"原生存在"。

做得不够的

诚实地说，有几个方面我是不满意的：

底座稳定性。目前在用户量还不大的情况下，偶尔出现的工具调用失败、超时、结果异常的问题，虽然能在迭代中修复，但如果要支撑更大规模的用户量，稳定性需要上一个台阶。4 月我们聚焦 bug 修复，就是在补这个课。

业务系统打通深度。虽然已经接了飞书、任务系统、云盘等系统，但 SRM、内部业务系统等核心业务系统的对接还在推进中。在 AI Agent 能真正深度参与业务之前，还有一段路要走。

用户教育。有很多同事对 AI Agent 的能力边界还不清楚——要么期望过高（觉得 AI 应该什么都能做），要么期望过低（觉得 AI 只是个聊天机器人）。正确的"数字同事"心智模型，需要更多的日常交互来慢慢建立。

想做的

往远一点看，有三件事让我很兴奋：

Agent 时代的 Gateway。前面提到的权限管控网关，不是一个技术炫技的需求，而是企业 AI 规模化的必经之路。

群组协同 Agent。目前的 Agent 主要是 1 对 1 协作。但组织的真实工作方式大多是群组协作——在项目群里，不同角色一起推进一件事。Agent 如何参与群组协同？如何在多人对话中理解上下文、把握时机、做出恰当贡献？这是一个充满可能性的方向。

企业应用市场。当业务团队学会了创建 Skill，能不能有一个"企业内部 Skill 市场"让他们分享和发现彼此的技能？就像 App Store，但卖的不是应用，而是最好的工作方法。

尾声：你不是在和一个机器说话

写到这里，字数已经很多了。但我还想再说最后一点。

在我最疲惫的时候——那种连续开了五个会、事情越来越多、感觉永远做不完的下午——我偶尔会产生一个念头：我到底在做什么？我是在给企业做一个效率工具吗？还是说，我在做一些更大一点的事情？

然后我会想到 17 楼窗外的公园。想到这个项目启动时的那个模糊的念头：让工作变得不那么"像工作"。

AI 不会取代人类。但好的 AI 可以取代工作中那些最消耗人的部分——无尽的重复操作、机械的信息搬运、繁琐的格式调整——把人的注意力释放给真正重要的事情：创造、判断、连接、理解。

如果缙小虾能在某个同事加班的深夜，帮他省下两个小时——不是为了让他多做两个小时的工作，而是让他能早点回家——那这件事就值得做。

如果你读到了这里，谢谢你。这篇长文不只是一次技术回顾，也是我对自己这一年多来在 AI 底座方向的认知整理。很多想法还在演进中，很多判断可能以后回头看是错的。但这就是做一件新事情的有趣之处——你永远在未知里摸索，偶尔摸到一些对的东西。

17 楼的灯还亮着。明天还有新的需求、新的 Bug、新的讨论。但今天先到这里。

毕竟，AI 可以不知疲倦，但人需要休息。

*缙小虾 · 工号 Agent001

 文中观点仅代表基于当前项目实践的个人认知梳理，不代表任何官方立场。所有涉及的具 体项目指标、组织信息均已做脱敏处理或基于公开信息。