把 AI 当团队管理：规划、派活、调研与交接的四条实践

单会话聊到第 50 轮之后，你会发现一个问题：它开始忘事，而你开始替它记。

上下文压缩不是免费的。每压缩一次，模型就要重新理解一遍"我们到底在干什么"，反应变慢、判断变钝。 这篇记录我目前跑通的四条做法：把 AI 当团队管理，而不是当聊天对象。

一、规划与施工分离：我只做规划、审查和裁决

最早我是让一个会话从头干到尾：出方案、写代码、跑测试、改 bug。跑到中后期就开始失控—— 它会为了"把这一步做完"而临时改变架构，也会在你问"这样对吗"的时候顺着你的话说"对"。

后来改成两个角色：

• 规划会话：出计划、审阶段、裁决提案，不碰施工
• 施工会话：接计划、干活、交证据

关键的一条是给施工方一个反问权：

接到计划时，顺带判断「这一步对项目目标有没有正面作用」——抛开计划架构本身。 有异议就写提案，但不停工。

这条规则解决了一个很隐蔽的问题：计划是规划方写的，施工方最清楚现场。 如果现场发现"这一版计划其实在给一个错误的架构添砖"，允许它说出来，但不允许它擅自停工等待—— 提案走裁决通道，活照干。两边都不被卡住。

分工边界

我把整套协作类比成一家公司：

这条分工最重要的一点是秘书这个角色的存在。没有它，所有中间产物都会涌到我这， 我变成瓶颈；有了它，我只看"提炼后的决策点"。

派活的颗粒度

每个任务必须写清七件事，否则员工会在中途自己发明规矩：

1. 上下文    —— 这件事为什么存在，前置结论是什么
2. 文件范围  —— 允许改哪些文件，禁止碰哪些
3. 步骤      —— 按顺序给出可执行动作
4. 工具      —— 用哪个工具/命令，参数怎么写
5. 验收      —— 怎么算完成（可测量）
6. 停止条件  —— 什么情况下停手并上报，而不是硬试
7. 交付路径  —— 结果写到哪里，证据放哪里

配套的两条硬规矩：

• 每个新员工先读指定文件。不要假设它继承了当前会话——它没有。
• 并行只用于互不冲突的工作；有依赖的任务严格按门推进。

验收只认证据

这一条是踩过坑之后加的：

每次交付都检查真实文件、哈希、解析结果和实际证据， 不以"完成"状态代替交付。

“完成了"是一句话，sha256sum 是一个事实。状态字段可以被误填，文件不会。

错误也不浪费——记成下一轮派活的预防条件：

[预防] 上次因为没检查 <X> 导致返工 → 本轮所有同类任务必须显式验证 <X>

这样同一个坑只会踩一次。

无人值守的现实约束

我也不会假装 AI 能"自动运行”：

• 没有系统通知时，不能假装收到了员工结果
• 不让一个员工无限循环
• 不让多个员工同时写同一份权威文件

所以任务按波次推进：派一波 → 等系统提醒 → 收集、审阅、派下一波。 这不是效率损失，是避免"三个人同时改同一个文件"这类灾难。

工程规范的长期管理

顺手记几条容易忽略但影响很大的：

• 目录、命名、脚本、变量、上下文和状态文档都按长期工程规范管理，临时文件不堆在项目根目录
• 原型归档；新重写按契约从 Phase 0 开始，不把旧 JSON 管线、大文件逻辑或旧目录结构偷偷带回新架构
• 代码冻结、许可证、原版证明、判定数值、外部资源边界按既定门管理，不为了"无人值守"而越权

最后一条的实际含义：无人值守只延长了时间，不降低标准。不能因为没人盯着就把门放开。

二、技术选型：先调研，再动手

第二个习惯改自我自己的一个毛病：想做个东西，直接让 AI 开始写代码。

现在的固定话术是：

我要做一个 XXX，先不要写代码。 去 GitHub 找能直接使用或二次开发的开源项目，确认： 是否在维护、部署是否麻烦、哪些功能可以复用。 最后告诉我：应该直接用、基于现有项目改、还是自己开发， 并给出最简单的 MVP 方案。等我确认后再动手。

