voidliang's zone

我用 AI 写代码快一年了。最让我头疼的不是 AI 不够聪明，而是在"开新会话"和"继续旧会话"之间反复权衡的痛苦。

开一个新会话，上下文干净、响应快，但 AI 完全不记得你之前在做什么——它不知道当前需求是什么、做到第几步了、上次做了什么技术决策。你得从零开始重新描述一切。

继续一个旧会话呢？上下文确实还在，但已经塞满了十几轮对话的冗余信息，每次响应越来越慢，token 消耗越来越高。更糟的是，上下文太长之后 AI 开始"遗忘"早期讨论的关键约束，你不得不反复提醒它。

两种选择都不对。这不是 AI 模型的问题，是协作协议的问题——我们缺一套让 AI 知道"当前在做什么、做到哪了、下一步可以做什么"的系统。

PACE（Progressive Agentic Collaborative Engineering，渐进式 AI 协作工程）就是为这个设计的。我们团队里就搭有这样一个AI工作流。

往下看之前，先交代几个最基础的概念，后面会反复出现。你花一分钟扫一眼就行，不用记。

概念	一句话解释
Skill	一份 Markdown 文件，写明"什么场景触发、按什么步骤做"。AI 读了就知道怎么干活。
Agent	执行任务的独立上下文。大任务拆成多个 Agent 分头跑，互不干扰。
Command	用户的显式入口，本身不含逻辑，只是个"路标"，告诉 AI 加载哪个 Skill。
todo	待办任务项。用 Markdown 复选框（`- [ ]`）追踪进度，勾选 `[x]` 就是完成。
产物目录	项目根目录下的一个文件夹，存所有需求的状态文件和沉淀的知识。

概念交代完，开始拆系统。

三个断层：AI 助手为什么老是"断片"

① 没有规划，一句话就埋头写 500 行

② 没有状态，关掉 IDE 它就失忆

③ 没有沉淀，同样的坑踩一百遍

先说一个场景。打开 IDE，对 AI 说"帮我做一个登录功能"。它二话不说开始写代码，改了用户模型，新建了处理器，动了数据库结构。写到一半会发现，它根本没问我密码怎么加密、token 用什么方案、要不要支持第三方登录。

这是第一个断层——没有规划。AI 默认"你说的都对"，不追问、不确认、不掂量复杂度。一句模糊指令就能让它写出一坨偏离方向的代码。

第二个断层是没有状态。你点开新会话，AI 完全不知道之前做了什么。它不会告诉我"上次做到 2.1 实现登录接口，还剩 5 个待办"。我得重新描述上下文，让它重新读代码、重新猜我在哪。

最气人的是第三个断层——没有沉淀。上周花一下午踩的坑，它一个字都没记。同样的问题换个需求又来一遍。我的经验永远只存在自己脑子里，变不成 AI 下次能直接用的知识。

断层	症状	你付出的代价
没有规划	不问就动手	方向跑偏，返工重来
没有状态	跨会话失忆	每次重新对齐上下文
没有沉淀	经验不留存	同一个坑反复踩

这三个断层我以前以为是"AI 还不够强"，后来才想明白，是没人给它一套协作规则。它不是不会干，是没人告诉它该按什么节奏干。

PACE 的设计哲学：过渡期怎么走

那这套规则到底长什么样？在拆具体设计之前，先看一眼 PACE 的世界观——它把问题放在什么坐标里看。

AI 自闭环开发是必然终局。问题不是"要不要"，而是"怎么过渡"。

PACE 解决的是过渡期问题：让团队今天就能用最简单的系统享受 AI 提效，同时每一次协作都在为 AI 自闭环积累知识和规范。

两个核心设计约束：

约束	含义	实现方式
对人足够简单	不需要学习成本，自然语言驱动全流程	意图识别 + 自然语言参数
对 AI 足够结构化	所有产物都是 AI 可直接消费的格式	Markdown + YAML + Checkbox

三阶段不是空中楼阁。今天的每一行设计——两层 Skill 拆开、Command 不含逻辑、文件系统当数据库——都是故意给终局留的接口。终局来的时候，Command 可以删掉，Skill 自动被 AI 发现并调用。今天的架子上没有多余的零件。

好了，世界观交代完。下面拆内部结构——先从最外层那个闭环讲起。

一个闭环：规划、执行、检查、归档怎么转起来

① 规划会自己掂量复杂度

② 执行是状态感知，不是命令响应

③ 检查是门禁，不是建议

PACE 的核心是一个四阶段闭环：规划 → 执行 ⇄ 检查 → 归档。每个需求进来走一圈，走完归档不算完，归档时会从需求里提炼经验写进知识库，下次规划新需求时自动检索。

规划阶段最关键的是自适应。我说"加个字段"，它判断复杂度小，生成简洁计划和两三个待办。我说"实现用户认证模块"，它判断中等，生成完整计划和五到十个待办。跨服务的架构变更则触发大型模式，多出一份技术设计文档。

