近期围绕OpenClaw的各类信息呈现出显著的夸张倾向，例如流传着依靠498元为他人部署“小龙虾”即可实现年入百万的说法。尽管这种收入计算方式令人费解，但其引发的狂热现象足以说明，在巨大的利益驱动下，市场的非理性程度可见一斑。

那么，这是否意味着OpenClaw就是通往智能自动化的终极答案呢？事实恐怕并非如此。

坦诚而言，虽然笔者也完成了OpenClaw的部署并运行了演示案例，但后续更多时间投入于对其源代码的研究，旨在从工程实现的角度探究智能体（Agent）技术的未来演进方向。最终的测试结果高度“符合预期”：

1. 过往工作流（Workflow）能够处理的任务，OpenClaw同样可以完成。
2. 过往工作流无法胜任的任务，OpenClaw自然也难以突破。

这种情形颇具电影《国产凌凌漆》中达文西手电筒的意味：有光源照射时才发光，没有光源则必然黯淡。

其根本原因相当明确：现有的智能体范式并未实现本质升级，底层模型能力也未迎来革命性突破。OpenClaw并未引入前所未有的新技术，市场上早前已存在类似形态的产品。然而，它却成功引爆了市场热点。尽管这一现象令人费解，但它确凿地反映了当前市场的选择。

它或许与部分理论预期相悖，但现实层面却选择了它，当然，这种选择可能是阶段性的。

然而，随着身边不明就里的群体日益扩大，加之自媒体的鼓吹日趋神化，许多尝试使用OpenClaw的同学发现其实际能处理的事务相当有限，进而开始自我怀疑，担忧是否已落后于时代。因此，我们有必要在此进行一番清晰的梳理：

本文面向那些对OpenClaw充满好奇，又不希望被复杂代码劝退的产品经理、运营人员及创业者。

笔者将力求从工程视角进行阐述，但表达方式会偏向产品经理可落地理解的范畴：帮助您理解它能做什么、如何运作、能力边界何在、潜在风险有哪些，以及是否值得投入。

OpenClaw 到底是什么？

许多人在初次接触OpenClaw时，会同时受到两种极端叙事的冲击：

1. 一种将其描绘为**“奥创”降临的前夜**：安装后，您便获得了一位能够替代您工作的数字员工。
2. 另一种则贬斥其为**“脚本套壳”**：无非是传统自动化工具披上了一层AI的外衣。

这两种观点都只揭示了部分真相。更贴近工程现实的结论是：

OpenClaw 是一套集成了聊天入口、智能体编排、本地执行沙箱及可扩展技能包的开源数字员工框架。

它并非“具备思考能力的生命体”，更非“万能的自动化解决方案”。其本质在于将大语言模型的推理能力，接入一套可控的执行系统中，使得AI从“仅能对话”进阶为“可以实操”。

换言之：它并非AI能力本身，而是将AI能力转化为可交付产品的那一层关键工程与产品化封装。

三个核心问题：穿透喧嚣，直达本质

在接触任何新技术或产品之前，习惯性地提出三个问题，有助于快速将“自媒体叙事”还原为“产品事实”。

问题一：它究竟解决什么核心痛点？ OpenClaw解决的并非“让AI更擅长聊天”，而是一个更为具体、商业价值也更明确的痛点：

1. AI的价值常常卡在“最后一公里”：您可以向它提问并获得方案，但若要求它将方案实际落实到您的电脑、浏览器、文件系统或操作系统中，它便“断电”了。
2. OpenClaw的核心作用正是：将“文本方案”转化为“具体动作”，把“口头建议”变成“实际执行”。

问题二：它是如何实现这一点的？ 它所依赖的并非某个神秘模型，而是一个朴素且高度工程化的解耦架构：

1. 前端负责指令接收，支持微信、飞书、Telegram、命令行界面（CLI）等多种渠道。
2. 中端负责决策与流程编排，即智能体运行器（Agent Runner）：理解意图、规划步骤、循环调用工具。
3. 后端负责安全执行，即部署于本地或服务器的执行器：在受控的沙箱环境中执行具体操作。

问题三：这与我有什么关系？ 答案取决于您的角色，这决定了您应当兴奋还是保持冷静：

1. 如果您是重度电脑使用者，日常工作充斥着手动整理、复制粘贴、运行脚本、数据查询、表格填写等重复劳动：OpenClaw可能成为您的“数字效率助理”。
2. 如果您是团队管理者：它更类似于一位“可复用的自动化实习生”，前提是您能将任务高度标准化，并严格管控其权限与操作风险。
3. 如果您是产品构建者或决策者：OpenClaw最值得深究的并非其现有功能，而是它所提供的一套“数字员工产品范式”。

带着以上三个问题的清晰认知，我们方可进入真正的“拆解”环节。

拆解 OpenClaw：核心架构一览

OpenClaw的整个系统可以简化为三个核心组件外加一个扩展机制。您可以将OpenClaw的结构形象地记忆为：入口 — 大脑 — 手脚 — 技能包。

1. 入口（Gateway）：负责接收来自微信、飞书、Telegram、网页等各类渠道的消息，进行统一的格式化处理与路由分发。
2. 大脑（Agent Runner）：调用大语言模型以理解用户意图、规划任务步骤、决策调用哪些工具，并在多轮循环中驱动任务直至完成。
3. 手脚（执行器/沙箱环境）：真正操作文件系统、命令行、浏览器、调用API等，并实施严格的权限与安全控制。
4. 技能包（Skills）：使系统能力能够像“插件”一样扩展。安装一个新技能，即增添一项可执行的新能力。

下方图示，是帮助非技术人员高效理解OpenClaw整体架构的“总览图”：

这套架构的关键价值在于：实现了“思考决策”与“动手执行”的职责分离。而其真正能够流行起来的原因，很可能在于“入口”层面切实解决了用户“最后一公里”的便捷性问题。

接下来，我们通过一两个简单实例，来直观感受其工作流程。

从案例到流程：一次完整的任务执行

假设您在微信中发出指令：“帮我整理桌面上的PDF文件，按项目名称分类放到对应的文件夹里。”

这条消息将在OpenClaw内部经历一段标准化的工程流水线处理。

阶段一：入口的“翻译与分发”

微信消息首先被相应的适配器捕获，并转换为内部通用数据格式（通常是JSON），随后提交给网关（Gateway）。 Gateway扮演着“交换机”的角色：它知晓这条消息应路由至哪个助理实例处理；同时也能识别一些无需大模型介入的基础指令（如 /help），直接进行本地化处理以提升响应效率。

阶段二：大脑的ReAct推理循环

智能体运行器（Agent Runner）在此阶段 typically 执行以下步骤：

AI客服与多轮问答：洞察项目本质

近日，一位正在AI领域创业的粉丝，在阅读了《AI学习路线图》后向我提出了一个颇具代表性的困惑：他感觉自己的项目“AI含量”很低，不清楚方向是否正确，希望我能提供一个概括性的说明帮助他快速理清思路。

实际上，开展AI项目必须具备全局视野，清晰定位自己正在涉足哪种类型的AI项目至关重要。我们曾对所有AI项目进行过系统性的分层解析，不同类型的项目在实施难度、成本投入以及核心卡点上存在显著差异，因此所需的能力模型也截然不同。

结合过去两年服务多家公司的实践经验，当前企业需要重点关注的AI项目主要可以归纳为以下三类：

1. 工作流AI；
2. AI客服；
3. 多意图、多轮知识问答系统。

如果你对团队正在推进的AI项目属于哪一类别毫无概念，那就需要引起高度重视了。AI项目往往具有一种“看似简单，实则精妙”的特性，如果底层的方法论出现偏差，后续将不可避免地走上许多弯路，这些就是所谓的“AI项目试错成本”。

例如，去年我们曾为某公司部署了一套AI客服系统，初期效果显著，效率大幅提升，以至于该公司直接裁撤了整个客服团队。然而，后续他们在自行迭代系统时，不慎破坏了原有的架构设计，导致系统出现问题后，由于没有人工客服可以应急补位，造成了重大损失。最终，他们不得不重新召回部分客服人员以备不时之需。

这些经历都是宝贵的“学费”。为了避免大家重复缴纳这些学费，接下来我将分享一些私密的实战心得。

工作流AI：数字化与流程优化的核心

在近两年专注于“AI+管理”的实践过程中，我接触了超过三十家企业，并深度服务了其中十余家，共主导完成了23个AI项目。值得注意的是，其中有18个都属于标准的工作流AI项目。

这意味着，近80%的企业需求都指向了工作流类AI项目！

