【共创稿事节】仓颉小游戏开发，棋盘能画了，规则却散在 onTouch 里——我用多个 Grok Bot 怎么先卡住驿路

关注

原创最新推荐文章于 2026-11-07 07:24:25 发布 1.1k 阅读 AI 写同款· GEO 优化 ›

利用MATLAB 4f光学系统，在Python中进行弗劳恩霍夫衍射和傅里叶面滤波——用镜头模拟光学图像处理。.zip 1.版本：matlab2014a/2019b/2024b 2.附赠案例数据可直接运行。 3.代码特点：参数化编程、参数可方便更改、代码编程思路清晰、注释明细。 4.适用对象：计算机，电子信息工程、数学等专业的大学生课程设计、期末大作业和毕业设计。立即下载

第一周用 Agent 搭驿路巡点，体感很分裂：Empty Ability + Canvas 很快能绿、棋盘能画、手指能动；可规则一旦散落在 onTouch 分支里，两天后谁都不敢动。

不是模型不会写仓颉。是我没先写清「什么叫过」，Agent 就会优先交出「能看见的皮肤」。

这篇讲两件事怎么叠在一起：三条规则约定，以及我怎么用 Grok Bot（桌面多助手协作环境）开多个专家角色（含 Projects Manager、1:1 与拉群、Notion 回流）把脚手架和打回跑起来。

这是驿路第一周我正在用的卡法，给第一次用 Agent 搭仓颉游戏的人一个能试的切口；已经在跑多助手的，也可以拿验收约定怎么写来和我对一对——不是官方教程，也还没写成最终方法。

驿路巡点是 Zip 风格正交哈密顿路径：按序踩编号驿站且铺满网格。规则不复杂，却刚好验清——领域模型能不能先于 Canvas 站住。

先看一眼真机棋盘（长安·第 1 驿）与拖出第一步后的路径态：

为什么用仓颉写这款游戏

早前那条线，是把已有 ArkTS 产品往仓颉迁：源码可以尽量写成仓颉，系统边界仍常要 ArkTS / JS interop，并不是全量仓颉的手机应用。驿路巡点换了一条路——从零做一款纯仓颉手机游戏：官方 Empty Ability 模板，入口在仓颉侧，工程树里不混 ArkTS 页，先把规则层和 Canvas 手感走通。

优点先写：Zip 规则正交、可判定、可单测——升序驿站、不回头占格、全图覆盖——非常适合写成纯函数；网格尺寸可控，第一周就能用「长安」一类教程关把闭环跑通。缺点也清楚：仓颉侧 Canvas / onTouch 文档仍是 Beta（API 起始版本 22，以当时工程为准），资源读取绑定未必有你敢在真机上赌的写法；人侧闸门（体验版 / 插件）开篇已写，排期里必须留人侧时间。

所以我故意选了官方 [Cangjie] Empty Ability 模板：入口在 index.cj，官方树里也没有 src/main/ets。路径与 import 细节以当时官方模板为准。

本节速览：驿路巡点不是「证明仓颉比 ArkTS 好」，而是证明——在 Agent 协作下，规则层能不能先于皮肤站住。

用 Agent 搭骨架：什么过了，什么崩了

我把目标写成可引用的验收面，而不是「帮我做一个 Zip 游戏」这种空 prompt。Agent 擅长：按 Empty Ability 树生成工程骨架；拼出 RenderingContextSettings(antialias: true) + CanvasRenderingContext2D + onReady 首帧（宽高用 100.percent，颜色用整数，坐标用 Float64）；在 Canvas 上挂 onTouch，用 event.eventType（不是 ArkTS 的 event.type）把 touches[0].x/y 映射到格子。这些「过了」的部分，体感是：编译能绿、棋盘能画、手指能动——Empty Ability + Canvas + 规则层能交卷，说明现模型从零写仓颉已经够用，不是卡在语言能力。

「崩了」的部分更有价值，而且几乎都发生在我没写验收清单的时候：

