先识别问题长 prompt 失控不是文字问题很多 Skill 一开始都很朴素读输入、分析、调用脚本、生成结果、做一次校验。第一次上线时一个workflow.md足够清楚。真正的麻烦通常发生在后面用户要重跑校验、只改某个结论、从中断处恢复维护者于是不断往同一个文件里加if create、if validate、if edit、if resume。这时继续补一句“不要跳过步骤”或者“验证阶段禁止修改文件”效果很有限。模型看到的仍然是一团混合状态它同时知道生成链路、验证链路、编辑链路和恢复链路也就容易在该只读的时候顺手修复在该局部修改的时候重新生成全文。长 prompt 失控本质不是文字太多而是生命周期、权限和完成条件混在了同一层。图长 workflow 中的状态混杂如何导致边界失控。失控迹象常见补丁更底层的原因模型跳过中间步骤反复强调“必须逐步执行”每一步没有独立完成条件也没有明确的下一跳Validate 阶段顺手修复再写一条“只读”规则验证和编辑共享同一上下文边界只靠自然语言提醒中途失败只能从头跑让模型重新读取全部材料进度没有外化产物也没有检查点文件越写越长继续追加分支说明入口路由、执行逻辑、校验门禁被放在同一层判断一个 Skill 是否需要升级不看它有多少行 prompt而看它是否已经拥有多个生命周期。如果同一个入口既要创建、又要校验、还要局部编辑或续跑那么它已经不是“提示词写得更细”能解决的问题。Mode-Step 网格把生命周期和执行步骤分开Tri-Modal Step File 的核心可以压成一句话外层按 Mode 分生命周期内层按 Step 分执行阶段。Agent 先进入某个 Mode再加载该 Mode 下的当前 Step File。每个文件只承担一段很窄的职责。换句话说Mode 管生命周期Step 管当前动作。这两个维度拆开以后生成、校验、编辑、续跑才不会在同一份提示词里互相污染。图Mode-Step 网格把生命周期和当前动作拆开让模型只进入一个窄边界状态。图Mode 管生命周期Step 管当前执行阶段。Mode典型目录适合处理的意图必须守住的边界Createsteps-c/从零读取上下文、分析材料、生成目标产物可以创建新 artifact但要按 Step 前进Validatesteps-v/对已有产物做重新校验、覆盖率检查、差异核对默认只读只输出PASS / CONCERNS / FAILEditsteps-e/针对某个章节、规则、finding 做局部修改先评估影响范围再做定点替换避免重生成Resume通常不单独成目录读取 frontmatter、sentinel 或日志判断从哪里继续只负责路由不承担业务执行这个拆法的好处很实际新增一次局部编辑能力不必去改 Create 主链路补一个重新校验规则也不会把生成逻辑搅乱。维护者先找 Mode再找 Step改动范围通常会小很多。Step File给模型一个局部执行契约Step File 不是把长 prompt 切成几段那么简单。它更像一份小契约告诉模型这一步唯一目标是什么可以看哪些上下文哪些事情绝对不能做执行顺序是什么怎样算完成完成后去哪里。图Step File 像一份局部执行契约把目标、边界、顺序和验收条件钉住。图一个 Step File 应同时约束目标、边界、顺序、验收和下一跳。一个可维护的 Step File 至少应该写清这些内容契约字段解决的问题写作要点STEP GOAL防止模型在本步做太多事用一句话说清本步唯一目标MANDATORY RULES固定必须遵守的纪律少而硬不写泛泛的价值观CONTEXT BOUNDARIES防止上下文外溢明确可读材料、可写文件和禁止动作MANDATORY SEQUENCE防止跳步写成可执行顺序不写抽象建议SUCCESS CRITERIA让步骤可验收用可判断的完成条件不用“尽量完善”NEXT STEP让状态可转移成功、失败、需人工介入时分别去哪目录结构也不需要复杂关键是让人一眼看出生命周期和步骤边界skills/your-skill/ ├── SKILL.md ├── workflow.md ├── workflow.yaml ├── steps-c/ │ ├── step-01-gather-inputs.md │ ├── step-02-analyze.md │ └── step-03-generate-output.md ├── steps-v/ │ └── step-01-validate.md ├── steps-e/ │ └── step-01-assess-and-edit.md ├── scripts/ ├── references/ └── templates/其中workflow.md不应该继续承载业务细节。它只做初始化、参数优先级处理、预检查、模式判断和首步路由。确定性逻辑尽量放进scripts/比如解析输入、做 diff、检查格式、统计覆盖率、渲染报告。LLM 更适合做语义理解、归纳和取舍不适合靠记忆执行一堆机械门禁。按状态加载不是少读上下文而是读对上下文Step File 经常被误解成“减少上下文”。减少当然有价值但更关键的是按状态加载上下文。普通渐进式加载是按需读资料主要缓解 token 压力Mode-Step 加载是先判断状态再读取这个状态需要的材料目标是压住边界漂移。图Mode-Step 加载不是少读上下文而是按状态读取正确上下文。当 Agent 知道自己处在Validate / step-02-check它就不需要同时携带 Create 的生成细则和 Edit 的替换策略。它只需要读校验输入、执行检查、输出结论。边界越窄模型越不容易“热心过头”。这种设计还会自然带来检查点。每个 Step 的输出可以写入 artifact frontmatter、状态文件或 sentinel。下一次 Resume 不是让模型猜“我上次做到哪了”而是读取状态记录再回到对应 Mode 的对应 Step。图Step 输出、检查点和 Gate 共同支撑续跑与失败恢复。什么时候值得上什么时候别上这个模式不是默认模板。一次性问答、单脚本调用、输入输出都很单一的小工具没必要套一层工程结构。越早过度工程化越容易把简单问题写复杂。更好的触发信号是流程已经出现第二个生命周期或者失败后重跑成本明显变高。比如同一个 Skill 既要生成长期产物又要允许后续校验和局部修订或者它需要多人维护PR 里经常有人看不出到底该改哪段规则。适合使用 Mode-Step不适合使用 Mode-Step同一个 Skill 同时支持生成、校验、编辑、恢复一次性问答或一次性改写有 3 个以上连续步骤且每步有中间产物两三句话就能说清的小工具输入来源复杂需要参数优先级和缺失处理输入单一、输出单一、失败成本低流程可能中断需要从中间继续没有中间状态也不沉淀 artifact多人长期维护需要明确修改边界短期实验性 prompt一个很实用的判断是如果你已经在workflow.md里写了第二条if mode ...就该停一下。继续往下堆分支并不是不行但那通常意味着你正在用 prompt 模拟一个没有显式建模的状态机。从旧 Skill 迁移先切主链路再隔离校验迁移不必一步到位。最稳的做法是先保留原来的用户入口只把 Create 主链路切成几个 Step。这样用户行为不变维护者却能立刻获得更短的上下文和更清楚的执行边界。图迁移旧 Skill 时先切主链路再隔离校验和检查点风险最低。迁移阶段具体做法为什么这样风险低切出steps-c/把原有主流程拆成输入收集、分析、生成几个 Step不改变入口只降低单步复杂度增加检查点给产物写stepsCompleted、changelog或 sentinelResume 有了事实依据不靠模型记忆隔离steps-v/把重新校验从 Create 中拿出来Validate 的只读边界最容易被污染值得优先隔离补steps-e/在真实出现局部返工后再设计编辑路径Edit 的边界来自实际场景过早设计容易空泛从设计顺序看不要先问“我要建几个 Step 文件”。先问最终产物是什么、哪些错误不能发生、失败时如何发现、哪些逻辑可以脚本化。Step 只是承载这些约束的容器。落地前的工程检查写复杂 Skill 前可以先做一轮很短的设计检查最终产物的路径、格式、更新方式是否明确。用户会触发哪些生命周期Create / Validate / Edit / Resume 是否需要分开。上下文来源是否有优先级显式参数、本地配置、自动探测和询问用户的顺序是否固定。每个 Step 是否只有一个目标是否写明本步不能做什么。失败后能否从某个 Step 恢复而不是从头重跑。解析、格式校验、覆盖率、diff、渲染这些确定性工作是否已经尽量下沉到脚本。Validate 是否只读Edit 是否局部Create 是否不会偷偷承担校验修复职责。每个 Step 末尾是否有明确的下一跳或完成标记。最小可行改造其实不重一个入口workflow.md一条steps-c/主链路再加一条只读的steps-v/校验链路通常就能明显减少跳步、越界和失败后重跑的问题。Resume 和 Edit 可以等真实返工场景出现后再补不必一开始就把所有未来情况设计完。结语别让模型猜状态Prompt 思维经常问“我还要告诉模型什么”Workflow 思维会先问“模型此刻处在哪个状态它能读什么不能做什么完成后转移到哪里”这两个问题不是同一层级。复杂 Skill 的稳定性来自状态显式化、边界契约化、检查点外化和门禁脚本化。长 prompt 能把规则写进去但很难保证模型在正确的时间只使用正确的那一部分。Mode-Step 网格的价值就在于把这些隐含状态拆开让模型不用每次都重新猜。
