# 从辅助编码到 Agentic Coding：团队如何真正把 AI 编程用起来

## 1. 什么是 AI 编程 / Agentic Coding

AI 编程已经不是“补全几行代码”这么简单。

过去说 AI coding，更多是在 IDE 里做补全、解释代码、生成函数；现在说 **Agentic Coding**，指的是 AI 不只生成代码，而是可以围绕一个目标持续工作：读代码库、理解规范、拆解任务、修改文件、运行命令、执行测试、汇报结果，再等待人审核。

这和传统“问答式 AI”的差别在于：

- 它操作的对象不只是文本，而是**代码库、终端、测试、文档和任务流**。
- 它接收的输入不只是一个 prompt，而是**仓库上下文、团队规范、工具权限和执行边界**。
- 它输出的不只是代码片段，而是**一个可审查的过程和结果**。

OpenAI 在《Introducing Codex》中把 Codex 定义为能在独立云沙箱里并行处理任务的软件工程 agent，并明确强调仓库里的 `AGENTS.md` 可以告诉 agent 如何导航代码库、跑测试、遵循项目规范。Anthropic 在《Claude Code overview》里则把这类工具定义得更直接：它可以读代码、改文件、跑命令、接 MCP、记忆项目信息、用自定义命令和 hooks 执行团队工作流。

一句话说，**AI 编程的重点已经从“会不会写代码”变成“能不能在真实工程环境里稳定完成任务”**。

---

## 2. 现在主流工具长什么样

今天的 AI 编程工具，大致可以分成 4 类。

### 2.1 IDE 内联补全型

典型代表是 Cursor、GitHub Copilot、Windsurf 这类 IDE 内工具。

它们的强项是：

- 快，适合日常编码、补全、局部修改
- 几乎不打断心流
- 更像“增强版编辑器”

它们的短板也很明显：

- 更适合局部任务，不擅长长链路任务
- 上下文通常围绕当前文件或当前会话
- 对“多步骤执行”支持有限

### 2.2 终端 Agent 型

典型代表是 Codex CLI / App、Claude Code。

这类工具的特点是：

- 直接在终端或沙箱中工作
- 能跨多个文件和目录完成任务
- 能跑命令、测代码、查日志、生成变更
- 更接近“合作开发者”而不是“补全插件”

这也是现在 Agentic Coding 最值得关注的一条路线。

### 2.3 多 Agent / 异步协作型

OpenAI 在《Introducing the Codex app》里把 Codex app 定义成一个“agent command center”。

这一类工具的核心不是单次生成，而是：

- 多 agent 并行
- worktree / 隔离副本
- 长任务异步运行
- review queue
- automations 定时执行

这意味着团队开始从“我和一个 AI 对话”进入“我在调度一组 agent 干活”。

### 2.4 企业流程接入型

真正成熟的落地，不会停留在 IDE 或终端本身，而会继续往下接：

- issue / ticket
- design
- docs
- CI
- release
- review

OpenAI 的《How OpenAI uses Codex》和 Anthropic 的 Claude Code 文档都在强调同一件事：**AI 编程不是一个孤立工具，而是一个接进研发流程的执行节点。**

---

## 3. 为什么“上下文工程”比模型参数更重要

如果说模型决定上限，那么上下文工程决定下限。

同一个 agent，在没有规范、没有边界、没有工具约束的仓库里，常常只能给出“像是对的”结果；一旦把团队规则、常见命令、外部依赖和重复流程固化好，它的稳定性会明显提升。

这也是为什么我更建议团队优先建设：

1. `AGENTS.md`
2. `Skill`
3. MCP

不是反过来。

### 3.1 `AGENTS.md` 是最基础的持久上下文

`AGENTS.md` 的价值，在于它把“每次都要重新说一遍的话”固化到仓库里。

最适合放进去的内容包括：

- 仓库结构怎么理解
- 哪些目录能改，哪些不要碰
- 跑测试和构建的标准命令
- 代码风格、提交规范、评审要求
- 哪些历史坑和业务约束不能靠读代码推断

OpenAI 在《Introducing Codex》和《How OpenAI uses Codex》里都明确强调了 `AGENTS.md` 的作用：它能给 agent 持续、稳定、跨任务的仓库上下文。

对团队来说，`AGENTS.md` 解决的是**统一口径**问题。

### 3.2 为什么我更推荐团队优先用 Skill

