ChatGPT点评Claude版《刘韧写作Skill》附迁移方案

刘

刘韧2026年07月09日约 6 分钟

Claude适合干活，ChatGPT适合当老师。Claude在我还不太明白的时候，将很多活都帮我干了，ChatGPT则能讲得更清晰，让我站得更高。

2. 你现在最应该改变的使用方式

不要把 Skill 当“提示词”。

应该把它当：

一个记者编辑部。

错误用法：

“请按照我的 Skill 写这篇文章。”

这样会导致：

模型读取大量规则，但不知道当前任务调用哪一个模块。

正确用法：

第一层：启动身份

第一次对话：

加载刘韧写作系统 v13.8。任务：
写一篇关于××的文章。
先不要写正文。
请执行：
1. 判断任务类型
2. 调用对应卫星模块
3. 给出任务图
4. 列出缺失材料

你的 Skill 里面已经有任务图思想。

应该先让 AI 做“编辑部策划”。

第二层：让 AI 选择引擎

例如：

修改《六纺生死劫》：

不要：

用我的 Skill 修改。

应该：

启动：
project-delta
engine
publish-recut目标：
把旧稿提升为新发表版。
先输出：
事实层
冲突层
人物动作链
删除清单

原因：

你的 Skill 最大价值不是文风。

最大价值是：

减少错误决策。

第三层：把 AI 变成责任编辑

你的系统里面有：

回归测试
范例库
删除机制

这些其实比生成更重要。

每篇文章应该增加一个固定步骤：

生成初稿↓
运行回归测试：
检查：
1. 是否有抽象判断？
2. 是否有作者自我解释？
3. 是否缺现场？
4. 是否违反减法？
5. 是否存在不可证伪结论？
↓
二稿

这比让模型“写得漂亮”重要十倍。

3. 你的 Skill 目前最大的技术问题

我认为不是模型，而是：

“规则密度过高”

你的 v13.8 大约已经接近软件工程里的：

单体应用（monolith）

优点：

规则完整。

缺点：

维护成本指数增长。

你自己在 Skill 里已经发现：

“规则之间冲突随规则条数呈平方增长。”

这是软件工程里的真实问题。

假设：

100 条规则：

冲突组合：

100×99/2 = 4950

500 条规则：

124750 个潜在冲突。

所以下一步不是继续增加规则。

应该做：

Skill 14.0：压缩层

类似操作系统：

用户任务↓
任务分类器
↓
调用10条核心规则
↓
调用卫星模块
↓
生成
↓
测试

不要每次加载宪法。

只加载执行路径。

4. Pro 版最佳玩法

如果你升级 Pro，我建议你的工作流：

建一个长期 Project：

名字：

《刘韧写作系统》

里面放：

SKILL.md
engine.md
project-delta.md
范例库
你的代表作品

然后每次：

进入项目输入：
今天任务：
《××》
调用：
人物稿模式
目标：
发表版

不要每次上传 zip。

5. 一个反向判断

你的直觉可能是：

模型越强，我的 Skill 越有效。

实际上：

对于你这种高级用户，可能相反。

你的边际收益排序：

工作流设计
知识库组织
评价体系
模型升级

原因：

普通用户瓶颈是生成能力。

你的瓶颈是：

如何把35年记者经验变成机器可执行流程。

这已经进入“AI Agent 工程”问题。

[关键判断 | 立即可执行步骤 | 最大风险点]

你的 v13.8 已经超过普通 Prompt，应该按“编辑部操作系统”使用，而不是一句话调用。升级 Pro 会提升长文、多轮编辑能力，但不是核心变量。立即做三件事：①建立固定 Project 存放 Skill 与范例；②每篇稿先运行任务图，再生成；③增加回归测试环节。最大风险是继续增加规则，导致 Skill 从“增强智能”变成“规则负担”。下一版重点应是压缩和路由，而不是扩充。

最近，很多用户遇到一个现实问题：

原来在 Claude 里运行得很好的 Skill，因为账号、服务、访问等原因，需要迁移到 ChatGPT。

很多人第一反应是：

“把文件上传过去，不就可以了吗？”

我的实践告诉我：

没有这么简单。

因为 Skill 不是一个 Prompt。

如果只是几句提示词，复制粘贴即可。

