WorkBuddy创建专家全攻略：从智能体设计到自动化落地

1. WorkBuddy不像你想的那么简单——先搞懂“创建专家”到底在做什么

我最早接触WorkBuddy，是看到有人拿它处理表格、盯群消息、定时发周报，以为又是一个套壳的聊天机器人。真正上手之后才发现，这个工具的底层逻辑完全不是“你问我答”，而是一个可以自己搭“数字员工”的工作台。今天这篇文章，我打算不讲那些官网文档里早就写烂的界面介绍，直接聚焦在“自己创建专家”这条主线上，把我的实操过程、踩坑经历和最终的配置成果完整拆给你看。

先说结论：WorkBuddy里最核心的单元叫“专家”，本质就是一个具备特定角色、特定工具、特定记忆和特定执行流程的智能体实例。你完全可以把它理解成你的一个员工——它知道自己的岗位职责，知道能用哪些工具，知道按照什么流程办事，也知道哪些信息需要记住、哪些信息不需要。普通聊天机器人是“问一句答一句”，而WorkBuddy里的专家是“领了任务自己干”，干完还能给你交一份像样的结果。

这篇文章适合谁看？一是刚接触WorkBuddy、觉得它不过是个对话窗口的初级用户，二是已经在用WorkBuddy但只会套默认模板、想自定义专家却不知道怎么下手的中级用户，三是想做企业内部效率工具交付的开发者。我会尽量把每一步都讲透，包括你为什么这么做、这么做能解决什么问题、不做会踩什么坑。

2. 创建专家前的核心设计思路——先想清楚你的专家要干什么

2.1 专家不是“提示词模板”，而是一个完整的任务闭环

很多人第一次创建专家，脑子里想的是“把一个越长的提示词丢进去，它就越聪明”。这个观念得先纠正过来。WorkBuddy的专家体系，核心是四个要素的组合：角色定义、技能集、记忆空间、执行流程。四个要素缺一个，这个专家都只能算半个。

我拿一个最常见的场景举例：你想创建一个“周报收集与汇总专员”。如果只是写一段提示词告诉它“你是一个周报专员，请你收集大家的周报”，那它就是功能残缺的，因为它不知道去哪儿收集、用什么工具收集、收集完之后如何汇总、汇总完如何分发。真正合格的创建流程是：先告诉它自己的岗位是什么，再给它挂上能访问周报文件夹的技能，给它配置一个定时触发的执行计划，最后允许它把汇总结果发送到指定群或邮箱。这样它才是一个完整可用的专家。

所以你在开始创建之前，先别急着打开操作界面。拿张纸或者在文档里写下五件事：这个专家叫什么、为谁服务、要完成什么任务、完成这个任务需要哪些信息、完成之后结果交给谁。这五个问题想不清楚，后面的每一步都是瞎配。

2.2 为什么WorkBuddy要把“创建专家”做成一等公民功能

我对比过当前市面上主流的几类效率工具，包括纯提示词平台、RAG知识库工具、自动化工作流工具，WorkBuddy在“专家”这个概念的完整度上做得比较靠前。它不是简单地让你写一段系统提示词，而是把“智能体该有的零件”全部模块化了。

这里面的设计考虑其实很务实：一个能真正干活的AI，必须同时具备“懂业务”和“能动手”两种能力。“懂业务”靠的是角色设定和知识库，“能动手”靠的是技能插件和自动化触发。如果你只给大模型塞一段很长的提示词，它确实能“懂业务”，但它“动不了手”——它读不了你本地磁盘上的文件，调不了你的插件，也没办法每天定时执行任务。WorkBuddy把这些能力拆成了独立的模块，让用户像搭积木一样去组合，这本质上是在说：你要创建的每一个专家，都是一台微型机器，而不是一段对的文本。

这个设计逻辑还有一个隐形好处：方便复用和交接。你创建了一个专家，可以直接导出它的配置，分享给同事，或者放到团队空间里让其他人基于你的版本继续迭代。这个特性我后面会详细讲，它是WorkBuddy和“一次性问答机器人”最大的区别。

2.3 和CodeBuddy的区别——先分清“写代码的”和“干活的”

