持续总结实践经验1. 用 skill-creator 生成初版不要从空白页空想结构。用 Cursor 的skill-creatorcreate-skill先出一版目录、SKILL.mdfrontmatter、description、基本章节都按规范搭好。初版的目标是「能跑、能触发」不是「一次写完美」。人只补领域约束和本仓库约定骨架交给工具省掉格式纠结。2. 固定逻辑脚本化动态逻辑交给 LLMSkill 里两类事要分开类型谁做原因固定逻辑脚本命名、转换、合并、校验——结果应可复现动态逻辑LLM造数策略、业务判断、边界怎么补——需要理解上下文能算死、一算错就全盘歪的写成脚本并在 Skill 里写清以脚本输出为准禁止重算臆造。需要智能的部分留给模型。这样过程随机性会明显下降失败也可定位到「脚本」还是「判断」。3. LLM 必做的确定性事项写成自然语言硬门禁有些事没法或不值得脚本化但结果必须确定——例如「未读 plan 不得落库」「清场必须进 finally」「error 清零前不得宣称完成」。这类约定交给 LLM 执行时不要写成「建议」「尽量」「最好」要用自然语言写成硬门禁可判定、可违反即停、无商量余地。软建议会被跳过硬门禁才会改变行为。脚本管算得死的硬门禁管「必须靠模型遵守、但结果不能飘」的那一层。4. 生成式 Skill 必须带评测凡是「生成产物」的 Skill用例、代码、文档草稿等不能停在「生成完了」。要加一层多方位评测结构是否合规、约定是否满足、关键路径是否可跑通等等。评测最好可脚本化、可出下一步修复建议未过门禁就不许宣称完成。生成 → 评测 → 按意见修 → 再评比单纯加长SKILL.md更能稳住质量。5. 多轮迭代后主动清理冗余Skill 会随踩坑变长多一条禁令、多一段解释、多一个特例。迭代几轮后要专门做一次「减肥」删已被脚本/评测兜住的重复说明删从未改变行为的软建议和背景长文细节外置到旁路文件主文件只留主路径与硬门禁短而硬比长而全更不容易把上下文撑满也更容易被真正执行。6. 长任务拆成主子智能体单次对话塞完整条长流水线上下文会膨胀、中后段开始丢约束。做法是把重复、可并行、边界清晰的工作拆成子任务由主智能体编排、子智能体执行单块再汇总结果。主智能体只保留目标、进度与接口约定子智能体各自带着小上下文干活。长任务不再「一条对话扛到底」Skill 也更像编排手册而不是巨型操作手册。7. 用 LLM 评估 Skill 的优化空间Skill 写完、跑过几轮之后把失败案例、多余步骤、反复口头纠正过的点丢给 LLM让它专门评估哪里该脚本化、哪里该升硬门禁、哪里是冗余、哪里该拆子任务。人审结论再改一版。这和「评测生成产物」不同那边验输出质量这边审 Skill 本身是否还在帮倒忙。定期用 LLM 做一次「Skill 体检」比凭感觉加条文更对症。8. Skill编写纪律原则大于规则要记得告诉why。把AI当做聪明人这样面对未规划场景时也能自主泛化处理。防止跑偏就需要定硬门禁。