加载失败
Ki 是一个以 AST（抽象语法树）为中心的源码编辑器，示例展示了语法级选择与修改（例如自动处理逗号、按节点扩展选择）。讨论把 Ki 放在更长的结构化编辑传统里来审视，提到 Mathematica 的早期选择机制、JetBrains MPS（一个语言工作台）和 Charles Simonyi 的 intentional programming 等先例。评论同时关注实现细节与工程折衷：Tree-sitter（增量解析库）、容错解析器、ast-grep/semgrep 这类基于 AST 的批量变换工具，以及如何兼容现有工具链、版本控制与键位布局问题。许多人把 Ki 的 VS Code 扩展当作降低试用门槛的务实做法，同时对纯 AST-first 编辑器在大规模工程中造成的生态成本表示担忧。
评论里普遍称赞把“语法节点”作为第一类选择与修改对象能显著加快重构与常规编辑。典型对比是 JetBrains 的 Expand/Shrink Selection（Ctrl+W）与 Ki 的语法级选择，用户举例说明按节点扩展选择比基于文本的多光标或正则更精确；Ki 的示例还演示了像自动删除/插入逗号这类语法敏感改动的细节处理。多人提到把这类操作与“extract method”等重构配合后能把繁琐流程压缩为少量按键，且 Helix/Neovim 通过 Tree-sitter 已能做到类似功能；相对地有人抱怨 VS Code/Zed 在结构感知上表现仍偏粗糙。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
讨论回顾了三十年左右的结构化编辑研究与工业尝试，既有作者的博士工作，也提到 Mathematica 早期 notebook 的树形选择、JetBrains MPS 的实验和 Charles Simonyi 的 intentional programming。关键教训是“只允许有效语法状态”会带来可用性难题：某些合法结构必须经过一段不可避免的无效中间状态才能构造，或造成输入路径变长，因此出现用“holes/gaps”表示不完整节点的折衷方案。现代续作如 Pantograph、BABLR 被提为将旧思路与容错解析、可见缺口表示结合的尝试，但评论也警告显示层（二维文本）与树结构的不一致会增加交互复杂度。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
反对或谨慎的声音集中在工程与生态代价：完全基于 AST 的编辑器通常需要专用 IDE、丢失终端可见性（不能直接 cat 或用传统文本工具查看）、并且会让版本控制、代码审核等现有流程难以复用。有人以 JetBrains MPS 的实际体验为例指出重量化、生态锁定与工具链重建的高成本；社区同时在讨论基于 AST 的 VCS/差异算法（如 Weave、librdx/be 等）来缓解这类问题。因此很多人把 Ki 的 VS Code 扩展视为降低门槛的务实做法，而不是直接替换全部生态的理由。
技术实现讨论集中在 Tree-sitter、容错解析与基于 AST 的批量变换工具上。多条评论指出 Neovim/Helix 已依赖 Tree-sitter 实现增量选择与语法节点导航，并且举出 ast-grep 的 pattern→rewrite 示例（例如 TypeScript 的 $A && $A.$B → $A?.$B）作为可复用的代码迁移手段，同时提到了 semgrep 作为已有替代。应对不可解析中间态的方案包括使用 tolerant parser（如 tolerant-php-parser）、把不完整位置用 gap/hole 表示（BABLR 的做法），或在必要时把片段序列化为文本再解析回树。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
可发现性（不知道屏幕上哪类节点对应哪个命令）与键位/肌肉记忆是被反复提到的采纳障碍。有人构想用颜色或 overlay 来提示可选语法范围，Ki 的交互设计则提供在光标周围显示可跳转的节点标签（如按 d m），以降低认知门槛；但也有对位置化键位和 keyboard-drawn 布局的反感，特别是对非 QWERTY（例如 Dvorak）或终端环境兼容性的抱怨。另有讨论指出 Ki 的 momentary layers 依赖 kitty keyboard protocol，导致在 Neovim 中难以原生复现，这些实现细节加大了将 Ki 完全替换现有编辑器的成本，因此 VS Code 扩展被视为更平滑的入口。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
很多人认为 AST 编辑并非普适必需：对偶尔改动或注重快速编码的开发者，学习成本可能超过收益；但在需要大规模结构化重构或跨文件变换时其优势明显。讨论也触及 LLM/IDE-AI 的角色：有人提议直接用自然语义让 AI 执行重构以省掉学习新编辑模型，但也有人反驳称简单局部改动用键盘/语法节点操作往往更快且更可控。总体倾向是把 LLM/自动化视为补充（生成 AST 操作脚本或调用 LSP/refactoring），而非彻底替代语法感知工具。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
AST: 抽象语法树（AST）：把源代码解析为节点与子节点的树状结构，编辑器用它来识别语法级单元以实现精确选择、重构与代码变换。
Tree-sitter: Tree-sitter：一个增量解析库和解析器生成器，常被嵌入编辑器以维护实时语法树、支持语法高亮、语法节点导航与增量选择。
LSP: LSP（Language Server Protocol）：编辑器与语言服务之间的协议，提供跳转、重命名、补全与诊断等功能，通常与语法树/解析器配合用于精确重构。
结构化编辑（Structural editing）: 结构化编辑 / structure editor：直接在 AST 上进行插入、删除与变换的交互模型，目标是以语法为单位保证或辅助正确性，常用“holes/gaps”表示不完整位置以支持逐步输入。
ast-grep: ast-grep：基于 AST 的代码匹配与重写工具（类似 semgrep），通过模式+rewrite 在语法层面批量迁移代码（示例中用于 TypeScript 的模式替换）。