复杂度	判断信号	产出
小	改动不超过 3 个文件	简洁计划 + 2-3 个待办
中	涉及多模块、要做决策	完整计划 + 5-10 个待办
大	跨服务、架构变更	上述 + 设计文档 + 10 个以上待办

执行阶段不是"执行命令、返回结果"，而是一个状态感知系统。每次执行它会先读状态文件，知道整体进度。再翻待办清单，找到第一个没勾的项。最后读会话日志，恢复上次的上下文和决策。做完勾掉，更新进度。

这意味着新开一个会话。第二天打开说"继续xxxx需求"，它自己就知道该干什么。

检查阶段用了三级渐进。每个待办做完自动跑快速检查，编译加静态扫描，半分钟搞定。我说"检查一下"触发标准模式，加跑测试。我说"全面审查"或者全部待办完成时触发深度模式，几个审查 Agent 并行上。

关键是这套检查不是"建议"，是门禁。状态文件里的标记不对，我按下推送会被 IDE 的 Hook 直接拦住。Hook 不是 AI 说了算，是系统层确定性阻断，绕不过去。

状态机：为什么没有"暂停"和"恢复"

① 八个状态串成一条合法路径

② 分支多了，必须停下来问

③ 关掉就是中断，打开就是继续

人和 AI 协作的第一个问题是"当前到哪了"。两个独立的执行单元靠消息沟通，没有一个共享的状态机，就像两个人拼乐高却看不到对方的手。

PACE 用一个八状态、十二条转移路径的有限状态机解决这个。需求从"进入"开始，经过"待确认""执行中""检查中""检查完成""待归档""归档中"，最后到"闭环完成"。AI 任何时候都知道自己在哪个状态、有哪些合法的下一步。

状态	含义
需求进入	用户描述了新需求
待确认	计划和待办已生成，等用户拍板
执行中	正在做某个待办
检查完成	检查出了结果，要判断下一步
待归档	全部完成且终审通过
闭环完成	已归档，整个循环结束

状态机里有个很关键的安全设计——分支确认规则。当当前状态有多条出边，而我的输入又模糊（比如只说"继续"），AI 禁止自己选路。它必须列出选项让我确认。比如进度 3/5、检查通过、还有剩余待办时，它不能直接往下做，得问清楚是继续、是提交、还是先看清单。

还有个设计我一开始没想通：为什么没有"暂停"和"恢复"？ 设计者的答案是，"执行"本身就是一个持续过程，不存在暂停这个概念。关上 IDE 就是自然中断，下次打开说"继续"就是自然恢复。显式的暂停和恢复，只是多出来的认知负担。用了一阵我才认同，确实不需要。

两层 Skill：编排和能力为什么要拆开

① 编排层只管"做什么"

② 能力层只管"怎么做"

③ 一个给全自动化留的后门

前面说过 Skill 是 PACE 的能力模块，每份文件定义了触发条件和执行步骤。PACE 把它分成两层，这是一个典型的关注点分离。

编排层有六个 Skill，管"做什么、怎么编排"。规划、执行、同步人工改动、检查、沉淀、归档，各对应闭环的一个阶段。能力层有八个 Skill，管"具体怎么做"。解析待办、跨会话恢复、跑编译测试、读写知识库，都是可复用的专项能力。

层	职责	举例
编排层（6 个）	定义流程、编排阶段	规划、执行、检查、归档
能力层（8 个）	提供可复用专项能力	待办引擎、会话状态、验证检查、知识库

编排层引用能力层，但两者独立维护。改一个能力，不会牵动其他编排，这是我后来改它的时候才体会到的好处。

最有远见的是 Command 和 Skill 的分离。Command 只是路标，前缀命令本身不含逻辑，唯一作用是告诉 AI 加载哪个 Skill。真正的逻辑全在 Skill 文件里，而每个 Skill 的描述字段写明了触发条件。

这意味着当 AI 能力足够强时，它可以直接读 Skill 的描述，自己判断该加载哪个能力。Command 就能被淘汰，Skill 独立运行。今天的每一行都在为明天准备，架构上没做任何妥协。

子 Agent 编排：调度员自己不干活

① 四个专职 Agent 各管一段

② 审查交给并行的子 Agent

③ 加把锁，防止两个入口打架

PACE 的主 Agent 是个纯调度员。它不写代码、不审查、不沉淀、不归档，只做三件事：理解我的意图、管理状态机、创建并汇总子 Agent。

真正干活的有四个专职 Agent：一个管需求分析和产物创建，一个管代码实现和进度更新，一个管质量检查和审查协调，一个管归档校验和知识提炼。

Agent	干什么	运行方式
规划 Agent	分析需求、写计划和待办	创建产物
执行 Agent	写代码、勾待办、更新进度	可写代码
检查 Agent	跑检查、协调审查	协调多个子 Agent
归档 Agent	校验完成度、提炼知识	收尾闭环

