1. 为什么你的 ChatGPT 提示词总是“这次行下次崩”很多人第一次用 ChatGPT 处理重复任务时都会经历一个相似的循环第一次精心写了一段提示词输出格式完美心里想着“以后就这么干”结果第二次做同类任务把提示词复制过去出来的东西却少了风险提示、语气也变了甚至把该分三段的内容揉成了一大段。于是你不得不重新解释一遍“要分几个部分”“每部分写什么”“最后加不加风险提示”说完之后发现这次又和上次不一样。这个问题的根源不在于模型变笨了而在于提示词是“一次性”的而重复任务需要的是“可复用的流程”。提示词像是一张便签写的是“帮我做一份周报”而 Skills 更像是一张标准作业卡写的是“周报必须包含本周完成、下周计划、风险与依赖三部分每部分不超过五条风险项必须标注负责人”。前者靠模型临场发挥后者靠流程约束输出。我试过把同一段提示词连续跑十次输出结构的一致率大概只有六成左右而把同样的要求写成 SKILL.md 之后连续跑二十次结构完整率基本稳定在九成以上。差别就在于提示词是“请求”Skill 是“规程”。这篇文章要解决的就是怎么把你在 ChatGPT 里那些高频、重复、有固定格式要求的任务从“每次重新说一遍”改造成“一次写好、随时调用”的 Skill。你会看到 SKILL.md 的完整模板、目录结构怎么组织、触发示例怎么写以及一次从提示词到技能化的完整改造与验证过程。适合所有已经在用 ChatGPT 处理周报、会议纪要、客户邮件、数据复盘这类重复工作但每次都要重新解释一遍的人。2. Skills、SKILL.md 与 GPTs/Projects 到底怎么分工在动手写第一个 Skill 之前先把三个概念的分工理清楚否则很容易把 Skill 写成另一个“长提示词”用起来还是不稳定。Skills 管的是“流程一致”。它回答的是“这类任务应该按什么步骤做、输出长什么样、交付前检查什么”。一个 Skill 的核心是一份 SKILL.md 文件里面用 Markdown 写清楚用途、输入、步骤、输出格式和自查清单。它不绑定具体话题只要任务类型匹配随时可以调用。GPTs 管的是“上下文一致”。它回答的是“这个助手是谁、知道什么、能用什么工具”。一个定制 GPT 可以预设知识库、启用联网或数据分析、配置自定义操作。GPT 更像一个领域专家而 Skill 是这个专家手里的一张操作卡。一个 GPT 内部可以挂多个 Skill分别处理该领域里不同类型的子任务。Projects 管的是“协作一致”。它把相关的对话、文件和成员收在一个空间里围绕一个共同目标推进。在 Project 里可以调用特定的 GPT也可以使用预置的 Skill 来处理项目中的重复任务。打个比方GPT 是“品牌内容专家”Projects 是“夏季推广项目组”而 Skills 是专家手里的“博客初稿生成流程”“社媒文案改写流程”“数据图表解读流程”。三者不是替代关系而是各管一段——Skill 管步骤GPT 管知识Project 管协作。那 SKILL.md 为什么用 Markdown因为它足够简单不需要学编程就能改同时它结构清晰标题、列表、粗体这些标记既方便人读也方便系统解析。一份典型的 SKILL.md 通常包含五块内容用途说明一两句话、所需输入用户要提供什么、分步操作指引按顺序列动作、输出格式要求最终产出结构、交付前自查清单结束前检查什么。这里要特别提醒一点Skill 不是“更长的提示词”。提示词可以模糊比如“整理得有条理一些”但 Skill 必须具体比如“按时间顺序列出讨论要点每点后面跟一个负责人姓名”。越具体执行越稳。如果你在团队里用Skill 还有一个隐性价值它把老员工脑子里的“不成文规矩”变成了明文指令。比如“写报告先列数据再给结论”“写邮件开头先感谢再提正事”这些以前靠问、靠猜的东西现在写进 SKILL.md新成员直接调用就行。3. 可复制配置SKILL.md 模板与目录结构这一节给你可以直接抄的配置。先看目录结构再看 SKILL.md 模板最后看一个真实改造案例。3.1 目录结构怎么组织一个 Skill 在本地或工作空间里建议按下面的结构放skills/ └── weekly-report/ ├── SKILL.md # 核心流程文件必须 ├── templates/ │ └── report.md # 输出模板可选 ├── examples/ │ └── sample.md # 范例输出可选 └── assets/ └── brand.md # 品牌规范/术语表可选SKILL.md 是入口templates 放格式模板examples 放一两个“好输出”的样例assets 放品牌语气、术语对照这类辅助材料。刚开始只写 SKILL.md 也能跑后面再逐步补。3.2 SKILL.md 完整模板下面这份模板可以直接复制把方括号里的内容换成你的任务# Skill 名称周报生成 ## 用途 把零散的工作记录整理成结构固定的周报供团队同步使用。 ## 输入 - 本周完成事项列表或流水账均可 - 下周计划事项 - 当前风险或阻塞项没有则写“无” ## 步骤 1. 读取输入按“完成 / 计划 / 风险”三类归并。 2. 每类内部按重要性排序最多保留 5 条。 3. 每条用“动词 对象 结果”的句式改写不超过 30 字。 4. 风险项必须标注负责人和期望解决时间。 5. 按下方输出格式组装不添加额外寒暄。 ## 输出格式 ### 本周完成 - [条目] ### 下周计划 - [条目] ### 风险与依赖 - [条目]负责人X期望解决X月X日 ## 交付前自查 - [ ] 三类是否齐全没有的写“无” - [ ] 每类是否不超过 5 条 - [ ] 风险项是否都有负责人和时间 - [ ] 是否没有多余开场白和总结这份模板的关键在于步骤用数字编号输出格式用固定标题自查清单用可勾选项。这三样齐了模型执行时的“自由度”就被压到最低稳定性自然上来。3.3 触发示例怎么写Skill 装好之后有两种调用方式。一种是自动触发你直接说“帮我整理这周的周报”系统判断匹配就启用。另一种是手动指定在对话里 这个 Skill 的名称明确调用。为了让自动触发更准可以在 SKILL.md 的“用途”里写清楚适用场景比如“当用户提供工作流水账并要求生成周报时使用”。触发示例可以这样写周报生成 本周完成了 A 项目接口联调、B 需求评审、C 线上问题修复 下周计划做 D 模块开发、E 文档补全 风险F 依赖第三方接口可能延期。3.4 从提示词到 Skill 的改造对照假设你原来每次都说这段提示词帮我把下面的工作记录整理成周报分本周完成、下周计划、风险三部分 每部分不超过五条风险要写负责人不要加开场白。把它改造成 Skill就是把这段话拆进 SKILL.md 的对应区块用途写“整理周报”输入写“工作记录”步骤写“归并三类、排序、限五条、风险标负责人”输出格式写三个固定标题自查清单写四条检查项。改造完之后你只需要贴工作记录不用再重复那段话。如果你在团队里用 GPTs 承载这个 Skill可以在 GPT 的指令里写“处理周报时优先调用周报生成 Skill”这样成员在 Project 里直接贴记录就能出结果。需要管理多个 Skill 和 API Key 时可以在控制台里统一配置地址是 https://taotoken.net/api-keys 接入文档在 https://taotoken.net/doc 。4. 验证请求跑一遍看输出稳不稳配置写完不算完得跑验证。验证的目标不是“能不能出结果”而是“连续多次出结果是否结构一致”。4.1 准备三组测试输入选三组差异较大的输入一组条目多、一组条目少、一组带风险项。比如输入A条目多 完成接口联调、需求评审、线上修复、文档更新、代码review、周会 计划模块开发、文档补全、测试用例 风险第三方接口可能延期 输入B条目少 完成写了一份方案 计划等反馈 风险无 输入C带风险 完成数据迁移 计划灰度发布 风险迁移脚本在高峰期可能超时需要DBA支持4.2 连续跑并对照自查清单把三组输入分别跑两到三次每次输出都对照 SKILL.md 里的自查清单检查三类是否齐全、每类是否不超过五条、风险项是否都有负责人和时间、有没有多余开场白。如果输入B里“风险无”输出里风险部分应该写“无”而不是省略整个标题。如果输入C的风险项没写负责人说明步骤里的“风险项必须标注负责人”没被严格执行需要回到 SKILL.md 把这条写得更硬比如改成“风险项格式固定为‘[描述]负责人X期望解决X月X日’缺一不可”。4.3 用模型对话快速对比如果你想快速对比“提示词版”和“Skill版”的差异可以在模型对话里分别跑同一组输入观察结构完整率。地址是 https://taotoken.net/models 把两版输出并排看差异一目了然。4.4 验证通过的判断标准我的判断标准是连续跑五次结构完整率不低于九成风险项负责人和时间字段不缺失没有多余寒暄。达到这个标准这个 Skill 就可以投入日常使用了。达不到就回到 SKILL.md 改步骤或自查清单改完再跑。这里有个经验验证时不要只测“正常输入”一定要测“边界输入”。比如空输入、只有一条的输入、风险项缺失负责人的输入。边界输入最能暴露 SKILL.md 里没写死的地方。5. 常见报错与排查401、local proxy failed、reading choices、OAuthSkill 本身是流程文件但一旦涉及调用 API 或在工具里接入就会碰到一些典型报错。下面按真实报错逐条排查。5.1 401 Unauthorized这是最常见的接入报错意思是 Key 没被认出来。排查顺序先确认 Key 有没有复制完整前后有没有多空格再确认 Key 有没有过期或被禁用最后确认请求头里的字段名对不对通常是Authorization: Bearer 你的Key。如果是在 Cline、CC Switch 这类工具里配置检查 Base URL 和 Key 是不是填在了对应的输入框里别把 Key 填到 URL 栏。5.2 local proxy failed这个报错通常出现在本地工具通过代理转发请求时。意思是本地转发层没起来或端口不通。排查确认本地服务是否在运行、端口是否被占用、工具里配置的本地地址和实际监听地址是否一致。如果是 CC Switch 这类切换工具检查当前选中的配置项是不是指向了正确的 Base URL。5.3 reading choices 相关报错这类报错一般出现在解析模型返回结构时意思是返回体里没有预期的choices字段。常见原因是请求发出去但返回的是错误信息比如 401 或 404被当成正常响应去解析了。排查先把原始返回打印出来看确认是不是错误码再检查请求的模型 ID 是否写对模型 ID 写错时也可能返回非预期结构。5.4 OAuth 相关报错在 Claude Code、Codex 这类工具里接入时可能碰到 OAuth 流程报错。排查确认回调地址是否和配置一致、本地端口是否被占用、浏览器是否拦截了跳转。如果是 Codex 的auth.json检查里面的字段是否完整Base URL、Key、Model ID 三件套是否都填了。5.5 三件套检查清单只要涉及工具接入就检查这三样配置项说明常见错误Base URL接口地址多写或少写路径、带了多余斜杠Key访问密钥复制不完整、前后有空格Model ID模型标识拼写错误、用了不存在的模型名这三样任何一样不对都会表现为各种看似不相关的报错。排查时先核对三件套能省很多时间。需要新建或查看 Key 时去 https://taotoken.net/api-keys 接入细节看 https://taotoken.net/doc 。6. 把 Skill 用起来从单个任务到团队复用写到这里你已经有了 SKILL.md 模板、目录结构、触发示例和验证方法。接下来最关键的一步是真正把它用起来。我的建议是从最小的任务开始。不要一上来就写一个“处理所有市场文案”的大 Skill而是先挑一个你每周都要做、格式固定、步骤不超过五步的小任务。比如“把零散笔记转成三段式会议纪要”或者“把客户通话记录转成商机评估”。用模板写一份 SKILL.md跑三组输入验证稳定之后再用到日常里。当你发现某个 Skill 已经连续用了十次、每次结果都稳定可靠时那种“不用再操心琐事”的轻松感就是这件事最实在的回馈。之后再逐步扩展把多个 Skill 组合进一个 GPT在 Project 里让团队共用甚至把 Skill 分享给同事让输出的质量站在同一条基准线上。如果你需要长期跑编码或 Agent 类任务可以考虑 Coding Plan地址是 https://taotoken.net/coding-plan 。需要管理多个 Skill 和 Key 时控制台在 https://taotoken.net/console 。把这些基础配置理顺之后Skill 的复用价值会进一步放大。最后留一个实用技巧给每个 Skill 在 SKILL.md 顶部加一行版本号和更新日期比如 版本v1.2 | 更新2025-06。改过几次之后你会感谢这行字因为它能帮你快速判断某个输出是用哪版流程跑出来的。 不止是提示词：用 Skills 与 SKILL.md 让 ChatGPT 重复任务可靠又省力
1. 为什么你的 ChatGPT 提示词总是“这次行下次崩”很多人第一次用 ChatGPT 处理重复任务时都会经历一个相似的循环第一次精心写了一段提示词输出格式完美心里想着“以后就这么干”结果第二次做同类任务把提示词复制过去出来的东西却少了风险提示、语气也变了甚至把该分三段的内容揉成了一大段。于是你不得不重新解释一遍“要分几个部分”“每部分写什么”“最后加不加风险提示”说完之后发现这次又和上次不一样。这个问题的根源不在于模型变笨了而在于提示词是“一次性”的而重复任务需要的是“可复用的流程”。提示词像是一张便签写的是“帮我做一份周报”而 Skills 更像是一张标准作业卡写的是“周报必须包含本周完成、下周计划、风险与依赖三部分每部分不超过五条风险项必须标注负责人”。前者靠模型临场发挥后者靠流程约束输出。我试过把同一段提示词连续跑十次输出结构的一致率大概只有六成左右而把同样的要求写成 SKILL.md 之后连续跑二十次结构完整率基本稳定在九成以上。差别就在于提示词是“请求”Skill 是“规程”。这篇文章要解决的就是怎么把你在 ChatGPT 里那些高频、重复、有固定格式要求的任务从“每次重新说一遍”改造成“一次写好、随时调用”的 Skill。你会看到 SKILL.md 的完整模板、目录结构怎么组织、触发示例怎么写以及一次从提示词到技能化的完整改造与验证过程。适合所有已经在用 ChatGPT 处理周报、会议纪要、客户邮件、数据复盘这类重复工作但每次都要重新解释一遍的人。2. Skills、SKILL.md 与 GPTs/Projects 到底怎么分工在动手写第一个 Skill 之前先把三个概念的分工理清楚否则很容易把 Skill 写成另一个“长提示词”用起来还是不稳定。Skills 管的是“流程一致”。它回答的是“这类任务应该按什么步骤做、输出长什么样、交付前检查什么”。一个 Skill 的核心是一份 SKILL.md 文件里面用 Markdown 写清楚用途、输入、步骤、输出格式和自查清单。它不绑定具体话题只要任务类型匹配随时可以调用。GPTs 管的是“上下文一致”。它回答的是“这个助手是谁、知道什么、能用什么工具”。一个定制 GPT 可以预设知识库、启用联网或数据分析、配置自定义操作。GPT 更像一个领域专家而 Skill 是这个专家手里的一张操作卡。一个 GPT 内部可以挂多个 Skill分别处理该领域里不同类型的子任务。Projects 管的是“协作一致”。它把相关的对话、文件和成员收在一个空间里围绕一个共同目标推进。在 Project 里可以调用特定的 GPT也可以使用预置的 Skill 来处理项目中的重复任务。打个比方GPT 是“品牌内容专家”Projects 是“夏季推广项目组”而 Skills 是专家手里的“博客初稿生成流程”“社媒文案改写流程”“数据图表解读流程”。三者不是替代关系而是各管一段——Skill 管步骤GPT 管知识Project 管协作。那 SKILL.md 为什么用 Markdown因为它足够简单不需要学编程就能改同时它结构清晰标题、列表、粗体这些标记既方便人读也方便系统解析。一份典型的 SKILL.md 通常包含五块内容用途说明一两句话、所需输入用户要提供什么、分步操作指引按顺序列动作、输出格式要求最终产出结构、交付前自查清单结束前检查什么。这里要特别提醒一点Skill 不是“更长的提示词”。提示词可以模糊比如“整理得有条理一些”但 Skill 必须具体比如“按时间顺序列出讨论要点每点后面跟一个负责人姓名”。越具体执行越稳。如果你在团队里用Skill 还有一个隐性价值它把老员工脑子里的“不成文规矩”变成了明文指令。比如“写报告先列数据再给结论”“写邮件开头先感谢再提正事”这些以前靠问、靠猜的东西现在写进 SKILL.md新成员直接调用就行。3. 可复制配置SKILL.md 模板与目录结构这一节给你可以直接抄的配置。先看目录结构再看 SKILL.md 模板最后看一个真实改造案例。3.1 目录结构怎么组织一个 Skill 在本地或工作空间里建议按下面的结构放skills/ └── weekly-report/ ├── SKILL.md # 核心流程文件必须 ├── templates/ │ └── report.md # 输出模板可选 ├── examples/ │ └── sample.md # 范例输出可选 └── assets/ └── brand.md # 品牌规范/术语表可选SKILL.md 是入口templates 放格式模板examples 放一两个“好输出”的样例assets 放品牌语气、术语对照这类辅助材料。刚开始只写 SKILL.md 也能跑后面再逐步补。3.2 SKILL.md 完整模板下面这份模板可以直接复制把方括号里的内容换成你的任务# Skill 名称周报生成 ## 用途 把零散的工作记录整理成结构固定的周报供团队同步使用。 ## 输入 - 本周完成事项列表或流水账均可 - 下周计划事项 - 当前风险或阻塞项没有则写“无” ## 步骤 1. 读取输入按“完成 / 计划 / 风险”三类归并。 2. 每类内部按重要性排序最多保留 5 条。 3. 每条用“动词 对象 结果”的句式改写不超过 30 字。 4. 风险项必须标注负责人和期望解决时间。 5. 按下方输出格式组装不添加额外寒暄。 ## 输出格式 ### 本周完成 - [条目] ### 下周计划 - [条目] ### 风险与依赖 - [条目]负责人X期望解决X月X日 ## 交付前自查 - [ ] 三类是否齐全没有的写“无” - [ ] 每类是否不超过 5 条 - [ ] 风险项是否都有负责人和时间 - [ ] 是否没有多余开场白和总结这份模板的关键在于步骤用数字编号输出格式用固定标题自查清单用可勾选项。这三样齐了模型执行时的“自由度”就被压到最低稳定性自然上来。3.3 触发示例怎么写Skill 装好之后有两种调用方式。一种是自动触发你直接说“帮我整理这周的周报”系统判断匹配就启用。另一种是手动指定在对话里 这个 Skill 的名称明确调用。为了让自动触发更准可以在 SKILL.md 的“用途”里写清楚适用场景比如“当用户提供工作流水账并要求生成周报时使用”。触发示例可以这样写周报生成 本周完成了 A 项目接口联调、B 需求评审、C 线上问题修复 下周计划做 D 模块开发、E 文档补全 风险F 依赖第三方接口可能延期。3.4 从提示词到 Skill 的改造对照假设你原来每次都说这段提示词帮我把下面的工作记录整理成周报分本周完成、下周计划、风险三部分 每部分不超过五条风险要写负责人不要加开场白。把它改造成 Skill就是把这段话拆进 SKILL.md 的对应区块用途写“整理周报”输入写“工作记录”步骤写“归并三类、排序、限五条、风险标负责人”输出格式写三个固定标题自查清单写四条检查项。改造完之后你只需要贴工作记录不用再重复那段话。如果你在团队里用 GPTs 承载这个 Skill可以在 GPT 的指令里写“处理周报时优先调用周报生成 Skill”这样成员在 Project 里直接贴记录就能出结果。需要管理多个 Skill 和 API Key 时可以在控制台里统一配置地址是 https://taotoken.net/api-keys 接入文档在 https://taotoken.net/doc 。4. 验证请求跑一遍看输出稳不稳配置写完不算完得跑验证。验证的目标不是“能不能出结果”而是“连续多次出结果是否结构一致”。4.1 准备三组测试输入选三组差异较大的输入一组条目多、一组条目少、一组带风险项。比如输入A条目多 完成接口联调、需求评审、线上修复、文档更新、代码review、周会 计划模块开发、文档补全、测试用例 风险第三方接口可能延期 输入B条目少 完成写了一份方案 计划等反馈 风险无 输入C带风险 完成数据迁移 计划灰度发布 风险迁移脚本在高峰期可能超时需要DBA支持4.2 连续跑并对照自查清单把三组输入分别跑两到三次每次输出都对照 SKILL.md 里的自查清单检查三类是否齐全、每类是否不超过五条、风险项是否都有负责人和时间、有没有多余开场白。如果输入B里“风险无”输出里风险部分应该写“无”而不是省略整个标题。如果输入C的风险项没写负责人说明步骤里的“风险项必须标注负责人”没被严格执行需要回到 SKILL.md 把这条写得更硬比如改成“风险项格式固定为‘[描述]负责人X期望解决X月X日’缺一不可”。4.3 用模型对话快速对比如果你想快速对比“提示词版”和“Skill版”的差异可以在模型对话里分别跑同一组输入观察结构完整率。地址是 https://taotoken.net/models 把两版输出并排看差异一目了然。4.4 验证通过的判断标准我的判断标准是连续跑五次结构完整率不低于九成风险项负责人和时间字段不缺失没有多余寒暄。达到这个标准这个 Skill 就可以投入日常使用了。达不到就回到 SKILL.md 改步骤或自查清单改完再跑。这里有个经验验证时不要只测“正常输入”一定要测“边界输入”。比如空输入、只有一条的输入、风险项缺失负责人的输入。边界输入最能暴露 SKILL.md 里没写死的地方。5. 常见报错与排查401、local proxy failed、reading choices、OAuthSkill 本身是流程文件但一旦涉及调用 API 或在工具里接入就会碰到一些典型报错。下面按真实报错逐条排查。5.1 401 Unauthorized这是最常见的接入报错意思是 Key 没被认出来。排查顺序先确认 Key 有没有复制完整前后有没有多空格再确认 Key 有没有过期或被禁用最后确认请求头里的字段名对不对通常是Authorization: Bearer 你的Key。如果是在 Cline、CC Switch 这类工具里配置检查 Base URL 和 Key 是不是填在了对应的输入框里别把 Key 填到 URL 栏。5.2 local proxy failed这个报错通常出现在本地工具通过代理转发请求时。意思是本地转发层没起来或端口不通。排查确认本地服务是否在运行、端口是否被占用、工具里配置的本地地址和实际监听地址是否一致。如果是 CC Switch 这类切换工具检查当前选中的配置项是不是指向了正确的 Base URL。5.3 reading choices 相关报错这类报错一般出现在解析模型返回结构时意思是返回体里没有预期的choices字段。常见原因是请求发出去但返回的是错误信息比如 401 或 404被当成正常响应去解析了。排查先把原始返回打印出来看确认是不是错误码再检查请求的模型 ID 是否写对模型 ID 写错时也可能返回非预期结构。5.4 OAuth 相关报错在 Claude Code、Codex 这类工具里接入时可能碰到 OAuth 流程报错。排查确认回调地址是否和配置一致、本地端口是否被占用、浏览器是否拦截了跳转。如果是 Codex 的auth.json检查里面的字段是否完整Base URL、Key、Model ID 三件套是否都填了。5.5 三件套检查清单只要涉及工具接入就检查这三样配置项说明常见错误Base URL接口地址多写或少写路径、带了多余斜杠Key访问密钥复制不完整、前后有空格Model ID模型标识拼写错误、用了不存在的模型名这三样任何一样不对都会表现为各种看似不相关的报错。排查时先核对三件套能省很多时间。需要新建或查看 Key 时去 https://taotoken.net/api-keys 接入细节看 https://taotoken.net/doc 。6. 把 Skill 用起来从单个任务到团队复用写到这里你已经有了 SKILL.md 模板、目录结构、触发示例和验证方法。接下来最关键的一步是真正把它用起来。我的建议是从最小的任务开始。不要一上来就写一个“处理所有市场文案”的大 Skill而是先挑一个你每周都要做、格式固定、步骤不超过五步的小任务。比如“把零散笔记转成三段式会议纪要”或者“把客户通话记录转成商机评估”。用模板写一份 SKILL.md跑三组输入验证稳定之后再用到日常里。当你发现某个 Skill 已经连续用了十次、每次结果都稳定可靠时那种“不用再操心琐事”的轻松感就是这件事最实在的回馈。之后再逐步扩展把多个 Skill 组合进一个 GPT在 Project 里让团队共用甚至把 Skill 分享给同事让输出的质量站在同一条基准线上。如果你需要长期跑编码或 Agent 类任务可以考虑 Coding Plan地址是 https://taotoken.net/coding-plan 。需要管理多个 Skill 和 Key 时控制台在 https://taotoken.net/console 。把这些基础配置理顺之后Skill 的复用价值会进一步放大。最后留一个实用技巧给每个 Skill 在 SKILL.md 顶部加一行版本号和更新日期比如 版本v1.2 | 更新2025-06。改过几次之后你会感谢这行字因为它能帮你快速判断某个输出是用哪版流程跑出来的。