规则散落在 onTouch 分支里——边界、墙、编号、撤销各写一段 if，两天后谁都不敢动。
引擎文件为了「方便」直接 import Canvas / UI 类型，结果单元测试要起整棵 ArkUI。
幻想运行时读 rawfile/levels.json，文档核不到稳妥绑定，真机才发现空表或读失败。
把 ArkTS 画板习惯（字符串色、方法式 lineWidth(5)、社区过时 import ohos.component.*）原样搬进仓颉，类型检查或首帧绘制直接打脸。

我后来固定成四步：先写验收句 → Agent 交最小 diff → 本机 / 真机反馈 → 把坑写进 memories。跳过任意一步，下一轮都会用相同代价再踩一遍。定性要分清：少了这四步，多半是验收约定缺位或脚手架偷懒，不是「模型不会仓颉」。优点：Agent 把脚手架压到小时级，人可以把精力留给「什么叫过」。缺点：没有验收约定时，Agent 会优先交出「能看见的 Canvas」，而不是「能测的规则」——这仍不等于可停在 cjc（仓颉编译器命令行）绿。协作清单压成三句——下面三条决定，全部改写成 Agent 要能对得上的验收约定，而不是事后复盘感想。

第一次先做的，是写清三句验收约定（规则离开 UI / 步进唯一入口 / 关卡进源码），再让 Agent 交最小 diff；没写约定前，不把「棋盘能画」当成过。

验收清单一：规则纯函数，GridMap 零 Canvas 类型

触摸、绘制、动画都会变；「相邻能不能走」不会。所以我要求 Agent：engine 包里的 GridMap 只认格子和墙，不 import 任何 Canvas / UI 类型。对角线直接禁掉：曼哈顿距离必须正好是 1；正交边上若有墙，同样算 blocked。触点到格子的映射单独放在 touchToCell(px, py, layout)——吃像素和布局（原点、格宽、行列），吐 Option<Cell>；Canvas 只负责把手指坐标喂进来，规则层永远看不到「按下 / 拖动 / 抬起」。

// engine/grid.cj — 正交邻居（示意）
public func isOrthogonalNeighbor(a: Cell, b: Cell): Bool {
    var dx = a.x - b.x
    var dy = a.y - b.y
    if (dx < 0) { dx = -dx }
    if (dy < 0) { dy = -dy }
    return dx + dy == 1
}

验收语言比代码更重要：会话结束时，我只问三件事——GridMap 的 import 里有没有 UI；邻居与墙判定能否在无 Canvas 进程里跑；换皮肤是否需要改 engine。任一否，就打回，而不是「先把棋盘画好看再说」。可复用的那一块，正是这句：引擎包零 Canvas 类型。

优点：换皮肤、换控件、甚至换到非鸿蒙前端，规则代码不用动；Agent 再生成绘制层时，也不会把墙判定拖进 UI。缺点：前期要忍住「全都写在 index.cj」的快感；Agent 默认喜欢把逻辑贴在事件回调旁，必须用验收约定把它拆开，并在审查时显式扫 import。

验收清单二：canEnter / tryStep 唯一入口

Zip 规则叠在网格之上：升序踩驿站、不回头占格、最后一格必须是最大编号且路径覆盖全图。我把判定收敛进 PatrolGame.canEnter，步进入口只有 tryStep——拖回上一格等于撤销一步（Zip 手感），其余一律先问 canEnter 再 path.push。UI 只做「坐标 → Cell → tryStep」；断言写在规则对象上，不挂 UI 也能跑。

// game/patrol.cj — 唯一入口示意（非完整实现）
func canEnter(cell: Cell): Bool { /* 边界 / 已访 / 墙 / 编号 / 终局覆盖 */ }
public func tryStep(cell: Cell): Bool { /* 拖回=undo，否则 canEnter 才 push */ }

canEnter 的验收句可以写得很干：出界 false；已在路径上 false；相对上一步若 blocked（非正交或有墙）false；格子上有编号则必须等于下一个应收驿站；若编号等于最大驿站，则 path.size() + 1 必须等于全图格数——否则终局捷径一律拒绝。Agent 若在 UI 里再写一套「能不能走」，就算编译绿也算验收失败。