OpenAI 在《Introducing the Codex app》里对 skill 的定义非常清楚：**skills bundle instructions, resources, and scripts**。也就是说，skill 不是一句 prompt，而是一套可复用、可执行、可共享的工作单元。

我更推荐 Skill 而不是把 MCP 当默认答案，核心原因有 5 个。

#### 1. Skill 更适合沉淀团队方法

团队真正要复用的，往往不是“连上某个系统”，而是：

- 怎么做 code review
- 怎么写 changelog
- 怎么同步接口文档
- 怎么排查线上问题
- 怎么做发布前检查

这些本质上是**方法、步骤、约束和脚本**，而不是“外部系统连接协议”。

Skill 正好适合承载这些内容。

#### 2. Skill 更容易版本化和审查

Skill 可以直接放进仓库，跟代码一起评审、迭代、回滚。

这对团队非常重要，因为它意味着：

- 变更可追踪
- 规则可审查
- 经验可继承
- 新成员可复用

OpenAI 也明确写到，skills 可以在 app、CLI、IDE extension 之间复用，也可以 check in 到仓库里供团队共享。

#### 3. Skill 的权限面通常更小

大部分 Skill 的核心是：

- 指令
- 本地资源
- 已知脚本
- 固定工作流

相比之下，MCP 经常意味着：

- 额外 server
- 远程连接
- 外部认证
- 实时数据访问
- 可执行工具调用

对团队治理来说，Skill 通常更容易做权限收敛和风险控制。

#### 4. Skill 的复现性更强

Skill 更像“标准作业程序”。

只要输入条件差不多，输出路径通常也比较稳定。它更容易形成：

- 项目 onboarding skill
- 发布检查 skill
- API 文档同步 skill
- 故障排查 skill

这类资产的价值，远高于一次性的 prompt。

#### 5. Skill 更适合先落地，再扩展

很多团队一上来就谈 MCP，最后会卡在：

- server 怎么部署
- 认证怎么管
- 数据怎么授权
- 哪些 tool 可以执行
- 审计怎么做
- 出问题怎么排查

而 Skill 的起步门槛低得多。先把高频流程做成 Skill，团队就已经能吃到 70% 的收益。

### 3.3 MCP 是什么，它有用，但不是默认答案

MCP 官方规范定义得很清楚：它是一个 **host / client / server** 架构、基于 JSON-RPC 的上下文与工具交换协议。它提供的核心原语包括：

- resources
- prompts
- tools
- sampling

所以，**MCP 更像“协议层”和“接入层”**，而不是团队方法论。

它当然有用，尤其适合这些场景：

- 读取 Figma、Google Drive、Jira、Slack、Linear 等外部系统
- 把 AI 接到实时数据源
- 暴露明确的工具调用接口
- 在多个 agent / host 之间做统一接入

但它也有天然缺点。

### 3.4 MCP 的几个现实问题

下面这些判断是我基于 MCP 官方规范、OpenAI / Anthropic 文档和真实团队落地经验做的归纳。

#### 1. MCP 解决的是“连接”，不是“方法”

MCP 能告诉 agent 怎么拿资源、怎么调工具，但不会告诉团队：

- review 怎么做
- 代码规范怎么执行
- 哪些命令该跑
- 哪些步骤必须人工确认

这些还是要靠 `AGENTS.md` 和 Skill 来补。

#### 2. MCP 的治理成本更高

一旦引入 MCP，你引入的就不只是一个“能力”，而是一整套额外复杂度：

- host / client / server 关系
- 能力协商
- 认证与权限
- 服务可用性
- 调用失败与重试
- 审计与追责

对于很多团队来说，这一层复杂度并不划算。

#### 3. MCP 的安全面更大

MCP 常常连接的是外部系统和可执行工具。

这意味着你要额外考虑：

- 哪些数据能暴露给 server
- 哪些工具可以被调用
- 远程 server 是否可信
- 网络访问怎么限制
- prompt injection 后会不会放大影响面

MCP 官方规范自己也强调了 user consent、data privacy、host 侧的安全边界。换句话说，规范本身已经默认这是一个高风险面。

#### 4. MCP 不适合承载项目内隐性规则

项目里最关键的东西，往往不是 Jira ticket、Figma 设计稿，而是那些“只有团队自己知道”的约束：

- 某个模块的历史包袱
- 某个目录不能动
- 某个字段不能改
- 某套测试必须跑
- 某类问题要先查哪几个日志

