gstack Pacing Updates 设计解读：如何把 30–50 次审查中断压缩到可接受范围

gstack Pacing Updates 设计解读如何把 30–50 次审查中断压缩到可接受范围【免费下载链接】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本篇解读 gstack 仓库中的设计文档 PACING_UPDATES_V0.md状态V1.1 计划尚未实现它回答了一个具体的工程问题当一套 AI 审查流水线/autoplan在一次约 45 分钟的运行里向用户抛出 30–50 次AskUserQuestion提问时如何通过节奏pacing改造把中断量压下来同时不牺牲安全性one-way door 决策必须全量呈现。读完本文你能理解该方案的问题建模、十个结构性缺陷、十项改造范围、可量化的验收标准以及它如何与仓库中已有的 question-log、问题注册表、one-way 分类器等基础设施对接。1. 问题来源两种疲劳两种解法设计文档的开篇把非技术用户阅读 gstack 审查输出时的疲劳归结为两个独立来源术语密度Jargon density——技术术语出现时没有解释。这一半由 V1 计划ELI10 写作标准解决对应 PLAN_TUNING_V1.md 中的写作风格规范术语首用注释、结果导向措辞、短句。中断量Interruption volume——/autoplan依次运行 4 个阶段CEO Design Eng DX每个阶段触发 5–10 次AskUserQuestion提问全链路约 30–50 次持续约 45 分钟。文档给出的关键经验值是非技术用户在约 10–15 次中断后就开始走神。这一半正是本文V1.1的主题。文档用一句话点明方案边界Translation alone doesnt fix interruption volume. A translated interruption is still an interruption.光做翻译修不了中断量被翻译过的问题依然是问题。因此修复必须改变发现何时浮出水面WHEN findings surface而不仅是措辞怎么写HOW theyre worded。这与 autoplan/SKILL.md 中的真实阶段结构相互印证Phase 0.5 预检后Phase 1CEO必跑、Phase 2Design仅当检测到 UI 范围、Phase 3Eng必跑、Phase 3.5DX仅当检测到开发者向范围每个阶段都以STOP标记开头要求先 Read 对应sections/*-phase.md再执行阶段之间Each phase MUST complete fully before the next begins。每个阶段内部的 STOP/AskUserQuestion 序列是硬编码在技能模板里的这正是后文结构性缺陷 #4的由来。2. 为什么被从 V1 中拆出来10 个结构性缺陷Pacing 工作流最初是 V1 计划的一部分在 PLAN_TUNING_V1.md 的Revision 3中被提出给发现排序、自动接受 two-way door、每阶段最多 3 次提问、Silent Decisions 块、flip id命令。第三轮 Eng Review 加第二轮 Codex Review 暴露出 10 个无法靠改计划文字修复的缺口文档因此被整体拆出进入独立的 V1.1 设计轮次。这 10 个缺口可以归为五类a状态模型缺失#1、#5Pacing 需要每阶段状态哪些发现已浮出、哪些被自动接受、哪些用户还能翻回。V1 只有每次技能调用级别的状态用于 glossing没有承载每阶段 pacing 记忆的后端存储。回复flip id可更改原本只是一句散文承诺没有命令解析器、没有状态存储、没有重放行为。一旦对话被压缩、Silent Decisions 块滑出上下文原始决策就丢了。b观测基础设施缺字段#2静默 Eng 审查 #8 希望在单阶段内提问超过 3 次时告警但 V0 的question-log.jsonl没有phase字段V1 声称无需 schema 变更与这个强制目标自相矛盾。仓库中 bin/gstack-question-log 的现行 schema 确实只有skill / question_id / question_summary / category / door_type / options_count / user_choice / recommended / followed_recommendation / session_id / ts / source等字段——没有phase证实了该缺口。c注册表覆盖不了动态发现#3scripts/question-registry.ts 的注册表覆盖的是问题在技能定义时静态注册约 30–50 个常见类别one-way door 覆盖率要求 100%。而审查发现review findings是运行时动态生成的agent 会随手生成{skill}-{slug}形式的临时 id。靠注册表做door_type: one-way强制执行对 ad-hoc 发现无能为力——agent 审查中途生成的一-way 安全性无法强制执行。d散文规则无法反转既有控制流#4V1 打算在 preamble 散文里加一条先排序再提问的规则。但现有技能模板如plan-eng-review是按小节硬编码STOP/AskUserQuestion 序列的preamble 里的一句散文规则无法可靠覆盖模板中每一节的 STOP。文档的结论很明确The behavioral change is sequencing, not prompt wording.行为改变在于执行顺序不是提示词措辞。e边界中断与未校准的参数#6、#7、#8、#9、#10升级后的迁移提示提供恢复 V0 散文本身算一次中断会挤占 V1.1 想压缩的预算首跑的 lake intro、telemetry、proactive、routing 注入等 meta-prompt 也都发生在第一个真实技能运行之前同样要计入。排序公式从未用真实数据校准V1 先后考虑过product 0-8被证明取值分布是{0,1,2,4,8}公式失效和sum 0-6加阈值 ≥4但都没对照过真实发现分布。每个 one-way door 都必须浮出与每阶段最多 3 次两条规则同时存在却未声明优先级逻辑上矛盾。验证值未定义Silent Decisions 块的 ≥ N 条 中 N 从未给值吞吐量 JSON 的active: true字段也无定义。3. V1.1 的十项范围文档的 Scope 部分给出 10 项具体改造逐项对应上述缺口定义会话状态模型——per-skill-invocation / per-phase / per-conversation 三选一后端存储预计为~/.gstack/sessions/session_id/pacing-state.json记录每阶段已浮出 vs 自动接受的发现清单清理 TTL 与 preamble 中既有的会话跟踪120 分钟见 plan-tune/SKILL.md 的 preamble 中find ~/.gstack/sessions -mmin 120逻辑保持一致。question-log schema 增加phase字段——把每次 AskUserQuestion 归入其来源阶段CEO / Design / Eng / DX / other存量条目默认unknown非破坏性扩展。扩展注册表对动态发现的覆盖两个候选方案CEO review 时二选一(a) 拓宽scripts/question-registry.ts支持运行时注册ad-hoc id 也要被记录并分类(b) 新增二级运行时分类器scripts/finding-classifier.ts用模式匹配把发现文本映射到风险层级。把 pacing 从 preamble 散文移入技能模板控制流——更新每个审查技能模板使其按显式序列执行(i) 阶段内部先跑完(ii) 用gstack-pacing-rank二进制对发现排序(iii) 最多发出 3 个 AskUserQuestion(iv) 其余打包为 Silent Decisions 块。这不是 preamble 规则而是模板中的显式执行顺序。实现 flip 机制——新二进制bin/gstack-flip-decision从用户消息解析flip id在 pacing-state.json 中查原始决策重新展开为一个显式 AskUserQuestion用户新选择持久化。迁移提示的预算裁定——一次性迁移提示豁免于每阶段中断预算理由它们在审查阶段开始之前触发而不是期间。首跑 preamble 审计——逐个审计 lake intro / telemetry / proactive / routing 注入对首次用户是承重件还是可延后文档预判的结果是除 lake intro 外全部压到第 2 个会话之后其余通过用户自愿调用的/plan-tune first-run提供。排序阈值校准——V0 的 question-log 已在运行且有历史数据先测量近期 CEO Eng DX Design 审查中severity × irreversibility × user-decision-matters的真实分布再定阈值。目标约 20% 的发现浮出约 80% 自动接受。显式规则one-way door 不设上限——硬编码进技能模板散文one-way doors surface regardless of phase interruption budgettwo-way 发现每阶段上限 3 个。给出具体验证值——定义 Silent Decisions 的 N例如非平凡计划预期 ≥ 5 条并给吞吐量 JSON 定义具体字段名。4. 与仓库现有基础设施的对接源码佐证设计文档不是凭空立论其每一项都与仓库中已存在的机制衔接。以下几处源码可以让锦上添花部分落到实处。4.1 问题日志中断量的数据底座bin/gstack-question-log 是 append-only 的 JSONL 写入器落盘到$GSTACK_HOME/projects/SLUG/question-log.jsonl。它对每个事件做严格校验skill必须 kebab-casequestion_summary限 200 字符且经hasInjection()共享自 lib/jsonl-store.ts 的审计模式列表做注入防御user_choice限 64 字符自动计算followed_recommendation比较前会剥掉双方尾部的(Recommended)标记。它还支持source字段区分写入方agent/hook/auto-decided等并对source:tool_use_id组合做 100 行窗口去重。写入后以 fire-and-forget 方式触发gstack-developer-profile --derive维持推断维度最新。V1.1 的每阶段可观测性/plan-tune能显示任意会话的每阶段 AskUserQuestion 计数正是建立在这条数据流之上——只需补一个phase字段。文档 #2 指出的矛盾在于V1 声称无 schema 变更而告警目标恰恰依赖该字段。4.2 问题注册表与 door_typeone-way 安全的主闸门scripts/question-registry.ts 中每个注册项都声明door_type: one-way | two-way注释规则是one-way 用于破坏性操作、架构/数据模型分叉、超 1 天 CC 工作量的范围扩张、安全合规选择ALWAYS asked regardless of user preferencetwo-way 可被显式用户偏好自动决策。文件头注释说明注册表是/plan-tune的底座question-log 用它打标、question-preferences.json以它为键、心理画像信号映射scripts/psychographic-signals.ts以(id, user_choice)查维度增量。Pacing 方案的排序前提就是这套 door_type 分类预算优先花在最难逆转的决策上见第 6 节的 fork 合并决策two-way 发现才允许进自动接受通道。4.3 双层 one-way 防线注册表 关键词兜底scripts/one-way-doors.ts 是第二道防线classifyQuestion()的判定顺序在文件头注释中写得很清楚按question_id查注册表命中则直接用注册表的door_typereason:registry未命中则查技能类别兜底——cso:approval与land-and-deploy:approval组合恒为 one-way再对question_summary做破坏性关键词正则匹配rm -rf、force push、git reset --hard、drop table、terraform destroy、rollback、凭据 revoke/reset/rotate 等reason:keyword无任何证据时默认 two-way。文件头特别引用了 V1 设计文档 Decision C 的结论散文解析太弱不能当主闸门——措辞会变注册表才是主闸门这里只是未编目问题的兜底。 这一分层结构与 V1.1 范围 #3 中方案 (b)运行时finding-classifier.ts模式匹配器在方法论上同源动态发现也需要先查注册表、再用模式匹配兜底、保守倾向多问一句的次序。4.4 用户偏好检查AUTO_DECIDE 通道已经存在bin/gstack-question-preference 提供--check id输出三态ASK_NORMALLY/AUTO_DECIDE/ASK_ONLY_ONE_WAY偏好值只能是always-ask/never-ask/ask-only-for-one-way且对注册表 one-way id 拒绝写入never-askalways-ask 在 one-way id 上没问题因为它与安全覆盖一致。autoplan/SKILL.md 中每个提问前的流程是从注册表或{skill}-{slug}选question_id然后管道调用gstack-question-preference --check id --summary-stdin摘要走 stdin 喂给 one-way 关键词网AUTO_DECIDE意味着选推荐项并注明 Auto-decided [summary] → [option] (your preference). Change with /plan-tune.。这正是 V1.1 要提速的既有管道现状是逐题询问偏好V1.1 要在阶段维度上批量做排序 自动接受 Silent Decisions 块并保证 one-way 恒问。4.5 模板硬编码 STOP为何散文规则失效autoplan/SKILL.md 展示了缺口 #4 所指的具体形态每个阶段以**STOP.** Before starting Phase N ... Read sections/phase.md and execute it的模板指令开头且NEVER run phases in parallel — each builds on the previous。这意味着先内部跑完一个阶段、再统一提问的行为改变必须落在各阶段模板的执行序列上范围 #4 的第 (ii)(iii)(iv) 步而不是加一句 preamble 散文。5. 验收标准可重跑、可计数的定义文档的 Acceptance criteria 全部是可测量的中断计数Louise或同等非技术协作者在一份与 V0-baseline 相当的计划上端到端重跑/autoplanAskUserQuestion 次数≤ V0 基线的 50%V1 负责捕获基线转录供 V1.1 校准。one-way 覆盖100% 安全关键决策door_type: one-way或被分类器标记的动态发现以完整技术细节逐条浮出不设上限。Flip 往返用户输入flip test-coverage-bookclub-form原自动接受决策重新展开为 AskUserQuestion用户新选择持久化进 Silent Decisions 块或若翻回显式浮出则从块中移除。每阶段可观测性/plan-tune可读取 question-log.jsonl 的新phase字段显示任意会话的每阶段 AskUserQuestion 计数。首跑削减新用户第一个真实技能运行前看到的 meta-prompt≤ 1 个仅 lake intro对比 V1 的 4 个lake telemetry proactive routing。人工重跑Louise 与 Garry 独立定性评审模式同 V1。6. 对 V1 的依赖与明确不碰的东西V1.1 构建在 V1 的基础设施之上explain_level配置键与 preamble 回显模式V1 的 A4 项、术语表 写作风格节V1.1 的中断措辞本身要遵守 ELI10 规则、V0 休眠负向测试V1.1 同样不能唤醒 5D 心理画像机器、以及 V1 捕获的 Louise 转录验收校准基线。文档同时声明 V1.1不依赖任何 V2 项E1 substrate wiring、narrative/vibe 等。NOT touched in V1.1 一节列出的 V2 延后项包括困惑信号检测、5D 心理画像驱动的技能自适应V0 E1、/plan-tune narrative/plan-tune vibeV0 E3、per-skill 或 per-topic 的 explain 级别、团队画像、基于 AST 的已交付功能指标。7. Fork 合并链级chain-scoped预算记账文档末尾的Fold-in from fork port wave 2 (2026-08-14)记录了与 time-attack/gstack fork 的取舍该 fork 从互补轴攻击同一问题——用构建规模分类session/hobby/project/product/venture决定机器体量并引入全链提问预算。2026-08-14 CEO review 批准的合并决策是只吸收 fork 的记账判断不吸收其数值常量。具体规则四条预算是链作用域的链式审查从剩余预算中扣减绝不重置阶段交接时携带questions-already-spent已花费的提问数审批/变更门approval/mutation gates永不计入预算预算优先花在最难逆转的决策上。文档明确拒绝采纳 fork 的 5/8/12 数值常量——因为 fork 自己后来用零默认的自主性拨盘取代了它们。分工被表述为Scale sizes the machinery and sets the budget; pacing (this doc) ranks what the budget is spent on.规模决定机器体量并设定预算pacing 决定预算花在哪。8. 评审计划与文档定位评审计划本身也体现了 gstack 的审查文化预工作是从当前 V0 数据捕获真实 question-log 分布作为范围 #8 的校准输入CEO review 要求挑战前提pacing 是对的药吗还是干脆把 4 个阶段合并成一次统一审查scope 模式预判为 SELECTIVE EXPANSIONCodex 独立过一遍重点盯范围 #4 的控制流改动V1 在这里翻过车DX review 专注 flip 机制——flip id是否可发现、命令语法是否自然、错误路径是否清晰Eng review 预期多轮。综合来看PACING_UPDATES_V0.md 的价值不在任何单条技术点而在于它示范了 AI 驱动的开发工具如何量化人机中断成本以 bin/gstack-question-log 的 JSONL 流水为数据底座以 scripts/question-registry.ts 的 door_type 分类为安全不变式以 scripts/one-way-doors.ts 的双层判定为兜底防线再叠加每阶段 ≤3、one-way 不设上限、~20% 浮出 / ~80% 自动接受的量化目标与可重跑的验收标准。若你正在设计多阶段 LLM 审查流水线这套中断预算 门型分类 决策可翻转的组合是一个可以直接对号参考的工程范式。【免费下载链接】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），仅供参考