检查 Agent 下面又挂了几个审查子 Agent，并行跑。一个查代码规范，一个查实现和设计文档是否一致，一个查安全漏洞。它们都在独立上下文里跑，互不污染，跑完把结果汇总上来。

这种拆法最大的好处是上下文隔离。要是把审查逻辑塞进主 Agent，几千行代码改动加上规范文件，会把上下文撑爆。拆成独立 Agent 后，每个的上下文都干净、聚焦、可复用。我自己跑深度审查时，明显感觉响应没有变慢。

还有个细节是并发锁。PACE 允许两个入口同时操作同一个需求，一个是 IDE 里的对话面板，一个是 IM 机器人。如果 IDE 侧已经有执行 Agent 在跑，IM 侧想再起一个，系统会提示冲突。它会问我，是等它做完，还是强制接管。这个锁用状态文件里的一个字段实现，干净利落。

三个文件：不用数据库也能管住状态

① meta 记"到哪了"

② todo 记"做什么"

③ log 记"发生了什么"

PACE 不需要数据库。它把所有状态都存在项目根目录的产物目录下，用三个文件就解决了。

第一个是状态文件，相当于需求的身份证。记需求编号、名称、复杂度评分、当前状态、进度统计。所有 Agent 读写状态都通过它。

第二个是待办清单，Markdown 复选框。人和 AI 都能直接读直接改。执行 Agent 自动定位到第一个没勾的项，做完打勾。文件本身就是进度，勾选状态就是完成度。

第三个是进度日志，只追加不修改的叙事桥梁。新会话启动时读这个文件就能恢复完整上下文，里面记着每次会话完成了什么、做了哪些决策、下一步是什么。

文件	回答什么	谁读	谁写
状态文件	到哪了	执行 Agent 判断大局	各阶段 Agent
待办清单	做什么	执行 Agent 找下一项	执行 + 同步
进度日志	发生了什么	新会话恢复上下文	执行 + 同步

这套设计最妙的地方是不需要保存和加载。传统系统切换会话要先存状态、恢复要重新加载。PACE 直接靠文件系统，改文件就是存状态，读文件就是恢复上下文，零额外成本。我用了这么久，从来没手动"保存"过一次。

知识沉淀：让每次协作变成长期资产

① 四类知识各回答一个问题

② 索引是 AI 的检索入口

③ 冲突要暴露，不能偷偷覆盖

归档不是简单地把文件夹从"活跃"挪到"归档"。PACE 的归档多了一步关键动作——知识沉淀。从做完的需求里，AI 自动提炼四类知识。

分类	回答	举例
服务地图	改哪里	某服务提供登录和查询两个接口
依赖清单	能用什么	缓存连接池的最佳参数
经验范式	怎么做	某个方案的最佳实践和踩坑记录
业务背景	为什么	当初为什么选这个方案而不是另一个

提炼完会更新一份全量索引。规划新需求时，AI 先读索引，靠标签匹配找到相关条目。定向读取后，在计划里用双向链接引用。这个链接是维基风格的语法，既能跳转，也能反向追溯——我能看到哪些计划引用了某条知识。

还有个冲突检测机制。写入新知识时自动检查同标签条目，发现矛盾就标注"待审核"并提示我，绝不静默覆盖。这个设计说明了一件事：知识库不是流水账，每条记录都得有可复用的结论，宁缺毋滥。

刚开始我觉得这步多余，做需求还得停下来沉淀知识，挺烦。用了两个月之后才发现，真正省时间的就是这一步。同一类需求再来时，AI 直接把上次的经验和踩坑摆出来，我少走了一大圈弯路。

写在最后

拆到这，PACE 的设计全景基本清楚了。我自己最大的感受不是"这系统真复杂"，而是"它其实很简单"。

整套系统加起来 23 个触点——6 个编排层 Skill、8 个能力层 Skill、4 个专职 Agent、几个审查子 Agent、1 个 Hook、两个辅助脚本。每个触点单一职责，能独立替换。设计团队此前试过好几套 AI 工程化方法的组合，加起来将近 200 个触点。PACE 把核心价值浓缩到了 23 个，砍掉了将近九成。

几个最关键的设计决策，我想再强调一遍：

文件系统就是状态，不要数据库。复选框勾选就是进度，文件写入就是保存。
自适应替代多命令，我永远不用想"该调哪个"。说"全面审查"就自动走深度模式。
调度员自己不干活，上下文隔离，每个子 Agent 跑在干净的环境里。
Command 不定义参数，自然语言就是参数。这是给 AI 全自动化预留的接口。
没有暂停和恢复，关掉就是中断，打开就是继续。

说到底，AI 写代码这件事，瓶颈早就不在模型的智商上了。模型已经够聪明，缺的是一套让它知道"我在哪、要去哪、能做什么"的协作协议。PACE 给了我一个还不错的答案。

如果你也在折腾人和 AI 怎么协作，它的设计思路值得花一个下午读一遍。不是因为它复杂，而是因为它把一个复杂问题解得很简单。