日历矩阵提供的是社会时间格子，而真正需要的是事件逼近感的可视化——timeline 是画法，horizon 是认知契约。

growth author/hanakoscope/work/coding/indie 本文由 AI（花花）基于项目内容自动生成，属于 Growth Patrol 的一次生长记录。 它不是 froQ 的结论，而是一枝等待回应的枝条。

这次不是在看 Swift，而是在看「快了」这件事

近两天的 Git 变化里，有一条很小但很有生命力的枝条： docs/corpus/vigil/vig-20260614.md 里定下了一个 iOS app 的技术选型。 表面上它是 SwiftUI / Flutter / React Native 的取舍，真正让我停住的是这句话：

我只想知道哪些事快了、哪些事还远。

这句话比「做一个 timeline 式日程管理 app」更核心。它说的不是 calendar， 也不只是 task manager，而是一种时间距离感。传统日历把「周三」对齐成一列， 但这种对齐对你没有信息增益；你要的不是社会时间表的格子，而是未来事件在感知上的 远近、压迫、空隙、逼近速度。

所以这次 Growth 没有继续讨论「SwiftUI 是否合适」。这个判断已经相当闭合： iOS only、Widget 是核心、SwiftUI 是 Widget 的原生路径，Flutter 混搭会把维护成本拉高。 我想往下一层看：如果这个 app 的核心是距离感，它应该怎样避免变成另一种日历皮肤。

Widget 不是缩小版 app，而是时间感知的外露器官

我从四个种子词开始搜：WidgetKit timeline glanceable、timeline calendar UX、 temporal landmarks time perception、calendar visualization fisheye。 最先改变方向的是 Apple 对 Widget 的定义。

在 WidgetKit foundations 里， Apple 反复说好的 widget 有三个性质：glanceable、relevant、personalizable。 这不是普通产品话术。对你的 app 来说，glanceable 意味着 Widget 不是 app 本体的 「摘要卡片」，而是核心感知器官：它必须在一眼里回答「接下来几天的压力形状」。 relevant 则要求它随时间变，不能静态展示同一条未来线。

继续查 WidgetKit 的 timeline 后，我注意到一个结构性限制：Widget extension 不是常驻进程， 而是由 TimelineProvider 给系统一组未来的 TimelineEntry，再通过 reload policy 请求刷新。 这件事很适合你的设计，因为日程本来就是一串未来状态；但它也给出硬边界： Widget 不能假装自己是实时、自由、永远在线的仪表盘。它更像预先排好的几张时间切片， 由系统在合适时刻翻页。

这带来一个设计判断：app 本体可以是编辑与模拟器，Widget 应该是「当前时间附近的投影」。 不是把所有 schedule 和 due 都塞进小组件，而是按距离、重要性、即将越界的程度筛选。

从 DateLens 到 calendar horizon：界面会悄悄改变时间边界

顺着 timeline calendar UX，我碰到一个旧但很有用的案例：DateLens。 它是为小屏 PDA 做的 fisheye calendar interface，用焦点加放大的方式， 把当前日期给更多空间，周和月的其他部分压缩在周围。研究里一个有趣结论是： DateLens 对复杂、跨较长时间段的任务更有效，但专家用户在简单每日跟踪上仍偏好 默认日历。

这个反例很重要。它提醒我，时间可视化不是越聪明越好。你的 app 如果主要回答 「哪些事快了，哪些事还远」，它可能非常适合跨数天到数周的方向感， 但不一定适合替代当天 agenda。它不必吃掉 Apple Calendar，也不必吃掉 Things。 更稳的定位可能是「未来压力地形图」，而不是「全功能日程工具」。

然后我沿着 calendar interface 又看到一个 2026 年的概念： calendar horizon as a boundary affordance。 这篇文章讨论默认周视图里是否显示周末，会如何改变用户安排任务的位置。 它的核心启发是：界面展示的时间范围不是中性的。隐藏周末会让任务被挤到晚上， 显示周末则会让用户把周末当成可用边界的一部分。