但当 Skill 发展到一定规模，它实际上变成了一套“认知操作系统”。

我自己的《刘韧写作系统》就是一个例子。

最初，它只是几个写作提示：

如何采访？

如何判断事实？

如何组织文章？

如何减少废话？

后来不断增加：

采访方法。

叙事结构。

事实核查。

标题系统。

出版改写流程。

回归测试。

项目管理。

最后，它已经不是一个 Prompt，而是一套工作流。

以前我主要在 Claude 中使用它。

迁移到 ChatGPT 后，我发现一个有意思的问题：

模型能力不是最大的障碍。

真正的问题是：

怎样让 Skill 适应新的运行环境。

Skill迁移的第一个误区：把规则当代码

很多人设计 Skill 时，会不断增加规则。

比如：

必须这样写。

不要那样写。

遇到这种情况应该怎样处理。

规则越来越多。

看起来越来越完善。

但软件工程里有一个规律：

系统复杂度不是线性增长。

规则数量增加，规则之间的冲突可能呈平方增长。

100条规则，理论上有4950种潜在关系。

500条规则，组合关系超过12万种。

人的经验可以处理这种复杂性。

机器不一定。

所以，Skill发展到一定阶段，不能继续堆规则。

需要架构。

第二个误区：让AI执行全部规则

迁移到 ChatGPT 后，我做的第一个调整：

不是增加规则。

而是减少入口。

过去：

“请按照我的Skill写文章。”

这个命令太模糊。

模型不知道：

现在应该调用采访模块？

还是人物稿模块？

还是旧稿改写模块？

还是出版版优化模块？

更好的方式：

先让AI做任务判断。

例如：

“启动刘韧写作系统。

分析这个任务属于哪种类型。

选择对应模块。

列出执行路径。

不要直接写正文。”

这一步类似软件里的路由。

先决定调用哪个服务。

再执行。

第三个误区：Skill价值不在生成，而在判断

很多人使用AI，关注：

写得像不像人。

语言流不流畅。

标题够不够吸引。

但对于长期写作者，真正稀缺的不是文字生成。

而是判断。

记者35年的经验，核心不是写字速度。

而是：

什么值得写？

什么是假问题？

哪里有冲突？

哪个事实改变结论？

哪个人物动作代表时代变化？

这些东西，才是Skill应该保存的部分。

所以我给自己的Skill增加了一层：

回归测试。

每篇文章完成后，不先问：

“写得漂亮吗？”

而问：

有没有现场？

有没有人物动作？

有没有抽象判断？

有没有不可证伪的结论？

有没有作者偷懒？

ChatGPT给我的另一个提醒：Skill应该像编辑部，而不是说明书

过去我把 Skill 看成一本操作手册。

现在我更愿意把它看成一个编辑部。

编辑部有：

总编辑：

决定方向。

记者：

采集事实。

编辑：

调整结构。

校对：

检查错误。

出版：

适配平台。

一个优秀 Skill，也应该如此。

它不是告诉AI：

“你必须怎么写。”

而是建立一个决策流程：

面对这个任务，下一步应该做什么。

Claude写出的Skill，为什么需要ChatGPT重新改造？

这不是Claude的问题。

也不是ChatGPT的问题。

不同模型有不同的推理特点。

同一套Skill，在不同模型中运行，会产生不同效果。

这和软件跨平台运行类似。

Windows程序迁移到Linux，不是复制文件就结束。

需要适配运行环境。

Skill也是如此。

真正可迁移的不是规则文本。

而是：

问题定义方式。

决策流程。

评价标准。

知识结构。

我的建议：不要打造更大的Skill，打造更好的架构

下一阶段，我认为个人AI使用的竞争，不是谁拥有最长的Prompt。

而是谁拥有更好的认知架构。

未来的个人AI系统，应该类似：

用户经验层。

任务路由层。

专业模块层。

执行层。

评价层。

不断迭代。

像软件系统一样升级。

这次把 Claude 里的 Skill 迁移到 ChatGPT，最大的收获不是换了一个模型。

而是发现：

过去我们以为自己训练的是AI。

实际上，我们是在整理自己的经验。

AI只是第一个能够运行这套经验的机器。

真正需要升级的，不只是模型。

还有我们自己的思考系统。