WorkBuddy的热搜词里总伴随着CodeBuddy，这俩东西到底啥关系，我一开始也迷糊。简单来说，CodeBuddy偏开发助手，面向的是程序员，主要场景是写代码、读代码、修Bug、做代码审查。WorkBuddy偏效率智能体，面向的是所有人，主要场景是任务执行、流程自动化、信息处理和团队协作。你可以粗暴理解成：CodeBuddy是你的结对编程搭子，WorkBuddy是你的数字助理。

但需要注意，两者不是完全隔离的。WorkBuddy里也可以调用CodeBuddy的能力，给专家挂一个“代码执行技能”，让它能写Python脚本处理数据、调用API拉取信息，甚至做简单的脚本调试。反过来，CodeBuddy某些场景也能用到WorkBuddy的任务编排。如果你是个开发者，我的建议是：把CodeBuddy当生产力工具，把WorkBuddy当流程调度平台，两者配合起来用效率是最高的。

3. 实战：从零创建一个“会议纪要专家”的完整流程

3.1 环境准备与入口选择——先确保你的WorkBuddy能用

开始创建之前，你先确认自己的WorkBuddy版本。网页版、桌面客户端和本地部署版的基础功能一致，但部分配置入口有差异。我用的是Windows桌面客户端，配合本地部署的模型服务。如果你用的是网页版，操作路径基本类似，只是“文件访问权限”这类本地功能会受限。

安装和登录的过程我不展开说了，官网客户端一路Next就行。有一个细节必须提醒你：WorkBuddy启动速度受网络环境影响比较大，如果你发现启动卡在加载界面，先检查网络连接是否稳定，不要急着反复杀进程重开。关于启动慢和3002网络错误的解决办法，我在第5部分会专门写。

进入主界面后，你会看到左侧的专家列表。默认情况下系统会预置几个官方专家，比如通用对话、文档处理、数据分析。我们需要做的是点击“创建专家”按钮，开始自定义。

3.2 第一步：写清专家的基础身份信息

点击创建后，界面会让你填写几个字段，包括专家名称、头像、简介和基础角色指令。这几个字段千万别随便填，它们是整个专家能力的“地基”。

我创建的“会议纪要专家”，名称直接叫“会议纪要专员”，简介写的是“负责从录音和文字记录中提取会议要点，生成结构化纪要和待办事项”。基础角色指令我写了下面这段：

你是一名专业的会议纪要专员。你的工作是接收会议录音转写文本或手工整理的会议记录，提取其中的关键信息，包括：会议主题、参与人、讨论要点、最终结论、待办事项。待办事项必须包含负责人和截止时间，如果原文中没有明确，你要标注“待确认”。输出格式固定为：会议概况、讨论详请、结论与待办三个板块。

注意，这段指令不是随便写的，它做了三件重要的事：第一，明确工作输入是“录音转写文本或手工记录的会议记录”；第二，定义输出结构；第三，给出信息缺失时的兜底策略。这三点缺一不可。如果你只写“请提取会议要点”，它会输出千奇百怪的格式，后续处理起来非常痛苦。指令里定义输出结构，是让专家可用的关键一步。

3.3 第二步：配置技能集与知识库

基础指令只解决了“知道怎么做”的问题，接下来要解决“用什么做”。

在我的场景里，会议纪要专家需要三个核心能力：读取文本文件、处理音频转写文本、搜索历史纪要作为参考。对应到WorkBuddy，我需要给它挂上以下技能：

• “文档读取”技能，让它能读入Word、TXT和PDF格式的会议材料。
• “目录扫描”技能，让它能列出指定文件夹下的文件清单，避免我每次手动指定文件名。
• “知识检索”技能，我给它挂了一个知识库，把过去半年的历史会议纪要放了进去。这样它写新纪要及时，能够参考以前的格式和风格，保持团队文档的一致性。

技能配置界面会列出所有可用的技能插件，你直接搜索关键词然后启用即可。但有一个坑必须先说：技能不是越多越好。每个技能都会占用专家执行时的上下文和调用时间，你把20个技能全挂上，结果是它连“你好”都要扫描一遍文件系统，响应速度会拖垮。我的建议是，专家能用3个技能解决的事情绝对不挂5个，保持精简。

如果你想创建自己的技能插件，WorkBuddy支持简单的可视化配置，也支持上传代码实现复杂逻辑。这个门槛稍微高一些，需要懂一点编程基础，我建议新手前期先用现成的技能，跑通了流程再研究自定义插件。