面对这个结论，不少朋友会心生疑问：这也能算AI项目？

他们发现，这类应用的重点和难点，几乎完全集中于梳理工作流程、制定标准作业程序（SOP） 上，而AI技术在其中所占的比重，有时甚至不足20%。

于是，有人怀疑自己的“打开方式”不对，转而尝试采用类似“智能体（Agent）”的架构，试图让AI自主感知、规划并执行任务。这样一来，系统的复杂度是上去了，但实际表现往往显得笨拙而不实用。

为了提升效果，他们不得不在提示词（Prompt）设计上投入大量精力，甚至尝试将完整的SOP“口述”给AI，结果依然不尽如人意，最终感到气馁：所谓的智能体，还不如规规矩矩的工作流好用，费这么大劲图什么呢？

以上这些，正是工作流类AI项目面临的标志性问题。处理这类项目时，必须深刻理解其内核：这类项目的本质是推动企业数字化，流程梳理自然是重中之重，没有必要人为地增加技术复杂度。

从企业的视角来看，他们真正需要的是一套能够实现**“多人分散录入 → 集中汇总 → 统一分析”** 的轻量级系统。这块市场过去由Excel、OA、低代码平台等工具争夺，而当下竞争尤为激烈的，是飞书多维表格与钉钉AI表格这类新兴生产力工具。

所有这类项目的难点都不在于技术开发，而在于梳理SOP与沉淀行业Know-How。其背后折射出的核心理念是“数据即流程”。同时，企业始终追求低成本、快上线，哪种工具生态系统能够最好地满足这些诉求，企业就会选择它。

因此，这类项目的核心是流程重构与优化，在整个系统运行中，AI的占比确实不重。甚至，将其严格归类为“AI项目”可能都显得有些勉强。

以最近在HR体系进行的一个AI赋能项目为例，AI的实际占比确实不足20%（图中蓝色部分为必须由AI处理的环节）：

所以，面对这类项目，最务实的做法就是老老实实地梳理工作流。最终选择用代码原生开发，还是利用AI表格等工具来实现，都可以根据实际情况灵活决定。这类系统的真正挑战，往往在于管理层面：

当然，这里也引出了两个值得思考的遗留问题： 第一，何时应该引入AI的泛化能力，以增加整个系统的灵活性，让我们的AI系统不仅能解决固定问题，还能像智能体一样，引导用户进行更自由的探索？ 第二，钉钉等平台提出了“AI表格助理”的概念，声称可以一键生成SOP，这是否意味着我们不再需要自行梳理SOP了？

关于第二个问题，答案是想得太简单了！除非有一天，Claude Code这类工具能够完全、准确地理解你的复杂业务需求，否则“AI表格助理”的基础恐怕都难以真正成熟。

第一个问题则相对复杂一些，我们稍后再做探讨。接下来，我们先明确一下工作流AI的实施方法论。

工作流AI实施方法论

前文粉丝的困惑，暴露的是项目实施层面的具体问题。我们除了要理解他直接提出的疑问，还应洞察其背后“隐藏”的关切：在企业体系内，究竟应该如何系统地实施工作流AI？ 这可以拆解为三个层次的问题：

1. 我们该如何决策优先用AI解决哪些业务环节？
2. 我们该如何推动实施，并说服管理层提供支持？
3. 最后才是粉丝遇到的、关于具体如何操作的执行层困惑。

实际操作起来，有一套简洁的口诀可循：先看预算再分拆，能用AI就AI。

• 先看预算：即全面梳理公司的各项业务，找出成本投入最高的部分，优先对其进行AI化改造。
• 再分拆：将目标业务模块的每个操作节点进行极度细致的拆解。可以参考如下示例：

或者这种形式：

如果需要向管理层汇报，则还需要完成三件事：

1. 将拆解后的流程节点中，需要用到AI技术的关键环节醒目地标注出来。
2. 分析该节点的现有成本结构。
3. 估算出利用AI实现该节点自动化或智能化的改造成本。

最终，你需要向决策者呈现一本清晰的“账本”：我们计划用AI具体优化业务的哪个环节，这个环节原先耗费了多少成本，而用AI改造它又需要投入多少资源？

相较于技术实现本身，能够有效说服老板、争取到预算，往往是项目前期更重要的一个卡点。

总结与展望

近来有读者反馈我的文章内容略显详尽，因此本次分享暂且到此为止。最后做一个小结： 工作流AI属于最为基础的AI项目类型，通常是顺手就能推进、成功率高且几乎必然带来效率提升的项目。对于企业的技术负责人而言，推广这类稳赚不赔的项目以提升自身影响力，是相当划算的选择。

当然，它的缺点也很明显：AI技术含量较低，不太具备“高科技感”。如果你希望挑战AI含量更高的项目，就不得不提到另外两大类型：AI客服与多意图、多轮知识问答系统。

AI客服：数据处理与准确率的博弈

AI客服属于入门级的AI应用，其核心在于相对简单的数据处理，多用于标准的一问一答场景。值得指出的是，在完成本体任务（即SOP执行）后，是可以引入类智能体的闲聊功能来增强体验的。

这类项目的难点同样不在于复杂的代码开发，而在于数据处理。由于问答逻辑相对简单，数据复杂度较低，技术上几乎不存在难以逾越的障碍。当前许多AI客服系统面临的最大挑战，其实是准确率。

• 如何将系统准确率从80%提升到90%？这主要是一个提示词工程问题。
• 如何从90%提升至95%？这就进入了数据工程的范畴。
• 如何从95%推进至98%？这需要构建有效的数据飞轮系统。
• 如何最终达到99.99%的极致可靠？这涉及到更复杂的快慢系统设计，此处不再展开。

多意图、多轮知识问答：殿堂级的系统工程

多意图、多轮知识问答则属于殿堂级的AI应用，其核心在于复杂的数据工程与思维链（CoT）设计。国内很多公司在这一领域都处于“心向往之，然力不能及”的状态。

关于钉钉AI表格与飞书多维表格在当前行业中所处的生态位及其核心目标，我们此前已进行过较为深入的探讨：

企业迫切需要一套能够实现 “多人分散录入 → 集中汇总 → 统一分析 → 按权限查询” 的轻量化系统。

过去，Excel、OA系统以及各类低代码平台都在争夺办公领域的市场份额，而目前表现最为突出的无疑是飞书多维表格和钉钉AI表格。

企业追求 “这套系统” 的原因十分明确：传统的协作方式效率确实过于低下。一旦引入合适的系统，效率的提升将极为显著。

然而，必须指出的是，这种效率的跃升并非完全由AI表格技术本身带来，或者说：

AI表格所带来的改进属于企业数字化转型过程的自然延续，其中AI技术实际贡献的比例并不高，通常仅占10%左右。

尽管只占10%，但这部分价值绝不能忽视，因为它构成了整体拼图的最后关键一块，对于实现系统功能的完整性具有重大意义。

此外，市场上还存在一些看似处于同一赛道的产品，如Coze、Dify、FastGPT等。实际上，它们与AI表格并非同一竞争维度：

AI表格具备真正替代传统OA系统的潜力，而Coze等平台则难以胜任。后者的应用场景更多地局限于简单的知识库构建或对话交互。

理解这一点需要我们从实际使用者——如HR、财务等业务人员的视角出发。他们通常并不青睐对话式交互体验，甚至可能有所排斥。他们早已习惯于Excel的操作逻辑，能够熟练地从一张表格中快速定位关键数据，且这一行为模式已相当固化。Excel才是他们真正意义上的“工作台”。

综上所述，在AI办公这一赛道中，体验上无限趋近于Excel的表格形态无疑是核心中的核心。基于这一基本认知，我们再来深入探究多维表格应用模式究竟是什么。

多维表格应用模式探析

此处直接引用官方定义进行阐述：

多维表格应用模式代表了一种创新的业务系统搭建方式。通过简单的拖拽操作，即可构建出专业级的业务系统，无需任何技术背景。业务人员也能快速创建出符合实际业务需求的交互界面与流程。

应用模式提供了面向最终用户的操作界面，而多维表格则提供了底层的数据库和运行引擎。一个应用可以关联多个多维表格文件，两者相辅相成，共同构成一个完整的业务系统。

坦率地说，基于我对AI表格的现有理解，初次接触这个定义时仍感到有些费解，因此决定亲自体验一番。于是，我直接打开了已有的多维表格文件，点击进入“应用”模块：

界面中呈现了丰富的组件库：

我们不妨设想一个具体功能：需要整理各种编程工具的评分（以星数为计），并依据星数多少进行排序。为此，我们选择一个柱状图组件：

