从崩溃日志到 AI 技能：tri-god 蒸馏实战

做鸿蒙应用这几年，最折磨我的不是写,是看崩溃日志。尤其 App 上线后，用户一句「闪退」甩过来，后台给我一屏堆栈。早期我全靠手感：这个错我见过，那个是 native 的，这条八成是生命周期。手感好了就能两分钟内指对方向，手感不好就对着 Hiview 里的日志发呆半小时。

后来团队的排查活越来越多，我意识到一件事：这套「手感」没法复制。别人问我看日志先看什么，我说「先看是不是 ArkTS 侧」，再问细节，我又说不清了。知识长在我脑子里，说出来全是「凭直觉」。

把直觉变成 AI 能照做的判断规则，这就是 tri-god 干的事。

tri-god 是什么，一句话

它是 tri-xxx 家族里的「蒸馏造物」skill。简单说，你给它一个对象（一个人的经验、一套流程、一门手艺），它按对应的方法论，把里面可复用的判断规则提炼出来，封装成一个 Agent 能独立调用的新 skill。产物不是一篇总结，是一套能跑的技能目录。

它怎么知道该用哪套方法？靠 methodologies/registry.md 做映射，只认五类对象。我这次要蒸的是「怎么快速定位崩溃」这门手艺，属于「专业技能」，tri-god 就锁定了 distill-skill.md：

这套加载逻辑不难懂，其实就是一个按类型加压字典：

python 复制代码

# 借鉴 tri-god/methodologies/registry.md 的思路
# 蒸馏对象类型 -> 方法论文件 的注册映射
REGISTRY = {
    "human":     "distill-human.md",     # 蒸馏某人的思维方式
    "workflow":  "distill-workflow.md",  # 蒸馏一套可复用流程
    "skill":     "distill-skill.md",     # 蒸馏一门专业技能 <-- 我这里走这条
    "thing":     "distill-thing.md",     # 蒸馏书/课程里的知识框架
}

def load_method(obj_type: str):
    # 精确命中就加载对应方法论，匹配不上就兜到通用档
    return REGISTRY.get(obj_type, "distill-general.md")

tri-god 真正值钱的不是这个 if 判断，是它逼着用户走完三道审批门（需求、设计、任务清单），每一道都要基于真实素材。这条铁律救了我。

第一道坎：它拒绝「凭记忆蒸馏」

最开始我想省事，直接跟它说「把我排查崩溃的经验蒸成技能」。tri-god 没接活，先反问我要素材：你的排查案例、拆过的堆栈、坑过你的报错记录在哪？

我当时觉得它死板。后来想通了：凭记忆蒸馏出来的规则，跟凭记忆写出来的代码一样，全是幻觉。我脑补的「先看 native 帧」，万一只是我碰巧记得的几条呢？没有真实样本兜底，蒸出来的 skill 会在第一个陌生日志上翻车。

于是我把最近一年处理过的二十多个崩溃案例导出，按「日志长什么样、我第一眼看了什么、最后定位到哪」归成三列。这就是 distill-skill 第二阶段要的素材，核心追问是那句「你当时为什么这么判断」。

把「手感」逼成 IF-THEN 规则

distill-skill 的第三阶段是蒸馏的核心：把直觉提炼成 IF 观察到 X THEN 采取 Y，因为 Z 的决策规则，每条都要能回溯到一次真实的排查。我那些「凭感觉」的判断，被硬逼着说出理由之后，长这样：

python 复制代码

# 蒸馏产物：崩溃日志首诊决策规则（IF-THEN 启发式）
def first_responder(log: StockLog) -> str:
    # 规则 1：没有 ArkTS/JS 侧业务帧，全是 native 帧 -> 先怀疑 so / 系统库
    if has_native_only_frames(log):
        return ("native", "多半是第三方 so 或系统库,先搜相关 .so 的 issue")

    # 规则 2：带 Hiview 或 /dev/shm 信号 -> 疑似 OOM / 匿名内存,别在业务代码里找
    if "Hiview" in log.raw or "shm" in log.raw:
        return ("memory", "优先查内存占用,不是业务空指针")

    # 规则 3：业务帧以 Page 或 onDestroy 收尾 -> 生命周期释放问题
    if log.ends_with("Page", "onDestroy"):
        return ("lifecycle", "页面销毁后仍有异步回写,查未取消的协程/回调")

    # 规则 4（兜底）:都不像 -> 先看 LogCat 里崩溃前 20 行用户操作
    return ("unknown", "回滚到崩溃前 20 行日志,找用户最后一步操作")

