AI Coding on 鬼哥的空间

从 agent-skills 拆解：如何开发一套 Skill + Agents 项目脚手架

Tue, 18 Aug 2026 00:00:00 +0000

很多团队做第一套 Skill 仓库时，目录通常很快就长成这样：十几个 Markdown，名字都很专业，内容也都像模像样。真正使用两周后，问题开始出现：有的规则每轮都加载，有的永远触发不了；两个“专家”互相转述，token 花了两遍，结论反而少了一层；换到另一个 Coding Agent，又得复制一套提示词。

这不是 Prompt 写得不够好，而是项目没有分层。

我最近沿着一段关于 Claude Code sub-agents 的讨论，重新拆了一遍 Addy Osmani 的 agent-skills 项目。它最值得借鉴的，并非某一份代码评审提示词，而是把一组自然语言指令做成了工程资产：能被发现、能被调用、能被组合、能被覆盖，还能被自动检查。

这篇文章就做一件事：以它为样板，搭一套自己的 Skill + Agents 项目脚手架。

我以前写过架构拆解和项目参考手册，重点是“这个项目为什么这样设计”。本文换一个方向：假设现在要从零建自己的仓库，第一批目录与验证门应该怎样落下去。

本文核对的是 agent-skills 2026 年 8 月 14 日的 0.6.7 版本：仓库包含 24 个 Skills、4 个 Agents 和 8 个 Claude lifecycle commands。项目仍在快速变化，具体字段与安装命令请以文末官方资料为准。

先分清三件事：怎么做、谁来做、何时组合

agent-skills 在 docs/agents.md 里给出了一个非常实用的三层模型：

层	回答的问题	例子	主要产物
Skill	怎么做	`code-review-and-quality`	步骤、约束、验收条件
Agent / Persona	谁来做	`code-reviewer`	专业视角、工具权限、输出格式
Command / Orchestrator	何时及如何组合	`/review`、`/ship`	确定性入口、并行编排、结果合并

这个区分看似是命名问题，实际决定了整个项目会不会失控。

Skill 不应该只是“你要认真检查安全问题”这种知识卡片。它更像一份可执行 SOP：什么时候触发，按什么顺序行动，哪些步骤不能跳过，最后拿什么证据证明任务完成。

Agent 也不该是“精通前后端、测试、安全、产品与运维的超级专家”。它需要一个稳定视角。例如 security-auditor 只负责威胁建模与漏洞审计，test-engineer 只负责测试策略与覆盖缺口。角色越单一，输出越容易预测，也越容易被别的流程复用。

编排入口则解决确定性问题。用户输入 /ship，不是让模型临场猜测该做什么，而是加载一份预先写好的编排剧本：并行启动哪些专家、分别检查什么、如何合并报告、什么条件必须判定为 NO-GO。

可以把这三层记成一句话：Skill 是工艺，Agent 是工位，Orchestrator 是流水线。 把三者写进同一个大 Prompt，就相当于把操作手册、岗位说明和生产调度贴在同一张纸上——不是不能运行，只是出问题时很难知道该改哪一段。

但别照抄三层：今天还需要“包装层”和“验证层”

如果只看概念，三层已经够清楚；如果真要做一个可发布的仓库，还差两层。

第一层是平台包装。不同 Agent Harness 的发现规则并不一致。Claude Code 能识别插件根目录的 skills/、agents/、hooks/，也继续兼容 commands/；Codex 版 agent-skills 则通过 .codex-plugin/plugin.json 指向同一份根目录 skills/。项目文档也明确说明：当前 Codex 集成复用的是 Skills，Claude 的 slash commands、personas 与 hooks 仍属于 Claude Code 侧能力。

第二层是验证。自然语言文件同样会出现“编译错误”：frontmatter 缺字段、目录名与 name 不一致、引用路径失效、多个 manifest 版本不一致、命令引用了不存在的 Skill。agent-skills 把这些检查放进 scripts/ 和 evals/，这一步把“提示词收藏夹”与“可维护项目”真正区分开来。

因此，一套更完整的结构其实是五层：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


语义核心
├── skills/ # 可复用工作流：怎么做
├── agents/ # 专业执行者：谁来做
└── references/ # 多个工作流共享的检查表与标准