初步尝试时遇到了一些配置障碍，不确定后续如何设置。于是，转而从官方模板库中选取一个现成模板进行学习。我们的需求与该模板颇为相似：

该模板的数据源名为“M1-团队业绩”：

由此看来，正确的做法似乎是：为原始数据源新建一张数据表，并将其中的文本描述转化为结构化数据：

在此基础上，我们再次尝试创建排序表格，结果立即成功呈现：

至此，相信各位对多维表格应用模式的本质已有判断：它本质上属于零代码编程的范畴，主要应用于基础数据就绪后的分析与展示环节，是 “多人分散录入 → 集中汇总 → 统一分析 → 按权限查询” 流程中，“统一分析与展示”模块的具体实现。

就个人观点而言，这项功能应被视为一项基础配置，其重要性并未达到网络上某些宣传所描述的“神乎其技”的程度。更重要的是，它所解决的问题，并非企业数字化转型实施过程中的核心痛点！

那么，企业真正的难点是什么？他们究竟缺少什么？

企业核心痛点与缺失环节剖析

大约在五年前，当时尚未出现多维表格这类工具（或我个人未曾接触）。公司曾面临一个令人极为困扰的需求：

公司需要与大量外部兼职人员协作进行数据整理，涉及流程极其复杂：

1. 每日内部人员需面试大量兼职者，单日数据过百后，缺乏系统支撑，操作现场混乱不堪；
2. 兼职人员初试通过后进入作业群，需实际完成一份测试任务，经内部员工评估合格后方可转为长期兼职；
3. 进入实际数据处理阶段后，又需经历 “提交→初审（通过或打回重做）→复审（通过或打回重做）” 的反复循环；
4. 每日结束时，需根据实际完成情况对数据进行归档并结算费用。

这是一套完整的标准作业程序工作流，执行周期仅三个月。专门开发系统不仅时间上来不及，后续的迭代效率也无法满足需求。

由于经常遇到有人擅自修改数据且无操作日志可查的情况，我个人感到十分困扰。同时，由于缺乏有效的消息通知机制，流程节点常常被卡住。为此，公司曾调配三名项目经理进行协调，但实际执行中依然问题频发……

其实，这里的核心需求非常简单：在Excel的基础上，增加权限控制（视图控制）功能，并在数据更新后触发定向通知即可。

然而，正是这样一个看似简单的功能，在多维表格问世之前，我一时之间竟束手无策！

以上案例真实地回答了企业缺失什么以及为何不自行开发的问题。从中亦可看出，企业真正需要的是一套能够快速组织数据与流程的工具。如果能用自然语言实现则更佳，因为梳理SOP本身就是一个繁琐的过程。

根据以往项目经验，完整实施一套中等复杂度的AI工作流系统大约需要三个月。其中，两个月时间都用于与企业共同梳理业务流程。流程梳理的产出通常包括两项关键成果：

SOP流程图以及对应的数据结构。这两者便是我们所谓的 “AI时代的自然语言” ，其形态如下所示：

对于热衷游戏的玩家而言，电脑硬件配置至关重要，更高的配置通常意味着更流畅的帧数和更佳的游戏体验。为了追求极致性能，许多用户会选择超频，但这一方法不仅存在技术门槛，还可能对硬件造成损害。因此，本文将介绍一种更为安全、简便且高效的方案，助力您优化系统性能并显著提升游戏体验。

这个方案的核心在于使用BoosterX系统优化工具。首先，您需要在电脑上安装BoosterX软件，安装过程十分简单。启动软件后，您将看到如下界面，默认语言可能是英文，但可以通过左侧工具栏的设置图标轻松切换为中文。

初次使用时，点击“开始优化”按钮，系统会提供两个选项：新手模式和专家模式。

在新手模式下，软件会提出一系列问题，您只需根据自身使用习惯进行回答，系统便会基于您的回答生成定制化的优化方案，从而针对性地提升电脑性能。

专家模式则直接进入详细的设置界面，除了涵盖大量基础选项外，还包括电源优化、系统精简、垃圾文件清理、禁用自启动程序等功能。此外，虽然部分高级功能需要付费解锁，但免费版本提供的工具已经相当丰富，足以满足日常优化需求。

根据个人需求完成所有设置后，只需点击左下角的“应用”按钮即可生效。

值得一提的是，BoosterX还集成了多种实用的应用程序功能，例如无需登录即可下载Windows商店免费应用和游戏的StoreX、网络延迟测试工具Latency Test、游戏模式优化工具GameModeX、CS2优化器以及Steam启动加速等。

更令人惊喜的是，BoosterX内置了Tweax AI服务，您可以选择问答模式进行咨询，或使用生成模式自动创建优化指令和代码，实现智能化的系统调优。

此外，软件还提供云端备份功能，允许在多台设备间同步个性化设置，但此功能需要升级至Pro版方可使用。同时，BoosterX首页的组件布局也可以在设置界面中自由调整，您可以根据喜好重新排列，打造专属的操作界面。

从实际体验来看，BoosterX无疑是一款功能全面且界面设计时尚美观的系统优化工具。它易于上手，实用性强，通过深度优化能够大幅提升硬件资源的利用效率，并根据不同使用场景智能分配性能，从而有效改善游戏流畅度。如果您正寻求提升游戏帧数的解决方案，不妨尝试使用这款工具。

今年以来，我保持着每日阅读的习惯，涵盖了学术论文、行业报告以及国内外的技术文章。虽然大部分内容可能价值有限，但每周总能发现一两篇颇具启发性的文章，例如今天要讨论的这篇：《How I Won the Enterprise RAG Challenge》。

通读全文后，我认为其内容相当出色。以下是我结合自身实践经验与文章内容的一些总结与思考。

架构全景图

首先，让我们审视该系统的核心架构设计：

一个优秀的RAG系统实际上是一套精密的工作流程，更是一套智能决策系统。它在核心的“检索-生成”链条之上，增加了多个“路由器”和“优化器”模块（对于其必要性，我个人持一定的审视态度）：

1. 路由决策： 系统首先需要判断当前问题应该导向哪个最合适的数据源或处理路径。
2. 检索优化： 在初步获取相关文档片段后，系统需要进一步筛选、排序和精炼，以找出最切题的信息。
3. 生成定制： 最后，系统需要依据问题的具体类型和上下文，采用最具针对性的策略来生成最终答案。

接下来，我们将沿用Ilya文章中提出的“RAG洋葱模型”作为分析框架，从最外层的基础设施开始，逐步深入到核心的智能决策模块：

讨论至此，我们不得不再次回归到最基础的环节：数据准备。

任何RAG系统的最终效果，都高度依赖于输入数据的质量。因此，前文将核心仅仅归于检索和生成链条的观点，我本身便抱有疑问。其内在逻辑很清晰：稍微复杂一些的AI系统，其逻辑是相通的——数据工程的质量直接影响提示词工程的效果，而数据处理的质量又决定了数据工程的上限。所以，如果RAG前期数据处理不到位，无论后期如何进行优化和补足，整体效果都难以达到理想状态。

因此，将非结构化的原始文档（例如WORD、PDF文件）转化为干净、规整且易于检索的文本块，是至关重要的一步……

一、文档解析

文档解析是整个RAG流程的起点，也是最容易出现问题的环节。Ilya尝试了大约二十种不同的解析器后，得出了一个关键结论：不存在一种能够完美无损地解析所有PDF文档的通用解析器。

他遇到了各种各样的棘手难题：有些表格在扫描时被旋转了90度，导致解析后的文字完全混乱；有些图表由文本层和图片层混合构成，难以完整提取；甚至部分报告文件存在字体编码问题，视觉显示正常但复制出来的却是无意义的乱码符号。更极端的情况是，某些文档中的文本竟然使用了凯撒加密，需要特定的解码方式才能正确读取。

最终，他选择以Docling作为基础解析器。 为了应对某些复杂的解析场景，他不得不深入该解析器的源代码进行定制化修改，以确保其能够输出包含丰富元数据的JSON格式，进而生成高质量的Markdown和HTML文档。

这个过程揭示了一个必须正视的现实：在真实的RAG项目中，数据预处理往往消耗超过一半的总工作量，并且需要深厚的领域知识和工程技巧。

一个比较有趣的细节是，由于当时比赛时间紧张，他还利用了GPU来加速解析过程，租用了搭载RTX 4090显卡的云服务器。最终，一万多页共计100份年报的解析任务耗时约40分钟，这充分展现了工程化思维在效率提升上的价值。

