Spec / Skill / Memory 工作台三件套

Spec 管当前任务，Skill 管重复流程，Memory 管长期经验，AGENTS.md 管项目规则。新手不要一开始就把所有东西都写成 Skill 或 Memory，先用 spec 控制一次任务，复盘后再决定沉淀到哪里。

一句话区分

名称	管什么	例子
Spec	当前任务	这次只改 `index.html` 和 `css/app.css`
AGENTS.md	项目规则	本项目不允许新增依赖，测试命令是 `pnpm test`
Memory	长期经验	新手教程先用小任务，不从复杂 issue 开始
Skill	重复流程	小功能修改前先只读摸底、生成任务卡、看 diff

一个贯穿案例

目标：

给一个小型网页项目增加一个“练习项目”提示，并验证页面可见。

适合写进 spec：

# 小功能修改 spec

## 目标

在首页增加一行轻量提示文案：这是 Codex 练习项目。

## 范围

- 允许修改 `index.html`
- 如有必要，允许修改 `css/app.css`
- 不允许新增依赖
- 不允许修改 `package.json`
- 不允许改 Git 配置

## 验收

- 页面打开后能看到提示文案
- diff 只包含允许范围内的文件
- Codex 输出验证方式和回退方式

Spec 适合当前任务，因为它描述的是“这一次要交付什么”。

执行后怎么复盘

复制给 Codex：

请复盘这次任务。

只输出三类内容：
1. 下次做同类任务时仍然有用的流程
2. 只属于当前项目的规则
3. 不应该长期保存的信息

判断写到哪里

内容	放哪里
当前任务目标、文件范围、验收标准	Spec
项目长期规则	AGENTS.md
反复出现的个人工作方式	Memory
可复用的完整流程	Skill
当前页面的具体文案	不长期保存
临时错误日志	不长期保存

什么时候做 Skill

不要第一次成功就做 Skill。满足三条再做：

同类任务做过至少 2-3 次。
步骤稳定。
每次都能减少解释成本或减少跑偏。

Skill 草稿可以这样开头：

---
name: small-feature-change
description: Use when making a small, low-risk feature change in an existing project after a read-only scan and task card.
---

# Small Feature Change

先只读摸底，再生成任务卡。用户确认后，只改 1-3 个文件。改完必须输出 diff 摘要、验证方式和回退方式。

AGENTS.md 与 Memory 冲突时

优先级建议：

用户当前明确要求。
仓库内 AGENTS.md。
项目 spec。
Skill。
Memory。

原因：AGENTS.md 更贴近当前仓库，Memory 适合长期偏好，不适合覆盖项目规则。

来源与日期

访问日期：2026-06-17。Codex Memory、Skill 和配置行为发布前需要重新复核。