在上一篇文章里，我记录了自己在 GitHub 上第一次发现了 PAI（Personal AI Infrastructure）（第一次接触的同学，可以把PAI当成一个增强版的Claude Code） 。
这一篇，则是我开始真正动手尝试 PAI 之后的第一轮实践记录。
整体上，我主要做了两件事：
尝试把以前写过的 code 转成 PAI 的 skill（Code → Skill） 把 PAI 里现有的 Agent 和 Skill 大概翻了一遍，有个初步了解
不是教程，也不是结论，更像一次阶段性使用笔记。
注：下面的操作都是在PAI项目目录下，启动Claude Code后完成，也就是如第一篇结尾所言，我还没有安装PAI，只是先启用它的部分能力。
一、从一段旧代码开始：第一次 Code → Skill 的尝试
事情的起点非常简单。
我以前写过一段代码，用来做两件事：
搜索B站上的视频 提取视频字幕
在传统用法里，这类代码基本只有两个结局：
偶尔想起来再跑一次 或者长期躺在仓库里，不再被使用
这次我尝试在PAI里面把这段代码手搓成了Skill。
然后我对 PAI 说了一句话：
“帮我搜索 B 站上讲 Claude Code 最热门的视频，提取字幕，并总结，输出成 md 文件。”
接下来发生的事情是：
自动搜索视频 自动提取字幕 自动总结内容 最后直接生成了一个结构完整的 Markdown 文件
这让我第一次有一个很明确的感受：
我不是在“调用某段代码”，
而是在“直接调用一种能力”。
二、拆解过程：PAI 实际调用了哪些能力？
为了避免“感觉很强但说不清”，我反过来让 PAI 解释刚才整个流程里，自己到底调用了什么。
拆开之后，其实非常清楚：
这一步让我意识到一个很重要的点：
PAI 并没有引入“神秘新能力”，
而是把原本分散的能力，用 Skill 的方式组织了起来。
从结果上看，是“一句话完成一整件事”；
从机制上看，是一组能力被稳定地编排在了一起。
三、Code → Skill：差别不在能力，而在抽象层级
如果只看结果，很容易把这件事理解为：
“AI 帮我自动跑了一段流程。”
但当我对比 code 和 skill 的状态时，差异其实很明显：
Code 强依赖上下文 通常绑定某个项目 复用成本高 Skill 抽象成独立能力 可以被不同 Agent 调用 可以被自然语言直接触发
当一段 code 被转成 skill 后，它不再属于某个项目，而更像是：
我个人能力库里的一个模块。
这也是我第一次比较清晰地感受到：
PAI 的价值点，并不在于“能不能写代码”，而在于能不能把已有能力重新组织起来。
四、Code2Skill：当我意识到这不是“一次性工作”
既然第一次尝试Code转Skill有效，后面会重复这个工作。我就想能否有个Skill来自动完成这个工作。于是，我又顺手做了一件事：
写了一个 Code2Skill 的 Skill。
它的功能很简单：
基于inbox目录中的已有代码项目 输出一个符合 PAI 规范的 Skill 框架
这一步并不复杂，但意义很大。
因为它意味着：
过去写过的 code，并不是历史负担 而是一批尚未被系统化的能力
从这一刻开始，我对 PAI 的理解开始发生变化：
它更像是一个把个人经验不断“沉淀成能力”的工具。
在又尝试转了几个Code项目到Skill后，我逐渐有个疑惑，这个PAI创建的Skill难道和Claude Code创建Skill不一样么，会不会有兼容性问题？
研究后发现，原来创建Skill的过程是PAI自动调用了Createskill这个Skill来实现的。
Claude Code 里的 Skill，更像是“毛坯房”
PAI 里的 Skill，更像是“带装修标准的毛坯房”。
两者的底层机制其实是一样的：
能力来源一致 调用方式一致 LLM 还是同一个 LLM
区别在于：
PAI 在 Skill 之上，加了一层“最佳实践”和结构规范。
比如：
更清晰的输入输出约定 更稳定的触发方式 更明确的职责边界
五、翻一遍 Agent：我第一次用“岗位”而不是“模型”去理解 AI
做完 Code2Skill 之后，我接下去做的是：
把 PAI 里已有的 Agent 和 Skill，完整翻了一遍。
一开始我关注的是「这个 Agent 能干什么」，
后来慢慢变成了：
这个 Agent 的职责边界是什么？
后来又把全局Claude目录下的agent复制了部分过来，当我把它们按产品、研究、技术、设计、测试、安全、商业、SEO 这些维度整理出来时，一个很直观的感受出现了：
这更像是一张组织结构表，而不是模型清单。
在这种视角下，Agent 不再是“谁更强”，而是：
谁更适合这个任务 谁负责哪一类输出
六、关于 Research：我一度想“合并”，后来反而释然了
在整理过程中，我一度有个疑问：
Research Agent 会不会有点多？
Claude / Gemini / Perplexity 是不是可以合并？
直到我真正理解了 Skill 的另一种形态。
我之前默认把 Skill 当成：
类似招聘 JD 里的“通用能力 / 专业能力”。
但后来发现，Skill 其实至少有两类：
1️⃣ 能力型 Skill
做一件明确的事，输入 → 输出。
2️⃣ 编排型 Skill
通过驱动多个 Agent 协同工作来产生结果。
比如 Research 这个 Skill，本质上是：
并行调用 Claude / Gemini / Perplexity 突破反爬虫的升级策略：WebFetch → BrightData → Apify 自动选择分析模式（摘要、威胁建模、智慧提取等） 甚至可以直接从视频中提取文本内容
理解到这里之后，我反而不再纠结 Agent 数量了。
七、Fabric：当“工具感”开始消失
后来我又研究到了 Fabric 这个 Skill。
它内置了 247 个专业 Prompt 模式。
一开始我甚至让 Claude Code 帮我整理了一份参考文档，方便以后使用前翻阅。
但很快我发现：其实没太大必要。
因为在实际使用中，PAI 会自动根据上下文进行匹配。
也正是在这个过程中，我产生了一个很真实的感受：
有时候，我已经分不清——
我用的是 PAI 的能力，
还是 Claude Code 的原生能力。
这并不是困惑，而是一种正反馈。
写在最后：一次“初探”，但方向已经很清楚了
这一轮下来，我并没有觉得自己已经“掌握了 PAI”。
但至少有两点是确定的：
它并不是一个简单的 AI 工具集合 它更像一套值得慢慢搭建、持续演进的个人系统
对我来说，这一篇只是一次非常早期的探索记录。
接下来我可能会继续写下去。
但不管写什么，这一轮初探已经足够让我确认一件事：
PAI 值得继续往下试。
#PAI #AIAgent #ClaudeCode #AI工作流 #程序员效率 #个人生产力 #自动化系统