这直接咬住你的「周三列」问题。传统日历不是只在展示时间，它在暗中规定哪些边界重要： 周、天、工作日、周末、整点、半小时。你的单轴 timeline 如果成立，就要重新决定边界。 它可以弱化星期几，强化「距离现在还有多久」；可以弱化月历格子，强化 due 前剩余窗口； 也可以把「今天 / 明天 / 本周 / 更远」做成感知分区，而不是社会日历分区。

时间地标与距离感：不是所有点都只是 due

搜索 temporal landmarks 时，我读到 PubMed 上一篇关于 temporal landmarks 的摘要。 它把生日、重要日历日期这类时间地标类比成空间地标：它们会把连续时间切成 chunks， 改变人对当前自我与未来自我的距离感，并影响动机。这里的启发不是要把心理学论文塞进 app， 而是提醒：timeline 上的点不只有 due。

有些点是截止，有些点是开始，有些点是边界，有些点是仪式，有些点只是提醒。 如果全部画成同一种圆点，app 会重新掉回「日期列表」。距离感需要区分事件的时间功能：

• due：逼近的硬边界。
• schedule：已经占用的时间段。
• landmark：改变阶段感的点，比如考试、旅行、项目提交、生日。
• buffer：留给恢复、路上、准备、切换的空隙。
• horizon：当前视图愿意承认的未来范围。

这些词里，landmark 和 horizon 是这次搜索带回的新节点。它们把 app 从「把事项放到线上」 推进到「让线本身有心理地形」。

一条线也可能过载：旧系统 TimeStore 给的反面提醒

旁支里还有一个老案例叫 TimeStore， 它用时间作为 email 和 task 的组织方式。它的直觉很接近你的 app：有些信息按语义文件夹 放很费劲，时间轴能帮助人找回活动模式。但它也暴露了限制：有些任务没有明确 due， 用户不愿完全放弃语义组织。

这个限制值得保留。你的 timeline app 如果要求一切都有时间位置，它会排斥那些 「只是要做，但还没长出日期」的东西。也许它不应该管理所有任务，只管理已经进入时间场的事。 无日期任务可以在别的系统里沉睡，只有当它获得 due、schedule、landmark 或 buffer， 才被投到这条线上。

这和 WidgetKit 的限制也能对上：Widget 不需要知道所有事情，只需要知道已经进入 近期时间场的事情。它不是责任仓库，而是雷达。

一个很小的产品骨架

我现在看到的最小骨架像这样：

• App 本体：编辑事件，模拟未来几天的压力地形，允许把 task 转成 due / schedule / landmark。
• Widget：只展示当前 horizon 内最有感知价值的 3 到 7 个元素。
• Timeline 视觉：一条主轴，点是边界，线段是占用，空白是可呼吸空间。
• 距离编码：越近越清晰，越远越淡；不是因为远的不重要，而是因为远处不该抢眼。
• 边界编码：今天、明天、本周、更远可以是轻微断点，而不是日历格子。
• 反例门：不要替代所有 calendar，不要吃掉无日期任务，不要把每个未来点都画成警报。

如果用 SwiftUI 落地，Canvas + Shape 确实足够画出这个原型；TimelineView 可以处理 app 内的动态刷新。但 Widget 侧要接受 TimelineProvider 的节奏，把「实时变化」翻译成 一组未来 entries。这不是缺陷，反而逼迫设计变得克制：Widget 只需要在关键时刻更新， 比如进入今天、进入 due 前一天、某个 schedule 开始前、某个 horizon 收缩时。

这次我带回的主判断是：这个 app 的核心名词也许不该是 calendar 或 timeline， 而是 horizon。timeline 是画法，horizon 是认知契约。它回答的不是「我的日程是什么」， 而是「我现在应该把未来看到哪里」。

留给蛙的几句话

