那篇讲我怎么把 AI 对话自动同步到知识库的文章发出去之后，我用了几周，发现两个我没意识到的问题。一个是脚本本身的 bug，另一个是——这 bug 一半是我自己造成的。
这篇不讲实现细节，讲的是我作为需求方，怎么把一个自动化工具"用着用着发现没做对"，再花了两天和 AI 一起把它改对的过程。
故事的核心不是 AI 怎么改 bug，是我作为发需求的人，应该怎么把需求讲清楚。
01 早上 10 点的 sync 报告
我每天早上 10 点会有一个定时任务，把我前 24 小时里用过的 AI 对话同步到 Obsidian 知识库。
同步的脚本逻辑是：检查每个会话文件的修改时间，跟上次同步时的记录比一比。有变化就重新生成卡片，没变化就跳过。
那天早上 10:05 我看了一眼日志：
[Codex] 生成: 0, 跳过: 18, 失败: 0
[WorkBuddy] 生成: 4, 跳过: 8, 失败: 0WorkBuddy 那边有 4 个新生成，对得上——我前一天确实聊得挺多。
Codex 这边 0 新生成、18 跳过——看着很正常。脚本跑了 18 个会话，一个需要更新的都没有。
但我心里咯噔了一下：怎么可能一个都没动？
02 跳过 ≠ 没动
我随便点开了几个"跳过"的 Codex 会话卡片，翻了一下里面的内容。
发现里头其实是有新对话的——前一天的提问和回答都在。
也就是说，脚本说"没动"，但文件其实被 Codex 写过了。
我又看了一眼那些会话的"创建时间"：好几个都是 2、3 周前建的。也就是说我可能在更早之前就开过这个会话，但隔了两周又回来接着聊。
那为什么脚本会判定"没动"？
我又翻了一下我的 sync 日志，看了好几天：
[Codex] 生成: 0, 跳过: 18
[Codex] 生成: 0, 跳过: 18
[Codex] 生成: 0, 跳过: 18这种"全跳过"的状态，已经持续很多天了。
也就是说，这个 bug 不是昨天才出现的，是我从来没去翻过结果才没发现。
03 最蠢的需求：我想知道"最近聊过什么"
我同步这些 AI 对话到知识库，不是为了备份，是为了以后能查。
我经常会有这种需求：前几天跟 AI 讨论过的一个东西，我想再翻出来看看。
我就去索引里找。
索引当时是这样的——
按会话创建时间排，最近的几个会话是：
- 2026-06-24 帮我备份，然后开干
- 2026-06-24 重新写，可以先写前 10 章
- 2026-06-23 小红书工作空间
- 2026-06-22 我用 Obsidian 加 AI 搭了一套个人知识库
- ...
但这些会话里好几个我前两天才聊过。比如"帮我备份，然后开干"——我前天还在问 AI 怎么用 rclone 同步两个云盘。
也就是说，我用"创建时间"去找"最近聊过什么"，完全是错的。
我想要的功能，工具根本就没提供。
04 为什么没做对：我的需求没讲透
回过头看 v1 的开发过程，那次我给 AI 提的需求大概是这么说的：
我想让 Codex 和 WorkBuddy 的对话自动同步到我的 Obsidian 知识库，每条会话生成一张卡片。
AI 听懂了。它做出来一个能用的版本——每天扫一次文件，有变化就重新生成。
但我没讲的东西很多：
- "同步"是给谁用的？ 备份还是查询？我没讲
- 查询的时候，按什么排？ 创建时间还是活跃时间？我没讲
- "最近 N 天聊过什么"这种需求，我根本没提过——我以为同步完自然就能用
- 跨天、跨周的会话怎么处理？ 我没提
- 如果同步失败、跳过、漏同步，我希望能被通知还是默默跳过？ 我没讲
AI 不可能知道我心里默认的假设。它只能照着我说的做。
我给的需求，是一个"半成品需求"。
05 让 AI 修这个问题的过程：不是写代码，是讲清楚
那天我意识到问题之后，跟 AI 提了一个新的需求。这次我先把场景讲清楚了再讲功能：
我想查"最近 7 天我聊过哪些 AI 话题"。
但我现在去索引里找，按创建时间排，给我返回一堆 2 个月前建的会话——其实那些会话很多我前两天还在用。
我希望索引能告诉我"哪些会话最近活跃过"。
我顺便把判断标准也讲了：
- 如果一个会话 7 天内有新对话，就算"最近活跃"
- "最近活跃"的会话排在最上面，加个 🔥 标记
- 老的按创建时间排在下面就行
- 我希望能按时间范围查（24h / 7d / 30d）
- 我希望能只同步某一个工具的会话（Codex 或 WorkBuddy）
讲完这几条，AI 那边其实很快就把方案出了。
这次我看到了一个挺重要的差别：
- v1 的需求是"功能"——能同步
- v2 的需求是"场景 + 判断标准"——什么时候算最近、怎么算
需求从"功能描述"升级成"场景 + 标准"，AI 做出来的东西质量完全不一样。
06 我自己也没全讲对
但即使这样，v2 也不是一上来就做对的。
它第一版做出来的时候，索引长这样（简化的样子）：
🔥 最近活跃
- 帮我备份，然后开干 （1 天前活跃）
- 重新写，可以先写前 10 章 （3 天前活跃）
- 小红书工作空间 （5 天前活跃）
- ...
全部会话（按创建时间）
- 2026-07-01 ...
- 2026-06-30 ...
- ...我看了一眼，说了一句：把活跃过 30 天以上的也显示在 🔥 区。
AI 又改了一版。
我改完又看了一眼：算了，太长了，7 天之前的还是放下面吧。
AI 又改回来。
也就是说，v2 也不是一次性定下来的，是我看到中间结果，又反悔、又改、又重做。
这其实才是需求沟通的真实样子。
07 我自己复盘：需求讲不清楚的 3 个常见原因
写到这里，我自己想了下为什么会发生这种事，以后怎么避免。
==第一，我以为"显而易见"的事情，对方不知道。==
"同步对话"在我看来 = 同步 + 排版 + 能查询。
在 AI 那边 = 读文件 + 写文件。
这两边对"同步"的理解差了好几层，但当时我没意识到。
==第二，我自己的需求还没想清楚。==
"我想要一个能同步 AI 对话的工具"——这句话听起来很清晰，但其实我自己也不确定同步完会怎么用。我以为做完再想，但做完再想就晚了。
==第三，我没意识到"跳过"也是一种失败。==
"0 新生成，18 跳过"——我第一眼看到的时候觉得"稳"。
但"跳过"如果是错的，那它比"生成失败"还糟糕——因为它不会报错。
报错的功能我至少会去看一眼；静默跳过的功能，我会完全相信它。
写在最后
这篇我本来想写"v2 怎么修的"，写完发现，真正值得记下来的不是技术细节，是我作为需求方的几个反思：
- "功能描述"和"场景 + 判断标准"的需求，做出来完全不一样
- 需求不是一次讲完的，是看到结果再反悔、再补、再调整
- 静默跳过的 bug 比报错还可怕，因为你会一直相信它
v2 还有可以继续优化的地方（老的卡片要不要按活跃时间回填？时区怎么处理？），但这次我学到的更重要的事是——
我作为发需求的人，应该为这个工具的 bug 负一半的责任。
下一篇我应该会写《WorkBuddy 打通 IMA 和飞书文档以后》——同样的故事，又会发生一遍。
_本文适合：跟 AI 协作做工具，但经常发现"做出来的不是我要的"的人。_