Posts

基于 2025–2026 年现实数据的推演与印证 调研时间：2026-06-29 一、现实数据对核心推演的印证 推演1：「从写代码到描述意图」——已在发生，速度超出预期 Sonar 开发者调查（2025）：42% 的代码已是 AI 生成或 AI 辅助产出，预计 2027 年这一比例超过 63% 数字应用研究（2026）：AI 编程工具采用率达到 84–91%，覆盖了绝大多数主流开发者 Gartner 预测：2026 年底，75% 的开发者将把更多时间用于"编排与架构"而非直接写代码 但有一个微妙的反转值得注意：Fastly 2025 年 7 月对 791 名开发者的调研发现，高级工程师比初级工程师多交付 2.5 倍的 AI 代码——这说明 AI 不是均匀地赋能所有人，而是放大了有经验者的优势。中间层工程师的消失，可能不是"晋升"，而是两极分化。 推演2：「Vibe Coding 让非程序员也能开发」——已成真实工作流 Karpathy 在 2025 年提出的 Vibe Coding 概念，到 2026 年已演变成真实的工作流 产品经理直接用自然语言交付原型的案例大量涌现 「写代码变成说需求，软件创造的入场券从掌握编程语言变成能清晰表达想法」 然而，一个重要的新趋势正在出现：从 Vibe Coding 到 Spec Coding 的进化（钛媒体，2026年初）。纯粹的"感觉驱动"开发正在暴露出严重的可维护性问题——AI 生成的代码缺乏结构规范，导致后续迭代困难。行业正在往更结构化的「先写规格，再让 AI 实现」方向走，这和"验收标准（自然语言）→ AI生成实现+测试"模型不谋而合。 推演3：「部署复杂度趋近于零」——AI Agent 化的 CI/CD 正在推进 Deloitte 预测：2025 年 25% 的企业启动 Agentic AI 试点，2027 年增至 50% 自主 AI Agent 驱动的 CI/CD 系统正在实验阶段：自动代码分析、测试合成、自愈系统 2028 年预测：33% 的企业软件应用将内嵌 Agentic AI 但一个关键挑战显现：Stack Overflow 数据显示，尽管 AI 编程工具采用率超过 84%，对 AI 准确性的信任度却只有 29%——现实数据直接用数字量化了"信任"这个问题。 ...

tclaw 以前有个功能是内置轻量小程序，本意是让用户自定义一些个性化小工具，比如 todo、番茄时钟之类的。但随着 FBR skill 的完善，FBR skill 已经可以实现大多数带 UI 的程序功能，两者开始有点重叠。 FBR skill 和 mini app 本质上是同一类东西——都是带 UI 的内置工具，但名字不同，理解成本很高。FBR skill、skill、mini app 三个概念放在一起，很容易让人搞不清楚区别。 于是决定统一叫 App：带 UI 的工具就是 App，不管是游戏开发工具还是系统维护工具，都挂在同一个地方，一眼就知道是什么。 tclaw 是我在做的 Agent 运行时，感兴趣可以去 tclaw 体验。

本文基于 Tiled 的 Wangset 规范，以 corner 类型为主讲解如何标注 tileset、让编辑器自动选出正确的边角 tile。 一、什么是 Wangset 手动拼 tilemap 时，每次都要自己判断某个位置该用"左上角 tile"还是"上边 tile"——一旦地形形状复杂，就很容易选错。 Wangset 解决这个问题：你只需要一笔刷下去，系统根据周围邻居自动选出正确的 tile。 核心思路是给每个 tile 标注它的每个角/边属于哪种地形颜色，绘制时系统计算当前格子的周围情况，再去 wangset 里找最匹配的 tile。 → 二、三种类型 类型 使用的 bit 适合的地形 corner 4个角（NW/NE/SE/SW） 填充型：城墙、草地、水域 edge 4条边（N/S/E/W） 线条型：道路、河流、栅栏 mixed 全部8个 bit 复杂过渡，需要更多 tile 大多数情况用 corner 就够了。 corner 类型虽然只标角，但通过角的组合，间接表达了所有的边和拐角情况。 ...