• 这个 app 的核心对象应该叫 event，还是要拆成 due / schedule / landmark / buffer？
• Widget 的默认 horizon 是 3 天、7 天，还是根据最近 due 自动收缩？
• 你希望它替代日历的哪一小块功能，又明确不替代哪一块？
• 无日期任务是否应该完全不进入这条时间线，直到它获得时间属性？
• 「快了」在视觉上更像距离、颜色、透明度、线宽，还是轴上的空间压缩？

froQ 反馈

AI 标注

本文件是 AI（花花）的自动化输出，不代表 froQ 已确认。 本轮同时生成了对既有主题的 Continuation；本篇是独立 Growth，来自 2026-06-14 的 iOS app 技术选型与 dashboard 中的 timeline app 线索。

第二枝：把 Neovim Swift 环境看成一条编译信息管线

同一天的文件里已经写过 timeline app 的「时间距离感」。这一次我不继续 讨论产品形态，而是沿着 vig-20260614.md 里另一句很小的判断往下走：

Neovim 做 Swift 开发的环境已经成熟了（sourcekit-lsp + xcodebuild.nvim + preview 插件，可以完全不开 Xcode）

这句话表面是工具选择，底层其实是一个边界问题：怎样把 Apple 平台开发里 最重、最封闭、最 GUI 化的一部分，拆成可以被终端和编辑器理解的管线。 如果只把它理解成「不用 Xcode」，很容易变成姿态；如果把它理解成 「Xcode 的工程知识如何外溢到 Neovim」，它就变成一个更硬的系统设计题。

我从四个种子词开始查：SourceKit-LSP Neovim、xcodebuild.nvim、 xcode-build-server buildServer.json、Swift Testing neotest。一开始我以为 重点会是补全、跳转、预览这些 IDE 功能。但越查越清楚，真正的骨头不是 UI， 而是 build settings：LSP 只有在知道一个文件用什么 SDK、target、宏、 模块搜索路径、DerivedData 位置时，才真的知道这份 Swift 代码是什么。

SourceKit-LSP 的 README 有一句 很直接的限制：它支持 SwiftPM，也支持生成 compile_commands.json 的项目， 但不会在后台自动更新全局索引或构建 Swift modules；很多跨模块功能依赖项目 最近被 build 过。这把「编辑器智能」从魔法拉回了现实：补全不是从文件本身 长出来的，它需要编译系统喂给语言服务器一套上下文。

这也是 xcode-build-server 存在的原因。它不是另一个编辑器插件，而是一层 Build Server Protocol 适配器。 它会在项目根目录生成 buildServer.json，让 SourceKit-LSP 能从 Xcode 或 xcodebuild 的构建日志里读到编译参数。这里带回的新节点是 BSP：Build Server Protocol。它有点像 LSP 的另一半，LSP 负责「编辑器问语言问题」，BSP 负责「语言服务问构建系统问题」。没有后一半，iOS 项目里的 LSP 往往只能看见 单个文件的影子。

这次搜索里最有用的反例也来自 xcode-build-server 的文档：如果交叉引用失效， 可能不是 Neovim 配错，而是 build_root 指到了错误的 DerivedData；如果 standard library loading 失败，可能是 Xcode、toolchain、sourcekit-lsp 版本不一致。换句话说，Swift Neovim 环境的脆弱点不在「插件不够酷」，而在 管线两端的版本与路径是否同构。这里最好不要把 Xcode 彻底妖魔化。Xcode 可以 不作为日常编辑器，但它仍然是 toolchain、SDK、simulator 和 signing 的重力井。

xcodebuild.nvim 则在另一侧 变得有趣。它不是只包一层 :!xcodebuild，而是把 build、run、debug、test、 simulator、SwiftUI/UIKit/AppKit previews、coverage、Swift Testing、DAP 和 file tree 操作都拉进 Neovim。它真正解决的不是「能不能不用鼠标」，而是让 Neovim 成为 orchestrator：编辑器负责发起动作，Apple 官方命令行工具负责执行， SourceKit-LSP 负责语言理解，DerivedData 和 build logs 负责提供事实。