调用与适配
├── .claude/commands/ # Claude Code 的编排入口（兼容形式）
├── .claude-plugin/ # Claude 插件元数据与市场清单
├── .codex-plugin/ # Codex 插件清单
└── .gemini/commands/ # 其他 Harness 的薄适配

工程保障
├── scripts/ # lint、链接、版本与结构校验
├── evals/ # 触发准确率与行为评测
└── .github/workflows/ # 安装、校验与发布门禁

这里最重要的设计判断是：共享的是语义核心，复制的是薄适配层。 如果你在 Claude、Codex、Gemini 目录里各维护一份完整安全规范，三个月后一定会得到三个略有不同的“唯一真相”。

第一步：从最小可运行骨架开始

不要上来就造二十个 Skill。先选择一个高频、边界清楚、结果容易验证的场景，例如“发布前评审”。最小骨架只需要这些文件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


my-agent-kit/
├── .claude-plugin/
│ ├── plugin.json
│ └── marketplace.json
├── skills/
│ └── code-review/
│ └── SKILL.md
├── agents/
│ └── code-reviewer.md
├── .claude/
│ └── commands/
│ └── review.md
├── scripts/
│ └── validate-skills.js
├── README.md
└── LICENSE

Claude Code 官方插件文档有一个容易踩中的规则：.claude-plugin/ 里只放 plugin.json 等元数据；skills/、agents/、hooks/ 必须位于插件根目录。把所有东西都塞进 .claude-plugin/，目录看起来很整齐，Claude Code 也会很整齐地假装没看见。

一个最小 manifest 可以这样写：

1
2
3
4
5
6
7


{
 "name": "my-agent-kit",
 "version": "0.1.0",
 "description": "Reusable engineering workflows and specialist agents",
 "author": { "name": "Your Team" },
 "license": "MIT"
}

默认目录能被自动发现时，不必急着把每条路径都写进 manifest。脚手架的第一原则不是“配置齐全”，而是“每个配置都有必要”。

第二步：把 Skill 写成有退出条件的工作流

一个 Skill 至少需要 name 和 description：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


---
name: code-review
description: Reviews code changes for correctness, maintainability, security, and performance. Use before merging a pull request or releasing a change.
---

# Code Review

## When to use
- Before merge
- After a bug fix
- After an agent implements a feature

## Workflow
1. Read the task or spec.
2. Read tests before implementation.
3. Inspect the diff across five review axes.
4. Run the relevant verification commands.
5. Report findings by severity with file and line references.

## Verification
- [ ] Every blocker includes evidence and a concrete fix.
- [ ] Test and build status are reported.
- [ ] Uncertainty is labeled instead of guessed.

description 不是摘要，而是路由契约。Claude Code 会结合用户任务、当前上下文与 description 决定是否加载 Skill。写得太宽，Skill 会到处抢活；写得太窄，它会成为一份只有作者记得存在的文档。

agent-skills 的做法值得直接借鉴：description 同时写清“做什么”和“什么时候使用”，正文再写完整流程；把长清单移到 supporting files；尽量让 SKILL.md 保持聚焦。官方文档把这种加载方式称为按需加载：启动时主要暴露名称和描述，真正调用时再加载正文与相关资源。对于装了几十个 Skill 的环境，这不是洁癖，而是上下文预算。

我还建议给每个工作流增加两类内容：

失败时 Agent 最常找的借口，例如“改动很小，不需要测试”；
可以被外部观察的退出条件，例如测试输出、构建结果、截图或报告路径。

好的 Skill 不是让模型“更懂道理”，而是让它更难绕过流程。

第三步：让 Agent 只拥有一个视角

Agent 文件同样由 YAML frontmatter 和 Markdown 正文组成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


---
name: code-reviewer
description: Senior reviewer for correctness, readability, architecture, security, and performance. Use for a focused review before merge.
tools: Read, Grep, Glob, Bash
model: sonnet
---

# Senior Code Reviewer

You review the requested change from one perspective: code quality.

## Output
- Verdict: APPROVE or REQUEST CHANGES
- Critical issues
- Required changes
- Suggestions
- Verification story

## Boundaries
- Do not implement fixes unless explicitly asked.
- Do not invoke another persona.
- State uncertainty and request evidence when needed.

这里有三个设计点。

