从TinyGlade到Vibe Coding：意图驱动的AI编程实践

最近半年我一直在跟 AI 结对写代码，Vibe Coding 这个词也听了无数遍，但说实话，真正让我对这件事“开窍”的不是哪篇技术博客，也不是某个 AI 模型的发布——而是一款叫 TinyGlade 的游戏。

如果你还没玩过 TinyGlade，我先用一句话概括它：在一块小地皮上，你随便画几笔墙、点几个屋顶，它会自动长出窗户、烟囱、藤蔓和草地。整个游戏没有敌人，没有失败，你唯一要做的是“确定一个大概的想法”，然后剩下的细节全部交给系统补全。

听起来是不是很像我们现在的编程方式？我越来越觉得，TinyGlade 不是一个建造模拟器，它是一堂完整的 Vibe Coding 教学课，而且是反向拆给你看的那种。这篇文章我想从玩法机制、技术实现、工作流设计三个层面，把两款本质上毫不相关的东西放到一起盘一盘，说说我从一个“画小屋”的游戏里，悟出的 AI 编程实践方法。

1. TinyGlade 表面是建造沙盒，里子是一台“意图驱动的生成引擎”

我刚打开 TinyGlade 的第一反应是：这游戏的操作怎么这么少？没有资源系统，没有任务列表，没有建造菜单。你想建一面墙，不是从几十种建材图标里挑一个，而是直接按住鼠标拖出一条路径，墙就自动长出来了。

这种体验放在编程领域，对应的是 Vibe Coding 最核心的观念转变：过去我们写代码是在“砌砖”，每一块砖的尺寸、材质、砂浆配比都是自己定的；而现在我们用 AI 写代码，本质上是在“画线”，告诉系统“这里要一堵墙”，至于砖怎么铺、墙墩怎么收口，模型帮你自动补全。

1.1 没有像素级操作，只有“意图”，剩下的交给系统

TinyGlade 里有一个很典型的操作：你在地上画一个不规则的闭合区域，它会自动识别这是“房间”还是“院落”，然后以这个区域为基础生成墙体。接着你只要点一下屋顶图标，AI 会根据墙的形状自动选择合适的屋顶样式——尖顶、圆顶、斜顶都取决于你刚才画的轮廓。

这个逻辑细想一下非常厉害。开发团队没有做“玩家手选屋顶模型”这种传统交互，而是把屋顶的决策权交给了算法。算法的判断依据是你的墙形、朝向、区域面积。在 Vibe Coding 里，这就是“用自然语言描述意图，让模型自行决定实现方式”。

我见过太多人用 AI 编程还在用“指示式”Prompt：加上一个 flex 容器、item 居中、颜色 #fff 背景、加阴影。这种写法等于你在替 AI 决定每一块砖，AI 的价值只剩打字员。而 TinyGlade 给我的启发是：直接说“我想要一个居中的登录卡片”，模型自己会知道该用 flex——这才是意图驱动。

1.2 “无参数侵蚀系统”是何方神圣

玩 TinyGlade 久了你可能会发现一个细节：你永远看不到地形侵蚀、湿度、土壤厚度这些传统建造类游戏常有的参数面板。但这不代表系统没有这些逻辑。

我尝试过在一个湖边反复挖土，发现湖岸线的形状会微妙变化；尝试在斜坡上盖房子，地基会自动做阶梯状处理。这说明系统内部完全有物理/侵蚀模拟，只是它不让你直接调参数。它用视觉反馈代替了参数面板。

这给了我一个很直接的启发：**好的 Vibe Coding 也一样，不该让用户去微调“AI 温度”“top_p”“context size 配置”，而应该通过对话措辞自然控制生成风格。**同样是“帮我写一个 Python 脚本”，你加一句“给非技术人员看的，函数名要读起来像英文句子”，效果比你调半天参数好得多。TinyGlade 用“隐式参数”换来了流畅体验，说明意图驱动的系统设计中，少即是多。

2. 从“选地皮”到“选上下文”，TinyGlade 教我的第一个 Vibe Coding 原则

TinyGlade 开局会给你一块固定大小的地皮。你没办法像沙盒游戏那样无限制扩展地图。一开始我觉得这是限制，玩多了才发现这恰恰是它最聪明的地方。

地皮边界确定了生成系统的工作范围。如果系统需要在整个无限地图上判断“哪里应该长草、哪里有脚印”，它就会陷入选择瘫痪；而当你把范围限定在一个小镇地块内时，每个位置的可解释性大大增加，自动生成才能精准。

