写到这里，砚还要继续照着 IDE 加功能吗

Git、分栏、终端标签一轮轮补下来，功能列表长了不少。接着往下列，当然还能列出很多：语言服务、更多面板、更多快捷操作。

但我开始觉得，得停下来想想先做哪一个。

这篇沿着 10 月 15 日的方向笔记往下写。里面有几个想试的方向，也有当时顺着代码发现的问题，还没有定成新的开发计划。

先读任务文档，在终端运行编码工具，看它改了哪些文件，自己检查、修几处，再跑检查、暂存和提交。

砚已经有文档、文件、终端和 Git 总览，离这段工作并不远。

如果继续围绕它做，命令行工具可以保留自己的配置和认证，砚把本地阅读、修改和审查做好。暂时不必为了接上这段流程，就再造一个聊天面板或模型配置系统。

这是我想试的方向。至于别人会不会也这么用，还得拿真实任务试，光看功能能拼起来不够。

在另一个程序里改完文件，再切回砚，窗口重新获得焦点，可以触发一次磁盘检查。

但工具就在砚的内嵌终端里跑，人一直待在这个窗口，可能根本没有"切回来"这一步。

翻当时的代码，checkDisk 会刷新文件树、处理打开文档的外部修改，但不会顺便重建快速打开的索引。终端前端从 shell 返回时有重建索引的路径，窗口里的内嵌终端却不经过那次暂停和恢复。

这就留下一个待验证的场景：新文件已经出现在树里，快速打开却还搜不到。下一步需要把这条路径实际跑一遍，再决定刷新该放在哪里。

还有一种更难察觉的情况：

text 复制代码

第一次写入：状态 M，内容 A
第二次写入：状态 M，内容 B

只比较 Git 状态条目，两次结果可能一样。如果文件没在编辑器里打开，总览页又拿不到缓冲区变化的通知，就有继续显示旧内容的风险。

这是沿着当时的状态比较和刷新代码推出来的，还没有在真实窗口里复现确认。我先把它留成一个具体用例，比笼统写一句"加强同步"更方便继续查。

之前补过 HEAD 移动后的标记刷新，但 HEAD 变化和工作区文件被重写，是两条不同的消息。前者接上了，不能顺带认为后者也接上了。

砚已经会检查外部修改，避免保存时直接覆盖别人的内容。可审查的时候，我还需要知道眼前这份 diff 是新的。

即使没有点保存，后面也可能暂存或还原。如果看的是旧内容，操作基于什么就成了问题。

所以在那份笔记里，外部变化刷新排得比较靠前：文件清单、打开的文档和 Git 视图要一起考虑，异步返回的旧结果也要能识别。监听事件、合并通知、有限补扫都可以研究，还没到选定实现的时候。

最初设计写过空闲零定时唤醒，后来 Git 状态里已经用了 ticker，原来的描述就不能直接沿用。反过来，有 ticker 也不能说明 CPU 一定高，还是要测。

早期终端骨架的体积和性能数据，更不能拿来代替加了窗口、终端模拟器以后的表现。冷启动、输入延迟、多终端内存，都值得留一份带版本和场景的记录。

这件事和继续加功能一样，都得排进时间里。

10 月 15 日那份笔记给出的候选顺序，是先补外部改动与审查，再从一种语言服务开始补定义、引用、悬停和诊断，之后根据实际使用减少重复操作，分发也继续完善。

我觉得其中最值得留下的方法，是记录自己为什么不得不切到另一个编辑器。找不到定义，就记导航；不敢相信眼前的 diff，就记刷新；布局打断工作，就记交互。

这些记录积累起来，下一步该做什么会比盯着功能对照表清楚。至于砚最后会长成哪种工作台，先把这几段日常工作走顺，再往下写。

想看看这些想法建立在什么基础上，可以先下载砚试用。本文保留的是 10 月 15 日的讨论，下载版本的实际功能以对应发布说明为准。

2026-10-19 补充：公开安装包为 v0.1.0-alpha.14 ，适用于 macOS 13+、Apple Silicon（M 系列芯片）。

安装包目前尚未经过 Apple 公证，首次打开的说明见发布页。