3.4 第三步：设置文件访问范围与权限

这一步是安全红线，很多人在这个环节出错。

WorkBuddy的专家如果配置了文件操作类技能，它必须有明确的文件访问范围。你不可能让一个“会议纪要专家”去读取整个C盘的所有文档，这既有安全风险，也会让它检索时找错文件。

我建立的规则是：在WorkBuddy设置里为这个专家指定了一个独立的文件夹，路径类似D:\WorkBuddy\MeetingMinutes，里面只有会议录音、转写稿、历史纪要和输出模板。专家在执行过程中只能在这个目录内读和写。实际配置时，操作路径在“专家设置-文件权限-添加目录”，你可以按需添加多个目录，但每个目录必须自己确认过确实需要访问。

这里要分享一个我踩过的坑：有一次我给一个“报销单据处理专家”设置了文件夹权限，当时图省事给了整个D:\Work\目录的权限。结果专家在检索参考文档时，把同目录下完全不相关的合同文档也当成了报销参考，导致提取的字段格式乱七八糟。后来我严格把目录缩小到只包含报销单据的子目录，问题立刻消失。权限范围宁小勿大，这是铁律。

3.5 第四步：创建专属知识库

如果你希望专家输出更贴合自己团队的习惯，知识库是必须要做的一步。我的做法是把过去半年的历史会议纪要按照“日期_项目名”的方式命名，放在知识库文件夹里，然后在WorkBuddy中为该专家关联知识库。

知识库的构建过程本身并不复杂，你把文档拖入知识库，系统会自动完成分块和向量化处理。这里值得写一下的是分块大小的问题。如果你上传的是篇幅很长的年度报告，直接丢进去会导致检索时命中粒度太粗，检索出来的片段可能是一整段废话，对生成纪要没有太多帮助。我的操作习惯是：长文档先按章节拆分成多个文件再上传，每个文件控制在2000字以内。这样检索出来的片段更精确，专家引用的内容也更靠谱。

另外，知识库不是建完就一劳永逸的。你每开完一次重要会议，就应该把新生成的纪要追加到知识库里。专家会实时感知到新增内容，下一次写纪要时就多了一份参考。这是让专家越用越聪明的核心机制。

3.6 第五步：设定执行方式与交付物模板

到这里，专家已经“知道该干什么”也“有工具可以用”了。接下来还差两块拼图：什么时候干活、干完的活长什么样。

WorkBuddy支持两种执行触发方式：手动对话和自动任务。

手动对话很好理解，就是你主动打开这个专家对话框，把材料发给它，等它处理完输出结果。自动任务则是在“自动化”配置里新建任务，设定触发时间或触发条件。我给我的会议纪要专家配置了两种触发：一个是每日下午5点检查文件夹，如果有新上传的会议录音转写稿就自动生成纪要；另一个是每当指定邮箱收到会议邀请时自动启动处理流程。

交付物模板这步很多人忽略，但我认为它反而是效率提升最明显的环节。WorkBuddy允许你自定义输出模板，把输出结构格式化成团队统一的样式。我的会议纪要模板长这样：

会议名称： 会议时间： 参会人： 记录人：AI会议助手 一、会议背景与目标 二、核心讨论内容（按议题拆分） 三、关键结论 四、待办事项（备注负责人与截止时间） 五、风险与阻塞项

配置模板之后，专家每次输出都会严格遵循这个框架。团队拿到的每一份纪要格式都是一样的，不用再人工二次整理，这是能把重复劳动真正干掉的关键细节。

3.7 第六步：发布与持续迭代

配置完成后，点击“发布”按钮，这个专家就算是正式上岗了。发布之前我强烈建议你在沙箱环境先跑几个测试用例，拿历史会议记录试试它输出的纪要质量，然后再正式启用。

发布之后不是终点。专家的能力提升需要持续迭代。我一般每周会检查一次专家的历史输出，找出它处理得不好的案例，然后回去调整基础指令、增加参考示例或给知识库补充内容。这个过程就是“调教”专家，调教得越勤，它越懂你。

4. 让专家更懂你的核心细节——指令调优、技能搭配与记忆迁移

4.1 把“角色指令”写好的四个层次

我在前面强调了基础角色指令的重要性，这里再展开讲一下到底怎么写效果最好。以我实际调优的经验，一段好的角色指令应该包含四个层次：