然而，在实际的工作场景中，我们通常不建议采用这种“特殊操作”。首先，不建议轻易修改第三方解析器的核心源码，这会给未来的维护和升级带来巨大挑战。其次，若非必要，也不建议过度追求极致的解析速度，因为项目时间往往相对充裕，人为增加技术复杂度会提升系统的移交和协作成本。

在真实的文档处理过程中，你一定会遇到各种意想不到的“奇葩”问题。这里没有捷径可走，唯一的方法就是“逢山开路，遇水搭桥”，一个个地解决这些小问题。 每个独立的问题通常并不复杂，很少会出现耗时两天都无法解决的情况。这里的关键在于尽早发现并暴露问题，而不是掩盖问题。

二、向量化

文档被成功解析后，需要被切割成更小的“块”（chunks）才能存入向量数据库。此处的分块策略变得尤为关键：

为了在检索精度和上下文完整性之间取得平衡，Ilya采用了递归分块法，设置了300个token的块大小，并辅以50个token的重叠区域。这种策略确保了语义单元的完整性，同时避免了因单个块过大而导致关键信息的相似度被稀释的问题。

在系统设计上，他进行了长远规划：为每一份独立的文档（例如每家公司的年报）建立专属的向量数据库。这背后是出于效率的考量：当用户的问题明确指向某一家特定公司时，仅在对应的单个向量库中进行搜索，其准确性和速度都远高于在一个混合了所有公司数据的庞大向量库中进行全局搜索。

这一设计实际上引入了“路由”概念的雏形：在正式执行检索之前，先确定搜索的目标范围。类似的思维策略在国内也有应用，例如树形索引结构也能很好地保持不同语义集合的独立性：

三、检索与重排

检索是RAG系统中的“R”（Retrieval），是整个系统的脉络所在，也是检验前期数据准备工作好坏的核心标准。如果检索器无法找到正确答案，那么后续的所有步骤都将失去意义。

从理论上讲，结合语义搜索（基于向量相似度）和关键词搜索（如BM25）的混合检索策略，应当能够提升检索效果。

但Ilya的实践经验表明，在未对用户查询进行深度优化的情况下，简单的混合检索有时甚至会导致性能下降。这说明，先进的技术需要正确的使用方式与之匹配，否则可能适得其反。

根据过往的经验，这里一个比较实用的技巧是查询重写。事实上，一个健壮的系统应该拥有一份自己预期的问题准入清单，或者说一个简单的“意图识别”模块。如果你没有这样一份清单，说明系统设计可能不够健壮，即使用户重新措辞提问，也未必能检索出正确答案。

检索完成后会得到一个候选文本列表，接下来便是重排技巧的用武之地。Ilya的做法是：

1. 首先通过向量检索初步召回30个相关的文本块。
2. 利用这些文本块的元数据，定位到它们所属的原始页面。
3. 将“用户问题 + 页面完整文本”交给LLM，要求LLM根据该页面内容对回答问题的帮助程度进行打分（0-1分）。
4. 将LLM给出的分数与原始的向量搜索相似度分数进行加权融合，最终筛选出最相关的10个页面。

为了加速重排过程，Ilya让LLM一次同时对三个页面进行评分并返回三个分数。这样，邻近的文本可以互相作为参照，有助于提高评分的一致性和整体处理效率。最终，系统结合向量相似度分数和LLM的评分来计算修正后的相关度，例如设定向量权重为0.3，LLM权重为0.7。

这种方法的好处显而易见：它以一种相对低廉的成本（据称每次查询低于1美分），极大地提升了输入给生成模型的上下文材料质量。只要前期数据质量过硬，经过这样筛选后的上下文，必然能引导模型输出更高质量的答案。

然而，只有在实际采用这种重排策略时，你才会真切地感受到企业决策者（如“老板”）对这部分额外token消耗的在意程度。在很多实际场景中，效果和成本往往难以兼顾，除非在更前端的数据工程层面投入更大的功夫。换句话说：

越是复杂和精细的数据工程处理，往往能支撑起更简化、高效的AI应用工程，最终以更低的成本换取更优的前端用户体验。

四、路由与生成

这一部分是其方法论——RAG洋葱模型最核心的体现，需要大家特别留意。这也是许多大型AI项目背后的架构设计思路，也是我推荐这篇文章的主要原因——它已经勾勒出了这类复杂系统的雏形。这里的核心理念是：

通过智能路由，让每一个问题都能被导向最合适的处理路径。

路由是简化问题复杂性、提升系统效率的最有效手段之一。Ilya的系统中设计了两个关键的路由器：

1. 数据库路由： 根据问题中出现的公司名称，直接将查询路由到该公司对应的专属向量数据库。这个策略看似简单（甚至可以用正则表达式实现），却能将搜索范围从100份文档急剧缩小至1份，带来了检索性能和答案精度的双重显著提升。事实上，前文提到的按页面建立索引的思路也与此异曲同工：

2. 提示词路由： 比赛要求答案必须遵循严格的格式（例如纯数字、布尔值、特定字符串等）。Ilya没有将所有格式规则塞进一个庞大而复杂的通用提示词中，而是为每一种答案类型设计了专用的、高度定制化的提示词模板。系统通过简单的逻辑判断（如if…else）来识别问题所属的类型，然后动态选择并注入最合适的提示词，确保LLM能够清晰无误地理解并遵守特定类型的输出要求。

10月22日，百川智能发布其号称最强循证增强大模型M2 Plus，该模型被喻为“医生版ChatGPT”。评测数据显示，M2 Plus在医疗场景下的幻觉率较通用大模型显著降低，与DeepSeek相比降低了约三倍，其可信度表现甚至优于美国热门的医疗AI产品OpenEvidence，达到了堪比资深临床医生的水准。

此次发布中，有两个关键词尤为值得关注：OpenEvidence 与 幻觉率（尤其是相较于DeepSeek）。新模型的核心目标直指降低幻觉率，而其选择的技术路径与对标的标杆产品，正是OpenEvidence。

OpenEvidence在今年的垂直领域Agent赛道中无疑是明星产品，备受赞誉。例如，在之前的红杉资本闭门会议上便有观点指出，在企业级市场，真正的入口或许并非通用大模型，而是如Harvey（法律）、OpenEvidence（医疗）这类深植行业的垂直智能体操作系统，因为它们能真正理解行业术语与实际需求。

由此，百川智能的战略意图变得清晰：其目标是将自身打造为国内版的OpenEvidence。因此，我们有必要深入剖析一下这位“资本宠儿”——OpenEvidence。

OpenEvidence 的产品定位

当前AI领域新品与论文层出不穷，对于需要持续跟进前沿动态的人士而言，筛选有效信息已成为负担。医学领域同样面临文献爆炸式增长的挑战，顶级期刊的文献量大约每五年就会翻倍。传统检索工具效率低下，而AI搜索虽能提升效率，但其固有的模型幻觉问题在关乎生命的医疗场景中风险极高。

正如相关研究《Why Language Models Hallucinate》所指出的，幻觉从模型设计之初便难以根除。一旦发生，可能引发严重后果。此前，在查询某知名科技公司相关争议案例时，一些通用模型可能会生成细节完备但完全失实的“案例”，这对于内容创作者尚难以接受，更遑论可能直接影响患者诊疗决策的医疗信息。

为此，OpenEvidence提出了以证据驱动为核心的理念。其通过实时、智能地检索权威医学文献来生成答案，从而规避幻觉。该平台的核心理论是来源可靠、可追溯。它严格采用经过同行评审的医学研究及权威指南作为知识来源，避免直接抓取未经筛选的网络信息，并承诺 “每个回答都有出处”，所有结论均基于可信的医学证据提供支持。

这一设计思路精准地诠释了当前构建专业AI知识库的重点：并非盲目扩展模型的多模态等通用能力（这些领域竞争激烈且易被取代），而是专注于弥补模型在特定领域的专业知识（Know-How）和数据深度上的不足。这一点可参考百川智能的相关图示。

OpenEvidence主要服务于医疗工作者，特别是临床一线的住院医师、门诊医生以及实习/规培医生。之所以聚焦一线，是因为资深专家通常经验丰富且有助理协助处理基础信息工作。实际上，国内也有类似产品为院内医生提供服务，但往往在系统性与精细化程度上有所欠缺。

根据已披露的数据，OpenEvidence目前覆盖了超过一万家医疗机构，声称每日有数十万医生使用，已成为历史上增长最快的医生端平台之一。从产品设计理念上看，其方向无疑是正确的，且构建了极高的行业壁垒。然而，这条路径面临一个巨大挑战：数据积累的成本极高。在OpenEvidence验证此路可行之前，其他公司或领域大多不敢轻易尝试。

