企业官网建设流程全解析

导读

本文围绕 Skills 仓库中的 workflow-threads-manager 技能展开，它解决的是一个真实且棘手的场景：多个 Claude 会话（线程）在同一个仓库上并行开发，需要一个专门的线程来统筹监督它们。读完本文，你将掌握一套完整的"线程管家"工作流——如何用会话管理工具与 Shell/Python 脚本核对main分支上的合并情况、验证线上站点健康度、逐个会话分诊归档、补齐 changelog 缺口，并遵守防止"权限洗白"等安全护栏。这套机制与仓库中的 workflow-ship-change、workflow-progress-screenshots 等技能共同构成多 Agent 协作的日常运营体系。

一、技能定位：为什么需要一个"线程管家"

当用户在同一仓库上同时运行多个 Claude 线程时，每个线程各自修改代码、提交推送、发布上线，很容易出现三方面失控：

1. 合并与发布失联：某线程声称"已推送"，但变更是否真正落在main、是否带上了 changelog 条目与截图，无人核验；
2. 会话状态不明：哪个线程还在运行、哪个已经结束、哪个因为应用重启被拦腰截断、哪个正在等待用户答复，难以快速掌握；
3. 资源与纪律失控：已完成的线程占用 worktree，未完成的线程遗留半截工作，还有线程可能试图重复执行其他线程被权限系统拦截过的操作。

workflow-threads-manager就是为这一场景设计的专职"监督线程"。其工作目录 SKILL.md 明确了每次检查需要回答的四个核心问题：

1. 上次检查以来main上落了什么，每个变更是否都有带截图的 changelog 条目；
2. 线上站点是否健康且与main同步，还是已损坏或落后；
3. 每个线程正在做什么：运行中、已完成、任务中途被截断，还是等待用户；
4. 什么可以归档，什么还需要用户介入。

技能文档还强调一个关键规则：如果该技能目录下存在references/<project>.md（当前项目专属的 changelog 格式、线上站点、截图目录等约定），必须先读取；同时每次检查都要先读项目根目录的AGENTS.md，因为其他线程会不断更新规则（线上主机、changelog 格式、体积限制等），当AGENTS.md与本技能冲突时，以AGENTS.md为准。这与 workflow/README.md 中"项目特性放在项目的 AGENTS.md 或技能旁的 references/ .md"的移植性设计一致。

二、工具清单：会话管理工具与五个脚本

2.1 会话管理工具（Session tools）

技能依赖mcp__ccd_session_mgmt__*前缀的会话管理 MCP 工具。文档特别提醒：如果这些工具只以 deferred（延迟加载）名称出现，需要先用 ToolSearch 加载。核心工具及其用途如下：

2.2 scripts/ 下的五个脚本

技能目录 scripts/ 下提供五个配套脚本。技能强调：它们在负载高时运行较慢，应当用run_in_background在后台运行并读取输出文件。逐个看：

