Codex 写完一轮代码，手机上能收到提醒——这是这个产品第一条跑通的链路。后来它长出了本地语音、独立对话、加密记录，以及一个全屏动的星核界面。下面是从最初的想法到 2026 年 11 月 1 日的完整记录。
我想做一个自己的“贾维斯”。
坐在电脑前，叫一声它的名字，就能直接对话；聊清楚开发问题后，让它把要求交给正在使用的 Codex 聊天；离开电脑后，微信能收到本轮工作的结果，还能继续回复下一步要求。以后，再把 iPhone 和家里的小爱音箱接进来。
这个想法最后有了一个名字：星核助理，STARCORE。
它的起点其实很小：Codex 写完这一轮代码，我能不能在手机上收到提醒？围绕这个需求，产品逐渐增加了原聊天续写、本地语音识别、独立对话、加密记录和全屏动态界面。中间也走了不少弯路，尤其是微信连接和“让设计图真正动起来”这两部分。
这篇文章把最初的想法、需求变化、实施过程和当前进度串起来。现在能用的部分已经落在 Mac 上，iPhone 独立客户端和小爱音箱仍是后续计划。
一 最初的想法是把电脑和音箱连起来
这段开发最早还夹在另一个需求里：研究 Quiet TV，考虑给家里的雷鸟电视换一个更简洁的桌面。电视方案还没继续推进，我又想到家里现成的小米音箱 Play。
电视桌面当时考虑过时间日期、信号源、常用应用、全部应用列表、遥控焦点和壁纸等功能，也要求先只读检查设备、保留原桌面和恢复方式。后来这条线暂停，没有在这个过程中对电视实施安装或系统应用禁用。
新的设想是，让电脑上的一个程序连接音箱，能读取音箱说出的内容，也能观察电脑上程序的工作状态。电脑里的事情做完了，就让音箱开口提醒；手机上也有一个入口，能实时看到这些消息。
最早的目标包含三个方向：
- 电脑上的工作完成后，主动通知我。
- 手机上的微信能接收和查询这些通知。
- 将来通过微信控制音箱，让它执行一些事情。
“监听电脑的一切程序”这个说法很宽，真正做起来，需要先确定能稳定观察什么。我们先把对象缩小到了开发工作：观察 Codex 一轮工作是否结束，把最终回复摘要发到微信。
这个阶段没有接入电视，也没有开始读取小爱音箱里的对话。先把最常用的一条链路跑通，产品才有继续扩展的基础。
二 第一阶段是 Codex 完成后发微信提醒
手机端先使用微信里的 ClawBot 入口，不急着做一个独立 App。电脑上负责收集 Codex 的完成事件，微信负责把结果送到我手里。
最初的使用方式很直接：绑定微信，发送“开启提醒”，然后等待 Codex 完成一轮工作。
二维码反复过期
第一个问题就出在绑定上。我连续扫码，看到的却总是过期提示。
这里有一个容易忽略的区别：聊天里的一张二维码图片是固定快照，而登录服务中的二维码可能已经刷新。继续扫旧图片，重试多少次也不能代表扫到了当前有效的登录码。
后来把正式登录入口改成了本机实时页面：页面持续检查二维码状态、刷新当前登录码，并避免图片缓存。连接结束或服务失效时，旧码也不再继续展示。
这一步解决的是“看到当前有效登录码”的问题。扫码成功之后，通知通道是否真的能发送，仍然需要单独验证。
绑定成功和消息送达是两件事
绑定之后，我曾同时收到“Codex 微信提醒已连接”和“微信未确认接收消息”的提示。
这个现象说明，产品需要把状态拆得更清楚：账号完成绑定、建立可主动发送的微信会话、接口确认发送成功，以及手机实际看到消息，分别是不同的环节。
因此，界面后来保留了待发送、发送结果未确认等状态。微信里可以发送“开启提醒”“暂停”“状态”“最新”等文字，激活会话或查询结果。
遇到发送结果未知，程序不会反复重发。因为没有收到确认，既可能是没有发出去，也可能是已经送出、回执丢了。盲目重试会把不确定性变成刷屏。
先发模拟提醒 再验证真实任务
为了区分“微信能不能发”和“Codex 有没有触发通知”，最开始先发送了一条明确标注为模拟的连接测试。
手机收到它，只能证明通知通道可以发送。随后又进行了真实 Codex 任务测试，才逐步验证事件是否进入了通知队列。
测试期间，我也反馈过“怎么又来了两条”。当时有多次测试任务，不能只看两条相似文案就认定同一事件重复发送。后来对通知身份使用聊天和回合标识去重，让同一轮结果通过不同入口到达时，仍然只进入同一套队列。
提醒文案也刻意没有写成“项目已完成”，而是：
Codex 本轮已结束，待查看。
下面会带项目名、时间和最终回复摘要，并保留一句说明：回合结束不代表代码或测试已通过，需要看摘要和实际验收。
这件小事影响了产品的语气。一个开发助理应该把状态说准确，让我知道什么时候需要查看，而不是替我宣布所有事情都成功了。
三 命令行测试通过后 桌面任务仍然漏提醒
微信通道能发、命令行测试也有结果，我就让另一个正在运行的开发任务继续，想看它结束后会不会提醒。
结果是：任务结束了，手机没有消息。
继续排查后发现，微信服务本身正常，问题出在完成事件的入口。原先接入的是 Codex 的完成通知配置，但已经打开的桌面聊天没有触发新加的入口。
这也回答了当时反复出现的问题：是不是必须重启 Codex？
只依赖新通知配置，已有进程是否加载它确实会影响结果。最后采用的补充方案，是单独增加一个桌面完成记录监听器，读取本机 Codex 的聊天索引和新增完成记录，把桌面任务也送进原有通知队列。
实现时保留了几个约束：
- 只读 Codex 的本地状态和新增记录，不修改原聊天内容。
- 首次启动以已有文件末尾为基线，不把历史任务集中补发到微信。
- 保存读取游标，服务重启后继续读取。
- 一条记录尚未写完整时，等下一次读取再处理。
- 过滤子任务的完成记录，避免主任务之外的额外提醒。
- 与原通知入口共用去重机制。
补上这个入口后，我确实收到了桌面聊天结束的提醒。这时才算解决了真实使用里的漏通知问题。
这套监听适配依赖当时安装版本的 Codex 本地记录格式。它服务于这台机器上的实际需求，后续 Codex 升级时仍需要检查兼容性。
四 从脚本变成打开就能用的 Mac 客户端
通知稳定下来之后，下一个想法很自然：能不能做成客户端，每次打开就自动监听？
于是，原来的脚本增加了 Mac 原生外壳。打开客户端后，可以查看 Codex 监听和微信服务状态、待发队列，进行绑定或重新绑定，也可以启动和停止监听。
客户端会检查已有服务，避免重复启动。关闭窗口和退出客户端也需要有明确含义：既有微信提醒可以继续在后台运行；如果要停止提醒，则通过“停止监听”处理。
这时候的产品仍主要是一个开发通知工具。它还没有麦克风、唤醒词和独立语音对话，但已经有了可持续使用的桌面入口。
后来增加语音能力时，又补充了另一条规则：退出客户端会停止语音，微信后台提醒继续遵循原有运行方式。两种能力的生命周期需要分清楚。
五 手机收到结果以后 我还想直接继续开发
只收到通知，能让我少盯一会儿电脑，但下一步还是得回到电脑前输入要求。
我真正想要的是：手机看到结果后，直接在微信里回复下一步，它就回到当前项目继续做。
这里我们先确定了默认目标：手机消息发给最近一条已送达提醒对应的 Codex 聊天。 这样不用每次输入项目名，但也意味着目标会随新的提醒变化，因此必须提供“当前项目”查询和投递回执。
真正难的是“继续原聊天”。桌面版占用了原聊天的写入通道，另开命令行进程并不能简单地接管它。
中间讨论过创建一个“手机专用 Codex 聊天”，我没有接受。我的要求很明确：
必须继续原来的桌面聊天，先不要创建新聊天。
最后复用了当时本机 Codex 提供的原聊天消息队列接口，将外部文字要求交给原桌面进程处理。没有新建聊天，也没有复制一份项目上下文去另开任务。
在本机验证中，原聊天确实因为队列消息开启了新一轮，并按测试要求回复了指定文字。这个结果证明了原聊天续写入口可用；微信手机输入、投递、执行、再收到完成通知的完整体验，还需要在实际使用中继续确认。
投递逻辑也增加了几项保护：只接受绑定账号主人的入站文字；收到要求时先固定目标，避免等待期间被新提醒改到另一个项目；先记录投递状态，再发送；重复的微信入站消息不重复执行；结果未知时不自动重投。原聊天的模型、权限和审批设置继续生效。
这一步让产品从“告诉我做完了”走向了“我能在手机上接着安排下一步”。
六 产品方向开始变成自己的贾维斯
有了提醒和原聊天续写，我开始觉得，单纯的通知窗口还不够。
我想要一个可以坐在电脑前直接交谈的个人助理。它有一个名字，有回应，有自己的全屏界面；我说清楚要做什么，它能理解，再把开发要求交给 Codex。
当时我用“钢铁侠里的贾维斯”来描述这种感觉。这里包含两种需求：一部分是使用方式，另一部分是视觉体验。
使用方式上，我希望通过说话完成讨论和任务交接；视觉上，希望它有明显的科技感，处于待机、聆听、思考和播报状态时能给出不同反馈。
我们随后把第一阶段的范围定为 Mac：先坐在电脑前把语音对话做出来，后面再接小爱音箱。手机设备是 iPhone 13 Pro，但独立手机端不和 Mac 首版一起展开。
“贾维斯”只是默认称呼。产品需要允许修改助理名字，也允许单独修改唤醒词。这样以后可以叫它“星期五”，或者使用其他自己习惯的名字。
至于“我命令它干什么，它就干什么”，当前落地的范围仍然是对话和明确授权后的开发任务交接。任意控制所有电脑程序、家居设备，并不属于这一版已经完成的能力。
七 语音识别留在本地 不同模型分别负责不同工作
语音方案讨论时，我提供了 SpeakMore 的参考，以及自己已经使用过的 Fish Audio。SpeakMore 的界面里有本地 Qwen3 识别和文字润色，这种分工很符合我的需求。
首版 Mac 助理接入了本地语音识别、云端对话和语音播放。后来考虑到 DeepSeek 余额不多，我又明确调整了方案：本地识别，必要时才使用 DeepSeek 润色，聊天改走已经在用的云桥中转服务。
最终形成的链路是：
Mac 麦克风
→ 本地 Qwen3 ASR 识别
→ 检查唤醒词或连续对话状态
→ 可选的 DeepSeek 口述校对
→ 云桥聊天
→ 屏幕显示回复
→ Fish Audio 或 Mac 系统声音播报开发任务走另一条明确入口：
点击交给 Codex 或说让 Codex 加具体要求
→ 取得当前选定的原聊天
→ 附带近期相关讨论
→ 投递到原聊天队列
→ Codex 在原聊天继续
→ 本轮结束后通过微信提醒本地识别和唤醒
当前使用 Qwen3 ASR 0.6B 的 GGUF 模型，复用本机已有模型文件，识别运行在本机。实现并没有读取 SpeakMore 的密钥。
唤醒词会在识别文本开头匹配，避免对话中随口提到名字就被当成命令。唤醒后，可以在 45 秒的连续对话窗口里继续说话；说“结束对话”则回到待唤醒状态。
这个版本通过语音识别检查唤醒词，还不是专用低功耗唤醒引擎，因此会有语音分句和识别开销。
DeepSeek 只做可选润色
日常聊天不再交给 DeepSeek。润色默认关闭，开启后也只校对口述中的明显错字、标点和重复，不应该扩写意思或生成新的开发授权。
聊天失败时，不自动切到另一个付费模型继续请求。明确的开发指令也按原文判断，不能因为润色结果变了，就执行用户没说过的事情。
聊天和声音分开配置
云桥负责聊天，具体使用哪一个模型取决于客户端保存的模型设置和密钥分组。它不等于助理共享了这个 Codex 窗口的模型或内部记忆。
Fish Audio 负责把回复文字转换成声音，也可以选择 Mac 系统声音。之前使用过免费的服务，不意味着以后所有模型、音色和接口调用都免费，实际仍取决于所配置服务的规则与额度。
为了避免扬声器播报再次触发识别，当前播放时暂停拾音。可以点击“打断”或使用快捷键停止回复和播放，播放中的自由插话与完整回声消除还没有实现。
八 让它记得讨论内容 同时解决反复输密码
助理能对话以后，另一个问题就出现了：聊过的话要记录下来，后面继续讨论时不能每次从头解释。
我的要求里也有一段容易误解的表达：一方面不希望信息随意留在本机，另一方面又觉得每次进入都要输入好几次密码太麻烦，最后明确选择了本地加密保存。
这次调整的重点是：聊天、密钥和配置保存在本机，但不直接以明文落盘；正常再次打开时自动恢复。
实现使用 AES-256-GCM 加密密钥、设置和聊天正文。聊天保存在本地数据库中，历史界面支持分页和检索。已有旧数据在验证后迁移，不继续写入旧的明文设置和聊天文件。
最初使用 macOS 钥匙串存储服务密钥，开发中的反复打开和授权影响了使用体验。后来改为在当前 Mac 账户的私有目录保存加密文件和本地随机主密钥，正常打开不再逐项访问钥匙串。
这个选择也有清楚的边界：自动解密需要机器上有解密密钥，因此可以避免直接打开数据文件看到正文，却不能阻止已经控制当前 Mac 账户的程序读取它。备份时，加密数据和主密钥必须一起保留。
完整保存和每次发送全部历史是两件事
本地完整记录，是为了查阅和继续讨论；每次聊天并不会把全部历史都发给云端。
当前实现对聊天上下文设置了上限：最多 16 条、合计约 12000 字符的近期内容，单次输出上限为 800 tokens。交给 Codex 时，附带最多 12 条、约 10000 字符的近期讨论。
这样可以保留连续性，也控制单次请求体积。超过范围的旧内容，模型并不一定知道，不能假装自己记得。
更重要的是，星核助理和原 Codex 聊天没有自动共享的完整记忆。任务交接需要显式附带背景，并把本次要求和背景讨论分开。
九 设计图确定之后 真正困难的是做出同样的感觉
功能推进的同时，我对界面的要求也越来越明确：全屏、深色、蓝色能量核心、机械轨道、底盘、远处的星球和星辰，下面是对话字幕与语音控制条。
界面不能一直像一个聊天框。没有说话时，也应该显示当前状态、项目和最近对话，让这个助理有自己的存在感。
我们用 imagegen 生成概念图，讨论过一个更简洁的核心方向。但看过之后，我最后还是选回了细节更丰富、科技感更强的那一张。
这个选择确定了后面的视觉基准：中心球体的通透层次、倾斜轨道、蓝色与少量暖色高光、空间纵深，以及下方字幕和控制条的位置，都要尽量往原图靠。
第一轮看起来像一张图在呼吸
早期实现把场景图放进页面，再叠加亮度、呼吸和局部动画。静态画面有感觉，但一动起来，我看到的主要还是整体一大一小。
我反复提出过几句话：
页面还是有些不一样。
页面里的动态效果实现不出来吗？现在看还是一个图片放大。
这些反馈指向的是同一个问题：画面应该有内部结构在运动。球壳、轨道、底盘和星辰，不能都依靠同一个整体缩放来表现活力。
十 动效实现经历了几次方向调整
从背景动画走向实时三维
接下来引入 Three.js 和 WebGL，使用真实球面、轨道几何、刻度、光丝和粒子，让不同结构沿不同方向运动。
这一阶段也做过相机推进和退回。透视变化可以带来前后层次，但它仍然不能代替主体自身的动态。我又要求调整中心区域，让底盘和旁边的星辰也动起来。
于是，环境逐渐分离成可独立更新的部分：反向旋转的机械环、底盘弧段与扫光、缓慢自转或漂移的星球，以及不同深度的星点。
这些版本改善了运动，却出现了另一个问题：程序化做出来的三维球体，与生成图里的材质和摄影式光感差距还是很大。
完整几何样片能证明运动 但没有达到选定的外观
为了解决“是不是只在缩放”的争议，中间专门做过固定镜头的独立样片。
样片保持相机、视角和模型整体比例不变，让厚金属环、面板、光丝和粒子自行运动；提供暂停、分层和线框模式，能直接查看真实网格。
后来又尝试增加机械层次、调整轨道轮廓、加入体积光和底盘反射，继续向设计图靠近。
这些实验说明，真实动态是可以实现的。问题在于，单张生成图包含很多细密的机械结构、透明层和光照关系，仅靠几轮程序化建模，并没有复原出同样的外观。
所以后面没有继续把“更多几何”当成唯一方向。
最终采用指定视角的分层投影
最后选择保留原图的材质细节，再把它拆成分别运动的曲面网格。
正式界面采用固定正交相机和恒定整体比例，五层曲面球壳、核心、四层倾斜底盘以及四个星球分别更新。外部轨道光点、星辰也有各自的运动。
字幕、时间、状态、按钮、项目和历史入口由真实界面代码绘制，和场景美术分开。
这个方案更适合当前全屏助理：主要从一个指定视角观看，优先保持我已经选定的外观，同时让内部结构动起来。
它仍然有真实网格和分层运动，但本质上是基于单视图的投影场景。它没有凭空获得设计图背后的完整模型，不能任意绕到背面看，也不能宣称已经逐像素复原了所有字体和细节。
如何确认不是又在放大图片
后来的验收不只看一张截图，而是检查相机和整体比例是否恒定、各层角度是否随时间变化、暂停后是否冻结，以及线框模式是否仍能正常更新。
减少动态时，各层运动一起停止；页面隐藏时暂停绘制。真实输入和播报电平只小幅影响核心亮度，不再驱动整个画面缩放。
视觉测试使用明确的模拟音量和实际 WebGL 录像，不为调整动画额外调用聊天或 Fish 接口，也不把模拟聆听画面当成真实麦克风验收。
十一 浏览器里正常 原生客户端里还要再过一关
场景在浏览器预览中能运行，并不代表放进 Mac 客户端就完全一样。
正式页面运行在 WKWebView 中。本地文件来源对 WebGL 图片纹理的加载会有限制，曾导致客户端进入静态备用画面。这样即使预览页里能动，用户打开 App 仍可能只看到一张图。
后来把场景 PNG 内嵌进脚本，减少对本地纹理加载方式的依赖，并在设置里显示动态效果正在运行、暂停或回退的实际状态。
这一轮还把已验证的投影场景模块接回正式渲染器，继续使用原生语音、真实聊天、项目选择和加密记录。独立样片通过之后，仍然需要在原生客户端里确认它没有静态回退。
十二 左下角项目选择器也影响实际使用
大场景逐渐稳定以后，小控件的问题就明显了。
左下角原先把当前项目、聊天标题、长地址和刷新入口挤在一起。我提供截图，要求再处理一下左下角和下拉样式。
修改后，项目名和聊天标题分层显示；“固定聊天”与“自动跟随”单独标记；长内容省略，悬停可以查看完整提示。下拉改成深色面板，向上展开，刷新入口放到面板内部。
同时补齐了方向键、Home、End、Enter、空格、Esc、Tab、外部点击和长列表滚动。Esc 关闭选择器后恢复焦点，不应该误触助理的取消操作。
这些细节决定了多项目之间能不能放心切换。选择器不仅要好看，还要让人知道下一条开发要求会交给哪里。
十三 中间球体偶尔出现黑线
后来我注意到，中心星球运动时偶尔出现黑线，也希望再增加一些效果。
排查后发现，核心曲面会轻微倾斜，相邻球壳却主要在平面内旋转。它们原本共用的分割边界，在运动后不再完全对齐，于是露出了后面的暗色环境。
修复方式是在分层边界后方补上一张连续的原图投影曲面，略微后移，覆盖运动时露出的缝隙。这样保留原有倾斜，也避免用强光晕把问题遮过去。
随后增加了 160 个局部流光粒子和两条反向短光轨。它们使用同一动画时钟，暂停和减少动态时一起冻结，不改变主体的整体轮廓与比例。
这里也保留了一个区分：设计图里的暗色机械结构可以存在，需要修的是随运动出现的露底黑缝。
十四 应用命名和图标逐渐统一
最开始它叫“Codex 微信提醒”，名字准确，但随着语音、对话和后续设备控制的方向出现，已经不能覆盖整个产品。
图标也经历了多轮调整。我特别提出过，之后还想通过微信控制音箱，图标和产品方向不能只体现一个开发通知工具。
最后应用正式命名为“星核助理”，英文使用 STARCORE。产品名和助理个性称呼分开：应用叫星核助理，里面仍然可以叫贾维斯，也可以修改名字与唤醒词。
应用包、窗口标题、菜单和页面副品牌同步更新；原来的内部标识和数据目录继续保留，避免改名后变成一份全新安装，丢失原有配置。
图标白边是资源适配问题
新图标装上以后，系统里仍出现了浅色边框。
检查后发现，旧素材没有直接画一圈白边，但带有透明留边和预制圆角。系统渲染时叠加出的浅色底板，让它看起来像又套了一层框。
后来的处理是生成满版不透明深蓝素材，去掉预制容器边界和透明边距，再通过原生资源目录编译，让系统统一处理图标遮罩。
在 Finder 的系统预览里做前后对照后，白边问题得到修正。这个过程也说明，生成一张看起来像 App 图标的图片，与把它正确装进 macOS 应用，是两项工作。
十五 最近修复的是当前项目没有进入聊天上下文
最新一次问题很有代表性：我已经在客户端左下角选好了项目，问“当前项目”时，它却回答：
我这边看不到 Codex 界面的选中状态；把项目名或路径发我就行。
界面明明有状态，模型却不知道。
排查发现，项目选择已经保存，真正向 Codex 投递任务时也会读取这个目标，但普通聊天请求只带了近期对话，没有带项目选择器的状态。
所以这次修改分了两层。
第一层，直接问“当前项目”“当前项目路径”这类简单问题时，本地读取当前选择并回答，不需要调用聊天模型，也不需要先做口述润色。是否进行语音合成，仍按原来的播报设置处理。
第二层，进行普通讨论时，每轮请求都附带当前项目的简要元数据，包括项目名、聊天标题和选择方式。固定聊天优先，只有自动跟随模式才使用最近一条已送达提醒对应的聊天。
目标不可用时会明确提示，不悄悄换到其他项目。请求开始时取得一次状态快照，避免等待润色或回复期间目标发生变化。
本地完整路径不会作为这份项目元数据默认发给聊天服务。知道项目名和聊天标题，也不等于已经读取仓库文件或原 Codex 聊天全文。
这轮使用真实已选项目验证了读取结果，并补充了固定目标、自动跟随、无目标、目标不可用、语音提问、元数据更新和只读数据库查询等回归检查。最近一次完整测试是 57 项通过。随后更新实际运行副本，重新打开助理，原固定选择也恢复了。
这件事给我的一个具体提醒是：界面上显示的信息，必须真正接进模型请求和执行流程，否则用户看到的“当前状态”和助理理解的状态会是两回事。
十六 当前产品由哪些模块组成
目前整体可以分成五层：
| 模块 | 主要职责 |
|---|---|
| Mac 原生宿主 | 窗口、麦克风权限、音频采集、播放、设置和本地加密桥接 |
| 全屏界面与场景 | 字幕、控制条、项目选择、历史入口、Three.js 动态场景 |
| 本机助理服务 | 本地 ASR、唤醒会话、聊天、润色、播报、取消和上下文组织 |
| Codex 交接与监听 | 原聊天投递、状态记录、完成事件收集和去重 |
| 微信通道 | 绑定、会话激活、提醒发送、查询和手机续写入口 |
Swift 原生宿主通过结构化消息与 Node 子进程通信。视觉场景负责展示，实际任务由明确的投递入口处理。这样后面增加 iPhone 或音箱时，可以复用对话、任务和通知能力，而不必把所有逻辑重新写进每一个界面。
当前版本不会因为普通聊天里讨论了一个想法，就直接把它当成开发指令。要开始开发，仍然需要点击“交给 Codex”，或者说“让 Codex”加具体要求。
十七 主要实施节点
| 阶段 | 当时的问题或决定 | 形成的结果 |
|---|---|---|
| 初始构想 | 电脑工作结束后，音箱和手机都能提醒 | 先收敛到 Codex 结束后的微信通知 |
| 微信接入 | 二维码重复过期，绑定与发送状态混淆 | 实时登录页面、会话激活和发送状态区分 |
| 完成监听 | 命令行测试有提醒，已有桌面聊天没有 | 补充只读桌面完成记录监听，与原入口去重 |
| 桌面客户端 | 不想每次手动运行脚本 | 增加窗口、状态、绑定和监听控制 |
| 手机续写 | 收到通知以后还要回电脑操作 | 适配原聊天队列，验证原会话续写入口 |
| Mac 语音首版 0.3.0 | 希望叫醒后直接对话 | 麦克风、本地识别、可改唤醒词、TTS 和开发交接 |
| 对话与存储 0.4.1 | 控制模型费用，保存上下文，减少重复授权 | 云桥聊天、默认关闭的 DeepSeek 润色、本地加密与完整历史 |
| 三维迭代 0.5.0 和 0.5.1 | 动态主要像背景缩放 | 实时球面、轨道、底盘、星球和星点 |
| 原图方向 0.6.0 | 三维结构与选定设计图仍有明显差距 | 转向原图保真与投影动态，并继续做独立样片 |
| 正式场景 0.6.1 | 样片需接回客户端，原生纹理加载有差异 | 固定镜头分层投影、内嵌纹理和运行状态提示 |
| 项目选择器 0.6.2 | 左下角拥挤，下拉样式不协调 | 分层信息、深色面板和键盘操作 |
| 核心效果 0.6.3 | 球体运动时出现黑缝 | 连续曲面补缝、局部粒子与短光轨 |
| 应用命名 0.6.5 | 微信提醒的名称覆盖不了后续方向 | 统一为星核助理，保留可改助理称呼 |
| 图标适配 0.6.6 | 系统渲染出现浅色外边 | 满版图标素材与原生资源目录 |
| 当前项目修复 | 选择器状态没有进入普通聊天 | 本地查询与逐轮项目上下文，完整检查 57 项通过 |
最近一次项目上下文修复更新的是 Node 运行文件，没有为此另建一个新的原生应用版本号。
十八 已经做到哪里 还有哪些没有完成
到目前为止，已经形成的核心能力包括：微信完成提醒及状态查询、Mac 客户端管理、本地语音识别、可改名字与唤醒词、连续对话、云桥聊天、可选润色、Fish 或系统声音、本地加密历史，以及向选定原 Codex 聊天交接要求。
微信提醒已经有用户实际收取记录，原聊天队列续写也有本机执行验证。后续每一轮界面修改，并没有反复调用付费服务重跑整条链路，因此视觉验收、接口检查和完整日常体验需要分别看待。
原生客户端在这台 Apple Silicon Mac 上完成过构建、安装和本地签名验证。当前仍依赖这台机器的 Node、模型和运行目录，还不是面向所有用户的一键分发安装包。
后续没有完成的部分主要是：
- iPhone 独立客户端。 现在手机侧使用的是微信入口，不是已经发布的 iOS App。
- 小爱音箱接入。 读取音箱对话、语音播报、通过微信控制音箱，仍需要后续单独实现和验证。
- 任意电脑应用控制。 当前围绕 Codex 工作流，没有实现对所有程序的通用监听与操作。
- 播放中的语音抢话。 当前通过暂停拾音避免反馈，还没有完整回声消除方案。
- 专用低功耗唤醒、跨设备同步和正式发行。 包括设备身份、任务路由、冲突处理及发行签名公证，都还有工作要做。
Mac 睡眠、断网或微信会话过期时，也不能保证实时送达。跨设备助理要长期可用，这些运行条件都需要纳入后续产品设计。
十九 后面想怎么继续
接下来的重点，是先把 Mac 上每天都会用到的体验做扎实：语音分句是否自然、对话是否接得住、目标是否清楚、任务状态是否可信、打断后会不会继续播旧回复，以及重新打开后能否稳定恢复。
之后再做 iPhone 端，让它能查看同一个助理的讨论和任务状态，也能发送下一步要求。接入时需要明确是在继续哪个项目、哪个聊天，而不是只把手机做成一个无目标的输入框。
小爱音箱再作为新的输入输出设备接进来。最初设想的微信控制音箱、音箱播报和家庭场景联动，都应建立在实际可用的设备接口上，不能把 Mac 已经能播报，直接当成音箱已经接通。
中间我还提到过 nanobot，想看看有没有值得借鉴的地方。它属于讨论中的参考方向；当前星核助理并没有因此变成一个基于 nanobot 重做的项目。后续可以继续围绕工具接入、消息通道和任务组织研究，但是否采用，需要结合现有代码判断。
二十 这次开发留下的几个具体经验
最先解决一个经常发生的问题，产品才能开始被使用。对我来说，那个问题就是 Codex 本轮结束后，手机能及时告诉我结果。语音、界面和设备扩展，都是在这条链路上长出来的。
通知系统要区分绑定、会话、发送确认和用户看到消息。开发系统也要区分回合结束、任务完成和验收通过。这些状态一旦混在一起，界面再漂亮也会让人误判。
原聊天续写比新建一个聊天更符合我的使用方式，但它需要处理目标、队列、重复消息和结果未知。真正影响可靠性的，往往是这些看不见的部分。
视觉实现也需要诚实。图片呼吸、相机推进、模型自转和分层投影各有用途，不能因为画面有变化，就认为已经满足“原设计图里的结构在运动”。最后采用指定视角的投影方案，是为了同时保留选定的外观和可观察的内部动态。
上下文则需要主动连接。项目选择、近期讨论和本次指令，只有被正确传递，助理才知道我在说什么。“当前项目”这次修复，就是最直接的例子。
现在，我已经可以在 Mac 上打开星核助理，叫它的名字，讨论开发问题，再把明确要求交给原 Codex 聊天。下一步，是把这条工作流用得更稳，再让手机和音箱接进来。
附录 对话中参考过的项目与服务
下面保留这次讨论中出现过的公开链接，便于继续了解相关背景。它们分别参与了最初调研、方案讨论或实际接入，不代表每个项目都被集成到了星核助理中。
- Quiet TV：最早电视桌面需求的研究对象，后来暂停。
- SpeakMore：本地语音识别与文字处理方案的参考。
- Fish Audio：声音与语音合成服务，Mac 助理已提供对应配置和接入。
- 云桥指南：当前助理聊天网关配置的参考。
- nanobot：中途提出过的助理架构参考，尚未作为当前项目的重构基础。
- weixin-agent-sdk：当前微信通道使用的第三方桥接依赖。