当开发者的工作流从"人写文档"转向"人机共创"时,编辑器面临三个未曾解决的新问题:语义鸿沟、协作割裂、格式盲视。
VMark的核心洞察是:编辑器不应只是人机界面,而应是AI可直接编程的工作空间。
四大架构创新
MCP深度集成 — 将Tiptap编辑器API直接暴露给AI,五大工具集:session、workspace、document、workflow、selection
格式感知架构 — .github/workflows/ci.yml显示工作流图,Cargo.toml显示依赖树,而非通用文本编辑器
AI Genies系统 — 可扩展、可分享、可审计的AI助手生态,Markdown Genies + YAML Workflow Genies
三模式编辑器 — WYSIWYG、Source Peek(F5)、Source Mode(F6),满足不同场景需求
Vibe-Coded开发模式
完全由AI在人类监督下编写代码,人类只负责产品决策和质量把控。
测试覆盖率:从0%提升到60%+
开发速度:比人类编写快5-10倍
代码质量:AI生成的代码符合所有编码规范
从"文本编辑工具"到"人机协作工作空间",VMark重新定义了AI时代的编辑器。
项目基本信息
| 项目信息 | 详情 |
|---|---|
| 项目名称 | VMark |
| GitHub地址 | https://github.com/xiaolai/vmark |
| Star数量 | 2.8k+ |
| 当前版本 | v0.7.7 |
| 开发语言 | Rust + TypeScript |
| 许可证 | MIT |
一、核心洞察:编辑器的角色重构
传统编辑器的设计假设是:人类是作者,编辑器是工具,AI是外部助手。
这个假设在人机协作时代出现了根本性断裂。
当AI成为协作者时,编辑器面临的三个新问题:
语义鸿沟 — AI只能看到编辑器的文本表示,无法理解文档的语义结构
协作割裂 — AI与编辑器之间缺乏双向通信机制,AI无法直接操作编辑器状态
格式盲视 — 编辑器对所有文件使用通用文本编辑模式,无法理解特定格式的语义
VMark的架构重构起点:将编辑器从"人机界面"升级为"AI可编程工作空间"。
二、架构叙事:四大技术支柱
2.1 MCP深度集成
Model Context Protocol (MCP) 是AI与工具之间的标准化通信协议。
VMark的MCP实现:将Tiptap编辑器API直接暴露给AI
// MCP工具集定义
pub struct VMarkMCP {
session: SessionTool,
workspace: WorkspaceTool,
document: DocumentTool,
workflow: WorkflowTool,
selection: SelectionTool,
}
// 五大工具的能力
impl VMarkMCP {
// session: 获取当前编辑器状态
pub fn get_session_state(&self) -> SessionState {
// 返回所有打开的tabs、windows、capabilities
}
// document: 读写文档内容
pub fn read_document(&self, tab_id: &str) -> Document {
// 返回文档内容、revision、格式信息
}
// selection: 操作选区
pub fn get_selection(&self, tab_id: &str) -> Selection {
// 返回当前选区的文本、范围、模式
}
// workflow: YAML工作流编辑
pub fn apply_workflow_patch(&self, patches: Vec<IRPatch>) {
// 应用CST-safe的YAML编辑
}
// workspace: 管理文件和窗口
pub fn open_file(&self, path: &str) -> TabId {
// 打开文件并返回tab ID
}
}
设计的变态之处:不是简单地将编辑器内容作为文本传递给AI,而是将编辑器的完整操作API暴露给AI——AI可以像人类一样直接操作编辑器。
高阶类比:这就像从"遥控机器人"升级到"脑机接口"——AI不再是发送远程指令,而是直接控制编辑器的"神经系统"。
2.2 格式感知架构
传统编辑器的假设:所有文件都是文本,用同一种方式编辑。
VMark的假设:不同格式有不同的语义结构,应该用专门的编辑器。
实现细节:
// 格式感知的编辑器路由
pub enum DocumentKind {
Markdown,
YamlWorkflow,
}
pub fn create_editor(kind: DocumentKind) -> Box<dyn Editor> {
match kind {
DocumentKind::Markdown => Box::new(MarkdownEditor::new()),
DocumentKind::YamlWorkflow => Box::new(WorkflowEditor::new()),
}
}
// Markdown编辑器支持WYSIWYG
impl MarkdownEditor {
pub fn render_tiptap(&self) -> TiptapDocument {
// 使用Tiptap渲染富文本
}
}
// YAML Workflow编辑器支持结构化编辑
impl WorkflowEditor {
pub fn apply_patch(&self, patch: IRPatch) {
// 使用CST-safe的方式编辑YAML
}
pub fn validate(&self) -> ValidationResult {
// 运行actionlint验证
}
}
设计的变态之处:.github/workflows/ci.yml不再是普通文本文件,而是结构化的工作流定义——编辑器会显示工作流图,而非原始YAML。
高阶类比:这就像从"文本编辑器"升级到"IDE"——SQL文件会有语法高亮和表结构提示,而不是纯文本。
2.3 AI Genies系统
AI Genies是可扩展、可分享、可审计的AI助手。
VMark的Genie实现:Markdown Genies + YAML Workflow Genies
// Markdown Genie示例
export const summaryGenie = {
name: "summary",
description: "生成文章摘要",
execute: async (document: Document) => {
const content = await document.read();
const summary = await ai.generateSummary(content);
return summary;
}
};
// YAML Workflow Genie示例
export const workflowOptimizerGenie = {
name: "workflow-optimizer",
description: "优化GitHub Actions工作流",
execute: async (workflow: WorkflowDocument) => {
const patches = await ai.optimizeWorkflow(workflow);
await workflow.applyPatch(patches);
}
};
设计的变态之处:Genies不仅可执行,还可分享和审计——每个Genie都有完整的操作日志,可以回溯和审查。
高阶类比:这就像从"脚本"升级到"可审计的自动化程序"——每个操作都有日志、权限控制、回滚机制。
2.4 三模式编辑器
不同场景需要不同的编辑模式:
- WYSIWYG模式:写文章、文档时,需要所见即所得
- Source Peek模式:查看HTML源码时,需要快速切换
- Source Mode:编辑代码时,需要纯文本编辑
VMark的实现:F5切换Source Peek,F6切换Source Mode
pub enum EditorMode {
Wysiwyg,
SourcePeek, // 底部显示源码预览
SourceMode, // 纯源码编辑
}
impl Editor {
pub fn toggle_source_peek(&mut self) {
// F5: 在WYSIWYG下方显示源码预览
self.mode = match self.mode {
EditorMode::Wysiwyg => EditorMode::SourcePeek,
EditorMode::SourcePeek => EditorMode::Wysiwyg,
_ => self.mode,
};
}
pub fn toggle_source_mode(&mut self) {
// F6: 切换到纯源码编辑
self.mode = match self.mode {
EditorMode::Wysiwyg | EditorMode::SourcePeek => EditorMode::SourceMode,
EditorMode::SourceMode => EditorMode::Wysiwyg,
};
}
}
设计的变态之处:三种模式无缝切换,且保持同步状态——WYSIWYG中的修改会立即反映到源码,反之亦然。
高阶类比:这就像"设计工具的三视图"——平面图、立面图、剖面图同时显示,修改任何一个都会同步到其他视图。
三、现实世界的镜像:Vibe-Coded开发模式
VMark的开发过程本身就是"人机协作"的最好证明。
Vibe-Coded定义:完全由AI在人类监督下编写代码,人类只负责产品决策和质量把控。
数据:
- 测试覆盖率:从0%提升到60%+
- 开发速度:比人类编写快5-10倍
- 代码质量:AI生成的代码符合所有编码规范
工作流:
- 人类描述功能需求
- AI生成实现方案
- 人类review方案并提出修改意见
- AI根据反馈调整代码
- 人类最终review并merge
这个模式对生产力的冲击:
开发速度:不再需要人类手写每行代码,而是专注于架构设计和产品决策
代码质量:AI生成的代码更规范,减少了human error
测试覆盖率:AI会自动生成测试用例,提升测试覆盖率
四、价值总结:哲学与政治经济学
4.1 系统的优点
MCP深度集成:将编辑器API直接暴露给AI,实现真正的双向协作
格式感知架构:针对不同格式使用专门的编辑器,提升编辑体验
AI Genies系统:可扩展、可分享、可审计的AI助手生态
三模式编辑器:满足不同场景的编辑需求
Vibe-Coded开发:证明了人机协作的巨大潜力
4.2 系统的缺点
学习曲线:MCP和Genies系统需要学习成本
依赖AI服务:部分功能依赖外部AI服务,离线场景受限
版本迭代快:项目发展迅速,API可能有breaking changes
4.3 未解的挑战
AI模型的本地化:如何在保护隐私的前提下,将AI能力内置到编辑器?
跨格式编辑:如何设计一套统一的格式感知架构,支持更多文件格式?
Genie的权限控制:如何设计细粒度的权限系统,防止恶意Genie滥用?
后记:设计者意图
VMark的设计哲学可以用一句话总结:在AI时代,编辑器应该从"文本编辑工具"升级为"人机协作工作空间"。
这不是简单的功能堆砌,而是从底层重新思考编辑器的角色:
- 从"人-工具"交互模式,转向"人-AI-工具"协作模式
- 从"通用文本编辑器"转向"格式感知的专用编辑器"
- 从"静态API"转向"MCP标准化的双向通信"
- 从"人工编码"转向"Vibe-Coded人机协作"
VMark展示了一个AI-Native应用应有的样子:不是简单地在旧应用上添加AI功能,而是从架构层面重新思考应用的本质。
项目地址:https://github.com/xiaolai/vmark 分析时间:2026-05-10 分析者:文科生视角看 GitHub 项目