调研范围：算法库、引擎内置方案、独立工具、AI 辅助生成 适用决策：2D 游戏/应用中的 Tilemap 自动生成方案选型 三条主路线 当前主流技术路线分三大方向： 约束传播类（WFC 及变体）：以 Wave Function Collapse 为代表，通过样例学习约束规则自动生成视觉一致的 tilemap，是近年最受社区关注的方向，适合有样例地图、追求局部一致性的场景。 传统程序化生成（PCG）：包括 BSP 分割、随机游走、噪声函数（Perlin/Simplex）、房间连接算法等，技术成熟、可控性强，是引擎内置方案的主流实现基础，适合工程化生产环境。 AI/ML 辅助生成：包括 GAN、扩散模型、强化学习等方向，处于学术探索阶段，少数工具已产品化，适合内容需求量极大且愿意投入训练成本的团队。 核心选型建议： 快速上手 + 风格一致 → WFC（fast-wfc 或引擎插件） 工程稳定 + 高可控 → Perlin Noise + BSP/房间算法（引擎原生） 编辑器辅助 + 团队协作 → LDtk + Auto-layer 规则 大规模内容生成研究 → PCGML 方向（学术） 一、约束传播类：WFC 及变体 技术原理 Wave Function Collapse（WFC）由 Maxim Gumin 于 2016 年提出，本质是一种约束传播 + 回溯搜索算法。输入一张样例 tilemap，算法自动提取相邻关系约束，再在新画布上逐格"坍缩"——每格从所有可能 tile 中选一个满足邻居约束的值，直到整张图确定。 核心优势： 无需手写规则，从样例自动学习 输出视觉上与样例风格高度一致 可保证局部邻接关系合法（无穿墙、无悬空） 核心缺陷： 可能出现矛盾（contradiction），需重试 全局结构控制弱（无法保证有入口/出口） 大地图生成速度较慢 主要项目对比 项目 语言 Stars（约） 许可证 特点 适用引擎 mxgmn/WaveFunctionCollapse C# ~23k MIT 原版实现，含 Overlapping 和 Tiled 两种模式 任意（命令行） fast-wfc C++ ~1.1k MIT 性能优化版，支持并行；适合嵌入 C++ 项目 任意 godot-wfc GDScript ~300 MIT Godot 4 插件，直接操作 TileMapLayer Godot 4 unity-wave-function-collapse C# ~800 MIT Unity 集成，支持 3D Tile Unity wfc-rust（多个实现） Rust ~200-400 MIT 高性能，适合服务端生成 任意 Tessera C# ~600 MIT Unity 插件，扩展了 WFC 支持约束自定义 Unity superpositioned TypeScript ~150 MIT 浏览器端 WFC，带可视化 demo Web/JS WFC 变体与改进方向 变体 解决的问题 代表实现 Constraint-augmented WFC 加入全局约束（保证连通性） BorisTheBrave 的多篇博客 + 参考实现 Hierarchical WFC 先生成大结构再细化 学术论文方向，暂无成熟库 WFC + A* 生成后用寻路验证可玩性 需自行组合 Automatic Tiling（Auto-Tile） 非约束传播，基于位掩码规则自动选 tile RPG Maker、Godot Terrain、LDtk Auto-layer 二、传统程序化生成（PCG） 核心算法类型 算法 原理 典型用途 优点 缺点 Perlin/Simplex Noise 连续随机函数生成高度图 地形/海拔/生物群系 平滑自然，速度极快 难以控制宏观结构 BSP（二叉空间分割） 递归分割空间生成房间 地下城、室内关卡 结构规整，无重叠 风格单一，走廊感强 随机游走（Drunkard’s Walk） 随机方向掘进生成通道 洞穴、有机地形 风格有机，实现简单 不可预测，需大量后处理 Cellular Automata 生命游戏规则迭代平滑 洞穴地形、平滑地貌 视觉自然，易于理解 生成结果不确定，难以调控 房间+连廊（Room & Corridor） 先放房间再连接通道 RPG 地下城 可控性强，标准做法 需要额外的装饰逻辑 Voronoi 分割 以随机种子点划分区域 地区划分、生物群系 视觉多样，可配合 Noise 实现稍复杂 L-System 文法规则递归展开 植被、分形结构 视觉有层次感 调参复杂，学习成本高 主要库与框架对比 项目 语言 Stars（约） 定位 主要功能 libtcod C/C++/Python ~1.5k 经典 Roguelike 工具库 BSP、随机游走、FOV、寻路 rot.js TypeScript ~2.3k 浏览器端 Roguelike 工具库 多种地图算法、随机数、FOV gdungeon（Godot） GDScript ~500 Godot 专用地下城生成 BSP + 走廊连接 dungeon-generator（npm） JavaScript ~200 轻量地下城生成 房间+连廊 noise.js / open-simplex-noise JavaScript ~1k+ Noise 函数库 Simplex/Perlin 多维噪声 FastNoiseLite C/C#/多语言 ~3k 高性能 Noise 库 多种 Noise 类型，Unity/Godot 均有移植 mapgen4 C++ ~700 岛屿地图生成 Voronoi + 物理侵蚀模拟 引擎内置 PCG 能力 引擎 内置 Tilemap 生成支持 典型方案 Godot 4 TileMapLayer + Terrain 系统（Auto-tile） 内置地形自动拼接；PCG 需脚本实现 Unity Tilemap + Rule Tile + Scriptable Tiles Rule Tile 可做简单 Auto-tile；复杂 PCG 靠插件 GameMaker 内置 tilemap 函数 需手动实现算法 Phaser 3 内置 Tilemap（配合 Tiled） 无原生 PCG，靠 JS 脚本 LÖVE2D 无内置 tilemap，靠社区库 STI（Simple Tiled Implementation）读取 Tiled 数据 三、AI/ML 辅助生成（PCGML） 技术路线概览 方法 原理 成熟度 代表工作 GAN（生成对抗网络） 训练生成器模仿真实地图分布 🟡 中（学术可用） DCGAN for Mario levels（Volz 2018） VAE（变分自编码器） 学习地图潜空间，插值生成 🟡 中 Latent Variable Evolution 扩散模型（Diffusion） 图像级地图生成，细节丰富 🟡 中（2023-2024 新兴） ControlNet 配合 tileset 风格化 Transformer/LLM 把 tilemap 当序列，自回归预测 🟡 中 GPT-2 生成 level 序列 强化学习（RL） 训练 Agent 设计关卡 🔴 低（难以实用） PCGRL（Khalifa 2020） Markov Chain 基于转移概率的序列生成 🟢 高 简单实现，效果有限 Evolutionary Algorithm 遗传算法优化地图适应度 🟡 中 配合可玩性评估函数 新兴方向：LLM 辅助关卡设计 近期（2024-2025）出现了用 LLM 作为关卡设计助手的实验性方向： ...