第一，description 决定“什么时候派它上场”，正文决定“上场之后怎么工作”。不要把关键执行规则只写进 description，也不要指望正文能挽救一份含糊的 description。

第二，权限应当服从职责。一个只负责评审的 Agent 通常不需要 Edit 或 Write。限制工具不只是安全措施，也是在减少角色漂移：当手里只有锤子时什么都像钉子；当手里同时有读、写、部署和发消息工具时，评审员很快会产生创业冲动。

第三，插件提供的 Agent 和项目级 Agent 使用相同的基本定义格式，但能力范围与优先级并非完全相同。Claude Code 当前的优先级是：组织托管配置、--agents、项目 .claude/agents/、用户 ~/.claude/agents/、插件 agents/。项目定义可以覆盖同名插件 Agent；而出于安全原因，插件 Agent 不支持 hooks、mcpServers、permissionMode 等字段。

这反而形成了一个很好的产品机制：插件给出安全的默认角色，团队在项目中覆盖它，个人还能保留自己的通用角色。脚手架不必预见所有业务，只要设计好覆盖点。

第四步：把编排写成“显式剧本”

单一 Agent 适合直接调用。多个 Agent 只有在任务真正独立时，才值得并行 fan-out。

agent-skills 的 /ship 是一个很好的例子：主 Agent 针对同一份 diff，同时派出 code-reviewer、security-auditor 和 test-engineer。三个子 Agent 互不依赖，各自在独立上下文里生成报告；等它们返回后，主 Agent 去重、提升严重级别，并输出 GO / NO-GO 与回滚方案。

1
2
3


 ┌─ code-reviewer ────┐
/ship → parallel fan-out├─ security-auditor ├→ main agent merge → GO / NO-GO
 └─ test-engineer ────┘

这个模式成立，需要同时满足四个条件：

子任务之间没有顺序依赖；
不写同一份可变状态；
每个 Agent 提供的是不同种类的信息；
合并工作足够小，适合留在主上下文完成。

如果步骤有明确依赖，例如 /spec → /plan → /build → /test，不要为了显得“Agentic”而强行并行。agent-skills 选择让用户逐步触发生命周期命令，保留每一步之间的人类判断。流水线不是越自动越高级；错误方向跑得更快，通常只是更早抵达返工现场。

还有一个常见反模式：创建 meta-orchestrator Agent，职责只是判断该叫哪个 Agent。它没有领域价值，却多了一次上下文转述与信息损失。路由能写进入口 Skill，就不要再招聘一位“负责转接电话的 AI 经理”。

需要特别更新一个来自早期实践的认知：在当前 Claude Code 中，自定义 command 已并入 Skill 机制。.claude/commands/review.md 仍然兼容，也会生成 /review；但新项目更适合优先用 skills/<name>/SKILL.md，因为它支持 supporting files、自动触发与更完整的 frontmatter。概念上仍然需要“编排入口”，实现上未必非要保留独立 commands 层。

第五步：为不同平台写薄适配，不复制核心

如果目标只支持 Claude Code，到这里已经可以工作。如果希望项目同时服务 Codex、Gemini CLI 或其他 Harness，需要先接受一个现实：Skill 的可移植性通常高于 Agent 编排的可移植性。

agent-skills 当前版本就是很诚实的示范：同一份 skills/ 被 Claude Code 与 Codex 复用；.codex-plugin/plugin.json 只负责告诉 Codex 到哪里发现它们。Claude 专属的 agents、slash commands 和 hooks 没有假装“一次编写，到处运行”。其他平台有自己的 command 文件与安装说明。

建议把跨平台边界写成一张能力矩阵：

能力	共享语义核心	平台适配
工作流步骤与验收标准	`skills/`	通常可直接复用
共享检查表	`references/`	注意安装后的相对路径
Persona 正文	`agents/`	按 Harness 的 Agent 机制注册
并行与结果合并	编排意图可共享	工具名、并发方式需适配
安装与发现	无	manifest、marketplace、命令格式
hooks / MCP / 权限	原则可共享	配置 schema 基本各不相同

跨平台设计的目标不该是文件树完全对称，而是行为语义尽量一致。能复用 80% 的核心、允许 20% 的适配，比三套看起来相同、实际逐渐漂移的实现可靠得多。