看出区别了吗？手写 prompt 是我替 AI 定规则，规则一多就打架；蒸馏是让 AI 从我那一列「为什么」里自己长规则。规则 2 那条「Hiview 就想到 OOM」，就是我从三个真实 OOM 案例里逼出来的，不是我猜的。这个细节，教科书里没有。

蒸馏还逼我见了反模式。distill-skill 第五阶段硬性要求写清「什么情况这套规则会失效」。我发现一个特别打脸的坑：某些 ArkTS 侧报错其实是 native 泄漏带来的，按规则 1 只看堆栈会误判。所以第二条我加了一条边界单行注释：遇到「既是 native 又反复偶发」的，直接升级人工，别让 AI 硬猜。

版本门：为什么连这个技能自己也要自检

tri-god 家族有个很轴的约定，叫「第零步版本门」。每个 skill 跑之前,都先跑一段 scripts/check_update.py，连着 skillhub 校验自己是不是最新版，不是就自动升级。上次用它蒸馏，我看见脚本开头那几行注释写得很实在：

python 复制代码

# check_update.py 的四态判定与 version-gate.md 逐条对应：
#   A 校验通过   响应有效且 current >= latest
#   B 离线降级   网络不可达，重试 1 次仍失败
#   C 通道降级   可达但响应无效（非 200 / 非 JSON / 读不到配置）
#   D 升级降级   确实陈旧且尝试过升级但未完成

这套「降级了也能继续跑，只有真堵死才阻断」的思路，我在交付自己的技能时照搬了。蒸出来的 skill 一旦版本落后，同样要先说明自己是第几次被校验、能不能放行，绝不能静默跑旧逻辑。把「自己也要被审计」写进规则，是我的蒸馏产物和网上那些 prompt 模板最大的不同。

蒸完怎么验收：诱饵压力测试

最后一步是压力测试。distill-skill 要求的不只是「正例能跑对」，还得做「诱饵测试」：造一些长得像、其实不该用它判定的场景，确认 skill 不会越界乱接。

我给那套首诊规则造了两个诱饵：一个日志开头干净利落、其实属于 HotFix 回归问题，不该推到定位链路；一个明显是配置错误导致的崩溃，属于部署问题。确认 skill 拒绝接手，直接留白返回「不适用，建议转 XX 流程」。这一步通过了，我才敢把技能交出去。

这套流程折腾下来，把我三分钟的手感变成了一段三行能看懂的小函数。现在团队再有人丢崩溃日志过来，先丢给这个 skill 首诊，命中率八成以上，漏的会明确说「升级人工」，不再硬给结论。省下的时间远大于建它那半天。

说个小教训收尾。蒸馏和写 prompt 最大的差别，是「素材必须真实」这条硬约束。它挡着我走捷径，也保证了产物不是正确的废话。你要是手头也有反复在做、又觉得「说不清怎么做」的判断活，别急着写 prompt，先攒素材，再去蒸馏。一次沉淀，团队里人人都能借用你的手感。

顺带一提，这套「先蒸规则、再单独验收边界」的做法，我现在也用在自己做的雷达鸭上，它的选题和案例审核流程就是这么蒸出来的。如果你也在一个人维护带判断逻辑的小项目，与其让 AI 每次都重新理解，不如先把你的判断沉下来。

我是老三，10+ 年软件开发经验，软件设计师、人工智能应用工程师，专注鸿蒙应用开发（ArkTS）北向开发与 Web 前端，平时爱折腾 AI 自动化，不定期在 CSDN 分享鸿蒙 / AI 方向的技术文章。

本文遵循 MIT 协议，转载请注明出处。