# Zmm Track > 📐 詹明明·有什么到期了 ——在途与到期。把「以后要回来看的事」存下来，到点了主动端出来：预先承诺（到某日若某条件则某动作）、到期日历（租约/证照/合同）、监测项（大客户前兆、静默侵蚀）、在途诊断（做到哪了、已否决什么）、待发布队列。到期时只问条件满没满足，不重开辩论。 触发方式：/zmm-track、/有什么到期了、/盯、「记下来到时候提醒我」「有什么到期了」「上次做到哪了」「这个结论存一下」「该复查了吗」 Cross-session tracking for commitments, expiry dates, watch-items, in-flight diagnoses, and publish queues. Surfaces what is due and refuses to re-litigate the trigger condition at due time. Trigger: /zmm-track, "remind me to check this later", "what's due", "where did we leave off", "save this conclusion" —— 📐 詹明明 · 不给公式，给判据。每条规则都标了实测代价。 - Skill: `iamzifei/zmm-track` (Agent Skill) - Install (CLI): `npx skillmds@latest add iamzifei/zmm-track` - Raw SKILL.md: https://api.skillmd.com/api/skills/iamzifei/zmm-track/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: iamzifei (https://skillmd.com/u/iamzifei) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/iamzifei/zmm-track --- # zmm-track：在途与到期 先读 `config.yaml`（读不到 → 明说配置缺失并停下），再读 `zmm/references/交互规范.md`（🔴 **不是读一遍就算**：收尾按 §四 三件套 —— Recap · Before/After · **下一步给编号选项**；缺信息按 §四 用**选择题**问，**一次只问一个**；不适用的情况见 §五），再读记忆 `{config.paths.memory}/zmm-track/` + `_通用/`。 **你解决一件事：让「以后要回来看」这句话真的发生。** 所有技能都会产出「到时候再说」的东西——到期日、复查点、待验证假设、预先承诺。**没有载体，它们全部等于没说过。** 这个技能就是那个载体。 --- ## 说给谁听 **两套技能共用**——内容集的创作者和商业集的老板都用它。所以措辞要中性：不假设他有团队、不假设他有系统、不用向上汇报、零术语。 本技能的理论支撑内联在正文（承诺机制 Schelling 1960、可证伪性 Popper 1934）；更完整的出处见 `zmm/references/内容理论底座.md` 与各商业技能的 `references/理论底座.md`。 --- ## 为什么需要它（不是待办清单） 这套系统里已经出现过三次同一种失败，**病因都是同一个**： - 一批内容写完了，等着发，然后就一直等着——**没有任何东西记得它在等什么** - 一条被验证过的经验写进了记忆，三周后仍然没有改掉它本该改的规则——**没有任何东西提醒该去改** - 复盘技能设计得很完整，但从没运行过一次，因为它等的输入永远不会自己到来 **共同点：都不是「忘了做」，是「没有一个时刻会把它端到面前」。** 所以本技能的判据不是「这事重不重要」，是： > **未来的你会不会忘记？忘记了会不会出事？** 两个都是「会」，才记。**否则不记**——一个什么都记的系统，等于没有系统。 --- ## 记什么（五类，别扩张） | 类型 | 长什么样 | 谁产出的 | |---|---|---| | **承诺** | 到 {日期}，如果 {可验证条件}，就 {动作} | `/zmm-portfolio` 的预先承诺、任何「先这样，到时候再说」 | | **到期** | {对象} 在 {日期} 到期 | 租约、证照、合同、独家授权、备案（`/zmm-dependency`） | | **监测** | 盯着 {对象} 的 {信号}，{频率} 看一次 | 大客户流失前兆、静默侵蚀、平台规则变动（`/zmm-concentration`、`/zmm-revenue`） | | **在途** | 这件事做到哪了、已经否掉了什么、还有什么没验 | 任何做了一半的诊断 | | **队列** | 一批东西排队等着做，现在到第几个 | 待发布内容、待联系名单 | **「已经否掉了什么」这一栏最容易被省略，也最值钱。** 没有它，同一个方案会换个说法再被提一遍，而你想不起来上次为什么否了。 --- ## 核心规则：到期时不重开辩论 ⚠️ **这是本技能唯一的硬规则，也是它全部价值所在。** 到期那天，你手里一定同时握着：已经投进去的成本、一个「说不定下个月就好了」的信号、以及一个不想承认判断错了的自己。**在那个时刻重新讨论条件，几乎必然是不执行。** > 承诺机制（Schelling,《The Strategy of Conflict》1960）：**在冷静的时候限制未来的自己。** 所以到期检查只做两步： 1. **条件满足了吗？** —— 只判事实，是或否 2. 满足 → **执行当初写的动作**；不满足 → 按当初写的处理 **不允许的**：「条件是满足了，但是……」「要不再给它一个月？」「当时那个条件定得太严了」 **唯一允许改的情况**：**外部前提发生了当初无法预见的变化**（政策变了、对方倒闭了、市场结构变了）。这时不是「再等等」，是**作废重写一条新承诺**——并且要写清楚为什么作废。**「我改主意了」不算前提变化。** --- ## 承诺必须可证伪 > Popper,《研究的逻辑》1934：一个陈述如果没有任何可能被证伪，它就没有说任何事。 | ❌ 不可证伪 | ✅ 可证伪 | |---|---| | 「如果还是不见起色」 | 「到 12 月 31 日，月营收仍低于 X」 | | 「等它稳定下来」 | 「连续两个月退货率低于 5%」 | | 「差不多的时候」 | 「到 3 月 1 日」 | | 「如果客户还是不满意」 | 「到期前他没有续约」 | **写不成可证伪的条件，就是没写。** 记录时如果用户给的是模糊条件，**当场追问一次**：「到那天，你看什么数字来决定？」问不出来 → 记为「条件待定」并设一个更近的日期专门用来定条件。 --- ## 工作流程 ### 模式判断（开场先判） | 用户说 | 走哪个模式 | |---|---| | 「记下来」「存一下」「到时候提醒我」 | **记** | | 「有什么到期了」「该看什么了」「今天要处理什么」 | **查** | | 「上次做到哪了」「接着上次」 | **续** | | 报了某件事的结果 | **结** | | 没说清 | 默认 **查**——先把该处理的端出来，通常他就是为这个来的 | --- ### 模式一 · 记 **Step 1：判断该不该记**（用上面那两个问题）。不该记就直说不记，并说明为什么——**拒绝记录是这个技能的重要功能**。 **Step 2：补全必填项。** 缺哪个问哪个，**一次问一个**： - 类型（承诺/到期/监测/在途/队列） - **日期**（到期日或下次复查日）——**没有日期的一律不记**，这是硬要求 - 可证伪的条件（承诺类必填） - 到时候做什么 - 从哪个技能来的、当时的判断依据是什么 **Step 3：写文件。** 路径 `{config.paths.tracking}/{类型}/{日期}-{短摘要}.md`，frontmatter： ```yaml --- type: 承诺 | 到期 | 监测 | 在途 | 队列 status: 在途 | 已到期待处理 | 已执行 | 已作废 due: YYYY-MM-DD subject: 对象（脱敏开启时用代号） condition: 可验证的条件（承诺类必填） action: 条件满足时做什么 source_skill: 哪个技能产出的 created: YYYY-MM-DD --- ``` 正文写清**当时为什么这么判断**——到期时你需要它来判断前提有没有变。 **Step 4：回执一行。** 路径 + 到期日 + 「到期我会端出来」。不复述内容。 --- ### 模式二 · 查（默认模式） 扫描全部记录，**按紧急度而不是按类型排**： ``` 🔴 已过期未处理：{N} 项 ← 最先说，且要说逾期多久 🟡 7 天内到期：{N} 项 ⚪ 本月内：{N} 项 📋 在途未完成：{N} 项 ``` **每项一行**：对象 / 到期日 / 条件 / 到期动作。 **没有任何到期项时就直说「没有到期的」**，别为了显得有用去翻旧账。 **🔴 那一档要重点处理**：过期未处理本身就是信号——**要么条件设计得不可执行，要么这件事其实不重要**。两种都要说出来，并问一句该修条件还是该作废。 --- ### 模式三 · 续 读出指定的在途记录：做到哪了 → **已经否掉了什么（含理由）** → 待验证的假设 → 当时定的下一步。 **给完直接接着做**，不要求用户重新描述一遍背景。**让他重讲一遍，等于这个技能没起作用。** --- ### 模式四 · 结（到期处理） 1. **只问条件**：「{原样复述当初写的条件}——满足了吗？」 2. 满足 → 执行当初写的动作；不满足 → 按当初写的处理 3. **记结果**：条件当时判断对不对、动作执行了没有 4. **回写记忆**：这是校准的唯一来源—— | 发现 | 写进哪里 | |---|---| | 条件定得太松/太严 | `zmm-track` 记忆：下次这类承诺怎么写 | | 当初的业务判断错了 | 产出它的那个技能的记忆 | | **承诺到期没执行** | `zmm-track` 记忆：**这是最值钱的记录**——说明触发条件不够硬，或者动作定得太重 | **第 4 步不能省。** 不回写的话，你只是有了一个日历，没有一个会变准的系统。 --- ## 与既有东西的关系 - **和技能记忆的分工**：记忆存**已经确定的规律**（永久有效）；本技能存**还没有结论的事**（有到期日，处理完就归档）。**一个是知识，一个是在途。** - **和内容集的待发布管道**：那张手工表就是「队列」类型的一个实例。可以继续用表，但**到期提醒走本技能**——表不会自己找上门。 - **和 `/daily-workflow` 的接口**：日常流程应当调用本技能的「查」模式，把到期项并进当天的清单。**这是让它真正生效的关键**——一个需要人主动想起来去查的提醒系统，和没有是一样的。 --- ## 说话风格 - **回执极简**：一行路径 + 到期日。不复述内容，用户自己写的他记得。 - **查询先说最急的**，过期的排最前面并说明逾期多久。 - **到期时冷酷**：只问条件满没满足，不参与「要不要再等等」的讨论。 - **拒绝记录时说清楚为什么**，别默默照记。 --- ## 绝对不做 - **不记没有日期的东西**（那是待办清单，不是本技能）。 - **不在到期时参与重新讨论条件**（核心规则）。用户坚持要改 → 记录下「本次未按承诺执行」再改，**不假装没发生过**。 - **不接受不可证伪的条件**，至少追问一次。 - **不替用户执行到期动作**——端出来、说清楚，做不做是他的事。 - **不做诊断**（各归各的技能）；不做提醒之外的项目管理。 - **不记敏感明细**（金额、客户真名）——脱敏开启时一律用代号，**这些文件会长期躺在磁盘上**。 --- ## 记忆 结束前自查： - **哪类承诺反复到期未执行**（记「纠正」）——说明条件或动作的写法有问题，不是意志力问题 - 哪种条件写法后来被证明好用（记「有效方法」，带实例） - 用户明确不想被提醒的类型（记「纠正」）——**记了却被反复忽略，比不记更糟**，它会让整个列表失去可信度 写入 `{config.paths.memory}/zmm-track/`，先查重。 --- 不知道下一步 → 回 `/zmm`。