这些更适合写进 `AGENTS.md` 和 Skill，而不是塞进 MCP server。

### 3.5 一个更实用的优先级

如果目标是团队落地，我建议优先级是：

1. 先写好 `AGENTS.md`
2. 把高频流程做成 Skill
3. 只有在确实需要实时外部系统时，再接 MCP

也就是说：

- `AGENTS.md` 解决“这项目该怎么干”
- Skill 解决“这件事该怎么反复稳定地干”
- MCP 解决“这件事需要连到外部系统去干”

这个顺序更稳，也更适合团队推广。

### 3.6 原理：模型怎么知道什么时候用 MCP、Skill、`CLAUDE.md`、`AGENTS.md`

这部分是最容易被讲虚的地方。

很多分享会把这些东西都混在一起，说成“都是给模型喂上下文”。这不够准确。它们的原理、触发方式、控制权，其实完全不同。

先给一个最重要的判断：

| 机制 | 本质 | 谁控制触发 | 什么时候进入上下文 |
|------|------|------------|--------------------|
| `AGENTS.md` | 仓库级持久说明书 | agent / 宿主在任务开始时读取 | 通常在 repo 任务启动时作为持久上下文 |
| `CLAUDE.md` | 项目 / 用户 / 组织级持久说明书 | Claude Code 启动和读目录时加载 | 启动即加载；子目录规则按需加载 |
| Skill | 可复用工作流包 | 模型根据描述匹配，或用户显式指定 | 先只加载元数据，命中后再加载正文和资源 |
| MCP Prompts | 模板化 prompt | 用户控制 | 用户选中或执行时进入 |
| MCP Resources | 外部资源引用 | 宿主 / 应用控制，也可用户显式引用 | 被附加或引用时进入 |
| MCP Tools | 外部工具调用接口 | 模型控制，但宿主负责权限 | 模型决定调用时才执行 |

### 3.7 MCP 的原理是什么

MCP 不是“一个插件”，而是一套协议。

官方规范把它定义成 **host / client / server** 架构：

- host 负责协调、授权、执行安全策略
- client 代表 host 连接某一个 server
- server 暴露 prompts、resources、tools 等能力

MCP 的基础通信是 JSON-RPC。标准 lifecycle 很明确：

1. 先 `initialize`
2. 做 capability negotiation
3. 再进入正常 operation

也就是说，**模型不是一上来就“知道一切工具”**。先是宿主把可用能力谈判清楚，后面模型和应用才在这个边界里工作。

### 3.8 MCP 到底是怎么触发的

这里要分 3 类看，官方规范写得很清楚：

- Prompts 是 **user-controlled**
- Resources 是 **application-controlled**
- Tools 是 **model-controlled**

这 3 类东西看起来都像“能力”，但触发机制完全不同。

#### 3.8.1 MCP Prompts：用户触发

MCP prompt 更像一个可复用的模板命令。

它通常在这些时机触发：

- 用户从菜单里选
- 用户执行 slash command
- 用户显式调用某个 prompt 模板

所以 prompt 不是模型自己偷偷用的，而是**用户选了，宿主再把模板展开给模型**。

#### 3.8.2 MCP Resources：应用或用户引用时触发

Resource 是上下文，不是动作。

它的典型触发方式有两类：

- 宿主自动附加
- 用户显式引用

Anthropic 的 Claude Code 文档给了很具体的例子：MCP resource 可以像文件一样用 `@server:protocol://path` 引用；一旦引用，资源会被自动拉取并作为 attachment 放进上下文。

所以 resource 的本质不是“让模型去执行”，而是**把外部内容喂给模型看**。

#### 3.8.3 MCP Tools：模型决定是否调用

Tool 才是真正最接近“agent 在外部世界动手”的那一层。

根据 MCP 官方规范，tool 是 **model-controlled**。也就是：

- 宿主先把可调用工具暴露出来
- 模型在推理过程中判断是否需要用
- 真正执行前后仍然由宿主负责权限、隔离、确认和日志

所以“模型怎么触发 MCP”这句话，严格说只对 tools 部分成立；对于 prompts 和 resources，并不是同一种触发逻辑。

### 3.9 Skill 的原理是什么

Skill 不是外部连接协议，而是**可加载的工作流包**。

