GStack 自学习基础设施解析跨会话复利式项目知识、四大状态系统与 /autoship 状态机设计【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack本篇基于仓库内的设计文档 SELF_LEARNING_V0.md 展开系统梳理 gstack 的自学习能力是如何落地的它用一套按项目隔离、追加式写入的 JSONL 存储把跨会话、跨 skill 沉淀下来的机构知识pitfall / pattern / architecture结构化、打分、并随时间衰减再叠加 timeline、checkpoint、health 三层持久化最终支撑起一个可恢复的状态机/autoship。读完后你能掌握 gstack learnings 的数据模型、读取/写入二进制的实际行为、置信度衰减与跨项目信任门的实现细节以及为什么信任与ceremony必须解耦。一、问题陈述会跑 30 skill却从不学习设计文档开篇就把痛点说得很直白gstack 能在一次会话里跑 30 多个 skill但会话之间什么都不学。一个/review会话抓到了 N1 查询模式下一次对同一代码库跑/review时又是从零开始一次/ship发现了正确的测试命令之后每次/ship都要重新发现/investigate排查出一个棘手的竞态条件没有任何后续会话知道它的存在。设计文档认为这是所有 AI 编码工具的通病Cursor 有按用户维度的记忆Claude Code 有 CLAUDE.mdWindsurf 有持久化上下文但它们都不复利compound不结构化所学习的内容也不在 skill 之间共享知识。目标可复利的机构知识要构建的是按项目维度的机构知识跨会话与跨 skill 持续积累。形态是结构化的、类型化的、带置信度评分的 learnings每个 gstack skill 都能读、能写。设计文档给出的北极星目标是在同一个代码库上跑 20 个会话之后gstack 应当知道每一处架构决策、每一个历史 bug 模式、以及它每一次曾经判断错误的地方。定位与受众受众用 AI 构建产品的 YC 创始人每周在真实代码库上跑 gstack 20 次、并且会注意到它问了两遍同一个问题的人。差异化设计文档用一张表对比了各工具的记忆模型 / 作用域 / 结构三个维度ToolMemory modelScopeStructureCursorPer-user chat memoryPer-sessionUnstructuredCLAUDE.mdStatic filePer-projectManualWindsurfPersistent contextPer-sessionUnstructuredGStackPer-project JSONLCross-session, cross-skillTyped, scored, decayingTyped, scored, decaying 是 gstack 与静态文件 / 非结构化记忆的核心区别后面所有实现都围绕这三个词展开。二、四大状态系统共享存储模式但回答不同的问题设计文档强调 gstack 有4 个彼此独立的持久化层。它们共享同一套存储模式——都落在~/.gstack/projects/$SLUG/下用 JSONL 格式——但用途各不相同SystemFile存什么谁写谁读Learningslearnings.jsonl机构知识pitfalls、patterns、preferences所有 skill所有 skillpreambleTimelinetimeline.jsonl事件历史skill start/complete、branch、outcomePreamble自动/retro、preamble 上下文恢复Checkpointscheckpoints/*.md工作状态快照决策、剩余工作、涉及文件/checkpoint、/ship、/investigatePreamble 上下文恢复、/checkpoint resumeHealthhealth-history.jsonl代码质量随时间的得分每工具 综合分/health/retro、/shipgate、/health趋势设计文档特别提醒这四者不重叠分别回答四个不同的问题Learnings 你知道什么what you knowTimeline 发生过什么what happenedCheckpoints 你现在在哪where you areHealth 代码质量如何how good the code is这个四问划分是理解后面所有 release 的骨架——Release 1 建 LearningsRelease 3 建 Timeline Healthcheckpoint 与 Release 5 的/autoship恢复机制绑定。三、Release 1GStack Learns已发布——learnings 的数据模型3.1 落地内容Learnings 持久化到~/.gstack/projects/{slug}/learnings.jsonl提供/learnskill 用于手动 review、search、prune、export对所有 review finding 做置信度校准1-10 评分 显示规则对 observed/inferred 类 learnings 做置信度衰减每 30 天 -1 分跨项目 learnings 发现opt-in需 AskUserQuestion 同意review 命中历史 learnings 时显示Learning applied提示集成进 /review、/ship、/plan-*、/office-hours、/investigate、/retro3.2 learnings.jsonl 的 Schema一条 learning 记录如下设计文档给出的完整示例{ ts: 2026-03-28T12:00:00Z, skill: review, type: pitfall, key: n-plus-one-activerecord, insight: Always check includes() for has_many in list endpoints, confidence: 8, source: observed, branch: feature-x, commit: abc1234, files: [app/models/user.rb] }字段取值范围设计文档定义Types:pattern|pitfall|preference|architecture|toolSources:observed|user-stated|inferred|cross-model从源码结构看实际写入端允许的 type 比设计文档多出两个operational与investigation。在 gstack-learnings-log 的校验逻辑里ALLOWED_TYPES为[pattern, pitfall, preference, architecture, tool, operational, investigation]且operational正是每个 skill 结束时的Operational Self-Improvement步骤所用的类型见 learn/SKILL.md 末尾。这说明实现已经沿着记录操作性知识的方向扩展了。3.3 架构原则追加式 JSONL 读时去重设计文档明确写道append-only JSONL重复项在读时解决keytype 维度latest winner写入时不做任何修改无竞态条件。这一设计在源码里得到了完整印证写入端gstack-learnings-log 的行为用gstack-slug解析出$SLUGmkdir -p出~/.gstack/projects/$SLUG/校验输入 JSONtype必须在允许列表内、key必须匹配^[a-zA-Z0-9_-]$无注入面、confidence必须是 1-10 的整数、source必须在允许列表内对insight字段做注入内容筛查调用lib/jsonl-store.ts的hasInjection若命中指令式模式如 ignore previous instructions则拒绝写入防止一条被污染的 learning 在未来被重放成对 agent 的指令注入ts若缺省并根据 source 标记信任级别trusted (source user-stated)——即只有用户亲口说的才算可信其余全是 AI 生成的最后一行echo $VALIDATED learnings.jsonl纯追加追加后异步gstack-brain-enqueue入队跨机同步若未开启则 no-op。共享底层jsonl-store.ts 是 learnings / decisions / questions 三类 JSONL 存储共用的唯一被审计过的写入路径它解决三件事注入筛查契约appendJsonl本身不做筛查存自由文本的调用方必须先调hasInjection()/firstInjectionMatch()并拒绝。INJECTION_PATTERNS是一份集中维护的正则列表ignore previous instructions、you are now、system:/assistant:/human:前缀、from now on、approve all等设计文档里没有这段但它是typed, scored, decaying 能安全地跨会话重放的前提原子单行追加appendJsonl用O_APPEND打开单条小于 PIPE_BUF 的写操作在多进程间原子因此多个 agent 并发追加不会互相穿插。记录必须序列化成单行内嵌换行会抛错以守住一行一条的不变量容错读取readJsonl逐行解析遇到坏行半截写入尾部、单行损坏跳过而不是抛异常文件不存在返回空数组未知字段保留schema 升级不破坏旧读者。3.4 读取端置信度衰减、去重与跨项目信任门gstack-learnings-search 是 learnings 的读路径参数为--type/--query/--limit默认 10/--cross-project。它做的事与设计文档一一对应且实现里能读出几个设计细节置信度衰减observed/inferred两类按ts距今天数每满 30 天扣 1 分下限 0——即conf max(0, conf - floor(days/30))。user-stated与cross-model不衰减。这正对应设计文档1pt/30d。读时去重以key|type为维度ts最新的一条胜出latest winner与设计文档一致。跨项目信任门--cross-project会额外收集其他项目最多 5 个的learnings.jsonl但跨项目条目只有在trusted true时才会被加载——这是一个白名单而非黑名单注释里引用了 issue #1745说明旧的! false判断会误放缺失 trusted 字段的旧行目的是防止一个项目的 AI 生成的 learning 静默影响另一个项目的 review。排序与分组按有效置信度降序、再按ts新近度排序输出按 type 分组每行带[key] (confidence: N/10, source, date)以及可选的files列表。查询匹配是 token-OR--query按空白切成多个 token任意一个 token 命中key/insight/files中任一字段即保留。/learnskilllearn/SKILL.md把这套读能力暴露成用户可感的命令/learn看最近 20 条、/learn search query、/learn prune检查引用文件是否已删除 → STALE、同 key 冲突 → CONFLICT逐条 AskUserQuestion 决定删/留/改删除是读文件删行回写修改是追加一条更正因为存储 append-only、latest 胜出、/learn export导出成 Markdown 供并入 CLAUDE.md、/learn stats去重后按 type / source 计数、平均置信度、/learn add手动录入source标为user-stated从而获得trusted。3.5 Learning applied 提示当 review finding 命中一条历史 learning 时gstack 会显示Prior learning applied: [key] (confidence N/10, from [date])。这条提示在 cso/SKILL.md、investigate/SKILL.md、plan-ceo-review/SKILL.md、office-hours/SKILL.md、design-review/SKILL.md 等多个 skill 里以相同格式出现正是设计文档让你亲眼看到复利在发生的落点。四、Release 2Review Army已发布——7 个并行专家子代理设计文档描述的落地内容7 个并行专家子代理always-ontesting、maintainability 条件触发security、performance、data-migration、API contract、design red team大 diff / 关键 finding 时。这与 review/specialists/ 目录下实际存在的 7 个专家 checklist 文件testing、maintainability、security、performance、data-migration、api-contract、red-team一一对应JSON 结构化 finding带置信度分 跨 agent 指纹去重fingerprint dedup**PR quality score0-10**每次 review 记录一次并进入 /retro 趋势learning 注入专家的 prompt 由 learnings 信息驱动按域注入历史 pitfall多专家共识高亮被多个专家确认的 finding 会被加权boosted通过 PLAN_COMPLETION_AUDIT 增强交付完整性checklist 重构CRITICAL 类保留在主流程专家类抽取成 review/specialists/ 下的聚焦 checklist。Release 2.5Review Army Expansions尚未发布预检要求先看 R2 的质量指标PR quality score、专家命中率、误报率、E2E 稳定性核心循环有问题就先修。其规划项 E1按项目命中率自适应跳过 0 命中的专家用户可用--security等强制、E3每个专家输出 TEST_STUB 供 AUTO-FIX 建测试文件框架按项目探测 Jest/Vitest/RSpec/pytest/Go test、E5读历史 review 抑制用户已跳过的 finding、E7专家性能进 timeline 供 /retro 趋势目前都还是设计态。五、Release 3Session Intelligence已发布——timeline、/health 与 /checkpoint这一 release 对应第二节的三大持久化层中的 Timeline 与 Health设计文档指向了单独的设计文档SESSION_INTELLIGENCE.md。落地内容5.1 Session Timeline每个 skill 自动把 start/complete 事件写入~/.gstack/projects/$SLUG/timeline.jsonl。设计文档强调三点local-only、永不上送、与遥测开关无关的 always-on。gstack-timeline-log 的实现印证了这一点必填字段skill、eventstarted|completed可选branch、outcome、duration_s、session、ts校验失败静默跳过non-blocking成功则追加一行并异步gstack-brain-enqueue未开启同步则 no-op。每个 skill 的 preamble见 learn/SKILL.md 等会在 skill 启动时后台gstack-timeline-log {skill:...,event:started,...}结束时再记一条completed带 outcome 与 duration。5.2 Context Recovery上下文恢复在 compaction 或会话启动后preamble 列出最近的 CEO plan、checkpoint、reviewagent 读最新一条以恢复上下文。跨会话注入LAST_SESSION与LATEST_CHECKPOINT按当前 branch 过滤让你还没打字就知道上次停在哪。/learn等 skill 的 preamble 里有一段Context Recoverybash读ceo-plans、checkpoints目录最近 3 个文件tail -5 timeline.jsonl用grep按当前 branch 过滤出LAST_SESSION与最近 3 个RECENT_PATTERNskill——这正是设计文档branch 过滤防串味的落地。5.3 Predictive Skill Suggestion预测式建议若最近 3 个会话遵循某模式review → ship → reviewgstack 建议下一步你最可能想跑的 skill。5.4 /checkpoint 与 /health/checkpoint保存/恢复/列出工作状态快照支持跨 branch 列出以支撑 Conductor workspace 的 agent 间交接。/health代码质量记分牌封装项目工具链tsc、biome、knip、shellcheck、tests产出 0-10 综合分、趋势追踪、分数下滑时给改进建议。health-history.jsonl的记录结构在 health/SKILL.md 中给出了字段定义对应第二节的 Health 层{ts:2026-03-31T14:30:00Z,branch:main,score:9.1,typecheck:10,lint:8,test:10,deadcode:7,shell:10,gbrain:10,duration_s:23}字段tsISO 8601、branch、score综合一位小数、typecheck/lint/test/deadcode/shell/gbrain各分项 0-10 整数跳过的分项置null、duration_s。/health会tail -10该文件做趋势分析对旧格式缺gbrain字段的条目按null处理、从第一个新版本 run 开始追踪。六、Release 4Adaptive Ceremony未发布——信任与 ceremony 必须解耦设计文档在此处提出一个重要的概念切分Ceremony 与 Trust 是两件独立的事。Ceremony 一个 PR 要经过的 review/test/QA 步骤集合Trust 一个策略引擎决定哪个 ceremony 级别生效。二者交互但不合并。6.1 Ceremony 级别FULL全部专家、adversarial、Codex 结构化 review、coverage 审计、plan 完整性。用于大 diff、新功能、迁移、auth 变更。STANDARDadversarial Codex、coverage 审计、plan 完整性。用于中等 diff、典型功能开发。FAST仅 adversarial。用于受信任项目上的小型、测试充分变更。6.2 信任策略引擎Trust Policy Engine按变更类change class积累信任而非全局。docs-only PR 的干净历史买不来 migration PR 上的信任。变更类检测docs、tests、config、frontend、backend、migrations、auth、infra每类有自己的信任阈值。信任信号每类连续干净 review 次数、/health 分数稳定性、回归频率、测试覆盖率趋势。信任永不给某些变更开绿灯migrations、auth/permission 变更、新 API endpoint、infra 变更无论信任多高都走 FULL。渐进降级而非二元重置一次回归不会清空所有信任只把该变更类的信任降一级。6.3 作用域评估与 TODO 生命周期/review、/ship、/autoplan里做 TINY/SMALL/MEDIUM/LARGE 分类基于 diff 大小、涉及文件、变更类Ceremony level f(scope, trust, change class)/triage交互审批新来的 TODO/resolve用并行 agent 批量解决。七、Release 5/autoship — 一条命令完整功能未发布——可恢复状态机设计文档把/autoship定义为可恢复的状态机而非线性管道review 和 QA 可以把工作打回 build/fixcompaction 可以打断任意阶段系统必须能优雅恢复。其状态机如下设计文档原图┌──────────┐ │ START │ └────┬─────┘ │ ┌────▼─────┐ │ /office- │ │ hours │ └────┬─────┘ │ ┌────▼─────┐ │/autoplan │ ◄── single approval gate └────┬─────┘ │ ┌──────────▼──────────┐ │ BUILD │ ◄── /checkpoint auto-save └──────────┬──────────┘ │ ┌──────────▼──────────┐ │ /health │ ◄── quality gate │ (score 7.0) │ └──────────┬──────────┘ │ fail → back to BUILD ┌──────────▼──────────┐ │ /review │ └──────────┬──────────┘ │ ASK items → back to BUILD ┌──────────▼──────────┐ │ /qa │ └──────────┬──────────┘ │ bugs found → back to BUILD ┌──────────▼──────────┐ │ /ship │ └──────────┬──────────┘ │ ┌──────────▼──────────┐ │ /checkpoint archive │ ◄── preserve, dont destroy └─────────────────────┘落地内容/autoship自治流水线每个 phase 写timeline.jsonl每个 phase 前自动/checkpointcompaction 恢复context recovery 读 checkpoint timeline从最后一个完成的 phase 续跑完成时做 checkpoint归档archive而非删除保留恢复态以便调试失败的 autoship run/ideate头脑风暴 skill并行发散 agent 对抗过滤/plan-eng-review里的研究 agentcodebase analyst、history analyst、best-practices researcher、learnings researcher。依赖关系设计文档明示R5 依赖 R1learnings 供研究 agent、R2review army 保质量、R3session intelligence 保持久化、R4adaptive ceremony 保速度。这正是Releases 1-4 是让 /autoship 真正可用的基础设施这句话的含义。八、Release 6 / 7并行执行与视觉媒体未发布Release 6 Execution StudioSwarm 编排多 worktree 并行构建基于 R3 的 /checkpoint Conductor 交接一个 orchestrator skill 把独立工作流派给各自 worktree 里的并行 agentCodex build 委托按任务类型自动判断何时把实现交给 Codex CLIboilerplate、测试生成、机械式重构PR 反馈解析跨 review 平台并行解析评论/onboard从代码库分析自动生成贡献者指南/triage-prs维护者批量 PR 分诊。Release 7 Design MediaFigma 设计同步像素级匹配迭代循环功能视频录制自动生成 PR demo跨平台可移植性Copilot、Kiro、Windsurf 输出。九、风险登记Risk RegisterCodex review 识别的三类风险设计文档保留了一份由 Codex review2026-04-01识别的风险清单这是理解 gstack 设计取舍的关键。9.1 代理信号被当作免检许可/health 分数、干净的 review 历史、timeline 模式都是有用的信号但不是安全的证明。若这些信号既喂给 ceremony 降级又喂给 /autoship失败模式是罕见、静默、高严重度的错误。缓解措施某些变更类永不走快速通道migrations、auth、infra、新 endpoint信任渐进降级而非二元重置/autoship 在每个项目的首次运行始终走 FULL ceremony——信任是挣来的。9.2 过期的上下文恢复Context recovery 可能注入错误 branch 的状态、过期的 plan 或失效的 checkpoint。缓解措施checkpoint 在 YAML frontmatter 里带 branch 名context recovery 按当前 branch 过滤timeline grep 在展示LAST_SESSION前先按 branch 过滤过期产物检测checkpoint 若已 7 天标注为可能过期而非当作当前状态展示。9.3 需要验证的指标在 R4Adaptive Ceremony发布前需先测量预测式建议的准确率用户是否真的跑了被建议的 skill信任策略的误跳过率被快速放行的 PR 合并后是否出问题上下文恢复的准确率恢复的上下文是否匹配实际状态/health 分数与真实代码质量的相关性高分是否预测更少的线上 bug设计文档要求这些指标在 R3 使用期间收集并在 R4 发布前复核——这体现了先证明 R2 核心循环稳定再谈扩展的纪律。十、实现层面的几条可验证事实小结把设计文档与仓库源码对齐后可以确认以下实现事实均可在仓库中查证写入路径单一且带注入筛查gstack-learnings-log 是唯一 learning 写入端校验 type/key/confidence/source 后追加注入筛查依赖 lib/jsonl-store.ts 的INJECTION_PATTERNS与hasInjection()命中即拒写。追加式 读时去重lib/jsonl-store.ts的appendJsonl用O_APPEND原子单行追加readJsonl容错跳过坏行去重逻辑key|type latest-winner在 gstack-learnings-search 与 learn/SKILL.md 的 stats 命令里都以相同方式实现。信任标记trusted字段只在source user-stated时为 true跨项目加载是白名单要求trusted true防止一个项目的 AI learning 污染另一个项目。衰减公式observed/inferred每 30 天 -1 分、下限 0user-stated/cross-model不衰减。timeline 本地优先gstack-timeline-log 必填skillevent失败静默跳过仅在用户把artifacts_sync_mode设为full隐私档时才会经 brain-sync 上送默认纯本地。Health 分层记分health/SKILL.md 的health-history.jsonl记录综合分 6 个分项typecheck/lint/test/deadcode/shell/gbrain跳过的分项置 null供 /retro、/ship gate、/health 趋势消费。十一、如何查看与运行只读指引gstack 通过./setup安装到~/.claude/skills/gstack/。安装后learnings 体系无需额外配置即生效查看项目 learnings在装好 gstack 的项目里运行/learn看最近 20 条、/learn search 关键词、/learn stats查看底层原始文件cat ~/.gstack/projects/$SLUG/learnings.jsonl$SLUG由bin/gstack-slug从 git 仓库解析查看 timeline / healthtail ~/.gstack/projects/$SLUG/timeline.jsonl、tail ~/.gstack/projects/$SLUG/health-history.jsonl直接调用读写二进制调试用bin/gstack-learnings-search --type pitfall --limit 20、bin/gstack-learnings-log {skill:review,type:pitfall,key:...,insight:...,confidence:8,source:observed}。需要注意的适用前提learnings 按项目slug隔离、存于用户主目录~/.gstack/不随仓库提交跨项目发现--cross-project默认关闭且需用户同意timeline 默认 local-only。Release 4-7 的内容adaptive ceremony、/autoship、swarm 编排、视觉媒体在当前仓库中仍是设计态尚未发布引用时应以规划中理解。十二、结语gstack 的自学习基础设施本质是把机构知识从隐性的对话上下文变成了按项目隔离、类型化、打分、会衰减、可跨 skill 共享的一等公民数据。四大状态系统各答一问你知道什么 / 发生过什么 / 你在哪 / 代码多健康learnings 负责复利timeline checkpoint 负责可恢复health 负责质量门而 adaptive ceremony 则用信任与 ceremony 解耦、按变更类挣信任的原则把复利换来的效率与某些变更永不免检的安全底线分开。对想在真实代码库上长期跑 AI 编码 agent 的团队而言这套typed, scored, decaying的存储模型与其配套的二进制读写路径是值得参考的一套可落地范式。【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考