AI编程的下一步：不是更强的提示词，而是更好的工作流程
AI编程的下一步：不是更强的提示词，而是更好的工作流程
——Matt Skills 如何解决AI编程中的上下文失控
摘要
本文介绍Matt Skills体系如何通过一套工程化的工作流程，解决AI编程中的上下文失控问题。核心观点是：先把上下文做扎实，再让智能代理动手。
第一章：问题与解法概述
1.1 AI写得很快，为什么项目还是容易失控？
很多人使用AI编程时，习惯从一句"帮我实现这个功能"开始。
代码虽然生成得很快，方向却容易逐渐跑偏；随着对话变长，上下文窗口（Context Window）被占满，自动压缩、令牌消耗（Token）和模型幻觉也随之增加。更换会话（Session）或模型（Model）后，还需要重新解释背景。
常见问题包括：
- 需求不清楚，智能代理（Agent）只能自行补充假设
- 代码生成很快，但实现方向逐渐偏离
- 重要信息散落在聊天记录中
- 上下文窗口被占满后触发自动压缩
- 模型开始遗忘信息，甚至产生幻觉
- 更换会话、模型或智能代理后，无法顺利交接
Matt的解法不是写一个更强的提示词（Prompt），而是把AI编程变成一条可以重复执行的工程流水线（Workflow）。
先把上下文做扎实，再让智能代理动手。
1.2 一套完整的AI编程工作流程
下图直观展示了完整的工作流程：
从需求澄清、规格生成、任务拆分，到功能实现和独立审查，每个阶段都会将关键信息沉淀为可复用的项目上下文。
前置准备：统一技能（Skills）与运行环境（Setup）
这张图是本文的主线。我们首先把需求问清楚，然后形成需求规格说明，再拆分成可独立执行的任务。接着由智能代理完成编码、测试和检查，最后使用独立上下文进行代码审查。整个过程中产生的文档、规格、任务、测试和审查记录，共同构成稳定的项目上下文。
每个Skill不只是执行一段提示词，还会产生可以交接的工程产物。
第二章：环境与技能准备
2.1 先统一技能，再讨论工作流程
Matt将常用的AI协作方法封装成一个技能仓库（Skills Repository）。
安装时建议：
- 保留一份独立的技能仓库
- 通过符号链接（Symbolic Link）共享给不同工具
- Claude Code、Codex等智能代理使用同一套技能
- 技能仓库更新后，只需要维护一处
初始化工具 setup-matt-pocock-skills 可以：
- 检查运行环境
- 检查系统路径（Path）
- 识别当前使用的智能代理
- 完成对应的初始化配置
对于第一次使用的人，ask matt 可以作为动态使用说明：
- 不需要记住所有技能
- 只需要描述当前目标
- 系统会推荐合适的技能入口
2.2 环境初始化产出
执行环境初始化技能后，项目中通常会增加：
项目根目录/
├─ CLAUDE.md
└─ docs/
└─ agents/
├─ issue-tracker.md
├─ triage-labels.md
└─ domain.md
各文件作用：
CLAUDE.md：记录项目启用的智能代理技能和规则issue-tracker.md：记录本地规格和任务文件的保存方式triage-labels.md：记录任务状态和标签规则domain.md：记录领域文档的位置和读取方式
需要特别说明：
初始化阶段不会立即创建
CONTEXT.md和docs/adr/，它们会在真正产生领域知识或架构决策时按需创建。
统一的不是某个工具，而是团队与AI的协作方式。
第三章：需求澄清与规格生成
3.1 真正的起点不是代码，而是需求盘问
面对一个还不够清晰的功能想法，Matt不会直接进入实现，而是先使用文档化需求访谈技能（Grill with Docs）。
它类似一位有经验的：
- 产品经理（Product Manager）
- 技术负责人（Tech Lead）
- 需求分析师（Business Analyst）
它会持续追问：
- 谁会使用这个功能？
- 用户为什么需要这个功能？
- 正常流程和异常流程是什么？
- 数据如何产生、存储和流转？
- 哪些内容明确不在本次范围内？
- 需要兼容哪些已有行为？
- 有哪些边界情况（Edge Cases）？
- 验收标准（Acceptance Criteria）是什么？
访谈结果不会只保留在聊天记录中，而是持续写入项目文档。
3.2 需求访谈产出
需求访谈技能可能生成或更新：
项目根目录/
├─ CONTEXT.md
└─ docs/
└─ adr/
└─ 0001-xxx.md
文件作用：
CONTEXT.md：记录业务术语、业务规则和重要约束docs/adr/NNNN-xxx.md：记录重要架构决策和选择理由
例如：
CONTEXT.md
├─ 什么是"K线"
├─ 什么是"日线"
├─ 什么是"导入批次"
├─ 如何定义"重复数据"
└─ 哪些业务规则必须保持一致
注意：
- 没有产生新业务术语时，不一定修改
CONTEXT.md - 只有重大且难以逆转的架构决策，才会生成架构决策记录
CONTEXT.md不保存临时代码、接口细节和调试过程
先消除需求中的模糊空间，再进入代码实现。
3.3 把人脑中的判断变成项目上下文
需求访谈的结果不会只保留在聊天记录（Chat History）中，而是持续写入项目文档。
人脑中的想法
↓
聊天中的讨论
↓
项目中的正式文档
完成迁移后：
- 需求不再只存在于某个人的脑中
- 决策不再散落在长对话里
- 更换会话后仍然可以继续工作
- 更换模型后不需要重新解释
- 更换智能代理后可以从文档接手
- 团队成员也能理解实现依据
如果访谈过程中遇到暂时无法回答的问题，可以：
- 调查现有代码库（Codebase）
- 查询外部资料
- 与相关人员确认
- 回到文档中补全决策
3.4 上下文文件的职责与组织
CONTEXT.md
保存跨需求复用的业务术语和业务规则
docs/adr/*.md
保存重要架构决策和选择理由
CONTEXT-MAP.md
大型项目中记录不同模块的上下文位置
小型项目通常使用：
项目根目录/
├─ CONTEXT.md
├─ docs/
│ └─ adr/
└─ src/
大型或多模块项目可以使用：
项目根目录/
├─ CONTEXT-MAP.md
├─ docs/
│ └─ adr/
└─ src/
├─ ordering/
│ ├─ CONTEXT.md
│ └─ docs/adr/
└─ billing/
├─ CONTEXT.md
└─ docs/adr/
CONTEXT-MAP.md 负责告诉智能代理：
- 当前需求属于哪个模块
- 应该读取哪个模块的
CONTEXT.md - 哪些上下文与本次任务无关
- 不同模块之间的边界是什么
需要注意：
多上下文架构（Multi-Context）通常需要人工主动触发或确认，生成后还需要人工检查模块边界是否合理。
项目文档是人类与智能代理之间稳定、可复用的上下文接口。
3.5 从需求文档生成规格说明
需求被问清楚后，下一步使用规格生成技能（to-spec），形成需求规格说明（Spec）。
一份真正有用的需求规格说明应包含：
- 问题定义（Problem）：要解决什么问题
- 目标（Goals）：希望实现什么结果
- 非目标范围（Non-goals）：哪些事情本次不处理
- 用户行为（User Behavior）：用户会看到什么
- 技术方案（Technical Approach）：准备如何实现
- 边界情况（Edge Cases）：异常情况如何处理
- 验收标准（Acceptance Criteria）：如何判断功能完成
3.6 规格说明产出
本地模式下，规格生成技能会创建：
.scratch/
└─ <功能名称>/
└─ spec.md
例如：
.scratch/
└─ csv-import/
└─ spec.md
spec.md 的内容通常包括：
功能背景
问题定义
目标
非目标范围
用户行为
技术方案
数据流转
边界情况
测试方案
验收标准
这个文件的作用是：
- 作为后续任务拆分的输入
- 作为功能实现的依据
- 作为代码审查的检查标准
- 让新的智能代理快速理解完整需求
需求规格说明不是形式化长文，而是实现、测试和验收的共同依据。
第四章：任务拆分与功能实现
4.1 从规格说明拆分可执行任务
需求规格说明完成后，使用任务拆分技能（to-tickets）生成独立任务（Tickets）。
拆分时需要明确：
- 每个任务要解决什么问题
- 任务需要哪些输入
- 任务应该产生什么输出
- 会修改哪些代码区域
- 有哪些约束条件
- 验收标准是什么
- 依赖哪些前置任务
- 能否与其他任务并行执行
任务之间需要处理依赖关系（Dependency）：
基础数据结构
↓
核心业务逻辑
↓
接口能力
↓
页面接入
↓
自动化测试
只有互不依赖的任务，才适合并行执行。
判断任务是否拆分合理，可以使用一个简单标准：
把任务交给一个没有参与前期讨论的新智能代理，它能否仅凭项目文档、需求规格说明和任务描述开始工作？
4.2 任务拆分产出
本地模式下，任务拆分技能会生成：
.scratch/
└─ csv-import/
├─ spec.md
└─ issues/
├─ 01-parse-csv-rows.md
├─ 02-validate-fields.md
├─ 03-upsert-with-dedup.md
└─ 04-import-summary.md
每个任务文件通常包含：
任务标题
任务状态
前置依赖
任务描述
约束条件
验收标准
后续讨论
例如：
# Validate CSV fields
Status: ready-for-agent
Blocked by: 01-parse-csv-rows
## Description
校验日期、开盘价、收盘价和成交量字段。
## Acceptance Criteria
- 日期格式错误时返回明确提示
- 价格字段必须为有效数字
- 成交量不能为负数
需要强调：
多个任务应该按照前置依赖逐个实现，不要一次让智能代理同时实现所有任务。
好的任务描述，本质上是一份可以独立交接的上下文包。
4.3 功能实现阶段不再依赖模糊提示词
进入功能实现阶段（Implementation）后，实现人员或实现智能代理（Implementer）的输入不再是一句模糊提示词，而是：
- 需求规格说明（Spec）
- 约束条件（Constraints）
- 验收标准（Acceptance Criteria）
- 代码库上下文（Codebase Context）
- 任务描述（Ticket Description）
实现阶段需要完成：
- 阅读项目文档和任务描述
- 理解相关代码和现有设计
- 按照需求规格说明修改代码
- 补充必要测试
- 运行测试和检查命令
- 对照验收标准确认结果
如果发现需求规格说明存在缺口：
- 不应该自行猜测
- 应该记录具体问题
- 将问题反馈给需求负责人
- 必要时回到文档阶段补充决策
- 同步更新需求规格说明和任务描述
4.4 功能实现产出
功能实现技能会产生真正的代码改动：
项目根目录/
├─ src/
│ └─ importer/
│ ├─ csv-parser.ts
│ └─ index.ts
└─ tests/
└─ csv-parser.test.ts
实际目录会根据项目结构变化，也可能将测试文件放在源码旁边：
src/importer/
├─ csv-parser.ts
├─ csv-parser.test.ts
└─ index.ts
本阶段产出包括：
- 新增或修改的源代码
- 新增或修改的测试代码
- 测试和检查结果
- 一次对应当前任务的Git提交
例如：
feat(importer): add CSV parser
多任务实施时应遵循：
任务01
实现 → 测试 → 检查 → 提交
↓
任务02
实现 → 测试 → 检查 → 提交
↓
任务03
实现 → 测试 → 检查 → 提交
智能代理可以自主执行，但不应该自主发明需求。
第五章：代码审查与质量保障
5.1 功能实现和代码审查使用不同视角
功能实现完成，并不代表任务已经完成。
Matt建议让另一个上下文中的智能代理承担代码审查（Code Review）。
原因是：
- 实现人员容易沿着自己的思路证明代码正确
- 独立审查人员更容易发现隐藏假设
- 新的上下文不会受到实现过程中的路径依赖影响
代码审查的重点不只是：
- 代码语法（Syntax）
- 编码风格（Code Style）
- 变量命名（Naming）
更重要的是检查：
- 实现是否真正符合需求规格说明
- 是否满足全部验收标准
- 边界情况是否得到处理
- 测试是否覆盖关键行为
- 是否破坏已有功能
- 是否引入新的行为或架构不一致
发现问题后，需要回到功能实现阶段修正，直到满足验收标准。
5.2 代码审查产出
代码审查技能默认不会在项目中生成文件，而是在对话中输出审查报告。
审查报告通常包括：
代码审查报告
├─ 是否符合需求规格
├─ 是否满足验收标准
├─ 是否遗漏边界情况
├─ 测试覆盖是否充分
├─ 是否存在兼容性问题
└─ 建议修改项
如果审查发现问题：
审查报告
↓
返回功能实现阶段
↓
修改源码和测试
↓
重新运行测试和检查
↓
产生新的Git提交
因此，本阶段的产出可以描述为：
对话中的独立审查报告；如需修复，则产生新的代码修改、测试和Git提交。
实现和审查分离，可以减少智能代理对自身方案的路径依赖。
第六章：总结与落地指南
6.1 这套工作流程真正解决的是什么？
表面上看，这套方法增加了几个步骤：
- 需求访谈
- 编写文档
- 形成需求规格说明
- 拆分独立任务
- 进行代码审查
实际上，它把最容易造成返工的问题提前解决了。
它真正改善的不是代码生成速度，而是上下文的质量和寿命，也就是"上下文保鲜"。
6.2 上下文与本地文件的关系
模糊想法
↓
CONTEXT.md / docs/adr/
↓
.scratch/<功能名称>/spec.md
↓
.scratch/<功能名称>/issues/*.md
↓
源码、测试和Git Commit
↓
代码审查报告
各类产出的职责：
CONTEXT.md：保存长期有效的业务知识docs/adr/*.md：保存重要架构决策spec.md：保存当前功能的完整规格issues/*.md：保存可以独立执行的任务- 源码和测试：保存最终实现结果
- Git Commit：形成清晰、可追踪的修改记录
- 审查报告：检查实现是否真正符合规格
通过这个过程：
- 想法不再困在人脑中
- 决策不再散落在聊天记录中
- 任务不再依赖某个了解前情的人
- 不同智能代理之间可以顺利交接
- 团队成员可以追踪决策依据
- 实现结果可以被明确验证
上下文不再依赖聊天记录，而是逐步转化为可追踪、可交接的工程产物。
6.3 团队应该如何逐步落地？
建议先选择一个中等复杂度的功能进行试运行。
第一步：初始化项目
执行一次：
setup-matt-pocock-skills
确认项目中已生成：
CLAUDE.md
docs/agents/issue-tracker.md
docs/agents/triage-labels.md
docs/agents/domain.md
第二步：编码前完成需求盘问
要求智能代理先回答：
- 用户是谁？
- 目标是什么？
- 非目标范围是什么？
- 边界情况是什么？
- 如何判断完成？
同时确认是否产生：
CONTEXT.md
docs/adr/*.md（可选）
第三步：生成本地需求规格
确认生成：
.scratch/<功能名称>/spec.md
第四步：拆分本地任务
确认生成：
.scratch/<功能名称>/issues/*.md
每个任务需要包含：
- 背景
- 目标
- 约束
- 依赖关系
- 验收标准
第五步：逐个实现任务
每个任务独立完成：
实现
↓
测试
↓
检查
↓
Git Commit
第六步：实现和审查分离
- 一个会话负责功能实现
- 另一个独立会话负责代码审查
- 审查结果重新反馈给实现阶段
- 修复后重新运行测试和检查
第七步：记录试运行效果
可以关注：
- 需求澄清次数
- 实现返工次数
- 智能代理之间的交接成本
- 代码审查发现的问题数量
- 验收标准一次通过率
- 上下文和令牌消耗情况
6.4 总结
这套工作流程可以总结为三句话：
第一，上下文（Context）是AI编程中最重要的工程资产。
第二，文档、需求规格说明和任务，是团队与智能代理之间稳定的接口。
第三，不要只给AI一个提示词，要给它一条能够执行、检查和纠偏的工作路径。
最终需要改变的是我们对AI编程的理解：
把AI当成代码生成器
↓
把AI当成软件交付流程中的协作者
AI可以更快地生成代码，但"写得快"并不是软件交付（Software Delivery）的全部。
真正决定效率的是：
- 方向是否清楚
- 上下文能否复用
- 任务能否交接
- 结果能否验证
- 错误能否及时纠正
最终，本地项目中会沉淀出：
项目根目录/
├─ CLAUDE.md
├─ CONTEXT.md
├─ CONTEXT-MAP.md （多模块项目可选）
├─ docs/
│ ├─ agents/
│ │ ├─ issue-tracker.md
│ │ ├─ triage-labels.md
│ │ └─ domain.md
│ └─ adr/
│ └─ 0001-xxx.md （重要决策时生成）
├─ .scratch/
│ └─ <功能名称>/
│ ├─ spec.md
│ └─ issues/
│ ├─ 01-xxx.md
│ ├─ 02-xxx.md
│ └─ 03-xxx.md
├─ src/
│ └─ 功能代码
└─ tests/
└─ 测试代码
结束语：
先把上下文做扎实，再让智能代理动手。
浙公网安备 33010602011771号