1. 从“贴Prompt”到“真学习”一个AI编码者的困境与觉醒如果你最近也在用各种AI编码助手比如GitHub Copilot、Cursor或者尝试过Claude、GPT-4来写代码那你很可能和我有过一样的感受一开始是惊艳然后是依赖最后是隐隐的不安。这种不安我称之为“贴Prompt工程师”的困境。你输入一段需求AI吐出一大段代码你复制粘贴跑一下有问题就再贴一段更详细的Prompt去修正。整个过程里你的大脑更像是一个需求翻译器和结果校验器至于代码为什么这么写、有没有更好的架构、背后的设计模式是什么你可能根本没时间也没动力去深究。代码是跑通了任务完成了但你感觉自己像个“二传手”知识并没有沉淀下来离开了AI面对一个全新的复杂问题可能依然无从下手。这正是我决心改变的状态。我不想只成为一个高效的“贴Prompt”的人我希望AI编码的过程能反过来促进我自己的学习和成长让每一次代码生成都变成一次有深度的“刻意练习”。这个想法促使我深入研究了AI Agent和工作流技术并最终选择用WorkBuddy这个平台亲手打造了一个属于我自己的AI编码Skill。这个Skill的核心目标不是简单地“生成代码”而是“在生成代码的过程中引导我思考并帮我构建可复用的知识体系”。它涉及的核心技术栈正是当前AI应用开发的前沿LangGraph用于构建有状态、可循环的工作流以及围绕特定领域比如编码设计的Skill机制。简单来说我这个Skill就像一个坐在你身边的“教练型”编码伙伴。当你提出一个需求时它不会立刻给你最终答案而是可能会先问你几个澄清性问题帮你拆解问题在生成代码后它会自动添加详尽的注释甚至用简单的图示解释关键算法逻辑它还会把本次任务中涉及到的关键概念、设计模式自动整理归档到你指定的知识库比如Notion或Obsidian里。这样一来每一次编码互动都是一次小型的“学习-实践-归档”闭环。这篇文章我就来详细拆解我是如何用WorkBuddy和LangGraph实现这个想法的从设计思路、技术选型、具体实现到踩过的坑希望能给同样不想停留在“贴Prompt”阶段的开发者们提供一条可行的实践路径。2. 为什么是WorkBuddy与LangGraph技术选型的深层考量当决定要做一个促进学习的AI编码助手时我评估了几个方向直接基于OpenAI API自研、使用LangChain框架、或者采用更上层的AI Agent平台。最终选择WorkBuddy并决定在其基础上用LangGraph构建核心工作流是基于以下几个关键考量2.1 放弃纯API调用从工具到伙伴的范式转变直接调用大模型API如GPT-4、Claude-3是最灵活的方式但也是成本最高的方式——这里说的成本不仅是API Token费用更是开发和维护成本。你需要自己处理对话状态管理、工具调用Function Calling的解析与执行、长期记忆的存储与检索、以及复杂任务的多步骤规划。这相当于要从头造一个“AI大脑”的调度中枢。对于我的目标——“构建一个引导学习的编码伙伴”这个中枢的逻辑会异常复杂。我需要它能够根据对话上下文决定何时该生成代码何时该提问何时该调用知识库检索何时该进行解释。纯API调用难以优雅地管理这种有状态、多分支的工作流。2.2 LangChain与LangGraph的差异工作流 vs. 状态机LangChain是一个优秀的框架它将大模型、工具、记忆等模块化提供了丰富的“链”Chain来组合它们。在早期我用LangChain的LCELLangChain Expression Language构建过一些简单的链。但当我需要实现“循环”和“基于状态的路由”时LCEL就显得有些吃力。例如我的Skill需要这样一个逻辑生成代码 - 询问用户“是否需要我解释其中的递归逻辑” - 如果用户说“是”则进入“解释模式”用图表和文字进行说明如果用户说“否”或“继续”则询问下一个问题或结束。这种基于上一个节点输出结果来决定下一个节点的能力是一个典型的有向图结构并且图中可能存在环。这正是LangGraph解决的问题。LangGraph可以看作是LangChain之上一个专门用于构建有状态、多参与者工作流的库。它将工作流中的每一步定义为一个“节点”Node节点之间的连接由“边”Edge定义而决定走哪条边的逻辑由“路由”Router函数控制。整个工作流的状态State是一个共享对象在各个节点间传递和修改。这完美契合了我对“编码教练”的设想整个交互过程是一个状态机根据用户反馈和中间结果在不同的“教学模式”如拆解、生成、解释、归档间切换。注意很多人容易混淆LangChain和LangGraph。你可以粗略地理解为LangChain提供了构建AI应用所需的“材料”模型、工具、记忆等和简单的粘合剂Chain而LangGraph则提供了设计并运行复杂“流水线”或“决策流程图”的蓝图和引擎。对于需要复杂逻辑和循环的AgentLangGraph是目前更优雅的解决方案。2.3 选择WorkBuddy作为承载平台集成与部署的便利性有了LangGraph构建的核心工作流“大脑”我需要一个“身体”来承载它让它能够被方便地调用、管理并与真实环境集成。这就是我选择WorkBuddy的原因。WorkBuddy是一个AI Agent创作与分发平台它核心的概念就是Skill。一个Skill就是一个具备特定能力的AI智能体。WorkBuddy的优势在于Skill即服务它帮我处理了最繁琐的部分用户界面聊天窗口、对话历史管理、Skill的发布与版本控制。我只需要专注于用LangGraph实现这个Skill的核心逻辑。无缝集成工具WorkBuddy支持轻松配置各种工具Tools比如计算器、网络搜索、知识库连接Notion, Obsidian、代码执行环境等。我的“学习归档”功能就需要调用Notion API来更新页面这在WorkBuddy里可以很方便地封装成一个工具供LangGraph节点调用。上下文与记忆管理WorkBuddy为每个Skill对话提供了上下文管理我可以直接利用其内置的对话历史作为短期记忆而将长期的知识点归档到外部系统实现了记忆的分层管理。社区与生态WorkBuddy正在构建Skill商店这意味着未来我可以分享或发现其他优秀的Skill这种可组合性带来了更大的想象空间。因此我的技术栈最终定为WorkBuddy平台作为载体和交互层 - 内部使用LangGraph构建核心的、有状态的教学工作流 - 利用WorkBuddy的工具集成能力连接知识库等外部服务。这个组合让我能在较高抽象层级上设计Agent行为同时又能扎实地落地每一个细节功能。3. “教练式”编码Skill的核心工作流设计我的Skill我给它起名叫“CodeMentor”。它的核心目标不是最快地给出代码而是最大化用户在每次交互中的学习收益。因此它的工作流设计充满了“互动”和“分支”。下面我详细拆解用LangGraph实现的这个工作流图。整个工作流的状态State我定义为一个Python字典包含以下关键字段{ “user_request”: “原始用户需求” “clarified_details”: {“关键点1”: “值1”, ...} # 澄清后的问题细节 “generated_code”: “生成的代码片段” “explanation_required”: [“概念A”, “算法B”] # 需要解释的知识点列表 “knowledge_points”: [ {“title”: “设计模式策略模式” “content”: “...” “reference”: “代码行10-25”} ] # 待归档的知识点 “conversation_history”: [...] # 精简的对话历史 “next_step”: “clarify” | “generate” | “explain” | “archive” | “end” # 决定下一个节点 }工作流由以下几个主要节点构成它们通过条件边连接### 3.1 节点一需求澄清与拆解 (Clarify Node)这个节点的任务是“不急于动手先问清楚”。当用户提出“帮我写一个快速排序函数”时一个普通的AI助手可能直接生成Python的quicksort实现。但CodeMentor会先触发这个节点。节点动作分析user_request结合conversation_history生成1-3个关键的澄清性问题。例如“你希望排序的对象是数字列表还是包含复杂对象的列表如果是复杂对象排序键是什么”“你需要的是原地排序in-place还是返回一个新列表”“你对算法的时间/空间复杂度有特殊要求吗还是以代码简洁清晰为首要目标”状态更新将用户的回答整合到clarified_details中。同时将next_step设置为“generate”。设计理由这个过程模拟了资深程序员接到任务时的思考。它强迫用户和我自己在编码前明确边界条件这是写出健壮代码的第一步也是最重要的学习环节之一——学会定义问题。### 3.2 节点二代码生成与注释 (Generate Node)在问题清晰后进入代码生成节点。这里的重点不是生成代码本身这步反而相对标准而是生成“教学级”的代码。节点动作根据clarified_details生成满足需求的代码。关键步骤在生成代码后立刻要求大模型为这段代码添加超详细的注释。注释不仅包括“这行在做什么”更要包括“为什么这么做”设计决策和“潜在的陷阱”边界情况。例如在快速排序的partition函数里注释会解释为什么选择某个元素作为pivot、循环不变量是什么、如何处理重复元素。自动分析代码提取其中涉及到的关键编程概念如“递归”、“双指针法”、“惰性求值”并将其放入explanation_required列表。状态更新填充generated_code和explanation_required。将next_step设置为“explain”如果解释列表非空或“archive”。实操心得我最初是让模型一次性生成带注释的代码效果不稳定。后来拆成两步先生成纯净代码再将其作为输入要求模型“以资深工程师教导新人的口吻”添加注释。这样生成的注释质量更高教学性更强。### 3.3 节点三交互式解释 (Explain Node)这是体现“教练”角色的核心。当explanation_required列表不为空时工作流进入此节点。它不是一股脑地全部解释而是交互式地、逐个知识点地进行。节点动作从列表中取出第一个知识点如“递归”。生成对该知识点的解释。这里我强制要求解释必须包含两部分文字描述 ASCII示意图或伪代码流程。例如解释递归时会画出调用栈的ASCII图。向用户展示解释并询问“关于‘递归’的概念我解释清楚了吗是否需要我结合刚才的代码再讲一个更具体的例子回复‘清楚’、‘再举个例子’或‘继续下一个’”状态更新根据用户反馈。如果用户说“再举个例子”则next_step仍为“explain”但节点会基于同一个知识点生成一个扩展案例。如果用户说“清楚”或“继续”则将该知识点从explanation_required列表中移除并检查列表是否为空从而决定下一个步骤是继续解释还是进入归档。设计理由学习需要反馈。这个交互循环模拟了“讲授 - 询问理解程度 - 调整教学策略”的真实教学过程。它让用户有控制感可以按自己的节奏学习。### 3.4 节点四知识提炼与归档 (Archive Node)“学而时习之”。如果不做记录再好的互动最终也会被遗忘。这个节点的目标是将本次会话的“学习成果”结构化地保存下来。节点动作分析整个对话历史、生成的代码及澄清的细节。提炼出1-3个最核心的知识卡片。每张卡片包括标题如“Python中的装饰器语法糖”、核心内容简洁的定义和要点、代码示例本次生成的代码片段、关联概念如“闭包”、“高阶函数”。调用WorkBuddy配置好的Notion工具将这些知识卡片作为新的子页面添加到用户指定的“编程知识库”数据库中。状态更新将生成的知识卡片内容存入knowledge_points。将next_step设置为“end”标志着本次教学会话圆满结束。避坑指南自动归档最大的挑战是提炼的准确性。最初模型有时会提炼出无关或过于宽泛的概念。我的优化方法是在Prompt中严格要求它“必须且仅从本次对话已出现的代码和讨论中提取概念”并给出固定的卡片格式。同时归档动作是自动的但会在完成后告知用户“已为您将‘XX概念’和‘YY模式’归档至您的Notion知识库方便日后回顾。”### 3.5 路由逻辑工作流的指挥棒LangGraph的魅力在于“条件边”。我的工作流中从一个节点出来后下一步去哪由“路由函数”根据当前state决定。def route_after_generate(state: dict) - str: if state[“explanation_required”]: return “explain” # 有需要解释的就去解释节点 else: return “archive” # 没有就直接归档 def route_after_explain(state: dict) - str: if not state[“explanation_required”]: # 列表已空 return “archive” else: return “explain” # 列表还有内容继续解释下一个这种显式的状态驱动路由使得整个工作流的逻辑非常清晰、可调试远比用复杂的if-else语句写在单个Prompt里要可靠得多。4. 在WorkBuddy中构建与调试Skill的实战记录设计好工作流后接下来就是在WorkBuddy平台上将其实现为一个可用的Skill。这个过程并非一帆风顺。### 4.1 环境搭建与初始配置首先需要在WorkBuddy官网创建一个账户并创建一个新的Skill。WorkBuddy提供了两种开发模式图形化编排和代码编辑。对于我这种基于LangGraph的复杂工作流毫无疑问选择代码模式。创建Skill并连接资源在Skill设置中需要配置几个关键部分模型供应商我选择了OpenAIGPT-4作为核心模型因为它在代码生成和复杂指令遵循上表现最稳定。WorkBuddy支持配置API Key费用会走你自己的账户。工具配置这是关键。我配置了两个工具notion_append_page: 这是一个自定义工具封装了Notion API。你需要先在Notion创建一个集成Integration获得API密钥和数据库ID然后在WorkBuddy的工具配置里填入这些信息并写好工具的描述供模型理解何时调用它。search_web: 对于某些需要最新文档或社区解答的概念解释我允许Skill在必要时进行网络搜索。我使用了Serper API一个搜索API来实现。技能说明Instructions这里填写的是整个Skill的“系统提示词”用于设定它的角色和基础行为准则。我写得很详细例如“你是一位耐心、注重教学的程序员教练目标是帮助用户真正理解代码而不仅仅是完成任务...”。导入LangGraph并构建工作流WorkBuddy的代码编辑器支持Python。我需要将本地开发好的LangGraph工作流代码移植过来。核心步骤是定义好前面提到的State结构。用node装饰器定义各个节点函数clarify_node,generate_node等。用add_conditional_edges来设置路由。最后编译成一个Graph对象并暴露一个入口函数如run_mentor给WorkBuddy。### 4.2 调试过程中遇到的典型问题与解决问题一状态State污染与隔离在早期测试中我发现不同用户会话之间的状态偶尔会串扰。比如用户A的问题细节残留在了用户B的会话中。这是因为最初我错误地将工作流对象设为全局变量。根因WorkBuddy为每个独立的用户对话会话Session调用一次Skill的入口函数。如果工作流对象是全局的且其内部状态没有在每次调用时重置就会导致串扰。解决方案确保在Skill的入口函数内每次调用都重新实例化一个新的工作流对象和初始状态。将LangGraph的编译和运行放在入口函数内部。def run_mentor(user_input, conversation_history): # 每次调用都创建新的初始状态 initial_state { “user_request”: user_input, “clarified_details”: {}, “generated_code”: “”, “explanation_required”: [], “knowledge_points”: [], “conversation_history”: conversation_history[-5:], # 只保留最近5轮作为上下文 “next_step”: “clarify” } # 创建图 workflow create_mentor_graph() # 运行 final_state workflow.invoke(initial_state) return final_state[“response”] # 将最终响应返回给WorkBuddy问题二工具调用的权限与错误处理在归档节点调用Notion工具时经常因为页面权限、数据库字段不匹配等问题失败导致整个工作流中断。根因LangGraph节点中调用工具时缺乏健壮的错误处理。一旦工具调用抛出异常整个图就会停止。解决方案在每个需要调用工具的节点函数中使用try...except进行包裹。在except块中可以做两件事1. 将错误信息友好地返回给用户如“知识库更新失败可能是权限问题请检查Notion集成设置”。2. 将next_step设置为一个安全的后续步骤如“end”避免工作流卡死。同时将本应归档的知识点以纯文本形式输出在对话中作为补救。问题三解释节点的“无限循环”风险在交互式解释节点如果用户一直回复“再举个例子”理论上会陷入无限循环。根因路由逻辑route_after_explain只检查解释列表是否为空没有设置单个知识点的最大解释次数。解决方案在State中增加一个计数器例如explain_attempts_for_current_topic。在explain_node中每次为同一个知识点生成新例子时计数器加1。在路由函数中除了检查列表是否为空还要检查该计数器是否超过阈值比如3次。如果超过则主动结束该知识点的解释并提示用户“我们已经讨论了多个例子建议您先动手实践一下。我们继续下一个知识点吗”然后将next_step设置为继续解释或归档。这引入了“教学节奏”的控制。### 4.3 效果优化让教学更“人性化”基础流程跑通后我开始优化体验让它更像一个真正的“教练”。个性化开场在clarify_node不只是问干巴巴的问题。我会让模型根据用户问题的复杂度调整提问的语气。对于简单问题“写个Hello World”快速进入正题对于复杂问题“实现一个简单的区块链”则会先给予肯定和鼓励“这是一个很棒的学习项目让我们一步步来拆解它...”再开始提问。代码审查视角在generate_node生成代码后我增加了一个可选的“代码审查”环节。模型会以审查者的身份对刚生成的代码提出1-2个改进建议例如“这里可以用列表推导式更简洁”、“考虑添加类型注解提升可读性”并询问用户是否愿意采纳。这引入了“迭代优化”的学习视角。学习反馈收集在会话最后archive_node之后Skill会多问一句“关于今天的编程学习你觉得哪个环节对你最有帮助或者还有什么困惑吗” 这个反馈不会影响状态但会记录在日志里供我后续分析持续改进Skill的教学策略。5. 从“使用”到“创造”Skill带来的思维转变与能力提升构建并持续使用CodeMentor这个Skill几个月后我深刻地感受到它带给我的变化这远不止于多了一个好用的工具。### 5.1 被动消费变为主动设计以前用AI写代码我是“消费者”被动接受AI的输出。现在我是“设计者”。为了教会AI如何教学我必须首先把我认为“好的学习过程”抽象化、流程化、节点化。这迫使我去思考一个新手程序员在面对问题时最常缺失的环节是什么从理解需求、到设计思路、再到代码实现和复盘哪些步骤是可以被结构化引导的这个过程极大地锻炼了我的教学法设计能力和元认知能力——即对自己学习过程的认知和调控能力。### 5.2 对代码的理解从“黑盒”到“白盒”为了让Skill生成优质的注释和解释我必须为它提供极其精准的Prompt。例如不能只说“添加注释”而要说“请为这段快速排序代码添加注释注释需分为三个层级1. 函数级注释说明功能、输入输出和算法思想2. 区块级注释解释每个循环或条件判断的目的3. 关键行注释说明容易出错的边界情况处理。” 为了写出这样的Prompt我自己必须对“快速排序的注释应该怎么写”有非常清晰的认识。这倒逼我去深入研究那些我自以为“熟悉”的算法和模式我的代码注释能力也因此大幅提升。### 5.3 构建可复用的知识网络自动归档到Notion的功能起初只是为了“保存”。但随着时间的推移它形成了一个属于我个人的、高度结构化的“编程知识图谱”。每个知识点卡片都关联着具体的代码实例和产生它的上下文。当我在未来遇到类似问题时我不仅可以搜索代码更能快速回顾当时的学习要点和设计决策。这个外部化的“第二大脑”极大地缓解了记忆负担让我的学习成果得以沉淀和串联。### 5.4 对AI Agent技术栈的深度掌握通过这个项目我不仅仅是用了LangGraph和WorkBuddy而是真正理解了它们解决的问题域。我熟悉了有状态工作流的设计模式理解了工具调用的封装与错误处理实践了复杂AI应用的分层架构交互层、逻辑层、工具层。这种从零到一构建一个复杂、可用的AI Agent的经验是任何教程都无法替代的。它让我在面对其他Agent框架或需求时具备了快速理解和评估的能力。### 5.5 对“人机协作”的新认知最终CodeMentor并没有取代我而是重塑了我的工作流。我不再是和AI进行“一问一答”的线性交互而是与一个按照我设计的教学逻辑运行的“智能伙伴”进行螺旋式、启发式的对话。它有时会问我没想到的问题澄清节点有时会给我带来新的视角代码审查建议。这种协作关系更接近一个理想的“师徒”或“结对编程”场景其中AI承担了部分引导和知识管理的职责而我则专注于更高层次的思考、决策和创造。回过头看“不想成为只会贴Prompt的人”这个起点通过“用WorkBuddy和LangGraph构建一个教学型Skill”这个实践我确实走出了一条让AI编码助力真实学习的路。这条路的核心不在于用了多酷的技术而在于将学习的主动权重新夺回自己手中将AI从“答案生成器”转变为“学习过程的设计伙伴”。如果你也感受到了“贴Prompt”的焦虑不妨尝试一下这个思路选择一个你常做的任务思考如何用Agent工作流将其改造成一个促进自己成长的过程然后动手实现它。这个构建的过程本身就是最深刻的学习。
)
