Corterm - 一个让 Shell 在服务器上一直活着的远程终端

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

今年 5 月开始做 Corterm 。53 天，493 次提交。其中 317 次的 commit message 末尾写着同一行字：Co-Authored-By: Claude GLM 5.1 。

也就是说，这个项目 64%的代码提交是 AI 和我一起写的。但不是"AI 替我写代码"——是我写了 8 个自定义 Skill ，一套编译报错自动修复流水线，和一个写满了 ArkTS 奇葩限制的 CLAUDE.md 。

那四条铁律

CLAUDE.md 开头是四句话：

禁止 fallback：不要静默降级、空值兜底、try-catch 吞错误。异常直接抛出
最精简逻辑：逻辑上不可能为空就不要写空值检查
异常即信号：throw 是正常控制流
不要问要不要继续：任务明确就一口气做完

这四条不是写给 AI 看的。是写给我自己的。

AI 编程最大的坑不是 AI 能力不够——是你管不住它。你给它模糊需求，它会给你看起来很完整、实际上满是静默降级和空值兜底的方案。上线，半夜炸了，翻代码才发现某个 catch 里什么都没做。

后来的 commit 里，catch { return null }这种写法基本绝迹了。

8 个 Skill 怎么工作的

光有原则不够。AI 的另一类错误是用旧版 API 。鸿蒙 ArkTS 更新飞快，训练数据里混着大量 API 8/9/10 的废弃写法——它经常一本正经地瞎写。

我给 AI 装了 8 个外挂：

huawei-docs-scraper：通过 Playwright 直接抓 developer.huawei.com 最新文档，转 Markdown 喂给 AI 。从根源消灭 API 幻觉
arkts-code-lookup：输入 Android 的 Java/Kotlin 代码，输出对应 ArkTS 写法
harmony-build：执行hvigorw assembleHap编译
harmony-fix：编译报错后自动提取错误→按文件分组→逐文件修复→重新编译。修复失败就再修，直到 BUILD SUCCESS 或者人类介入

harmony-build 和 harmony-fix 是一对。你说"帮我把鸿蒙版编译通过"，然后去接水。屏幕上滚过报错，自动修复，再编译。几分钟后绿色 BUILD SUCCESS 。

按我的经验，80%的编译报错能在 3 轮以内自动修完。15%需要看一眼改一句。只有 5%需要坐下来认真解决。

那 154 行 CLAUDE.md 怎么长出来的

不是一次写出来的。每踩一个坑、发现 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 帮不了我的地方

架构决策。让 AI 决定"Gateway 和 Worker 之间用什么通信协议"，它会给你一张优缺点对比表。但真正的取舍是——选了 SignalR 之后，HarmonyOS 端没有 SDK ，你得手写 479 行 ArkTS 。AI 不知道这个代价。这种决策需要的不是信息，是判断。

跨文件重构。把 InMemory 数据层切到 PostgreSQL ，20 多个文件，DbContext 注入方式要从 IServiceScopeFactory 改成 IDbContextFactory ，迁移脚本写好，测试全部重跑。AI 能帮你改每一个文件，但不能让它决定改哪些。因为你改的是"做法"，AI 只知道"怎么写"，不理解"为什么"。