第六步：把 Markdown 当代码测试

脚手架至少应有四类静态检查：

1
2
3
4


结构检查：skills/<name>/SKILL.md 是否存在
Schema 检查：frontmatter、必填字段、合法字段
引用检查：相对链接、脚本与 references 是否存在
一致性检查：多个 manifest 的名称与版本是否同步

随后再加行为评测。每个 Skill 准备三组 case：

应触发：例如“帮我审查这次认证改动”；
不应触发：例如“解释一下这段代码做什么”；
边界 case：例如“只改了一行 README，需要完整发布审计吗？”

行为评测不必一开始就追求复杂分数。先记录三个结果已经很有价值：选对了哪个 Skill、有没有执行关键步骤、是否产出了要求的证据。等 case 多了，再统计触发准确率、漏执行率和不必要的 Agent 调用成本。

仓库还应提供最小安装冒烟测试：从干净环境安装插件，列出被发现的 Skills 与 Agents，调用一个最小示例，确认输出结构。很多项目的 CI 会认真检查 JSON 能否解析，却从没验证用户安装后是否真的看得到组件。这和餐厅通过了厨房验收但忘了留门，属于一种很工程化的幽默。

一套可以直接执行的开发顺序

如果现在开始搭自己的项目，我会按下面的顺序推进：

选一个高频场景，写出输入、输出与完成标准；
先实现一个 Skill，确保单独调用能稳定完成任务；
当确实需要独立视角或上下文隔离时，再增加一个 Agent；
只有多个独立视角需要合并时，才增加 fan-out 编排；
增加 manifest 与 marketplace，把本地目录变成可安装产品；
增加 lint、引用校验和安装冒烟测试；
用真实失败案例补 evals，而不是凭想象扩写 Prompt；
最后再做跨平台适配，并明确哪些能力无法等价迁移。

每新增一个组件，都应该能回答三个问题：它消除了哪段重复说明？它带来了哪种以前没有的专业判断？如果它失效，哪项测试会报警？三个问题都答不上来，先别加。

最后的检查表

发布第一版前，可以用这份清单收口：

每个 Skill 都写清 what + when，而非只写主题名称；
每个工作流都有可观察的退出条件；
每个 Agent 只有一个主要角色和一种输出格式；
只给 Agent 完成职责所需的工具；
编排只用于真正独立的并行任务；
主 Agent 负责合并，Persona 不互相转述；
共享内容只有一份源文件，平台目录保持轻薄；
项目级覆盖策略与优先级有文档说明；
frontmatter、引用、manifest 和版本经过自动校验；
至少有应触发、不应触发、边界三类评测；
在干净环境完成过一次安装与调用冒烟测试。

回头看最开始那堆 Markdown，问题从来不在数量。真正的分界线是：它们能否形成清楚的职责边界、稳定的发现机制、可控的编排关系和可重复的验证结果。

脚手架的价值，不是帮你更快地产生 Prompt，而是让团队可以像维护代码一样维护 Agent 的行为。

这也是 agent-skills 最值得借鉴的地方：它没有试图造一个无所不能的超级 Agent，而是把经验拆成工艺、工位、入口、包装和质检。所谓 Agent 工程化，大概就是从“这段提示词挺好用”，走到“这套系统出了问题，我知道该改哪一层”。

参考资料

持续学习 - 读吴恩达老师的 AI Engineering Skills Map

Sun, 16 Aug 2026 00:00:00 +0000

Andrew Ng 最近发布了 The AI Engineering Skills Map。

我原以为，它大概又会列出一串要学的新名词：模型、Agent、RAG、MCP、评估……毕竟这两年 AI 圈最不缺的，就是下一批必须学会的工具。

但读完后，真正让我停下来的不是某个工具，而是其中一项能力：Shaping the build。

当 AI 越来越擅长“按规格把东西做出来”，工程师更重要的工作，反而变成了决定：究竟什么值得被做出来。

我们太擅长围观模型，太少真正走进现场

这两年，AI 圈最不缺的，是围绕模型的热闹。

又一家机构发布了新模型，参数多大，跑分涨了多少，在哪个 benchmark 超过了谁。我们很容易花半天时间讨论它的能力边界，仿佛坐在路边摊上，也能把国际局势分析得头头是道。

