反复修改 Prompt 仍不稳定，任务该沉淀成 Skill

一项任务反复修改 Prompt 仍然不稳定，可以把其中已经确定的方法、输入输出和失败处理整理成技能（Skill）。Prompt 继续传递当前目标和临时要求，Skill 保存可复用的任务方法，工作流（Workflow）负责连接多个步骤。三类内容分开放，模型每次需要理解的规则会更清楚。

ZGI 将 Agent、Skill、知识、数据库和 Workflow 组织在同一个可自托管 Agent Runtime 工作区中。遇到频繁复用的文件处理、报告生成、计算或数据库任务时，团队可以把稳定做法从单次对话中抽出来，再由 Agent 或 Workflow 按需调用。

Prompt 为什么会越改越长

很多 Prompt 最初只有目标和几条限制。任务迭代几轮后，异常处理、输出格式、工具说明、历史经验和临时补丁不断追加，同一条规则还可能出现多个版本。模型需要先判断哪些要求仍然有效，再决定怎样执行，结果自然容易波动。

长 Prompt 也很难承载脚本、模板和参考资料。即使文字写得完整，不同成员复制时仍可能漏掉附件，修改后的版本也难以同步。某次成功依赖哪条规则，往往只能靠人回忆。

三类内容可以按职责拆开：

Prompt 写得长并不必然需要改成 Skill。只执行一次、规则仍在探索、每次目标差异很大的任务，继续用 Prompt 调整更省事。出现下面三个信号后，沉淀的价值会明显增加。

哪些信号说明该做成 Skill

第一个信号是重复。相似任务已经由不同成员多次执行，每次都要重新解释步骤、格式和注意事项。把共同部分整理出来，可以减少口口相传造成的偏差。

第二个信号是任务开始依赖固定资源。脚本、模板、字段说明、示例文件和检查规则需要一起出现，单独复制一段 Prompt 已经无法还原完整方法。Skill 可以把说明与所需资源放在同一能力包中，调用时再加载相关内容。

第三个信号是结果能够验收。团队已经知道什么算完成，哪些字段必须存在，遇到哪些情况要停止或转人工。缺少验收标准时，Skill 只会把一套模糊做法复制得更快。

一个可复用 Skill 要留下什么

先写清任务边界。它接收哪些输入，允许访问哪些资料和工具，产出什么结果，哪些情况超出处理范围。边界越清楚，Agent 越容易判断什么时候调用它。

随后整理执行材料。固定步骤写进说明，可确定的处理交给脚本，长篇参考资料按需读取，输出模板与字段规范单独保存。这样可以减少每次对话携带的内容，也方便团队只修改发生变化的部分。

失败处理也要写进任务契约。文件缺失时停止还是追问，接口超时能否重试，结果为空是否允许继续，高风险动作由谁确认。Skill 给出处理规则，Workflow 再把重试、分支和审批接进完整业务链路。

以批量整理合同信息为例，用户本次要处理的文件范围和交付时间属于 Prompt；字段提取方法、格式模板和异常说明适合进入 Skill；上传文件、调用识别、人工复核和写入系统的先后关系由 Workflow 管理。规则改动时，团队无需把整段对话重新拼一遍。

在 ZGI 中怎样验证这次沉淀

ZGI 的 Runtime Skills 可与 Agent、知识、数据库和 Workflow 配合，适合把重复任务放回实际运行链路中检查。验证时先选十条已经完成过的真实任务，记录旧 Prompt 的结果，再用同一批输入运行 Skill，比较字段完整性、异常处理和人工修改量。

测试时还要故意放入缺文件、空结果、格式变化和无权限数据。正常样本只能证明主路径能跑，异常样本才能看出边界是否写清。跨客户端兼容、版本管理和自动评测需要根据团队当前使用的版本单独确认，不能只凭一次成功调用下结论。

可以从最近重复三次以上的一项任务开始。把 Prompt 中的稳定规则、执行资源和验收条件分别标出，仍在变化的要求继续留在当前任务里。完成这一步后，Skill 才会成为团队能够维护的工作方法。

GitHub：https://github.com/zgiai/zgi

Gitee：https://gitee.com/zgiai/zgi