我做完了一个 AI 语音 App，最后把 App 删了
AI 已经能在很短时间里写出一个功能完整的 App。可功能写完了，不等于人愿意每天打开它。代码变便宜以后，使用摩擦反而成了更难处理的问题。
我花了一段时间做了一个 AI 语音产品。它能识别语音，理解我是在安排计划、记录执行，还是做复盘；它还有日历、知识库、个人画像和不同层级的记忆。
真正开始使用后，我把独立网页和数据库都拿掉了。最后留下来的，是 Obsidian、Mac 日历、iPhone 快捷指令，以及一个在 Mac 上运行的小程序。它负责把语音转成文字，判断内容应该去哪里，再写进我原本就在用的工具。
两版产品想做的是同一件事：让一个刚冒出来的念头，不必经过打开 App、找到页面、选择栏目、整理格式这一串动作，就能进入我的个人知识库。个人 AI 工具的价值，也许不在于自建一套完整系统，而在于缩短信息进入现有工作流的路径。
我想做的从来不只是语音转文字
普通的语音输入解决的是打字问题。你说一句话，屏幕上出现一段文字，后面仍然要靠自己整理。
我想再往前走一步。
比如我说：
下午两点看课程。最近安排得太满了，也该留点时间休息。
系统需要听出这里有两件事：前半句是一项日程，后半句是一段复盘。日程要进入今天的计划，复盘要留在当天的笔记里。如果涉及修改日历，还应该先让我确认。
这就是我理解的 Agentic：AI 不只回答问题，还要判断下一步该做什么，并把结果写进真实使用的系统里。
再往后，这些日常记录还能汇总成周复盘。积累得足够久以后，我可以从中看到自己反复出现的判断、习惯和问题。语音只是入口，真正的目标是把计划、执行、复盘和个人知识连接起来。
第一版的问题，是我同时造了大脑和身体
第一版叫 DI，意思是 Do it by AI，这是我给这套个人计划与复盘系统起的项目名。我给它设计了规划、执行、复盘三个区域，还有日历视图、自然语言修改日程、不同层级的个人记忆、八个维度的状态面板，甚至基于复盘数据做过 AI 个人画像。
从产品设想看，这一版相当完整。它试图把个人计划、知识管理和 AI 助手都装进一个网页里。
开发时，完整很快变成了负担。
我既要处理语音有没有听懂，也要处理网页怎么显示、数据库怎么关联、日期如何同步、不同页面如何保持一致。
这些问题当然可以继续修。麻烦在于，我每天已经在用 Obsidian 写笔记，也已经在用系统日历看安排。DI 增加了第三个入口。我每次使用前都要多做一个决定：今天到底去哪里记？
个人工具一旦要求我迁移旧习惯，它就已经开始收取使用成本。界面再完整，也抵不过我懒得打开。
我也考虑过是不是要这个产品与ios的日历关联，但相同的日历功能，目前个人使用而言无异于重复造轮子。
如果用“一个可以每天使用的独立产品”作为标准，第一版没有成功。它的功能比我的真实使用需求走得更远，而最核心的语音写入链路还没有稳定到让我放心。
第二版保留智能，借用我已经在用的工具
第二版叫 Voice Capture。我重新写了一遍产品定义：
说完一句话，自动写进正确的位置。
我不再自建知识库界面。Obsidian 负责阅读、修改、搜索和双向链接，Mac 日历负责时间提醒，iPhone 快捷指令负责手机录音。我只开发现成工具之间缺少的那一段：听见、听懂、写对。
现在，从说话到落盘大致经过这条链路：
按住快捷键或在手机上录音
→ 语音转成文字
→ 判断是计划、完成、复盘，还是一句话里有多件事
→ 按固定格式写进当天的 Obsidian 日页
→ 需要修改日程时，由我确认
→ 把必要内容同步到看板或系统日历这里有一个重要选择：当天的 Obsidian 日页是唯一的主账本。看板和日历只是同步出去的副本。
这个约束减少了大量麻烦。以前多个页面都可能修改同一件事，系统需要不断处理谁覆盖谁。现在只需要保证一处内容正确，其他地方同步失败也能补回来。
两版产品的共同愿景没有变化，承载方式完全换了。自建数据库换成了 Obsidian 日页，完整网页换成了轻量控制台，多处都能编辑换成了一个主账本，高风险操作则保留人工确认。
第一版试图让用户住进一个新系统。第二版主动进入用户已经生活的系统。第一版把产品价值理解成功能完整度，第二版开始关注一个念头到达目的地需要经过多少步骤。
两次 MVP，验证的其实不是同一件事
回头看，两次开发最重要的差别不只是“文字变成语音”，而是 MVP 要验证的核心假设变了。
第一版从文字输入开始。我想验证的是：AI 能不能理解一段话，并在一套完整的计划系统里推动规划、执行和复盘。为了让它有地方执行，我又搭建了日历表、周泳道、数据库和任务状态。AI 在我自己铺设的轨道上运行。
这个选择并非毫无道理。文字输入可以暂时避开语音识别噪声，自建数据库和界面也更容易控制字段与动作。但范围由此迅速扩大：我不只是在测试意图识别，还要同时证明自己能造好日历、任务系统、知识库和完整 App。
第二版验证的问题更窄：
一个刚冒出来的念头，能不能通过语音，以最短路径进入我已经使用的知识和时间系统？
因此，第二版反而选择了更复杂的语音入口，却删掉了更厚的产品外壳。Obsidian 负责知识承载，Mac 日历负责时间呈现，我只保留听懂意图、校验风险和可靠写入这层能力。
这是从“解决方案 MVP”转向“假设 MVP”。第一版更像最终产品的缩小版，第二版则只留下验证关键假设所必需的链路。关注点也从“产品具备多少功能”，转向“说完以后，用户是否真的不用再整理，并愿意每天使用”。
我最初选择自己造轮子，也和一种常见的产品形态惯性有关：只有网页、页面和数据库都存在时，它才看起来像一个真正的产品。完整界面容易演示，自有环境也容易让 AI 操作。AI 编程又降低了“再多做一个页面”的表面成本，却隐藏了同步、维护、权限和迁移用户习惯的长期成本。
但第一版不能简单归结为走错路。正是因为真的造过，我才看见完整产品壳的摩擦，也确认自己真正愿意反复使用的是语音入口。它是一个成本不低、但有效的认知原型。
如果把这次变化压成一句话：
第一版是在证明“我能不能造出一套 AI 计划系统”；第二版是在证明“AI 能不能无摩擦地进入我的生活”。
AI、规则和人，分别做自己擅长的部分
开发过程中，我一度想把更多判断交给大模型。实际使用很快暴露了问题。
“需要去考虑”里包含“要去”，简单的关键词匹配可能把一段学习感悟当成出行计划。“我今天完成了第二条视频，实现了 MVP”，听起来有“完成了”，系统却不该因此把看板上的几项任务全部勾掉。
这些错误让我重新划定了边界。
AI 负责提取语义：这句话在说什么，有几件事，时间和行动分别是什么。
固定程序负责校验和执行：写哪个文件、使用什么格式、如何避免重复、连接失败后怎么保留原文。AI 不直接生成整份笔记文件，也不直接改看板。
人只保留高代价的决定。感悟写错栏目，之后还能移动；日程写错时间，可能直接影响一天的安排。因此复盘可以自动写入，新增、修改或取消日程必须由我确认。一句话里混着多件事时，系统把它们分开，我再勾选需要执行的部分。
可靠性也因此有了更实际的定义。目标不是要求 AI 永远不犯错，而是让它犯错时不丢内容、不悄悄改动重要数据，并且能让人看见发生了什么。
听错一个字还能改。听懂了却写错地方，甚至直接消失，才是语音工作流真正需要防住的问题。
最难的不是转写，而是判断一句话在做什么
产品真正进入日常以后，我发现“意图识别”并不是给整段话贴一个标签那么简单。
比如“我已经完成了 AI 语音的复盘”。这里的“复盘”是任务名，“完成了”是在汇报任务完成，系统应该去勾选已有待办。可如果我说“我完成复盘后发现，自己以前太关注产品外壳”，前半句仍然是完成任务，后半句却是一段值得保留的感悟。它们不能被一起塞进复盘，也不能因为出现“完成”就把整段当成日程操作。
这让我把原来的一次分类，改成一条分层判断链路：
保留原始转写
→ 生成去掉“嗯、啊”等噪声的分析副本
→ 把长句切成若干语义片段
→ 判断每段是在下指令、讲计划、汇报结果，还是表达感悟
→ 查找相似的历史误判案例
→ 让 AI、固定规则和历史案例分别给出判断
→ 根据错误代价决定自动执行、要求确认，还是暂时阻断原文始终保留，清洗只作用于分析副本，避免“去噪”顺手删掉重要语气和上下文。日程完成、取消、改期属于高风险动作：即使模型很有信心，也要先匹配到具体任务；感悟和灵感则优先保证不丢。
我也不再只靠自己不断试用、发现错误、临时改提示词。每次真实误判都会进入案例库和冻结测试集。修改路由后，旧案例必须重新通过。新判断逻辑先以 shadow 模式跟在旧系统旁边运行，只记录两者分歧，不立刻改变真实写入。确认稳定后，才逐步接管执行。
这部分开发让我意识到，个人语音产品最有价值的数据，不一定来自互联网上的大型通用语料，而是来自一个人真实说过、并且明确纠正过的边界句。它们记录的不只是中文语义，也记录了这个人如何表达计划、完成和感悟。
GUI 的任务，是让我不用猜系统有没有工作
第一版的 GUI 承担了太多职责。它既要展示知识，又要管理任务，还要呈现日历和个人状态。
第二版把界面的目标压缩成几个问题：现在能不能录音？刚才那句话写到哪里了？有没有待确认的日程？手机和 Mac 之间的链路是否正常？
因此，我把界面缩成三个必要反馈：
- 按住语音快捷键开始说话，系统通知显示录音和转写状态；
- 涉及日程时弹出确认框，显示准备修改的内容；
- 菜单栏或悬浮小图标显示服务是否在线，并告诉我上一条内容写到了哪里。
录音通知和日程确认已经可以使用，状态与写入收据还在继续完善。手机上只保留一个简单的待确认页面，不再复制一套 Obsidian。界面没有消失，只是回到了合适的位置。它不负责承载全部知识，只负责触发、确认和显示状态。
如果没有这些反馈，我仍然要盯着终端看日志，猜录音服务是否启动、手机请求有没有到达、文件到底写没写成功。那仍然是开发者在调程序，还谈不上一个日常产品。
AI 能快速写代码，却碰不到最后一公里
这个项目里，写代码有时反而是较快的部分。更耗时间的是手机、Mac 和操作系统之间的连接。
麦克风权限没有开，快捷键就没有反应。Mac 睡眠后，手机访问不到本地服务。外出时，手机不能直接连接家里的 Mac，只能先把文字存在云端，等 Mac 上线再同步。自启动服务到底由哪个程序运行，也会影响权限和行为。
AI 可以告诉我应该检查哪些配置，也能生成诊断脚本。它无法替我在真实设备上按下快捷键，无法亲自感受某次请求为什么等了三十秒，更无法替操作系统授予权限。
这改变了我对 AI 编程效率的看法。代码生成的成本下降了，集成、权限、网络和验收的成本没有同步下降。个人开发者节省下来的编码时间，最后经常花在系统边界上。
第一版失败了，但它没有白做
“失败也是经验”很容易变成安慰自己的话。第一版真正留下的价值，需要落到具体结果上。
它让我确认了自己愿意持续使用语音记录，也让我量出了自建网页、数据库、日历和知识库的代价。如果没有先做过完整 App，我可能还会一直觉得缺的是更多页面、更漂亮的面板和更完整的功能。
做完以后，我才敢删。
我也积累了一套更具体的 build 方法。每次真实使用中出现误判，我会把原句加入测试。例如“下午看课”“需要考虑”“我今天完成了第二条视频”，都不再只是一次偶发事故，而会变成以后改代码时必须通过的标准测试句。
这套方法比继续堆提示词更可靠。口语没有整齐的格式，只有真实说过的话才能暴露规则边界。系统每犯一次错，就应该多留下一条测试和一条可检查的记录。
现在回头看，我得到的经验可以压成三句：
- 1.先找出最短的价值链路。对这个项目来说，就是说完以后，内容能进入正确的日页。
- 2.能借用的承载体就借用。把时间花在只有自己能提供的那层能力上，而不是重做用户已经习惯的工具。
- 3.按照错误代价分配权限。AI处理模糊含义，程序执行确定动作，人负责授权和例外。