起点很具体：把微信里说过的事，接到真正的待办里
这篇日记回看的是 2026 年 10 月 27 日到 30 日的开发记录。几天里，wxomni 从完成 DSH 迁移和 2.1.0 发布，走到多用户 3.0 预览版，再补上注册、计费、管理面板和新手教程。版本变化很快，但真正推动开发的，往往是一个具体的使用障碍。
这个项目想解决的事情并不复杂：在微信里说一句话，或者发来通知截图，让助手理解内容，整理成待办；需要安排起止时间时，再连接日历。聊天入口尽量贴近日常习惯，任务则保存在用户自己连接的账户里。
为了说明场景，可以用这样一条示例请求：“把这张群通知整理成待办，先让我看看。”它包含了内容理解、时间提取、操作预览、账户选择和最终保存。任何一环说不清楚，用户都很难判断事情到底办好了没有。
图 1：10 月 30 日 preview.19 的首页留档。随后 preview.20 又进一步把用途改成群通知转待办等具体场景，本文保留这张截图作为迭代过程的记录。
10 月 27 日：跑通之后，先处理“这是谁的账户”
最初这一阶段完成了 DSH 迁移。DSH 承担模型会话和工具调用的核心链路，微信、微软待办、日历与设置页围绕它衔接。2.1.0 又补上中文设置、预览、取消、安全撤销和按用户开启的诊断功能。
这些能力解决了“能不能办事”，紧接着出现的问题是“由谁授权、替谁办事”。项目用途已经转为让其他人首次初始化，旧使用者的微信连接、模型配置、Microsoft 和 Apple 授权就不能顺手带进新实例。历史备份需要保留，新的运行环境却必须与它们分开。
这件事很容易被“复用配置更省事”掩盖。实际上，账户归属一旦不清楚，后面的成功测试也可能建立在错误身份上。因此，新用户需要亲自扫码、登录并完成授权；保留备份，不意味着可以自动恢复到另一个人的实例。
当天另一个值得记下的细节是：公开的 2.1.0 源码包与后来补充的线上首次初始化页面，并不是同一份完整交付。页面已经在线，并不能反过来证明原 ZIP 包含它。版本、源码和部署差异，需要分别记录。
10 月 28 日：查到了，为什么还是看不全？
多用户预览版开始承接独立账户、持久队列和各自的第三方连接。随后的一次查询问题，比增加新功能更能暴露链路中的薄弱处。
表面现象是待办查询反复“截断”。直觉上可能会怀疑微信消息长度，或者模型输出额度。但记录中的定位结果是：工具一次返回了过多原始任务内容，触发 DSH 对内联工具结果的体积保护。后台把任务读完了，模型实际看到的内容却已经被省略。
更麻烦的是，当时的任务工具没有分页，模型也不能通过通用文件读取去取回剩余内容。重复查询没有改变这个条件，便可能反复遇到同一个问题。
修复最终落在数据接口上：列表先给紧凑摘要，提供清单目录和按条件分页，长正文按需分段读取。游标还要绑定用户、账户与数据版本，防止把一个人的查询入口带到另一个人的数据里。
这里留下的经验很明确：后台读取完成、模型收到完整结果、用户看到完整答复，是三个需要分别确认的状态。 一个笼统的“完成”，不足以解释整条链路。
同一天也在补使用节奏。微信里连续发出的文字、图片和说明，往往属于同一个请求；每条消息都立刻启动处理，容易把上下文切碎。项目因此加入连发合并，并让执行确认参考本人偏好和当前要求。输入状态提示则帮助用户分辨：请求正在处理，还是没有收到。
图 2：后来教程中使用的偏好演示界面。时区、提醒和确认方式，会直接影响同一句自然语言请求的执行结果。
10 月 29 日：功能开始牵动真实状态
进入管理面板和计费阶段后，开发对象变得更沉重了。用户资料、长期规则、私人文件、余额、消费流水和业务授权，都需要跨更新保留。程序能重新启动，只能证明服务活着，不能说明这些状态仍然正确。
管理能力也随之扩展到用户、配置、用量、诊断、备份与恢复。这里最需要克制的地方，是软件回退与数据恢复的关系：切回旧镜像，不应该顺手用旧数据库覆盖后来产生的注册、消息和消费。
开发记录里反复出现更新前后摘要核对，以及把加密备份下载后放进隔离环境恢复。它们看起来不像用户能直接感知的功能，却决定了一次更新出问题后，还有没有继续处理的余地。
多用户也仍然有明确边界。当前保留了提示词层面的软隔离选择，不能把它写成所有能力都已具备操作系统级强隔离。公开说明应当与实际实现一致，测试夹具通过也不能替代所有真实账户组合的验证。
图 3：账户连接演示界面。微软待办是主要任务入口，Apple 日历按需连接，普通待办不要求先具备 Apple 账户。
10 月 30 日：开放注册以后，账要能对上
公网注册与正式计费把项目又往前推了一步。记录中已经有真实结算扣费和对账，后续更新就必须承认这些消费是有效的新状态，不能为了“恢复基线”把余额统一改回原值。
计费也让原本隐藏在后台的事情需要变得可见：还剩多少余额、发生了多少消费、思考设置可能影响怎样的用量。用户能够查询，比只收到一句“已扣费”更有意义。
图 4：教程演示数据，不代表任何真实用户余额。页面中的价格与赠金文案属于当时版本，实际规则以使用时页面为准。
这一阶段还修复了联网工具选择器：运行时配置需要指向真正注册的搜索和抓取能力。它再次提醒我，某项功能以前验证过，不代表更换运行路径后仍然自然成立。关键入口发生变化，就需要沿着新的路径核验。
同一天最直接的反馈：新用户还是不知道从哪里开始
功能补了很多，首页却仍然可能没讲明白用途；教程默认用户已经有微软账户，也已经装好了 To Do。对第一次接触的人来说，这些默认前提足以让流程停下来。
于是最后一轮改进回到了非常基础的地方：用群通知、报销材料、截止时间和提前提醒解释产品；补上从零注册微软账户、下载或打开 To Do、登录同一账户、允许通知、创建第一条提醒，以及检查同步和完成状态。
图 5：本地演示注册界面，没有真实账户、密码或二维码。对新用户而言，清楚的第一步同样是产品能力的一部分。
教程最终扩展到 16 章、20 张配图，并与微信内的求助入口共用内容。用户问“这一步怎么做”，应该得到具体的下一步；需要本人登录或扫码的环节，也必须说清楚由本人完成。
这轮修改让我更在意“成功判断”。告诉用户点哪里只是半步，还要说明：完成后应该看见什么，没有出现时检查哪里。写出这种教程，也是在倒过来检查流程是否足够清楚。
留在这次记录里的完成与未完成
截至 10 月 30 日的本地交付记录，最新版本是 3.0.0-preview.20。该轮 Windows 与隔离 Linux 的核心回归各通过 236 项，日历与提醒相关检查分别通过 63、53 项；公网文件与候选源码哈希核对、更新前后数据摘要核对，以及前后备份下载后的隔离恢复也有通过记录。
这些结果有各自的范围。最后这轮没有主动发送测试微信、调用真实付费模型或写入真实云端任务，不能把它们描述成新完成了一遍真实手机全流程验收。本文依据留档回顾开发，也没有为写作重新连接或核查生产服务器。
回看几天的变化，我最想记住的已经不只是版本号。查询失败时，能否解释卡在哪一层；更新完成后，用户的数据和消费能否保留；第一次打开页面的人，能否独立走到第一条提醒。wxomni 接下来是否好用，仍然需要从这些具体问题里得到答案。
记录与配图说明
本文根据项目内 2026 年 10 月 27 日至 30 日的开发接续、查询截断诊断、发布交付及恢复记录整理。文中的请求例句用于解释场景，并非私人聊天摘录。图 1 来自 preview.19 首页留档；图 2 至图 5 来自 preview.20 随附教程素材，为本地演示账户的真实组件渲染，保留了原有步骤标注。全部图片取自本项目，没有使用真实用户任务、生产账户信息或授权凭据。
聊聊这篇内容