沉寂了一段时间 随着 tclaw 功能逐渐完善，有点失去方向了，失去目标了，沉寂了一段时间，不知道该开发什么。 感觉它好像什么都能做，又什么都不能做。和同类产品拉不开差距。缺少对一个具体领域的精准支持，什么都做了一点，什么都做得不深。 后来用 tbrain + tclaw 测试多 agent 协作开发游戏，做出来的几个游戏感觉效果还不错。但问题也很明显，游戏里的美术资源都是AI画的基础色块、简单几何，如果当小游戏demo，验证游戏原型没问题，但如果想做完整的游戏，没有一个像样的美术资源不行。 网上有大量免费的高质量美术素材，像素风、卡通风各种风格，可以先方便搜索下载，然后再处理编辑素材，先不生成美术，后面可以做。 于是方向就出来了：先深挖游戏开发领域。 十几年的游戏开发经验，我对这个领域很熟悉。 想清楚要做什么 看一下具体需要做什么： 美术素材搜索，从多个网站聚合搜索，用户选好后自动下载 切图，大图切小图、小图合大图，支持各主流引擎的 atlas 格式 序列帧动画的编辑和预览 Tilemap 编辑，自动生成地图 这些都是游戏开发的基本需求，先支持这些吧。 怎么做 这些工具本身不依赖 AI，就算没有 AI 能力也能完成功能。tclaw 的文件浏览器就是这样一个本地工具，本身已经支持根据文件后缀定制渲染——只要把这个能力扩展成支持插件的模式，就可以随意扩展了。 但具体怎么实现需要想一想。tclaw 本身已经有插件系统了，这里直接叫"插件"不合适，容易混淆。和 AI 讨论了一番，感觉做成 skill 比较合适——现有的 skill 不支持 UI 显示，需要为这类 skill 加上 UI 能力。调用某个编辑器时，本质上就是显示这个 skill 的 HTML 界面，配上对应的操作。 另外，因为 tclaw 是 AI 原生的工具，每个插件还需要支持 AI 直接调用的接口——这部分不需要 UI，纯逻辑就行，所以 UI 和逻辑需要分开，这就有了 FBR（File Browser Renderer）。目前做了四个：切图（sprite-slicer）、序列帧动画编辑（frame-animator）、图集打包（atlas-packer）、Tilemap 编辑（tilemap-editor）。为此也整理了一套 FBR skill 的开发规范和参考示例，方便以后自己或别人继续扩展。 终于引入了 goja 现在 AI 写代码很方便，应该任何人都能很随意地写自己需要的工具才行。FBR skill 的 UI 部分靠浏览器实现没问题，但要让 AI 直接调用 FBR skill 的接口，要么走无头浏览器，要么走纯 JS。无头浏览器感觉不太爽，因为本质就是纯逻辑，非得经过浏览器感觉很重，纯 JS 就需要引入 JS 引擎。 ...