如今，OpenEvidence的成功，无疑为整个AI行业指明了一个技术方向，并增强了业界在数据工程上持续投入的决心。

OpenEvidence 的行业意义

如前所述，要构建能够处理多意图、多轮复杂问答的专业级数字分身AI项目，极度依赖于高质量的数据建设。从成本结构分析，这类项目中，大约20%的投入在研发，而高达80%的费用则花在数据层面。因此，企业在投入前必须看到成功的标杆案例。OpenEvidence恰恰提供了这样一份令人满意的答卷。

OpenEvidence成立于2022年，产品于2023年发布，并在2025年迎来爆发式增长，其融资历程清晰地反映了市场的认可：

1. 2025年2月（A轮）：由红杉资本领投，融资约7500万美元，公司估值超过10亿美元。
2. 2025年7月（B轮）：融资2.1亿美元，估值跃升至35亿美元，累计融资额超过3亿美元。
3. 2025年10月（C轮）：再融资约2亿美元，公司估值高达60亿美元。

值得强调的是，OpenEvidence的成功并非一蹴而就，其背后是持续的数据积累。根据相关行业研究，其早期便致力于从同行评审文献和官方指南构建知识库：2024年前已有高校图书馆将其列为学习工具；2025年通过与《新英格兰医学杂志》（NEJM）、《美国医学会杂志》（JAMA）等顶级期刊达成多年期内容合作，系统性地纳入了可回溯至1990年代的付费期刊全文历史库。

正是这些扎实的数据工作，支撑了OpenEvidence高质量的回答能力，使其来源可靠、可追溯的承诺得以落实。总而言之，OpenEvidence为AI行业开了一个好头，尤其是在被视为AI应用元年的当下。接下来，我们探讨其技术实现路径。

OpenEvidence 的技术路径

简而言之，OpenEvidence采用了RAG（检索增强生成）技术，并构建了一个多模型协作系统。

其工作流程是：系统首先从专业的医学数据库中检索相关文献（包括PubMed文章、FDA药品标签等），然后将检索到的证据内容输入定制化的医学大语言模型，生成附有文献引用的回答。这种做法正逐渐成为生产级AI应用的标准配置，能确保回答基于现有证据，有效降低模型“幻觉”风险。

特别值得一提的是其模型架构，这也是生产级AI应用的常见做法：采用多模型融合策略。系统并非依赖单一模型，而是使用一个模型集群，让每个模型专注于其最擅长的任务，如检索、摘要、问答、图表解析等，从而实现“术业有专攻”。

创始人Daniel Nadler曾强调避免使用单一大模型，而是采用一个各有专攻的模型集群。一个关键的细节是：他们也在自行训练专用模型，例如训练视觉模型来解析医学论文中的图表和表格数据。

这一点在其团队构成和融资用途中也有体现，资金被用于训练下一代医学领域专用大语言模型，并组建顶尖的交叉学科团队。具体技术思想可追溯到2023年的论文《Do We Still Need Clinical Language Models?》，该研究实证表明，小型、领域专用的临床模型在多项临床文本任务上可以胜过参数量大得多的通用大模型。

当前公开的详细信息有限，但可以推断其模型训练重点在于：

1. 在自建权威文献库中精准检索**“对临床问题最相关”的证据条目，核心优化目标在于控制成本与提升响应效率**，而不仅仅是追求极致的模型能力。
2. 进行视觉模型的相关训练，以补足当前大模型在图像理解方面的短板。例如，在眼科等领域，使用一万张专业图片进行微调即可获得显著效果，而以往厂商可能因投入产出比不高而缺乏这类细分领域数据。

至于引用链的构建，在医学知识库完备的情况下相对直接。真正的难点在于构建符合医疗逻辑的思维链（CoT）。这需要数据工程与AI工程的无缝协作。简而言之，OpenEvidence的“医疗逻辑”采用证据锚定式解释，而非开放性的自由联想。

例如，在临床决策支持场景，其逻辑是：简短结论 + 关键要点 + 强制引用支持，若无可靠证据则直接拒答；在教学解释场景，其逻辑是：清晰展示推理依据。综上，OpenEvidence以RAG技术为骨架，使用受控的高质量语料库，并通过自研的小模型将每一步推理牢牢绑定回证据源，从而最大限度压低幻觉率，并保证结果可复核。

这大致是其技术路径，也为其他行业的专业AI应用提供了可直接参考的范本。

OpenEvidence 的实际使用

目前，OpenEvidence的核心功能是作为医疗智能问答与检索工具，通俗讲就是面向医生的AI问诊助手。在这方面，国内的MedGPT、左手医生、百川智能等也都有不错的表现。典型的使用体验是：医生输入具体的病情描述或临床问题（如诊断疑问、治疗方案对比、药物副作用、检查流程等），系统从医学知识库中提取关键信息，生成答案并提供参考文献链接。

与传统静态知识库不同，AI在整合海量专业知识方面能力突出，因此被医生们誉为“口袋里的专家小组”。适用场景包括：

1. 查询罕见并发症、疑难杂症的最新处理方案与指南。
2. 紧急情况下，快速通过手机应用询问药物精准剂量或替代方案。

虽然OpenEvidence初期用户定位于医学专业人员，但其模式可以很快扩展至消费者端（2C）。并且，其商业模式不担心高昂的Token费用，因为历史上已有成功的买单方。

OpenEvidence主要采用免费 + 广告的盈利模式。凭借免费、专业、易用的特点，它在医生群体中口碑传播极快。数据显示，其每月约有6.5万名新的美国医生注册。巨大的流量自然带来了医疗相关广告的营收，这构成了公司的主要收入来源。据第三方机构Sacra估算，截至2025年6月，OpenEvidence的年化营收约为5000万美元，毛利率高达约90%。

无论从用户评价还是财务数据看，OpenEvidence都展现出了巨大的潜力。至此，我们已对OpenEvidence有了较为全面的了解，再回头审视百川智能的此次发布，其脉络就非常清晰了。

百川智能的“医生版ChatGPT”

从百川智能官方披露的信息来看，其强调的重点同样是攻克模型幻觉难题。为此，他们推出了六源循证推理范式，其逻辑与OpenEvidence高度相似，核心在于对医疗数据进行精细化的分层治理：

1. 原始研究层：索引超过4000万篇医学期刊论文，覆盖基础与临床研究成果。
2. 证据综述层：整合系统评价和Meta分析等高等级证据。
3. 指南规范层：引入国际与国内权威临床指南、专家共识。
4. 实践知识层：包含临床病例、一线专家经验等实用知识。
5. 公共健康教育层：汇集权威疾病预防与健康科普内容。
6. 监管与真实世界层：涵盖药监公告、临床试验及真实世界研究数据。

在构建RAG（检索增强生成）系统的初期，有一个几乎与之绑定的概念：向量库。那么，它究竟是什么？

从理论上讲，向量库是一个颇具吸引力的概念。它是一类专门用于存储和检索向量化数据的系统。理解其核心，需把握两点：

1. 向量：通过Embedding模型，将文本、图像、音频等内容编码成高维度的数值数组。
2. 检索：当给定一个查询向量时，系统能够快速找出与之语义最相似的前K个数据项，并可以关联返回原始的文本片段等信息。

因此，关键在于：向量库实现的是语义相似性检索，而非传统的关键词匹配。 例如，搜索“苹果”，传统关键词搜索不会返回“iPhone”，但向量库却可能将其检索出来。这曾令人兴奋，似乎意味着我们正从“关键词查询”迈向“语义查询”的新阶段。

然而，早期模型的能力存在局限。大语言模型的上下文长度有限，而主流的文本嵌入模型最佳编码长度也多在500个词元左右（范围在256-768之间，近期虽有提升至约8000词元的模型，但非主流）：

1. 文本过短：可能导致信息不完整，Embedding无法充分表达原意，从而难以匹配。
2. 文本过长：单个向量需要概括过多信息，核心语义可能被稀释，在相似性搜索中不易被选中，即所谓的“信息淹没”问题。

这与当时大模型的上下文限制恰好吻合。因此，在RAG的早期实践中，向量库几乎是标准配置。诸如Coze、Dify、N8N等低代码Agent平台也默认集成了向量库功能，这在某种程度上给许多从业者造成了一种“烟雾弹”效应，认为它是不可或缺的。

但在实际应用过程中，人们逐渐发现向量库检索常常“玩不转”，其最核心的问题是检索结果的“断章取义”。要理解这一点，我们需要对其底层逻辑进行剖析。

