说话人 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. 关于Workbody与Codex使用体验及文章撰写讨论（新录音 55.m4a）