2.1 别把 AI 丢进深渊般的全局代码库

很多同学用 AI 写代码的翻车现场是这样的：把整个项目几十个文件一股脑贴进对话，然后说“帮我把订单模块优化一下”。结果 AI 回复了一堆泛泛而谈的代码，甚至改错了别处的逻辑。

这本质上是上下文失控。我玩 TinyGlade 之后，再也没这样干过——不是因为技术变了，而是我突然想通了：AI 模型的注意力集中范围，就像一块地皮，你得主动帮它圈好范围。

我现在的操作方式：只给 AI 那个订单模块的文件内容和它的直接依赖，明确指出改动边界。这就像在 TinyGlade 里选一块地皮开始建造，而不是把整个世界都铺满。地皮明确，系统才能专注生成高质量细节；上下文明确，模型才能专注生成高质量代码。

2.2 画围墙等于声明约束条件

TinyGlade 里画围墙时，只要你画出一个圈，系统就自动知道里面是你的一亩三分地，墙体自动连接闭合。这看起来是游戏交互的细节，但放到编程里就是“约束声明”：墙圈住的范围，在代码里就是我不希望 AI 超越的边界。

举个例子。我最近让 AI 帮我写一个数据导入模块。如果我只说“帮我写个导入 CSV 的功能”，它会自由发挥，甚至可能自作主张加上图形界面、多线程、自动调度。但按照 TinyGlade 的“围墙逻辑”，我会明确声明：只处理这一列映射关系、不碰数据库层、单线程跑、异常直接抛出由调用方处理。

这几个约束就像围墙，AI 生成的代码被控制在合理范围内。玩过 TinyGlade 之后你再回头看“围墙”交互，就会明白一个道理：玩家花更多时间在“画边界”上，而不是“装饰细节”上。Vibe Coding 的专家也是这个习惯——70%的 prompt 工作在定边界，30%才是描述功能。

2.3 一个小数据：地皮大小和任务颗粒度的对应关系

我统计了一下自己在 Cursor 里最近 30 次 AI 任务提交，发现一个有意思的规律：任务描述控制在 150 字以内、涉及文件不超过 3 个的时候，生成代码的一次通过率明显高；超过这个范围，代码返工的概率呈指数增长。

TinyGlade 和 Vibe Coding 的关系在这里体现得淋漓尽致。游戏设定里地皮太小了，造不出像样的建筑群；太大了，系统生成的细节会变得稀疏空洞。AI 编程的任务划分同理：单次提交的功能点应该“刚好能装下一座小屋”，而不是“一次性建一座城”。

我把这种划分方法叫做“小屋粒度”——每个任务大到有完整价值（墙、屋顶、窗户都有），小到 AI 能一次生成完（不跨三个以上模块）。批量任务的正确姿势不是把一整个项目丢给 AI，而是拆成一个个小屋，逐个盖，逐个验收。

3. TinyGlade 为什么敢“自动补全细节”，而 AI 编程却总是幻觉频出

TinyGlade 最让我津津乐道的一点是：你明明只画了几笔，它却能长出一整片藤蔓、一丛丛花草、一堆圆润的鹅卵石。你会发现一个问题——为什么游戏里的自动补全看起来“恰到好处”，而 ChatGPT 写代码却经常一本正经地生成调用一个不存在的函数？

答案不在 AI 本身，而在约束和规则。

3.1 自动补全的本质区别：是“规则兜底”还是“纯统计生成”

TinyGlade 的自动生成系统并不是一个单纯的统计模型在那里“猜”你要什么。我研究过它的一些技术分享，这套系统的核心是大量手写的程序化生成规则：墙体生成规则、屋顶匹配规则、植被分布规则，再叠加一些随机种子做出自然感。

AI 生成的权重只在关键时刻介入，做选择，而不是从零开始生成一切。这就好比它有一个“审美安全网”：无论你怎么画，墙体最终一定闭合，屋顶一定衔接在墙上，植物一定长在泥土上。

而很多人的 Vibe Coding 实践里，AI 是在没有“安全网”的情况下自由发挥，然后我们还要它保证函数存在、类型不出错。这可能吗？不可能。

我的做法是给 AI 搭三层安全网：第一层，类型系统（我在 prompt 里明确告诉它接口签名约束）；第二层，测试用例（写明期待的行为，让它生成实现来通过测试）；第三层，静态检查（生成完立即跑 lint 和类型检查，发现问题马上回滚）。