OpenAI 在《Introducing the Codex app》里给的定义是：skills bundle instructions, resources, and scripts。Anthropic 的 Agent Skills 文档则把原理讲得更细：Skill 是 VM / 文件系统里的目录，里面放 `SKILL.md`、脚本、参考资料，Claude 通过 progressive disclosure 分阶段加载。

这件事非常关键，因为它解释了为什么 Skill 更适合团队落地。

Skill 的本质不是“把外部系统接进来”，而是：

- 把团队方法包装起来
- 把说明、资源、脚本放到同一个单元
- 让模型在需要时再加载，而不是一直占上下文

### 3.10 Skill 是怎么触发的

#### 3.10.1 OpenAI / Codex 的公开口径

截至 **2026 年 2 月 2 日** 的 OpenAI《Introducing the Codex app》，官方公开说法是：

- 你可以**显式要求** Codex 使用某个 skill
- 也可以让它**根据当前任务自动使用**

OpenAI 公开资料目前没有像 Anthropic 那样，把内部加载分层机制写到很细。基于公开信息，比较稳妥的理解是：

- skill 至少有“可发现的描述信息”
- agent 会根据任务语义做 skill 路由
- 命中后再使用这个 skill 里的 instructions / resources / scripts

这里最后两点是**基于公开行为的推断**，不是 OpenAI 目前公开文档逐条写死的实现细节。

#### 3.10.2 Anthropic / Claude 的公开口径

Anthropic 这一块公开得更细。

官方文档把 Skill 的触发写成了三层：

1. **Metadata** 常驻加载  
   `name` 和 `description` 在启动时进入系统提示，用来做发现和匹配。
2. **SKILL.md 正文** 在触发时加载  
   当用户请求和 skill 描述匹配时，Claude 才会去读 `SKILL.md`。
3. **附加资源和脚本** 按需加载  
   只有在正文里引用到额外文档或脚本时，Claude 才会继续读或执行。

这就是典型的 progressive disclosure。

所以，Skill 的触发不是“整个 skill 包永远都进上下文”，而是：

- 先知道“有哪些 skill”
- 再判断“当前任务像不像这个 skill”
- 命中后才读说明书
- 需要更多材料时再继续展开

这也是 Skill 比“大段系统提示”更高效的根本原因。

### 3.11 `CLAUDE.md` 是干嘛的，什么时候会用到

`CLAUDE.md` 不是命令，也不是插件，它是 **Claude Code 的持久指令文件**。

Anthropic 官方文档写得非常直接：

- `CLAUDE.md` 用来给 Claude 持续说明项目规则、工作流、架构信息
- Claude 在**每次 session 开始时**读取
- 上层目录的 `CLAUDE.md` 会在启动时整份加载
- 子目录里的 `CLAUDE.md` 会在 Claude 读到对应目录文件时按需加载

更重要的是，Anthropic 还把它和 auto memory 区分开了：

- `CLAUDE.md` 是你写的 instructions and rules
- auto memory 是 Claude 自己积累的 learnings and patterns

也就是说，`CLAUDE.md` 的原理不是“记忆库”，而是**你手工维护的、可审查的、跨 session 生效的系统化说明书**。

如果要问“什么时候大模型会用到 `CLAUDE.md`”，最准确的答案是：

- 会话启动时就用到
- 进入特定目录 / 读取特定文件时会继续加载更细粒度的规则
- 它不是等模型临时想到才去找，而是 Claude Code 的上下文装载机制本身就会处理它

Anthropic 还补了一层 `.claude/rules/`：

- 无路径限制的规则，启动就加载
- 带 `paths` 的规则，只在匹配文件被读取时触发
- 官方甚至明确写了：如果是“任务型、不是常驻型”的说明，应优先用 Skill，不要全塞进常驻 rules

这点很值得抄。

### 3.12 `AGENTS.md` 是干嘛的，什么时候会用到

先纠正一个名字。

截至 **2025 年 5 月 16 日** OpenAI《Introducing Codex》和 **2025 年 10 月** 的《How OpenAI uses Codex》公开资料，OpenAI 官方用的名字是 **`AGENTS.md`**，不是 `agent.md`。

`AGENTS.md` 在 Codex 体系里的作用，和 `CLAUDE.md` 非常接近，但公开细节没有 Anthropic 那么细。

OpenAI 官方已经明确公开的点有两个：

- `AGENTS.md` 可以告诉 Codex 如何导航代码库、跑哪些测试、遵循哪些项目规范
- 它能给 Codex 提供 **persistent context**

