返回首页
最新
嘿，HN！<p>我是在开车、做饭或锻炼时，因无法记录灵感而感到沮丧后开发了这个工具。你知道灵感闪现的那一刻，但双手却忙于其他事情吗？<p>问题：Doubao AI耳机（在中国很受欢迎，类似于AirPods，但内置AI）非常适合问答，但所有对话在听完后都会消失。它是一个封闭的生态系统，无法导出有价值的内容。<p>我的解决方案：一个Python工具，监控Doubao的网页界面，并实时将语音笔记同步到Obsidian。<p>它的有趣之处在于：<p>30多种语音变体识别 - 即使你说“记下”而不是“做笔记”或使用“呃，记下这个”等填充词也能正常工作
免提操作 - 只需说“Doubao，记下，[你的内容]”，它会立即出现在Obsidian中
智能去重 - 对于相似内容不会创建重复条目
跨平台 - 适用于Windows、macOS和Linux
技术实现：<p>使用Playwright监控DOM变化和网络请求
正则表达式引擎处理语音变体和口语化表达
SQLite用于去重逻辑
异步I/O实现实时文件操作
我测试过的实际用例：<p>在办公室之间开车时捕捉会议见解
在跑步时记录锻炼想法
在做饭时记录食谱改进
在散步时快速捕捉想法
这个工具本质上打破了AI耳机的封闭生态，将其转变为一个合适的知识管理设备。就像拥有一个真正能记住和整理你所说内容的语音助手。<p>演示：说“Doubao，记下：记得研究异步模式” → 立即出现在收件箱/语音笔记/2026-01-21.md<p>使用Python + Playwright + SQLite构建。MIT许可证。<p>你觉得怎么样？你是否也遇到过语音助手无法保存信息的类似问题？很想听听你在移动中捕捉想法的工作流程！<p>GitHub: <a href="https://github.com/GptsApp/doubao-earphone-to-obsidian" rel="nofollow">https://github.com/GptsApp/doubao-earphone-to-obsidian</a>
我们使用视觉错觉风格的谜题来反映角色的心理状态。
简而言之 - 在 Docker 容器中输入 `/login` 的 Claude 代码将会在你的主机浏览器中进行身份验证 :)
我的团队几乎完全在开发容器中进行开发。如果你在开发容器内发起 OAuth2 身份验证（例如用于 Claude、Azure CLI 等），你要么 (a) 需要进行一些烦人的复制粘贴，要么 (b) 使用 VS Code，这样就能神奇地使其与主机浏览器配合工作。
这个工具将 VS Code 的魔法变成一个独立的实用程序，因此你不需要使用 VS Code，但仍然可以自动将你的 OAuth2 请求代理到主机浏览器。
基本思路（我相信这也是 VS Code 在后台所做的）是建立一个主机与容器之间的服务器-客户端关系，抓取你容器内 CLI 工具的浏览器请求，转发到主机，进行 OAuth 身份验证，然后再转发回容器。
我们已经使用它一段时间了，效果很好。想和大家分享一下。
现在是2026年，人类语言在某种程度上已经趋于统一。我们逐渐从编写代码转向编写详细的计划。这些计划已经发展到可以直接嵌入我们的工具中（例如，Cursor的计划模式，CC也有类似功能）。为什么我们不把这些计划像代码审查一样进行审查呢？
最终，我们对Python的看法将不会再像现在对汇编语言的看法一样。我从不检查GCC编译器的二进制输出，因为我信任它。我现在所看到和使用的工作流程完全不同。我希望团队能够对计划进行代码审查，而不仅仅是对实现进行审查。
AI尚未达到确定性，因此我们还没有达到GCC编译器的水平。然而，一个好的计划审查的价值是实施审查的10倍。代码是一种商品，而计划则是尚未解决的部分。你可以花几个小时让你的代理去实现，然后把所有东西都丢掉，或者让团队达成共识，几乎一次性完成大多数任务。当然，这在AI出现之前就一直是如此，达成共识关于构建什么总是比如何构建更重要，但像Claude Code和Cursor这样的工具使得计划成为唯一真正重要的部分。
团队应该在一个结构化的文本文件上达成一致。可以称之为plan.md，或者根据你所使用的实现工具命名。它描述了功能、逻辑，最重要的是成功的衡量标准。
以下是实际的工作流程：
1. 选择一个任务，并使用Claude Code / Cursor创建一个plan.md文件。根据需要进行迭代，确保你有好的成功标准，以便代理可以朝着这个目标构建。
2. 打开一个草稿PR，附上该文本文件。将其放入Slack中。团队在Slack或GitHub评论中对方法达成一致。我通常更喜欢在Slack上对计划进行迭代，而在GitHub评论中进行代码评论。
3. 一旦团队对计划表示认可，就将代理指向该计划。由于成功标准已经写出，代理可以自我验证。
4. 一旦你对实现满意，现在就更新PR，附上生成的代码，让你的队友像审查任何代码审查一样审查代码，除了他们已经审查过你的计划，因此有更多的上下文。
老实说，如果没有氛围编码，我绝对不会去做这么轻浮的事情。
我被指派撰写一个临时开发但使用频繁的遗留系统的需求。我将这种写作称为“追溯性需求”，简称“retreq”。类似地，我将“追溯性规范”称为“retspec”。请问这个术语或类似的术语是否已经存在？