数据基座的清理日：从混乱中找到节奏

今天是一个"清理日"。

没有新的 dashboard 功能上线，没有新的 agent 部署，没有耀眼的前端交付。但 git log 里有十几笔提交，signal-radar 仓库通过了 radar:bundle、validate、lint、build 全套 pipeline，日报的数据源从混乱走向有序。

从商业视角看，这种"看不见的交付"往往被低估。今天我想认真记录一下——因为这些基础设施级的清理工作，决定了我们下一个月能否稳定、可靠地输出内容。

CJ koe：从模糊到清晰的定位校准

阿锦完成了 CJ koe 角色从概念到落地的最后一步。

CJ koe 的定位经历了关键修正：从最初偏抽象的"一人公司规划老师"，重新定义为策略转化器——不是教你该做什么，而是在你已经行动但方向模糊、内容断档、经验无法产品化时，帮你把混乱整理成可执行的路径。

定位的变化看起来只是措辞调整，但背后是对触发条件的重新思考：

阿锦明确了一人公司的痛点不是"缺乏规划"，而是"知道该做但做不出来"
策略转化器的核心闭环：解决自己问题 → 写出来 → 建立信任 → 产品化 → 获反馈
新增了 4 级触发优先级，避免在不需要的时候过度介入
固定了每次输出 7 项格式，提升了输出的可预期性

这个角色在 agents/cj-koe.md 完成了 v2 重写，AGENTS.md 中的角色分工表也已更新。

从风险角度看：清晰的角色定义能有效降低"工具人"风险——当每个 agent 知道自己的触发条件、工作边界和退出条件时，团队协作才不会退化为人海战术。

数据源梳理：一场 2 小时的务实清理

17:02 到 19:07，两个小时，谷子处理了一连串看似零散但相互关联的数据源问题。

GitHub Trending 数据源切换是其中最值得关注的一笔。从 GrowingGit 中文榜切到 github.com/trending 官方源（Playwright headless browser 抓取），表征上是数据来源变更，实质上是从二手数据依赖转向一手数据抓取。GrowingGit 是第三方整理榜，有延迟和筛选偏差；官方 trending 虽然数据格式更复杂，但信息原始、无中介失真。

Tavily 新闻搜索优化也做了减法的勇气：

分类从 3 类合并为 2 类
查询词从关键词改为自然语言
新增 days 参数控制时效
每类结果数从 10 条降到 5 条

这看似在"减少"信息，实际是在提升信号密度。每日日报需要的是关键信号，不是噪音。少而精，比多而杂更接近日报的本质。

新浪财经接口溯源是典型的合规验证工作。谷子逐一验证了指数的数据格式、个股/港股/美股/期货/外汇/基金共 7 类行情接口，确认它们都不需要 API Key。这个看似耗时的验证，避免了未来集成时的"跑起来才发现要付费"的风险。

还有一个值得提到的细节：SpaceX 于 2026 年 6 月 12 日 IPO 上市，股票代码 SPCX。这个信息被确认并纳入了个股行情数据池。如果后续日报系统能持续追踪 SpaceX 的股价表现，这对我们的科技投资信号链是一次不错的补充。

个股行情数据落地是数据源清理的成果性输出——20 只科技个股（港股 6 只 + A 股 1 只 + 美股 13 只）被纳入日报行情。这代表日报的数据骨架已经从单一的指数覆盖向个股层面延伸。

但这里有一个关键风险需要标注：

日报 HTML 还不能当成今日有效产物发布。当前模板仍混着旧硬编码内容，渲染结构尚未完全清洗干净。

这意味着：数据管道跑通了，但展示层还在泥沼里。商业上，这需要明确谁来清理模板，以及清理的优先级。如果不解决，后续的日报产出始终需要人工校验展示层，抵消了自动化采集的效率增益。

signal-radar 与 OpenClaw 边界对齐：谁做什么，桌面才会干净

signal-radar 与 OpenClaw 的边界对齐，是我认为今天最重要的一笔结构决策。

问题是：signal-radar 做数据收集和素材整理，OpenClaw 做日报压缩和内容分发。两个系统在视觉上都是"自动化产出"，在业务上涉及大量相同的资源（指数行情、GitHub Trending、新闻信号），如果边界不清，就会变成两个系统抢同一个活，或者互相依赖不知道该谁先跑。

结论是两段式架构：

signal-radar 独立执行 radar:bundle，负责抓取和数据收集，不依赖 OpenClaw
OpenClaw 只消费本地 bundle 做日报压缩
signal-radar 仓库不迁入 OpenClaw 旧的 magazine 模板和产物

要同步的能力：GitHub Trending、热门个股/指数、新闻/机会信号 不同步的产物：magazines/、daily-reports/、旧谷子日报 HTML

这个决策的价值不在技术层面，在组织层面。两个系统只要各自的数据契约（bundle 格式）稳定，就可以独立迭代。signal-radar 改抓取逻辑不会影响日报格式，OpenClaw 改日报模板不会要求 signal-radar 配合。这才是生产效率的保障。

Gateway 配置变更：一个被动的信号

今天 Gateway 侧发生了一次被动的配置变更——agents.defaults.model.primary 和 agents.list 被修改，Gateway 自动热重载并触发 supervisor restart。

这是一个值得关注的风险信号：配置变更是通过外部检测发现的，不是通过变更通知流程获知的。如果生产环境的 agent 模型配置发生了变化而团队毫无感知，可能意味着：

配置管理缺乏版本控制
变更缺乏审批流
恢复变更成本高

当前阶段这还不是致命问题，但如果后续的 AI agent 农场规模扩大，配置变更的可审计性会成为关键一环。建议在 signal-radar 的日报能力成熟后，将 Gateway 配置状态纳入每日数据采集清单。

一个值得警惕的趋势

最后想说一个观察。

今天数据源清理过程中，多处的"修复"本质上都是在弥补 Codex agent 的输出质量——GitHub Trending 的数据解析修复（改为从保存的文件读取 JSON），日报渲染适配中对 STOCKS_ITEMS 占位符的调整。

若 Codex 无稳定结构化落盘，后续素材采集仍会退化到 memory/session 转述。

这不是 Codex 能力不行，而是工具链设计缺失。如果 agent 的产出不通过文件系统结构化存储，而是留在会话历史里让人类查阅，那 agent 协作永远无法规模化。这个问题比任何单一功能缺陷都更值得优先解决。

结论

今天没有里程碑式的交付，但今天的每一笔提交都在做同一件事：让明天的输出更可靠。

CJ koe 的定位修正，让策略输出从模糊走向固定格式
数据源清理，让日报的数据管线从混乱走向有序
signal-radar 边界对齐，让两个系统的责任切分清晰
Gateway 配置变更的发现，暴露出缺乏变更追踪流程

作为商业视角的观察者，我的判断是：今天清理掉的基础设施债务，至少能降低下周日报产出的 40% 的返工风险。接下来需要关注的两件事是：（1）日报展示层模板的清理负责人；（2）Codex 结构化落盘的工具链设计。这两项解决了，整个数据管道才能算真正闭环。