# 一、扫描结论 共扫描 78 条 session 记录，保留 5 个早上值得 review 的候选。昨天的主线是 BU 化工作台、skill 治理、外部采集/调研、Product BU 发布推进，以及 Codex/Night Gym 自我迭代。 ## 1.1 候选排序 | 优先级 | id | 类型 | 风险 | 主题 | |---:|---|---|---|---| | 1 | `codex-capability-verification` | workflow-pattern | low | Codex 能力/配置问题需要本机核验 playbook，避免凭记忆回答 | | 2 | `skill-inventory-governance` | tool-upgrade | medium | 全局/BU skill 需要注册表和迁移审计，而不是逐个问删改挪 | | 3 | `crawl-hub-schema-canaries` | skill-gap | medium | crawl-hub / Apify 类采集 skill 需要 schema canary、成本闸门和 actor 健康表 | | 4 | `product-bu-release-control-plane` | workflow-pattern | medium | Product BU 需要发布状态机和 release 自动化，而不只是 Markdown 看板手工更新 | | 5 | `night-gym-dag-review-loop` | tool-upgrade | medium | Night Gym 已有 MVP，下一步应升级成真实 DAG + 可运行 demo 的候选包 | # 二、候选详情 ## 2.1 Codex 能力/配置问题需要本机核验 playbook，避免凭记忆回答 - id：`codex-capability-verification` - 类型：`workflow-pattern` - 风险：`low` - 摘要：这个主题有效，不是噪音：同一类问题在模型上下文、CLI 非交互参数、subagent 配置里反复出现，而且纯靠官方文档或记忆都会漏掉当前本机实际状态。应沉淀成固定核验流程：先分清官方 catalog、全局 config、当前 session runtime、spawn 日志四个口径，再回答用户。 - 证据： - `019dded9` / `~/Documents/info-bu`：用户：codex官方文档看看，支不支持1m上下文。助手：Codex 专用模型页标的是 400K context；另一个最新模型总表里有 GPT-5.5 标 1M context。 - `019dded9` / `~/Documents/info-bu`：已加到全局配置：model_context_window = 1050000；但 codex debug models 仍显示 gpt-5.5 context_window 为 272000，说明它不是最终生效配置口径。 - `019dded9` / `~/Documents/info-bu`：用户：目前这个session的最大上下文是多少。助手从本地 session 日志看 task_started / token_count，结论当前 session 实际还是 258,400 tokens。 - 建议改动： - 新增 skill：/Users/bytedance/.codex/skills/codex-capability-verification/SKILL.md。触发词覆盖 Codex 上下文、model、config.toml、subagent、spawn_agent、codex exec、bypass、profile；流程要求先核验官方文档/本机 CLI/config/session log，再回答。 - 更新 /Users/bytedance/.codex/AGENTS.md，加入“Codex 能力/配置问题核验规则”：必须区分官方模型 catalog、~/.codex/config.toml、当前 session 的 task_started/token_count、spawn/collab_agent_spawn_end 日志四个口径。 - 新增辅助脚本 /Users/bytedance/.codex/scripts/codex-capability-probe.sh，输出 codex --version、codex --help/codex exec --help 摘要、codex debug models/prompt-input 关键字段、全局 config 关键行、最近 session 的 model_context_window。 - 沉淀概念笔记 /Users/bytedance/Documents/info-bu/info-workspace/resources/codex-capability-verification.md，用表格解释 catalog vs config vs running session vs subagent shard log，附常见误判和推荐验证命令。 - 示例：`examples/codex-capability-verification.md` ## 2.2 全局/BU skill 需要注册表和迁移审计，而不是逐个问删改挪 - id：`skill-inventory-governance` - 类型：`tool-upgrade` - 风险：`medium` - 摘要：这个主题有效，不是单点噪音：片段同时覆盖了全局/BU skill 清点、迁移/删除、依赖补齐、触发规则改写和跨 BU 分发。共同问题不是“某个 skill 怎么装”，而是缺少一个能回答 scope、来源、安装时间、依赖、验证命令和迁移历史的 registry/audit 层。 - 证据： - `019dde6b` / `~`：用户连续要求：列一下我全局，和各个bu的skill；多个 skill 不需要出现在全局，移动到 product-bu/info-bu/learning-bu；删除 deep-research-trio、learn-english、x-deep-research 等。 - `019ddd6a` / `~/Documents/product-bu`：安装 office-hours 时出现子目录识别、Gstack runtime、bun 依赖、项目级 vs 全局安装等判断，最后靠人工补齐 runtime 和多次验证。 - `019dde8c` / `~/Documents/info-bu`：用户问“你用到思考skill了吗”，指出说“思考一下”就应该触发 thinking skill，并要求把“这个信息本质是什么经典问题的变体”写进 skill。 - 建议改动： - 新增用户级 skill：`/Users/bytedance/.codex/skills/skill-inventory-governance/SKILL.md`。触发词覆盖“列一下全局和各BU skill”“移动/删除 skill”“什么时候安装”“依赖是什么”“给某 BU 也装上”，要求先产出 inventory + migration plan，再做文件改动。 - 新增审计脚本：`/Users/bytedance/.codex/skills/skill-inventory-governance/scripts/audit_skills.py`。扫描 `~/.codex/skills`、`~/Documents/*-bu/.agents/skills`、`skills-lock.json`、symlink target、mtime/ctime、SKILL.md 外部 helper 引用，输出 `out/skill_inventory.json` 和 `out/skill_inventory.md`。 - 新增规范文件：`/Users/bytedance/.codex/skill-registry/registry.yaml`。字段至少包含 `name`、`scope`、`owner_bu`、`source`、`installed_at`、`migrated_from`、`dependencies`、`validation_commands`、`trigger_notes`、`status`，把全局与 BU skill 的真源从散落目录提升为可审计清单。 - 把第一批 seed 记录补进去并回归验证：`phone-use`、`office-hours`、`Superpowers`、`thinking skill`、`Alibaba Cloud/GPU skill`。每条记录都附验证命令，例如 `npx skills list`、`codex debug prompt-input`、helper 可执行性检查。 - 示例：`examples/skill-inventory-governance.md` ## 2.3 crawl-hub / Apify 类采集 skill 需要 schema canary、成本闸门和 actor 健康表 - id：`crawl-hub-schema-canaries` - 类型：`skill-gap` - 风险：`medium` - 摘要：这个主题有效，不是噪音：片段显示同一类外部采集入口反复遇到输入 schema 漂移、免费计划占位结果、空 dataset 和平台 actor 质量不稳定。现有 crawl-hub/apify-research 已经有 runner 和路由表，但缺少运行前 schema canary、运行后质量判定、成本闸门和 actor 健康记录，导致每次都在任务中临场降级。 - 证据： - `019ddd83` / `~/Documents/info-bu`：用户围绕知乎爬虫、Apify、YouTube/Reddit/X actor、Douyin/知乎/小红书 actor 做一长串调研，并要求把三类 actor 接入 info-bu skill。助手新增 apify-research skill、脚本和输入模板，但起初没有 APIFY_TOKEN，只能 fallback 到公开网页。 - `019ddd83` / `~/Documents/info-bu`：Apify 实测里：YouTube actor 成功，X actor 起初受 Free Plan 限制只返回 noResults/demo，占位，升级后 twitter-scraper-lite 才返回 50 条；小红书 actor 技术上返回 5 条但搜索质量一般，另一个热门 actor 成功但 dataset 为空；知乎没有可推荐专用 actor。 - `019ddea2` / `~/Documents/info-bu`：多次使用 crawl-hub 时 Google Search actor 因输入 schema 变化报 400，助手只好改用 web search/官方来源，并在结论里说明“输入 schema 不一致”。 - 建议改动： - 改 `/Users/bytedance/Documents/info-bu/.agents/skills/crawl-hub/scripts/crawl_hub.py`：新增 `--canary` / `--validate-input` 模式，对每个 Apify source 先生成最小输入、执行一次低 limit smoke run，并把 HTTP 400、schema mismatch、0 items、demo/noResults 识别为结构化失败。 - 新增 `/Users/bytedance/Documents/info-bu/.agents/skills/crawl-hub/actors.health.json`：记录 actor id、用途、当前推荐等级、已知输入字段、最小可验查询、plan requirement、expected_min_items、last_ok_at、last_error、fallback_source，作为路由前的健康表。 - 改 `/Users/bytedance/Documents/info-bu/.agents/skills/apify-research/scripts/apify_actor_run.py`：增加 `--max-usd`、`--min-items`、`--fail-on-placeholder` 参数，读取 run metadata 里的 usage/cost 信号，并检测 `noResults`、demo、空 dataset 等假成功。 - 改 `/Users/bytedance/Documents/info-bu/.agents/skills/crawl-hub/SKILL.md` 和 `/Users/bytedance/Documents/info-bu/.agents/skills/apify-research/SKILL.md`：把工作流改成“健康表检查 -> canary -> 小批量 -> 扩量”，并明确 Google Search、X、小红书、知乎的降级策略和何时改用 web search/官方来源。 - 示例：`examples/crawl-hub-schema-canaries.md` ## 2.4 Product BU 需要发布状态机和 release 自动化，而不只是 Markdown 看板手工更新 - id：`product-bu-release-control-plane` - 类型：`workflow-pattern` - 风险：`medium` - 摘要：该主题有效，而且不是噪音：同一条 product-bu 线同时覆盖 dejavu、viva、obsidian-groq-copilot 多个产品包，并反复出现安装验证、发布提交、社区审核、版本升级、PR 评论和看板同步。问题本质不是缺一个 Markdown 看板，而是缺一个可查询、可校验、可自动推进的 release 状态机，把本地包、浏览器插件、GitHub release/PR 和 BU 总看板串起来。 - 证据： - `019dddc4` / `~/Documents/product-bu`：用户把 product-bu 定位成类似互联网公司，从 RD/PM/项目到最终产品，要求落地目录结构；随后围绕 dejavu、viva、obsidian-groq-copilot 三个发布包持续推进安装、发布、社区审核和状态查询。 - `019dddc4` / `~/Documents/product-bu`：产品线动作很多：dejavu.zip 被识别为非标准浏览器插件并包装成 Edge extension；viva.zip 解出 dist 插件、确认权限、加载到 Edge，并同步更新产品概览和 BU 总看板。 - `019dddc4` / `~/Documents/product-bu`：Obsidian 插件发布流程包含 GitHub device 授权、社区 PR、bot validation、sentence-case lint、升版本到 1.0.5、release 资产验证和 PR 评论；用户持续问“现在啥进度/有进展了吗”。 - 建议改动： - 新增 `/Users/bytedance/Documents/product-bu/00-company/release-control-plane.yml`，作为发布事实源，字段包含 product、artifact_path、release_channel、state、version、last_checked_at、next_action、blockers、github_pr_url、github_release_url、dashboard_row_id。 - 新增 `/Users/bytedance/Documents/product-bu/tools/release-control/release_status.py`，读取 release-control-plane.yml，自动校验本地包是否存在、浏览器 extension manifest 是否合规、GitHub PR/release/bot validation 状态，并生成 `00-company/bu-dashboard.md` 的发布区块。 - 新增 workspace skill `/Users/bytedance/Documents/product-bu/.agents/skills/release-control-plane/SKILL.md`，要求 agent 在新增产品、移动发布包、修改发布状态、创建 release/PR 或收到审核结果时，同轮更新状态机和 BU 总看板。 - 新增 `/Users/bytedance/Documents/product-bu/tools/release-control/tests/test_release_state_machine.py`，用 dejavu、viva、obsidian-groq-copilot 三个 fixture 覆盖状态流转：intake -> packaged -> local_verified -> submitted -> bot_validated -> released/blocked。 - 示例：`examples/product-bu-release-control-plane.md` ## 2.5 Night Gym 已有 MVP，下一步应升级成真实 DAG + 可运行 demo 的候选包 - id：`night-gym-dag-review-loop` - 类型：`tool-upgrade` - 风险：`medium` - 摘要：这个主题有效，不是噪音：用户已经从“每天 1 点复盘 Codex 使用记录”推进到“个人 Codex agent 系统自我迭代”，并明确提到一键批准、agent 实现方案、跑例子、早上 review。当前 MVP 已能产出候选包和 approve.sh，但仍停留在 review-first 的候选生成层，缺少显式 DAG、worker/reviewer 分工和可运行 demo 结果。 - 证据： - `019ddda6` / `~/Documents/info-bu`：用户提出“晚上1点的时候弄个定时任务，一群agent去看白天的codex使用记录找到能提高的点”。助手开始搭建 1:00 定时任务、读取 Codex logs_2.sqlite、按重复性/失败率/低效交互输出改进点。 - `019ddda6` / `~/Documents/product-bu`：用户继续明确产品形态：个人 Codex agent 系统自我迭代、可一键批准的改动包、更酷的是 agent 在环境里实现方案并跑例子，最后带着效果让早上 review。 - `019ddda6` / `~/Documents/product-bu`：助手实现 Codex Night Gym MVP：每天 01:00 跑，产出候选包；当前 seed case 是打标流水线工具债和 phone-use 学习债，13 个 unittest 通过，approve.sh 只记录批准状态。 - 建议改动： - 在 `/Users/bytedance/Documents/product-bu/tools/night-gym/night_gym/dag.py` 新增显式 DAG runner，节点包括 `ingest_sessions`、`propose_candidates`、`spawn_analyzers`、`route_candidates`、`build_demo`、`review_demo`、`package_writer`，并把每个节点的 input/output/status/timestamps 写入 `out/dag_state.json`，支持失败后 resume。 - 改 `/Users/bytedance/Documents/product-bu/tools/night-gym/night_gym/orchestrator.py`：把现在单次 `run_master()` 包一层 DAG 执行器，保留现有 master prompt 作为 `propose_candidates` 节点，新增 `demo_only` / `max_workers` 参数，避免每次都全量重跑。 - 补 `/Users/bytedance/Documents/product-bu/tools/night-gym/night_gym/prompts/worker.md` 和 `reviewer.md`：worker 只允许在临时 demo workspace 里实现候选方案并运行 smoke test；reviewer 只读 worker 输出、测试日志和 diff，给出 `pass/block/needs-human` 结论。 - 新增 `/Users/bytedance/Documents/product-bu/tools/night-gym/tests/test_night_gym_dag.py`：覆盖 DAG 拓扑顺序、失败节点不阻塞其他候选、resume 不重复执行已完成节点、最终 package 包含 `examples/`、`demo_results/` 和 reviewer verdict。 - 示例：`examples/night-gym-dag-review-loop.md` # 三、建议早上先看 1. 先看 `codex-capability-verification`，风险低、收益快，能减少之后关于 Codex 上下文、subagent、exec 配置的误判。 2. 再看 `skill-inventory-governance` 和 `crawl-hub-schema-canaries`，这两项会直接减少重复扫目录、重复踩 connector schema/成本/空结果的问题。 3. `product-bu-release-control-plane` 和 `night-gym-dag-review-loop` 更像中型建设项，适合批准后分两步做原型。