VSCode没有真正的敏捷看板，仅靠插件基于Markdown标签模拟；其核心是文本结构+快捷键链路，而非UI拖拽；性能瓶颈多源于Webview插件监听全量文件变更。
VSCode 里没有真正的敏捷看板，只有模拟方案
VSCode 本身不提供拖拽式 Kanban 看板 UI，所有标榜“敏捷工具”的插件（如 kanban-board、vscode-todo-plus、Todo Tree）都基于 Markdown 文件 + 标签解析 + 侧边树视图来模拟看板逻辑。这不是缺陷，而是设计取舍：VSCode 定位是编辑器，不是项目管理平台。所谓“敏捷工具”，本质是把任务状态映射到可版本控制的文本结构上。
核心依赖是 Markdown 语法和标签约定
这类插件能否工作，完全取决于你是否在 Markdown 文件中使用了它能识别的模式。常见有效写法包括：
-
- [ ] 【TODO】用户登录接口超时重试（kanban-board识别方括号 + 中文状态标签） -
// TODO @board: 实现导出 CSV（Todo Tree提取注释 + 自定义 tag） -
## IN PROGRESS\n- [x] 重构 auth 模块（vscode-todo-plus按二级标题分组）
一旦格式不匹配——比如用 - [ ] TODO: … 少了中文括号或空格，插件就无法归类。别怪插件“不灵”，先检查你写的到底算不算它认的“任务”。
快捷键链路比 UI 拖拽更关键
真正提升效率的不是“看板长得像不像 Jira”，而是操作路径是否闭环。例如：
- 用
Ctrl+P直接打开TODO.md，而不是靠鼠标点开资源管理器 - 在看板文件内用
Ctrl+D批量选中[ ]后输入[x]，比一个个点勾快 5 倍以上 - 给
todo-tree: toggle绑定Ctrl+Alt+T，点击树中条目直接跳转源码，省去手动搜// TODO
这些操作不依赖插件渲染 UI，只依赖文本结构和快捷键绑定，稳定性远高于任何 Webview 渲染的“看板面板”。很多用户卡顿，其实是装了带复杂 Webview 的看板插件，又没关自动刷新。
性能陷阱：别让“看板”变成内存泄漏源
部分插件（尤其是早期 kanban-board v1.x）会监听整个工作区的文件变更，对含数百个 Markdown 文件的 monorepo 造成明显卡顿。实测发现：
- 启用
kanban-board后，保存任意 .md 文件触发全量重解析，CPU 占用峰值达 40% -
Todo Tree默认只扫描打开的文件和package.json中声明的 glob 模式，更轻量 - 若只需看板功能，禁用
kanban-board的自动刷新（设"kanban.refreshInterval": 0），改用Ctrl+K V手动预览
真正的设计约束从来不在界面上，而在你是否愿意为每一条任务付出一行可维护、可搜索、不拖慢编辑器的 Markdown。
