文章目录一、三次跃迁从“写规则”到“做工程”二、第一次跃迁Skill 不是大 Prompt三、第二次跃迁Skill 不是全能体四、第三次跃迁Skill 不是一次性执行五、第三跃迁沉淀出的工程机制六、state.json协作流程的中控台七、一个具体恢复场景过去的方式有 state.json 之后八、过去 vs 现在九、最终认知链路十、最终结论一句话总结Skill 的价值不是把一个 Prompt 写得越来越大而是把复杂任务拆成小而清晰的能力单元并用流程、状态和恢复机制把它们稳定串起来。一、三次跃迁从“写规则”到“做工程”阶段原来的想法遇到的问题认知变化第一次跃迁Skill 不是大 PromptAI 漏什么就补什么最后把 Skill 写成一本厚说明书规则越来越重AI 光理解说明就耗掉大量注意力不再堆规则而是给 AI 减负让 Skill 聚焦关键约束第二次跃迁Skill 不是全能体一个 Skill 负责定位、理解、规划、生成、校验、收尾职责混在一起出错难定位维护时牵一发动全身把大 Skill 拆成职责单一的小 Skill第三次跃迁Skill 不是一次性执行拆成小 Skill 后以为就能稳定协作交接、断点、恢复、重试都没有稳定机制用主流程、状态文件、检查点和最小重试把 Skill 变成可恢复流程这三次跃迁的本质是从“让 AI 更聪明”转向“让流程更稳定”。二、第一次跃迁Skill 不是大 Prompt一开始很容易把 Skill 当成一个更大的 Prompt。AI 哪里漏了就补一条规则AI 哪里误解了就再加一段说明AI 哪里不稳定就继续加约束。最后 Skill 会变成一份越来越厚的说明书。问题是规则越多AI 需要理解和遵守的上下文就越重。很多时候模型不是能力不足而是被过量规则拖慢了判断。所以第一次跃迁是Skill 不是把所有规则都塞进去而是只保留当前任务真正需要的关键规则。好的 Skill 应该帮 AI 减负而不是继续制造上下文负担。三、第二次跃迁Skill 不是全能体后来会发现即使 Skill 没有写得特别长只要它承担的职责太多也会很快变得难维护。比如一个 Skill 同时负责定位问题理解上下文制定计划生成内容校验结果收尾交付。看起来很完整但实际会带来几个问题问题表现职责混杂一个 Skill 里既有判断逻辑又有执行逻辑出错难定位不知道是理解错、规划错还是生成错复用困难某个环节想复用时只能连同整套逻辑一起搬走维护成本高改一个局部规则可能影响整个 Skill所以第二次跃迁是Skill 不应该追求“全能”而应该拆成职责清晰的小 Skill。主 Skill 负责调度和流程控制小 Skill 负责局部能力比如定位、理解、规划、生成、校验、交接。四、第三次跃迁Skill 不是一次性执行拆成小 Skill 后流程确实清晰了但新问题也会出现小 Skill 之间如何交接中途失败怎么办用户开了新窗口怎么办某一步生成错了是全部重来还是只重试局部当前做到哪一步谁来记录这时才意识到真正稳定的不是“拆分”本身而是拆分之后的状态管理和恢复机制。第三次跃迁是Skill 不只是一次性执行指令而应该是一套可追踪、可中断、可恢复、可重试的工程流程。五、第三跃迁沉淀出的工程机制机制作用关键点主流程编排决定任务先后顺序主 Skill 不背所有细节只负责流程调度小 Skill 组合承担局部任务每个 Skill 只做一类清晰职责检查点在关键步骤停下确认防止错误一路传递到最终结果state.json记录进度、状态和交接信息支持跨窗口、跨人、跨步骤恢复产物落盘每一步都有留痕便于回看、复用和局部修正最小重试哪里失败修哪里避免一次错误导致整体重来六、state.json协作流程的中控台在第三次跃迁里state.json不只是一个临时文件而是 Skill 流程的交接协议。它至少应该记录{version:1.0.0,timestamp:2026-07-14T21:58:0008:00,task_id:skill_design_article_v1,current_step:review_outline,next_step:rewrite_section_three,completed_steps:[collect_context,draft_outline,write_section_one,write_section_two],artifacts:{outline:artifacts/outline.md,draft:artifacts/draft.md,review_notes:artifacts/review_notes.md},pending_confirmations:[{step:rewrite_section_three,question:是否需要补充恢复流程示例}],last_error:null,retry_policy:{mode:minimal_retry,max_attempts:3}}其中几个字段很关键字段作用version标识交接协议版本便于后续升级兼容timestamp标识最近一次状态更新时间current_step当前执行到哪一步next_step下一步应该继续做什么completed_steps已完成步骤避免重复执行artifacts已生成产物的位置pending_confirmations等待用户确认的事项last_error最近一次失败信息retry_policy失败后的重试策略七、一个具体恢复场景假设正在执行一篇文章改写任务流程做到一半时窗口中断。过去的方式新窗口里AI 不知道之前做到了哪一步。用户只能重新解释背景或者把上一轮内容复制一遍。如果信息没补全AI 可能从头开始甚至改偏方向。有 state.json 之后恢复流程可以变成这样窗口中断 ↓ 新窗口启动 ↓ 读取 state.json ↓ 发现 next_step rewrite_section_three ↓ 加载 artifacts/draft.md 和 artifacts/review_notes.md ↓ 只继续改写第三部分 ↓ 更新 completed_steps 和 timestamp这时新窗口不需要重新理解全部历史只需要读取状态、加载产物、从next_step继续。这就是“可恢复”的关键不是要求 AI 记住一切而是把流程状态显式记录下来。八、过去 vs 现在维度过去一次性黑盒生成现在可恢复的工程流程Skill 设计一个大 Skill 背所有规则主 Skill 调度多个小 Skill执行过程过程不可见每一步有检查点状态管理依赖对话上下文用state.json显式记录中断恢复容易重来从next_step继续错误处理局部失败牵连整体哪里错修哪里产物管理结果散落在对话里产物落盘、路径可追踪协作方式依赖单轮记忆支持跨窗口、跨人交接九、最终认知链路Skill 不是大 Prompt ↓ Skill 不是全能体 ↓ Skill 不是一次性执行 ↓ Skill 是小能力 主流程 状态协议 恢复机制最终会发现Skill 工程化的核心不是“写得更长”而是能拆小能交接能追踪能恢复能局部重试能持续演进。十、最终结论真正稳定的 Skill不是一个越来越复杂的 Prompt而是一套可运行的工程流程。它把复杂任务拆成小 Skill把执行过程交给主流程编排把中间状态记录到state.json再通过检查点、产物落盘和最小重试让任务在中断、失败和跨窗口协作时仍然可以继续推进。这也和之前的「Agent 工程化治理」是一脉相承的上下文治理解决“信息不要乱灌”执行编排解决“复杂任务不要压给一个 Agent”质量闭环解决“结果不能只看生成还要看验证、采纳和持续改进”。而这篇里的核心方法正好可以落在一句话上拆小 Skill状态可追失败可恢复。
文章目录一、三次跃迁从“写规则”到“做工程”二、第一次跃迁Skill 不是大 Prompt三、第二次跃迁Skill 不是全能体四、第三次跃迁Skill 不是一次性执行五、第三跃迁沉淀出的工程机制六、state.json协作流程的中控台七、一个具体恢复场景过去的方式有 state.json 之后八、过去 vs 现在九、最终认知链路十、最终结论一句话总结Skill 的价值不是把一个 Prompt 写得越来越大而是把复杂任务拆成小而清晰的能力单元并用流程、状态和恢复机制把它们稳定串起来。一、三次跃迁从“写规则”到“做工程”阶段原来的想法遇到的问题认知变化第一次跃迁Skill 不是大 PromptAI 漏什么就补什么最后把 Skill 写成一本厚说明书规则越来越重AI 光理解说明就耗掉大量注意力不再堆规则而是给 AI 减负让 Skill 聚焦关键约束第二次跃迁Skill 不是全能体一个 Skill 负责定位、理解、规划、生成、校验、收尾职责混在一起出错难定位维护时牵一发动全身把大 Skill 拆成职责单一的小 Skill第三次跃迁Skill 不是一次性执行拆成小 Skill 后以为就能稳定协作交接、断点、恢复、重试都没有稳定机制用主流程、状态文件、检查点和最小重试把 Skill 变成可恢复流程这三次跃迁的本质是从“让 AI 更聪明”转向“让流程更稳定”。二、第一次跃迁Skill 不是大 Prompt一开始很容易把 Skill 当成一个更大的 Prompt。AI 哪里漏了就补一条规则AI 哪里误解了就再加一段说明AI 哪里不稳定就继续加约束。最后 Skill 会变成一份越来越厚的说明书。问题是规则越多AI 需要理解和遵守的上下文就越重。很多时候模型不是能力不足而是被过量规则拖慢了判断。所以第一次跃迁是Skill 不是把所有规则都塞进去而是只保留当前任务真正需要的关键规则。好的 Skill 应该帮 AI 减负而不是继续制造上下文负担。三、第二次跃迁Skill 不是全能体后来会发现即使 Skill 没有写得特别长只要它承担的职责太多也会很快变得难维护。比如一个 Skill 同时负责定位问题理解上下文制定计划生成内容校验结果收尾交付。看起来很完整但实际会带来几个问题问题表现职责混杂一个 Skill 里既有判断逻辑又有执行逻辑出错难定位不知道是理解错、规划错还是生成错复用困难某个环节想复用时只能连同整套逻辑一起搬走维护成本高改一个局部规则可能影响整个 Skill所以第二次跃迁是Skill 不应该追求“全能”而应该拆成职责清晰的小 Skill。主 Skill 负责调度和流程控制小 Skill 负责局部能力比如定位、理解、规划、生成、校验、交接。四、第三次跃迁Skill 不是一次性执行拆成小 Skill 后流程确实清晰了但新问题也会出现小 Skill 之间如何交接中途失败怎么办用户开了新窗口怎么办某一步生成错了是全部重来还是只重试局部当前做到哪一步谁来记录这时才意识到真正稳定的不是“拆分”本身而是拆分之后的状态管理和恢复机制。第三次跃迁是Skill 不只是一次性执行指令而应该是一套可追踪、可中断、可恢复、可重试的工程流程。五、第三跃迁沉淀出的工程机制机制作用关键点主流程编排决定任务先后顺序主 Skill 不背所有细节只负责流程调度小 Skill 组合承担局部任务每个 Skill 只做一类清晰职责检查点在关键步骤停下确认防止错误一路传递到最终结果state.json记录进度、状态和交接信息支持跨窗口、跨人、跨步骤恢复产物落盘每一步都有留痕便于回看、复用和局部修正最小重试哪里失败修哪里避免一次错误导致整体重来六、state.json协作流程的中控台在第三次跃迁里state.json不只是一个临时文件而是 Skill 流程的交接协议。它至少应该记录{version:1.0.0,timestamp:2026-07-14T21:58:0008:00,task_id:skill_design_article_v1,current_step:review_outline,next_step:rewrite_section_three,completed_steps:[collect_context,draft_outline,write_section_one,write_section_two],artifacts:{outline:artifacts/outline.md,draft:artifacts/draft.md,review_notes:artifacts/review_notes.md},pending_confirmations:[{step:rewrite_section_three,question:是否需要补充恢复流程示例}],last_error:null,retry_policy:{mode:minimal_retry,max_attempts:3}}其中几个字段很关键字段作用version标识交接协议版本便于后续升级兼容timestamp标识最近一次状态更新时间current_step当前执行到哪一步next_step下一步应该继续做什么completed_steps已完成步骤避免重复执行artifacts已生成产物的位置pending_confirmations等待用户确认的事项last_error最近一次失败信息retry_policy失败后的重试策略七、一个具体恢复场景假设正在执行一篇文章改写任务流程做到一半时窗口中断。过去的方式新窗口里AI 不知道之前做到了哪一步。用户只能重新解释背景或者把上一轮内容复制一遍。如果信息没补全AI 可能从头开始甚至改偏方向。有 state.json 之后恢复流程可以变成这样窗口中断 ↓ 新窗口启动 ↓ 读取 state.json ↓ 发现 next_step rewrite_section_three ↓ 加载 artifacts/draft.md 和 artifacts/review_notes.md ↓ 只继续改写第三部分 ↓ 更新 completed_steps 和 timestamp这时新窗口不需要重新理解全部历史只需要读取状态、加载产物、从next_step继续。这就是“可恢复”的关键不是要求 AI 记住一切而是把流程状态显式记录下来。八、过去 vs 现在维度过去一次性黑盒生成现在可恢复的工程流程Skill 设计一个大 Skill 背所有规则主 Skill 调度多个小 Skill执行过程过程不可见每一步有检查点状态管理依赖对话上下文用state.json显式记录中断恢复容易重来从next_step继续错误处理局部失败牵连整体哪里错修哪里产物管理结果散落在对话里产物落盘、路径可追踪协作方式依赖单轮记忆支持跨窗口、跨人交接九、最终认知链路Skill 不是大 Prompt ↓ Skill 不是全能体 ↓ Skill 不是一次性执行 ↓ Skill 是小能力 主流程 状态协议 恢复机制最终会发现Skill 工程化的核心不是“写得更长”而是能拆小能交接能追踪能恢复能局部重试能持续演进。十、最终结论真正稳定的 Skill不是一个越来越复杂的 Prompt而是一套可运行的工程流程。它把复杂任务拆成小 Skill把执行过程交给主流程编排把中间状态记录到state.json再通过检查点、产物落盘和最小重试让任务在中断、失败和跨窗口协作时仍然可以继续推进。这也和之前的「Agent 工程化治理」是一脉相承的上下文治理解决“信息不要乱灌”执行编排解决“复杂任务不要压给一个 Agent”质量闭环解决“结果不能只看生成还要看验证、采纳和持续改进”。而这篇里的核心方法正好可以落在一句话上拆小 Skill状态可追失败可恢复。