这才是“有规则的自动补全”。TinyGlade 的窗户永远长在墙上，是因为规则不允许它长在草地上——你的 AI 生成的函数永远符合接口定义，也该是因为测试和类型约束不允许它偏离。

3.2 一次实测：用“规则兜底法”让 AI 从幻觉中回头

我分享一个最近真实发生的事。我让 AI 写一个文件监控模块。第一次 prompt 我只说了一句“帮我写个监控文件夹变化的功能”，结果它给我生成了一个调用watchdog库的代码，而环境中根本没装这个库。

以前我会直接告诉它“不要用 watchdog”，但它又会换一个更冷门的库。现在我会在 prompt 里直接把“地皮边界”划出来：

帮我实现文件夹监控。约束：只用标准库os和time，轮询方式即可；不要把业务逻辑写进来；返回一个普通列表；代码里不要有阻塞主线程的循环，只封装一个纯函数。

这次生成的代码完全可用，因为我把它的“活动范围”限制在了围墙内。不会跑出去找第三方库。这个方式我起名“围墙式 Prompt”——跟 TinyGlade 里的画围墙操作是同构的：先圈定边界，再让算法在边界内自由发挥。

3.3 关于“幻觉”的重新理解

玩了 TinyGlade 之后，我对 AI 幻觉有了一个新的理解：幻觉不是模型的 bug，而是模型在没有边界约束时的自然表现。TinyGlade 里的生成算法如果没有任何规则约束，它也会生成一些抽象建筑——只是在游戏里我们可以用那叫“艺术风格”。在代码里，我们就叫它“幻觉”。

所以解决幻觉的正确方向不是换更大的模型，而是给现有模型配上更强、更细、更明确的约束规则。就像 TinyGlade 不依赖“更聪明的算法”去理解人类想要什么，而是靠精心编写的规则网络把生成结果限制在合理范围内。我后来写 prompt 时，会刻意给自己加一条检查项：“我的描述里是否足够清楚地圈定了输入、输出、边界？”缺哪一项，补哪一项。

4. 从 TinyGlade 的交互流程，倒推一套完整的 Vibe Coding 三层工作流

TinyGlade 的建造流程其实可以拆成三个步骤：先在空地上规划出大概区域，再在区域内放置主体建筑，最后通过随机装饰让它看起来像“活”的。仔细琢磨一下，这套流程跟我现在日常使用 AI 编程的节奏简直一一对应。

4.1 第一层：粉刷意图，不急着动手

TinyGlade 里你开始建造的第一笔，往往是画一条大轮廓线——这片是院子，那片是房子。做 Vibe Coding 的第一步也是这样：先用自然语言把意图“粉刷”出来。

我以前犯过的错是，一上来就要求 AI“写一个parse_config()函数解析 ini 文件然后把结果存到 dict”。这其实已经是在“砌砖”了。我现在更愿意先描述意图：“我需要一个配置读取模块，拿 ini 文件路径做输入，返回字典格式的解析结果，改配置不需要改代码。”让 AI 自己决定用configparser还是手动 split。

这里有个很微妙的心态变化：从“控制 AI 怎么做”转变成“信任 AI 能让墙自动长出来”。你会发现自己节省了大量时间，而且 AI 给出的方案往往比我的第一直觉更干净。

4.2 第二层：像“拖动小屋”一样迭代领域对象

TinyGlade 里最爽的操作是把建好的小屋整体拖到另一个位置，所有关联的台阶、栅栏、树木都会自动跟着适配。这个设计的精妙之处在于：它把“移动”这个物理操作，抽象成了对象级操作，而不是逐个移动每块砖。

对应到 Vibe Coding 里，如果你的 prompt 描述得足够“对象化”，AI 就能帮你进行模块级重构。比如你不再说“把第 30 行的判断改成>=”，而是说“把这个校验逻辑的边界条件从开区间改成闭区间，并把相关的文档注释一起更新”。AI 会像拖动整个小屋一样，把相关的位置、调用点、注释统一改掉。

我自己的经验是：想让 AI 具备这种“拖动整座小屋”的能力，前提是你已经把代码结构维护得足够模块化，就像 TinyGlade 的地基上已经做好了模块分组。模块化越清晰，AI 做对象级操作的准确率越高。

4.3 第三层：信任与校验的节奏感

TinyGlade 之所以让人觉得治愈，是因为它构建了一个“低压力、高频反馈”的循环：你画一笔，系统立刻给你反馈，每一次反馈都让你觉得“挺好，再改一笔”。这个循环里没有长时间等待，也没有一锤定音的决定。