从 DAG 到行为树 tbrain 最初的任务调度是 DAG（有向无环图）：brain agent 把 job 拆成带依赖关系的任务列表，orchestrator 按依赖顺序执行。这套机制简单直接，但有一个缺陷——缺乏条件分支和自适应能力。任务成功失败的处理方式是固定的，无法根据执行结果走不同路径。 为了解决这个问题，引入了行为树（Behavior Tree）——游戏 AI 里常用的决策架构。实现了 sequence、selector、retry、condition、parallel 五种节点类型，支持顺序执行、失败回退、条件判断、重试等逻辑，并为此做了 SVG 流程图渲染。 两个根本问题 但随后发现两个根本问题： 让 LLM 建树难度很高。 LLM 建普通任务列表已经容易出错，建一棵结构正确、逻辑合理的行为树更难——节点类型选择、嵌套结构、条件语义，每一步都容易出偏差。 渲染流程图难度也高。 行为树是嵌套树形结构，和 DAG 的布局算法完全不同，需要手写递归布局算法才能正确渲染。 结论 行为树的核心价值——条件分支、根据结果重新规划——其实可以用更简单的方式实现：brain agent 在任务末尾根据验收结果决定是否追加新任务。本质上是同样的能力，但对 LLM 的要求和系统复杂度都低得多。 行为树分支因此未合并，回到了 DAG + brain agent 动态追加任务的路子。 tbrain 源码在这里：tbrain 最兼容 tbrain 的 Agent 运行时是 tclaw，感兴趣可以去 tclaw 体验。

