每日计划/记录自动化落地，以及 614 个会话文件全部失败的发现

🤖 每天的计划和记录，自动化跑起来了

起点是「让外部服务驱动 Apple 做每日计划与记录」，摸完底后改了口径：交给 Alma 自己跑，只写 Apple Notes，09:00 写计划、23:00 写记录，调度用 Alma 自己的定时任务。

新技能由四个脚本组成，每个都解决一个具体的坑：

脚本	解决什么
write-note.applescript	argv 传参写入，避开 shell 与 AppleScript 双层转义
read-note.applescript	按标题把笔记读回来
notes-write.py	Markdown → Notes 富文本 + 幂等同名覆盖 + --dry-run / --date
gather-context.py	采集日历 / 提醒事项 / 历史笔记 / 记忆笔记 / 近期线程，每个源独立容错

验证方式我没有手跑脚本，而是 alma cron run <id> 让调度器真触发一遍——计划 10:47 落笔、记录 10:48 落笔，两个任务的执行次数都从 0 变成 1。

机制性踩坑（后来写进了技能文档）

• 命令行笔记工具是交互式编辑器（会打开 $EDITOR），没法自动化写正文 → 必须走 AppleScript
• Apple Notes 用正文首行定义笔记名 → 所以正文首行必须是标题

顺带挖出一个硬伤（未修）

翻到一个权限问题：某个锁文件的属主是 root，而服务以普通用户运行 → 抓锁时报权限错误，被 except 吞掉并记成 debug 日志 → 结果是几个定时任务从 4 月起一次都没跑过，每 60 秒静默空转。

📋 五项长期任务 + 本周交付立项

用户下达五项长期任务，明确只要记录、不要立刻开工。落点三处：Apple Notes 长期台账、今日计划笔记追加、工作区侦察报告。

五项任务覆盖：三账号内容梳理、每天固定图文产出、车型品牌图片汇总、每月产品模块更新官网、轮毂数据整理。

另建了本周任务清单，第一点是小程序物料准备（服务商要求：图片、标题、内容介绍、以及一类待确认的字段）。

⭐ 三个关键发现

① 要「用」的那个应用是无 CLI 的 GUI 应用

查了它的 bundle 结构：纯图形界面、Chromium 内核、没有任何命令行入口，技能目录是空的。→ 要自动化它只能走屏幕操作，对「每天 2 篇」这类高频任务风险很高。

② 真瓶颈不是文案，是生图

看了运营的交接文档：9 个选题里 4 篇卡在「待生图」、2 篇卡在「待审核」、1 篇待发布。而且有个节日选题已经过期了。

③ 缺的是一层关联数据

两套轮毂数据 —— 一套是规格表（尺寸 × 工艺），一套是图片库（工艺 × 车型）—— 中间没有关联表。而「一个车型切换不同轮毂」这件事，恰恰需要这层对应关系。

小程序物料现状（实测）

四项交付物里，三项产出为零：

目录	状态
车型图片	🟡 有素材（11 品牌 48 张）
成品图片	🔴 空（只有一个 0 字节占位文件）
内容和标题	🔴 空（同上）
提示词	🔴 空（同上）

目录结构一个多月前就建好了，但一直没填内容。

不过找到可复用的数据源：已有 12 个品牌的《车型支持产品清单（脱敏版）》，格式是「车型 × 产品维度」矩阵 → 可以直接当作标题和内容介绍的事实依据，不必从零编。

量级估算：12 品牌 × 约 10 车型 × 2–4 个适配产品 ≈ 数百条。这是本周最大工作量。

🧾 工作记录双源核查

傍晚把两边的当日产出合成一份工作记录写进 Apple Notes。合成过程中顺手做了一次实据核查，查出一个异常：

当天有一个是很实在的产出 —— 某车型产品表优化：统一成标准 13 列字段、整理 64 条产品记录 / 13 个车型主系列，产品分布为底盘护板 28 / 电动踏板 2 / 软包脚垫 17 / 平面尾箱垫 14 / 全包尾箱 3；增程/纯电/续航/座位版本合并进字段而不重复建车型，含表头样式、自动换行、列宽边框、冻结前三列与筛选，逐项回读通过。

⚠️ 但同一天的另一个数字就很难看：614 个会话文件，全部失败。

• 610 个失败于：model is not supported when using Codex with a ChatGPT account
• 2 个失败于流中断
• 2 个只启动没跑完
• 成功产出文本：0 条（全库助手文本总量 = 0 字符）

原因很清楚：拿一个不兼容的模型去驱动只支持自家模型的 CLI —— 结构性不兼容，不是偶发故障。

核查路径也记一笔：常规的历史文件当天是 0 条、线程索引停在更早的日期，最后是从本地一个 SQLite 库的线程目录表里才查到「今天动过哪些线程」——这是唯一有效的路径。

证据边界（如实标注）：外置盘在核查中途被卸载，部分产出无法核验；其中一侧的记录是用户提供的原文，未独立核验。

📝 博客第四、五篇

两篇都是外部仓库拆解，各 24KB 左右：

• 第四篇（agent-skills）：主线是「当你有 25 条规则，你怎么知道它们还在生效」——三层评测 + 反合理化表 + 棘轮。点名了那句「一个完全由自家测试构成的门槛，价值低于掺了外部意见的门槛」。
• 第五篇（Strix 渗透测试）：主线是「三态结案 + 完句测试 + 跨 Agent 共享的覆盖面账本」。它要防的失败模式是「agent 读了代码、感到不确定、然后悄悄把候选关掉」。

两篇都如实写了仓库自曝的缺口——包括第四篇那个「被拒改动账本」目前其实是空的（刚立起来的机制，不是已有成果）。

💾 磁盘：可用空间单日净减 30GB

对照三天的快照：78.6G → 67.6G → 48.6G。

也就是说这一天净减了 30G。但重点目录只能解释其中 7.3G 左右（缓存、应用、临时目录）—— 剩下约 22.7G 消耗在监控范围之外，没定位到。

关键决策

决策	理由
计划/记录交给自己跑，不自建外部链路	更可控，且外部服务的定时任务已证实不可信
验证用 cron run 让调度器真触发	手跑脚本只能证明脚本对，证明不了调度通
长期任务先完整记录、不立刻开工	用户明确要求先记录
核查发现的问题如实标注证据边界	外置盘被卸载，不能假装核验过
异常如实写进记录，不掩盖	614 个失败是有价值的发现，不是家丑

待办

• 「积分类的」含义待确认 —— 阻塞物料上线
• 小程序物料：先出 1 个品牌样板，还是全量铺开？
• 修那个锁文件权限问题（几个定时任务已空转五个月）
• 磁盘 30G 消耗定位
• 两篇博客待审阅