GLM / Deepseek / Minimax / Mimo / Kimi 编程能力实测：从 Web 到 3A 游戏开发
用了一年多，踩了不少坑。这五个模型各有各的毛病，选错了会浪费时间。 下面是我实际用下来的感受，附带具体的代码测试案例。 五款模型概览先看基本信息： 模型 厂商 最新版本 上下文 架构特点 GLM 智谱AI GLM-5.2 200K 全模态矩阵，结构化输出，批量处理 Deepseek 深度求索 V4-Pro / V4-Flash 1M 推理能力强，FIM代码补全，上下文硬盘缓存 MiniMax MiniMax M3 1M MSA 架构，原生多模态，音频/视频/图像生成 Mimo 小米 Mimo 2.5 / Mimo 2.5 Pro 1M 深度推理，MCP工具调用，实时搜索 Kimi 月之暗面 K2.7 256K Coding/Agent 前沿模型，长程代码编写 价格差异很大： 模型 输入价格（/百万tokens） 输出价格（/百万tokens） Deepseek V4-Flash ¥1 ¥2 Deepseek V4-Pro ¥3 ¥6 GLM-5.2 (≤...
可视化面板重构：动态玩家、环形拓扑与 30 秒到 100 毫秒
上一篇写了 Flow 粒子动画的实现。这一篇记录可视化面板的后续大改——从固定 5 玩家到动态玩家管理，从底部单侧 port 到四边环绕 port，以及一次 INP 性能修复。 动态玩家管理：从固定 5 人到无限扩展之前的可视化面板硬编码了 5 个玩家（p1~p5），调试时只能看预设场景。实际联机房间里玩家是动态加入离开的，固定人数的面板根本不够用。 Create/Join 弹窗现在点”添加玩家”会弹出一个对话框，输入玩家名后选择 Create（创建新房间）或 Join（加入已有房间）： 12345function showAddPlayerDialog() { // 弹窗：输入玩家名 + 选择 create/join // Join 按钮旁实时列出已有房间的下拉框 // Create 自动创建 room_{name} 房间} Join 按钮旁边有个下拉框，实时列出当前所有房间。选好房间点 Join，玩家就加入去了。 动态 StoreStore 里加了 testPlayers Map，支持动态增删： 12345// ...
Flow 粒子动画：UDP 消息流的可视化实现
游戏联机服务器的 UDP 流量监控一直是个麻烦事。日志里密密麻麻的 ingress/forward/drop 事件，运维人员需要在海量数据中肉眼定位异常包。我们给 mingmo-server-go 的 UDP Proxy 加了一个实时可视化面板，把消息流变成了拓扑图上的粒子动画。 这篇文章讲的是这个可视化系统的实现，重点放在 Flow 粒子动画的设计和踩坑。 问题：为什么需要消息流可视化UDP Proxy 转发层每秒处理数万个包。传统的日志排查方式有两个痛点： 延迟高：从出问题到发现问题，中间隔着日志采集、落盘、查询，至少几分钟 上下文丢失：单条日志只能看到”收到了包”，看不到”这个包从哪来、到哪去、有没有丢” 我们需要一个实时的、有拓扑关系的可视化工具。 方案演进：从 strokeDashoffset 到 atConnectionRatio我们在 X6 重写时经历了 5 次方案迭代，最终选定了 atConnectionRatio + 直接 SVG DOM 操作。 Round5：strokeDashoffset 光流动画（已废弃）最初的方案是用 X6 ...
tts-tool 的多编码文件系统：BOM 检测与 UTF-8/GBK/UTF-16LE 自动识别
导入一份从旧版 Windows 导出的台词脚本，加载后中文全部变成问号。排查发现，文件是 UTF-16 LE 编码，而代码直接用 fs.readFile(path, 'utf-8') 读取。Node.js 的 utf-8 参数不会报错，它只是按 UTF-8 解析字节流，遇到不匹配的字节就静默替换。 MiMo TTS Studio 是一个配音工具，用户会从各种地方拷贝台词文件进来。Word 导出的 txt、记事本另存为的编码、甚至从聊天记录里复制粘贴的文本，编码五花八门。工具不能要求用户手动转换编码。 BOM 检测：先看文件头大多数带 BOM 的文件，前几个字节就能确定编码： 12345字节序列 编码EF BB BF UTF-8 with BOMFF FE UTF-16 LEFE FF UTF-16 BE无 BOM → 试探 tts-tool 的 FileCont...
tts-tool 的 WAV 编码与格式转换：手写 RIFF Header 的实践
TTS 工具需要支持 WAV 和 MP3 两种导出格式。API 返回的音频数据有两种形态：一种是 JSON 里包着 Base64 字符串，另一种是裸二进制流。tts-tool 的做法是：能用二进制就用二进制，Base64 只作为 fallback。同时手写了一个 WAV 生成器，用于 API 不可用时的合成降级。 RIFF/WAVE 格式结构WAV 文件由 RIFF 容器包裹，结构很简单： 123456789101112131415偏移 大小 内容0 4 "RIFF" 标识4 4 文件总大小 - 88 4 "WAVE" 格式标识12 4 "fmt " 子块标识16 4 fmt 子块大小（固定 16）20 2 音频格式（1 = PCM）22 2 声道数（1 = 单声道）24 4 采样率（44100）28 4 字节率（采样率 × 声道 × 位深/8）32 ...
easy-word 的多编码文本读取：BOM 检测与编码自动识别
导入一份从 Windows 记事本导出的单词表，界面上出现了一堆 锟斤拷。排查发现，文件是 GBK 编码，而代码直接用 TextDecoder('utf-8') 解码。 这个问题在教育类应用里特别常见。老师用的电脑五花八门，导出的文本文件编码也不统一。easy-word 虽然内置词库是 JSON 格式（统一 UTF-8），但用户手动导入单词表的场景迟早要做。与其到时候一个个修 bug，不如先把编码检测的逻辑理清楚。 编码检测的优先级拿到一个文件，先读前几个字节判断编码： 12345字节序列 判断结果EF BB BF UTF-8 with BOMFF FE UTF-16 LEFE FF UTF-16 BE前 3 字节无 BOM → 尝试 UTF-8 BOM（Byte Order Mark）是编码格式的”身份证”。有 BOM 的文件，编码是确定的。问题出在没有 BOM 的文件上——这...
godot-game-one 的 HUD 与游戏内 UI 实现
HUD 是玩家在战斗中唯一能看到的 UI 层。godot-game-one 的 HUD 要同时展示血量、分数、技能冷却、Boss 状态、排行榜，还要处理多人模式下的玩家标识。东西不少，但拆开来看每个都不复杂。 HUD 布局HUD 的场景文件在 scenes/ui/hud.tscn，核心节点结构： 123456789101112HUD (CanvasLayer)├── ScoreLabel ← 左上 (16,12) "总分: 0"├── LevelLabel ← 左上 (16,42) "等级 1"├── PlayerScoresLabel ← 左上 (16,60) "P1: 0 | P2: 0"├── HealthBar ← 左上 (16,84→220,110) ProgressBar│ └── HPNum ← 居中 "200/200"├── PowerupDisplay ← 左上...
godot-game-one 的道具与升级系统设计
godot-game-one 是复古弹幕射击游戏，战斗节奏快，道具和升级系统决定了从开局到通关的成长曲线。这篇讲三件事：道具怎么掉落、升级怎么生效、不同敌人的掉落策略差异。 道具类型与效果游戏有 6 种道具： 类型 效果 是否累积 spread 增加子弹数量，扩展射击角度 是，上限 10 级 speed 提高射速，缩短射击间隔 是，上限 15 级 power 提高子弹伤害 是，上限 50 级，溢出转回血 heal 恢复 1 点生命值 否，即时效果 bomb 清屏，逐个击杀所有敌人 否，即时效果 core 技能和激光冷却时间 ×0.7 否，即时效果 power 道具有一个特殊设计：当 bullet_power_level 达到上限 50 后，再拾取会自动转为回血。这避免了满级后道具浪费的问题。 核心逻辑在 scripts/game_state.gd： 12345678910111213141516171819func collect_powerup(type: String, peer_id: int = -1) -> void: ...
easy-word 的数据模型设计：双音标与双时间戳同步
easy-word 的数据层要解决两件事：单词要同时展示 IPA 音标和简易拼读标注，多设备之间要保持学习进度同步。这两个问题的解法都不复杂，但有些细节值得记录。 双音标系统模型定义单词的核心数据结构在 entry/src/main/ets/model/Word.ets： 12345678910111213141516export interface Word { id: string; word: string; phoneticIPA: string; // IPA 国际音标，如 "/həlˈoʊ/" phoneticSimple: string; // 简易拼读标注，如 "hel-lo" translation: string; partOfSpeech: string; exampleEn: string; exampleEnAlt: string; exampleCn: string; audioUrl: string | null; grade: 1 | 2 | 3 | 4 |...
ArkUI 自定义组件设计：翻转卡片与热力图的实现
easy-word 是鸿蒙 NEXT 原生的单词学习应用，UI 全部用 ArkUI 声明式语法写。项目拆了 15 个以上的 @Component，每个只管一件事。这篇挑三个说说：翻转闪卡、热力图、浮动宠物。 翻转闪卡：三层状态管理组件结构WordFlashCard 是学习页面的核心交互组件，用户点击卡片翻转查看中文释义。文件位于 entry/src/main/ets/components/WordFlashCard.ets。 123456@Componentexport struct WordFlashCard { @Prop word: Word; // 外部传入，只读 @State private flipped: boolean = false; // 内部翻转状态 @Prop speakHandler: SpeakHandler | null = null; @StorageLink('appThemeMode') themeMode: string = 'lig...