游戏看上去不错 tbrain + tclaw 多 Agent 协作开发游戏这件事，之前大概就是验证一下能不能跑通，没想太多。 做了几个游戏下来，发现效果比预期好不少——UI 有模有样，玩法完整。几个 Agent 分工合作，设计、写代码、测试，整个流程下来没有人工干预。 做到这程度，就想继续往下走：tclaw 在游戏开发上，还能做什么？ 有一个短板很明显 但玩着这些游戏，有一个感受挺直接的：游戏能玩，但美术很糙。所有图形都是 AI 自己画的——基础色块、简单几何，能表达意思，但跟真正的游戏差得远。 网上其实有很多优秀的免费美术资源，像素风、卡通风各种风格都有，专门给独立开发者用的，质量很高。 于是就想：能不能让 tclaw 来做这些事——搜索素材、整理素材、管理本地素材库，甚至处理帧动画？ 怎么做 拿这个想法去和 tclaw 讨论，来来回回聊了好几轮。 一开始是从开发者的角度想：这个功能该怎么支持？ 做成独立插件，有自己的窗口——但插件里没有对话，用不了 tclaw 的核心能力；要用就得把对话嵌进插件里，以后每多一个插件就多一个对话框，越来越割裂。 改成全屏扩展页面，像文件浏览器那样接管整个主区域，进去是个独立的世界——用户得在对话和扩展页之间来回切换，体验还是断的。 做一套扩展系统，类似 VS Code 的插件机制，每个 Skill 可以注册自己的 UI 组件——但这意味着要定义扩展 API、生命周期、沙箱隔离……一套新的基础设施，比要解决的问题复杂多了。 怎么想怎么别扭。 后来重新梳理思路，从用户使用的角度出发：用户会怎么用这个功能？在对话框里说"搜个像素风骑士素材"，tclaw 去搜，搜出来的结果直接显示出来，看合不合适，合适就点下载。就这样。 倒推回来——tclaw 本来就是对话驱动的，对话就是入口，这个体验才是最适合的。 方向就出来了：做成 Skill，结果嵌在对话流里展示。 这样下来就需要对现有系统做一些扩充：Skill 现在只能输出文字，素材搜索的结果需要缩略图、下载按钮、动画预览，得让 Skill 支持输出富内容。 想要的效果是这样的： 用户：搜几个像素风骑士的素材 AI：找到这些 ↓ [搜索结果——带预览图、授权信息、下载按钮] 用户：这个不错，下载，帮我切成序列帧 AI：切好了 ↓ [动画预览——GIF 效果、帧分组] tclaw 本来就能把特定代码块渲染成图表。同样的思路可以用在这里——Skill 输出一个特殊的代码块，前端识别后渲染成卡片。 tbrain 源码在这里：tbrain 最兼容 tbrain 的 Agent 运行时是 tclaw，感兴趣可以去 tclaw 体验。 ...

关于协议 第一个要想清楚的问题：agent 怎么和 tbrain 通信？ 一开始想过用 WebSocket，实时性更好。但想了想，任务调度对实时性要求没那么高，agent 每隔几秒来拉一次任务完全够用，换来的是协议简单、接入方便。就用 HTTP 了。agent 的工作流程大概是这样： 注册自己，告诉 tbrain 我是谁、能做什么，拿到一个 token 每 30 秒发一次心跳，证明自己还在线 每 3 秒拉一次任务，有活就认领 执行过程中可以上报进度，UI 上能实时看到 做完上报结果，或者上报失败并说明原因 tbrain 通过心跳判断 agent 是否在线。心跳超时的 agent 会被标记为离线，手里的任务重新放回队列，等其他同角色的 agent 来认领，不需要人工介入。 任务计划谁来出 调度是确定性的，但"这个任务该怎么拆、交给谁"不是——这需要判断力。 有些场景流程是固定的，比如"先开发、再测试、再部署"，每步交给谁很明确，提前写死就行。但有些场景不好提前定死，需求一来，得先看看现在有哪些 agent 在线、各自能干什么，再临时决定怎么安排。 所以支持了三种模式： 静态模式：提交 Job 时自己写好任务列表和依赖关系，tbrain 照着跑。 AI 规划模式：只提交一个目标，brain agent 看到目标后自己规划出任务列表，发回给 tbrain 执行。 混合模式：骨架是静态的，某些步骤交给 brain agent 来决定怎么做。 任务失败了怎么处理 设计失败处理的时候，想了一下失败都有哪些情况：网络抖一下超时了、agent 做错了需要重来、碰到了没权限处理的情况需要人来拍板……这几种情况的处理方式完全不一样，不能一刀切。 最后让 agent 自己在上报失败时指定失败等级： 自动重试：瞬态错误，系统自动重试，不超过两次 打回重做：业务失败，打回上游任务重新来过 人工审核：需要人来决定，任务挂起等人处理 致命错误：整个 Job 直接失败 agent 自己最清楚为什么失败，让它定级比 tbrain 猜要靠谱。 ...