第一层是岗位说明，一句话讲清楚这个专家是干什么的。第二层是工作流程，分步骤描述它在接到任务之后应该先做什么再做什么。第三层是输出规范，明确结果的形式、结构、长度，甚至语气。第四层是边界约束，也就是它不该做什么，比如“不要编造未出现在原文中的数据”“不要删除原始文件”“不要在信息不足时强行下结论”。

很多人的角色指令写得像散文，洋洋洒洒几百字，其实全是废话。大模型对冗长且结构混乱的指令，提取关键信息的效率会显著下降。我的体感是，指令控制在300字以内，用条目式表达，比写小作文的效果好很多。你可以在WorkBuddy的调试界面直接对比两个版本指令的输出差异，多试几次就能找到规律。

4.2 热门自定义指令场景参考

热搜词里很多人搜“WorkBuddy自定义指令推荐”，说明大家在这个环节的困惑普遍存在。结合我自己用下来觉得不错的几个场景，我把可复用的指令框架贴出来供参考。

素材汇总类专家，核心指令是：“你负责从收到的多个素材文件中提取关键信息，按主题归类去重，生成一份带标注来源的汇总文档。信息缺失时保留原文，不擅自改动数据。”这个指令的要点是“保留原文，不擅自改动”，防止专家在整理过程中修改数值语义。

数据分析类专家，核心指令是：“你先检查数据文件的字段名称和数据类型，再开始分析。分析结果必须同时包含统计结果和结论解读。如果数据字段含义不明确，先列出字段清单并向用户确认。”这个指令的价值在于先建立对数据结构的认知，而不是急着跑分析，能避免很多因为字段理解错误导致的低级错误。

日程管理类专家，核心指令是：“当用户提供新日程时，先检查与已有日程是否有时间冲突，如有冲突先提醒再添加。所有日程操作必须二次确认后才执行。”如果你需要让专家操作你的日历，二次确认机制是保命项，否则它可能一次性帮你删掉一堆重要安排。

4.3 技能（Skill）搭配的几个实操心得

关于技能配置，上面我提到了精简原则，这里再补充几个真实使用中的搭配心得。

第一，凡是涉及外部数据获取的专家，优先配“网页内容抓取”而不是“用户手动粘贴”。很多人的做法是让用户把网页内容复制粘贴给专家，这在工作流里效率极低。如果你给专家挂上网页抓取技能，直接在对话里发链接就能完成信息采集。

第二，涉及批量文件处理的专家，优先配“文件夹扫描”技能。这个技能能让专家自己感知目录内新增了哪些文件，配合自动任务就能实现“文件一到就自动处理”的无人值守流程。我现在的做法是设置一个“入站文件夹”，任何需要处理的文件放进去，专家5分钟内自动处理完并把结果输出。

第三，跨系统联动的专家，优先考虑插件平台。目前WorkBuddy支持连接常见办公软件，比如钉钉多维表、企业微信、飞书文档。你可以创建“定时同步专家”，每天自动把多维表里的数据同步到另一个系统，或者定时给微信好友发送消息。这些功能不是靠提示词能实现的，必须依赖插件能力，你要仔细看一下自己的WorkBuddy版本支持哪些连接器。

4.4 历史对话、本地记忆迁移的正确操作姿势

创建新专家的时候，如何把旧专家的历史对话记录和本地记忆迁移过来，是很多人都会卡住的点。WorkBuddy的记忆机制和聊天记录是两回事。

聊天记录只是你和专家对话过程的日志，它不影响专家行为。记忆则不同，它存储的是专家从任务交互中沉淀下来的“经验信息”，比如你纠正过它对某个术语的理解，它就会记住，下次不再犯同样的错误。如果你创建了一个新专家，希望它能延续旧专家学到的经验，必须做记忆迁移。

目前实际操作的路径是：进入旧专家的“记忆管理”面板，把需要保留的长期记忆导出，再到新专家里导入。这里有一个经验要分享：不要一股脑把旧记忆全部导入，因为记忆里可能包含大量临时性的、甚至会误导新专家的一次性信息。我会手动挑出与长期能力相关的记忆条目，比如“用户报告格式要求”“常用术语含义”“特定客户的偏好”等，再批量导入。