这说明它本质上也是一种**仓库级持久说明文件**。

不过要注意，OpenAI 公开资料目前没有像 Anthropic 那样把“加载顺序、子目录按需加载、路径规则触发”写得那么明确。

因此，更稳妥的结论是：

- `AGENTS.md` 会在 Codex 处理 repo 任务时作为持续上下文被参考
- 它适合放项目规范、命令、边界、架构提示
- 它不是“外部工具触发器”，也不是“只有问到时才临时加载的知识块”

如果再往前一步说“Codex 一定在什么时候加载 `AGENTS.md`、一定按什么顺序合并”，那就已经超出目前公开资料了。这部分只能做**实现层推断**，不适合写成确定性结论。

### 3.13 一句话讲透这 4 种机制

如果要在分享里一句话区分它们，我建议这样讲：

- `AGENTS.md` / `CLAUDE.md`：仓库或项目的**长期说明书**
- Skill：按任务触发的**工作流包**
- MCP Resource：外部系统的**可引用上下文**
- MCP Tool：模型在边界内可调用的**动作接口**

只要把这四类分清，很多“AI 编程为什么有时候很强、有时候很笨”的现象就都能解释通。

---

## 4. 安全、沙箱、权限控制怎么做

AI 编程不能只讲效率，必须讲边界。

因为一旦 agent 能读文件、改代码、跑命令、联网，它的风险模型就已经和普通聊天机器人完全不一样了。

Anthropic 在《Making Claude Code more secure and autonomous with sandboxing》里讲得很清楚：真正关键的是两层隔离。

- 文件系统隔离
- 网络隔离

只有同时具备这两层，才谈得上“更安全地让 agent 自主执行”。

OpenAI 在《Introducing the Codex app》里也给了类似方向：默认只允许 agent 编辑工作目录内文件，默认网络受限，超出边界的命令再请求授权。

团队落地时，我建议至少做到下面几条。

### 4.1 默认最小权限

起步建议是：

- 默认只读
- 默认只允许当前工作目录
- 默认禁网或只允许缓存搜索
- 默认不允许高风险命令

不要一开始就给 agent 全盘读写和随意联网。

### 4.2 文件系统边界要清楚

最基本的限制应该包括：

- 只允许改当前 repo 或当前 worktree
- 禁止访问敏感目录
- 禁止碰 SSH key、签名密钥、全局配置
- 把产物目录、缓存目录、临时目录单独约束

### 4.3 网络权限要白名单化

如果 agent 要联网，建议只开放明确域名：

- 文档站
- 包仓库
- 指定 API
- 指定内部服务

不要给“任意出网”。

### 4.4 任何越权都必须可见

理想状态不是“绝对不出错”，而是：

- 它一旦越界就会被拦下
- 它的每一步都有日志
- 它跑过哪些命令可追踪
- 它看过哪些输出可回看

这比单纯“信任模型”更重要。

### 4.5 把高风险动作留给人

下面这些动作，建议默认保留人工确认：

- 推送远程分支
- 修改生产配置
- 删除大量文件
- 执行数据库变更
- 调用真实线上写接口
- 访问敏感业务数据

Agent 可以准备动作，但最后一步最好别自动做。

---

## 5. 怎么衡量效果，不只看演示

AI 编程最容易误导团队的地方，就是 demo 看起来都很强。

但真正要回答的问题不是“它能不能做出一个例子”，而是：

- 它能不能稳定处理真实任务
- 它能不能在团队环境里复现
- 它引入的返工和审查成本是多少
- 它到底是提效，还是把成本后移

### 5.1 外部 benchmark 能看什么

SWE-bench 是目前最值得引用的公开基准之一。

它的价值在于：

- 用的是真实 GitHub issue
- 有可复现的 Docker 评测环境
- 看的是“能不能真正解决问题并通过测试”
- 不只是比谁会生成一段像样的代码

这类 benchmark 很适合拿来解释：**为什么评估 AI 编程不能只看演示视频和单次样例。**

### 5.2 但团队不能只看 benchmark

SWE-bench 解决的是“模型 / agent 在公开任务上的能力比较”，不等于“你们团队已经能提效”。

团队真正该看的，是自己的内部指标。

### 5.3 更应该追踪的 8 个指标

我更建议团队跟下面这些指标：