信息当然重要。模型进步也确实会改变工程方案。我自己也在关注、在试用、在学习各种 AI Coding 工具、harness 和 Skill。

但读完 Andrew 的文章，我开始反问：这些信息最后有多少变成了我真正做过的东西？我有没有拿一个真实问题去试过、撞过墙、做过评估、承担过一次“它答错了怎么办”的后果？

鬼哥一直有个很朴素的判断：

上过一天战场的普通士兵，强过训练过一年、却从未见过敌人眼中杀气的特种部队。

放到 AI 开发上，这不是鼓吹粗糙上线，而是说：一次真实实践里遇到的脏数据、用户误解、预算约束、模型幻觉和责任边界，比十篇模型评测更能逼着人长出工程判断。

一句“做个 AI 客服”，其实还没有开始定义问题

假设有人对你说：

“我们做一个 AI 客服，提高客服效率吧。”

这句话看起来已经足够清楚。于是很自然的下一步是：选一个模型，接知识库，做一个聊天窗口，必要时再加个 RAG 和转人工按钮。

这些都没错。但这其实是把一个尚未被理解的问题，过早翻译成了一个技术方案。

更值得先问的是：

“效率”到底是谁的效率？是用户更快得到答案，还是客服少处理一些重复问题？
用户来找客服时，真的只需要一个事实答案吗？还是需要确认、安抚、解释，甚至需要一个愿意负责的人？
如果它答错了一次，错的是退款金额、物流状态，还是医疗、金融、账户安全这类高风险问题？
哪些问题可以自动处理，哪些必须立刻转给人？

这些问题会直接改变知识库怎么建、工具权限开多大、评估集怎么选、何时升级人工、界面如何表达不确定性，以及为了可靠性愿意付出多少成本。

所谓“理解用户”“理解人性”，不是产品课上的漂亮话。它会一行一行地进入你的系统设计。

Andrew 的四项能力，恰好解释了差别从哪里开始

Andrew 的团队基于 10,000 多条招聘信息、专家与招聘方访谈、问卷及其他在线数据，归纳出四项最重要的 AI Engineering 能力。对我来说，它们不是一张“待学名词表”，而是一张让那句 AI 客服需求显影的地图。

1. 构建与部署 AI 应用：把“不确定”当作系统属性

传统软件大多是确定性的：同样的输入，通常得到同样的输出。AI 应用不是。你给 LLM 一段上下文，不会完全知道它下一次会怎么回答；你训练一个模型，也无法保证它面对新样本时的判断。

所以 AI 客服的关键从来不是“它能不能回答”，而是：它会怎样答错，我们如何发现、衡量并纠正它。

这就是为什么 Andrew 特别强调 disciplined evals 和 error analysis loops。没有评估和错误分析，所谓优化常常只是换一个 Prompt、换一个模型，然后凭感觉说“似乎好一些”。

2. 软件工程基础：AI 不会替你做取舍

一个客服系统不仅有模型，还有并发、延迟、缓存、数据权限、审计、成本、可用性和隐私。

如果客户上传的订单截图被送进第三方模型，数据如何处理？如果一个工具调用错了退款接口，如何避免不可逆操作？如果高峰期响应慢了 3 秒，用户会等待还是转人工？

这些没有标准答案，只有取舍。工程基础的价值，不是让人比 Agent 多写几行代码，而是让人看见 Agent 看不见、也不会主动替你承担的代价。

3. 使用 Coding Agent：不是让它替你思考，而是让它进入闭环

Coding Agent 能很快搭出客服界面、接好 API、补齐测试的表面结构。它也可能在没有足够上下文时，做出一个看起来合理、实则危险的默认选择。

会用 Agent，远不止会写一段 Prompt。它意味着你知道该给什么上下文，什么时候先规划，什么时候直接执行；更意味着你能给它清晰的 verifier：哪些回答算正确，哪些调用绝不能发生，哪些失败必须自动暴露。

Agent 是执行的杠杆。没有规格、边界和验证，它放大的往往只是含糊。

4. Shaping the build：最难的工作在代码之前

前三项能力让系统能被可靠地做出来；第四项追问的是：它该不该这样被做出来？

当 Agent 越来越擅长交付一份明确的 spec，工程师的价值正从“把 spec 写成代码”，逐渐前移到“参与决定 spec 应该写什么”。