还有一个容易忽略的点：同一个专家在不同设备上登录，如果你没开启云同步，历史记忆可能不会自动跟随。遇到换了电脑后专家突然“变傻”的情况，先检查记忆同步状态，而不是怀疑模型出了问题。

5. 安装部署与连接配置——本地部署、网络错误与定时任务的坑

5.1 本地部署还是用云端，先想清楚三个问题

网上关于WorkBuddy本地部署的讨论很多，但我不建议一上来就追求本地部署。你先问自己三个问题：你的工作流里有没有强数据隐私要求？你的机器配置能不能跑得动本地模型？你需不需要随时随地访问？

如果三个问题里有两个是“否”，那我建议你直接用官方提供的云端服务，省心太多。但如果你的团队对数据安全有硬性要求，所有文档不能出内网，那就必须考虑本地部署。

本地部署的常规路线是在Linux或Ubuntu服务器上安装WorkBuddy服务端，配合本地运行的大模型服务。整个部署过程对新手来说还是有门槛的，核心步骤包括：准备一台配置够用的机器（内存建议32G以上，有NVIDIA显卡更好）、安装Docker和Docker Compose、拉取WorkBuddy服务端镜像并启动、配置模型服务的接口地址。启动完成后，所有用户通过局域网访问服务端地址即可使用。

我自己的方案是混合部署：开发测试用云端，正式业务跑在本地服务器上。这样做的好处是既能快速验证新功能，又能保证正式数据不出内网。你可以根据自己的实际情况调整。

5.2 启动非常慢、网络连接失败3002的解决办法

启动非常慢和网络连接失败3002是搜索频率最高的两个问题，我在这里直接给排查思路。

启动非常慢，最常见的原因是初始化时在加载模型或连接远程服务。如果你用的是云端模式，启动慢大概率是网络波动导致的认证请求超时，你可以先检查网络连接，确认能正常访问WorkBuddy服务域名后重试。如果是本地部署模式，第一次启动时需要构建索引和加载模型，这个阶段持续几分钟是正常的。但如果每次启动都慢，你要重点检查磁盘IO和内存占用，模型所在盘建议用SSD，机械硬盘会导致加载速度惨不忍睹。

网络连接失败3002这个错误码，我遇到的情况基本都是客户端与服务端版本不匹配导致的协议握手失败。解决办法很简单：把客户端升级到最新版本，同时确认服务端没有做过降级操作。如果你在公司内网用代理，要把WorkBuddy加入代理例外列表，代理服务干扰也会造成3002错误。

还有一种情况容易被忽略：系统时间不准确。客户端和服务端时间相差太大，安全证书校验会失败，同样会表现为网络连接类错误。检查一下服务器时间同步是否正常，特别是内网部署的机器，时间漂移是家常便饭。

5.3 Linux和Ubuntu版本的使用注意点

如果你在Linux环境下使用WorkBuddy，有几点和Windows环境不太一样，值得单独拿出来说。

首先是安装方式。Linux版本通常通过命令行安装，官方提供了脚本，直接执行即可。但安装脚本执行时需要注意权限问题，不要在root用户下直接跑，尽量用普通用户配合sudo执行，避免文件权限混乱导致后续服务无法读取配置。

其次是文件夹权限。Linux环境下如果专家要访问某个目录，操作系统层面的权限必须放对。常见的问题是：专家进程没有对应目录的读取权限，结果在WorkBuddy界面里看操作记录时会很奇怪，明明目录扫描技能已启用，却始终扫不到文件。排查这类问题，先在终端手动验证运行身份能否列出目标目录，再回头看WorkBuddy的配置。

第三是图形界面差异。Linux版客户端的界面渲染在某些桌面环境下可能会有点问题，特别是Wayland环境下窗口缩放异常比较常见。如果遇到界面模糊或按钮错位，优先尝试切换到X11协议，或者调整缩放设置，绝大多数时候能解决。

5.4 定时任务：微信消息、钉钉多维表同步的配置逻辑

定时发送微信消息和钉钉多维表定期同步，这两个需求也是热搜里的高频词。它们的实现依赖WorkBuddy的自动化任务和连接器功能。

