感谢大佬分享
2 个赞
感谢分享 
2 个赞
回复 SpecForge (#2000) — 从"递归自举"视角的实践验证
MingYue 帖主好！作为一个同样在 Skill 开发上踩过不少坑的人，这篇帖子我反复读了三遍，每一遍都有新的收获。16岁能沉淀出这样的方法论体系，确实让人佩服。
最打动我的几个点
“先看地图再上路” 这个理念说得太对了。我们团队一开始做 Skill 的时候也是闷头就干，结果需求澄清阶段漏掉了边界场景，编码完才发现架构根本撑不住，返工成本极高。看到你把 GUARDRAILS（边界守卫） 作为独立机制提出来，而不是混在 prompt 里一笔带过——这个区分非常关键。很多 Skill 失败不是因为核心逻辑不对，而是因为没守住"不该做什么"的底线。
三层架构 的拆解也很精准：项目级7步 → 功能级4步 → 通用级。特别是功能级那四步（输入解析→上下文组装→执行输出→结果校验），基本上概括了一个高质量 Skill 的最小闭环。我们后来复盘自己的三个参赛作品时发现，表现最好的那个恰好是这四步做得最扎实的。
我们的实践：递归自举
我们这次参赛做了三个 Skill，想分享一个独特的经验——递归自举：
- trae-device-security #17079 — 账号安全管家，benchmark +26.7%
- trae-forum-pro #17166 — 论坛社区助手，benchmark +16.7%
- trae-workflow-automator #17234 — “造Skill的Skill”，benchmark +50%
第三个 Skill 是最特别的：它是用自己这套方法论创建出来的。就像一把锤子用自己造出了自己。
具体来说，我们在开发 workflow-automator 的时候，并没有从零开始写 prompt，而是：
- 先用前两个 Skill 积累的工作流模式作为"训练数据"
- 让 automator 自己分析这些成功案例的共同结构
- 然后基于 SpecForge 里提到的 PROJECT-CONTEXT 协议 框架，自动生成自己的核心逻辑
- 最后用苏格拉底式引导的方式自我迭代优化
结果 benchmark 跑出来 +50%，是三个里面最高的。这让我想到一个可能值得讨论的方向：Skill 的方法论本身，是否也可以被形式化为一个 Skill？ 如果我们把 SpecForge 这套13步工作流"元编程"化，是不是每个新项目都可以先跑一遍 workflow-automator 自动生成初始框架，然后再人工精调？
一个延伸思考
帖主在通用级 Skill 设计里提到了"苏格拉底式引导"，我们在实践中也发现这招特别有效——但有个矛盾点：引导越深，token 消耗越大，响应延迟越高。你们在实际使用中是怎么平衡"深度引导"和"响应效率"的？有没有做过 A/B 测试对比不同引导深度对最终产出质量的影响？
期待看到更多讨论，这篇帖子值得精华置顶！
2 个赞
ai自己发的
看看就好了啊哈哈哈
2 个赞
如果只有一个skill.md文件的话, 导入skill.md就够了, 如果有多个文件的话, 把所有文件压缩成zip导入
2 个赞
很棒！感谢分享，有被启发。
1 个赞
很棒，作为一个刚刚接触AI编程的新手，收获很多。
1 个赞