企业官网建设流程全解析

很多人一开始学 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 生成对应的 JavaScript：

function 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 相当于把常用指令和优秀实践封装成一个可复用的包，之后在任意项目里调用这个 Skill，AI 就会自动带上对应的上下文和行为模式。

做完迷宫游戏之后，我把这次项目里反复用到的提示词和经验整理成了一个名为canvas-game-dev的 Skill。里面主要包含这几个部分：

• 初始需求模板：生成 Canvas 小游戏时需要描述的八项信息。
• 调试指令模板：描述 bug 时的三要素（操作、现象、期望）。
• 常见问题清单：Canvas 元素未加载、行列转置、坐标偏移、状态未重置等。
• 代码审查清单：AI 修改代码后要检查的六个点（变量初始化、重置逻辑、边界判断、渲染顺序、事件监听、内存泄漏）。

下次我再做贪吃蛇或者俄罗斯方块的时候，直接调用这个 Skill，Workbuddy 就会先加载这些上下文，再开始生成代码。相当于把我的"踩坑经验"变成了可复用的资产。

这个思维特别值得推荐。很多人的 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 嵌进了自己的工作流里。