尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

从聊天到同事:用WorkBuddy搭建AI Agent工作流实战指南

从聊天到同事:用WorkBuddy搭建AI Agent工作流实战指南 这一年多我观察到一个现象很多人手里握着ChatGPT、Claude、Kimi这类大模型工具但实际用法还停留在“有问题就问一句”的层面。AI确实越来越聪明可它在你这边始终是一个聊天窗口而不是一个干活的人。直到我把WorkBuddy这类AI Agent平台真正用起来才意识到差距不在模型本身而在于有没有把任务拆解、工具调用、上下文管理这些工作方法固化下来。这篇文章就围绕WorkBuddy讲清楚怎么把一个只会陪聊的AI改造成一个能独立领活、自己跑流程、最后交作业的同事。WorkBuddy这个名字在圈子里常跟CodeBuddy一起出现很多人以为它只是代码助手的周边插件其实不是。它的定位更接近一个“工作台”你在这个工作台里定义各种任务让AI按流程去执行而AI中途需要查文件、调接口、跑脚本时你可以把这些能力挂进去。换句话说大模型解决的是单次问答的智力问题WorkBuddy解决的是把一次次问答串成一个完整工作流的问题。1. WorkBuddy到底是个什么角色不是更聪明的聊天框是任务编排层1.1 聊天工具和干活同事之间的那堵墙如果你一直在用“聊天框模式”让AI干活会明显感觉到三堵墙。第一堵墙是上下文断裂。我在一个对话里让它帮我改方案标题、拟年度总结框架、写一段对外话术聊到第四轮它已经把第一轮的信息忘了。忘掉不是模型能力不够而是这种用法本身没把信息组织成可检索、可沉淀的结构每次打开窗口都要从头交代背景相当于你每天给一个新实习生重复讲一遍公司业务。第二堵墙是动作无法串联。聊天框里的AI只能“说”不能“做”。让它读本地文件、改文档、定时跑一次、把结果发到指定位置这些动作在纯聊天场景里都需要你手工完成。你跟同事交代一句“帮我把这周提交记录梳理成周报”他得自己查记录、自己排版、自己发给你你跟聊天框AI说同样的话它只会给你一段编的周报因为它看不到你的提交记录。第三堵墙是结果不可复现。同样的任务今天问和明天问提示词稍微改一个字结果就完全不一样。因为在聊天场景里你每次都在现场调没有把任务定义、输入参数、执行步骤、输出格式固定下来。可同事干活不一样——你说清楚要求他这次怎么干下次还怎么干。这个稳定性和边界感正是WorkBuddy这类Agent平台用来解决的核心问题。1.2 WorkBuddy的四个核心部件Skill、Workflow、Memory、Context理解WorkBuddy不需要把它想得太玄你可以拆成四个部件来看。Skill技能是最小执行单元。它定义了一件“能独立验收的事”比如生成周报、整理会议纪要、批量重命名文件。定义Skill不是写一句提示词而是写一份结构化任务说明书包含触发条件、输入参数、执行步骤、输出格式和约束边界。可以把它理解成给新人同事写的一份SOP。Workflow工作流是把多个Skill串起来形成一条流水线。比如“读取本周Git提交记录 → 按项目分组 → 生成周报草稿 → 输出到指定目录”。每个环节是一个Skill环节之间有输入输出的流转。这部分解决的就是上下文断裂的问题前一个环节的输出会作为后一个环节的输入。Memory记忆让AI具备跨任务的连续性。你可以让WorkBuddy记住某个项目的背景、团队的口头习惯、文档存放位置它不像聊天框那样每次从零开始而是带着历史积累干下一件事。不过记忆是一把双刃剑用不好很容易污染上下文后面避坑部分我会专门讲。Context上下文是当前任务执行时AI能看到的实时信息。比如一个Skill执行时需要读取某个Excel、需要查某个接口返回的数据、需要了解当前时间这些都是通过Context注入的。Context管得好AI才能像同事一样掌握“当前状况”而不是靠猜。记住一个判断方法聊天工具是“你问它答”是同步的Agent平台是“你给它派活它自己跑完回来交作业”是异步的。WorkBuddy的设计思路就是奔着异步工作方式去的。1.3 怎么判断你的AI已经“同事化”了这里提供一个可复现的判断标准不看任何宣传只需要回答三个问题。第一丢过去一个任务后你能否离开现场。如果这个任务需要你盯着、每几分钟给一次指令那它还是聊天工具如果任务交接完成后你去干别的事回来只看结果那它已经开始像同事了。第二同样一句话能否稳定地产出结构一致的结果。比如你让它整理技术交底材料连续跑五次输出的章节层级和格式是否一致。不一致就说明任务定义还不够清晰需要回去补Skill的约束条件。第三出错时能否查到过程痕迹。同事干活出错了你会回溯他中间哪一步做错。Agent平台也一样每次执行会记录日志你可以看到它读了什么文件、调了什么接口、在哪一步产生了偏离。查得到执行过程的AI才是合格的干活同事只给一个最终答案的再聪明也是聊天窗口。2. 安装与接入把WorkBuddy请到你的机器上先解决三个拦路问题说完了定位接下来落到实操。2.1 获取渠道与两种运行形态桌面工作台还是本地服务WorkBuddy的获取渠道主要是三条官方网站下载、应用市场分发、以及开源社区的构建包。如果你是在Windows或macOS上用优先选择签名完整的官方安装包避免从不知名渠道下载改过的版本这是基本常识。安装完之后WorkBuddy会有两种运行形态。第一种是桌面工作台形态。打开是一个可视化面板左边是任务列表中间是对话和日志区右边是Skill和Workflow管理区域。这种形态适合大多数非程序员用户特别是行政、运营、产品经理、工程管理这类角色因为你看得清每个任务的执行状态操作门槛低。第二种是本地服务形态。它以后台服务方式运行你通过命令行或HTTP接口跟它交互。这种形态适合有一定技术背景的人——比如你需要把WorkBuddy集成进自己的业务流程或者让公司内部系统定时调用它执行任务。两种形态背后是同一套Agent引擎区别只是前端交互方式。我的建议是第一天用桌面工作台跑通全流程一周之后再考虑要不要接命令行或服务化。大多数人死在第一步的原因不是不会装而是想得太大一上来就打算配置一整套自动化。2.2 安装过程中我遇到的三个高频坑这里补充三个我实测踩过的坑按出现频率排序。第一个坑是插件市场加载不出来。WorkBuddy之所以叫工作台是因为它支持装插件——Git、日历、飞书、企业微信、邮件客户端这些都有插件。但很多人装完主程序后插件市场一直转圈这个大概率是网络环境问题。我的处理方式很简单先跳过插件这一步把核心的Skill功能跑通插件后续再补。不要因为一个插件卡住就放弃整个工具。第二个坑是安装路径带空格。Windows上我一开始把WorkBuddy装在C:\Program Files\WorkBuddy\下结果某些本地脚本执行时因为路径里带空格导致执行失败。后来统一改成无空格路径比如C:\WorkBuddy\问题就再没出现过。这不算WorkBuddy独有的bug而是很多调用本地脚本的工具都会有这个通病。第三个坑是端口冲突。WorkBuddy的本地服务默认会监听一个端口如果你的机器上已经跑了其他开发服务抢占了这个端口WorkBuddy会提示启动失败。解决方式有两种一种是在配置里改端口号另一种是把占用端口的进程找出来关掉。Windows下可以用netstat -ano | findstr 端口查占用进程macOS/Linux下用lsof -i:端口。2.3 模型接入的两种路线API Key与本地模型的取舍WorkBuddy本身不自带大模型它需要接一个“大脑”接法分两种。路线一接云端模型API。在设置里填入模型服务提供方给的API Key然后选模型就完事。优势是配置简单、模型能力强、小参数模型跑不了的任务它也能跑。劣势是按调用量计费如果配置了比较激进的任务流一个月下来费用会让你肉疼。适合追求“立刻跑通”的人。费用方面我实测下来一个普通的轻量任务每天跑十几次每月大概几十块到一百来块要是拿它做大量文档生成或者长文本总结费用会明显上去。控制预算的办法是给每个Skill设置单次执行的token上限。路线二接本地模型。用Ollama这类工具把开源模型跑起来然后把WorkBuddy指向本地地址。优势是数据不出机器、不按量计费、断网也能跑。劣势是对机器要求高——我建议内存至少32GB起步模型选7B或8B量化版本起步跑复杂推理任务推荐32B量化版本。作为参考我机器是M系列芯片Mac跑7B量化模型流畅跑32B就明显变慢。所以如果你只是为了跑通功能先用API路线跑通之后觉得有数据安全或费用需求再考虑换本地模型。顺便说一句如果你团队本身是Java技术栈也可以关注一下Spring AI这类框架。Spring AI能把内部系统封装成标准接口WorkBuddy则负责把这些接口编排成任务流。两者不是二选一关系而是配合关系适合团队内有后端开发能力的情况。3. 第一个Skill实战让AI独立负责“周报生成”这件事装好WorkBuddy之后很多人会陷入一种“不知道让它干什么”的状态。我的建议是不要一上来就搞花活先找一个你每周都做、且足够痛的任务。我个人推荐从周报开始。为什么选周报因为它要素齐全有输入本周记录、有处理逻辑按项目归类、有固定输出结构化文档、有明确的验收标准能直接发出去。而且周报是每个人都经历过的事情你不需要额外理解一个业务场景可以用全部精力去理解WorkBuddy本身。3.1 Skill的正确理解它是任务说明书不是一句提示词我在很多交流群里看到有人把Skill理解成“高级提示词”这是最大的误解。提示词是给模型看的一句话作用是引导这一次回答Skill是一份任务说明书作用是让AI在没人盯着的情况下按固定流程完成任务并且结果稳定达到验收标准。区别可以用一个比喻提示词是“你和实习生说帮我把文件整理一下”Skill是“你把整理文件的SOP打印出来定好输入表格、整理规则、输出模板、最终交付位置以后每周五实习生自己照着做”。一份合格的Skill至少包含五部分组成部分作用举例技能名称让AI清楚这个技能叫什么weekly_report_generator触发描述说明什么场景下应该调用它用户要求生成周报时启用输入参数定义任务需要哪些数据time_range时间范围执行步骤写明处理流程按顺序编号第1步读取Git提交记录第2步按项目分组……输出格式与约束定义交付格式和不可逾越的边界输出Markdown表格不得编造提交记录注意最后一条“不得编造提交记录”这种约束恰恰是提示词模式最容易漏掉的。聊天框里AI为了让你满意会编数据因为它没有渠道核实但Skill模式里你可以给它接上真实的记录来源同时用约束把编造行为封死。3.2 从零配置一个周报Skill的完整过程下面我用一个最小可跑的配置带你走一遍完整流程。第一步新建一个Skill命名为weekly_report_generator。第二步填写触发描述。我实测下来描述写得越具体越容易被准确触发。不要只写“生成周报”而是写“当用户要求生成本周或指定时间范围的周报时使用此技能输入格式为YYYY-MM-DD的时间段或‘本周’等自然语言描述”。技能描述是触发判定的关键信号这个表述决定了AI是否知道在什么时机拿它出来用。第三步配置输入参数。我定义了两个字段time_range时间范围必填extra_notes补充事项选填。参数设计的原则是“只收必要数据”别把一堆当场能查的东西也变成手工输入项否则反而增加了使用成本。第四步编排执行步骤。我这里设计的步骤是读取版本控制工具的提交记录按项目目录或提交前缀分组统计每个分组的提交条数和主要变更内容结合extra_notes补充手工事项按模板生成Markdown周报将文件输出到指定目录。每一步都写得像一个独立操作方便出了问题定位。第五步设置输出格式和约束。输出模板是一个Markdown表格包含项目名、提交次数、主要变更、备注四列。约束写了三条不得编造提交记录没有提交记录的项目不出现输出文件名为周报_YYYY-MM-DD.md。这三条看起来简单实际决定了你得到的是一份能直接用的文档还是一份需要返工50%的草稿。整个配置过程熟练以后大概十五分钟。不熟练时第一次花一两个小时也正常不要着急。3.3 自定义指令模板用“任务五要素”写清楚需求如果你不想马上用完整的Skill编辑器也可以从自定义指令开始。我把常用写法总结成“任务五要素”模板直接套用即可。要素一角色。告诉AI它现在扮演什么比如“你是负责团队研发管理的项目助理”。要素二背景。给足上下文比如“团队采用敏捷开发方式每周五需要向管理层汇报”。要素三输入。明确它会拿到什么数据比如“输入是Git仓库的提交历史通过工具读取”。要素四动作。拆解要做什么分步写清楚比如“先按模块分类再统计变更量最后输出周报”。要素五输出与验收。交代交付格式和验收标准比如“输出Markdown表格必须包含项目名、提交次数、主要变更、备注四列不得输出空数据”。这套模板的好处是它强制你把模糊需求转成可执行可验收的任务。我见过太多人给AI丢一句“帮我写个方案”写出来必然是大空话。但如果你把角色、背景、输入、动作、输出都定义清楚效果是立竿见影的。这里也顺带回应一个热门话题网上流传的“WorkBuddy大学清单”并不是官方功能而是某个用户整理的一份自定义指令合集。它的价值在于你可以参考别人怎么定义任务但不适合直接照搬因为每个人的业务背景和交付标准都不一样。4. 五种典型场景拆解从AI编程到内容流水线周报Skill跑通之后你会对WorkBuddy的工作方式有体感。接下来上强度看看五个真实场景里它到底能承担什么角色。4.1 场景一用WorkBuddy当结对程序员与CodeBuddy联动先明确一点WorkBuddy不是代码编辑器你自己还得写代码。它的价值在于把“和AI协作写代码”这件事从聊天式变成任务式。我最常用的方式是在代码仓库里开一个具体issue例如“用户列表接口目前没有做分页在高数据量下响应超过3秒请调研并实现分页优化保持现有接口兼容并补充单元测试”。然后把issue编号交给WorkBuddy它通过插件读取代码、锁定关键文件、给出修改方案。你可以先审核方案再放行让它改代码、跑测试、提出推送请求。这个流程比在CodeBuddy聊天窗口里来回粘贴代码块的体验好在哪里主要好在三点任务有边界不会聊着聊着跑偏改动可追溯每一步在日志里都查得到验收有条件跑不过测试它就交不了差。如果你本身就在用AI编程工具可以考虑把WorkBuddy当“任务编排层”把其他工具当“执行层”两者联动。4.2 场景二专利与技术文档辅助AI能干到哪一步另一个我观察到的典型应用是专利与技术交底辅助很多研发人员会用WorkBuddy处理专利申请前期的资料整理。可以交给它的工作包括根据技术方案描述生成背景技术部分的初稿和梳理现有技术存在的痛点检索关键词方案建议帮助确定技术领域和检索字段的组合把研发周会记录整理成技术方案文档的素材清单。这些都是“资料整理和初稿生成”范畴能显著节省前期时间。但有一个边界要划清楚涉及权利要求保护范围、法律判断、以及最终提交内容的审核需要具备专业资质的人完成。AI生成的初稿只能作为素材不能作为定稿。这不是保守而是底线。把AI当辅助工具可以极大提效把AI当责任主体就会出问题。4.3 场景三短视频与AI漫剧的剧本流水线内容创作是目前WorkBuddy用得最热闹的领域之一尤其是短视频和AI漫剧因为这类生产流程正好是流水线式的非常适合Skill化。我自己搭过一套剧本流水线选题生成模块负责根据热门关键词输出10个候选选题每个选题附带用户痛点分析和钩子建议大纲模块负责把选中选题拆成3分钟短视频的叙事结构包含开头钩子、中段冲突、结尾反转分镜脚本模块负责输出画面描述、台词、字幕文案、时长预估最后还有一个标题模块根据全文内容生成10版候选标题和封面文案。这套流程的核心逻辑是每一个环节的输出格式固定下一个环节把它当输入。你不需要AI一步到位写出神作但每个环节都比上一环节更接近成品最后人工只做筛选和润色。相比在单个聊天窗口里反复生成流水线的稳定性和可复用性要高出一个数量级。4.4 场景四建筑行业里的规范查询与清单整理建筑行业听起来跟AI不沾边但实际用起来反而很顺手。我交流时认识的几位工程管理方向的用户常用WorkBuddy处理三类事情。第一类是规范和条文检索。把项目涉及的规范文档喂进去然后问某个构造做法允许的最小尺寸是多少、某个材料在防火分区里的适用条件是什么。这不是简单的“百度一下”因为规范文档往往几百页人工翻找费时而Agent可以结合上下文回答问题并标注出处。第二类是材料清单和报表整理。从设计变更单、会议纪要里提取材料名称、规格、数量整理成标准表格。这类工作重复度高、规则明确是Agent比较擅长的任务类型。第三类是项目会议纪要和任务分发。把录音转写结果丢给它让它提取决议事项、责任人、截止日期并生成待办列表。不过要提醒一点工程场景容错率低所有结果都要人工复核后再进流程AI省的是整理时间不是审核责任。4.5 场景五让Agent调用Agent初步的流程自动化雏形当你积累了一定数量的Skill之后可以做一件更有意思的事让一个“管理员Agent”来调度其他Agent。比如我搭过一个“项目周复盘”的流程管理员Agent先调用“数据汇总Skill”从多个数据源拉取本周指标再调用“报告生成Skill”把指标整理成叙事化周报接着调用“风险识别Skill”在周报中标记异常指标并给出风险等级最后调用“消息推送Skill”把结果分别推送给管理层和相关执行人。这就是一个很好理解的多Agent协作雏形。每个Agent只负责自己擅长的一段管理员Agent负责拆解任务、传递结果、检查是否符合预期。这个过程中如果某个环节失败日志里能看到是哪一个Skill出的问题修复也只动那个Skill而不会影响整条流水线。5. 从“能跑”到“稳定用”八个月实测踩坑记录跑通功能只是第一步稳定使用才是真正有价值的部分。这八个月里我踩过的坑按出现频率和破坏力排序集中在下面四类。5.1 Skill一直不触发先按这条链路排查这是新手最常遇到的问题Skill配好了但跟WorkBuddy说“帮我生成周报”它完全没反应或者给了你一段普通对话式的回复根本不走你的流程。我第一次遇到时第一时间怀疑是功能有bug后来才发现大多数情况下是配置问题。排查链路我整理如下。第一步检查触发描述。在WorkBuddy里触发Skill不是靠严格匹配而是靠模型理解触发描述写得越具体模型越容易在对话中识别调用时机。比如描述里只写“生成周报”模型可能拿不准要不要启用写成“当用户要求生成本周或指定时间范围的周报时此技能应被触发”命中率就明显提升。第二步手动执行测试。WorkBuddy里一般都有手动运行Skill的入口填入参数直接跑。手动能跑通说明Skill本身没问题手动就跑不通重点检查执行步骤和权限配置。第三步检查工具权限。很多Skill卡住其实是执行到工具调用那一步就静默失败了。比如你想让AI读Git提交记录但Git插件没有授权凭证它在后台尝试调用时失败又不会主动告诉你。这种情况去日志里看通常能发现权限错误。第四步把复杂Skill拆开测试。如果一个Skill有八个步骤中间某一步报错会导致整个任务失败。我的习惯是先建一个只包含第一个步骤的简化版本跑通后再逐步加回剩余步骤这种“增量构建”方式排查效率远高于一次性写完再找错。5.2 Memory越用越乱上下文被污染后的典型症状Memory是WorkBuddy的优势也是最容易踩的坑。刚开始用的时候我什么信息都往Memory里塞项目背景、文档路径、团队偏好、几个旧方案的上下文……结果两周之后WorkBuddy开始出现明显“失忆”。具体症状是让它生成内容时它会混入其他项目的信息同一个指令早上和下午跑出来的结果差异巨大有时候甚至会把早前任务里的一句闲聊当成背景资料。这就是典型的记忆污染。原因其实不难理解Memory不是越长越好大模型的注意力是有限的装太多无关信息就会稀释重点。排查之后我定了几条规矩按项目维度隔离记忆一个项目一套记忆标签不混用只有跨多次任务都需要复用的信息才进Memory一次性任务的信息用临时上下文不进长期记忆每隔两到四周清理一次Memory删除过期信息遇到复杂任务临时关掉Memory避免历史信息干扰当前执行。调整之后“失忆”现象基本消失。记住这句话Memory是给AI做的“工作档案”不是给它做的“聊天记录”。5.3 目录结构异常、Linux兼容性与“点开头”文件夹有一段时间我发现WorkBuddy项目目录里冒出了一个“点开头”的文件夹比如.workbuddy周围不少用户也困惑过。这里给你吃个定心丸这不是病毒也不是配置错误这是程序用来存放配置、日志、记忆数据的隐藏目录。在Windows里它可能只是显示为普通文件夹在macOS和Linux里点开头的目录默认是隐藏的你需要在文件管理器里开启显示隐藏文件才能看到。这类隐藏目录的作用是集中管理状态数据不要随意删除。如果你需要迁移机器或者备份配置把这个目录整体复制走就行。另外如果你在Linux服务器上跑WorkBuddy有几个细节要注意文件权限要正确尤其是运行用户对数据目录的读写权限否则会出现“能启动但写不了数据”的怪问题依赖库版本要提前查清楚我遇到过因为系统Python版本过旧导致部分插件无法安装的情况如果要用命令行方式执行任务优先配置绝对路径避免相对路径在不同调用环境下指错位置。5.4 生成结果一股“AI味”问题其实出在四个环节很多用户跑通WorkBuddy之后第一个不满意是“生成结果太AI了”——用词讲究但空洞到处都是“首先、其次、最后、综上所述”。这个问题其实不是模型不够好而是你在四个环节里没有做约束。第一个环节是角色定义。你说“你是文案专家写一段产品介绍”得到的就是标准AI文案但你说“你是跟客户打了十年交道的销售写一段在电话里说服客户升级套餐的话术语气要像真人说话避免书面连接词”结果立刻不一样。角色定义决定了表达腔调。第二个环节是输出规范。在Skill的输出约束里明确写“禁止使用首先/其次/最后/综上所述等连接词”“句子不超过25个字”“允许口语化表达”。这些约束看似琐碎但对输出风格的影响非常直接。第三个环节是少样本示例。给一个你满意的范文让它照着风格写。这是最朴素也最有效的方法比调模型参数更可控。我在搭内容流水线时会把历史爆款的文案结构喂进去“模仿这篇的风格”成了最常用的一句话。第四个环节是采样参数。在模型配置里适当调整temperature生成类任务建议0.7到0.9结构化整理类任务建议0.2到0.4。温度调低输出更稳定温度调高输出更多样。如果你的任务需要结果一致性就不要把温度设在0.4以上。这里也要说一句所有调优的目的都是提升内容质量而不是为了规避某个平台的检测规则。用工具提升表达质感没问题动歪心思搞弄虚作假就没必要了合作方和平台都不是傻子。6. 收尾阶段的真心话什么任务适合交给它什么任务别勉强写到这你应该已经对WorkBuddy有了比较完整的画面。最后分享几点真实的使用感受以及我在实践里总结出的边界感。6.1 三个我建议你提前养成的使用习惯第一个习惯是控制任务粒度。交给WorkBuddy的任务最好是你自己能在三十分钟内完成的。如果这件事你自己都要花半天说明它包含大量不确定性AI大概率也处理不好。把大任务拆成小任务再把小任务逐个Skill化这是从“能跑”走向“稳定用”的关键转折。第二个习惯是每一次任务都设验收标准。同事交作业要过验收AI也应该一样。你在配置Skill时就把验收标准写清楚之后每次执行都以它为准绳。没有验收标准的自动化任务跑几次就会开始失控。第三个习惯是每周回顾一次Skill清单。我每月固定时间翻一遍已有Skill删除一个月没用的合并功能重叠的更新描述已过时的。这个过程好比整理工具箱常维护的Skill越用越顺不维护的Skill就是个摆设。6.2 哪些场景现阶段不适合硬上WorkBuddy最后说点泼冷水的内容。有几个场景我实测下来不太适合交给WorkBuddy建议你别硬上。第一类是需要深度价值判断的任务比如商业决策、人事判断、内容好坏的方向性判断。这类任务依赖大量隐性经验AI能给你参考信息但你把决策权交给它等于把职业风险外包给一个没有责任感的实习生。第二类是容错率几乎为零的任务。比如财务管理里的对账、工程验收里的关键数据核对。这类任务一旦出错后果严重即使AI表现得再专业也需要完整的双重复核机制才能上线。第三类是低频且每次定制化程度都很高的任务。如果一件事一个月做不了一次每次要求还完全不同配置Skill的投入产出比就很低。这种任务在聊天框里临时问问效率反而更高。工具不是用得越多越好用得准才是本事。我个人的体会是WorkBuddy这类Agent平台带来的最大变化不是“节省了多少时间”而是“改变了我组织任务的方式”。以前我是把任务在脑子里拆好自己做现在我是把任务拆好之后交出去盯进度、验结果。这个转变一旦发生你对工具的认知就再也回不到聊天框时代了。希望这篇教程能帮你少走一些弯路早点把那个只会聊天的AI培养成一个真正能帮你分担工作的同事。
返回列表