说话人 1 来，今天要早一点出门的。本来想是早一点出门，这样还能去嗯你才能去找他，但是就很尴尬呀。临出门发现啊，他是那个 A coldness 刚才也突然哎，12点的时候想，我12点开始练。那万无一失了，确定一下。没想到修改一下，然后修崩了。大概了解了一下。我跟他吐槽说长时间，但是不太确定是不是这个原因。因为并行，还有那个搞那个浏览器插件。但是浏览器插件我也不太确定。网上也有人传说是浏览器插件。跟那个 CodeX 有 bug，然后所以现在今天是叠加了版本更新，加上让他去做修复那个长时间控制那个。移动端设备的这个东西，因为控制暖暖，他现在看起来没有我发比来好用，因为它会涉及到网络的连接。然后远程的连接。等系列内容吧，反正就是从连接这个角度，Codex 反而给我造成了很大的困扰，因为它不是能特别稳定的去处理。 说话人 1 相比较来看的话， Walkie Talkie 它来去做那个连接这一块，它至少可能因为有国内的环境。它没有受限于那么复杂的体系，它其实这个连接是非常稳定的。虽然说他们那个 APP 交互现在做的一言难尽，体验并不是很友好，但是我看他也在努力去优化这几个方向了。那具体呢，可以体现在这几个方面。 说话人 1 今天我刚好看到了那个卡兹克，也分享了那个移动端，Workday 移动端这个事情。然后我还在想说，今天看到那个，还是朋友分分享给我，然后我觉得啊，是家人分享给我，家人分享给我说今天看到卡斯特分享那个腾讯的 Walkie Talkie 移动端连接的这个事情。然后我刚好就是想到了，其实我最近也在用这个事，这个东西，分享一下我的体验。 说话人 1 这个事情早在我半年前的时候，那个时候龙虾刚出来。甚至说龙虾出来之前的时候，我就一直想要有一个移动端去控制的方式。在很早以前就了解到，就是最开始有一个那个叫代码的一个编辑工作，我忘了叫啥了，好像是贾维斯还是什么东西来的。就是当初最开始的时候，在 Cursor 出来时候不是变 AI web coding 爆火嘛。然后出来这个之后，然后陆续出来了很多那种coding 的工具。那其中有一款就是是，它付费特别高，我我还尝试去用过。然后它当时是云端操作的，它相当于是直接控制那个 GitHub 云来去操作一系列内容。它当时特别贵，我记得我当时好像是20美金，就跑了两个任务就结束了绘画。所以说对我来说是相当贵的。 说话人 1 在现在看来这个有了给我20美金，你都可以用一个月的 Colab 去反复做很多东西了。但那个时候不行，而且还是当时让他改一个很简单的前端的操作。也非常费钱。但是当时，那个时候是一年前吧，差不多一年前的时候，我也不太记得了，我觉得到时候在写这个文章的时候。可以让我的 AI 去找一下我的日记，因为我当时日记应该可能会记录一下，记录了这个内容。然后再后来的话，就是一段时间，我就才尝试用那个 SSH，因为当时我刚好有一个阿里云。然后我就相当于去登录我的阿里云，然后在里面去做一些修改，然后就提交到 GitHub 里面。但其实整个操作还是比较繁琐的，还不像现在这样这么便捷。然后有一段时间一直在弄那个改，然后一直就是相当于它都是命令行终端嘛，整个那些操作也不便捷。然后当时我还在想要不要自己做一个什么什么 SSH 工具，让它变得更加方便。但是由于自己的这个技术水平确实没办法实现这一系列。所以，而且还有很多其他的事情要做，所以精力也没有放在这个这这上面。 说话人 1 再后来随着龙虾爆火，然后其实就看到了移动端控制，就是操控一系列的可能性嘛。因为相当于龙虾它就作为一个媒介。来去操作这一系列。当，但是当时龙虾出来的时候，我其实就觉得，因为我平时一直都在用那个 SSH 来去跟那我系统交互。所以对我来说龙虾它无非就是把这个操作的终端，从这个移动端的这个命令行。 说话人 1 到了移动端的一个 APP 应用而已。所以现在去找我那个时候，就龙虾刚出来那个时候，我其实本来想去做一个一个播客或者怎么样。就是关于我我现，我觉得为什么我觉得龙虾它看起来跟我这个 Codex 差不差不多？如果有一天，CODESYS 出了移动应用的话，那它其实完全就可以替代龙虾了。 说话人 1 我们现在回到现在，其实也能看到，时隔这样半年，这个龙虾基本上是没有什么人提及了，因为很多这个大模型。他们中，他们自己就佩戴了这样的移动端的工具。也意味着就是我们不再需要，就是自己去配置复杂的龙虾操作。只不过它是一个开源的东西，它可以给任何极客来用，它可以允许集成到任何的地方。但是这个方式其实本身，就是随着，也是龙虾这件事情出现之后，激发各个大厂也都在痛。在平常去做这件事情。也让每一个就是可能像我这种比较叫什么，个人的玩家。然后也可以去，就是操作起来了，将它用一种更便捷的方式，不用依赖于场域，只是在任何地方都那这是一部分。 说话人 1 再后来的话。因为我很早以前其实就听说过他们，那个叫什么 OpenAI 内部，还有克劳内部，他们自己就是在使用。那个云端的就是写作，代码写作。他们在编辑一个什么事情，就直接会提交到仓库里面，然后他们去进行写作。那是，只不过现在随着时间的发展。逐步把这个体验，就是移动到那种 APP 终端，让每一个人都有可能性去操控他自己的电脑。那这里就会提到操控自己电脑到底有什么好处？实际上我认为是，就像上一篇文章我就提到过。 说话人 1 一个这个模型你感觉到它智不智能，其实取决于两，它是否懂你，它其实取决于两个方面。第一方面就是这个模型它本身是否足够强大。但如果模型足够强大，但是它不了解你的话，它也不一定能够显得特别的智能，或者是非常懂你。所以另一方面就是它对你的信息了解多少。那至于了解多少这件事情，大家都在做的就是上下文管理的这件事情。那上下文管理这一块，也有很多很多种方式再去做。但是万变不离其宗，都是离不开，就是你个人的信息的一个收集和你个人信息的收集、维护以及信息的一致性啊什么那些东西。然后你用个人电脑的话，你自己的电脑，尤其是日常使用的电脑的话，它里面会有更多你个人的信息。当它有更多的信息，你用一种比较好的管理的方式让这些信息都轮转起来，然后你每次使用的时候。你都可以基于这些信息去进行对话的话，那他就更能知道你在说些什么。因为人的记忆也是有限的，他不是说你你不是说什么时候你都能回想起来。 说话人 1 事无巨细地想起来曾经发生的事情。也许昨天的事情你可能记忆犹新，但是时隔几，时隔半个月或者时隔几个月的时候，你在回顾去年或者几个月之前。你做过哪些事情？你可能没有什么印象。像以前，如果没有 AI 的话，我们在搜集一些内容的话，那我们可能会通过一些关键词来去进行寻找。但是有些内容，如果你连关键词都想不起来，那你再去寻找的话，这个记，这个效率是非常低下的。但是有了 AI 的话，你只要给个大致模糊的概念，即便没有匹配上对应的关键词，它依然可以根据你描述的时间段。然后描述的内容，来，通过各种寻找的方法，来帮你找到对应的信息。这个就是所以这里就提到为什么要用个人的电脑，因为个人电脑里面有各种材料，你在其他的平台去操作那些事情。除非你有很好的信息管理的习惯，你可能说你自己一定会找到那些乱。就是任何你看到或者是想到的东西。但是如果你没有的话，那有些东西你可能说，你如果不用自自己电脑可能就是有利有弊。我觉得比较好的方式可能是，就是他会更了解你。那比较，有些人不敢不敢去使用自己电脑，也有他们自己的原因，比如说他们的隐私比较重要。 说话人 1 担心被窃取，或者有些重要文件怕被删除。那关于重要文件被删除这个事情呢，其实只要做好版本管理，然后限制好一些，保护分支。让 AI 禁止去触碰一些，就不给他一些明确的权限的问题就可以解决，即便他删除了本地的某些电脑。但是我们有良好的版本管理的习惯的话，它即便是操作错了，它其实也不会影响到我们的这个数据的一个一个完整性吧。就是这个就跟我们其实如如果是你是曾经是开发者的话，可能会比较了解这一套代码管理习惯。其本身我们在 AI 大模型普及了之后，其实管理信息就可能像管理代码一样。它它其实是有一套比较理想的管理方式的。比较好的模型的话，它一般也不会犯那些低级错误。那如果模型的质量差一点，你可能要给到更为详细的规则。那这些规则也可以通过 skills 或者一些 SOP 等提示词的方式。然后去限制这些模型的使用。 说话人 1 那至于隐私隐私这个层面的话，那这个就因人而异了。可能如果你的东西是一些比较重要的公司的资产。说是有，强调不能泄露的话，那你如果安全性大于这个便捷度的话，那也可以有自己的选择。可以通过用内部部署。模型的方式或者是怎样，就可能还是为了隐私，这一层面肯定肯定是要付出更多的成本。对于我这种对于一些个人的，其实隐私并没有很重要的人来说，是可以通过，叫什么，失去一部分的隐私性来换取更大的便捷程度的。因为现在顶尖的模型，它确实可以在很多地方帮助你，去实现很多你以前做的事情，可以带来几倍甚至几十倍的提效。那这样的方式的话，它其实有一些我们日常产出的一些文件，或者说我们记的东西。那这些东西其实本身我们也可能是从网络上获取的。它本身就没有那么高的一个稀缺性，除非是一些密钥的存在或者什么的存在。但是你只要能确保这些东西你是，你可以保存的就还好。其实更重要的我觉得应该是信息的隔离吧。所以所以说很多人之前在跑龙虾的时候会去新买一个电脑，就相当于将那个新买的电脑作为主机电脑。 说话人 2 那我其实个人还好，因为我在，其实在做了一个内容的一个多人账号，其实对我来说，可能比较想。就是说本身比较严重一点。 说话人 2 是说，主要就是这些新闻。必要的，但是实际上我个人，我更，你可以配置一些限额或者等方式来处理。觉得。 说话人 1 首先我觉得个人的隐私并没有那么重要。 说话人 2 我认为他跟我电电解性大的性质是这一个。好，回到我们的正题，那事情，然后提到了它的意义和重要性。 说话人 1 它的便捷的便捷度有什么好处？尤其是跟我们平时使用是非连接电脑的方式。那当我们使用连接电脑的方式时，目前我就在用两款。 说话人 2 一是。 说话人 1 Hold X up 是巴迪的那个，连接电脑工具。他们两个电脑各有优劣，前面就像我最开始提到过，那个 Work Buddy 的话，它这里。它毕竟是国内的公司。他晚安。它的连接稳定性是永远好于口袋。上。不存在什么连接问题。 说话人 1 存在一些连接性，而且由于最近它免费，所以其实也没有什么额度的问题。就像我在使用 Colleagues APP 的时候，我每天还要注意它的额度。度，还是生成模型。然后 Workday 之前，就前几天前，其实它还不具备那个切换模型的作用，就是功能。但是这两天上线看它已经改掉了。它在连接电脑模式的时候也可以去开设新的窗口，然后连接模型。它之前的话它只有一条通信的通道，然后也不能选模型。导致我每次用的那个连接电脑的时候都要花费，额外花费 token。所以那个时候并没有怎么使用。但是不管怎么样，它它们的那个逻辑是比较像的。都是在手机端操作，你其实在电脑端就能看到它，去进行操作。因为它本身其实只是一个窗口嘛，它运行就是运行在你的电脑上，所以你在电脑上可以无缝去衔接住这个操作。然后继续去操作它。 说话人 1 那但是现在目前我体验下来，可能 cotai 的 APP 比较好用的点在于说它的一个交互是比较自然的。它整个设计风格。动态的效果，然后等待的一个样式。就是说会有更多的信任感在里面的。然后我花臂的话他整个设计风格，嗯。就是动态的效果的话，就就差一点。具体体现在他的那个胶布的样式，比较生硬的。然后，现在我不太确定它是不是能够开多个窗口并行来处理，因为我发现我在开多个窗口的时候。它自己就停止了。操作不过我不知道它是样式的问题，还是说它现在就是同时只能进行一个远端进程的处理。但是这一点的话，CODESYS 的它的那个 APP 就可以。同时操作很多个对话，这个对我来说还是一个比较用目光，因为现在很多 agent 它在执行的过程链路是非常长的。我不可能在一个画面一直等待他操作。我通常都是像收菜一样，就是会开启一个目标之后，我就会接着去处理下一个目标了。只偶尔，当他差不多处理完成了之后，我才会去看他，一个处理的结果。如果要是一直等待在那边的话，其实所以说多多线程并行的这样的一个操作对我来说是非常重要的。 说话人 1 其他的目前其实还好，就是这个我觉得是本质上影响我的东西，其他都是一些体验层面的交互细节。我觉得当他们想修复应该还是可以处理的。总之就是我认为就是移动端操作是一件非常好用的事情，也希望各大厂商都卷起来，这样的话也有更多的选择。然后不管是在，用各个 APP，其实都在操作我自己的电脑。我所有的数据是共享的，也就是说我可以用不同的 APP 连接电脑，然后去同时操作我电脑上的文件来进行多版本的并行和多工作数的处理。票票票。 音频文稿完整详细总结 这份音频是一段个人分享，核心围绕移动端远程操控本地电脑、AI代码/本地设备控制工具展开，讲述分享者的工具使用历程、两款主流远程控制工具对比、移动端操控本地电脑的核心价值，同时分析隐私、数据安全、行业发展现状，整体分为四大板块： 一、本次分享的起因 1. 分享者原定提早出门办事，计划12点启动工具练习，却因修改工具配置直接崩掉；故障诱因推测为三点叠加：工具版本更新、并行运行程序、浏览器插件冲突，网传是CodeX存在程序Bug。 2. 亲友分享了卡兹克（卡斯特）关于腾讯Walkie Talkie移动端远程操控的内容，刚好契合分享者近期使用同类工具的实际体验，因此决定输出本次使用感受分享。 二、个人移动端远程操控工具使用发展史 分享者从一年前至今，逐步尝试多代本地/云端代码、远程操控方案，踩坑不断： 1. 早期云端付费代码工具 Cursor带动AI网页编程热潮后，出现一款高额付费云端编码工具，依托GitHub云运行，单次成本极高：仅运行两个绘图任务就消耗20美金；对比当下同等金额可包月Colab，性价比极低，仅完成简单前端修改就耗费大量成本。分享者计划后续通过AI调取日记，精确复盘这段使用经历。 2. 阿里云SSH命令行方案 改用阿里云服务器，通过SSH终端登录操作、提交代码至GitHub，但全程依赖命令行，操作繁琐低效；曾想自研简易SSH工具，受限于自身技术能力与精力搁置。 3. 龙虾开源远程操控工具（半年前爆火） ◦ 定位：作为移动端与本地电脑交互媒介，本质是把SSH命令行转移到手机APP端；刚上线时分享者就预判，若CodeX推出移动端APP，可直接替代龙虾。 ◦ 行业影响：龙虾爆火激发各大AI厂商自研内置移动端操控功能，如今半年过去龙虾热度大幅下滑；优势是开源、可自由集成，适合极客，降低普通玩家远程操控门槛，不用复杂手动配置。 4. 行业背景补充 OpenAI、Claude内部早已在用云端代码编辑，可直接提交代码仓库；如今技术下放，普通用户也能通过手机APP远程操控个人电脑。 三、移动端操控个人电脑的核心价值 判断大模型是否“懂用户”由两大要素决定：模型自身能力、模型掌握的个人信息，远程操控本机的核心优势围绕本地个人数据展开： 1. 大幅提升AI信息检索、理解能力 个人电脑存储大量长期私人文件、记录，AI读取本地数据后，上下文信息更完整；人类记忆存在时效局限，很难回忆数月前细节，传统检索依赖关键词，遗忘关键词就无法查找；而连接本机的AI仅需模糊描述、大致时间范围，就能自动匹配对应资料，解决记忆与检索痛点。 2. 数据安全风险对应的解决办法 用户两大顾虑：文件误删、隐私泄露，均有对应解决方案： ◦ 文件误删：借助代码式版本管理、权限分支隔离，限制AI操作敏感目录；即便误删本地文件，版本记录可完整恢复数据，把个人信息管理类比代码仓库管理。同时可通过Skills、SOP提示词约束模型行为，劣质模型可补充更细致操作规则。 ◦ 隐私泄露：分两种选择，按需取舍便捷度与安全性 ① 企业涉密场景：优先安全，采用本地私有化部署模型，承担更高成本； ② 普通个人用户：本机资料大多来自网络、稀缺性低，仅密钥类信息单独隔离保存，可适度牺牲部分隐私换取数十倍工作提效；行业通用方案：单独购置专用主机运行远程工具，隔离日常隐私数据。 3. 补充观点：多人账号、使用限额等问题可通过配置限额规则缓解，隐私风险对普通个人用户影响有限。 四、两款主流移动端远程电脑工具实测优劣对比（CodeX / Walkie Talkie（Work Buddy）） 两款工具底层逻辑一致：手机端下发指令、本地电脑执行、两端操作无缝衔接，数据互通，可多工具同时连接本机并行处理任务，但体验差异明显： 1. Walkie Talkie（腾讯，国内工具）优势 • 网络适配强：国内环境优化，远程连接稳定性远超CodeX，无频繁断连问题； • 成本友好：现阶段免费，无使用额度限制，无需像Colab类工具每日管控额度； • 功能迭代快：近期更新支持多窗口、切换模型，此前仅有单通信通道、无法换模型，使用成本高、很少启用。 2. Walkie Talkie 短板 • APP交互设计差：界面动效生硬、弹窗样式粗糙，官方虽持续优化但体验仍不足； • 并行能力存疑：多窗口开启后任务易中断，暂无法确认是界面显示问题，还是仅支持单远端进程运行。 3. CodeX（海外工具）优势 • 交互体验优秀：UI设计、动态加载、加载动画更自然，使用信任感更强； • 支持多线程并行多对话：可同时启动多条Agent长链路任务，不用单一窗口等待，像“收菜”一样批量下发任务、抽空查看结果，对多任务工作流至关重要。 4. CodeX 短板 • 网络缺陷：海外架构，远程连接不稳定，给日常操作造成大量困扰； • 存在程序Bug：叠加版本更新、插件、并行任务时极易崩溃。 五、总结与展望 1. 移动端远程操控本机是高效实用的工作方案，不同工具可同时连接同一台电脑，实现多版本、多工作流并行处理； 2. 期待行业厂商持续迭代同类工具，形成充分竞争，给用户提供更多选择； 3. 工具各有取舍：国内Walkie Talkie胜在稳定免费，海外CodeX胜在交互与多任务并行，可根据网络、工作需求按需选用。 说话人 1 刚刚我实际去测试了一遍，然后发现我刚刚其实有一些内容是误解的，对 Workbody。其实它本身是可以多对话并行的，也就是说其实最最，就是我之前最在意的那个点，它其实是不存在的。就是它并不是不能并行对话，只是它的交互看起来一卡一顿的，让人误以为它没有在执行，以为它卡掉了。但实际上它正在执行当中。我不知道，可能是它的那个前端的一个一个效果，然后不是，效果不是特别好，然后实际上我让那个 Codex 去调查了。他其实那几个让他跑的内容，他其实已经都跑起来了。并不是像我以为的那样，他没然后我实际对比了一下，他们两个其实本质上能实现的功能都是差不多类似的。 说话人 1 那其实本身从体验层面最大的问题，我觉得可能也不是交互层面的卡顿这些东西，因为它既然能完成。那至少这个任务最终它肯定是有效果的。那它即便是效果卡顿一点，或者样式不好一点他只是你觉得他体验友不友好的问题。但是体验友不友好这件事情也没有什么特别大的影响，因为我们本身就是像烧菜模式，扔出来一个内容。然后他就去做就好了。中间我们也不会一直在那去看他这个东西到底有没有做完。只是说这个可能做的这个心情的过程中，可能你会更享受去使用 Codex 那个产品，但是在使用 Walkie Talkie 的时候。可能会有一种就是目前有一种 low low 的感觉。但是这个视觉层面、交互层面的内容，它们随着版本的更新一定会趋近于越来越相似，所以我觉得这个倒不是什么问题。 说话人 1 那还有一个，我可能比较在使用便捷层面上，操作起来可能比较便捷的方式，就是因为我们本身在本地会有很多 skills。 然后在，其实，就是我在 Codex APP 的时候，在使用它的 Skills，它的操作是完全复刻电脑端的操作的。就在我使用一样的面，那个符号的时候，它其实两边都是在进行更新的，但是在使用那个就是 Workman 的时候。他并没有，就是照，在 APP 端并没有像电脑端一样输入同样的，就是指令来去召唤出一样的 flow 操作。是不是因为他们最近也是在拼命赶工上线，所以并没有把这一层的这个体验层面的内容加进去。 说话人 1 但是对于我的实际使用的体验其实还是影响蛮大的，因为我基本上每一个操作都是需要要借助一些 skills 来完成的。因为尤其是我前面不是说过，就是我之前的那一个对话，就是我其实提到过这件事情，就是因为即便模型不管它有多强大或者不强大。他如果不了解我到底想做哪些具体的事情，因为我有可能自己有一套标准的 SOP，我有一套固定的一个流程。如果他不按我那个流程来做的话，那可能还是需要我反复去跟他对话，来去完成一些事情。所以有了这个 skills 它可以去稳定的按照我想要的要求去完成固定内容，写入到固定的位置。然后就生成类似某些我需要的文件。或者是进行某些存储，或者是说思考哪些流程。那这些东西，他如果没有的话，那我可能要去，我去，就是我我就需要去跟他打一个可能就那个叫。需要去打一个关键词，那那关键词我可能会输错，那他可能就没办法命中他的缓存，或者是说他可能没办法理解我的内容。所以我觉得这个还是一个嗯操作的一个层面。 说话人 1 那我们，但其实问题应该也不是很大，因为如果我，就是相当于我要稍微花点力气去跟他讲到底你要根据哪个流程去做。然后让他具体去具体去查找。那沈天也没有说多少的影响。那我在想那个写那个文章，我现在刚刚已经让那个，Vogbody 来去帮我写了，我不太确定他能写出来什么样的一个结果。 说话人 1 我在想他两个其实差异还有，就比如说在 CodeX 使用的时候，其实会感觉到它在手机端使用跟在电脑端使用基本上可以是完全复刻一样的体验。比如说我在电脑端想去创建某一个新的文件夹，它也可以实现。它是在5个8的层面，它只能去选择你以前创建的那些文件夹。如果你在桌面端没有去创建那些文件夹，你在电，手机端你是没办法创建新的文件夹的。这就导致，那我可能有一些内容，如果我想去在其他文件夹创建，那是就不可能的。 说话人 1 那这个其实有什么不好的地方呢？是因为，我把它，它会写记忆，它会写历史的一些内容，就是它有出现问题的时候，它如果不写在同一个文件夹。然后下一次我要又写在另一个文件夹，如果我们不在一个文件夹写内容的话。他可能会把一些脚本或者甚至说一些注意事项都写在某个固定的文件夹。如果我们没有遵循上一个文件夹的内容，那我们犯的错误他可能不会记得。且这个问题我一直我觉得这个是上下文管理中的一个一个小的 gap 吧。 说话人 1 然后这个问题其实我在上一篇文章中我就给大家讲过，在创建一个存档的工具探板，在解决某一些特定类型的问题的时候。如果我觉得这个是一个比较经常会复现，或者后未来可能有一天会想要来查找历史的时候。我会把它去按照一个 skills 规范流程去植入我的看板，然后再去这个看板中让他帮我去寻找相关的内容。而不只是说依赖于也不只是依赖于，就是他自己本身的工作去记忆。因为工作去记忆，他可能会记忆一些细枝末节的东西，那这些东西并不是所有东西都要记录的。而且不存在那种情况，就比如说今天他记了一笔，明天他又记了一笔，他两边可能会有冲突。或者说由于模型的改进，或者某些脚本的改进，他可能曾经写的成功的记忆可能到后面会忘记。然后这个东西在时间长了之后其实是非常难以管理的。所以像现在在商量管理这一块，我也在不断地进化，在看有没有什么更好的方式来去类似解决一些事情。因为这些都是一些动态迭代的东西。虽然说我们现在这个模型已经越来越强大了，但是还是每次在操作一些事情的时候都是会有嗯。很多问题存在。至于那篇文章，我看看怎么写。先看看他的那个版本，然后把我这个今天刚刚校对过的这些实际体验的流程，然后去跟新的文章。就是去看一下。怎么去更新更改？然后还有一些，截了一些图片，我在想能不能去做类似的图片中的，就是那种对比图。 说话人 2 我会担心我这种视频的截图的话，如果直接展示在文章也会占据太多没有必要的空间。 说话人 1 所以我说在想能不能把两个什么图片拼在一起，直接去展示的那个方式。那可能需要借助一下模型帮我去做一下图片的拼接。那一会我看一下能一次性发多少个图片，然后看一下把这个图片传到。 文档详细总结 本文档是一段实测后的复盘对话，核心修正了前序录音里对Workbody（即前文Walkie Talkie）的认知偏差，对比Workbody与Codex两款远程操控工具的真实功能差异、使用痛点，同时聊到个人AI工作流的上下文/记忆管理方案，以及后续工具体验文章的撰写规划。 一、核心认知修正：Workbody支持多对话并行 1. 此前误以为Workbody无法多任务并行，实测后确认它能够同时运行多条对话任务；之前看起来卡住、断断续续只是前端界面动效差，后台任务实际正常执行，并非功能限制。 2. 两款工具底层可实现的核心能力大体一致，界面卡顿、视觉粗糙仅属于使用舒适度问题，不影响任务最终完成。 3. 使用者习惯“批量下发任务、后台自动执行，空闲时再查看结果”的烧菜式工作模式，不会持续盯界面，因此交互卡顿对实际工作效率影响有限；只是Codex界面观感更舒适，Workbody视觉质感偏弱，但该差距会随版本更新逐步缩小，并非长期硬伤。 二、两款工具关键功能差距（影响日常高频操作） 1. Skills自定义工作流同步能力 • Codex：手机端和电脑端操作完全互通，相同指令可同步调出配套Flow流程，两端数据、技能规则实时同步。 • Workbody：移动端未适配电脑端Skills调用逻辑，输入相同指令无法触发对应标准化流程，推测是开发赶工、功能尚未补齐。 • 该缺陷对使用者影响较大：使用者高度依赖自有Skills、固定SOP标准化流程，依靠固定关键词一键完成文件生成、数据存储、逻辑推演等操作；Workbody无法便捷唤起技能，只能手动详细描述完整流程，容易出现关键词输入错误、模型无法匹配缓存、理解偏差等问题，增加沟通成本。 2. 文件夹创建权限限制 • Codex：移动端支持新建文件夹，和电脑端权限统一，目录创建不受限制。 • Workbody：手机端仅能选择电脑端提前建好的文件夹，无法在移动端新建目录。 • 衍生负面影响：使用者依靠文件夹分类归档任务历史、脚本、操作记录，若分散存储在不同目录，AI上下文记忆会断裂；模型无法跨文件夹调取过往流程、历史注意事项，容易重复犯错，属于上下文管理的明显缺陷。 三、个人AI信息/上下文管理优化思路 1. 原生模型自带记忆存在短板：记忆杂乱、新旧记录冲突，模型迭代、脚本更新后会丢失过往有效存档，长期积累难以梳理管理。 2. 使用者自研标准化归档方案：高频、可复用、后续需要回溯的任务，统一通过Skills规范存入专属存档看板，主动归类关键流程，不单纯依赖模型自动记忆；区分普通临时记录与需要长期留存的标准化流程，规避记忆混乱、丢失问题。 3. 现状：模型能力持续升级，但本地远程操控的流程管理仍存在各类细节缺陷，使用者仍在持续摸索更完善的信息管理方案。 四、体验对比文章的撰写规划 1. 已让Workbody辅助生成初稿，后续会结合本次实测修正的全新体验内容，更新、校对文稿，修正此前存在的认知错误。 2. 配图方案：计划制作Codex与Workbody的界面对比拼接图；担心单独截图占用大量版面，打算借助AI模型完成图片拼接，后续测试单次可上传图片数量再统一处理配图素材。 说话人 1 刚刚在路上一直在操作这两个 APP 来去，移动端 APP 就是，Mokbody 和 Moco Docs APP 的内容。好， Codex 位置拼错，是 C O D E X 这个拼音。是 OpenAI 加的这个产品。然后这整个过程其实我就是用它来去完成了我最新版本的这个文章的创作。在想等文章出来之后，我需要让我的文章加一句，就是说你现在看到的这篇文章主要就是。有那个 Codec APP 来完成的创作，因为确实我在用它来去做创作。然后解释一下为什么我用它来做创作，而不是用 CodeX 来创作，因为我感觉 CodeX 在创作的时候。它那个文章有很明显的英译中的这种感觉。但是用中文的会好一点。尤其是如果用 the six 的话，效果会更好一点。但是现在是因为什么文员，他免费，所以我现在还是用，直接用那个。 说话人 1 来做，差不多完善。然后相当于我初稿，会让他结合我的一些思路去帮我写。我会去，首先我会用我大致的一个创作流程，我觉得可以讲一下。就是我会先用手机，我会先用录音模式，然后去把我想写的那个内容和思路。去讲一下我想写什么样的内容，我从我遇到了什么什么事情，我可能做了哪些操作，然后我想起了哪些内容。然后把这些内容梳理出来，然后去将我的这个转录文件。还有一些可能相关资料和一些我之前已经列好的 skills，收集的一些内容，还有整整理的一些内容。他那里可能会有一些措辞的要求，然后写作风，文风的设定，然后让他根据这个内容来去产出文件的初稿。当然这个通常很少有一变就可以达到满足的效果，还需要我进行二次的迭代优化，然后我要去进行处理。那我个人现在目前是将这个生成后的内容展示到了一个本地的工作看板，然后这个看板的话。我就可以直接在这上面进行编辑。啊，编辑目前设置了一些基础的操作功能，比如说标题的编辑，然后文字的编辑，然后以及文字样式的处理。然后还有一些，我默认样式模板的选择，然后他们的文章发布的状态的管理。当我确定这个文章，还有一些图片的展示，然后默认会让他去进行一些基础的配图，包括真实截图的一些选取。还有图片的标注。哦，结尾的。要求啊，那你相关参考文章的链接。以及他的一些图文的一些编辑调整。 说话人 1 还有就是我还将我的这个公众号的发布流程集成到了我一个看板。也就说当我觉得这个文章差不多可以进行发布之后，我会点击去发布，然后将它发布到我们的。就是配置好的这样的一个公众号。现在我目前是正在正在运营两款公众号。就是再两，再写两个公众号的文章，然后将配好的公众号放在这边进行配置好的管理。然后并且相关这些文章的管理。方式，然后在这边展示。 说话人 1 有一个就更清晰的这样的一个流程嘛。然后未来我还计划说看看能不能去做一个 Agent 的一个版本，然后可以让这套流程更加的智能化吧。然后还想去接入一些数据看板的一些支撑，然后目前其实只做了一个简单的。Demo 的一个状态。构思，而这一部分我可以先不放图片，因为有一些内容数据可能比较敏感。我觉得后续有机会的话，如果做的还，我觉得还比较满意的情况下，可以跟大家分享。这一系列基本上都是根据在我日常的这样的一个使用流程来去搭建的这样的一个看板。哎，其实刚好最近那个。那个什么，我和芭比正在有一个什么看板工作台分享计划，我觉得这个可以跟大家分享一下。然后这个分享计划这个事情，我现在先可以不写在文章里面，我可以先把我这篇文章发出去之后。然后去把那个这个内容去准备好一些材料吧，因为现在材料好像准备了一部分。然后现在让他去帮我提炼一些，就是提取那个工作台的模板出来，然后这个模板可以给大家用。然后包括那个昨天我其实有一个存档看吧，我觉得可以直接拿出来用。这个可以，接下来也可以拿出来用。 说话人 1 其实而且最近不是那个什么，B 站20号之前要提，能提交一个AI，用 AI 开发什么这个计划吗？除了我之前分享那个 money 那东西，其实我这个应该也可以去做分享，这两个文章的主题。而且还是一个比较通用的流程。虽然是本地化的 APP，但是这个文章，工作台样式还是可以对外去做展示的，然后可以让所需要的人去看到这些东西。然后相当于多个平台都去展示出来了，所以我觉得今天已经十几号了，我不太确定那个20号之前还来不来得及提交。其实因为家里那个还在调整。我不知道是不是。直接拿我的语音来弄会比较好，还是说还是执念于用那个 AI 工作流来搞？ AI 工作流，那个我觉得搞也可以了。然后顺便就可以把我这套 AI 工作流的这个内容，也可以作为素材发出去，我觉得这也挺不错的。就是本身它其实都对我来说就是素材的一部分嘛。 说话人 2 嗯。 说话人 1 也许他现在可能没有那么自然，但是我在想，他会越来越自然。越来越自然。上周五其实我还说呢，完全可以让那个。我自己平时的一些语音都用来训练，那它就可以更加的口语化。然后也不至于把我的一些隐私的表达来去说出来。主要是我不太确定它这些声音，是不是够清晰，值得去训练。那这也是作为一个计划，我还没有没有搞，因为上周五的事情我还没有注意去弄。就这几天一直在搞那个。求职那套那套系统搞的有点焦头烂额，没有太好。就是弄太好，然后现在应该要去游泳了，大概出来也得5点半了，得快去了，不然走还来不及了。 文档完整详细总结 这份录音围绕Codex、Workbody两款移动端工具写稿全流程、自研本地工作看板、后续内容分享与参赛规划、个人待办计划展开，完整梳理了说话人AI辅助创作、内容发布、工具落地的整套工作流，末尾顺带提及近期忙碌事项与出行安排。 一、两款远程APP写稿体验对比，选定Workbody作为本次文章主力创作工具 1. 纠正拼写：Codex是OpenAI旗下产品；另一款国内工具为Workbody（前文Walkie Talkie）。本次完整依靠两款移动端APP完成对比评测文章撰写。 2. 写作效果差异 ◦ Codex产出文本带有明显英译中生硬语感，中文流畅度差； ◦ Workbody中文表达更自然，同类中文工具The Six效果更佳，但Workbody当前免费，出于成本考量优先使用它完成文稿完善。 3. 文末标注规划：成文后会在文章说明本文由Workbody辅助完成创作，并解释放弃Codex的原因。 二、标准化AI文章创作完整工作流程 说话人形成固定、可复用的写稿流水线，全程依托手机+本地看板完成： 1. 素材收集阶段：先用手机录音口述思路，记录遇到的工具故障、操作过程、相关思考； 2. 素材打包投喂AI：将录音转写文本、参考资料、自定义Skills、固定文风措辞要求全部整合，交给AI生成文章初稿； 3. 人工迭代优化：AI初稿很难一步达标，需要人工反复修改调整； 4. 本地工作看板精加工：生成内容同步至自建本地看板，看板内置全套图文编辑功能：标题/正文文字修改、样式模板切换、文章发布状态管理、自动配图、截图选取、图片标注、文末参考链接排版、图文微调； 5. 公众号发布一体化：看板集成双公众号发布流程，定稿后一键发布，统一管理两篇公众号稿件，流程清晰可视化。 三、看板后续迭代开发规划 1. 短期目标：开发Agent自动化版本，让整套图文创作、发布流程智能化； 2. 中期规划：接入数据看板，目前仅完成简易Demo原型；部分数据涉及敏感信息，现阶段不对外截图展示，优化满意后再分享； 3. 看板来源：完全贴合自身日常工具使用场景自主搭建；近期刚好有“看板工作台分享计划”，计划对外输出。 四、内容对外分享、参赛相关安排 1. 工作台模板分享：本次文章发布后，整理看板模板、现成存档看板素材对外提供给使用者；会先用AI提取可复用工作台模板； 2. B站AI开发活动参赛：B站活动截止日期为当月20号，可用两套素材参赛：此前分享的资金相关项目、本次移动端AI远程操控工作台完整流程；该工作流通用性强，即便依托本地APP，工作台方案也适合公开分享； 3. 时间顾虑：当日已十几号，加上求职系统调试占用大量时间，不确定能否赶在20号前完成提交；纠结两种素材产出方式：直接使用原始录音加工，或是完整走一遍整套AI自动化工作流作为参赛素材，倾向后者，可完整展示全套AI工作流作为参赛内容； 4. 语音训练备选计划：上周五产生想法，想用自己日常语音素材微调模型，让AI输出更贴合自身口语习惯，同时规避隐私表述泄露；但不确定录音清晰度是否适合训练，目前还未落地执行。 五、近期个人状态与收尾安排 1. 近期重心：一直在调试求职相关系统，耗费大量精力，语音微调计划因此搁置； 2. 即时行程：即将出门游泳，返程时间约五点半，需要立刻动身，结束本次分享。 说话人 1 去哪了？ 说话人 2 人家的那个游得很起劲。好累啊。 说话人 1 那个会有一个提示，就是于是你现在有这个然后我实际上之前其实很多时候有的。 说话人 1 这么高的频次。 说话人 1 这个 APP 的一个激励下，原本以为它可能会很复杂，但实际上它蛮简单的操作。做一个简单的同步就可以。还有几件事情。首先，游泳这个可以先用着，看看价格吧。后，我肯定还是希望把数据保留到自己身上。 说话人 1 我肯定是想自己做一份，但是也受限于经历吧，不着急现在就要去做它。那后面如果要是有时间有额度的话。 说话人 2 课因为复课不是目的。 说话人 1 对，借助这样的一个流程跑通。人家是已经有成熟的方案的话，那肯定跑通会比较简单。我觉得可能复杂点就在于算法吧。 说话人 2 吃难点应该是好像也没有什么太多难点。 说话人 1 本质上他就是在做一个动作的一个时间。他接触你的手表，然后做个实验。出水的角度，什么划水的角度，反正这些是一些专业的名词吧。你去看怎么去定义这些名词。定义这个实际动作，然后它是否准确。其实我突然想到这种，是，比如说你像游泳啊这种重复性质的动作，你就是要尽可能做到标准。是一个很简单的规范，它其实很好做的。就跟你健身一样。那包括我在想你去做拉丁舞的跳舞动作也是一样的，因为我意向肯定想做一个拉丁舞的动作。但是他的这个监测就没有手那么简单，因为手的这个的话是会有，很明显。啊，控制的一个点，甚至我在想。我可以去可以去，这因为你有一个手表，你肯定还可以监测一个手表的，然后手的一个实际的运动的路路径。但是它现在只能监测一个，要是想准确肯定两个都监测，但是这个也要平衡你的实际的体，实际的运动体验。得到的一个结果。得到一个什么样的结果，而去更复杂的带两个手表，肯定是不合适的。 说话人 1 说其实正在做拉丁的话，那这个问题就在于说你身体的那些该怎么去识别？这个其实是件挺困难的事情。衣服会不会好一点？但是衣服的话，它的一个长度可能也太多了，然后实际上会出汗。这也很好的做法。那你要是用，光是用手表来去统计拉丁动作，我觉得这个可能很难。 说话人 1 位置这件事情不是很容易的事。但是应该也会有一个最标准的点吧。就是比如说你手放到哪个位置，但是你手即便能放到那个位置，但是不代表你是，你的肩膀。还有你的这个上半身。和你的肌肉发力是不是准确，肯定还是不合适的。其实最好的方式应该是体感，就像我以前在玩那个 Xbox 一样，也有可能 Xbox 它的那个识别的会比较多。像那个什么，现在我记得有一个 Live Motion，它在手势识别的时候都可以做到很精准的手部的识别动作。那是不是肯定现在也会有有那种比较高级的识别的方式，可以实现不只是这个手指的这种识别。甚至说身体肌肉的识识别。只不过他们可能不会像是这种手表这样的操作这么容易去实现。 说话人 1 反正现在觉得他是确实是一个很好的方式。我觉得可能我想让他去帮我做的事，就比如说去录音。就比如说我，比如说我有些场合我想让他去帮我录音，那我开启之后，它自动可以把录音数据同步过来。但是可能这里也会有比较困难的地方。就比如，一是存储问题。那手表的存储空间就那么大，你肯定不能存储太多数据。那这些数据怎么去同步，怎么去清空？你如果说我们手表录制的话，肯定是尽可能。 说话人 1 如果说为了存储空间的问题，是不是就不要保留原人，音频直接转录文字存储了？然后再有就是不要让别人发现。或者是说这是否是一个很好的方式？或者是它是不是一个真的需求？其实也会觉得它的使用场景可能不一定有手表这种这么的适合。那结合这个手表的使用，我其实还挺想去用一下那个，叫什么，打羽毛球的操作。只要我换一下这个手表的使用的手，只要改到右手去使用。那样的话，我就可以去监测我右手挥拍的一个实际的情况。那这个的话看一下这周末有没有时间搞一下，然后下载一下，弄一下。 说话人 1 这个是运动表现这一块，然后实际上我游的可能比想象的还还不错，就是速度可能不太行。我这一地方我也问问豆包，看看怎么我去加强我的这个动作的规范性，然后和一个体能的练习吧。我觉得速度可能一方面是我的动作不够标准，一方面可能是我整个就是肌肉的耐力和那个运动表现确实还有待加强。当然这个肌肉的力量我觉得可能也是很重要的，因为没有力量的话你可没办法带动身体去进行运动。当然我认为手臂可能是一个很少的一部分，它只能说明这个手的角度是怎么样子的，但实际上它是一个全身的运动。而可能除了手部运动，还有一些身体的姿态的一个实际的表现，肯定也是有有所关联的，它只能作为一个监测参考。就跟我说说这个舞蹈是一样的，没办法去监测到身体的运动，他是去大致去弄一个路线来去检测这个事情。 说话人 1 那除此之外，今天刚去那个进入的时候，然后不是付了那个25块钱吗？然后准备去记录这个游泳的这个价格。然后今天发现这个记录虽然出了问题，我不太清楚是什么导致的这个问题。按理说我上一次记录，我不太记得上一次记录是什么时候了。我好像这段时间因为可能一直都没有花过钱，可能如果要是我周一出没出门？周一好像就没有出门。所以有可能上周五的时候，这个 Marni 这个就出现了问题。不知，不太清楚是不是跟我上周好像让什么东西提交导致的问题，好像把新版本提交之后，它可能自动部署了。我不太确定是由于这个原因，还是去做那个那个监控的那个修复的那个东西导致的。反正就是它现在不可用的状态。然后刚刚我在游泳之前已经让我的Codex 去进行修复了，我不太清楚它是不是能够一次性完成这个修复的这个内容。然后我也让他去尝试帮我去记录这个东西，我也不知道他会不会帮我把我之前的这个事情去记录进去。然后我发现这种场合比，还比较尴尬。 说话人 1 如果实际生产使用的时候，一是监控系统没有通知到位这件事情，我不知道监控系统到底有没有跟踪这件事情。以及，就算跟踪了，我不知道是不是最近的监控问题，跟他有没有关系。如果有关系的话，那他其实根本就看不清是这个问题，其实相当于监控的通知就完全无效了。所以这个监控一定要他一定要对接到具体的内容，而不是说只是一个略略的展示，然后它的一个影响性。我觉得可能要在监控中具体去体现。再有就是在我就吃饭。 说话人 1 啊，对，就是这种生产情况，遇到这个问题其实是一个很严重的问题。如果别人在用我这个产品，用着用着突然就挂掉了，而且他可能一共一几天想记一次的时候。那将我相当于就会永远失去这个用户了。我在想这种情况下如何保障让他离线也可以完成我们的操作，而不，而可以做离线去记录，或者说说你当前的登录态失效了。然后，但是你可以，仍然可以记，当需要同步的时候可以同步。就这个数据，我认为是必须要允许他随时随地，不管受限于网络还是什么登录，都应该支持存储。甚至是说下载导出或者怎么样呢？就是这数据不能没有。这是一件很可怕的事情。看一下这个兜底的方案怎么去做吧。我觉得这个严重影响了这个使用，实际的使用的一个感受。就不太适合一个非常成熟的产品。 说话人 2 或者还是那种问，你在网上所以我感觉我的监听系统还不是特别对呀，感觉 音频文字完整详细总结 这份音频是两人围绕智能手表运动监测产品研发、多运动场景监测难点、手表附加录音功能设想、自研记账工具线上故障、产品稳定性优化方案展开的交流，核心分为四大板块内容： 一、游泳场景实测与运动监测产品基础体验 1. 设备APP使用体验：配套APP操作简单，仅需简单同步即可使用，激励机制友好，游泳监测功能可先行试用，后续会对比定价；说话人核心诉求是运动原始数据自主留存，目前受精力限制暂不落地自建存储方案，后续有时间、资源再推进。 2. 游泳监测技术逻辑：成熟商用方案落地门槛低，核心难点在于动作算法；依靠手表传感器采集出水、划水角度等数据，关键是对各类专业动作指标做标准化定义，并保障识别精准度。 3. 个人游泳现状与提升计划：实测自身游泳耐力尚可，但速度不足，问题分为两点——划水动作不标准、全身肌肉耐力与力量薄弱；手表仅能采集手部轨迹，游泳属于全身运动，手表数据仅可作为参考；计划咨询优化动作规范、配套体能训练的方法。 4. 配套消费记录：本次游泳消费25元，本打算使用自研工具记录消费，但工具出现故障无法使用。 二、多类运动场景监测技术难点探讨（游泳、羽毛球、拉丁舞） 1. 羽毛球监测方案 操作门槛低，仅需将手表更换至持拍右手佩戴，即可采集挥拍运动数据，计划周末下载对应功能实测。 2. 拉丁舞动作监测（核心难点讨论） 1. 单手表局限：拉丁舞依靠全身肢体、肩膀、上半身协同发力，仅靠单只手表只能采集手部运动轨迹，无法识别躯干姿态、肌肉发力状态，动作识别准确度极低。 2. 多设备方案弊端：双手表分戴双手虽能提升数据完整度，但佩戴累赘，严重破坏运动体验，实用性差。 3. 替代硬件方案权衡 ◦ 传感衣物：可覆盖全身监测，但出汗、衣物尺寸适配问题明显，体验不佳； ◦ 体感识别设备（Xbox、Live Motion）：可精准捕捉手部、全身甚至肌肉动作，识别精度远超手表，但硬件复杂、便携性远不如智能手表，难以做成穿戴式轻量化产品。 4. 总结：重复标准化运动（游泳、健身）监测易实现；全身协调类舞蹈动作监测是技术难题，轻量化穿戴设备很难做到精准识别全身姿态。 三、智能手表新增录音功能的可行性思考 说话人设想给手表增加自动录音、数据同步功能，同时梳理两大核心痛点与需求争议： 1. 硬件存储瓶颈：手表存储空间有限，无法存储大量原始音频；提出优化方案：本地不保存完整音频，实时转录为文字存储，压缩占用空间。 2. 隐私与需求争议：一是隐蔽录音存在隐私合规问题；二是使用场景有限，对比运动监测刚需，录音不属于手表核心高频需求。 四、自研记账工具Marni线上故障复盘与产品稳定性优化思路 1. 故障现象 工具突发不可用，本人游泳当天无法记录25元消费；上一次正常记录时间大概率为上周五，周一未出门无消费记录，暂无法定位故障根源。 2. 故障可疑诱因 1. 新版本代码提交、自动部署上线引发异常； 2. 此前监控系统修复操作产生连锁bug。 3. 临时处理措施 已安排Codex工具执行修复，不确定能否一次性修复完成，也不确定能否补录历史消费数据。 4. 现有监控系统重大缺陷 1. 告警通知失效：故障发生后监控未及时推送提醒； 2. 监控颗粒度粗糙：仅做笼统展示，未绑定对应业务功能、标注故障影响范围，出现连锁问题时无法定位根因，监控失去作用； 3. 优化方向：监控系统需细化，精准关联对应业务模块，清晰展示故障影响范围。 5. 产品底层稳定性兜底方案（核心诉求） 本次线上故障暴露线上服务不可用时数据丢失风险，提出强制离线存储机制： 1. 断网、登录失效、服务宕机等任意线上异常场景，设备端必须支持离线本地记录消费数据； 2. 恢复网络后可一键同步离线数据至云端； 3. 支持本地数据导出备份，杜绝用户数据丢失； 4. 业务影响分析：记账工具用户使用频次低（数天才记录一次），一旦线上崩溃且无离线兜底，极易永久流失用户；当前无离线容错机制不符合成熟产品标准，后续需落地兜底方案。 补充对话收尾 说话人2补充反馈，认为当前整套监控系统设计仍存在明显缺陷，与说话人1观点达成共识。