Git、分栏、终端标签一轮轮补下来，功能列表长了不少。接着往下列，当然还能列出很多：语言服务、更多面板、更多快捷操作。
但我开始觉得，得停下来想想先做哪一个。
这篇沿着 10 月 15 日的方向笔记往下写。里面有几个想试的方向，也有当时顺着代码发现的问题，还没有定成新的开发计划。
现在这些功能，已经能接起一段工作
先读任务文档，在终端运行编码工具，看它改了哪些文件，自己检查、修几处，再跑检查、暂存和提交。
砚已经有文档、文件、终端和 Git 总览，离这段工作并不远。
如果继续围绕它做，命令行工具可以保留自己的配置和认证，砚把本地阅读、修改和审查做好。暂时不必为了接上这段流程，就再造一个聊天面板或模型配置系统。
这是我想试的方向。至于别人会不会也这么用，还得拿真实任务试，光看功能能拼起来不够。
一想到终端工具连续改文件，刷新就绕不过去了
在另一个程序里改完文件，再切回砚，窗口重新获得焦点，可以触发一次磁盘检查。
但工具就在砚的内嵌终端里跑，人一直待在这个窗口，可能根本没有“切回来”这一步。
翻当时的代码，checkDisk 会刷新文件树、处理打开文档的外部修改，但不会顺便重建快速打开的索引。终端前端从 shell 返回时有重建索引的路径，窗口里的内嵌终端却不经过那次暂停和恢复。
这就留下一个待验证的场景：新文件已经出现在树里，快速打开却还搜不到。下一步需要把这条路径实际跑一遍，再决定刷新该放在哪里。
Git 还是一个 M，内容可能已经改了两遍
还有一种更难察觉的情况：
第一次写入：状态 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 公证，首次打开的说明见发布页。
仓库留档
- 研究原文：product-direction-research-2026-10-15.md。截至本轮整理，该文件仍未提交；保留原状。
- 本轮核对：workspace.go、git.go、changes.go、Git 状态比较。
- 未重新进行外部产品研究，不转述竞品的当前能力；未执行方向文档中的开发任务或变更产品规格。
这篇方向笔记的价值在于把“加功能”转为“修工作流”，适合正在做编辑器/IDE 或开发工具的产品与工程团队参考，尤其适用于功能膨胀后需要重排优先级、验证刷新与状态同步的场景。