如果你在用 Agent 或 Skills，这篇值得看。SmolForge 用两个真实事故告诉你，生产环境里一个 Skill 能怎么把简单发布拖成 7 小时架构工程。
swyx 提醒用户在生产环境中谨慎使用 Skills，并建议定期删除不必要的 Skills。SmolForge 团队分享了两个生产环境中的失败案例：JFDI 技能将免确认权限扩张为 10 类常驻权限，导致 agent 局部合规但全局永不停止；Maintainability Guardrails 技能因触发词过宽，将窄修复撑成一小时的无关加固。这两个案例暴露了 Skills 的权限、作用域和持久性三大致命问题。个人工作流可尝试 Skills，但生产环境必须按代码标准审查其作用域、重试与终止条件。
赞同 @swyx 对 Skills 在生产环境的判断！ 如果你只是完成个人工作流，可以放心的尝试一些 Skills，虽然它们肯定没有传说中那么神乎其神，过滤掉泡沫看这个 Skill 对你个人有没有实...
赞同 @swyx 对 Skills 在生产环境的判断！ 如果你只是完成个人工作流，可以放心的尝试一些 Skills，虽然它们肯定没有传说中那么神乎其神，过滤掉泡沫看这个 Skill 对你个人有没有实际提升，就可以。 但如果是在生产环境，一定要特别谨慎，如果要采纳某个 Skill，要了解清楚它的权限、触发范围、工作痕迹等等；而且个人工作环境，尽量和生产环境隔离。 因为 Skills 引导的 Agent 策略一旦授予生产权限，就等同于生产代码——必须按代码标准审查其作用域、重试与终止条件；有时最安全的"补丁"不是更详细的 Skill，是删掉那条教 Agent 永不停止的 Skill。 SmolForge 团队的两个生产环境的例子，很值得反思： forge.smol.ai/blog/dangerous… 1. JFDI (Just Fucking Do It) 把"已批准任务免再确认"扩张为 10 类常驻生产权限（推 main、跑发布编排、改 provider 策略、跑迁移、中断重试、自举 Forge）的发布运营 skill。 致命问题：把"持续推进"绑到一个会移动的验收条件上——每暴露一个新平台缺陷就被字面契约重新归类为"依赖缺口"而吸入作用域，于是 agent 局部每步都合规、全局却永不停止，把一次发布变成了一场优化发布系统的 7 小时架构工程。 2. Maintainability Guardrails 把"避免巨型文件/脆弱重构/浅测试"等质量清单绑定到 "most substantial coding work" 触发词的代码质量 skill。 致命问题：触发词几乎涵盖所有值得交给 agent 的任务，使整份清单自动成为每个任务的"完成定义"——于是它扩大了 agent 认为好工作应包含的范围，把一次窄修复撑成一小时无关的架构与测试加固。 这两个 Skills 在生产环境中刚好命中了三个致命问题： 1. 权限问题——把"免确认"扩张为"相邻变更已批准"（JFDI 的 permission 维度）。 2. 作用域问题——把"完成请求"扩张为"吸收路径上所有依赖缺陷"（JFDI 的 scope 维度 + Maintainability 的触发广度）。 3. 持久性问题——把"持续推进"扩张为"直到一个会移动的验收条件满足"（JFDI 的 persistence 维度）。 swyx @swyx occasional reminder to DELETE your skills. forge.smol.ai/blog/dangerous… when you are bombarded constantly by "this skill changed my life!! you have to try!!" on the timeline, you will pile up stuff that at best just eats context, and at worst interacts with other skills nastily in unforeseen ways if you dont stare at your traces. 🔗 View Quoted Tweet 💬 1 🔄 0 ❤️ 0 👀 334 📊 1 ⚡