最近用 ChatGPT、Codex 做真实开发时我遇到一个越来越明显的问题有些Prompt我已经不是在“写”而是在“复制”。比如每次准备合并一个稍大的PR我都会告诉Codex先看任务目标。再看改动文件。检查有没有越界修改。重点看API、数据库、事务和兼容性。然后跑测试。失败以后先定位原因不要为了让测试变绿直接改测试。最后再总结风险点。第一次这样写很正常。第二次也没什么。但如果一周里已经重复输入五六次而且每次只替换仓库。分支。模块。任务名称。这时候真正值得问的已经不是这次Prompt还能不能再优化一点而是这套工作方式是不是已经应该从Prompt升级成Skill但这里也有一个很容易踩的坑。重复出现的Prompt不一定都值得做成Skill。有些任务虽然每次说的话差不多但真正的执行过程并不稳定。如果过早Skill化最后很可能只是把一个灵活Prompt封装成一个更难修改的固定流程。所以真正的判断标准不是这段Prompt我复制了几次而是这项任务背后的Workflow是否已经稳定到值得复用一、先区分你重复的是“文字”还是“工作流”这是判断要不要做Skill最重要的一步。比如你每次都输入帮我分析这个线上Bug找到根因并给修复方案。这句话可能已经复制了很多次。但每次Bug都完全不同一次是MySQL锁。一次是Redis。一次是Kubernetes。一次是线程池。虽然Prompt长得很像但实际执行路径并不一样。这种只是Prompt Pattern重复。不代表Workflow稳定。反过来有些任务即使Prompt并不完全相同背后的步骤却高度一致。比如每次发布前都要读取变更。分类风险。确认Migration。检查配置。运行测试。生成发布Checklist。这时候真正重复的是Execution Pattern。这类任务才开始具备Skill化价值。所以判断Skill的第一条不是Prompt重复率。而是执行步骤重复率。二、一次性Prompt最适合解决什么问题Prompt最大的优势其实就是灵活。一个今天才出现的问题。一个临时分析。一个探索性任务。需求还没想清楚。执行过程中可能不断换方向。这类事情本来就应该继续用Prompt。例如帮我判断这次重构到底应该拆成几个PR。你可能聊到一半发现真正的问题不是PR拆分而是数据库兼容。方向会变。如果这时候强行套固定Skill反而限制了Agent。所以只出现一两次的任务我通常不会急着沉淀。先让ChatGPT、Codex自由完成。先看它真正需要哪些步骤。哪些步骤每次都存在。哪些只是这一次的特殊情况。也就是说Prompt适合探索。Skill适合复用已经验证过的流程。三、什么时候开始出现Skill化信号我更关注四个信号。第一同类任务开始反复出现例如每周都要做PR风险检查。发布前检查。日志归因。测试失败分类。依赖升级验证。这说明它已经不是偶发任务。第二执行步骤开始固定每次基本都是输入材料。分析。执行几步固定检查。跑验证。生成结果。换项目以后步骤仍然变化不大。第三你开始反复纠正Agent同样的问题例如每次都要提醒不要直接改generated code。先分析失败原因。必须跑指定测试。失败不要直接跳过。这意味着一些稳定规则已经值得从临时对话里拿出来。第四结果格式也开始稳定每次最后都希望得到问题。Evidence。风险等级。建议动作。验证结果。下一步。当输入、流程和输出都逐渐稳定以后Skill化价值就会明显提高。四、不要从“Prompt”直接跳到“Skill”我更推荐一个中间阶段Prompt → Checklist → Skill第一次做任务直接Prompt。第二三次发现步骤开始重复。先整理成Checklist。例如PR Review确认任务目标建立Change Surface找高风险修改检查Contract看测试输出风险总结。接下来继续用几次。如果你发现这6步大部分情况下都成立顺序也稳定失败处理也比较固定这时再考虑做成Skill。为什么要多一个Checklist阶段因为Checklist很便宜。写错了随时改。而且它可以帮助你验证你以为稳定的Workflow到底是不是真的稳定。很多流程第一次看起来很完整。真正跑五次以后才发现第三步根本不总是需要。第五步应该提前。有一种异常场景还缺处理。这些都应该在Skill化之前暴露。五、Skill里应该沉淀“步骤”而不是沉淀“答案”这是我认为最容易做错的一点。比如做一个“Java线上故障排查Skill”。如果里面直接写死CPU高先查GC。接口慢优先查数据库。502优先查Nginx。这种Skill很快就会变得僵硬。因为真实故障根因变化太大。更合理的是沉淀怎么获取Evidence。怎么缩小范围。什么条件下进入下一步。也就是把“结论”换成“决策过程”。例如先收集时间点。确认错误范围。检查应用与基础设施事件。根据Evidence决定进入数据库、网络还是JVM分支。这类流程即使问题变化也还能复用。所以一个好的Skill更像可重复执行的方法。而不是预先写好的标准答案。六、输入变化太大时不要太早Skill化例如你经常让Codex帮我分析一个新项目架构。看起来也是重复任务。但一次可能是Java单体。下一次是Go微服务。再下一次是Python数据平台。输入结构完全不同。目标也不同。这时候如果做一个巨大Skill里面需要同时覆盖十几种项目。几十种判断。最终很容易变成一个比Prompt还复杂的大说明书。所以我会看一个很实际的问题每次任务变化的是“参数”还是“方法”如果变化主要是仓库名。模块名。分支。时间范围。目标文件。这些更像参数变化。适合Skill。如果每次连分析方法。判断顺序。验证方式。输出目标都不一样那就继续保持Prompt。七、Skill不要做得太大刚开始做Skill时很容易产生一种冲动既然要复用那就一次把所有东西都塞进去。比如做一个“完整开发Skill”。里面包含需求分析。写代码。测试。Review。重构。提交。发布。异常处理。结果就是任何一个小任务都要启动一大套流程。这和把所有工程规则都塞进一份巨型AGENTS.md本质上很像。更好的方式是一个Skill只解决一个稳定Workflow。例如PR Risk Review。Release Readiness Check。Test Failure Triage。Dependency Upgrade Check。Migration Safety Review。边界越清楚复用反而越稳定。八、为什么Agent时代特别需要把重复Workflow沉淀下来以前一个人重复做同一套工作最大的成本是时间。现在ChatGPT、Codex能够快速执行以后新的问题变成同一任务每次执行方式不一样。今天你Prompt写得详细。明天少写两句。后天换一个人操作。结果同一种任务的执行标准开始漂移。所以Skill真正有价值的地方不只是少打几段字。而是把“个人临时习惯”变成“可复用执行方式”。也就是说Prompt解决的是这一次怎么做。Skill解决的是以后这类任务默认怎么做。九、失败分支决定一个Skill是不是成熟很多流程正常路径都很好写。例如读取代码。执行测试。生成报告。真正决定Skill能不能长期使用的往往是失败以后怎么办。比如测试失败是直接修先判断是不是原有失败环境无法启动继续分析静态代码还是停止缺少必要文件自己猜还是要求补充发现任务需要扩大范围继续改还是Escalate如果这些没有定义Skill执行到异常情况以后仍然会开始自由发挥。所以我会特别检查一个Skill有没有至少处理Missing InputValidation FailedScope ExpandedRule ConflictCannot Verify这些分支。十、什么时候应该继续用Prompt不要做Skill有几类任务我会明确继续用Prompt。第一类第一次出现的问题。因为还不知道正确流程是什么。第二类探索型任务。比如架构方案比较、产品方向判断。过程本身就需要发散。第三类输入和目标高度变化的任务。每次几乎都是新的问题。第四类低频任务。半年才做一次即使能Skill化维护成本也可能比收益更高。Skill不是越多越好。如果一个Skill一年用两次很可能下次使用时里面的流程自己都已经过时了。十一、什么时候我会明确建议做成Skill如果一个任务满足下面这种特征我会非常倾向Skill化每周重复。步骤基本固定。输入格式相似。有固定工具调用。有明确验证方法。有明确失败处理。结果结构也基本相同。例如每次CI失败以后都需要读取失败Job。定位第一个真实错误。排除后续连锁错误。找到相关修改。给出最小修复。重新运行验证。这已经不是“问AI一个问题”。而是一套相当稳定的Debug Workflow。这种工作就很适合沉淀。十二、一个简单指标Workflow Reuse Rate如果这篇只看一个指标我建议用Workflow Reuse Rate——工作流复用率可以简单理解成同类任务中真正复用了同一套核心步骤的次数 ÷ 这类任务总次数。比如一周做了5次PR Review。其中4次都使用Intent → Change Surface → Risk → Contract → Validation只有一次因为特殊情况完全不同。那么Workflow Reuse Rate 80%。当一个流程长期达到70%80%以上都能复用Skill化通常就开始有明显价值。如果只有30%任务能套进去那说明Workflow还没有真正稳定。这时继续Prompt反而更轻。十三、还有一个容易被忽略的问题维护成本Skill一旦建立就不能假设它永远正确。项目会变化。测试命令会变化。目录会变化。工具会变化。团队规则会变化。所以真正的问题不是能不能做成Skill还要问这个Skill以后谁维护如果一个流程变化非常快每周都要改那它可能还没有进入适合固化的阶段。好的Skill通常来自已经稳定一段时间的Workflow。而不是刚出现的新习惯。十四、Skill、AGENTS.md和Prompt应该怎么分工这三个东西很容易混在一起。我更倾向于这样理解AGENTS.md负责仓库长期规则。什么不能动。Source of Truth在哪里。必须遵守哪些工程约束。Skill负责某一种任务应该按照什么流程执行。例如PR Review、发布检查、测试失败分析。Prompt负责这一次具体要完成什么。例如检查payment-service这次PR重点确认退款逻辑和数据库兼容。这样就形成了三层Repository RulesReusable WorkflowCurrent Task如果什么都写进Prompt每次都要重复。如果什么都写进AGENTS.md又会越来越臃肿。Skill正好负责中间那层可复用任务流程。十五、Plus和Pro怎么判断如果你主要用ChatGPT、Codex做偶尔的代码修改。临时分析。少量重复任务。同一种Workflow一周可能只跑一两次那没必要为了“工程化”强行把所有Prompt都做成Skill。Plus通常已经足够。先把真正反复出现的任务整理成Checklist比一次建立大量Skill更有价值。如果你的工作已经变成每天大量使用Codex。同一类开发、Review、测试、排障流程不断重复。一个Skill需要连续读取仓库、执行工具、运行验证、处理失败分支再进入下一阶段而且这种长任务已经成为常态这时Pro会更适合。判断重点仍然不是“有没有Skill”。而是可复用Agent Workflow是不是已经成为你的日常生产方式。最后同一套任务每次都要重新写Prompt什么时候应该做成Skill不是Prompt复制了三次以后。也不是觉得Skill比较高级以后。真正值得Skill化的信号是任务开始重复执行流程开始稳定。最简单的演化路径其实是Prompt → Checklist → SkillPrompt负责探索。Checklist负责验证流程。Skill负责复用已经稳定的方法。而且Skill真正应该沉淀的也不是一个固定答案。而是一套可以重复执行、能够验证、遇到异常知道怎么处理的Workflow。如果每次变化的只是任务参数而核心方法已经基本不变那么继续复制Prompt的价值就越来越低。这时候把它沉淀下来真正节省的也不只是几分钟输入时间。更重要的是让ChatGPT、Codex每一次执行同类任务时都从一套更稳定的工程起点开始。持续分享 Codex、大模型开发与 AI 编程实战内容也整理了稳定的 Plus/Pro 订阅渠道有需要下方可自取。