很多人一开始学 AI习惯先找一堆理论课从神经网络讲到反向传播结果还没碰到代码就先晕了。我的做法刚好相反——先挑一个明确的小目标让 AI 工具帮我把活儿干出来再回头补理论。这次我拿 Workbuddy 做了一个走迷宫的小游戏前前后后花了大概两个晚上中间还把 Workbuddy 的 Agent 模式、自定义指令、Skill 这些能力全过了一遍。等于用一个小项目把 AI 辅助编程这条入门路走到头了。这篇文章会把整个经历完整拆开为什么选迷宫游戏当练手项目怎么用 Workbuddy 一步步生成代码、调通逻辑中间踩了哪些坑以及最后我总结出的 AI 入门路线。不管你是刚接触 AI 编程还是已经在用 Cursor、GitHub Copilot 这类工具这篇文章都能给你一些不同的视角。1. 为什么要拿迷宫游戏当 AI 练手项目1.1 迷宫游戏里藏着哪些基础我必须坦白选迷宫游戏不是因为它炫酷而是因为它颗粒度刚好合适。一个走迷宫的小游戏看起来就是个二维格子地图加键盘上下左右但认真拆下来它几乎覆盖了计算机入门最重要的一批概念数据结构二维数组存地图、队列和栈用在生成和寻路算法里。算法迷宫生成递归回溯 / Prim / Kruskal、最短路径BFS / A*。逻辑与状态管理玩家位置、终点判定、步数统计。交互与渲染键盘事件监听、Canvas 绘制或者 DOM 操作。边界处理越界、撞墙、重新开始。这么一列你会发现迷宫游戏就是一个压缩版的编程基础综合练习。做一遍这个项目等于把数据结构、算法、前端交互、状态管理全串了一遍而且每一个环节都能清楚地看到运行效果。这种即时反馈对新手特别重要因为你在写每一行代码的时候都知道它在整个系统里干了一件什么事。先说明一下我自己的技术底子我有一定编程基础也写过前端但对 AI Agent 类工具的使用经验不算深。用 Workbuddy 之前我顶多用过 AI 补全代码、解释报错这类浅层功能。所以这篇文章从一个会用 AI 但还没真正理解 AI Agent的人的角度出发记录的是整个上手过程。1.2 为什么是 Workbuddy而不是别的工具工具选型这件事我纠结过一阵子。当时手头可以选的有 Workbuddy、CodeBuddy、还有直接用 Claude 网页版手动复制粘贴。最后选了 Workbuddy核心原因有三个。第一Workbuddy 是 Agent 形态不是补全器形态。普通的 AI 编程插件更像是你的打字助手你写一半它帮你补但 Workbuddy 更像是带任务执行的伙伴你给它一个目标它能把文件建好、把代码写好、把依赖装好一步一步执行给你看。这个差异决定了整个工作流你是在派活不是补缺。第二它支持自定义指令和 Skill。这个对新手来说很有价值。别人踩坑总结出来的经验可以封装成一个 Skill 让你直接用相当于请了一个随身老师傅。后面我会详细讲我怎么把迷宫游戏的开发经验固化成一个 Skill。第三Workbuddy 支持 CLI 和 Linux 环境。这一点可能对纯前端选手无所谓但如果你以后往 AI Agent 开发方向走能跑命令行任务、能直接操作文件系统就是刚需。我想学的不是怎么在一个聊天框里把代码问出来而是怎么把 AI 嵌进我的开发流程里所以选了 Workbuddy。2. 项目需求拆解与提示词设计2.1 先画清楚功能边界很多人在用 AI 写代码时有个误区上来就一句帮我做个迷宫游戏然后等着看结果。这样做不是不行但生成出来的东西大概率不是你想的那样。AI 不像人它不会追着你问你要什么难度等级要不要计时用 Canvas 还是 DOM你说得越模糊它只能越自由发挥。我第一次就是这么干的结果 Workbuddy 给我生成了一个纯文字描述的迷宫开局画面简陋不说用方向键控制人物移动时每按一次都要等下一帧重绘。能用但完全没有游戏感。后来我重新整理需求发现关键不是把话说得多而是把边界画清楚。我最后整理出来的需求是这样的迷宫是 21x21 的网格四周是墙玩家从左上角出发终点在右下角。地图用 0 和 1 的二维数组表示0 是路1 是墙。玩家用键盘上下左右控制移动撞墙不能穿过去。界面用 Canvas 绘制格子大小 24px窗口自适应。到达终点后弹窗提示通关并显示当前步数。提供新迷宫按钮点击后重新生成迷宫。迷宫生成用递归回溯算法保证任何两个格子之间都有通路。你会发现这已经不只是一句话需求了而是一份简单的 PRD。每一步都是一个可验证的点AI 生成的代码要能通过所有这些检查才算过关。强烈建议大家在让 AI 写代码之前先花 20 分钟把需求理到这个程度。这个时间花得很值因为后面调试返工的时间会少很多。2.2 一次性把需求说清楚的关键要素我用 Workbuddy 生成迷宫游戏的过程中总结了几个让 AI 理解需求的关键要素按重要性排序如下输入输出边界比如迷宫尺寸、地图表示方式、玩家坐标的起止位置。技术栈约束用 Canvas 还是 DOM要不要引入第三方库明确说不引入任何外部依赖纯原生 JavaScript最省事。交互行为定义按键响应、撞墙、通关提示、重置功能。视觉表现要求格子大小、颜色、高亮方式。代码组织偏好单 HTML 文件还是拆成 HTML/CSS/JS 三个文件。把这些信息放在第一条消息里AI 生成的初版代码可用性会大幅提升。Workbuddy 的 Agent 模式会自己读取你的项目目录如果你已经建好了一个空文件夹它会主动在里面创建 index.html、style.css、script.js。如果这些文件已经存在它会先读取再修改而不是整个覆盖。我第一次用的时候不小心让它覆盖了手写的一些注释代码虽然影响不大但提醒大家把重要代码先提交 git 或备份这是 AI 编程时代最基本的自我保护。2.3 从零开始生成的第一个版本我用的提示词大概长这样请帮我做一个走迷宫的小游戏要求 1. 迷宫用 21x21 的二维数组表示0 是路1 是墙四周必须是墙。 2. 玩家从左上角出发终点在右下角终点格子用特殊颜色标出。 3. 用 Canvas 绘制格子大小 24px迷宫整体居中显示。 4. 支持键盘上下左右控制移动撞墙无反应不能穿透。 5. 从起点开始用递归回溯算法生成迷宫。 6. 到达终点后弹窗提示通关显示用掉的步数。 7. 页面上有一个新迷宫按钮点击后重新生成并重置玩家位置。 8. 用纯 HTML/CSS/JavaScript 实现不要引入第三方库。Workbuddy 生成完代码后我直接用浏览器打开 index.html结果页面一片空白。我打开控制台看到了一个Cannot read properties of null (reading getContext)的报错。这个错的原因是 JavaScript 加载时 Canvas 元素还不存在——传统 HTML 的解析顺序问题。我让 Workbuddy 看这个报错它立刻把脚本挪到了 body 末尾并建议我用DOMContentLoaded事件包一层这样更稳。这种报错 - 交给 AI 排查 - 修复 - 继续的循环就是整个项目开发的主旋律。你会发现纯用 AI 编程的核心技能不是写代码而是把问题描述清楚并且能判断 AI 给的建议是否合理。3. 迷宫核心算法与关键实现3.1 二维网格与迷宫表示迷宫的数据结构是整个项目的地基。我用的是 0/1 二维数组其中 1 是墙0 是路。这里有一个隐藏的细节如果你单纯地用格子是否可走来表示迷宫会很占内存。比如 21x21 的地图看起来是 441 个格子但如果每个格子都有墙或路的属性就至少需要 441 个字节。这还不算大问题但如果你把迷宫扩展到 101x101数据量就上来了绘制和寻路都会变慢。更常见的做法是用格子 墙分开存储格子是网格节点墙是两点之间的边。这样迷宫大小完全由网格密度决定而绘制时只需要检查相邻格子之间是否有墙。本次实践为了简单我还是采用了 0/1 数组因为 21x21 这个量级对渲染性能完全无压力而且数据结构直观AI 生成时不容易出错。初始状态下整个迷宫全是墙。生成算法的任务就是把墙凿开形成一个路线完整的网络。如果你直接让 AI 写一个二维数组初始化为全 1然后在里面挖路这就是典型的墙优先思路。递归回溯算法就是基于这个思路工作的。3.2 递归回溯生成迷宫的实现原理递归回溯Recursive Backtracking是生成迷宫最经典、最容易理解的算法之一。它的思路非常像一个人在一个完全黑暗的迷宫里摸索从某个格子开始随机选择一个方向前进如果旁边的格子还没被访问过就把墙打通继续往下走如果四个方向都走过就原路返回重新选一个分支继续探索。我把算法拆成几个关键步骤并让 Workbuddy 生成对应的 JavaScriptfunction generateMaze(width, height) { const maze Array.from({ length: height }, () Array(width).fill(1)); const visit (x, y) { maze[y][x] 0; const dirs [[1,0],[-1,0],[0,1],[0,-1]]; // 随机打乱方向保证迷宫的随机性 for (let d of dirs.sort(() Math.random() - 0.5)) { const nx x d[0] * 2; const ny y d[1] * 2; if (nx 0 ny 0 nx width ny height maze[ny][nx] 1) { maze[y d[1]][x d[0]] 0; visit(nx, ny); } } }; // 从 (1, 1) 开始挖路因为四周是墙 visit(1, 1); return maze; }这里有一个很关键的细节为什么要d[0] * 2一次走两步因为我们要保证挖出来的路是墙 - 路 - 墙交错的结构。如果只走一步那就只是把当前格子旁边的墙挖开了迷宫看起来会很碎不像迷宫更像随机撒了一堆点。走两步再判断就意味着我们每次打通的是相邻两个格子之间的墙中间留出至少一个格子的通道迷宫的回廊感就出来了。递归回溯生成出来的迷宫有一个特性任意两个格子之间都有且仅有一条通路不会出现环路。这意味着玩家在游戏里不会迷路迷到死胡同里出不来当然如果算法实现有 bug可能就会出现孤立区域。这也是迷宫游戏公平性的基础。3.3 BFS 寻路与碰撞检测迷宫生成之后玩家要能从起点走到终点。怎么判断能走到最可靠的方法是跑一遍 BFS广度优先搜索。BFS 的逻辑是从起点开始一层一层往外扩展先访问距离为 1 的格子再访问距离为 2 的格子一直到终点或者队列为空。如果 BFS 结束后终点没被访问到说明迷宫生成的代码有 bug起点和终点不在同一个连通区域里。在调试阶段我让 Workbuddy 加了一个隐藏功能按W键显示 BFS 路径。这个功能帮了大忙——因为有一次生成的迷宫起点区域和终点区域竟然没有连通玩家根本走不过去。追查发现是在递归回溯算法里判断越界的条件写错了应该nx width而不是nx width导致最右边一列永远不会被访问。这种逻辑错误肉眼盯着代码看反而不容易发现但有可视化路径之后一眼就能看出问题。碰撞检测方面玩家的位置用(playerX, playerY)表示每次按键先算出目标位置再检查maze[targetY][targetX] 1。如果是墙就不更新坐标同时可以给一个小震动反馈——这里我让 Workbuddy 做了个细节优化撞墙时让 Canvas 整体轻微抖动一下玩家手感瞬间提升这个交互反馈很重要。4. 用 Agent 调试与迭代的实战过程4.1 调试是对话不是自己翻代码传统开发遇到 bug第一反应是自己打开代码找问题。但用 Agent 型 AI 工具时调试逻辑变成了描述现象 - AI 定位 - AI 修复 - 你验证。这个转变一开始我不太适应总觉得不亲自看代码不放心。实际试了几次后发现效率是真的高。举个例子有一次迷宫生成后页面上出现了一根很奇怪的对角线墙从左上角一直延伸到右下角。我没去翻生成算法而是直接把这个现象告诉 Workbuddy还附了一张截图。它立刻意识到问题出在绘制函数的双层循环里for (let y 0; y height; y)和for (let x 0; x width; x)的嵌套顺序写反了导致绘制时行列转置。修复只需要换一下循环顺序几秒钟的事。还有一次更隐蔽玩家站在格子中心的偏移量计算错误。Canvas 绘制玩家时应该把玩家坐标换算成像素坐标公式是x * cellSize cellSize / 2。我让 AI 绘制的时候用了playerX * cellSize导致玩家永远显示在格子的左上角看起来像是站在墙角。这问题在走迷宫时特别明显因为玩家和墙的边缘重合了。我把这个现象描述给 Workbuddy玩家的圆形位置偏移了不在格子中心看起来像卡在墙里它立即定位到绘制函数的偏移量问题。这个过程的启示是和 AI 协作调试时描述现象越具体越有画面感AI 定位越准。最好带上在哪一步操作、看到什么、期望什么三要素。比如不要说有个 bug而是说在按向右键走到第二行第三列附近时玩家图标有一瞬间消失再按一下又出现。4.2 代码审查环节AI 写出来的代码不能直接信AI 生成的代码初版能用是一回事质量是另一回事。我在这个项目里养成了一个习惯每让 Workbuddy 改完一个功能就自己快速扫一遍它改了哪些地方再运行验证。别把所有验证都丢给 AI因为 AI 有时候会陷入自以为改好了的幻觉。有一个很典型的例子我让它加一个步数显示的功能。它的修改方式是在movePlayer函数里加了一个steps但忘了在新迷宫按钮的点击事件里重置steps 0。结果就是每次重新开始游戏步数会接着上一局继续累积。AI 在它的逻辑闭环里没有发现这个问题因为它可能只在移动这一个场景中验证了步数的变化没有走移动 - 通关 - 新迷宫 - 移动这个完整流程。试想一下如果我不检查、不验证直接把这块功能放上线那用户玩到第二局就会看到起步步数是两位数体验很差。所以我把自己的角色定位成测试责任人AI 负责生成和修改我负责验收和报告问题验收通过的标准是实际跑起来的体验不是代码看起来对不对。我还发现一个前置检查技巧让 Workbuddy 在改代码前先输出一段本次修改涉及的文件与影响范围。这样我能提前知道它会动哪些文件避免它改出无关的变量。这个习惯帮我避免过一次它把绘制函数的fillStyle从深色改成浅色的事故那次它本意只是调整玩家的高亮颜色结果把整面墙的颜色都改了。4.3 把常用能力沉淀为 Skill这个环节是我觉得 Workbuddy 和其他 AI 工具拉开差距的地方。Skill 相当于把常用指令和优秀实践封装成一个可复用的包之后在任意项目里调用这个 SkillAI 就会自动带上对应的上下文和行为模式。做完迷宫游戏之后我把这次项目里反复用到的提示词和经验整理成了一个名为canvas-game-dev的 Skill。里面主要包含这几个部分初始需求模板生成 Canvas 小游戏时需要描述的八项信息。调试指令模板描述 bug 时的三要素操作、现象、期望。常见问题清单Canvas 元素未加载、行列转置、坐标偏移、状态未重置等。代码审查清单AI 修改代码后要检查的六个点变量初始化、重置逻辑、边界判断、渲染顺序、事件监听、内存泄漏。下次我再做贪吃蛇或者俄罗斯方块的时候直接调用这个 SkillWorkbuddy 就会先加载这些上下文再开始生成代码。相当于把我的踩坑经验变成了可复用的资产。这个思维特别值得推荐。很多人的 AI 使用方式是一次性的——用完就忘下次遇到同样的问题重新踩一遍。但 Skill / 自定义指令的核心价值就是把每一次实践变成下一次的起点。5. 从迷宫游戏延伸出的 AI 学习路线5.1 提示词工程的基本功做这个迷宫游戏的整个过程中我其实一直在做提示词工程只是当时没意识到。后来回头看提示词工程的核心既不是花哨的请你以某专家的身份也不是复杂的思维链模板而就是四件事明确目标你要让 AI 产出什么边界在哪里。给出约束用什么技术栈、不做什么、风格是什么。提供样例有参考输出尽量给AI 模仿能力远比理解抽象描述强。迭代反馈第一次结果不好不是重开而是在已有结果上提修改意见。我在迷宫项目里做过一次对比用帮我写个迷宫游戏和用21x21 网格、0/1 二维数组表示、递归回溯生成、Canvas 绘制、方向键移动、通关显示步数这两份提示词跑出来的代码一个是基础玩具一个是可以直接玩的成品。差距不在 AI 能力而在我给的信息量。提示词工程最容易被忽略的一点是上下文管理。Workbuddy 这类 Agent 工具有记忆窗口如果对话太长它会忘记前面的细节。所以我养成了在关键节点主动总结需求、或者让 AI 重新输出当前项目结构的习惯。比如中途加重新加载迷宫功能时我会把前面定好的数据结构再描述一遍避免它在改代码时搞混。5.2 Agent 的工作机制与边界做完这个项目我对 Agent 这个概念的理解不再停留在AI 能聊天这个层面了。Workbuddy 的 Agent 模式给我的感觉是它像一个能操作电脑的实习生你说把迷宫入口放到左上角它会自己读代码、找函数、修改、测试然后把结果汇报给你。这不只是生成代码而是执行一个复杂的多步骤任务同时在关键节点会停下来问你。但它也有明显的边界。有一次我让它优化迷宫生成算法让迷宫包含死胡同,它给出了好几种方案但当我要它从数学上证明这个算法生成的迷宫不会产生孤立路径时它给出的解释不够严谨存在逻辑跳跃。这不是说它错了而是提醒我AI 善于做但不总是善于论证为什么对。所以在 Agent 的使用里我把 AI 定位成执行者 平行思路提供者而不是权威答案来源。涉及算法正确性、安全边界、数据准确性这些关键判断最终责任还是在人。这也是我理解 AI 编程入门中人和 AI 协作的真正含义AI 负责把想法变成代码、把报错变成修复建议人负责定义什么是对的。5.3 下一步可以怎么做扩展迷宫游戏这个项目做完之后我给自己列了几个可选的扩展方向每个方向都会指向不同的学习深度加难度分级不同尺寸迷宫、随机障碍物、限时模式这涉及到游戏平衡和状态管理。加 AI 自动求解用 BFS/A* 实时计算路径并按路径自动移动。这会把重点从开发转向算法本身。改成手机端触摸滑动控制这要处理触屏事件和响应式布局。让 AI 分析玩家行为记录每个玩家走过的路径用简单统计找出最容易走错的区域。这个方向会串到数据分析和可视化。直接复用 Skill 开发新游戏用我沉淀的canvas-game-devSkill再做一个贪吃蛇。这会验证 Skill 的复用价值。我自己下一步选的是AI 自动求解”因为正好复习 BFS 和 A*还能对比不同算法在迷宫里的表现。如果你想练手我建议也从这三个方向里挑一个因为它能让你在同一个项目上持续深化而不是每学一个概念就换一个项目一直在浅水区打转。6. 我踩过的坑和 Workbuddy 使用心得把这次经历完完整整梳理下来有几条我特别想在最后分享给其他人的经验和感受。第一AI 工具的能力上限并没有很多人想象的那么高但它对开发效率的提升是实实在在的。以前我从零做一个画布小游戏可能要先查 Canvas API、再写生成算法、再调试半天至少得一个下午。这次我用 Workbuddy第一个可用版本半小时就出来了后来反而是在加细节、优化手感、整理 Skill上花的时间更多。这说明 AI 不是把你的技术能力替换掉而是把重复劳动的时间压缩了让你把精力花在更有创造性的地方。第二用 AI 编程最大的风险不是 AI 出错而是你不会判断 AI 出错。这个迷宫项目里Workbuddy 至少出现过两次代码能运行但逻辑不对的情况一次是步数不重置一次是玩家坐标偏移。如果我没自己跑一遍、没仔细看运行效果这些问题根本不会被发现甚至会变成某种看起来正常但体验很差的隐藏 bug。所以我的建议很简单AI 生成代码你负责验收验收标准是实际体验而不是代码格式。第三Workbuddy 的 Skill 机制是我最推荐新手上手就用的功能。你不会一开始就写出完美的 Skill但你可以从第二次做同类项目时把第一次的经验整理成自定义指令然后逐渐完善。这种方式积累的不只是代码而是你把一个零散经验变成方法论的过程。我做的canvas-game-devSkill 还很简陋但下一次做游戏时我至少能省掉重复描述需求的二十分钟。最后再说一个使用细节。Workbuddy 在命令行模式下执行速度更快、也更适合自动化流程如果你想复用那些 skill最好在项目根目录建一个.workbuddy的目录把 Skill 文件放进去之后在任何一个子项目里调用都会生效。这个习惯我从迷宫游戏之后一直保留现在已经存了三四个自己的 Skill涉及 Canvas 游戏、Python 数据处理、Markdown 博客写作。这些资产比单个项目的代码更值钱因为它们是可以跨项目复用的经验结晶。如果你也想用 AI 入门编程或者把某项开发技能提上来可以照着我这条路走一遍选一个明确的小项目想清楚需求用 Agent 工具生成自己负责验收和反馈最后把经验沉淀成可复用的 Skill。做完一个完整闭环你对 AI 的理解就不只是能聊天、能写代码了而是真正把 AI 嵌进了自己的工作流里。