这个流程的价值不在于"少写代码"，而在于在投入前暴露真实成本。

AI 去查开源项目时，会自然回答出几个关键问题：

• 最近一次 commit 是什么时候（判断是否还在维护）
• star 数只是参考，issue 的响应速度更真实
• 部署需要几个依赖、有没有 Docker、文档是否过期
• 哪些模块能直接拿来用，哪些必须重写
• 许可证是否允许你的使用场景

最后必须落到三选一：

A. 直接用（部署成本 < 自研成本）
B. 基于现有项目改（核心可复用，边界清晰）
C. 自己开发（现有项目都不匹配，或改造成本高于重写）

并给出 MVP——能验证核心假设的最小版本。

这一步实际上省掉了我最多的返工。很多想法在调研阶段就被证明"有人做过且做得更好"，直接省下一周。

三、把会话记录变成可检索的记忆库

这是最近在做的一件事：让 AI 自己把 jsonl 会话文件转成 Markdown，再经由 LLM wiki 做成大型记忆知识库。

思路很直接：

原始会话（jsonl，含完整工具调用与结果）
  → 提取：任务目标、关键决策、失败尝试、验证证据
  → 转成结构化 Markdown（带 tags / 结论 / 避坑）
  → 灌进 wiki，按关键词加权检索
  → 下次遇到同类问题，自动命中过往经验

为什么值得做：

• 会话记录里最有价值的不是结论，是过程——尤其是"试过什么、为什么不行"
• 单次会话的上下文会丢，但事实不会消失，只是没人整理
• 检索比"重新想一遍"便宜得多

实现上有几个坑我提前踩过：

1. 不要把整个 jsonl 直接转文本。里面有大量重复的工具输出，会淹没真正的信息。
2. 必须标注来源：这条结论是用户说的、AI 推断的、还是工具验证过的？三者权重完全不同。
3. 失败路径要和成功路径同等对待。只存"怎么做对了"，下次还会在同一个地方摔倒。

这个方向还在做，但已经能感觉到：知识库的价值不在于"多"，而在于"命中"。 写了 100 篇没人检索到，等于没写。

（这一点在上一篇里有具体数据：方法论写完之后，自动预取的检索词根本选不到它。 页面存在、检索函数正常，但 AI 永远看不到——这是最难发现的一种失效。）

四、频繁压缩上下文会让 AI 变慢：写交接文档，不写项目总结

这条是体感最明显的：

上下文压缩次数多了，AI 会变慢、变笨。

原因不难理解——每次压缩都是一次"有损转述"。细节被概括，概括再被概括， 到后面模型手里只剩一层抽象，却还要假装知道具体怎么做。

解法不是"少压缩"，而是在压缩之前把该留的东西留下来。

我现在的做法是让 AI 写一份 prompt.txt，目标写得很明确：

让一个没有本对话历史的下一个 agent 能立刻接手，而不是写一篇项目总结。

这两者的区别是决定性的：

四条铁律

写这份文档时，有四条不能破：

1. 禁止编造——不知道就写「未知」。不要用合理的推测填补空白。
2. 以项目现场为准——先查 Git、文件、日志，别只靠聊天记忆。
3. 区分信息来源——每条结论标明：已验证 / 用户提供 / 推断 / 未知。
4. 保留失败尝试和精确命令/报错——不要只写抽象概括。

第 4 条最容易被忽略，也最有用。写"试过修复但失败了"是废话； 写"执行 npm run build 报 EBUSY: app.asar，原因是 Windows Defender 实时防护持有句柄， 尝试 unlink/rename/MoveFileEx 均失败，需要管理员权限加排除项"——下一个 agent 可以直接跳过这段。

判断标准

整份文档只有一个验收标准：

下一步必须可执行。

具体到：

• 先读哪个文件
• 先跑哪条命令
• 改哪个函数
• 怎么算成功

不能说"继续优化"“进一步完善"这类话——那不是指令，是愿望。

五、小结

四条实践，本质上是同一个思路的不同侧面：

如果只让我留一条，我会留交接文档那条。

因为其他三条都是在优化"这一次做得好不好”， 而交接文档决定的是——下一次开始的时候，是原地起步，还是从零起步。