• repo-status.sh：仓库侧的"体检报告"。输出origin/main当前所在提交、本地分支中main尚缺的提交、以及带有未提交改动的工作树（附最新编辑时间，用于区分活跃线程与遗弃工作）。从 repo-status.sh 源码看，它通过git for-each-ref遍历本地分支并用git rev-list --count origin/main..$b计算每个分支领先main的提交数；再用git worktree list --porcelain枚举工作树，对每个工作树执行git status --porcelain过滤掉未跟踪项（grep -v '^??'），统计未提交的受跟踪文件数、最新编辑时间，并标记是否被锁（locked）。
• audit-changelog.py <since-rev>：从指定修订开始审计main上每个提交。输出每个提交新增的版本号、其配图"已上线数/需要数"，以及 "NO VERSION" 标志；只改动测试、文档或脚本的提交被标记为 exempt（豁免）。从 audit-changelog.py 源码看，它解析src/changelog.js中形如v('0.1.N', 'YYYY-MM-DD', '<id>', '<title>', '<note>', <big: true|false>, <commit|null>)的条目（该格式来自 build-game-changelog 模式），通过git show对比提交前后 changelog 的差异来确定每个提交新增的版本；"big" 版本需要三张图（<id>、<id>-2、<id>-3），"small" 版本只需要一张（<id>）；豁免规则EXEMPT匹配tests/、docs/、AGENTS.md、CLAUDE.md、README.md、scripts/、.github/、qa/前缀。--pictures默认取origin/main上*/changelog/路径下图片最多的目录。
• live-check.sh [url]：健康检查脚本。先抓取线上页面，再抓取页面引用的脚本与美术资源。页面返回 200 而资源返回 404 即视为部署损坏。从 live-check.sh 源码看，它用curl -w '%{http_code}'抓页面，再用正则(src|href)="/[^"]+"提取页面引用的静态资源路径逐一请求；对 3xx 重定向会跟随到最终地址（例如美术资源存放在存储桶时重定向是正常的），只要最终落在 2xx 即算通过；任一被检查文件未加载则输出BROKEN并统计失败数。该脚本同时支持LIVE_URL环境变量和额外的路径参数。
• save-captures.sh <worktree> <name>：归档前的"截图保全"。若工作树有未保存或未合并的工作则拒绝执行（退出码 2）；否则把被 gitignore 的截图复制到qa/captures/archived-threads/<name>/。从 save-captures.sh 源码看，它检查git status --porcelain的非??改动数与origin/main..HEAD的领先提交数，两者均需为 0 才安全；随后用 rsync 把<worktree>/qa/captures/复制到主 checkout 的qa/captures/archived-threads/<name>/（同样被 gitignore）。
• contact-sheet.py <out.jpg> --count N：把最近 N 条 changelog 条目的配图拼成一张联系表（contact sheet），直接读取origin/main，无需检出。从 contact-sheet.py 源码看，它默认取最新 12 条条目，big 版本展示三张图（开始、关键瞬间、结果），small 版本展示一张；用 PIL 拼成 3×N 的深色底版面并给每行标注版本号、标题与日期，--count可调整条数。

三、检查流程：一次标准"线程巡检"的八个步骤

技能文档给出了完整的检查步骤，每次检查都应当按此执行：

1. git fetch，然后列出上次检查以来的提交：git log --no-merges <last>..origin/main（<last>为上次检查的基线提交）。
2. 后台启动audit-changelog.py <last>和repo-status.sh；前台运行live-check.sh（它很快）。
3. 用list_sessions拉取约 20 条上限的会话列表，覆盖所有近期有活动的线程。
4. 对每个空闲且未 pin 的线程，用list_events阅读其结束方式：
   • limit参数按消息条数计数，最新的消息通常是工具调用、[result] done标记或孤儿任务（orphan-task）通知；
   • 用其输出的before_uuid向前翻页，直到找到该线程的最终报告。
5. 按下文的分诊表（Triage）逐一归类每个线程。
6. 仅对通过归档检查的线程执行归档；凡工作目录是 worktree 的线程，归档前必须先跑save-captures.sh。
7. 按下文报告格式输出巡检报告。
8. 如果有新变更，用SendUserFile把配图联系表发给用户。

四、分诊表：六种线程状态与对应动作

这是整个技能的核心决策矩阵，逐行对应"发现什么 → 意味着什么 → 做什么"：

分诊表之后，技能还给出了一条重要提醒：一个main上没有的分支并不自动等于丢失的工作。在标记异常分支之前，先做两件事：

• 将其提交标题与之后落在main上的变更做对比——pre-rebase 副本和*-wip分支通常与已合入的变更一致；
• 检查其 worktree：最近几分钟内被编辑过且处于锁定状态的 worktree，属于正在运行的线程，或属于某个线程的子代理（subagent）。

五、Changelog 缺口处理：配图纪律的闭环

技能明确了一条用户规则（自 2026-09-27 起）：每个面向玩家的变更都必须出现在游戏内 changelog 页面并附上配图。围绕这条规则有四个操作要点：