常见做法是把规则塞进各个 onTouch 分支，过两周你就不敢动任何一处。这里反过来——真机手感不对时，先对 canEnter 用例，而不是在绘制里猜。优点：规则对象可测，Canvas 只是显示器；这四步转得快。缺点：唯一入口要求产品拍板提前（撤销手感、终局条件），Agent 不能自己发明第二套规则；人侧缺席拍板时，模型很容易「两边都写一点」。

验收清单三：关卡进 levels.cj，不走运行时 rawfile

工程里其实有两份同源数据：resources/rawfile/levels.json 给求解器、脚本用；entry/src/main/cangjie/levels.cj 是应用真正编译进去的字面量。没用运行时读 rawfile，原因很具体：仓颉 1.1.3（以当时工程为准）的资源读取绑定，官方文档里还核不到一套我敢在真机上赌的写法。于是关卡变成源码——坏坐标、坏墙边会在构建或测试里炸，而不是玩家点进关才发现空表。

tools/build_levels.py 只做一件事：把已验证的 JSON 抄成仓颉字面量，不发明关卡、不生成路径。改关必须先改 JSON，再跑脚本同步。Agent 的验收约定写成三条禁令：禁止手写「看起来像」的 levels.cj；禁止跳过求解器验证直接改字面量；禁止把「JSON 里有文件」偷换成「应用已加载关卡」。会话 memories 里写清「JSON 为源」，否则 Agent 「好心」直接改 .cj，人和脚本会打架。

优点：双重账——一边诚实承认仓颉资源绑定成本，一边吃到编译期收益；求解器与应用读同一事实源。缺点：多一步同步脚本；CI 若只有脚本没有 DevEco，只能证明「字面量生成过」，不能证明「HAP 装过」——这两层验收要分开记账。

一周付出去的成本

三条约定能站住，不等于工具链免费。一周里真实付出去的，至少这三笔：

DevEco（华为鸿蒙 IDE）↔ 仓颉插件版本锁步：插件与 DevEco 必须成套安装，不能「IDE 升了插件没跟上」。本工程当时用的是 SDK 1.1.3、插件与 DevEco 组合以当时工程为准（曾出现插件 5.x 装不进 DevEco 6.0.1 的组合）。报名体验版 / 公测、Install Plugin from Disk，仍是人侧闸门——细则见开篇人侧闸门。
云 CI 当前编不出 HAP：鸿蒙仓颉工具链仍要本机 DevEco；没有 DevEco / 仓颉鸿蒙工具链的环境，CI 不声称编过包。Agent 可以跑求解器与字面量生成，但不能把「脚本绿」偷换成「HAP 绿」。
纯仓颉路径，不是 hybrid：这篇游戏是纯仓颉 UI + Canvas。我不假装「无缝替代 ArkTS」——互操作路径存在，但驿路巡点故意不踩那条路，先把规则层走通。和 Hybrid 模板混用，只会把验收边界搅糊。

优点写透：成本写进排期后，Agent 长跑不会在错误层级空转（例如在云主机上硬编 HAP）；纯仓颉边界一旦卡住，后续讨论不会滑回「顺便嵌个 ArkTS 页」。缺点写清：本机锁步与真机共测吃时间；纯仓颉路径放弃了部分 ArkTS 生态捷径——这是主动选择，不是疏忽。一周账的中心判断只有一句：留下的是可测规则与同源关卡管道，付出去的是人侧闸门（开篇已写）与文档 Beta 不确定性。

我怎么用 Grok Bot 开多个 Grok Bot 搞驿路

Grok Bot 先说清楚：它是跑在桌面上的助手环境——可以同时养多个各有分工的 Grok Bot，而不是在一个聊天窗口里让模型硬扮演所有角色。我定验收约定与拍板；各 Grok Bot 认领任务执行。驿路这一周，脚手架、过关图、规则层、烟测和挑刺是错开推进的，靠的就是这套形状。

两台电脑：云侧长跑，本地碰真工程

多 Grok Bot 之外，还有一层常被漏写的体感：Grok Bot 能动手碰电脑——而且不是只能碰「助手自己那台」。我这边叠着用两套环境：

