今年 5 月开始做 Corterm 。53 天，493 次提交。其中 317 次的 commit message 末尾写着同一行字：Co-Authored-By: Claude GLM 5.1 。
也就是说，这个项目 64%的代码提交是 AI 和我一起写的。但不是"AI 替我写代码"——是我写了 8 个自定义 Skill ，一套编译报错自动修复流水线，和一个写满了 ArkTS 奇葩限制的 CLAUDE.md 。
CLAUDE.md 开头是四句话：
这四条不是写给 AI 看的。是写给我自己的。
AI 编程最大的坑不是 AI 能力不够——是你管不住它。你给它模糊需求，它会给你看起来很完整、实际上满是静默降级和空值兜底的方案。上线，半夜炸了，翻代码才发现某个 catch 里什么都没做。
后来的 commit 里，catch { return null }这种写法基本绝迹了。
光有原则不够。AI 的另一类错误是用旧版 API 。鸿蒙 ArkTS 更新飞快，训练数据里混着大量 API 8/9/10 的废弃写法——它经常一本正经地瞎写。
我给 AI 装了 8 个外挂：
hvigorw assembleHap编译harmony-build 和 harmony-fix 是一对。你说"帮我把鸿蒙版编译通过"，然后去接水。屏幕上滚过报错，自动修复，再编译。几分钟后绿色 BUILD SUCCESS 。
按我的经验，80%的编译报错能在 3 轮以内自动修完。15%需要看一眼改一句。只有 5%需要坐下来认真解决。
不是一次写出来的。每踩一个坑、发现 AI 在同一类问题上反复犯错，就加一条。
比如 ArkTS 编译约束表：
as const → 报错arkts-no-as-const → 用class X { static readonly }代替{ key: value } → 报错arkts-no-untyped-obj-literals → 必须显式声明类型throw e（ e 是 catch 的任意类型）→ 报错arkts-limited-throw → throw new Error((e as Error).message)整张表就是一份"AI 在 ArkTS 上最容易犯的错"的清单。不是给人类看的——是写给 AI 的 memory 。如果你也在写鸿蒙，可以直接抄这张表。大模型目前确实不知道这些。
架构决策。让 AI 决定"Gateway 和 Worker 之间用什么通信协议"，它会给你一张优缺点对比表。但真正的取舍是——选了 SignalR 之后，HarmonyOS 端没有 SDK ，你得手写 479 行 ArkTS 。AI 不知道这个代价。这种决策需要的不是信息，是判断。
跨文件重构。把 InMemory 数据层切到 PostgreSQL ，20 多个文件，DbContext 注入方式要从 IServiceScopeFactory 改成 IDbContextFactory ，迁移脚本写好，测试全部重跑。AI 能帮你改每一个文件，但不能让它决定改哪些。因为你改的是"做法"，AI 只知道"怎么写"，不理解"为什么"。
目前完全免费，MIT 开源。iOS/Android/鸿蒙/浏览器都能用。
Corterm 开发系列第 1 篇，共 10 篇。下一篇：为什么选 MAUI + Hybrid WebView
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。