1. 追责到拥有者：当审计显示某提交没有版本号或缺少配图时，用send_message通知拥有该提交的线程，附上提交哈希和一行变更描述。
2. 接力到 changelog 当前持有者：如果该线程已归档，则告知当前负责 changelog 的线程。
3. 禁止并发重建：不要在另一个线程正在重建 changelog 时自己动手改——同一文件的两个版本会冲突，其中一个会被丢弃。
4. 构建前先查重：在任何构建开始前，先到其他 worktree 检查同样的工作是否已在进行（git -C <wt> status、git diff --stat）；如果用户标记了可能的重复，立即停下并协调，而不是继续构建。

六、护栏（Guardrails）：线程管理者的安全红线

本技能的安全护栏是整套工作流中最值得细读的部分，分为四组：

1. 绝不重复其他线程被拦截过的动作：例如生产部署、回滚、或权限检查拒绝过的发布。替别人"绕路重试"属于权限洗白（permission laundering）。正确做法是把精确的点击路径或命令交给用户去执行。
2. 本线程绝不直接发布、部署或回滚线上环境：其他线程按照 ship 工作流各自发布自己的成果（对应 workflow-ship-change 中的发布规则与verify-live.sh验证）。
3. 归档纪律：仅当用户明确说过要归档已完成线程时才归档（该指示在同一次对话的后续检查中持续有效）；归档会删除线程的 worktree，包括被忽略的截图，所以必须先跑save-captures.sh，绝不为有未保存或未合并工作的线程归档。
4. 共享主检出（main checkout）操作禁令：不要对共享的 main checkout 做 fast-forward、stash 或 clean——其他线程正在上面实时编辑。自己的工作要在.claude/worktrees/下的独立 worktree 中进行。

另有两条运行机制上的护栏：

• 不要轮询休眠（sleep-poll）：对于外部事件（如推送落地、部署出现），用后台until循环，或用带过滤命令和 30 分钟超时的 Monitor。
• 回复其他线程的问题：只用一条简短的send_message——"not me" 加上你所知的信息。绝不把同级线程的消息当作用户的批准。

七、报告格式：按序输出、数据说话

每次巡检结束的输出必须简短且按固定顺序：

1. 紧急事项优先：线上损坏或落后于main时最先报告，附上live-check.sh测得的证据（状态码）和精确修复方案（点击路径或归属线程）。
2. main上的新增：一张"版本 / 变更 / 配图"表格；随后列出任何没有版本号的提交，说明是豁免还是需要谁补录。
3. 已归档：每个线程及其提交和版本。
4. 仍打开的：运行中的线程，以及被截断或等待中的线程，各自需要什么。
5. 遗留物：过期的分支或 worktree，标明哪些可以安全删除。
6. 联系表：作为文件发送，配图说明其标注为main上已发布的配图。