定时发送微信消息，核心逻辑是：在自动化任务里设定触发条件，比如“每天上午9点”，然后指定专家执行“发送消息”动作，填写接收人和消息内容模板。消息内容可以引用专家生成的数据，比如提醒大家提交日报。注意，微信消息发送权限需要在插件配置中完成授权，首次授权时需要用手机扫码确认。这里容易踩的坑是：如果你的微信账号在多个设备登录，授权凭证可能会失效，遇到发送失败先重新授权，不要反复调试消息模板。

钉钉多维表同步更复杂一点，它涉及双向同步问题。我的建议是：先确定一个数据主源，避免双向写入冲突。比如你的主数据在WorkBuddy里，那就只做“WorkBuddy→钉钉”的单向同步，钉钉上的数据只读。定时任务每5分钟检查一次，发现有新增或更新就推送到多维表的指定行。如果双向都要写，必须给每条数据加“更新时间戳”字段，并在同步逻辑里判断“最后修改时间”来决定谁覆盖谁。

很多人配置这类自动化时忽略了一个前置条件：专家必须首先具备访问这两个系统的能力，也就是先到连接器管理里完成账号授权和权限范围设置。授权之后，专家才真正有资格去读钉钉的表数据和发微信消息。

6. 高频问题速查与排错实录——把坑提前给你填平

我把自己实操中被问得最多的几个问题整理成了一张速查表，方便你先自查再决定要不要深入排查。

除了上面这张表，我再分享一个排查快捷思路：当专家行为不符合预期时，不要急着调整大模型参数，先看它的执行日志。WorkBuddy对专家的每一步操作都有记录，查看日志能看到它到底是怎么理解指令的、调用了哪些技能、检索了哪些知识片段。绝大多数问题都能在执行日志里找到根源。我甚至遇到过一次“专家频繁用错技能”的问题，看了日志才发现是技能名称相似导致工具调用歧义，我把技能改了个更明确的名字问题就消失了。

还有一个大家问得特别多的问题：“WorkBuddy就是小龙虾吗，为什么叫这个名字？”这个纯粹是网友玩梗，小龙虾的英文是crawfish，和WorkBuddy没有半毛钱关系。与其纠结名字，不如把它真正用起来，在创建专家的过程中体会这套体系设计的巧妙之处。

7. 用真实项目检验：我的“周报汇总与质量分析专家”全配置

为了让你看到一套完整的配置是什么样的，最后拿出一个我目前每天在用的真实项目做复盘。这个专家的名字叫“周报汇总与分析”，它是从“会议纪要专家”的经验基础上迭代出来的，可以说是上个专家的一次升级。

工作流程是这样的：每周五下午5点，自动化任务自动触发，专家先扫描周报文件夹，读取本周新增的周报文档。读完以后，它按照组别汇总每个人的工作内容，标注完成状态和风险项，然后整理成一份整体周报，发送到指定的工作群。同时，它还会对比前两周的数据，自动生成一份简单的趋势分析，指出哪些项目的进展速度在下降，需要管理层关注。

这个专家配置了四个技能：文件夹扫描、文档读取、数据统计分析、消息发送。基础指令里重点强调了几件事：必须提取每个项目Block的负责人、计划完成时间与实际完成时间的差值、风险等级自动判定规则、以及信息缺失时不得臆测。知识库挂了历史周报和项目计划文档，保证它的分析有依据。

落地效果方面，原来每周五我需要花一个多小时收集、整理、汇总周报，现在大约只需要20分钟复核专家生成的结果。最明显的改善还不是时间节省，而是格式统一了、信息完整度提升了，管理层看周报的效率高了不少。

从“为什么”的角度说，这个专家能跑通的关键在于我把工作流程标准化了。如果你的团队本身流程混乱，比如周报格式五花八门，专家汇总时确实会吃力，但这正好可以倒逼团队统一文档规范。AI落地最难的不是技术，而是先把流程理顺。

通过这个实战项目，我自己最大的体会是：创建专家的过程，本质上是在把你的业务知识、工作习惯和判断标准，翻译成一套可执行的结构化规则。这个翻译过程需要迭代，需要耐心，更需要你对业务的深入理解。工具本身只是脚手架，真正让专家发挥价值的，是你对流程的拆解和定义。如果你现在正准备创建自己的第一个专家，我建议你先别急着手写指令，先把上面提到的五个核心问题想清楚，然后动手搭一个最简单的版本跑通流程，再慢慢加技能、加知识、加自动化。这条路我走过，走通之后你会觉得，AI离你的真实工作，其实没那么远。