CCJK Skills 设计与持续升级指南

旧版 skills 文档曾经把重点放在一套 v2 SDK API 上，但这已经不能代表今天官网最需要解决的问题。现在更重要的是：

• skills 怎样帮助用户更快做决策
• skills 页面怎样避免继续输出历史命令
• 内容自动发布时怎样复用统一方法论

所以这篇指南不再围绕历史包名和实验 API，而是围绕“内容型 skills”与“工作流型 skills”的设计原则。

1. 先定义 Skills 的职责

在当前官网体系里，skills 至少分三层：

上手型 Skills

目标是把用户从“第一次接触”推进到“能开始用”。

典型内容：

• npx ccjk
• npx ccjk init --silent
• npx ccjk boost
• ccjk zc --preset dev

决策型 Skills

目标是把用户从“知道有这个东西”推进到“知道该不该用”。

典型内容：

• provider 的运营模式分类
• 接入建议结论
• blocking factors
• review cadence

持续运营型 Skills

目标是让内容和环境一起更新，而不是一次生成后长期失真。

典型内容：

• 官方 snapshot 同步
• 来源基线刷新
• 已发布内容的历史命令清理
• 自动发布提示词升级

2. Skills 页面不该继续做什么

下面这些内容在官方站里应该被弱化或移除：

• 没有上游公开依据的历史 SDK API
• 旧的 slash 命令神话列表
• 把技能解释成“越多越好”的素材堆
• 与当前 README 主线相冲突的安装方式

skills 不是为了让页面看起来更热闹，而是为了让用户执行更少错误动作。

3. 当前更稳妥的 Skills 表达方式

用目标表达，不用旧命令表达

比起列一排历史命令，更好的表达是：

• 代码审查
• provider 风险筛选
• 环境优化
• 远程巡检
• 持久记忆维护

然后再给出当前能确认的入口命令。

用结论块替代“百科全书式罗列”

一个好的 skill 卡片，至少要包含：

• 它解决什么问题
• 在什么阶段用
• 当前推荐命令
• 会影响什么决策

用和首页一致的主线命令

当前官方主线应该固定围绕：

hljs bash
npx ccjk
export ANTHROPIC_API_KEY="sk-ant-..." && npx ccjk init --silent
npx ccjk boost
ccjk zc --preset dev
ccjk remote setup

4. 如何升级自动发布机制

skills 内容自动发布最容易出问题的地方，不是模型写不出字，而是提示词没有约束：

• 不强制检查官方来源
• 不区分官方 provider 与聚合商
• 不要求产出“该不该用”的结论
• 不要求回写 review 时间与 freshness

因此提示词至少应该加入这些约束：

1. 先确认内容是否有官方来源
2. 如果是 provider，必须输出运营模式分类
3. 如果是 provider，必须输出接入建议结论
4. 如果信息不足，禁止伪造强结论
5. 输出必须和当前公开 onboarding 命令一致

5. 官方网站中的 Skills 升级清单

如果你在维护本站，skills 相关页面应该优先做到：

• 不再继续放大历史 v2 SDK 叙事
• 不再把旧 slash 命令作为默认技能体系
• 将 skills 与 provider intelligence、snapshot、自动发布流程串起来
• 让用户从“浏览技能”走向“做出动作”

6. 一个更实用的 Skills 内容模板

推荐以后所有新 skills 内容都按这个顺序写：

1. 这个 skill 解决什么问题
2. 适合在什么时候使用
3. 当前官方入口命令
4. 相关 provider / workflow 风险点
5. 推荐下一步动作

7. 当前建议

如果你在升级官网内容体系，不要再把 skills 当作一组历史命令目录。

更高价值的方向是：

• 把 skills 做成“任务入口”
• 把 provider 页做成“决策入口”
• 把 snapshot 和自动发布机制做成“更新入口”

这样技能体系才会真正服务于持续升级，而不是制造新一轮内容债务。