单进程的墙 重构之后的 agent 工具稳多了。但用了一段时间，新问题浮出来了。 所有 agent 都跑在同一台机器、同一个进程里。这意味着你没法把 coder 部署在开发机、tester 部署在测试机，让它们跨机器协作。不同机器上跑的 agent，没有办法互相知道对方，没有办法分工，更没有办法共同完成一个任务。 每个 agent 都是孤岛。 想真正做到多 agent 协作——不管 agent 在哪台机器、用什么语言写、跑在什么框架上——就需要一个独立的调度层，负责把任务分发出去，收集结果回来。 这就是 tbrain 最初的动机：一个专门的任务调度引擎，让分散在各处的 agent 能协同工作。 只做调度该做的事 开始设计这个引擎的时候，第一个问题是：它到底要做什么？ 最直接的想法是给它加上 AI——让它自己理解需求、自己拆任务、自己决定派给谁。但停下来想了一下，调度这件事本身，其实不需要理解任何东西。它要做的就是：task 1 完成了，通知 agent 去做 task 2；task 2 完成了，通知 task 3。就这些，纯粹是状态流转，机械的，确定性的。 那哪里需要 AI？继续想——需要 AI 的地方，是在任务开始之前：得有人把流程安排好，知道现在有哪些 agent、各自能干什么，然后决定先做什么、再做什么、交给谁。这一步需要判断力，是 AI 该干的事。 但这一步做完之后，后面的执行就不需要 AI 了。系统只要照着计划，按部就班地通知、等待、更新状态，就行了。 这么一推，结论就出来了：调度引擎本身不需要 AI，AI 只需要在开始的时候把计划交给引擎，剩下的事交给系统。 那 AI 去哪了 AI 没有消失，只是搬了个位置。 tbrain 里有一个叫 brain agent 的角色。它是专门处理"需要判断力"的事：理解目标、规划任务、决定顺序、处理失败。这些是 LLM 擅长的，就交给它来做。 但 brain agent 是一个外部角色，和其他 agent（coder、tester、researcher……）地位完全平等——同样是注册到 tbrain，轮询任务，上报结果。tbrain 不知道也不关心它内部用的是 Claude 还是 GPT，甚至不关心它是不是 LLM。 ...

下面是用 tbrain + tclaw 多 Agent 协作开发的挂机游戏： 一个听起来很合理的设计 做 AI agent 做到一定程度，你会开始嫌一个 agent 不够用。 写代码的事，交给 coder。做设计文档，交给 designer。整体协调，交给一个大管家 captain。每个人做自己擅长的，这不就是正常团队的运作方式吗？ 所以我给自己的 agent 工具做了一个消息总线。每个 bot 都注册在上面，bot 之间通过发消息协作，想让谁做事就 @ 它。设计上简洁，概念上直觉，感觉挺美的。 确实美了一段时间。 开车的时候用飞书和 captain 说一句需求，captain 帮我整理思路，觉得需要写代码就 @ coder，coder 内部再分工，architect 写设计、implement 写代码、tester 跑测试。我只管说，后面的事它们自己协调。那段时间我给这套东西取了个名字叫"咖啡"——一边喝咖啡，咖啡自己把活干完了。 好景不长 然后问题来了。被 @ 的 bot，自己也会去 @ 别的 bot，消息裂变，系统失控。 这段噩梦足足耗了三周，几十个分支，上百次提交，最后还是回滚了。细节就不在这里展开了——如果有兴趣，可以去看 tclaw 的开发故事，那篇写得比较完整。 简短结论：靠规则和提示词约束 LLM，本质上是在用不确定的方式解决不确定性带来的问题。这件事根本做不完。 放弃，重构。 重构之后 重构后的方案简单多了：不再有消息总线，改成调用制。用 list_categories 看看现在有哪些领域的 agent，用 list_agents 列出该领域下的具体 agent，再用 run_agent 让它去做事。被调用的 agent 做完返回结果，不能主动去找别人。控制权始终在调用方手里，不会有人越权乱插嘴。 这套方案稳了很多。但用了一段时间之后，碰到了另一堵墙—— 所有 agent 还是跑在同一台机器、同一个进程里。想在开发机上跑一个 coder，测试机上跑一个 tester，让它们协同，做不到。每个 agent 都是孤岛。 ...