两触点发版简报
你是一人平台发版顾问。只根据用户约束写提问清单，不要编造已自动驾驶。
仓结构：{{repos}}
是否常驻第二台机：{{always_on}}
合入前必审：{{merge_gates}}
输出 Markdown：
1. 编排/前端构建/后端构建职责与禁止项
2. 计划+RED 停与派工话术
3. 评审→反驳→走查门禁
4. 人工生产合入清单
禁止建议自动 merge；禁止声称吞吐已达标。← 返回用例列表
Batuhan：一人 IoT 平台两触点——编排审范围，构建到预发再合入
对照独立开发者实践：编排仓与前后端构建仓分席；披露计划+RED 停、评审+反驳、Chrome 走查，以及约 80% 做产品/20% 养流程；不代你吞吐、不外推。
场景说明
面向一人扛平台前后端又不想读每一行的创始人：把「再开 Agent Teams」写成可对账的两触点+瑞士奶酪门禁+跨会话消息，区别于 Hive Lead/Worker 与 hooks 工作流引擎。
案例叙事
01他们做了什么
Batuhan Ergör 在《How I ship for my company's platform on (almost) autopilot》（页内 16 October 2026 → 2026-10-16）写明：一人经营医院/餐饮卫生监测 IoT 平台 YIKA，过去一年产品优先、重回键盘。今日发版只保留两触点——(1) 指向任务，编排 Agent 起草范围供他审，批准后派给前端/后端构建 Agent；(2) 预发验证完成且生产 PR 打开后再审合入。中间无人接力。三席皆为 Claude Code：编排仓无产品代码，只持待办、每任务规格、会话 recap、从错误学来的规则与 skills；构建席各在自己代码仓加载规则与记忆。家用第二台笔记本 24/7，tmux 常驻，SSH/手机 Claude App 连入；编排与构建靠跨会话消息直连，单订阅。
流程强调「瑞士奶酪」层叠：范围 skill 会先用多角度新鲜子代理攻击规格（含不可逆性排序），再给人看；派工给目标与约束而非命令，并强制「先挑战隐含假设」；构建先交计划+失败测试（RED）再实现；绿测后新鲜评审→反驳，存证或修或记债；编排再用 Claude in Chrome 在本地/预发/生产走查。作者称约 80% 时间做产品、20% 养 skills/hooks/规则；规则堆肥会剪枝，屡次失败则升格为结构（如审阅者必须在 worktree、STE 句长 hook）。本场景据此输出「两触点瑞士奶酪」提纲。禁止建议取消生产合入人审。
02实际效果
- 源披露两触点、计划+RED 停、评审+反驳+Chrome 走查，以及约 80%/20% 产品与流程投入等作者窗口口径；属一人 IoT 平台叙事，不可外推为你的发版吞吐或缺陷率。
- 能把「再开 Agent Teams」与「编排仓分席 + 跨会话消息 + 门禁碰撞」拆开。
- 为虚假绿测、评审改坏工作树与走查看漏整屏提供提问清单。
03值得知道
- 强依赖 Claude Code 跨会话消息与常驻第二台机；订阅与网络中断会卡住流水线。
- 日历工期变长是故意的；默认可串行而非并行车道。
- 上面写的是个人博客实践帖，不是 Anthropic Agent Teams 官文。
04可复制提示词
虚假绿测复盘提纲
构建席报告「22 测全绿」但你一问发现无人读测文件，请写复盘提纲。
摘要原话：{{summary}}
真实测文件摘录：{{tests}}
输出：
1. 是摘要崇拜、缺「故意弄坏代码看测是否红」，还是编排未抽查
2. 门禁最小补丁
3. 下次验收标准
4. 人工确认清单
不要伪造「绿测已永可信」。怎么做
- 粘贴前后端仓结构、是否常驻第二台机，以及合入前必须人审哪些点
- Agent 按实践帖输出：两触点职责→计划+失败测试停→评审/反驳/走查提问清单
- 人工保留生产合入；Agent 不代你声称已自动驾驶上线
实用提示
- 源帖：故意不用 Claude Code Agent Teams——构建席要常驻规则与教训，评审席才要无历史的新鲜子代理
- 与 chris-gmyr-hive-lead-codex-workers / nick-tune-claude-hooks-workflow-engine 不同：本条是编排仓无产品代码+瑞士奶酪碰撞门禁，不是本地 SQLite Lead/Worker 或 hooks 引擎