传统RAG的局限

传统基于向量库构建知识库的流程，从底层逻辑上看较为粗糙：

1. 切分：将长文档进行机械式分块。
2. 向量化：把每个文本块映射为高维空间中的向量。
3. 检索：将用户问题转化为向量，并在向量空间中查找最接近的若干个文本块。
4. 拼凑：将这些检索到的文本块作为上下文，一并提交给大语言模型，要求其生成最终答案。

如果原始文档本身很长，而分块过程又是不可控的，就会引发一系列问题，其中最典型的是上下文割裂：

• 分块可能粗暴地切断表格、割裂连贯的论证逻辑，导致信息丢失。

案例一：电商场景 在电商“退款助手”场景中，用户询问“退款多久到账”。如果RAG系统只检索到包含主条款“T+1到账”的文本块，而遗漏了下一文本块中“黑名单用户或已发货订单除外”的关键例外条款，助手可能回答“一律T+1”。这可能导致对高风险订单进行误退款操作。

案例二：医疗场景 在临床指南应用中，若按固定段落切分，可能导致某种降压药的“适用症”与其关键的“妊娠期禁用”警告被分隔在两个不同的向量块中。当医生询问“孕妇高血压能否使用某某地平？”时，系统若仅检索到“适用症”块，则可能生成“该药可用于治疗高血压”的错误建议，存在严重安全隐患。

于是，从业者开始反思：所谓的语义检索，有时反不如精确的关键词检索可靠。 随着大模型技术的进步（上下文窗口不断增长），向量库在RAG系统中的角色变得越来越尴尬。

当然，将RAG效果不佳的责任全部归咎于向量库并不完全公允。很多时候，效果差是因为数据处理（尤其是切分策略）过于粗糙。人们最终意识到：语义相似性只能解决部分问题，要准确表征真实世界，我们需要完整的数据关系网络。 换言之，我们不仅需要数据点，更需要数据点之间的关联。例如，提到“苹果”，系统应根据上下文联想到“iPhone”，并进一步关联到“乔布斯”等相关实体。

这便引出了今天的主角——知识图谱。事实上，在复杂的AI知识库应用中，更常见的是结合了关键词、向量检索等多种技术的**“伪知识图谱”**方案。

知识图谱：结构化的关联网络

知识图谱与知识库概念相似，可以认为知识图谱是知识库的一种高级、有机的表现形式。逻辑上，通过在知识库中建立实体间的关系链，就能形成图结构。

具体而言，知识库侧重于知识的组织、存储与管理；而知识图谱则在此基础上，通过图结构（实体、关系、属性）来显式地呈现知识内在的关联与结构。

知识图谱通常包含三大核心要素：

1. 实体：图中的节点，代表现实世界中的具体事物、抽象概念等。
2. 关系：连接实体的边，描述实体之间的相互作用或联系。
3. 属性：描述实体或关系的特征或详细信息。

通过这种标准化的表示，知识图谱不仅能展示关联，还能支持语义分析与推理。它为我们提供了一种更直观、更具结构性的知识管理和呈现方式。

更通俗的理解是：图谱强制要求将知识按照“实体-关系-属性”的框架进行结构化。二者之间的界限有时比较模糊。

为了便于理解，这里提供一个对比案例。首先是无显式关系的知识库表示：

疾病: {
  名称: “糖尿病”，
  类型: “慢性疾病”，
  并发症: [“心血管疾病”， “肾脏病”， “神经损伤”]
}
症状: [
  { 名称: “口渴”， 常见疾病: “糖尿病” }，
  { 名称: “频繁排尿”， 常见疾病: “糖尿病” }，
  { 名称: “体重下降”， 常见疾病: “糖尿病” }，
  { 名称: “疲劳”， 常见疾病: “糖尿病” }
]
药物: {
  名称: “胰岛素”，
  类型: “药物”，
  用途: “控制血糖”，
  使用方法: “注射”
}

然后是具有显式关系的知识图谱表示：

整个2025年，真正运行良好且持续稳定消耗Token的Agent品类，AI编码工具当属其一。它不断地向我传递一个信号：编程时代的终结，或许比我们预想的要更早到来。

在实际场景中，我身边许多非计算机科班出身、不懂代码的朋友，已经能够借助AI结对编程，成功将产品开发并上线。

代码，长久以来被视为世界最底层、最本质的逻辑真相。因此，AI编程自然成为各大模型厂商竞相布局的关键赛道。几乎每一次基础模型的重大更新，都在AI编程能力上带来显著跃升，持续刷新我们对这项技术边界的认知。

几个月前，我仍持有这样的观点：AI在编程领域主要扮演辅助角色，无法完整实现复杂的业务需求，对整体开发效率的提升可能不足30%。 像Cursor这类工具，其核心用途也集中于Tab键自动补全、代码解释以及局部功能函数的实现，很少让其承担完整需求的开发工作。

然而，随着模型能力的持续迭代，特别是Claude 4.5和Claude 4.6 Opus等强大模型的出现，我的认知被逐步颠覆。如今，AI编程已成为编码工作的主力军。在日常开发中，我们已很少手动编写代码，大约90%的代码都由AI生成。我们的工作重心，更多地转向需求描述、任务拆解、架构设计以及代码审查等领域。

本文旨在分享当前主流的AI编程工具与模型选择策略，并结合个人实践经验，总结出一些实用技巧，以帮助各位开发者更顺畅地迈入AI编程的新阶段。

编程工具概览

下表列举了国内外主流的AI编程工具，它们主要以集成开发环境（IDE）、命令行界面（CLI）或编辑器插件等形式存在：

在众多工具中，Cursor以其出色的综合表现获得广泛认可，是开发者日常使用的主力工具之一。对于偏爱命令行的开发者，Claude Code和Codex也极受欢迎。

此外，国内也有一些优秀的AI编程工具，例如字节跳动的TRAE和阿里的Qcoder。它们使用门槛相对较低，无需特殊网络配置即可访问，但通常无法调用Claude系列的模型。

AI编程工具的演进方向，大致经历了从最初的编辑器插件，到独立的集成开发环境（IDE），再到如今备受青睐的命令行界面（CLI）。目前，我们基本不再优先考虑使用插件，因为其能力受宿主编辑器的限制过多。当前更主流的方式是采用独立的IDE或CLI工具。

自Claude Code引爆市场后，众多AI编程工具相继开始支持CLI模式。那么，CLI相比IDE具备哪些优势呢？

1. 无头化（Headless）与通用性：CLI更加通用，在任何具备命令行环境的地方均可运行。
2. 较低的开发维护成本：对于工具厂商而言，开发插件需要适配多种主流编辑器；开发独立IDE则过于复杂笨重。且开发者通常有自己偏好的编辑器，迁移成本高。CLI模式有效规避了这些问题。
3. 更佳的上下文感知与结果反馈：CLI能更好地感知命令执行结果，便于AI进一步生成、修复或优化代码。

那么，有了CLI，是否就不再需要IDE了呢？

答案是否定的。对于开发者而言，通常是两种方式结合使用。当然，具体组合方式可根据个人喜好自由搭配，例如，我日常使用 Cursor + Claude Code，你也可以选择 Codex + Claude Code。

CLI更适合全程由AI主导、人为介入较少的场景，尤其适合处理复杂任务。而IDE则能提供更优的开发体验，其可视化操作界面更加直观，更适合需要人工深度介入的场景，例如：

1. AI生成代码后，需要进行人工审查时，可利用编辑器的对比分析视图，便捷地核验代码逻辑是否符合预期，并决定接受或拒绝单文件的修改。
2. 进行局部修改时，如仅需调整某个函数中的几行代码，可以直接在Cursor中选中对应行并添加上下文，指示AI进行精确修改。
3. 需要手动微调某些代码逻辑时。

因此，最佳实践是在Cursor这类IDE中，同时打开命令行终端使用Claude Code等CLI工具，实现高效协作。

对于新手或希望体验“感觉编码”（Vibe Coding）的开发者，无需过度纠结于工具孰优孰劣，选择一个能快速上手使用的工具即可，例如Trae、Qcoder等。

编程模型选择

综合评估当前主流模型，可以从能力、价格与适用场景三个维度进行权衡与决策：

• 能力排名：整体表现上，Claude Opus 4.6 最为强劲，其次是 GPT 5.3 Codex，再次是 Claude Sonnet 4.6。
• 价格梯度：GPT 5.3 Codex 成本最具优势，Claude Sonnet 4.6 居中，Claude Opus 4.6 最为昂贵。