做 Vibe Coding 的时候，我犯过的一个典型错误是：让 AI 一次性生成一个超长文件，然后等三分钟，结果得到一坨没法跑的代码。后来我把节奏调成了 TinyGlade 模式：

1. 让 AI 生成一个小函数（画一笔）；
2. 立刻跑一个测试或检查（看反馈）；
3. 满意了再继续下一步（再画一笔）；
4. 每次都问自己：整条链路现在是不是 still workable?

这么做之后我发现，代码质量提升最快的不是 prompt 技巧，而是交互节奏。在 AI 编程里，反馈速度就是信任的基础。就像 TinyGlade 你永远不会画一堵墙等 30 秒才看到它长出来——如果会，你早就不玩了。等待越短，你越敢尝试；校验越快，你越敢交给 AI 发挥。

5. 从专用工具到通用技能：TinyGlade 隐喻下的 Vibe Coding 实操清单

文章最后这一部分，我想把自己从这个小游戏里悟到的内容整理成可以直接落地的实操清单。毕竟游戏玩再开心，回到编辑器里能提升效率才是正经事。这些规则我不吹嘘适用于所有场景，但它们确实是我在最近的项目里反复验证过、值得收藏的方法。

5.1 五条可以直接“抄作业”的 Vibe Coding 规则

这一路盘下来，我提炼了五条最核心的原则，列成一张对照表，左边是 TinyGlade 里的操作，右边是 Vibe Coding 里的对应动作，方便大家快速建立关联：

这条表看着简单，但每一条背后都有实际场景的教训。尤其是第三条，很多同学让 AI 写函数不写签名，AI 自由发挥的类型五花八门，最后编译不过。其实你在 prompt 里先写清楚def load_config(path: str) -> dict[str, str]，AI 就只能在“接口围墙”里工作。

5.2 我复盘过的典型案例：一次完整的翻车与修复

讲一个反面教材。上个月我做一个数据处理脚本，想趁热打铁学 Vibe Coding，直接甩给 AI 一句话需求：“做一个数据清洗工具。”结果 AI 给我生成一个 260 行的类，带日志、带进度条、带异常重试，还引入了一个 pandas 来处理只有三列的数据。

这让我很崩溃。后来我回想 TinyGlade 的边界感，当即重写提示词，核心修改只有两点：限定“只处理 ner 模型的输出格式，其他格式直接报错”；规定“只能用标准库，不许引入 pandas”。第二次生成的结果是 40 行干净的函数，测试一下，完美通过。

这个案例让我彻底明白了一个道理：AI 编程翻车，90% 不是因为模型不够聪明，而是因为我们给模型圈的“地皮”太大了。你的意图表达得越模糊，AI 的自由度就越大，结果就越像“在海边盖了一栋楼”。而 TinyGlade 教给我们的恰恰相反——在边界内自由发挥，远胜于在无边界的空间里胡来。

5.3 几条容易踩的坑和我的经验性规避方式

一、不要在一开始就追求完美 prompt。Vibe Coding 的精髓是快速迭代。TinyGlade 里你的第一笔也可以涂得歪歪扭扭，系统会根据你的修正实时更新。先用一句话描述意图，看到 AI 的第一次反馈后，再逐步收紧边界。错误的 prompt 并不可怕，可怕的是不敢开工。

二、别让 AI 写完后立刻投入生产。就算你用“围墙式 prompt”，也要保留人工审查环节。我的习惯是把 AI 生成的代码先跑一遍测试，再用 diff 方式逐段确认改动。这不是不信任 AI，而是对自己项目的负责。

三、告别“一次性生成大项目”的幻想。TinyGlade 再治愈，它一次也只是在一小块地上建一栋房子，而不是整个星球。也许有人已经能靠 AI 一次生成整个项目，但那就像用造小木屋的方式去造摩天大楼——地基都打不稳。从一个小模块开始，验证节奏，逐步推进，这才是普通人用 Vibe Coding 做事最可靠的路径。

我在 TinyGlade 里反复拆建过很多次小屋，每一次都发现不同操作能产生截然不同的建筑风格。这让我明白，AI 时代的编程方向已经很清楚：我们不再需要精确控制每段具体代码，而是应该像在 TinyGlade 里画线一样，精准表达意图和边界，让生成引擎帮我们完成细节。把注意力从“怎么写”转移到“要什么”上，你写出来的代码和产品，才能真正长成你想要的样子。