AI 难用非因智商低，实乃缺乏规则约束

AI 面临的最大瓶颈，或许并非模型能力不足，而是多数人仍将其视为普通的聊天工具。

近期，开发者社区开始重新聚焦两类 AI 工程实践：

一类致力于为 AI "制定规范"；

另一类则专注于为 AI "构建组织"。

前者的典型代表是 Matt Pocock 推出的 skills 项目——通过大量 SKILL.md 文件，明确指示 Claude Code 如何编写代码、提交变更以及执行重构。

后者的典范则是 Daniel Miessler 的个人 AI 基础设施（简称 PAI），目前已迭代至 v5.0 版本。其体系更为完整：协助你打造专属的 AI Agent 团队，每个 Agent 承担不同职能，分工明确。

这两个项目看似不同，实则指向同一个核心逻辑：

你不能仅依赖 AI 的智力，更必须为其建立结构。

凡是使用过 Claude Code 或 Cursor 的用户，想必都遭遇过此类困境。

今日你耗费半小时调教其代码风格，明日开启新对话，它便重蹈覆辙。你教导的 Git 提交规范，往往几轮交互后便被遗忘。你反复强调禁止修改测试文件，它仍会偶尔越界。

此处提到的"失忆"仅为一种便于理解的比喻。本质上并非 AI 的记忆系统故障，而是每次对话均为全新的上下文，先前约定的规范并未被带入。

Matt Pocock 的 skills 项目旨在解决这一注入难题。其方案并非依赖 AI 自行"记忆"，而是将规范文档化，植入项目之中，强制 AI 在执行任务前先行读取。

Skills 项目的核心理念极其简单：在 .claude/skills/ 目录下放置一批 SKILL.md 文件，每个文件对应一类操作准则。

目前 Matt Pocock 已开源 28 个 Skills，划分为若干大类：

当你在 Claude Code 中执行任务时，系统通常会将这些规则文件作为任务上下文的一部分进行读取，从而将规范纳入考量。无需你反复口述，亦不依赖 AI 自身的"记忆"。

其本质仍是利用上下文文件注入规则，而非赋予模型真正的长期记忆。.claude/skills/ 目录虽非 Claude 官方定义的 DSL，但属于社区共识结构，实践效果稳定。

该项目已被 skillsovermcp.com 接入为 MCP 服务，支持以 MCP 形式一键集成（此为社区方案，非 Claude 原生功能；具体指令请以该站最新文档为准）。

亦可直接克隆至项目根目录：

git clone https://github.com/mattpocock/skills .claude/skills

重启 Claude Code 后，这些规则即可作为项目上下文的一部分参与任务执行，促使 AI 在执行过程中更易遵循预设规范。

本人将这套逻辑应用于知识库管理已有一段时间，体验确有显著提升。AI 出错的边界，已从"模糊的口头约定"转变为"文件中的明文规则"。

Matt Pocock 解决的是"规范"问题，Daniel Miessler 解决的则是"分工"问题。

PAI 的核心理念在于：每个人都应拥有自己的 AI 基础设施，而非仅用一个 AI 处理所有事务。

此处提及的"AI Agent 军团"，实质是多个角色化工作流的编排，而非完全自主的"数字员工"。你依然是指挥官，只是将不同类别的任务分配给了更专注的工具。

在 PAI v5.0 中，个人 AI 系统被划分为多个层次（下图基于 PAI v5.0 思路的简化示意，具体以 GitHub 仓库文档为准）：

个人 AI 基础设施（PAI）

注：PAI 本身未内置持久记忆层，如需跨会话记忆需额外集成，组件构成亦可能随版本更新，请以 GitHub 仓库文档为准。

值得注意：许多 Agent 系统真正复杂的部分，在于长期记忆与上下文管理，而非 Agent 的数量本身。PAI 提供的是架构骨架，记忆层需由你自己解决。

其观点十分明确：用一个 AI 处理所有事务，本质上是将不同类型的任务塞入同一上下文，导致边界模糊、相互干扰。拆分之后，理想状态下，各 Agent 将拥有更纯净的上下文和更稳定的任务边界。

PAI 提供了配置模板和安装脚本，支持接入 Claude、GPT-4、Gemini 等主流模型。但这并非开箱即用的产品——安装脚本仅完成脚手架搭建，你仍需选择驱动模型、配置各 Agent 的 API Key 及角色提示词。其入门门槛高于 Skills，但仓库内包含完整文档及配套 YouTube 视频。

单看 Skills，它解决的是"AI 行为不一致"的问题。

单看 PAI，它解决的是"单一 AI 处理多任务效率低下"的问题。

但二者结合，实则正在构建同一事物：个人 AI 基础设施的两个基础层级。

一层是规范层（Skills），明确每个 Agent 的边界与行为准则。

一层是架构层（PAI），决定使用几个 Agent、各自职责及协作方式。

越是普通用户，越容易陷入"用一个对话解决所有问题"的误区，进而不断遭遇行为漂移、越界及风格不一致等问题。这并非 AI 不够聪明，而是缺乏结构。

在模型能力达到一定水平后，结构与上下文管理往往比单纯升级模型更能影响最终效果。

若你目前使用 Claude Code、Cursor 或其他 AI 编程 Agent，Skills 值得花费半小时进行一次配置。安装成本极低，效果立竿见影，尤其对团队协作助益更大。

PAI 则适合那些在日常工作中深度依赖 AI，并利用多个工具处理不同任务的用户。若你仅偶尔询问 ChatGPT，搭建 PAI 可能属于过度投入。

最值得关注的一点在于：这两个项目的价值，不仅在于工具本身，更在于其背后的思路。

这一思路正被越来越多的人提及，名为：Context Engineering。过去大家研究的是"如何写好一句 Prompt"，如今更多人开始探索："如何将 AI 纳入一个稳定工作的系统"。Prompt 技巧是战术，Context Engineering 则是工程方法论。从这个视角看，Skills、Memory、RAG、MCP、Agent，其实都在做同一件事：控制 AI 在当前任务中"能看到什么、应遵循什么"。

许多所谓的 Agent，本质仍是"带有工具调用和状态管理的大模型工作流"。脱离这一本质，任何"AI 军团"或"数字员工"的说法都易沦为空谈。

AI 不会自动成为你的好同事，你必须赋予其结构、制定规矩、明确分工。这件事，你做与不做，差距将日益扩大。