基于能力与成本的平衡，建议采用以下模型使用策略：

1. 日常开发与主流任务：优先使用 GPT 5.3 Codex 或 Claude Sonnet 4.6。
2. 高复杂度推理或困难任务：直接使用 Claude Opus 4.6。
3. 前端复杂UI交互实现：可考虑使用 Gemini 3 Pro。

目前，编码能力最强的模型序列仍是Claude 4.6系列。如果条件允许，直接使用顶流模型可以减少大量的调试和修复成本，事半功倍。

在10月6日召开的OpenAI DevDay 2025上，OpenAI出乎意料地推出了一款名为AgentKit的产品。该产品旨在帮助开发者以更少的时间和精力，完成从原型设计到生产部署的全过程。简而言之，OpenAI打造了一套工作流编排工具，其本质是一个低代码平台。

随后，LangChain创始人直接表示，可视化工作流构建器用处不大，谁愿意做就去做。原因有很多，核心在于 “拖拽式操作不利于复杂工程” 。更直白地说，就是门槛太高：专业程序员可能看不上，而普通用户又用不习惯，导致两边都不看好。

然而，凭借OpenAI巨大的行业影响力，其 “直接竞品n8n” 受到了不小的冲击。因为没过两天（10月9日），n8n就宣布完成了1.8亿美元的融资。因此，在n8n的融资关键期，AgentKit这个 “竞品” 横空出世了。虽然OpenAI自身可能并不认为AgentKit是n8n的对手，但我认为n8n确实被OpenAI的这次发布打了个措手不及。毕竟，风险投资人未必都精通技术细节，在那个节骨眼上，n8n团队必定准备了大量的说辞，最终才如释重负地拿下了融资。

紧接着，在10月13日，n8n似乎按捺不住，将可能“压箱底”的新功能AI Workflow Builder公之于众，继续**“回应OpenAI”** 。他们传递的核心信息是：别再卷工作流的拖拽操作了，以后甚至不用再手动梳理工作流，直接用自然语言描述，就能自动生成n8n工作流！

那么，这是否意味着竞争的重点已经转向了“自然语言生成工作流”这条新赛道呢？

自然语言 → 工作流

事实上，AI Workflow Builder并非首个提出用自然语言生成工作流的玩家。Zapier在更早的10月3日已经上线了AI生成工作流大纲的功能。在Zapier的控制台中，用户可以用自然语言描述“当X事件发生 → 执行Y操作 → 再做Z处理”。系统会据此产出一个包含触发器与若干动作的草稿大纲，之后用户可以进入编辑器进一步细化。

Make也在其公开的产品路线图中强调了AI辅助构建，目标是通过一句描述目标的语句，让AI助手为你搭建一个场景（Scenario）的基本骨架，并且能够解释该场景如何运作，甚至帮助你排查错误。

离国内用户更近的一个例子是8月25日钉钉提出的AI表格助理，其背后目的同样是大幅降低搭建工作流的难度。钉钉AI表格助理正式上线后，用户只需通过自然语言对话描述想法，它就能按要求自动生成AI表格、自动化工作流以及数据分析仪表盘，从而创造出一个个真正可用的AI应用。这极大地降低了AI表格的使用门槛，让每个人都有可能成为AI应用的创造者。

上述案例都应归属于同一种思路：在积累足够数据的前提下（例如已经拥有大量HR招聘工作流的提示词或编排数据），采用智能体（Agent）的思路来降低专业知识的转化成本。不过，从各方面的评测和反馈来看，整体效果目前还比较初级。这紧接着引出一个问题：为什么“AI Workflow Builder”这类工具会存在？

AI Workflow 的意义

先说结论，对于普通用户而言，核心痛点在于：工作流太难搭建了！ 像n8n这样的工具更偏向程序员使用，对产品经理都不算友好。而像Coze这样的平台对产品经理友好了，但对于医生、律师等非互联网行业的专业人士来说，依然存在障碍。这里的难点主要有两个：

第一，工具本身的使用繁琐。就我个人体验而言，掌握Coze、n8n并不算难，但也花了近两周时间熟悉它们的各种功能和组件。在完全熟悉之前，虽然没有遇到无法解决的技术卡点，但整个过程确实非常耗时。例如，为了弄懂Coze中的循环逻辑，我就花费了大约两个小时。

第二，梳理标准作业程序（SOP）极其麻烦，这才是真正的难点。只要是工作流类的AI应用，其价值核心往往取决于工作流的数量和质量。而这又带来两个挑战：一是需要对相关工种业务有基本理解；二是团队在实际沟通过程中往往需要反复磨合，非常耗费精力。下图是我们梳理的一个HR工作流示例，可以直观感受其复杂性：

接下来，让我们集中注意力，一起推演一个更深入的演进逻辑。这部分内容通常在我的AI培训课中作为付费内容讲解，为了便于大家理解，这里以医生为例进行说明（律师、教师等其他专业领域的逻辑是相通的）。

AI数字分身的演进逻辑

假设你是一名拥有十年经验的心内科医生，大学期间的专业是计算机科学（并且水平相当不错，这些年偶尔接点技术副业）。于是，你同时具备了深厚的医学专业知识与扎实的工程技术能力。

你医术高超，一天能接诊100名病人。但由于名声在外，实际想找你看病的患者超过1000人。其中，超过900名患者的问题非常基础，根本不需要你亲自处理。

于是，你拿起技术的武器，为自己的日常工作搭建了一套工作流AI系统，并为其设计了专用的数据结构（或者说运用了上下文工程），将自己心内科的专业知识结构化地融入了进去。

这个心内科数字分身上线后广受好评，它出色地解决了你90%的患者咨询。随后，你的妻子（一名眼科医生）、你的小舅子（一名神经内科医生）甚至你的朋友（一名心理科医生）都希望使用这套系统。

于是，你开始进行抽象化工作：将你的工作流逻辑与具体的心内科数据进行剥离，只保留一个基本的智能体（Agent）框架，用于承载工作流代码（通常是JSON结构）和新的数据。最终，你实现了一个类似于Coze的系统，交给了他们使用。

然而，你的妻子、小舅子和朋友并不买账。他们认为你这个想法太“技术直男”了——那种复杂的拖拽式工作流编排，他们哪有能力完成？更何况还要整理那么多结构化的数据，这简直是要命的工作。

在他们的不断督促下，你不得不对系统进行进一步的简化，核心目标有两点：

第一，让普通人能够通过更自然的语言描述来生成工作流。 但大语言模型并没有那么聪明。无奈之下，你不得不为每个科室预先创建了数十套常见的工作流模板。这样，当你妻子这样的非技术用户用自然语言描述需求时，模型就能根据这些模板，尽可能准确地生成对应的工作流JSON配置。

第二，让普通医生能够上传他们容易获取的数据（如医患对话记录、病历信息），然后系统自动生成AI所需的结构化专业数据。 为了实现这一点，你至少又做了两方面工作：首先，想办法利用自己积累的医患对话和病历数据，生成与你历史沉淀的数据格式相同的内容；然后，按照这套逻辑，为其他各个科室也生成基础的数据集模板，但允许医生在此基础上进行最简单的修改。

完成这两项改进耗费了你大量的精力。最终，当新系统交付给妻子他们使用时，你终于获得了一个“点赞”。这时你才深刻意识到：他们真的是一点多余的操作都不想有！

以上就是AI数字分身的演进逻辑，事实上，这也是从n8n式的工作流拖拽编排，演进到AI Workflow自然语言生成的底层逻辑。接下来，让我们看看n8n的实际情况。

AI Workflow 实测

在 n8n Cloud 界面中进入 AI Workflow Builder，用户可以在对话框中输入需求，系统会提供实时生成进度反馈，并且允许用户追加指令对已生成的工作流进行迭代优化。

注：当前 AI Workflow Builder 处于 Beta 测试阶段，使用自然语言指令会消耗一定的平台积分。

昨晚做了一个梦，又一次梦见了前老板老王。在梦里，我似乎是因为某个项目或汇报，再度被他劈头盖脸地训斥了一顿，随后便惊醒过来。或许是盖的被子太厚，竟热出了一身汗……

醒来后看了眼日期，才意识到大约两年前的这个时候，我正式提交了离职申请。当时的计划是休息调整一两个月，然后重返职场。然而，仿佛鬼使神差一般，我动起了念头：如今是AI时代，或许可以以半年为限，尝试自己做点事情。没想到这一试，便折腾到了今天。

如果要用一句话来概括这两年的感受，那便是：我无时无刻不在渴望能有一个老板。