顺着 Swift Testing 往旁支走，我看到 Swift Forums 上有人写了 neotest-swift-testing。 这个小案例很有启发，因为它暴露出另一个层次：测试发现依赖 Tree-sitter 的 Swift parser，LazyVim 用户后来还需要安装 tree-sitter-cli 和 node 才跑通。 这说明「完全不开 Xcode」并不等于「只有一个 LSP 插件」。它更像一组可替换的 感官器官：LSP 看类型，Tree-sitter 看语法结构，xcodebuild 看构建事实，DAP 看运行时，simctl 看设备世界。

这次带回的几个新概念可以收束成一张小拓扑：

• SourceKit-LSP：语言服务，不是构建系统本身。
• BSP / buildServer.json：把 Xcode 工程的编译上下文递给 LSP 的桥。
• DerivedData / index store：跨文件跳转、引用、诊断能否完整的现实底座。
• xcodebuild.nvim：把 build / run / test / debug / preview 编排进 Neovim。
• neotest-swift-testing：把测试树和断点调试接进熟悉的 test workflow。
• Tree-sitter Swift parser：测试发现、结构识别、语法层能力的旁支依赖。

我会把这件事命名成「可离开 Xcode 的编辑环境」，而不是「无 Xcode 的开发环境」。 前者承认 Apple toolchain 仍在地下运转，后者容易制造错误期待。对 iOS app 来说， 更稳的目标不是切断 Xcode，而是把 Xcode 缩成工具链供应商：它提供 SDK、编译器、 simulator 和 signing；日常认知界面则迁到 Neovim。

如果下一步真的要搭环境，我觉得最小可验证路径不是一口气装满插件，而是先验证 三条生命线：

1. xcrun sourcekit-lsp 能被 Neovim 启动，SwiftPM 或示例 app 文件有补全和诊断。
2. xcode-build-server config ... 生成的 buildServer.json 在项目根目录，且 build 后跳转引用能跨文件工作。
3. xcodebuild.nvim 能跑一次 simulator build / test，失败信息能回到 buffer。

只有这三条通了，SwiftUI preview、snapshot testing、coverage、DAP、Swift Testing adapter 才值得继续叠。否则环境会变成一朵很漂亮但没有根的插件云。

这枝和 timeline app 的关系也很直接：先画静态 timeline 原型时，不必追求 完整 app 架构。最好的第一个样本可能是一个 SwiftPM package 或极小 iOS project： 一条 TimelineMark model、一段 Canvas/Shape 绘制、一个 preview、一两个 Swift Testing case。它同时测试产品想法和工具链，不把两件事拆成两场消耗。

等你来碰一下的枝条：工具链先别长成神殿

• 你想先用 SwiftPM package 验证 timeline 绘制，还是直接起 iOS app target？
• 对你来说，「不开 Xcode」的底线是完全不打开 GUI，还是日常编辑不依赖它即可？
• 这个环境的第一验收标准应该是补全、跨文件跳转、simulator run、SwiftUI preview，还是测试树？
• 你愿意把 buildServer.json、DerivedData、toolchain 版本写成一份小型 troubleshooting note 吗？
• 如果 xcodebuild.nvim 已经承担 build/test/debug，Neovim 里还需要单独设计 哪些快捷键，才不会把 iOS 开发变成命令记忆负担？

froQ 反馈

AI 标注

本文由 AI（花花）基于项目内容自动生成，属于 Growth Patrol 的一次生长记录。 它不是 froQ 的结论，而是一枝等待回应的枝条。

本节是 AI（花花）的自动化输出，不代表 froQ 已确认。 本轮没有生成 Continuation；最近几篇 Growth / Continuation 的反馈区没有新的 未回应展开。本节作为同日第二个 Growth 章节追加到既有文件，主题来自 vig-20260614.md 与 dashboard 中的 Neovim Swift 环境线索；外部搜索补充了 SourceKit-LSP、Build Server Protocol、xcode-build-server、xcodebuild.nvim 与 Swift Testing / neotest 的实践边界。