助手侧的云电脑：每个 Grok Bot 自带的那台机。适合长跑任务、装工具、浏览器查文档，登录态也能常驻。脚手架脚本、调研抓取、把大段构建探针丢过去跑——我盯验收约定，云侧扛耗时活，少占本机焦点。
我已注册的本地电脑：真机工程、本机文件与会话所在。Grok Bot 可以经我授权后在本机执行：读工程目录、碰 DevEco / 模拟器相关路径、动本机文件。没授权就不碰；授权是按次确认，不是默认接管整台机。

分工。本节速览：云侧跑长任务、装工具；本地侧碰「只有我这台机才有的」工程与设备——人授权，Grok Bot 执行。本地机要先在 Grok Bot 设置的电脑页登记成可用机器；具体点哪几个按钮以你客户端实况为准，这篇不展开菜单路径。

优点：长跑不堵本机，设备侧验又不靠口头描述。缺点：本地动作会等人点授权，急活偶尔卡一下；云侧没有我本机的 DevEco / 模拟器，编 HAP 仍得回本地——这和前面「云 CI 当前编不出 HAP」是同一条边界，不是两套故事。

Projects Manager：按意图创建专家 Grok Bot

日常入口往往不是我亲手把每个角色建一遍，而是先跟 Projects Manager（项目管理） 说清意图：这一周要驿路可玩、规则可测、过关图可审。PM 负责澄清范围、排人、卡验收——按需要创建或唤醒 designer / researcher / coder / tester / reviewer / writer 等专家 Grok Bot。人定方向与验收约定；PM 排班；专家执行。优点：角色边界清楚，少「一个人既画又写又测」。缺点：意图含糊时 PM 也会把任务拆歪——验收句仍要我先写清，不能外包给排人。

专家怎么拆（仍扣驿路）

researcher：盘面与站名、过关图约束；不交「唯一解」四字空话。
designer：棋盘 / 触控与讲解屏；图标与色值按目标尺寸交，不交糊成方块的默认形。
coder：Empty Ability + Canvas + 规则层落地；过审设计稿才进代码。
tester：本机连模拟器烟测与缺陷报告；用 hdc+设备侧 uitest 点滑截图，拉回全屏图后人眼看——不是只会口述「我点过了」。
reviewer：故事自洽、关卡过关图、验收约定有没有被偷懒——专门挑刺。
writer：把这四步与三条约定写成可引用的验收句，不替产品拍板。

这四步照旧：先写验收句 → 对应 Grok Bot 交最小交付 → 本机 / 模拟器反馈 → 坑进 memories。某个 Grok Bot 交了「能看见的 Canvas」却没把规则提出 UI，reviewer 或我会打回，而不是让 coder 继续叠皮肤。

tester 怎么点滑验：hdc + uitest，不是录屏工具

本节速览：Agent 用鸿蒙的 hdc + 设备侧 uitest，像人一样点、滑、截全屏，再拉回图用人眼看——这证明平台给了可被脚本驱动的模拟 / 自动化测通面，而不是又一个「帮你录屏」的壳。

工具链本轮证据如下（来自驿路烟测，不夸大）：

hdc 连模拟器 127.0.0.1:5555；设备侧 uitest（dumpLayout / uiInput）负责读树与注入；snapshot_display 打全屏，再 hdc file recv 拉回本机（Mac）。
没用 Hypium；也没有自动像素对比流水线。脚本落在仓内 qa-shots/（例如 clear_zhuo10.py、play_to_5x5.py）。
装包与启停走平台能力（含 aa force-stop / aa start）；Grok Bot 负责把命令串起来，并把截图拉回。

点与滑怎么发生：先 uitest dumpLayout 拿到控件树 JSON（text / bounds / type）→ 按文案取 bounds 中心 → uitest uiInput click x y；树里找不到就退已知坐标。画线通关：把 Canvas bounds 映射到格子，再 uiInput drag …；列表用 uiInput swipe。这不是 Accessibility DSL，是「树 dump + 坐标注入」——选择器一漂，点击就会空，所以脚本要肯重 dump，而不是死记一次坐标。

