falsebeetle的博客

仓颉STS 1.1.x计划于2026年10月30日停维，尽管1.2.0已于9月22日上线，但因与旧版二进制不兼容，需全量重编项目及依赖。升级核心挑战在于重编窗口与依赖齐备度，建议优先评估是否受关键变更影响，再规划回归时间。对外交付应钉住稳定版，尝鲜可另开分支。升版前务必梳理依赖锁与CI镜像，避免为新特性过度消耗资源。

双端模拟器实测 94 关通关、6 关卡死，根因不在跨端框架，而在自己这边：转换脚本丢了渡口字段、引擎没有渡口规则、测试只按 20 关写。补齐后，6 关在求解器层面全部有解，后来的复测也没有再失败。

编译通过」不等于真能玩。作者的验收规矩：交活必须附过关图和全屏证据（截图或视频），缺一样就打回、不合并；证据只放合并说明和 Notion，不进仓库。对照 xAI Galaxy 演示，他的验证还没写成始终启用的技能；没有真实用量数据，也不宣称「可玩发布」。

仓颉游戏搬 iOS/Android，CJMP 三个缺口：Canvas 没编进去、registerFont 拿不到、@r 编译不过。原因与绕法逐一拆解，可作动手前的检查清单。

仓颉棋盘游戏驿路巡点从鸿蒙搬到iOS/Android：先试交叉编译+原生壳只通1关，发现CJMP的Canvas没编进iOS/Android构建，9月28日转向CJMP。全程模拟器验证，无真机。

本文分享了在仓颉手机游戏回归工程中，如何通过可执行断言（如test_rules.py）、自动同步校验（build_levels.py）与精准打回句，将规则约定转化为红绿日志，杜绝“只交截图”行为。强调规格必须可执行、同步必须可验证、偷懒必须被即时拦截，实现规则层与实现层的自动化卡点。提出“先改JSON再emit”“求解器路径喂try_step”“打回句短而狠”等实践，确保回归可信。反思多Agent协作下spec修改纪律、UI文案回归分层等问题，呼吁规则网真正落地为工程标准。

本文分享了在仓颉语言下从零构建纯仓颉游戏《驿路巡点》的第一周实践，核心是通过三条验收约定（规则层脱离UI、步进唯一入口、关卡源码化）与多助手协作框架（GrokBot）实现规则先行。借助项目管理、专家角色分工及自动化烟测，确保规则可测、可复现，避免逻辑散落在事件回调中。强调“先写过再画皮”，以最小交付+反馈闭环提升效率，揭示Agent协作中“验收约定”比代码能力更关键。

类型全绿≠能跑。编译绿只是门口：需四路对抗审查（API 语义、ArkTS 等价、运行时、UI）、三条可复现语义坑（ifv 急切、UTF-8 边界）、镜像只证环境。收束为六门验收合同 —— 系统 API 须在正确运行时验证，停在 cjc 不算过。

本文复盘鸿蒙应用「双栏对照」从 ArkTS 迁仓颉的经历。作者先以 ArkTS 打磨产品面，再借 ZCode 夜间免费窗口全量迁移：13 个 .cj 文件、编译签名成功、类型检查 0 错误，模拟器首跑却挂起。真机共测又证伪两件事：独立 JSRuntime 读不了 picker 的 file://docs，JS 桥关不掉 PC Enhance 三键。最终改混合分工：仓颉做产品（界面、diff、会话、沙箱文件），ArkTS 只留系统壳。结论：仓颉语言能力已够扛产品迁移，系统壳必须还给 ArkTS。

鸿蒙开发选栈核心在于明确路径：默认主力为ArkTS（生态成熟、易上手），仓颉适合高性能/高并发场景，可与ArkTS混合开发；已有Flutter/RN团队应优先适配鸿蒙，而非重写。仓颉需通过华为联盟报名获插件权限，非开箱即用。关键瓶颈不在语法，而在“选对栈+过人侧闸门”。模型已支持长跑生成，但真正稀缺的是清晰的验收合同与工具链记忆。建议：先定目标，再启Agent，避免在错误路径烧token。

文档给 Agent 钉了一张 "仓颉查文档索引"—— 语法与工具链跟 tip 1.1.3，白皮书从门户卡片进（短文、仍滞后），查 API 先认 cangjie_runtime（std 在这），三方库走 TPC / 中心仓、ArkTS 库走互操作或重写，目的是让人和 Agent 少绕废弃站、少空转一轮。