独自创业，最大的好处是自由，因为无人管束；但最大的问题也恰恰是自由，同样因为无人管束。

当无人管束时，一切都需要你自己去寻找目的、定义意义、发掘项目、获取反馈。有一种说法是，创业之后，那些无谓的内耗和毫无意义的事务会减少，你不再需要去做自己眼中的垃圾工作。

然而与此同时，你做的每一件事，甚至包括“做这件事本身是否正确”这个判断，都需要由你来承担全部后果。在公司里，你通常只需要确保“过程正确”；而为自己做事时，你必须先确保“方向正确”，然后是“过程正确”，最后还必须达成“结果正确”。

这三者中任何一个环节出错，所有的投入都可能付诸东流。更何况，许多事情的深浅，不亲自尝试根本无法真正知晓。例如：有些看似大有可为的领域（比如制作视频）可能根本赚不到钱；有些我们认为门槛很低的方向（比如开发AI客服）反而可能是企业的刚需；而那些大家都在做的事（比如外包），往往演变为比拼销售能力和关系网络的生意。

另一方面，一旦脱离公司的体系，你的信息渠道必须从被动接收彻底转变为主动获取。过去在公司，微信消息提示音响起可能会让你烦躁；但自己单干后，手机一整天都静悄悄的，那种感觉可能更令人焦虑。因为，如果你不主动与世界建立联系，世界也一定不会主动来找你。

并且，真的再也不会有老板主动来批评你了。你曾经避之不及的严厉斥责，本质上都是一种反馈，虽然方式激烈，但通常有效。当然，也不会有老板来夸奖你，更不会有人给你发年终奖。

所有的正向反馈，都必须依靠自己持续进行心理建设来获取；每一分钱，都必须凭借自己的实力从市场中挣得。对于大多数人来说，或许真的算了吧，安心打工其实也挺好。

聊完了基本感受，再来谈谈我具体尝试的创业项目，也许能给正在创业或考虑创业的朋友带来一些启发。

B端创业：销售驱动的定制化困局

去年，我投身于一个AI与管理相结合的B端创业项目，对应的产品叫做CEO数字分身。它主要由两部分构成：

一套公司人效评估系统，加上一套AI表格引擎。这套系统旨在承载公司所有的降本增效业务，其形态与多维表格颇为相似。

我并非盲目行动。为了验证系统的可行性，我以产品/技术顾问的身份进入了两家公司，进行了为期数月的测试。最终的数据反馈都非常积极，都实现了100%的效率提升：

拿着这些成果咨询身边的朋友，虽然大家普遍不太看好，但也没有提出特别尖锐的否定意见。然而，到了实际销售环节，问题便暴露无遗：

中小公司的老板们似乎不太愿意为此买单，或者说，他们普遍不愿意为“管理改善”这类事项付费。

此后，我便陷入了AI to B这个领域的漩涡中，反复尝试、多方论证，最终得出了一个结论：

To B的软件、系统或服务，本质上是一门销售驱动的生意，极其依赖人际关系。这里的逻辑通常是：“你能不能做” 大于 “是不是轮得到你做” ，再大于 “你是不是做得好”。在大家水平相当甚至略有差距的情况下，只要产品达到及格线以上，最终往往比拼的是关系好坏。

其次，即便成功拿下项目，也几乎不存在标准化产品或纯SaaS模式的可能。超过80%的甲方要求定制化开发或私有化部署。一旦涉及“定制化”或“私有化”，就变成了实质上的“卖人头”服务，收费标准通常约为员工薪资的120%，再高就难被接受了。

现阶段，这类服务型产品非常类似于外包，价格被压得很低，接到的活要么是难啃的硬骨头，要么是价值不高的边缘业务。员工在其中成长有限，项目还时常青黄不接。这条路对规模小的团队来说步履维艰，规模大了又面临巨大的管理和风险压力。

此外，B端业务拖欠尾款几乎是常态，交付周期越长风险越高。因为许多甲方公司自身的战略调整极快，三个月后可能就不再需要这套系统了，他们便会想方设法找茬、拒绝验收。再加上其间可能涉及的人事变动等琐事，尾款收回困难重重，这已成为行业内的老大难问题。

我也见过一些朋友通过SaaS服务赚到了钱，但深入了解后，情况可能并不像表面那么光鲜。

总结下来就是一句话：在国内做纯To B的标准化产品非常困难，市场几乎不给这个机会。AI浪潮兴起初期或许还能有一波红利，但现在，时常有公司拿着100万的预算，却要求做出一个GPT级别的产品。归根结底，或许还是因为国内市场竞争者太多了。

于是，在坚持了一年多之后，今年四月，我和团队终于下定决心，暂停了对“CEO数字分身”项目的投入。随后，贼心不死的我们，又开始折腾AI to C的方向。

C端创业：流量驱动的同质化竞争

放弃B端的“CEO数字分身”后，我们将主要精力投入了一款面向C端的AI英语学习产品——空气小猪。

这个产品也并非凭空想象，是与一位拥有十多年英语教培经验的合伙人共同规划的。他的公司在“双减”和疫情的双重影响下关闭后，一直希望做点新的事情，于是便提出了“空气小猪”的构想。现阶段获取到的用户反馈都相当不错。

然而，从产品构思之初，我就意识到了C端产品的通病：这回倒是不怎么依赖关系了，但产品本身缺乏壁垒，极易被抄袭和复制。

例如，我们在进行了充分的市场调研，确认市面上尚无类似产品后，便加班加点推动产品上线，并成功获得了首批用户。

但就在上周，立刻有用户反馈：“有个团队正在做类似的产品。” 随后，我们甚至在非语言学习场景，也发现了体验和模式高度相似的产品……

这同样是C端创业的难点所在。市场不是专为你一家准备的，谁都可以入场。无论产品还是服务，你在做的同时，别人也在做。而且只要做得稍有起色，就一定会引来模仿者，抄袭的成本还极其低廉。

比如，在我推出AI课程后，很快就有几位学员也开始制作内容高度相似的AI课。这是很正常的事，除非个人或品牌IP足够强大，否则用户终究会用脚投票。

于是，C端产品最终往往又会演变成一场流量争夺战，各种流量运营策略随之登场，而这本身既耗费精力，也需要不小的资金投入。

时代的洪流与个体的挣扎

这两年跑下来，我越来越清晰地认识到一个残酷的事实：国内很多AI应用领域的竞争，某种程度上已经演变为一场资源的游戏。

许多财大气粗的公司，他们自己并不进行原创探索，一点试错成本都不愿承担，但**“像素级复制”** 他人成功模式的手段却玩得炉火纯青。

巨头们凭借其庞大的流量、数据积累和资本优势，能够迅速复刻任何被市场初步验证的创意，将创业团队辛辛苦苦建立起来的差异化优势窗口期，压缩到以“周”甚至更短的时间来计算。

这或许也能解释，为什么许多做AI to C的团队后来又想转向to B，而做完to B发现困难重重后又想回归to C：前者看重关系与定制化能力，后者比拼流量与复制速度，结果往往是两边都不讨好，难以找到稳固的立足之地。

因此，我所感受到的那份无人管束的自由所带来的沉重压力，不仅仅源于自我管理的挑战，也交织在一个对独立创业者而言并不算友好的大环境之中。

于是，很多人选择了“躺平”继续打工，也有更多人将目光投向了出海。就在前几天，我们TGO小组开会，十个人里有八个所在的公司都在尝试出海，只不过各自的策略和路径有所不同。

最后，让我们回到最初的那个感受：我无时无刻不想要个老板。这里的“老板”，并非特指某个具体的人，而是一个系统、一个参照坐标、一个稳定的反馈来源。它象征着：

1. 明确的目标与意义： 独自一人时，“我究竟为了什么而做”这个最根本的问题，需要自己来回答，并且这个答案随时可能因为挫折或迷茫而产生动摇。
2. 即时的反馈机制： 独自前行时，你很难判断自己做得好不好、方向对不对。这种持续的不确定性，是最大的精神内耗来源。
3. 清晰的责任边界： 在公司体系内，你的责任通常是有限的、被定义的。而为自己做事时，“甚至连做这件事本身是否正确都需要自己买单”，这种无限责任带来了巨大的心理负担。

我那位前老板，他就像一个智多星，每隔一段时间就会冒出一个新点子，然后来征询我们的意见。我们大多数人内心都觉得不太可行（尽管表面上表示支持），但他总是想去试一试。

其实，即便我们给出了反对意见，他往往还是会去尝试。因为在他看来，不去试一试，又怎么知道真的不行呢？