回到 AI 客服：也许真正的问题不是客服打字太慢，而是退款规则本身让用户反复追问；也许用户要的不是一个更会说话的机器人，而是一个能告诉他“这件事已经由谁、在什么时候处理”的确定性。

如果没有走到用户面前，没有理解业务目标和人的感受，再强的模型也只会把错误的问题实现得更快。

持续学习，不是追完每一条模型新闻

Andrew 在最后还提到了一项贯穿所有能力的底层心态：Continuous Learning。

这句话看起来最不“技术”，却可能是最难的一项。

因为 AI 变化太快了。模型在变，Coding Agent 的能力边界在变，工具的最佳实践也在变。两个月前还需要手工拆解的步骤，今天可能已经可以交给 Agent；今天看起来可靠的工作流，下一次模型升级后又可能需要重新设计。

所以，持续学习当然包括关注新模型、试用新工具、阅读好文章。但如果它只停在这些地方，我们又会回到开头那种“围观模型”的热闹里。

我更愿意把它理解成一种把真实反馈不断写回自己脑中的能力：

用一个真实问题做出最小可用的尝试；
看它在真实用户、真实数据和真实约束下怎样失败；
分析失败到底来自模型、上下文、流程、工程设计，还是自己一开始就理解错了需求；
把得到的判断更新进下一次的规格、提示、评估和系统边界；
再去尝试新的模型和工具，而不是把“新”本身当成收获。

这才是一种会越用越强的学习循环。

比如 AI 客服上线后，发现用户不断追问“我的退款到底什么时候到账”。这未必说明模型不够聪明。它也许暴露的是：系统没有接到订单状态、退款流程对用户不透明、客服话术没有说清责任人，或者我们一开始就把“效率”误解成了“少回复几句”。

一次这样的失败，往往比知道某个新模型多了几个 benchmark 分数更有价值。前者会改变你下一次怎么理解问题；后者未必会。

持续学习因此不是把知识库存得越来越满，而是让自己的判断在一次次真实交付中变得更准。它让工具进步不只发生在屏幕上，也发生在使用工具的人身上。

AI 提高了效率，但没有取消人的认知边界

这也是我从这张技能地图里读到的、更私人一点的理解。

AI 确实让我们以前所未有的速度做出页面、功能、原型，甚至一个像模像样的产品。它降低了表达想法的成本，也放大了动手实践的机会。

但它没有自动给我们产品判断，没有自动补齐软件工程的基本功，也不会替我们理解需求背后那个焦虑、愤怒、着急或无助的人。

你给 AI 的不只是 Prompt。你给它的还有：你对用户的理解、你识别风险的能力、你知道哪些地方该慢下来、以及你愿意对什么结果负责。

当然，反过来也成立：你没有看见的约束、没有问出的需求、没有验证的假设，也都会被它更快地编码进产品。

你是什么，你的 AI 就是什么。

每次让 AI 开工前，先问自己五个问题

如果这篇文章只留下一件可以立刻执行的事，我希望是下面这五问：

用户说出的需求，背后真正想解决的是什么？
AI 答错或做错一次，谁承担什么后果？
我用什么真实样本和标准，判断它真的有用？
哪些决策可以交给 AI，哪些必须由人负责？
我现在给 AI 的上下文，是否已经暴露了自己的认知盲区？

AI Coding 最好的时代，或许不是每个人都能更快地生成代码的时代。

而是每个愿意走进真实问题、持续校准自己判断的人，都能把自己的能力更大规模地交付给世界的时代。

参考资料

Andrew Ng, The AI Engineering Skills Map

苹果原生 Container来了：天下苦Docker Desktop久矣T_T

Tue, 30 Jun 2026 00:00:00 +0000

天下苦 Docker Desktop 久已。

启动慢、资源吃得多、风扇一转就像在提醒你“容器不是免费的”。更微妙的是，哪怕 Apple Silicon 已经强到离谱，很多本地容器体验依然像是从 Intel Mac 时代一路拖过来的包袱。

Colima、OrbStack、Rancher Desktop 这些方案当然缓解了不少问题。但苹果这次亲自下场，意义不一样：它不是又做了一个 Docker Desktop 平替，而是针对 Apple Silicon 和 macOS 虚拟化能力，重新算了一遍 Mac 本地容器的账本。