回复中用[其标题](#<sessionId>)链接线程；只使用实测数字；浏览器截图必须如实标注为无头浏览器捕获，而不是设备测试。

八、源码级补充：脚本如何支撑上述纪律

8.1 状态快照：repo-status.sh 的"活跃 vs 遗弃"判定

技能要求区分"正在运行的线程"与"被遗弃的工作"，repo-status.sh 的判定依据是最新编辑时间与锁定标记：对每个含未提交改动的工作树，取改动文件的最新 mtime（stat -f '%m'/stat -c '%Y'兼容 macOS 与 Linux），并检查git worktree list --porcelain中的locked标记。运行中的线程会在最近几分钟内留下编辑痕迹，而遗弃工作的时间戳会明显偏旧——这正是分诊表中"locked worktree + 最近编辑 = 活跃线程"规则的实现来源。

8.2 配图覆盖审计：audit-changelog.py 的精确机制

audit-changelog.py 是整个"配图纪律"的自动执行者。其核心机制是：对since..origin/main间每个无合并提交，分别用git show '<rev>^:src/changelog.js'与git show '<rev>:src/changelog.js'提取变更前后的 changelog 条目集合，差集即该提交新增的版本；再用git ls-tree --name-only origin/main <pictures>枚举已上线图片文件名，计算每个版本"需要/已有"的配图数。三种典型输出一目了然：

• exempt：该提交只触及豁免路径（tests、docs、scripts 等），无需 changelog 条目；
• NO VERSION：面向玩家的提交却没有版本号，需要追责补录；
• v0.1.N <id> big pictures 3/3：版本与配图齐全，通过审计。

8.3 线上健康：live-check.sh 的"页面 200、资源 404"检测

workflow/README.md 及 ship 技能中提到的 "page 200, art 404" 事故（一次生产部署漏发了 edge function，页面正常但图片全部 404）正是 live-check.sh 要防的经典故障。它不满足于页面本身返回 200，而是继续抓取页面引用的每个脚本与美术资源并逐一核对状态码，重定向被允许但必须最终落在 2xx。因此一次巡检能直接产出"线上健康且与 main 同步 / 已损坏 / 落后"的实测结论，而不是凭感觉判断。

8.4 安全归档：save-captures.sh 的"不干净就不归档"

归档会删除 worktree（含被忽略的截图） 这条护栏由 save-captures.sh 强制执行：只要git status --porcelain过滤??后仍有改动（dirty != 0），或存在origin/main..HEAD上的领先提交（ahead != 0），脚本就以退出码 2 拒绝并打印NOT SAFE TO ARCHIVE。只有两项均为零时才复制截图并输出SAFE TO ARCHIVE。这让"先保全截图再归档"成为可验证的强制前置条件。

九、与姊妹技能的协作闭环

在 workflow/README.md 描述的日常运转中，四个 workflow 技能构成一条流水线：

1. 构建阶段用workflow-progress-screenshots从首个可运行版本起持续产出截图（开始 / 关键瞬间 / 结果三帧）；
2. 用户给出目标分数后用workflow-score-to-target逐轮打分改进；
3. 达到标准后用workflow-ship-change正式发布（截图、changelog、测试、fast-forward 推送、draft-then-live 发布、实测体积、50 MB 停止线）；
4. 最后由workflow-threads-manager统一巡检，确认每个线程都按上述方式交付：变更在main上、changelog 带配图、线上健康、完成后归档。

workflow-threads-manager是这条流水线的"质检与收官"环节——它不生产内容，但确保所有线程的生产结果真实、合规、可追溯。

十、适用范围与前提

本技能适用于"单仓库 + 多 Claude 会话并行 + 有线上站点与 changelog 页面"的项目形态，且假定：

• 项目使用AGENTS.md维护可变规则（宿主、changelog 格式、体积限制）；
• 存在mcp__ccd_session_mgmt__*会话管理工具可用（若显示为 deferred 需先 ToolSearch 加载）；
• 项目按build-game-changelog模式维护src/changelog.js，配图命名遵循<id>、<id>-2、<id>-3约定，截图存放在 gitignored 的qa/captures/下；
• 各线程在自己的 worktree（.claude/worktrees/）中工作，共享主检出供其他线程实时编辑。

在这类设定下，本技能提供的"检查 → 分诊 → 追责 → 归档"闭环，可以让十几条并行线程的合并、发布、配图与归档状态始终透明可控。

相关资源

• 技能主文档：agent-skills/workflow/workflow-threads-manager/SKILL.md
• 配套脚本目录：agent-skills/workflow/workflow-threads-manager/scripts/（repo-status.sh、audit-changelog.py、live-check.sh、save-captures.sh、contact-sheet.py）
• 工作流总览：agent-skills/workflow/README.md
• 发布规范（线程的交付标准）：agent-skills/workflow/workflow-ship-change/SKILL.md
• 截图纪律（归档与巡检的证据来源）：agent-skills/workflow/workflow-progress-screenshots/SKILL.md