# 你的skill又不稳定又费Token？那你应该学一学如何工程化了（内附提示词）
**作者**: 金尘马
**日期**: 2026-06-02T15:39:36.000Z
**来源**: [https://x.com/jinchenma_ai/status/2061835131107860582](https://x.com/jinchenma_ai/status/2061835131107860582)
---
好多朋友创建完自己的 Skill 之后，会慢慢发现一个问题：同一个 Skill，这次跑得好好的，下次就乱了。让它处理一个简单任务，结果跑了半天，Token 烧了一堆，最后还报错了。你盯着终端里那一长串输出，根本不知道它在哪一步开始走偏的。
这不是你 Skill 写的不够完善。
大模型的工作方式本身就跟传统程序不一样。它不是按固定规则一步步执行，而是在概率里选一个它认为最可能的答案。同一个需求，它这次判断对了，下次可能判断偏。同一个功能，这次生成的代码能跑，下次就可能漏掉一个边界、写错一个参数、调用错一个工具。
大模型天然带着不确定性和幻觉，这是底层机制，不是它故意每次都不一样。
而且，随着你的 Skill 越复杂，里面需要大模型临场判断、临场生成代码、临场补全细节的地方就越多。每次都要它现场发挥，不确定性就会被反复放大。
这就是为什么要学会把 Skill 工程化。
这篇适合已经创建过 Skill，但希望能够让 Skill 更加稳定、更节省 Token 的人。
我会分享如果在 skill 的基础上做好工程化。
如果你还没建过 Skill，这篇可以先收藏，后面用得上。
# 01｜不稳定来源
一个简单 Skill 刚建好的时候，通常只做一件简单的事：读一段规则，按规则执行。这时候它还很稳定。因为你已经把能固定的都固定在规则里了。
但当你开始让它处理复杂任务，问题就来了。
同一个 Skill，第一次跑通了。第二次换个输入文件，参数或者格式变了，它就开始不知道调哪个。再让它批量跑，中间某一项的细节跟前面不一样，它就开始跳步、漏步、重复做。你看着 Token 消耗蹭蹭涨，最后输出的东西还对不上。
不稳的来源拆开看，其实就五类：
逻辑判断不稳。 大模型每次都在根据上下文（AI 每次处理任务时能看到的所有聊天记录和文件内容）推断下一步该干什么。任务越复杂，判断链越长，走偏的概率就越高。
代码生成不稳。 同一个功能每次临时生成一遍代码，变量名、依赖、异常处理、边界条件都可能变。更麻烦的是幻觉式调用：它可能会调用一个根本不存在的函数，或者编一个看起来很合理但实际不存在的参数。
细节补全不稳。 路径、参数、格式、工具名称、API 用法——只要这些没有明确沉淀下来，大模型就只能靠猜。有时候猜对了，有时候猜错一个字母，就会反复再猜。
流程执行不稳。 步骤没有固化成流程文件或 Skill 调度逻辑，任务一长就可能跳步、漏步、重复做。不是它不想按顺序来，而是上下文越长，它越容易在中间某一步「重新理解」自己该干什么。
上下文承载不稳。 上下文越长，干扰信息越多，大模型越容易抓错重点。前面说过的规则，后面可能就忘了。不是规则写得不好，而是它同时要记的东西太多了。
五类问题，根因都是同一件事：你把太多东西交给了大模型现场发挥。
提示词是在尽量引导它「这一次」少飘一点。工程化是尽量减少它「每一次」需要现场发挥的地方。
# 02｜什么是工程化
别被「工程化」这三个字唬住。它不是什么高级程序员的专属词。
放到 Agent 和 Skill 的使用场景里，工程化解决的其实是一个很朴素的问题：哪些事情可以继续让大模型判断，哪些事情不应该每次都让它现场发挥。
一句话讲就是：把不确定性交给大模型，把确定性沉淀到系统里。
大模型擅长理解、判断、拆解、改写、审查——这些需要弹性的东西，交给它没问题。但固定流程、固定代码、固定参数、固定输入输出、固定验收标准，这些东西不应该每次都让它重新猜一遍。
具体怎么做，可以拆成四步：
1. 先把任务跑通一遍，确认这件事真的能做。
2. 把任务拆成固定步骤，写清楚每一步的输入、输出和成功标准。
3. 把能用代码稳定完成的部分沉淀成脚本，别每次让 Agent 临时生成。
4. 最后让 Skill 只负责调度：读规则、调用脚本、检查结果、遇到问题再修。
工程化不是让 AI 变聪明。它是让 AI 不用每次重新想一遍已经想清楚的事。
# 03｜一个学员的视频字幕案例
前面讲的四步工程化，听起来可能还是有点抽象。拿一个真实的案例来讲，就容易看清楚了。
有一个学员，想做一个视频处理的 Skill。
她的需求很明确：丢进去一批英文视频，最后自动产出一批带中英双语字幕的视频。
这件事如果直接丢给 Agent 说「帮我做一个视频字幕 Skill」，它会怎么做？它会开始从头判断：视频怎么处理、字幕怎么提取、翻译怎么做、怎么回写。每一步都要现场想、现场写代码、现场调。跑通一次也许能行，换个视频大概率要重来。
工程化的思路完全不一样。不是一上来就问「这个 Skill 怎么写」，而是先问「这个任务反复跑的时候，循环是什么」。
拆开看，这个任务的循环其实很清晰：
输入英文视频 → 转写成英文字幕 → 英文纠错 → 翻译成中文 → 字幕回写视频 → 输出带双语字幕的视频。
循环确定以后，再看循环里的每一步：哪些适合让大模型判断，哪些应该沉淀成脚本。
# 04｜四步工程化
把循环拆成四步来看，每一步的处理方式其实不一样。
视频转字幕。 这一步适合用脚本固定下来，直接调用转写工具或者本地能力。不需要大模型做任何判断，输入视频文件，输出字幕文件，纯执行。
英文纠错。 这一步需要理解语义，确实需要大模型。但不需要主 Agent 亲自做。最合适的做法是写一个脚本，调用外部大模型 API——比如 DeepSeek——把字幕文本发过去，拿到纠错结果再传回来。主 Agent 只负责把脚本调起来、检查结果。
英文翻译中文。 同理。翻译是典型的文本加工任务，交给外部模型更合适。脚本充当「传话筒」：把英文发给 DeepSeek，拿回中文，继续往下走。
字幕回写视频。 这一步又回到纯执行。字幕渲染逻辑用脚本固定下来，输入视频和中英文字幕，输出最终视频。不需要大模型参与。
中间两步用外部大模型，有三个很实际的理由：
第一，把主 Agent 的流程和具体文本处理动作分开。Codex 或 Claude Code 负责看流程、调脚本、检查结果，不要让它一边背着完整上下文，一边在主会话里纠错和翻译。纠错和翻译这种长文本加工任务，会直接把主 Agent 的上下文拖垮。
第二，省 Token，省成本。英文纠错和翻译不一定非要用最贵的主力模型。DeepSeek 这类按 API 调用的便宜模型已经足够胜任。代码只是传话筒，不消耗主 Agent 的 Token。
第三，排错更容易。主 Agent 只需要检查脚本有没有调用成功、输出有没有生成。如果翻译质量不对，就去改翻译脚本的提示词，或者换一个外部模型。不会把整个主流程搅乱。
# 05｜具体怎么工程化
前面把循环和四步的处理方式讲清楚了。先跑通单个视频。不要一上来就想着批量处理 20 个。单点跑通是为了验证流程、脚本、输入输出都没问题。一个视频跑通了，剩下的只是循环。
然后把四步分别固化成脚本：转写脚本、英文纠错脚本、中文翻译脚本、字幕回写脚本。每个脚本的输入和输出要写清楚：
- 转写脚本：输入视频文件 → 输出英文字幕文件。
- 纠错脚本：输入英文字幕 → 调用 DeepSeek API 纠错 → 输出纠错后的英文字幕。
- 翻译脚本：输入纠错后的英文字幕 → 调用 DeepSeek API 翻译 → 输出中文字幕。
- 回写脚本：输入视频 + 中英文字幕 → 输出带双语字幕的最终视频。
纠错和翻译脚本里调用外部大模型 API，主 Agent 不亲自纠错、不亲自翻译，只负责把脚本调起来。
最后再写 Skill，让 Skill 按顺序调用这四个脚本，每一步检查有没有产出结果。如果某一步挂了，Skill 要能告诉你挂在哪一步、哪个脚本、哪个输入或哪个外部模型调用上，而不是把整套流程重跑一遍。
这里有一个成本账值得算：Codex、Claude Code 这种主 Agent 是用来调度和修流程的，不是用来跑所有文本加工的。纠错和翻译这种大量消耗文本的任务，交给外部便宜模型更划算。
# 06｜判断标准
不是每个 Skill 都需要工程化。如果它做的事情很简单，规则固定，每次输入输出也稳定，那提示词就够用了。
该不该工程化，核心不是问「这件事要不要做成 Skill」，而是问：这个 Skill 里有没有太多本该固定下来的东西，还在让大模型每次现场发挥。
四个问题可以快速判断：
有没有固定流程？ 如果每次都是同一套步骤，只是输入不同，就适合工程化。
有没有固定代码？ 如果每次都让 Agent 临时写同一类脚本——视频处理、文件批量操作、API 调用——就适合工程化。
有没有固定输入输出？ 如果每一步的产物能清楚接到下一步，就适合工程化。
有没有明确分工？ 如果有些步骤适合脚本做，有些步骤适合外部模型做，主 Agent 只负责调度，就适合工程化。
要不要做成 Skill，看的是这件事会不会反复做。要不要工程化，看的是这个 Skill 里面有没有太多不该交给大模型现场发挥的部分。
# 07｜可直接复制的提示词
下面这套提示词可以直接丢给 Codex 或 Claude Code，让它帮你把现有的 Skill 工程化。
```
请你帮我把这个 skill 工程化。原则是：能用代码固定下来的，就生成脚本；不能用代码固定的，再写进 skill 的规则和调度逻辑里。不要只给方案，要尽量落到可执行文件和可测试流程。
要求：
1. 先列出这个任务的完整循环。
2. 把循环拆成固定步骤。
3. 标出每一步的输入和输出。
4. 判断每一步能不能用代码脚本化。
5. 能脚本化的步骤，直接生成或更新对应脚本，并写清楚脚本名称、脚本职责、输入输出和运行方式。
6. 不能脚本化的步骤，写进 skill 的规则、判断标准或调度逻辑里。
7. 生成或更新 skill 文件，让它按固定顺序调用脚本、读取规则、检查结果。
8. 先用一个最小样例跑通流程，不要一上来批量处理。
9. 如果某一步失败，说明失败在哪个脚本、哪个输入或哪个外部模型调用上，不要重写整套流程。
输出请分成三部分：
- 任务循环
- 已生成/建议生成的脚本
- skill 规则、调度逻辑和测试方式
```
# 写在最后
下次你的 Skill 开始不稳、费 Token、排错困难的时候，不要只想着继续补提示词。
真正要问的是：这个 Skill 里哪些东西不该再让大模型每次现场发挥。
能写成脚本的，就让 AI 帮你写成脚本。能调用外部便宜模型的，就从主 Agent 里拆出去。能固定输入输出的，就把格式和路径写清楚。最后让 Skill 负责调度、检查和修复。
你会慢慢感觉到，每次跑 Skill 不再是赌运气。
你知道哪一步是脚本在跑、哪一步是模型在判断、出了问题该改哪一块。这种感觉会溢出到其他工作中，凡是有固定流程的事，你都会下意识想：这件事能不能也工程化掉？
金尘马｜大厂程序员｜30天X破万粉变现过万｜持续分享 AI 搞钱、程序员转型、OPC 心得｜联系方式见主页介绍：https://x.com/jinchenma_ai
## 相关链接
- [金尘马](https://x.com/jinchenma_ai)
- [@jinchenma_ai](https://x.com/jinchenma_ai)
- [4.6K](https://x.com/jinchenma_ai/status/2061835131107860582/analytics)
- [https://x.com/jinchenma_ai](https://x.com/jinchenma_ai)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:39 PM · Jun 2, 2026](https://x.com/jinchenma_ai/status/2061835131107860582)
- [4,646 Views](https://x.com/jinchenma_ai/status/2061835131107860582/analytics)
---
*导出时间: 2026/6/3 09:26:13*