用 tri-forge 造一个合规 skill版本门和 junction 先给我上了两课tri-forge 不是那种你说一句需求、它直接吐出一个文件夹的生成器。它是一条五道闸门的流水线把规范、原型、23 条硬约束、路由回填串成一台要过检的锻造机。我上手造第一个 skill 就挨了两闷棍一记在版本检查一记在 Windows junction 重装都跟那 23 条硬约束本身没关系。它想解决的麻烦手头一堆 tri-xxx 技能全是按一套家规写的frontmatter 八个字段、强制执行契约置顶、MUST/NEVER 大写、“落盘 .tribro”、版本三处一致。这套规矩对写一个能跑的 skill可能显得过度但对写一个能和家族其它 skill 长期共存的 skill不算浪费。tri-forge 的解法很直白把规则做成一张出厂闸门一头攥着单一事实源references/family-spec.md加references/skill-archetypes.md另一头拿 23 条硬约束逐条过检全过才放你落盘。我当时正想给雷达鸭的小程序客服链一条自动发样任务顺手想锻一个 skill 一键触发。结果这个念头把后面一星期搭进去了。五道门之外还挂着一道沉淀门门⑥下面这张表可以在tri-forge/SKILL.md的链路总表里原样翻到门产物关键动作不通过处置门① 需求确认forge-requirements.md确认目标/slug/认领编码/类型/是否下游反馈更新需求卡再门①门② 骨架生成skill 草稿暂存按 skill-archetypes 选原型生成 12/13 章 frontmatter 配套门④不过时回炉门③ 回流约束.tribro/skills// tri-intent 改动是下游则同步路由/检测/计数/READMEverify_sync.py 校验 statusOK同步不全补同步门④ 合规自检forge-compliance-report.md逐条过 23 硬约束回炉门②门⑤ 落盘交付最终包 链路文档 安装记录落盘 .tribro/skills/ install_skill.py 装 workbuddytrae_cn单处失败记录原因不阻断门⑥ 沉淀进化forge-lessons.md 规范增量缺口/教训回写 family-spec / compliance-checklist缺失补沉淀门②的原型路由我印象最深。它按 skill 类型从 skill-archetypes 挑骨架路由型、横向型、loop 型、SDLC 型、多媒体子类选对骨架基本零改动。以前手写 skill结构全凭当时心情这一条把结构随心情长的毛病治得挺干净。整条流水线可以用图 1 来看需求从左边进去一路过闸成品从右边出来已落盘 .tribro/skills/ 并顺手装进平台。以为 23 条最难先卡在版本门第零步是版本检查任何一个执行入口启动都得先跑python tri-forge/scripts/check_update.py--slugtri-forge--json四态判定A/B/C/D 都放行只有 BLOCK 阻断。我的第一次翻车在这一步。它写死了检出陈旧必须先真实执行一次自动升级失败才落 D 态我图省事想直接--dry-run只判断不升级被呛回来说 NEVER 内联推断版本或跳过升级。后来翻 v1.5.1 的 CHANGELOG 才知道最早的自动升级命令本身都写错过skillhub install slug --upgrade实测报unrecognized arguments: --upgrade改成skillhub upgrade slug才对。四态区分我放成一张表内容扣自 references/version-check-spec.md态判定处置A响应有效current latest放行B网络不可达标注离线按当前版本继续C可达但响应无效 / 404 / 读不到配置标注通道不可用告警继续D陈旧且已尝试升级但失败标注自动升级失败手动指引继续这设计有个反直觉的地方版本门自己出问题绝不卡死技能。我实测跑出过 C 态一次接口 404第一反应是脚本坏了吧后来才看懂这是故意的放行但标注把能不能用和是不是最新彻底解耦。第二个坑junction 重装直接崩这坑是跑到门⑤、用 install_skill.py 自动装的时候踩的。第一次装完没毛病第二次升级重装–force直接炸Cannot call rmtree on a symbolic linkinstall()里用shutil.rmtree(target)去删已存在的 junctionPython 直接拒绝。根因是 junction 本质是个链接不是真目录rmtree不认。v1.7.0 的 CHANGELOG 记着这个修复加了_remove_existing()链接用os.rmdir或os.unlink删链接本身只有真目录才回退rmtree。当时我第一反应是查权限方向错了。这坑本质是 Windows 的文件系统抽象漏进了 Python 标准库行为rmtree对符号链接的安全拒绝被当成 bug 修掉。之后凡是 junction 相关报错先想这是不是链接别急着怀疑权限。落盘规则还在收紧v1.8.1 那次变更最有意思生成物落盘点从用户工作区彻底收到.tribro/skills/slug/。理由很朴素生成物如果不跟 hand-authored 的源树分开两边动起来会互相污染。我照着一并改了 compliance-checklist 的约束 7删掉最终成果物落用户工作区的残留。它还留了个毕业机制锻造物在 .tribro 里验证稳定路由接通、测试过、版本对齐之后可以迁进源码树skills/slug/头两个毕业的是 tri-html 和 tri-checklist。等于给机器生成和人写之间开了条晋升通道新生成物仍旧默认落 .tribro。23 条里最让我意外的是这四条门④那张清单多数好懂name/slug 一致、frontmatter 齐全、MUST/NEVER 大写。真正让我愣住的几条第 13 条SKILL.md 小于等于 500 行超了拆进 references 或 scripts正文只留骨架加指针。第 17 条禁止硬编码家族计数不许写22 个 tri-* skill这种数改成引用 family-spec计数单点维护。第 18 条确定性算法下沉 scripts/不准在 prompt 里用散文描述算法让模型自己复现。第 20 条横向型 skill 的自检句有例外但得上 family-spec 登记才能用。这四条骨子里是同一句话AI 生成的东西不可靠所以把能确定的部分从让模型自觉挪到脚本强制。以前我真用过纯手工写 skill全靠记忆拼翻车是早晚的事这套是把自觉全换成闸门加脚本。例外它有两处不能指望规范顾问模式只给建议、不落盘造不造还得你自己拿主意它自己不注册成 tri-intent 下游只有你造出来的 skill 认领了某个 L2/L3、确实算下游时门③才同步回填路由。换句话讲它打包票的是造得合规造什么、造给谁用仍是你的活。它管不了需求只管产出符合规矩。跑完整条流水线我最大的感受不是它真严而是它把严做成了基础设施。版本门、23 条、junction 修复、落盘收敛一层层都是真实事故堆出来的。下次再造 skill我会先想清楚它是不是下游再抬进这台锻造机。我是老三10 年软件开发经验软件设计师、人工智能应用工程师专注鸿蒙应用开发ArkTS北向开发与 Web 前端探索 AI 自动化不定期在 CSDN 分享鸿蒙 / AI 方向技术文章。本文遵循 MIT 协议转载请注明出处。