这件事为什么突然重要

AI Coding 火了以后，Mac 上的本地开发方式变了。

以前很多人开一个前端、一个后端、一个数据库，Docker Desktop 重一点也能忍；忍不了的人，就换 Colima 这类更轻的方案。现在不一样了：

过去的本地开发	AI Coding 之后的本地开发
跑 2-3 个服务	跑 Agent 后端、向量库、沙箱、队列、评测服务
偶尔 rebuild	频繁试错、频繁启动、频繁清理
人盯着终端	Agent 在后台连续跑任务
卡一下就喝口水	卡一下就是自动化链路断掉

所以大家对 Docker Desktop 的抱怨，不只是“它占内存”。

真正的问题是：当容器变成本地 AI 工作流的基础设施，容器工具本身就不能再像一个沉重的桌面 App，更不能长期停留在“能跑就行”的通用适配层。

原推文里提到 apple/container 上线后热度很高。这个判断没错。截至 2026-06-30，GitHub API 显示它已经有 45,143 Star，最新 release 是 1.0.0。

但更值得看的不是 Star，而是它的路线。

它不是“苹果牌 Docker Desktop”

苹果官方 README 对 container 的定位很直白：这是一个在 Mac 上创建和运行 Linux 容器的工具，使用轻量虚拟机，Swift 编写，并针对 Apple Silicon 优化。

听起来像 Docker Desktop？

表面像，底层思路不一样。

传统 Mac 容器方案大多是：先启动一个 Linux VM，再把多个容器塞进去。这很好理解，因为 Linux 容器终究需要 Linux 内核。

苹果这套更激进一点：每个容器一个轻量 VM。

这句话很关键。

它意味着苹果没有试图把 macOS 伪装成 Linux，也没有简单给 Docker Desktop 换个壳。它是在用 macOS 自己的 Virtualization、vmnet、XPC、launchd、Keychain、统一日志这些系统能力，重新搭一层容器运行环境。

一个粗略对比：

维度	Docker Desktop 常见体验	Apple container 路线
架构核心	一个共享 Linux VM 承载多个容器	每个容器一个轻量 VM
系统集成	跨平台桌面产品	深度绑定 macOS 能力
目标硬件	多平台	Apple Silicon 优先
镜像兼容	OCI/Docker 生态	OCI 兼容镜像
体验目标	通用、成熟、生态完整	轻、更系统化、更 Mac-native

这也是为什么它对 Mac 用户有吸引力：苹果不需要赢下所有平台，它只需要把 Mac 这台开发机上的容器体验做得足够顺。

真正的增量：不是命令兼容，而是资源边界更清楚

很多人第一反应会问：

1
2


docker run hello-world
container run hello-world

命令像不像？

当然重要，但这不是重点。

真正有意思的是，苹果把“容器隔离”重新拉回到 VM 级别，同时又尽量让它不像传统 VM 那么笨重。

官方技术概览里提到三个方向：

方向	它解决什么问题
Security	每个容器拥有接近完整 VM 的隔离属性
Privacy	只把必要的 host 数据挂载进对应 VM
Performance	比完整 VM 更轻，启动时间接近共享 VM 中的容器

这对 AI Coding 很现实。

Agent 会更频繁地拉依赖、跑脚本、启动服务、读写本地文件。你让它在一个又大又混的共享环境里跑，调试时经常会出现一种痛苦：到底是这个容器的问题，还是那个容器污染了环境？

每个容器一个轻量 VM，至少在设计上给了更干净的边界。

这不是免费午餐，但它是一个更适合自动化开发的方向。

但先别急着卸载 Docker Desktop

热度越高，越要泼一点冷水。

apple/container 目前更像是一个值得认真试用的系统级新工具，而不是你今天就能无脑迁移全部工作流的终局答案。

几个边界要看清楚：

问题	现实情况
系统要求	官方 README 写明需要 Apple Silicon，主要支持 macOS 26
安装方式	官方推荐从 GitHub release 下载签名 installer pkg，并启动 `container system start`
生态成熟度	Docker Desktop 仍有更完整的 GUI、Compose 生态、团队管理和跨平台一致性
迁移成本	复杂项目不只是 `run`，还有网络、卷、构建、CI、调试工具链
版本变化	1.0.0 已发布，但 release 里仍有不少 breaking CLI/API change 记录

