从 Photoshop、Unity、Unreal 到编程语言，AI 可能改变的不是工具本身，而是人使用工具的方式。 / From Photoshop, Unity, and Unreal to programming languages, AI may change not the tools themselves, but how people use them.
最初写 Aether，其实是因为我戴着 AirPods Pro 在写代码时产生的一个脑洞：既然耳机里塞满了加速计和陀螺仪，既然系统已经能追踪我的空间音频，为什么不能用它们来做点更酷的事？
我想探索一种更具“未来感”的交互——离开键盘和鼠标，也能用 Mac。这不仅仅是为了炫技，更是为了在我的双手正忙（或是单纯想换个姿态）时，能用一种更自然、更“空间化”的方式与设备交流。
这是一款极客味很重的作品，也是我对“下一代交互”的一次小规模实验。
Aether 是一款挖掘 macOS 隐藏交互潜力的工具。它让你用声音完成输入和常见电脑操作，不用每一个小动作都再回到键盘和鼠标。这不只是针对 AirPods 用户的增强，更是为了实现 “离开键盘鼠标，也能用 Mac” 的完整愿景。
回消息、改名字、写笔记。最直接的效率提升：说出来，它就出现在你要的地方。建议开启“按住说话 (Push to Talk)”来获得最稳定的体验。
点击、右键、双击、撤销、滚动。把那些总把你拉回触控板的小动作交给 Aether。它让键盘鼠标变成可选，而不是必须。
利用 AirPods Pro / Max 的传感器，像移动头部一样自然地控制光标。结合姿态引导和重新校准，提供了丝滑的指向体验。
由于空间感知交互需要一定的适应期，我们建议按照以下顺序循序渐进：
/Applications，再授予权限。这样系统会记住正确路径。更多信息请访问官网：aether.7caifei.com
If you are wearing AirPods, why move your hands back and forth between the keyboard and trackpad just to switch music, flip documents, or control the cursor?
Aether is a tool that unlocks the hidden interaction potential of macOS. It allows you to use your voice for input and common Mac actions, eliminating the need to revert to the keyboard and mouse for every small task. This is more than just an enhancement for AirPods users—it’s a step toward the vision of “Using Mac without keyboard & mouse.”
Reply to messages, rename files, and take notes. The most direct efficiency boost: say it, and it appears where you need it. We recommend starting with “Push to Talk” for the most stable experience.
Clicks, right-clicks, double-clicks, undo, scroll. Offload the small actions that keep pulling you back to the trackpad. It makes the keyboard and mouse optional, not required.
Utilizing sensors in AirPods Pro / Max to control the cursor as naturally as moving your head. Combined with posture guides and re-centering, it provides a smooth pointing experience.
As spatial interaction requires an adaptation period, we suggest following this sequence:
/Applications before granting permissions. This ensures macOS binds accessibility, microphone, and speech permissions to the final path.Aether is designed to keep interaction logic as local to the Mac as possible. Your dictation text and documents are not uploaded to our servers as part of normal use.
For more information, visit the official website: aether.7caifei.com
作为一名重度 Mac 用户，我一直对“自动清理”类工具又爱又恨。大多数工具在后台杀进程时都太“暴力”了：下载到一半的应用、正在开会的 Zoom，甚至是在后台跑着 AI 任务的浏览器，常常因为几分钟没被点过就被强行收割。
我想要的是一个能感知上下文、能跟我建立信任感的助手。它应该像一个懂行的管家：当你真在忙正事时（哪怕应用在后台），它保持安静；只有当一个应用彻底变成“僵尸”状态时，它才出面收拾。
这就是 Aion (灵汐) 的由来——它不仅是清理工具，更是一场关于“自动化中‘信任感’边界”的编程实践。
信任感是自动化的基石。 Aion 的核心目标不是多关几个后台，而是让你放心地把“关闭后台”这个决定权交给它，而不用担心它会在你下载 99% 时突然断掉你的浏览器。
灵汐默认是偏保守的：会先判断应用当前在做什么，再决定是否退出。
当本地 AI / Agent 工作流正在使用某个应用时，灵汐可以把它保护起来，而不是把它当成普通后台闲置应用来清理。
这是 Aion 最近几个版本中最重要的更新。它公开了自动化的“黑盒”，你可以清晰地查看到：刚才哪个应用被尝试关闭了，以及为什么它被保留了下来。
针对计算器、词典等小工具，灵汐可以让这类短时工具用完即走，不留痕迹。
很多工具只看“闲置了多久”，灵汐在决定前还会判断“它还在做正事吗”：
更多信息请访问官网：aion.7caifei.com
On macOS, we often face a dilemma: to keep the system smooth, we want to clear redundant background processes; but to avoid interrupting the workflow, we fear that tools might “mistakenly kill” critical tasks running in the background (such as large file downloads, video rendering, or meetings).
Aion is a background automation assistant designed specifically to solve this pain point. It no longer simply relies on “idle time” to decide whether to close an app, but instead judges whether an app is “truly idle” through a deep context-aware system.
Trust is the foundation of automation. Aion’s core goal is not just to close more background apps, but to let you confidently hand over the decision of “closing background apps” to it, without worrying that it will suddenly cut off your browser while your download is at 99%.
Aion is conservative by design. It checks what the app is doing before it quits anything.
Aion can protect an app while a local AI or agent workflow is actively using it, instead of treating that app like ordinary background idle time.
This is the most important update in recent versions. It opens up the “black box” of automation, allowing you to clearly see: which app was attempted to be closed just now, and why it was retained.
For small utilities like calculators or dictionaries, Instant Task mode lets short-lived apps disappear right after use.
Most tools only look at “how long it has been idle”. Aion looks at “whether it is still doing productive work” before deciding:
A background tool itself should not become a new background burden.
We’ve optimized Aion’s resource usage to ensure it remains nearly invisible:
For more information, visit the official website: aion.7caifei.com
本文包含中文与英文两个版本。
This post includes both Chinese and English versions.
这次遇到的问题是：Antigravity 聊天框里消息可以发出去，但一直没有回复。
最开始最显眼的报错是：
1 | [Error] Server initialization failed. |
另外还有一条容易让人分心的错误：
1 | Error generating commit message: [unknown] core.repositoryformatversion does not support extension: worktreeconfig |
但排查到最后，这两类信息都不是根因。
第一条假线索是 worktreeconfig。
它确实会影响 Git 相关能力，比如自动生成 commit message，但它和聊天框“不回复”不是一条链路。
第二条假线索是 ECONNREFUSED。
继续追日志后会发现，language server 后面其实已经成功拉起：
1 | LS lspClient started successfully |
所以端口拒绝连接更像是启动阶段的一次短暂失败，而不是最后把聊天功能彻底卡死的根因。
真正关键的报错出现在 renderer 日志里：
1 | [createInstance] ... depends on UNKNOWN service agentSessions |
同时还能看到类似提示：
1 | command 'workbench.action.chat.newChat' not found |
这说明问题已经不只是 language server，而是聊天工作台本身依赖的会话服务没有被正常注册。
也就是说，输入框虽然还在，但聊天的前端主链路已经坏了。
我后面做了一个关键对比：不仅看本机 /Applications/Antigravity.app，还去下载并比对了当时官方 releases 提供的当前版本安装包。
结论是：
也正因为如此，单纯删掉再重装最新版没有意义。
排查过程中，我一度已经定位到工作台主包里可疑的注册缺失点，也做过本地补丁尝试。
但在 macOS 上很快就会撞到系统安全策略：
1 | Security policy would not allow process |
意思很直接：
所以“直接热补丁现有安装包”不是一个稳妥方案。
最后真正可用的修法不是继续硬修当前版本，而是：
关键配置在：
1 | $HOME/Library/Application Support/Antigravity/User/settings.json |
核心字段如下：
1 | { |
其中：
codeiumDev.languageServerBinaryPath：强制指向旧版 1.20.6 自带的 language server。antigravity.persistentLanguageServer: false：避免继续黏住旧的异常状态。update.mode: none：防止自动更新把运行链路再次切回坏版本。这条路更稳的原因在于：它仍然使用的是官方签名包，没有继续破坏应用完整性。
这次问题最难的地方，不是没有日志，而是日志太多，而且有不少误导项。
表面看像 language server，像 Git，像本地缓存，最后真正影响聊天恢复的，却是工作台聊天链路和版本选择。
最后真正把它拉回正常的，不是继续修当前安装，而是：
回退到官方签名的 1.20.6，切换 language server 路径，并锁住更新。
The problem looked simple at first: messages could be sent in Antigravity chat, but no reply ever came back.
The first errors that stood out were:
1 | [Error] Server initialization failed. |
There was also another distracting error:
1 | Error generating commit message: [unknown] core.repositoryformatversion does not support extension: worktreeconfig |
In the end, neither of them turned out to be the real root cause.
The worktreeconfig error was the first false lead.
It can affect Git-related features such as commit message generation, but it is not on the same path as “chat sends but never replies”.
The second false lead was ECONNREFUSED.
Once I kept reading the logs, it became clear that the language server was eventually starting successfully:
1 | LS lspClient started successfully |
So the refused localhost port looked more like a startup race or transient failure, not the final blocker.
The truly important error showed up in the renderer log:
1 | [createInstance] ... depends on UNKNOWN service agentSessions |
There was also a related message like:
1 | command 'workbench.action.chat.newChat' not found |
That changes the diagnosis completely.
At that point, the issue is no longer just the language server. It means the chat workbench itself is missing a required session service registration.
In other words, the input box may still be visible, but the front-end chat pipeline is already broken.
I compared not only the local /Applications/Antigravity.app, but also the then-current official installer downloaded from the official releases feed.
The result was:
That is why deleting and reinstalling the latest version did not meaningfully help.
At one point I had already narrowed the issue down to a suspicious missing registration in the workbench bundle and even tried building a local patch.
On macOS, that quickly runs into system policy:
1 | Security policy would not allow process |
That means:
So “hot-patching the installed app” is not a reliable long-term fix.
The working solution was not to keep patching the broken current version, but to:
The key configuration lives in:
1 | $HOME/Library/Application Support/Antigravity/User/settings.json |
The important fields were:
1 | { |
Why this is safer:
The hardest part of this issue was not the lack of logs.
It was the opposite: there were too many logs, and several of them were misleading.
At first glance it looked like a language server problem, or a Git problem, or a cache problem.
In the end, the real issue was the chat workbench path itself and the version being used.
What finally brought the app back to a usable state was:
rolling back to the officially signed 1.20.6 build, repointing the language server path, and locking updates.
从文字、视频、AR/VR 到 AI Agent，讨论互联网如何从连接走向意图，以及大厂竞争、失业分配和以人为本在 AI 时代的变化。
从文字、视频、AR/VR 到 AI Agent，讨论互联网如何从连接走向意图，以及大厂竞争、失业分配和以人为本在 AI 时代的变化。
在进行 UE 插件开发时，我们通常会为 UPROPERTY 编写注释，期望这些注释能作为 Tooltip 在编辑器中显示，并支持多语言本地化。但在实际操作中，经常会遇到翻译失效的问题。
当你完成了以下步骤：
/** My Tooltip with \n Newline */。却发现编辑器里悬停显示的依然是旧的英文，甚至当你删除了代码中的注释，编辑器里依然顽固地显示着之前的旧文本。
这种情况通常不是缓存的问题，而是掉进了 UE 本地化中最隐蔽的陷阱：UHT 元数据持久化 (Metadata Persistence)。
UE 的 Tooltip 并非在运行时直接读取代码注释，其真实流程如下：
.h 文件。它读取注释并将其转换为一个字符串常量，作为 MetaData 烧录进生成的 .gen.cpp 文件中，最终编译进二进制。FProperty::GetToolTipText) 获取这个硬编码在二进制里的 SourceString。UHT 在处理注释时非常不透明：
/** A \n B */ 解析为 "A\nB"，也可能解析为 "A B"。导致失效的典型场景：
.h 无需重新处理。与其去猜测 UHT 会如何解析注释，不如直接接管这个过程。
最佳实践：对于必须本地化的编辑器属性，不要依赖注释，直接使用显式元数据。
1 | // ❌ 依赖注释（不推荐） |
meta=(ToolTip="...") 是直接赋值。UHT 不会对其进行任何“智能化”处理，你写什么，二进制里就是什么。meta 会明确告知 UHT 文件已变更，从而确保重新编译并刷新二进制中的元数据。如果你遇到了“代码改了、翻译更新了，但编辑器死活不认”的本地化难题，请尝试以下操作：
UPROPERTY 中添加 meta=(ToolTip="你的文本")。这通常是解决 UE Tooltip 本地化顽疾最稳妥、最高效的方法。