先诊断返工，再决定怎样转型
一家地方戏剧工作室将演出资料改写为票务介绍、公众号文章和短视频解说。现有流程会复制字段、调用模型、生成排期，但每当演员变更或场次取消，十份稿件就容易混入旧信息。这个问题可以涉及数据契约、版本和审核，不应先归咎于 workflow 画布。本例设计迁移方法，没有连接票务平台、发布内容或创建持续运行任务。
原文覆盖痛点诊断、Skills 模块化和自然语言编排，并讨论反馈进化。本文保留这些场景，纠正“可视流程只能表达线性逻辑”和“拆一次便可无限无成本复用”的推断。条件、循环和动态步骤都可能存在于工作流中；Skill 让方法更便于组织，不会自动迁移连接器、凭证与运行状态。
场景一：追踪一条错误穿过了哪里
选最近一次演员变更作为诊断样例。保留源资料版本、模型输入、输出草稿、审核记录和排期项，逐步比较。若新资料没有进入模型，是取数或缓存问题；若输入正确而输出旧演员，是生成或上下文问题；若审核后被旧草稿覆盖，是版本与写入问题。三个原因不能用“换更聪明 Agent”统一解决。
画一张现状图，标出选题、事实提取、写作、排版、审核与发布，每个节点写输入输出、拥有者、失败标记和耗时。收集实际等待和返工，不把模型猜测的效率提升当成测量。定位固定规则、需要判断的内容与外部副作用，决定保留、修复或试验迁移哪一部分。
第一轮可能只修复事实版本传递，保留现有定时和保存。如果固定格式也频繁失败，先明确字段与错误处理；如果需要按素材灵活选择叙事角度，再考虑动态方法。方案输出包含诊断证据、根因假设、最小改动和验收用例，不是一份工具购物清单。
场景二：按稳定责任划模块
不要机械地把每个点击都做成一个 Skill。提取“核对演出事实”“为指定渠道起草”“检查跨稿一致性”等有明确产物的责任。演员、日期、票价和取消政策来自批准事实包；渠道语气可以变化，事实不可在写作阶段自由改造。需要搜索新资料时另列来源验证，不能暗含在文案润色里。
定义输入 schema：production_id、事实版本、目标渠道、素材位置和约束。输出含草稿、事实对应关系、待核对项和完成状态。缺票价时不生成确定价格，演出取消时不继续输出购票催促。模块的停止条件与正常路径同样重要；一个状态为待审核的文件不算可发布成品。
方法包主说明保持适用范围与步骤清楚，长规则放参考材料，模板定义报告格式。包内脚本要有依赖和读写范围，客户、演员个人信息与临时凭证不进入共享方法。仅格式合法不代表可靠：准备正常演出、日期冲突、缺字段、取消和不相关任务等样例，检查触发与输出。
跨宿主迁移时分别核对发现路径、工具调用、脚本语言与资源引用。安装同一目录结构不能保证所有客户端运行一致。旧 workflow 负责的调度、接口和幂等写入必须明确交接，不能因为方法搬成文字就声称运行设施已迁移。
场景三：自然语言请求也要约定状态
一次请求可以是：“用演出资料 v6 生成票务介绍和解说草稿；每项事实附来源；缺失列待核对；只保存草稿，不发布。”主控先读取当前事实，再安排可独立起草的部分，最后汇总一致性检查。一个 Agent 顺序完成也成立，多 Agent 并行需要明确授权、独立产物和汇合条件，不是必选项。
保存 run_id、当前步骤、产物版本和审批状态。恢复时核对实际文件与已完成动作，不能只靠聊天回忆。读取失败可以有限重试，写入或发布超时先查结果，防止重复。不同模块不要同时改同一主稿，复核建议通过明确修订更新，旧结果不能覆盖新事实。
若每个平台拆成独立方法，需共享事实接口和基础规则，否则十个版本会变成十份互相漂移的规范。可保留一个公共事实模块与少量渠道适配材料，是否拆分以维护和试验结果决定。输入一次生成十稿只是批量形态，不证明十稿均正确或能直接发布。
反馈进化要有证据与回退
收集具体问题，例如“取消场次仍生成购票引导”，保留输入、输出、规则版本和人工判断。先提出原因假设，再做候选修改，避免看到一个低阅读数就让 Agent 自动重写所有策略。阅读变化也可能来自题材、发布时间、分发和样本量，不是文案规则优劣的直接证明。
分别验证方法有没有在相关任务触发，以及触发后产物是否合格。GitHub 的 Agent Skills 描述优化文档提供了正例、反例与保留样例思路，适合作为触发测试参考；不要把描述越宽、触发越多当作更好。样例用于修改后，另用没参与调优的请求检查，防止只记住原题。
对输出先看硬条件：事实一致、无捏造、未知保留、取消逻辑正确，再看语气与结构。把旧版和新版的通过项、失败项、用量与人工修订并列；没有明显收益或出现回归就不晋升。候选改动必须有版本、负责人、依据和回滚点，持续运行不等于持续改善。
一次完整的小规模迁移
用获准的虚构演出资料做影子运行，原系统继续作为唯一实际发布入口。新方法只产出草稿，比较同一输入下的演员、日期、渠道格式和待核对项。再注入演员替换与场次取消，确认所有相关草稿引用新版本，而其他已批准信息保持可追溯。
验收报告列明输入范围、产物清单、每个测试结果与未覆盖项。迁移达到门槛后再决定切换哪一步，不先删旧工作流。保存原配置与恢复说明，明确未来由谁维护共享规范。成本比较包括模型、工具、复核、失败重跑和维护时间，不只展示第一版生成耗时。
Skill 关联与使用前提
本专题未为原文六张卡片建立对应本站固定源码与用途证据，其中还包含重复名称，因此不添加推测链接。后续补充候选按诊断、模块化或编排阶段逐一核验 SKILL.md、许可证、依赖和实际访问，再指定使用步骤。不把“通用”“主动”或“自动进化”标题当作能力证明。
发现工具可以协助搜索，但无法替你确认数据接口和迁移成效。任何包采用前都要检查宿主支持、文件范围、网络与费用，用一份可恢复小样验收；卸载不会回收已发布内容或外部写入。本文没有安装框架或执行包内脚本，所有示例测试均为待执行的验收设计。
排查与 FAQ
新旧两套同时出稿冲突？区分草稿与正式发布权限，保证唯一发布入口和版本绑定。每次改平台要求都要改十个包？检查公共规则是否重复，适当合并共享部分。触发正常但输出差？看执行和输入，不继续盲改 description。包不触发？先确认宿主发现和实际适用范围，再调整描述。
是否必须抛弃 workflow？不必，保留稳定调度和写入，把方法放在需要判断的步骤。自然语言是否不用逻辑？依赖、条件和恢复仍要明确。能否保证日更十篇更省钱？不能，质量、模型、重试与人工成本需要实际比较。谁决定进化？负责人依据测试与实际反馈审核，自动提出修改不等于自动获准上线。
来源
中文原文提供诊断、模块化与编排场景；本文用独立戏剧案例覆盖迁移和反馈，不沿用下载量与必然自我优化保证。GitHub 的 Agent Skills 描述优化文档提供可核对的触发测试参考，本文仅借鉴测试边界，没有安装或执行所述流程。