边界必须诚实：本轮验收都在模拟器 5555。真机理论上同套命令，但没有跑真机对照——不能写成「已在真机验过」。平台给的是布局树、坐标点拖滑、全屏截图、装包启停；Grok Bot 拉回图后，章皮 / 半身 / 地貌带这类观感验收仍靠全屏肉眼，不靠 auto-diff。自动化省的是重复点滑；「好不好看、对不对章」仍是人审。

优点：烟测可脚本化，回归不必每次人手点完十盘。缺点：选择器不稳时要重 dump；全屏观感没有自动红绿；本地授权与模拟器在线仍是前置。把 tester 写进多 Grok Bot，不是为了多一个头衔，而是为了把「能跑到第几关」从口头变成可复现的命令链。

协作形态：1:1 消息，也可以拉群

各 Grok Bot 之间、以及我与某个 Grok Bot，都可以 1:1 发消息：派活、改稿、收交付，适合「只找 coder 修 tryStep」这种窄口。也可以 拉群（channel）——比如驿路相关的 designer / coder / tester / reviewer 同室对齐过关图与打回，减少私聊里来回传话。优点：并行对齐、少串台。缺点：群一热闹就容易刷屏；我要求群里只贴验收相关的结论与附件，过程碎嘴留在 1:1。不是只能跟用户单聊——专家 Grok Bot 彼此也能通气，但最终「什么叫过」仍由我拍板。

Notion：把验收约定与坑落到外部板

外部我接了 Notion 一类连接器：任务板上认领「未开始 / 接下来」类写作或关卡任务，做完把状态与链接回流，验收通过与打回大家看得见。规则验收句、这四步备注，也会落到 Notion 文档页，而不是只活在某个 Grok Bot 的短期上下文里。体感上：连接器擅长认领与回写状态；验收原文与锁版仍是人定——我不会让 Grok Bot 自己把「过了」写进终态。优点：周报与验收通过有外部锚。缺点：板一乱，Grok Bot 会认领错行；字段与状态名以板上实况为准，不展开点击路径。

这套形状服务什么（不是功能清单）

回到驿路三条约定：多 Grok Bot 的价值，是让「规则离开 UI / 步进唯一入口 / 关卡进源码」各自有人盯——researcher 与 reviewer 盯过关图与偷懒，coder 落地，tester 打红绿，writer 把验收句写硬。脚手架能绿只是进门；打回发生在约定被偷懒时，而不是模型「不会仓颉」。优点：并行、角色可记账。缺点：人必须验收；群聊要克制；PM 与连接器都替代不了「什么叫过」。这不是产品广告，是我这周真实用过的协作形状。

收束

目前我这样做：先写三句验收约定，再让多个 Grok Bot 认领脚手架 / 规则 / 过关图 / 烟测；GridMap 零 UI 类型，canEnter/tryStep 唯一入口，关卡经 build_levels.py 从 JSON 进源码；云侧长跑、本机授权后碰 DevEco；tester 用 hdc+uitest 在模拟器 5555 点滑截全屏，真机对照本轮没跑。目前我认这三条约定，才算「规则站得住」；别的拆法还没比过。从零搭仓颉游戏，目前我认脚手架能绿已够用，但棋盘能画只是进门，不是过。

仍待验证：真机是否同令可复现；云 CI 何时能诚实编 HAP；三条约定要不要再拆更细的「撤销手感 / 终局」产品拍板字段；选择器漂了之后，全屏肉眼验收能不能部分自动化而不误伤。

想和你讨论：验收约定写在 session goal / memories 里，和写进 Notion / 测试文件，哪一种更不容易被 Agent「先画皮肤」旁路？纯仓颉 Empty Ability 这条边界，在什么规模下其实应该早接 ArkTS hybrid，而不是再忍一周？

协作形状这里只摊开驿路这一周的现场；拍板放哪、批准之后怎么流转、证据怎么卡，我另有 Grok Bot 三篇笔记接着写——这篇不展开。

本节速览：三条约定 + 这四步是我这边这周的现场刀；别只复制 Canvas 脚手架，也别把「能交卷」误读成零坑。

收录于