过去大半年，我一直在尝试一件看起来有点“反直觉”的事：把 Claude Code 从“一个会写代码的对话窗口”，改造成一支有分工、有流程、有记忆的虚拟软件团队。这个方案我最后起名叫gstack。简单说，它不是在教 Claude Code 写代码——写代码它本来就会——而是要解决摆在所有重度使用者面前的三件事：它干完活之后没有长期记忆、它对待问题的视角永远只有一种、它从不会回头审视自己前一天写的那堆东西到底有没有埋坑。
这三个问题的本质，就是“单次会话”和“一支团队”之间的差距。你会发现，单次对话再强，它也是一次性的：这次聊完，下一次从头再来。但一支团队不一样，团队会开会、会分工、会评审、会复盘、会把踩过的坑写进文档。gstack 做的，就是把这套团队协作机制搬到 Claude Code 的运行方式里去。
这篇文章我会把整个思路、目录结构、角色定义、状态流转、复盘循环全部拆开讲，包括我踩过的坑和一些实测下来很稳的配置。适合已经在用 Claude Code 写真实项目、又被它的“没记性”和“一条道走到黑”折磨过的人参考。
1. 为什么把 Claude Code 组织成“团队”，而不是指望它当超人
先说一个我观察了很久的现象。很多人用 Claude Code 的方式，是把它当成一个“超级外挂”：扔给它一个需求，让它直接改代码，改完就完事。早期我也是这么干的，但项目一复杂，问题马上冒出来。
1.1 单次对话没记性，改着改着就“失忆”
Claude Code 本身有上下文窗口，也有 CLAUDE.md 这类可以长期携带的项目记忆文件，但它的问题是：一次会话里它能记住的东西有限，一旦会话结束，下一次它对你项目的理解，完全取决于你喂给它的新上下文。举个例子，我做一个内部工具，周一让它完成了数据库表设计，周二我让它写接口，它居然又给同一张表加了一列之前已经定义过的主键字段——因为它根本不知道周一聊过什么。这不是模型笨，而是你没有一个机制让它“在动手之前先读一遍团队纪要”。
gstack 的第一个核心，就是人为建立一套“团队共享记忆”。把所有跟项目相关的结论、约定、进度、风险，落到一组有结构的文件里，每次开工前强制角色们先读这些文件。这一步就像新员工入职先看《团队工作手册》，而不是上来就写代码。
1.2 单次对话视角单一，没人抬杠，也没人把关
你让同一个模型既做架构设计、又写业务代码、又做 code review，它通常都会“自圆其说”：反正代码是自己写的，review 的时候也不会太较真。这跟现实中一个人既当运动员又当裁判是一个道理，不是能力问题，是立场问题。
gstack 的第二个核心，是角色分离。我把整个流程拆成五个角色：负责人（Director）、架构师（Architect）、开发者（Developer）、评审员（Reviewer）、记录员（Chronicler）。每个角色有自己独立的角色定义文件，它们的上下文侧重、输出要求、甚至行为准则都不相同。开发者和评审员站的位置不同，代码被挑毛病的时候，是真的会有人出来“抬杠”的。
1.3 单次对话没有反馈回路，同样的坑会反复踩
这是最让我头疼的一点。Claude Code 写出来的代码如果有问题，你会在测试阶段发现，然后把它修好，但这个过程是发生在“一次会话”里的，下次遇到类似问题，它大概率还会按老思路写一遍，然后再让你修一遍。
我统计过一个模拟项目 X 的开发数据，在没有复盘机制的情况下，同一个类型的 bug（比如并发更新的竞态条件）在三个月内出现了四次。这说明模型不会从过去的错误中学习，除非你主动把“错误—原因—对策”沉淀成一个文件，并确保后续每一次生成代码之前，它都被明确要求阅读这个文件。
gstack 的第三个核心，就是把“复盘”做成一个显式的流程环节，而不是可有可无的收尾动作。
2. gstack 的整体拆解：思考层、交付层、复盘层
很多人听到“把 Claude Code 组织成团队”的第一反应是：是不是要写一堆复杂的框架代码？其实不是。gstack 的本质是一组约定：用什么结构组织项目文件、每个角色负责什么、任务按什么状态流转、每个状态触发什么动作。不需要写插件，不需要改 Claude Code 内部逻辑，只需要用 Markdown 文件和少量胶水脚本就能搭起来。
我把整个体系分成三层：思考层负责“别急着写代码”，交付层负责“按流水线干活”，复盘层负责“把经验带进下一轮”。
2.1 思考层：先想清楚，再动手
这一层解决的是“一拍脑袋就开工”的问题。传统开发里有设计评审、有需求澄清，但到了 AI 编程时代大家全忘了这套。反正模型生成代码很快，那就让它快点生成呗——但模型生成得越快，错误被放大得也越快。
gstack 里，任何任务的第一步不是写代码，而是产出TASKS.md。这个文件由负责人和架构师合作完成，内容包括：目标描述、约束条件、涉及模块、技术方案、验收标准、风险点。这一步的产出物是一份“可执行的计划”，代码一个字都不写。
我自己的体会是，加了这一步之后，返工率下降非常明显。原因是 Claude Code 在写代码之前，被迫把需求“翻译”成具体的模块级操作，很多需求里没考虑清楚的边界情况，在写 TASKS.md 的阶段就会暴露出来。与其让它在代码里翻车，不如让它在计划里翻车。
2.2 交付层：角色明确、流水线作业
计划定好之后，进入开发阶段。这一步我强烈建议不要只用一个 Developer 角色一路干到底，而是把一个任务拆成“实现 + 自检 + 评审”三个连续动作：
- Developer 按 TASKS.md 的要求实现代码，并在交付时附带一份说明，写清楚改了什么、为什么这么改、有没有已知风险。
- Reviewer 负责挑毛病，它看到的上下文里包含代码 diff、Developer 的说明、原有代码结构，它的职责是找出逻辑漏洞、边界问题、风格不一致的地方。
- 如果 Reviewer 发现问题，任务状态被打回，Developer 修改后再交上来，直到 Reviewer 认为达到验收标准。
这一层的效果是，代码每一个提交都经过一轮“较真”的评估，很多隐藏 bug 是在这一层被拦下来的，而不是等到联调阶段才爆出来。
2.3 复盘层：经验回流，越做越顺
一个任务通过验收，不代表整个流程结束了。gstack 的最后一步，是让 Chronicler 根据整个会话的记录、Reviewer 的意见、最终代码提交，生成一份复盘记录，写入项目的LEARNINGS.md文件。
这份文件不是写出来好看的，它会在下一个任务启动时，被强制注入到架构师和开发者的上下文中。这样一来，项目会形成一个正向循环：踩过的坑被记录 → 下次开工先读 → 不再踩同一个坑。用了一段时间之后你会发现，Claude Code 处理同类问题的风格会越来越符合你的团队习惯。
3. 实操：从零搭一套最小可用 gstack
下面这部分纯实操。我会按我自己的项目结构来演示，你可以直接照搬，也可以按自己的项目类型调整。核心原则有两个：文件结构要扁平、角色职责要清晰。千万不要一上来就设计一个几十个文件的复杂框架，那会让上下文管理变成新的灾难。
3.1 目录结构：一张表看懂所有文件放哪
我建议在项目根目录下建一个.gstack/文件夹，把团队相关的文件全部放进去，避免污染业务代码目录。目录结构大致是这样：
project-root/ ├── .gstack/ │ ├── ROLES/ │ │ ├── director.md │ │ ├── architect.md │ │ ├── developer.md │ │ ├── reviewer.md │ │ └── chronicler.md │ ├── STATE/ │ │ ├── current_task.md │ │ └── progress.json │ ├── LOGS/ │ │ └── session_20250110.md ├── CLAUDE.md ├── TASKS.md ├── LEARNINGS.md └── src/CLAUDE.md 放在项目根目录，是 Claude Code 启动时自动读取的全局说明。在里面写清楚一句话：项目使用 gstack 流程，开工前必须阅读 .gstack/ROLES/ 下的角色定义和 STATE 下的当前任务状态。这样就不需要每次手动重复告诉它“你是谁、你要干什么”，上下文省一大截。
3.2 角色定义怎么写：给出一个能直接改的模板
每个角色文件我控制在 30 到 60 行以内，太长了会挤占上下文窗口。核心元素是四个：职责边界、输入要求、输出格式、职业禁忌。我拿 developer.md 来举例：
# Role: Developer ## Mission - 依据 TASKS.md 中分配给你的任务实现代码 - 代码必须通过语法检查与基础自测 ## Input - TASKS.md（任务计划） - .gstack/STATE/current_task.md（当前任务状态） - 相关模块的现有代码 ## Output - 代码变更 - CHANGES.md：列出本次修改的文件、修改原因、已知风险 ## Rules - 不修改与当前任务无关的代码 - 不修改 TASKS.md 中已经确认的技术方案，除非先在 comment 中提出 - 遇到不确定的需求时，记录到 OPEN_QUESTIONS 列表，停下来等待下一步指令，不要替需求方拍板评审员的文件就要反过来强调“怀疑一切”：
# Role: Reviewer ## Mission - 找出 Developer 交付代码中的逻辑错误、边界问题、安全隐患、风格问题 - 对每个问题给出严重级别：critical / major / minor ## Input - Developer 提交的 diff 和 CHANGES.md - 相关模块的现有代码 ## Output - REVIEW.md：评审意见清单 ## Rules - 你的目标是挑错，不是夸代码写得好 - 每个 critical 问题必须明确说明“为什么会导致错误”，不允许写空泛的“建议优化” - 只有所有 critical 和 major 问题都被解决后，才能给出 APPROVEDDirector 的角色定义我建议写成“流程掌控者”，它的输出物是 TASKS.md 的初始版本、任务拆解优先级和进度更新。Architect 的角色定义则要强调“技术选型和接口设计”，它的输出物是技术方案说明，不需要写具体代码。Chronicler 是最后一个角色，它的输出物是复盘记录，格式见 3.4 节。
3.3 任务状态机：让流程自己往前滚
有了角色定义还不够，还得让整个流程“跑”起来。我用的是一个非常朴素的状态机，只有四个状态：
- PLANNING：任务正在制定 TASKS.md，对应负责人和架构师工作阶段。
- IN_PROGRESS：Developer 正在实现。
- IN_REVIEW：Reviewer 正在评审。如果发现问题，状态回到 IN_PROGRESS；如果通过，进入 DONE。
- DONE：任务完成，Chronicler 开始写复盘。
这个状态直接写在一个current_task.md文件里，每次角色切换时，新的角色会被要求读取这个文件，确认自己当前处于哪个阶段。比如 Developer 看到状态是 IN_REVIEW，就要知道自己现在不是主角，不需要做任何修改动作，而是等 Reviewer 的反馈。
如果你想更自动化一点，可以用一个简单的钩子脚本或者 Claude Code 的 hook 机制，在每次会话结束时更新状态。我自己用的是一个小 bash 脚本，大致逻辑是：
#!/bin/bash # 用法: gstack_transit.sh <from_state> <to_state> <comment> FROM=$1 TO=$2 COMMENT=$3 sed -i "s/state: $FROM/state: $TO/" .gstack/STATE/current_task.md echo "[$(date)] $FROM -> $TO: $COMMENT" >> .gstack/LOGS/state_transitions.log脚本本身不复杂，它的作用不是自动化魔法，而是让状态流转有迹可循，方便复盘的时候查历史。
3.4 复盘循环：复盘不是写日记，是写“下一次的行动指南”
很多做模型流程的人把复盘写成了流水账，这没意义。Chronicler 复盘的核心产出，必须是“可执行的改进项”。我用的复盘格式是这样的：
# 复盘记录: [任务编号] ## 完成情况 - 实际产出: ... - 是否达到验收标准: ... ## 关键问题 1. [问题描述]（严重级别） - 根因: ... - 触发场景: ... ## 经验沉淀 - 经验 1: ...（对应操作建议） - 经验 2: ... ## 下次行动 - [ ] 新增一条检查规则到 developer.md - [ ] 将某个常见错误模式写入 LEARNINGS.md重点在“经验沉淀”和“下次行动”这两栏。一条经验如果只是“要小心并发问题”这种废话，就不要写；要写成“当接口涉及同一数据表的并发更新时，必须使用事务并在 README 中说明隔离级别”这种可以立刻执行的具体条款。
写完之后，Chronicler 会把“下次行动”里的内容追加到对应的角色定义或者 LEARNINGS.md 中。这一步做完，本次循环的价值才算真正闭环。
4. 常见问题与排查记录
这套体系跑起来之后，你一定会遇到几个典型问题。我一个个列出来，附带我实测之后的解决方案。
4.1 上下文窗口爆炸：角色文件太多，喂不进去
系统提示加上 CLAUDE.md、TASKS.md、current_task.md、LEARNINGS.md、角色定义，一次性塞进去确实很占上下文。尤其当项目变大、LEARNINGS.md 写了上百条经验的时候，还没开始写代码，上下文已经用掉一大半。
我试过几种方案，最有效的是分段加载。不要把所有文件一股脑让 Claude Code 读，而是在不同阶段只读相关文件：Developer 阶段读 TASKS.md、current_task.md、LEARNINGS.md 里和当前模块相关的条目；Reviewer 阶段才额外读 REVIEW.md 模板和角色定义。具体做法是在 CLAUDE.md 里写清楚“何时读什么文件”，而不是“把所有文件读完”。
另外，LEARNINGS.md 建议定期做一次“压缩归档”。保留最近 20 条完整经验，更早的只保留标题和在标题里写清对应模块，用的时候按模块精确检索，而不是全文加载。
4.2 角色漂移：Developer 干着干着开始当 Reviewer
角色漂移是这套机制里最常见、也最隐蔽的问题。现象是：Developer 写代码写到一半，看到 review 阶段会用的 REVIEW.md 模板，就会忍不住先自我评审一通，把代码改得面目全非，结果团队里本该由 Reviewer 提出的意见被提前“自我消化”了，污染了评审的独立性。
我的解决方案有两个层面。第一，在 Developer 的角色定义里明确写一条规则：“如果你发现自己正在修改样式问题或评审类意见，请把问题记录到 CHANGES.md 的预留区域，然后继续当前任务。你的产出是代码，不是评审报告。”第二，在 current_task.md 的状态说明里加一行“当前状态下的工作重点”，状态是 IN_PROGRESS 时，工作重点一栏写“仅实现，不评审”。实测下来，这个“口头禅”式的提示比长篇幅的系统提示管用得多。
还有一个更简单有效的办法：把不同角色放到不同的 Claude Code 会话里执行。Developer 一个会话，Reviewer 单独开一个会话，两者通过 current_task.md 和 REVIEW.md 交流，物理隔离让角色漂移基本消失。缺点是切换会话增加了一点手动操作，但换来的是流程清晰度大幅提升。
4.3 流程空转：模型停在原地问“请问下一步做什么”
这个问题尤其容易出现在状态切换到 DONE 之后，Chronicler 不知道该干嘛，或者 PLANNING 阶段架构师没想清楚，反复产出“计划 v2、计划 v3”，浪费大量 token 也没推进。
我的经验是：每个角色定义里都要加一个“默认动作”。所谓默认动作，就是在没有明确指令时，这个角色应该主动做的事。比如 Chronicler 的默认动作是“查看当前任务的完成情况，生成复盘记录初稿”；Architect 的默认动作是“如果 TASKS.md 已经存在一个版本，并且当前没有新信息，则补充风险清单，而不是重写整个计划”。
另外，可以用一个简单的超时判断：如果一个状态连续两次输出都没有产生 state 变更，就让 Director 介入，把任务重新聚焦到最小可交付目标上。这个方法在长任务里特别有用，能避免模型陷入“过度分析”的舒适区。
4.4 复盘变成走过场：经验写了一大堆，后续根本不生效
复盘写完了，但下一个任务的行为却没有明显变化，这是最打击信心的问题。我曾经连续复盘了六次，发现 Developer 还是会在某个固定位置踩同一个坑。后来我意识到问题出在“经验没有被执行”。
复盘经验的落地，靠的是“注入 + 约束”双保险。注入是指 LEARNINGS.md 的内容要进入后续任务的上下文，这步不难；约束是指经验必须转化为角色定义里的强制规则，而不只是一段“建议”。比如“使用事务处理并发更新”这条经验，把它写进 developer.md 的 Rules 区，加一句“不遵守此规则视为代码缺陷”，它的执行力才会真的上来。换句话说，复盘的文字如果不能转化为某条规则，那你写的就不是经验，只是情绪。
5. 一点实际的体会
gstack 这套东西，与其说是一个技术框架，不如说是一套“驯服 AI 工作流”的方法论。它不依赖某款具体的模型工具，Claude Code 能用，换个模型也能用，核心就是把团队协作里那些成熟的做法——角色分离、状态流转、复盘沉淀——翻译成模型能理解的文件结构与流程约束。
我在实际使用中最受益的一个细节是：状态文件（current_task.md）必须放在一个“每次会话都能被看到”的位置，并且每次开工前都强制先读。这个动作看起来简单，但它有效解决了“AI 没有跨会话记忆”的基础问题。你不需要给它写一个几十 M 的知识库，只需要给它一个“开工前先看黑板”的习惯，项目的一致性就能提高一大截。
如果你刚开始尝试，建议不要一次把五个角色全铺开。先只加一个 Reviewer，让它在每次开发完成后挑一遍毛病，跑顺手了再加入 Chronicler 做复盘，最后再把 Director 和 Architect 请进来管计划。一层一层加，出了问题也好定位。我现在跑这套流程已经三个月，最大的感受是：AI 写代码的速度不是瓶颈，团队的一致性才是。gstack 解决的就是一致性这件事——至于代码本身，模型从没让我失望，让我失望的永远是那个“不读纪要就动手”的我自己。