也就是说，原推文里那种“苹果亲自把 Docker Desktop 饭碗砸了”的说法，很适合传播，但技术上要改一句：

苹果砸的不是 Docker Desktop 的饭碗，而是 Docker Desktop 在 Mac 上“理所当然必须常驻”的心理垄断。

这差别很大。

如果你是重度 Kubernetes、Compose、多团队协作用户，Docker Desktop 仍然很可能是更省事的选择。

如果你是本地 AI Agent、单机开发、轻量微服务、临时沙箱用户，container 值得试。

我会怎么试

我的建议不是“立刻迁移”，而是把它当成第二套本地容器运行环境来压测。

可以按这个顺序来：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 1. 从 GitHub release 安装签名 pkg 后启动系统服务
container system start

# 2. 跑一个最小镜像，确认基础链路
container run hello-world

# 3. 跑一个你最常用的开发镜像
container run --rm -it ubuntu:latest bash

# 4. 再测试真实项目里最容易出问题的三件事
# - 端口映射
# - volume 挂载
# - 私有 registry 登录

不要一开始就拿最复杂的项目开刀。

先拿一个你每天都会用、但出了问题不会影响工作的服务试。比如：

场景	适合程度
临时 Linux shell	很适合
单个 API 服务	适合
本地跑 AI Agent 后端	值得试
多服务 Compose 项目	先观望或小规模验证
团队标准化开发环境	等工具链更稳再说

如果它能让你的 Mac 少转几次风扇，少卡几次终端，少等几次 VM 启动，那它就已经有价值。

Takeaway

这件事的重点不是“苹果终于做 Docker 了”。

重点是：AI Coding 正在把本地开发机变成一台小型自动化服务器，而苹果开始给这台服务器补基础设施。

你可以这样判断要不要试：

你用 Apple Silicon Mac。
你经常本地跑容器。
你讨厌 Docker Desktop 常驻但暂时离不开容器。
你的工作流不是高度依赖 Docker Desktop GUI 和 Compose 生态。

满足三条，就值得花半小时测一下。

不满足，也不用焦虑。Docker Desktop 不是明天就没用，但它在 Mac 上的默认地位，确实第一次被苹果官方认真挑战了。

参考资料

Apple container GitHub 仓库：https://github.com/apple/container
Apple container 技术概览：https://github.com/apple/container/blob/main/docs/technical-overview.md
Apple container 1.0.0 release：https://github.com/apple/container/releases/tag/1.0.0

AI Coding on 鬼哥的空间

从 agent-skills 拆解：如何开发一套 Skill + Agents 项目脚手架

先分清三件事：怎么做、谁来做、何时组合

但别照抄三层：今天还需要“包装层”和“验证层”

第一步：从最小可运行骨架开始

第二步：把 Skill 写成有退出条件的工作流

第三步：让 Agent 只拥有一个视角

第四步：把编排写成“显式剧本”

第五步：为不同平台写薄适配，不复制核心

第六步：把 Markdown 当代码测试

一套可以直接执行的开发顺序

最后的检查表

参考资料

持续学习 - 读吴恩达老师的 AI Engineering Skills Map

我们太擅长围观模型，太少真正走进现场

一句“做个 AI 客服”，其实还没有开始定义问题

Andrew 的四项能力，恰好解释了差别从哪里开始

1. 构建与部署 AI 应用：把“不确定”当作系统属性

2. 软件工程基础：AI 不会替你做取舍

3. 使用 Coding Agent：不是让它替你思考，而是让它进入闭环

4. Shaping the build：最难的工作在代码之前

持续学习，不是追完每一条模型新闻

AI 提高了效率，但没有取消人的认知边界

每次让 AI 开工前，先问自己五个问题

参考资料

苹果原生 Container来了 ：天下苦Docker Desktop久矣T_T

这件事为什么突然重要

它不是“苹果牌 Docker Desktop”

真正的增量：不是命令兼容，而是资源边界更清楚

但先别急着卸载 Docker Desktop

我会怎么试

Takeaway

参考资料

苹果原生 Container来了：天下苦Docker Desktop久矣T_T