| 指标 | 要回答的问题 |
|------|--------------|
| 首个可用 patch 时间 | agent 多快能给出第一版能审的结果 |
| 任务完成率 | 给定任务最后到底有没有做完 |
| 一次合并率 | 首轮产出离可合并还有多远 |
| 人工返工时长 | 人为了把结果修到可交付，额外花了多久 |
| 测试通过率 | agent 是否会主动补测试、跑测试、修失败 |
| 评审驳回率 | 代码质量、规范、边界处理是否稳定 |
| 文档同步率 | 改代码之后文档、变更记录、接口说明是否跟上 |
| 安全越权次数 | agent 有多少次尝试越过权限边界 |

这些指标比“生成速度很快”“看起来很聪明”有用得多。

### 5.4 一个简单的评估分层

我建议把 AI 编程评估分成三层：

#### 第一层：公开 benchmark

看模型和 agent 的通用上限，比如 SWE-bench。

#### 第二层：团队标准任务集

自己做一组固定任务，比如：

- 修一个真实 bug
- 新增一个接口字段并同步文档
- 补一组测试
- 做一次重构
- 处理一次线上告警

这层最关键。

#### 第三层：真实研发指标

最终看：

- 交付周期有没有缩短
- 返工率有没有下降
- 线上事故有没有增加
- 文档和流程有没有更完整

只有第三层改善了，AI 编程才算真的落地。

---

## 6. 团队落地建议：先 Skill，后 MCP

如果让我给团队一个非常务实的落地顺序，我会建议这样做。

### 第一步：先把 `AGENTS.md` 写对

至少写清楚：

- 项目结构
- 核心命令
- 测试和构建方式
- 不可触碰的边界
- 提交和评审要求

### 第二步：把高频任务做成 Skill

最值得优先做成 Skill 的通常是：

- code review
- changelog 生成
- 发布检查
- API 文档同步
- 问题排查
- 新成员 onboarding

### 第三步：只把“必须连外部系统”的能力接 MCP

比如：

- Figma
- Jira / Linear
- 文档库
- 只读数据系统

不要把所有东西都往 MCP 上堆。

### 第四步：最后才谈自动化和多 agent

当 `AGENTS.md`、Skill、安全边界、评估方法都比较稳了，再上：

- automations
- multi-agent
- 长任务异步执行
- 定时巡检

这个顺序会比“先接一堆工具再慢慢补治理”靠谱得多。

---

## 7. 一个适合分享的核心结论

如果这次分享只留 4 句话，我建议讲这 4 句：

1. AI 编程已经从“补全代码”进入“Agentic Coding”，重点是能不能在真实工程环境里完成任务。
2. 团队落地的关键不是模型参数，而是上下文工程，尤其是 `AGENTS.md` 和 Skill。
3. MCP 很有用，但它更适合做外部系统接入，不应该替代团队方法论；默认优先级应该是 `AGENTS.md` > Skill > MCP。
4. 评价 AI 编程不能只看 demo，要看沙箱、安全边界、真实任务完成率和长期研发指标。

---

## 附录：核心参考材料

### 最值得消化的 5 份

