1. 为什么企业培训内容要从人肉生产转向智能体工坊我接手这个项目的时候正赶上公司培训部门连续第三个月被吐槽新员工入职培训的课件还是半年前的版本题库里一百多道选择题里有三十多道连老员工都在群里吵不出标准答案至于答疑——全靠三位培训专员在群里轮流值班下班之后的问题基本要靠缘分来回答。你问培训负责人痛点是什么他会告诉你是内容跟不上、题目不够用、答疑没人管但如果拆开看本质是内容生产的链路还停留在手工模式。这一篇是这个企业多智能体虚拟团队实战系列的第八个专题也是我个人认为在通用型Agent还没有完全成熟之前落地性价比最高的一个场景职业教育与技能培训内容工坊。核心就干三件事第一把业务专家脑子里的知识结构拆成一棵可以不断挂载内容的知识树第二基于这棵知识树自动生成多模态的智能题库第三架一个知识库兜底、Agent托底、人工收底的7x24小时答疑服务。为什么说性价比高因为培训内容的产出过程本身就很贴近大模型擅长的分步骤、抠细节、按模板输出的活儿而且每产出一次内容沉淀下来的知识树和题库可以反复被后续的答疑、考核、课程迭代复用。你不需要改变业务专家原有的工作习惯只需要让他们在系统里过一遍知识点就够了。这篇真正想分享的不是又一个大而全的中台方案而是我们实际跑通之后沉淀下来的具体做法知识树怎么拆才不会被AI拆烂题库怎么生成才能避免看起来很多但一考就废答疑Agent怎么接住那些非结构化、口语化、甚至带情绪的提问。适合正在做企业内训、职业培训平台、技能认证系统或者想给已有的知识库加上生产考核答疑闭环的人参考。1.1 传统内容生产的三个死循环先说我们当时面对的实际情况。公司本身做的是产业工人和转岗人员的技能培训业务课程覆盖电工、焊工、数控操作、设备维护、安全生产等十几个工种。每个工种又分初、中、高三个等级光电工这一个工种的知识点清单就有两千多条。培训部门一共四个人要负责所有工种的内容维护。这里出现了第一个死循环专家没时间写写出来也没人维护。线下的技能专家每天要在车间盯生产让他们抽出两周整理一门课的知识点根本排不过来。就算挤出时间整理第二年设备型号一更新知识点就得跟着变靠人肉维护根本跟不上。第二个死循环是题库老化速度远超迭代速度。业务部门考核要的是能考出真实操作水平的题但传统选择题只能考记忆类知识。我们抽样统计过原有题库中85%的题目停留在是什么的层面也就是布鲁姆教学目标分类里的记忆和理解层级应用分析层级的题目比例很低。换句话说考完试你会发现高分学员上手依然发怵。第三个死循环最隐蔽答疑消耗了内容团队所有剩余精力导致他们更没时间做内容。培训专员的日常工作很大部分是在微信群里回答重复问题——这个表格在哪下载实操考试能不能补考第二步的电压值为什么是380V。这些问题其实散落在课程文档、操作手册和往期聊天记录里但没有人把它们结构化沉淀出来于是同一个问题每周都要重新答一遍。当时我们判断这三个死循环必须用一个统一的底层结构来解决这个结构就是知识树。1.2 智能体工坊的整体设计思路想清楚之后我们搭了一套三智能体协同的内容工坊雏形后来逐渐扩展成了包含规划、执行、质检、答疑在内的完整链路。整体架构是这样的一条生产流水线外加一个对外服务出口。生产流水线由三个核心智能体组成——知识树拆解智能体负责把专家输入的专业资料我们可以叫它原料知识包拆解成标准化的知识节点和层级关系题库生成智能体负责在知识树的每个可考核节点上产出题目并且支持图片、图表、实操场景等多模态输入输出内容质检智能体负责对拆出来的知识节点和生成的题目做一致性校验、难度标定和错误清洗。在这条流水线之上的是一个负责调度编排的协同大脑管理任务分配和进度反馈。对外服务出口就是问答智能体它对接到企业内部的培训平台、钉钉/企微机器人、以及学员微信端统一承接7x24小时的答疑请求。用一系列大家更熟悉的概念来类比知识树相当于把教材目录升级成了可计算的知识图谱题库生成相当于把书后习题变成了按知识点动态出题的自动化产线而答疑Agent相当于给每门课配了一个永远在线、且翻过全部课程资料的助教。需要注意这里说智能体不是指一个ChatBot套了个名字。我们设计每个角色时都给它定义了明确的目标函数、输入输出格式、执行工具、以及与其他智能体的协作协议。后面我会把这套协作协议的具体内容展开讲这里先记住一个原则智能体的边界清晰比用一个大模型暴力调用要重要得多。2. 知识树拆解把专家的隐性经验变成可检索的结构化资产知识树是整个内容工坊的地基。它决定了两件事一是题库生成的粒度二是答疑检索的范围。地基没打好后面建什么都白搭。我们最早犯过一个特别典型的错误让大模型端到端直接生成一棵完整的知识树输入一份几千字的工种说明要求一次输出完整树状结构。结果生成的树形态上很漂亮层级清楚、节点命名也专业但一让专家校验就发现大量幻觉——有三成节点对应的内容在原始资料里根本找不到出处。这不是大模型能力不行而是任务设计不合理。一份针对叉车操作工的培训资料可能横跨安全规范、车辆结构、驾驶操作、维护保养四个大域每个域下面又细分出十几个知识模块让模型一次生成上千个节点的树相当于让新员工没经过轮岗就直接做全公司的组织架构图不出错才奇怪。2.1 知识树模型的工程定义我们先定义了知识树的工程格式这里我直接给出最终在用的schema供参考一个知识节点包含六个字段节点ID、节点名称、所属层级、父节点ID、学习者要求、考核权重。节点名称不用多说。所属层级我们分为三级领域、模块、知识点。领域是最大的分类比如低压电工实操安全模块是领域下的功能块比如触电急救知识点是叶子节点是实际会被考核和答疑引用的最小单位比如心肺复苏的按压深度与频率要求。学习者要求是动作化描述必须能考核比如能够独立完成跨步电压场景下的脱离电源操作。这个字段的存在是为了防止知道理解掌握这类模糊动词。考核权重是0到1之间的小数表示这个知识点在考核中的出现概率权重。权重不是拍脑袋定的而是参考两个数据源近一年学员在答疑中最常问的内容占比以及业务专家对岗位实际使用频率的打分会话记录。建树的一个核心原则每个叶子节点必须能从原始资料中找到出处。我们在每个节点上增加了一个资料溯源字段记录该节点对应的原始资料片段ID和页码。质检智能体在验收时会随机抽查10%的叶子节点逐条回查源头发现无法追溯的会打回重新拆解。最开始有同事觉得这个字段多余觉得AI拆出来的节点就是来自原文的不会找不到出处。但实际跑了一个月后这个字段救了我们好几次——凡是人工review时拿不准的内容点一下溯源就能看到它在原文中的位置效率比来回翻文档高太多。2.2 拆解智能体的工作流设计确定好节点格式后我们没有让AI一口气把树拆完而是设计了四步走的工作流第一步目录骨架化。智能体首先读取原始资料的结构把各级标题和导言段落抽取出来形成候选的领域和模块清单。这一步不做知识点拆解只做结构映射准确率很高。第二步模块并行拆解。把第一步生成的每个模块单独作为一次任务提交给拆解智能体让它基于模块对应的原文片段拆出该模块下的知识点叶子节点。这一步通过并行调度把整体任务拆小了模型幻觉率明显下降。我们测试过单次任务的知识点数量控制在15个以内时节点与原文的匹配度可以稳定在90%以上。第三步语义对齐。拆出来的知识点之间可能存在重复、包含或相互矛盾。这里需要一个对齐智能体做一次全树扫描把语义相似度高的节点合并把下级节点覆盖范围大于上级节点的结构错误标记出来。对齐之后会给每个节点重新编号。第四步专家抽查制。整个拆解过程不是无人值守的。业务专家不需要全量审核但必须完成两件事一是对每个模块至少抽查3个知识点确认拆解方向和颗粒度符合预期二是在树建好后参加一次走树评审——我们拉着专家对着树从上到下过一遍重点看有没有漏掉关键实操步骤。这一遍耗时看领域大小一般一两个小时但效果远好于让专家坐在电脑前逐条核对。这里有很多经验来自一次失败质检智能体在语义对齐时发现液压系统工作原理和液压泵结构两个模块下的知识点出现了大量交叉根源是原始资料在那个章节本身编写得就比较混乱。我们的处理方法是不强行让AI理顺而是把这个情况标记为课程资料结构异常推送给人工处理。训练和提示词都解决不了原始资料的质量问题时要及时让人工介入而不是让AI硬撑。2.3 拆解质量不达标的常见情况和修正策略整套跑下来后知识树拆解有几类问题是必然出现的先打个预防针。第一类是颗粒度失稳。同一个模块下有些知识点拆得非常细正确的持笔姿势中食指与笔尖的距离范围有些却像一篇小论文的标题高处作业的基本安全要求。解决方法是给拆解智能体的提示词里加入自检清单明确要求一个叶子节点应在15分钟内能完成讲解和演示超过这个时长的需要继续拆分。这个标准不是我们发明的而是培训部门自己的讲师提的他们发现一节课的PPT页数不能承载超过一定数量的叶子知识点否则学员会疲于抄笔记。第二类是节点命名教材腔过重。比如把掌握三相异步电动机的启动控制原理这种偏学术的描述用作节点名但真实车间里的说法是电机怎么接才能转起来。这个问题会影响答疑检索——学员用大白话提问时向量检索可能匹配不上。我们后来让拆解智能体在产出正名之外同时生成3个左右的别名别名来源是专家提供的工人常用说法和答疑历史的真实问法。向量库索引时把别名一起索引进去命中率提升明显。第三类是交叉学科的边界归属争议。比如数控机床加工参数调整这个知识点到底是归数控操作模块还是归设备维护模块不同部门的专家意见还不一致。我们的处理方式是在树上允许一个知识点出现在多个模块下但主从关系必须定义清楚——主节点挂在考核知识树上从节点挂引用。这样在答疑检索时不会漏掉在题库生成时避免重复出题。3. 多模态智能题库从有题可做到按场景出题知识树建好之后紧接着就是题库生成。为什么把题库单拎出来讲因为企业培训的题库和K12考试题库有一个本质区别考核目标不是筛选区分度而是验证岗位胜任力。这就决定了题目形式要充分贴近真实的作业场景——很多时候正确操作不是选一个选项而是看图判断、按顺序排序、识别异常音/震动等状态。我们内部做过一个小调研在100名刚通过理论考核的新焊工中超过60%的人对焊接电流调节旋钮的实际操作位置这类实操细节没把握。原因是他们背过焊接参数选择原则但没见过真实设备面板的图片。所以我们的智能题库从一开始就不是以文本选择题为主的而是明确要求支持多模态。3.1 题目生成链路与Bloom分层出题题库生成链路是这样设计的题库智能体接到一个知识节点先读取该节点的考核权重、学习者要求和知识点内容然后根据Bloom认知层次分类生成题目。我把出题策略展开一下。我们的Prompt里内置了一个简化版出题框架给每个知识点生成题目时强制要求覆盖三个层级记忆理解层考是什么和为什么用单项选择、多项选择、判断对错。这些题适合做入职前的基础摸底。应用分析层考怎么做和什么情况下做用场景题、排序题、识图题。比如以下哪个操作顺序可以避免工件在定位时发生偏移配上夹具装夹步骤的四选一图片组合就是典型的应用层题目。综合评价层考如何判断和如何优化用故障排查题、方案对比题。这类题多模态特征更明显——给一张设备运行参数界面截图让学员判断异常项并选择处理优先级。为了保证覆盖率我们要求每个知识点至少在记忆层和应用层各生成一题综合层按权重前20%的节点生成。同时打上难度标签。这里有个细节难度标签初期不用让模型直接生成因为大模型对该校的学员觉得哪道题难缺乏真实校准数据。我们采用模型初标质检复标考后修正的策略。模型和质检智能体先各自打一个难度预估值如果一致就采用不一致取较高值。等题目实际跑过一轮考试后再按学员的通过率和耗时对难度标签做一次回归修正。经过这样一轮校准题目的难度分布才真的可参考。3.2 多模态素材的输入输出处理多模态在这里主要体现在两种用法上。第一种是以图出题。比如安全标识识别题用一张真实车间照片让学员判断图中作业人员违反了哪条安全操作规程。这里要处理的关键问题是图片和文字之间的一致性问题——图片必须真实对应题目描述的故障情景不能凑合。我们接了一个外协的标注小组对真实场景照片做故障点拉框标注生成标准答案和干扰项的依据。在技术路线上图片素材统一经过一个视觉理解模型做预处理提取出图中元素列表这样题库生成智能体在写题目时就能准确引用图中的具体细节而不是凭印象写。第二种是生成图解材料。有些知识点如果没有真实照片可用就由系统自动生成教学示意图。举个例子管工法兰连接时螺栓对角紧固顺序培训讲师原来用一张静态箭头图学员理解起来很费劲。我们让多模态生成智能体直接产出一张分步骤的工序示意图每步用不同色块标出当前应紧固的螺栓位置训练效果好了不少。这里我要特别提醒一件事不要高估多模态生成内容在企业培训场景下的直接可用性。生成示意图适合做辅助理解素材但不宜直接用来当考题配图。原因是生成图里的细节可能有微小偏差——比如某个阀门的方向画反了对于新学员来说根本看不出来但到了考试里就会造成争议题。我们现在的做法是模型生成的示意图必须经过图像描述回放校验即让视觉模型重新描述图中的关键元素再和题目要求比对不一致的直接弃用能省掉很多考后申诉。3.3 质检智能体难度标定和干扰项清洗题库系统的最后一道关在质检智能体。这道关我们踩过的坑和收获的经验都是最多的。先说干扰项质量这个最典型的坑。模型生成的答案选项里几乎必然会出现一些被我们称为白给项的干扰项。比如题目问低压验电笔测量时若氖泡不亮下列哪项最可能导致模型生成的干扰项里有验电笔笔尖太脏——这在原理上说得通但对于实际学员来说过于冷门选了它的人反而暴露了真实经验。这种选项干扰性太强属于偏怪题在考试中应该被规避。质检智能体的规则里明确了干扰项的筛选标准优先选择常见操作错误和概念相近混淆作为干扰项禁止使用冷门设备故障生僻名词和原理上不可能的情况。另一个坑是重复出题。同一知识树上有过两个子节点的学习者要求在语义上高度相似题库智能体可能分别在两个节点下生成了一道几乎相同的题。传统做法靠人工抽样检查累且漏。我们的解决方式是在质检环节引入向量相似度比对对候选题目做两两计算超过相似度阈值的自动标记为疑似重复再决定保留哪一题或合并后重新出题。质检的输出不仅包括通过或不通过还包括一份审核意见反馈给题库生成智能体参照修改。如果连续三轮质检都不通过系统会把该知识点标记为存疑节点推给人工处理而不是无限循环重试。这个机制我们是在被一次死循环折磨之后加上的——某个复杂工序的知识点生成模型陷入了改完A问题出现B问题的循环跑了十几个小时费用消耗了不少最后出来的题目还是不能用。加了这个熔断机制后生产线的整体吞吐反而更稳定了。4. 7x24答疑把RAG做成能接住实弹的服务知识树和题库建完内容工坊的生产侧基本成型接下来要解决的是服务侧——7x24小时答疑。刚开始我们想得很简单上RAG把课程文档和题库灌进向量库接个Agent就能回答问题。但实际打开答疑入口后发现真实提问跟标准问答对的差别比你想象中要大得多。真实提问长什么样我摘几条脱敏后的真实消息师傅我今天做那个电机正反转的接线练习火线进开关后另一根线应该接哪昨天记得今天乱了我们这型号的设备是不是都不用碳刷的是不是考这个证必须得先过体检啊我同事说他血压高没让报。这三条提问分别代表了三个难啃的骨头一是对话中有真实操作背景和临时性遗忘二是提问中夹杂着不确定性、需要验证思辨问题、甚至是有误导性的陈述的问题是不是都不用碳刷三是关于政策流程的问题已经超出了技术知识树的范围。4.1 答疑链路的架构与上下文管理最终跑下来的答疑链路分为四个阶段意图路由、知识检索、答案生成、人工兜底。意图路由是第一个关键环节。进入的提问先经过一个分类模型判断属于四类中的哪一类技术操作类占70%左右、流程政策类占15%、情绪反馈类这门课太难了、闲聊礼貌类。后两类不需要走完整RAG链路流程政策类则需要接一个单独的规则库因为这类问题的答案必须以人事部门发布的文件原文为准不能由模型自由发挥。技术类的提问进入知识检索阶段。这里有个我们花了很长时间才做好的改进检索前先做提问改写。新员工提问里经常出现口语化的省略和指代不清直接拿去检索的命中率很不稳定。比如那个安全距离表的第四行——如果不结合上下文向量库根本不知道那个表在哪。我们的做法是让一个轻量Agent基于知识树语义和历史对话把这类提问先翻译成标准化的检索query。这个环节单独评测过有上下文时的首轮检索命中率比直接检索提高了大约25个百分点。上下文管理上我们为每个学员会话维护了一个操作上下文窗口包括他当前正在学习或练习的知识点、最近做的题目、上次答错的题。答疑Agent在回答时可以引用这些信息让答案更有针对性。比如学员问我这个接法对不对系统如果知道他最近三小时一直在练习星三角启动电路就会优先围绕这个场景组织答案而不是泛泛地讲接线安全规范。4.2 答不上来和答错的真实案例这个部分先讲坏消息。我们在内测阶段统计过首版答疑Agent的直接可采纳率只有62%也就是说大约每三个回答里就有一个不能让学员满意。拆解一下失败模式最常见的有三类。第一类是检索到但答案没组织好。知识树里相关知识点的原文本身就是表格或操作步骤列表Agent回答时却用了一大段文字复述学员看着累印象也不深。改进方案是答案生成时根据查询类型选用不同的回答模板。如果知识点自带表格数据优先输出化简后的表格如果是操作步骤输出编号列表并标注每一步的目的。这个改动看着不起眼但学员满意度提升非常明显。第二类是知识树覆盖不到但实际靠经验才知道的厂内知识。比如实训车间下午几点关门“哪个工位的设备是坏的可以去旁边的工位练”这些信息存在于培训负责人的脑子里课程文档里根本没有。这类问题被我们的意图路由归为无法回答直接转人工。后来我们在知识库里补充了一个本地运营FAQ词条库把这类高频线下问题整理进来答疑准确率又上了一个台阶。第三类是高风险回答的边界把握。有一次学员问我触电后手麻了是不是不用去医院检索系统返回了安全规范相关内容生成模型在回答末尾加了一句如果症状持续建议观察——这个建议观察是绝不能出现的反馈因为手麻可能是心肌损伤的信号。这件事之后我们在产品上做了两层防护一是设定高危意图词表凡涉及人身安全、医疗判断、法律政策类的提问一律不生成自由文本答案直接转人工或只能返回官方原文二是给Agent加了回答边界确认步骤在生成涉及安全的回答前必须先调用安全守则知识库确认不存在自由发挥空间。4.3 知识库的持续更新与人机兜底机制答疑系统上线后知识库不是静态的而是形成了一个失败驱动的更新循环。具体来说每当答疑Agent给出回答后学员端都有一个这个回答帮到我了吗的一键反馈。被点没有的回答会自动进入待复审队列。运营同事每天用二十分钟左右过一遍这个队列找出高频失败原因。如果原因是知识库缺内容就补进知识树对应的节点如果是答案生成质量不行就调整提示词或回答模板。这个循环特别像我们做推荐系统时看的bad case 回归每天不回归系统就慢慢变傻。人工兜底也是刚需。我们在系统设计里保留了转人工的两条触发路径学员连续两次对回答点没有或者提问涉及高危意图词系统会主动把会话转给当日值班的培训专员。在转接时系统会把之前所有对话记录、检索到的知识片段、已经尝试过的回答摘要一并打包给人工让人工不用从头了解上下文。值班专员转正的另一个来源是夜间提问——晚上十点后的问题如果学员不点加急会推迟到次日早上九点统一由人工复核。统计下来大约有60%的夜间问题在第二天早上学员醒来前已经被RAG正确回复了剩下的人工处理压力其实不大。5. 落地复盘智能体分工、模型选型与成本控制工坊上线到现在跑了大概四个月从内部工具变成了正式的培训支持模块。这一章把工程上最有参考价值的几个决策复盘一下包括智能体分工怎么定、模型怎么选、成本怎么压。5.1 智能体角色划分和协作协议我们把智能体分成了四类角色拆解者、出题者、质检者、答疑者。每个角色在系统里是独立的微服务但共享一套知识树作为工作台数据。拆解者只负责知识树构建不直接接触学员出题者只面向知识树的叶子节点和模块级节点不自己决定考核范围质检者纠错但不修改数据发现问题只打标签、给意见答疑者是唯一对外的出口所有回答都必须携带知识来源引用无法引用时不硬答。角色之间通过一个轻量级的任务协议通信用的是类似任务包验收回执的模式。下游智能体完成任务后会向上游提交一份验收回执包含做了什么、覆盖了哪些节点、有哪些可疑点。上游确认后再把任务状态改为完成。这种异步协作比所有智能体都改同一个数据表要安全得多至少不会出现两个Agent同时修改一个知识节点导致覆盖的乌龙。对这套协作协议我总结的一个关键经验是各智能体的反馈通道比执行通道更值得投入开发。我们在拆解者、出题者的返回结构中设计了存疑标记位这个字段后面接了人工review列表所有不确定的内容都会集中展示给运营人员。因为有了这个机制我们才能在真实专家资源严重不足的情况下把人工介入聚焦在最值得看的地方而不是像早期版本那样需要全量Review。5.2 模型选型的实际取舍多智能体系统的模型选型有一个容易踩的误区全局只用一个旗舰模型。我们一开始也这样干后来算了一笔账发现大约有40%的调用其实是低难度任务比如把PDF章节标题抽出来、把一段操作步骤转成编号列表完全可以用更小的模型完成。我们最终的选型策略是三档混用:第一档用于任务拆分、质检判断、答疑最终生成用能力最强的多模态大模型。这些环节的错误代价最高宁可慢一点。第二档用于知识节点抽取、题目生成初稿、意图分类、提问改写用一个中档模型。这些任务特点是有相对标准的输入输出格式偶尔出点小错也能被下游质检兜住。第三档用于简单的格式清理、去重过滤、标签标准化直接上轻量模型甚至规则脚本不调用大模型也行。这个混用策略让单次全流程的综合成本比原来下降了将近七成而端到端的产出质量没有明显下降。当然前提是每个任务的质量标准定义得足够清晰能在不同模型之间切换时保持一致。多模态这块最关键的选型教训是不要用同一个多模态模型做所有模态的任务。我们试过让一个视觉-语言模型同时处理识图出题和生成示意图结果识图出题的效果很好但生成示意图时经常在细节上出错。后来就把这两条链路拆开了——识图出题用理解擅长型模型示意图生成用生成擅长型模型。两个环节之间通过文本描述中转互不干扰最终效果稳定多了。5.3 成本与延迟的平衡最后落到大家最关心的成本问题。月度账单拆开看大头是答疑服务的持续调用占比超过半数。其次是知识树拆解和题目生成的批处理任务。答疑的成本控制主要靠三招第一招是分层回答。不是所有问题都需要走完整的多模态大模型链路。意图路由先分类简单问题走检索直达——直接返回知识树里匹配到的标准文本不经过生成模型中等复杂度问题走检索模板生成只有需要综合多个来源、组织多步骤答案的复杂问题才走完整生成链路。这一条至少砍掉了四成的生成调用。第二招是答案缓存。同一个问题在不同天内被反复问到的情况非常多尤其是考试前夕的集中提问。我们把问题文本做归一化后查缓存命中直接返回缓存有效期设为七天。第三招是夜间批处理。知识树拆解和题库生成这类重任务全部放到夜间低峰时段执行。虽然是异步任务但API价格在低峰时段更友好而且即使执行慢一点也无所谓不影响白天新增内容的交付。延迟方面答疑服务的首字节响应我们控制在2秒内完整回答平均在5秒左右。内部有个三秒法则如果回答超过8秒还没返回学员大概率会直接关掉页面。现在的架构在高峰期依然会有少量超时折中的方案是前端先把正在检索知识库的进度提示展示出来给后端多争取一些时间而不是干等。说到底这一整套多智能体内容工坊跑通之后给我最大触动的一点并不是模型能力本身有多强而是把大模型嵌入企业内容生产的正确姿势是给它一个边界清晰的结构和足够细的任务分工。知识树给了它结构题库模板给了它产出标准质检熔断机制给了它容错空间人工兜底给了它试错的底气。这些工程上的约束比任何单点模型优化都能带来更实在的收益。如果你也在做类似的内容工坊我的建议是从一个最小的闭环开始——选一个工种、建一棵局部的知识树、生成一百道题、接上答疑机器人跑通之后再去横向扩展。先把这四件事做扎实比一开始就铺开十门课的想象力要有用得多。