- [OpenAI《Introducing Codex》](https://openai.com/index/introducing-codex/)
- [OpenAI PDF《How OpenAI uses Codex》](https://cdn.openai.com/pdf/6a2631dc-783e-479b-b1a4-af0cfbd38630/how-openai-uses-codex.pdf)
- [Anthropic《Claude Code overview》](https://code.claude.com/docs/en/overview)
- [MCP 官方规范](https://modelcontextprotocol.io/specification/2024-11-05/index)
- [SWE-bench 官方 Overview](https://www.swebench.com/SWE-bench/)

### 适合补充的材料

- [OpenAI《Introducing the Codex app》](https://openai.com/index/introducing-the-codex-app/)
- [Anthropic《How Claude remembers your project》](https://code.claude.com/docs/en/memory)
- [Anthropic《Agent Skills Overview》](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview)
- [Anthropic《Making Claude Code more secure and autonomous with sandboxing》](https://www.anthropic.com/engineering/claude-code-sandboxing)
- [MCP Architecture](https://modelcontextprotocol.io/specification/2024-11-05/architecture/index)
- [MCP Server Features Overview](https://modelcontextprotocol.io/specification/2024-11-05/server)
- [OpenAI《Codex is now generally available》](https://openai.com/index/codex-now-generally-available/)
- [OpenAI《Introducing upgrades to Codex》](https://openai.com/index/introducing-upgrades-to-codex/)

### 二级参考层：演讲、分享、经验材料怎么引入

这类资料很有价值，但用法要分清。

我的建议是把材料分成两层：

- **一级材料**：官方文档、官方博客、官方规范  
  用来定义“事实层”和“机制层”。
- **二级材料**：个人演讲、经验分享、第三方解读  
  用来补“讲法层”“案例层”“视角层”和“争议点”。

也就是说：

- 原理、定义、触发时机，优先引用 OpenAI / Anthropic / MCP 官方材料
- 案例、经验、选题角度、分享节奏，可以引用下面这些二手资料
- 如果二手资料里出现强事实判断，最好回到一级材料核一下再写进正文

### Geoffrey Challen《A Day With Claude: Using and Teaching Coding Agents》

- 链接：[Geoffrey Challen《A Day With Claude: Using and Teaching Coding Agents》](https://www.geoffreychallen.com/talks/2026-01-15-a-day-with-claude-using-and-teaching-coding-agents)
- 适合放的位置：
  `什么是 Agentic Coding`、`团队工作方式怎么变`、`教育和组织怎么适应`
- 适合引用的点：
  他这份材料像一场完整 keynote，节奏很成熟。它不是单纯讲工具，而是把“Plan -> approve -> agent 实施 -> 用测试验证”的新工作方式讲成一条完整故事线。
- 可以借鉴的内容：
  - 用“一天的工作流”讲 agentic coding，而不是一上来堆定义
  - 强调“从迭代实现，变成迭代计划”
  - 强调测试不是附属品，而是 agent loop 的 secret weapon
  - 强调组织和教育系统必须适配这种新工作方式
- 写入文档时建议：
  这份更适合放在“趋势与工作方式变化”章节，作为经验案例，不要把他的个人使用数据直接当行业普遍结论。

### Claude Code Anonymous《Agentic Coding: Real Talk from the Trenches》

- 链接：[Claude Code Anonymous《Agentic Coding: Real Talk from the Trenches》](https://plattenschieber.github.io/agent-presentation/)
- 适合放的位置：
  `选题角度库`、`常见误区`、`经验型分享素材`
- 适合引用的点：
  这不是一份材料，而是一整组 presentation collection。它的价值主要不在于“给你一条权威结论”，而在于帮你找“别人都从什么角度讲 agentic coding”。
- 可以借鉴的内容：
  - 标题包装方式
  - 经验型 talk 的切口
  - 哪些话题容易引发共鸣
  - 哪些概念适合单独拆出来做一页
- 写入文档时建议：
  不需要在正文里大量引用，可以单独建一个“分享选题参考池”小节，作为你们后续整理素材时的灵感来源。

### Mitsuhiko《Agentic Coding: The Future of Software Development with Agents》

- 链接：[Mitsuhiko《Agentic Coding: The Future of Software Development with Agents》](https://speakerdeck.com/mitsuhiko/agentic-coding-the-future-of-software-development-with-agents)
- 适合放的位置：
  `总览部分`、`为什么 agentic coding 突然起来了`、`工具全景`
- 适合引用的点：
  这份很适合拿来做总览视角。它对 agentic coding 的定义比较清楚，也明确讨论了工具、workflow、observability 和 context conservation。
- 可以借鉴的内容：
  - 把 agentic coding 定义成“AI 不只是建议代码，而是参与 planning / implementing / refining 的软件开发过程”
  - 强调工具和 workflow 设计原则
  - 明确提出“太多 MCP 会更快造成 context rot”，并建议对 coding agents 谨慎使用 MCP
- 写入文档时建议：
  这份非常适合用来加强我们现在“Skill 优先、MCP 补充位”的论证。它不是官方规范，但它提供了很强的实战观点支撑。

### hiromitsusasaki《The World Has Changed》

- 链接：[hiromitsusasaki《The World Has Changed》](https://speakerdeck.com/hiromitsusasaki/world-has-changed)
- 适合放的位置：
  `行业总览`、`Plan 模式 / Spec-driven development`、`生态变化`
- 适合引用的点：
  这份材料很新，也很贴近你要讲的方向。它把 spec-driven development、Plan 模式普及、Kiro / Claude Code / Copilot / Cursor 这些生态变化串在一起了。
- 可以借鉴的内容：
  - “先 plan、后 coding”正在成为主流交互模式
  - spec-driven development 可以作为 agentic coding 的上层方法论
  - 工具生态已经从单点补全进入“多工具并存 + 工作流分层”的阶段
- 写入文档时建议：
  很适合放在“为什么现在突然火”和“工作方式正在怎么变”这两节，帮助把视角拉高。

### Gota《CodexでもAgent Skillsを使いたい》

- 链接：[Gota《CodexでもAgent Skillsを使いたい》](https://speakerdeck.com/gotalab555/codexdemoagent-skillswoshi-itai)
- 适合放的位置：
  `Skill vs MCP`、`怎么把 Skill 思路迁移到 Codex`、`上下文工程`
- 适合引用的点：
  这份和我们文档现在的主线高度一致。它明确在讲：
  - MCP server 读入会吃掉不少 token
  - MCP 接太多会降低工具选择精度
  - Skill 可以做分层加载
  - 可以借助 `AGENTS.md` 让 Codex 识别并自主选择技能
- 可以借鉴的内容：
  - 用 L1 元数据 / L2 `SKILL.md` / L3 脚本 的结构讲 Skill
  - 说明为什么 coding agent 更适合 Bash / Shell + Skill，而不适合无限堆 MCP
  - 说明 `AGENTS.md` 可以承担“让 Codex 知道有哪些技能可选”的角色
- 写入文档时建议：
  这份应该重点吸收，尤其适合补到我们现有“Skill 为什么比 MCP 更适合团队”这一节。

### Sunagaku《Codexを使い倒して気づいた、Claude Codeの本当の強みと使いこなし术》

- 链接：[Sunagaku《Codexを使い倒して気づいた、Claude Codeの本当の強みと使いこなし術》](https://speakerdeck.com/sunagaku/codexwoshi-idao-siteqi-tuita-claude-codenoben-dang-noqiang-mitoshi-ikonasishu)
- 适合放的位置：
  `实战技巧`、`多 agent / review agent`、`工具对比`
- 适合引用的点：
  这类材料最大的价值不是给定义，而是帮你把“怎么真正用起来”讲得更接地气。
- 可以借鉴的内容：
  - 怎么讲 Codex 和 Claude Code 的差异
  - 怎么讲 subagent / review agent 这类实战玩法
  - 怎么把经验讲成“可照抄”的 workflow
- 写入文档时建议：
  更适合放在后半段的“使用技巧 / 实战经验”部分，而不是前面的原理章节。

### PromptLayer《Watch my AI Engineering talk: How Claude Code Works》

- 链接：[PromptLayer《Watch my AI Engineering talk: How Claude Code Works》](https://blog.promptlayer.com/watch-my-ai-engineering-talk/)
- 适合放的位置：
  `agent loop 原理`、`为什么 Bash 很重要`、`为什么 subagent 有效`
- 适合引用的点：
  这份更偏“原理拆解”。它强调的几件事非常值得吸收：
  - `CLAUDE.md` 本质上就是一个可编辑的 markdown 说明文件
  - Bash 是 coding agent 的 universal adapter
  - subagent 的价值在于把子任务隔离到独立上下文窗口，避免主上下文被污染
- 写入文档时建议：
  很适合补在“Skill / 上下文工程 / agent loop”附近，用来解释“为什么简单工具组合反而有效”。

### 这些二手资料，怎么和当前文档衔接

我建议这样引入：

1. 在“什么是 Agentic Coding”里，补 Geoffrey 和 Mitsuhiko  
   用来增强总览和工作方式转变的叙事。
2. 在“Skill / MCP / AGENTS.md / CLAUDE.md 原理”里，补 Gota 和 PromptLayer  
   用来增强 Skill 分层加载、Bash、subagent、MCP 局限这些观点。
3. 在“为什么现在火”和“行业变化”里，补 hiromitsusasaki  
   用来连接 spec-driven development、Plan 模式和生态变化。
4. 在“实战技巧”或未来的“经验篇”里，补 Sunagaku 和 Claude Code Anonymous  
   用来丰富案例、标题角度和实操经验。

### 当前阶段的使用原则

现阶段我建议你们在正文里保持这个原则：

- **机制、定义、触发方式**：优先用官方来源
- **经验、讲法、实战观点**：再用这些分享材料补充
- **有争议的判断**：明确标成“实践观点”而不是“协议事实”