企业官网建设流程全解析

刚接触 VSCode 里 TODO 注释的整理时，我一度觉得这不就是个高亮插件吗，能折腾出什么花来。直到在一个快两年的老项目里，我看着密密麻麻散落在几十个文件中的TODO、FIXME、XXX，整个人都麻了——这些到底哪些是急着要修的，哪些是陈年旧账，哪些是临时过渡方案？没人说得清，因为连注释的发起人自己都忘了。就是从那个时候开始，我认真研究起了 Todo Tree 这个插件，也把 TODO 类注释的规范、写法和自定义玩法彻底理了一遍。这篇内容适合所有用 VSCode 写代码的人，不管你是刚入职的新人，还是要带团队的组长，搞懂这套注释管理方案，你的代码可维护性能往上拉一大截。

1. 为什么要用 Todo Tree：注释管理的核心需求拆解

先说一个很反直觉的事实：大部分人的代码注释习惯，是把 TODO 当成"待办事项"在写，但实际上 TODO 注释的作用压根不是记事，而是"标记"。标记什么呢？标记代码里那些已知但不紧急的问题、暂时妥协的方案、需要在某个时间点回头处理的逻辑。如果不能把这些标记从代码里捞出来聚合成一张清单，那它们跟空气没什么区别。

1.1 没有管理工具时的痛点清单

想象一下没有 Todo Tree 的日子。你想找项目里所有的 FIXME 注释，要么靠编辑器全局搜索，搜完之后逐个文件跳转，再靠人脑记住每个注释的上下文；要么用官方自带的问题面板，但那个面板对自定义标记的支持很弱，基本只能看语法错误和 lint 报错；再要么就是靠团队约定，大家在群里互相喊话"那个谁你留的 TODO 搞一下"。这三种方式我都经历过，分别对应三个问题：

第一，高亮缺失。默认 VSCode 对TODO这类注释是没有特殊高亮的，它在代码里就是一个普通绿色注释，跟其他注释混在一起，扫一眼根本找不到。第二，无法聚合。全局搜索只能给你一个平面结果列表，没有分组、没有排序、没有过滤，在多文件多标签的情况下，你要手动分辨每个条目属于哪块功能。第三，上下文断裂。找到注释之后，你得再去看它附近的代码才能想起来当时为什么写这个，有时候注释离真正的问题代码隔了好几行，这个"为什么"就彻底丢了。

1.2 Todo Tree 解决了什么核心问题

Todo Tree 做的事情其实很简单，就是把所有约定好的标记注释从源码中抽出来，在侧边栏生成一棵树，按文件路径归类，点击即可跳转。听起来好像没什么，但实际用下来你会发现它解决了三个层次的问题：

• 可视化层次：未完成的 TODO 以特殊颜色高亮显示，一眼看清哪些代码还在"半成品"状态。
• 组织层次：侧边栏的树状结构天然地反映了项目的功能模块，哪个文件欠的债多，哪个模块的 FIXME 扎堆，一眼分明。
• 流转层次：写完注释等于加入清单，解决完注释等于自动消失，整个过程不需要任何额外操作，这是它最打动我的地方——注释即任务，清理即完成。

第三个层次是很多人忽略的价值。任务管理工具（比如各类项目管理软件）里的待办和代码里的 TODO 本质上应该是联动的，但大多数人的工作流是两套系统互相脱节。Todo Tree 至少让你在代码这个层面形成闭环：你不需要在写完一个TODO: 这里需要补充错误处理之后，再去另一个软件里记一条"别忘了补错误处理"。代码本身就是待办清单，这个理念很朴素，但真的好用。

1.3 适合什么场景、什么人群

从人群讲，我最推荐这几类人优先用起来：第一类是维护老项目的人，老项目里遗留注释多，靠 Todo Tree 像扫雷一样把历史遗留问题清点出来，边清点边制定清理计划，这是对存量债务的管理；第二类是带团队的人，你可以在 code review 的时候明确要求"新的临时方案必须留 TODO 注释 + 责任人标识"，然后在开发周期末尾用 Todo Tree 把欠账拉出来，谁的东西谁认领；第三类是个人项目爱好者，自己写小项目的时候经常写到一半觉得"回头再改"，回头就是一万年，Todo Tree 至少能提醒你"这里确实没改完"。

如果你是刚入行的开发者，我反而建议你先从规范写注释开始，因为工具再好用，注释本身一团糟也白搭。看完后面的规范部分，再配合插件实践，会顺很多。

2. 基础配置与核心特性：让 Todo Tree 真正听话

装插件本身没什么好说的，市场里搜 Todo Tree 直接装就行。真正需要花心思的是理解它的配置体系和默认行为背后的意图，这样你才不会在遇到"为什么这个标签不显示"的时候一头雾水。

2.1 配置文件里的关键字段解析

Todo Tree 的配置项都集中在settings.json里，以todo-tree前缀开头。我最先建议你动的是todo-tree.general.tags，这个字段定义了插件要识别哪些标记，以及每个标记的展示行为。默认配置是长这样的：

"todo-tree.general.tags": { "TODO": { "icon": "check-circle", "iconColor": "#0a8f3c" }, "FIXME": { "icon": "tools", "iconColor": "#c74e00" }, "XXX": { "icon": "warning", "iconColor": "#d91e1e" } }

这里每个标签都配了 icon（图标名称）和 iconColor（图标颜色），这个设计特别聪明——它把标记的语义化从文字层面延伸到了视觉层面。TODO 是绿色圆形对勾，提示"有未完成事项"；FIXME 是橘色扳手，强调"需要修理"；XXX 是红色警告，意思是"这里特别需要注意，再不改要出问题"。视觉识别效率比纯文字高得多，这是插件做得很细致的一点。

2.2 全局开关与正则匹配逻辑

还有一个重点字段是todo-tree.filtering.excludeGlobs和todo-tree.general.rootFolder，不过我更想提醒你注意todo-tree.regex.regex这个字段。它决定了哪些注释会被匹配到，默认长这样：

"todo-tree.regex.regex": "(//|#|<!--|;|/\\*|\\*)\\s*($TAGS)"

这个正则其实很好理解：前面的(//|#|<!--|;|/\\*|\\*)是各种语言里的注释符号，后面的($TAGS)会替换成你在tags里定义的所有标签。也就是说，Todo Tree 默认只认"以注释起始符号开头 + 空格 + 标签"这种格式的注释。我特意说明这一点是因为很多人踩过一个坑：写了//TODO: something（没有空格）就不被识别，或者写/* TODO */里面带了星号前缀，匹配起来也有点别扭。解决办法也很简单，把正则改成"(//|#|<!--|;|/\\*|\\*|\\*)\\s*($TAGS)"就能多兼容一种星号开头的场景。

2.3 侧边栏视图的展示模式与交互技巧

装好插件后，侧边栏会出现一个 TODO 树，最开始你可能觉得"这不就是个文件列表吗"，但这里有几个交互细节值得说：

• 点击任意条目，会直接跳转到注释所在行，光标定位到注释行的开头。
• 条目右侧的（数字）表示该文件或目录下有多少个匹配标签，这个数字会在你解决注释之后实时减少，很有成就感。
• 顶部的搜索框是很多人忽略的神器。它支持按标签、按文件路径进行过滤。比如你输入!FIXME，就能过滤掉所有 FIXME 条目，只看剩下的；输入某个文件名关键词，就能只看这个文件下的所有条目。
• 右键菜单里可以"切换文件对其的包含/排除""隐藏当前标签类型"，这在你有一个目录全是第三方代码不想被扫进来的时候特别有用。

还有一个容易被忽略但实际很高效的用法：把 Todo Tree 从侧边栏拖到辅助侧边栏（Secondary Side Bar）。主侧边栏留给资源管理器，辅助侧边栏放 TODO 清单，这样你可以一边看文件树一边看待办清单，互不遮挡，效率翻倍。这个小细节我是在一次调窗口布局的时候偶然发现的，后来就成了固定习惯。

2.4 关于扫描范围与控制范围的进阶配置

默认情况下，Todo Tree 会扫描整个工作区所有文件。大项目里这就会产生问题：扫描慢、结果杂、还有一堆压根不需要管的三方依赖里的注释。所以我一般会配合两个配置用：

"todo-tree.filtering.excludeGlobs": [ "**/node_modules/**", "**/dist/**", "**/build/**", "**/vendor/**", "**/*.min.*" ], "todo-tree.general.settings": { "followSymlinks": false }

excludeGlobs就是字面意思，排除你不想扫的目录或文件。followSymlinks设为 false 是为了避免符号链接指向的外部目录被重复扫描。这两个配置一设完，侧边栏瞬间清爽，扫描速度也明显提升。段首的.vscode工作区配置里也可以单独覆盖这些设置，所以在团队协作时，你可以把 exclusions 写进项目的.vscode/settings.json，让所有协作者共享同一套扫描范围。

关于扫描速度，还有一个小 tip：打开一个超大项目时，Todo Tree 第一次扫描可能要 2 到 3 秒，这只是建立树索引的时间，后面文件编辑时它做的是增量更新，不会让你感到卡顿。如果你觉得卡，八成不是插件的问题，而是你有个特别巨大的文件（比如几百 M 的日志文件），这种文件直接加进 exclude 就完事了。

3. TODO 注释的正确打开方式：从格式到团队规范

插件配置再花哨，如果注释本身写得乱七八糟，Todo Tree 也只能给你展示一堆乱七八糟的条目。这一章我想认真谈谈注释规范的问题。注释是写给未来的自己和其他开发者看的，这句话说了无数遍，但真正执行的人不多。

3.1 三种核心标签的语义界定

先说语义。很多团队对 TODO、FIXME、XXX 的用法是模糊的，经常把 FIXME 当成 TODO 用，或者把 XXX 当 FIXME 用，这会导致后面看清单的时候完全分不清轻重缓急。下面这套区分是我个人比较推荐的，也是不少公司内部规范里常见的一种：

核心原则是：TODO 是"未来要做"，FIXME 是"现在有问题"，XXX 是"这里很危险"。三者的共同点是都不会立刻动手解决，区别在于解决时的紧急程度和处理方式。FIXME 一般是要修复现有行为的 bug，TODO 是要添加当前缺失的能力，XXX 则是提醒别人动这里之前先想清楚，别把隐患越捅越大。

3.2 结构化注释格式：让清单可以"追责"

光有标签还远远不够。我强烈建议在团队里推广结构化注释格式，也就是在标签后面补充类型、责任人和时间信息，像这样：

// TODO[error-handling]: 补全接口超时后的重试逻辑 // FIXME[legacy-payment]: 这里的金额单位混用了分和元，需要统一 // XXX[performance]: 这个双循环在数据量达到 10w 时耗时超过 2s // TODO[refactor][@某开发者]: 等账单模块重构完成后，把这段拆出去

你可以看到，方括号里写了模块或问题类型，有时候还带责任人和时间。这样做有什么好处？第一，Todo Tree 的搜索框可以按方括号里的关键字过滤，比如输入performance就能定位所有性能相关的待办；第二，责任人信息让清单可以"追责"，code review 的时候当场确认归属，比在群里@人高效得多；第三，时间信息可以帮你识别"陈年债"——超过三个月没人动的 TODO，基本可以判断优先级没那么高，可以先降级。

不过我建议时间信息不要写绝对日期，写相对行动点更稳妥，例如TODO[refactor]: 等下一个 sprint 开始后处理。写绝对日期的坏处是，如果某天已经过去，留着一行"2024-03-05"的注释会让人有种"这个任务是不是过期忘了"的暗示，反而产生认知负担。

3.3 注释中英文混写的通行准则

还有一个实操问题：注释到底用中文还是英文？我的看法是，英文注释在跨团队协作或开源项目里有必要，但国内团队内部用中文完全没有问题，效率更高。关键是保持一致性。你不要一个文件全中文，另一个文件全英文，更不要一条注释里中英混杂还没有空格。

另外尽量别在注释里写太口语化的词，比如"弄一下""搞搞"，建议用「处理」「修复」「优化」「重构」「补充」这类动词，这样搜索的时候关键词更统一。同一类 TODO 的描述尽量使用统一的句式，比如全部用"补全：""修复：""优化："，这样 Todo Tree 的清单扫过去非常整齐。

3.4 标签之外的隐藏注释类型：HACK、BUG、TEMP、OPTIMIZE

Todo Tree 的 tags 默认只显示那三个标签，但实际开发中我们经常还会用到别的标记。这些标记如果你不主动在配置里添加，Todo Tree 就不会识别，所以很多人根本不知道插件支持自定义标签。其实完全可以加，比如：

"todo-tree.general.tags": { "TODO": { "icon": "check-circle", "iconColor": "#0a8f3c" }, "FIXME": { "icon": "tools", "iconColor": "#c74e00" }, "XXX": { "icon": "warning", "iconColor": "#d91e1e" }, "HACK": { "icon": "bug", "iconColor": "#a371f7" }, "BUG": { "icon": "bug", "iconColor": "#d91e1e" }, "TEMP": { "icon": "circle-outline", "iconColor": "#e0a800" }, "OPTIMIZE": { "icon": "zap", "iconColor": "#2d7ff9" } }

加完后，Todo Tree 会把这几个新标签也显示在侧边栏并且自动高亮。我实际项目里加得最多的是HACK和TEMP，因为这两类注释出现的频率非常高。HACK代表"我知道这写得很丑陋但我现在没时间优化"，它的价值在于给后续接手的开发者一个心理预期，别对着烂代码骂娘。TEMP则代表"这只是临时方案，正式方案上线后必须换掉"，这种标签非常适合在对接第三方服务、写 mock 数据、走通主流程还没做边界处理的时候用。

4. 自制自定义图标：从改颜色到换图标的完整玩法

说完了常规配置，终于到了标题里那个最有意思的部分——自制 TODO 图标样式。很多教程到"改个颜色"就停了，但 Todo Tree 这套图标的可定制性远比大部分人以为的要深。我分三档玩法讲，你可以根据自己的实际需求选一档。

4.1 第一档：用内置 Codicons 图标，调整颜色就够了

第一档最简单，也适合绝大多数场景。Todo Tree 的 icon 配置接受两类值，一类是 VS Code 内置的 Codicons 图标名称，一类是自定义扩展提供的图标 ID。常见的内置图标你可以去 VS Code 的图标库网站查（搜索 codicons 就能找到），或者直接在配置里试。改颜色就是改iconColor字段，填十六进制颜色值即可。

"todo-tree.general.tags": { "TODO": { "icon": "check", "iconColor": "#22ab24" }, "FIXME": { "icon": "flame", "iconColor": "#ff6b00" }, "XXX": { "icon": "error", "iconColor": "#ff0033" } }

注意iconColor不是对所有的图标都生效。它本质上是给 SVG 图标做染色（tint），只有那些使用单色路径（stroke 或 fill 是 currentColor）的图标才能被染上颜色。很多自定义彩色图标是染不了的，因为它们的 SVG 路径里写死了颜色值。如果你改了iconColor但颜色没变，九成就是这个原因，换成单色的 codicon 图标就正常了。

4.2 第二档：自建一个主题扩展，挂上自己的 SVG 图标

如果你不甘心用现成图标，想完全自定义一个属于自己的 TODO 图标（比如一只小章鱼盯着一行注释），那就得走 VS Code 的主题扩展机制了。听起来很重，其实步骤很标准化，我拆解一下。

第一步：初始化扩展项目

用官方脚手架命令：

npm install -g yo generator-code yo code

Interactive 提示里选择 "New Theme Extension"，然后让你选 themes type 的时候选New Color Theme其实不太对，这里应该选 New Theme Extension 里的 Color Theme 也可以，但更准确的做法是我们需要的其实是一个能注册 Product Icon Theme 或者只是注册配置文件里contributes.icons的扩展。更简洁的做法是直接手动建目录结构，不依赖 yo 脚手架：

custom-icon-extension/ ├── package.json ├── icons/ │ ├── todo.svg │ ├── fixme.svg │ └── xxx.svg └── themes/ └── custom-icon-theme.json

第二步：写 package.json 声明 contributed icons

关键在contributes字段。VS Code 从 1.64 左右开始支持在扩展里通过contributes.icons定义自定义图标，你可以这么写：

{ "name": "custom-todo-icons", "displayName": "Custom Todo Icons", "version": "0.0.1", "engines": { "vscode": "^1.75.0" }, "categories": ["Themes"], "contributes": { "icons": { "custom-todo": { "description": "Custom TODO icon", "default": { "fontPath": "icons/todo.svg", "fontCharacter": "\\E001" } } } } }

等一下，这里如果完全按照 VS Code 扩展 API 的contributes.icons写，其实它不是用来给 Todo Tree 用的，这里要给 Todo Tree 用，更正统的方式是把图标作为文件路径在 Todo Tree 配置里直接引用。实际上 Todo Tree 支持在 tag 配置里写绝对路径的 SVG 文件，比如：

"todo-tree.general.tags": { "TODO": { "icon": "file:///c:/my-icons/todo.svg", "iconColor": "#22ab24" } }

而这种使用方式的前提是，图标本身是单色路径可染色的。所以"自制图标"最简洁的路径不是做 VS Code 扩展，而是直接写一个 SVG 文件，然后在 settings.json 里面用file://协议指向它。如果你想要把图标打包分发，再考虑做成扩展也不迟。

第三步：写一个可以被染色的 SVG

这个 SVG 不需要很复杂，关键是路径的 fill 或 stroke 必须写成currentColor。举个例子，一个简单的圆形对勾图标：

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16" width="16" height="16"> <path d="M8 1a7 7 0 1 0 0 14A7 7 0 0 0 8 1zm3.54 4.04l-4.5 4.5L5.46 7.96l-0.71.71 1.79 1.79 5.21-5.21-0.71-.71z" fill="currentColor" /> </svg>

核心就是把fill属性固定为currentColor。这样 Todo Tree 的iconColor配置才能在这个图标上生效，你后续想换颜色只需改配置，不用动 SVG 文件。

第四步：在 Todo Tree 配置里引用你的 SVG

"todo-tree.general.tags": { "TODO": { "icon": "file:///d:/dev/custom-icons/my-todo.svg", "iconColor": "#22ab24" } }

路径要写绝对路径，Windows 下盘符写法就是上面那样。这样配完，刷新窗口（Developer: Reload Window），侧边栏和编辑器内高亮处的图标都会变成你自制的样式。

4.3 第三档极客玩法：做一个完整的 VS Code 扩展分发图标

如果你有多个同事都要用同一套自定义图标，靠每个人各自在本机配置file://路径就太低效了。这时可以把图标打包成一个 VS Code 扩展，在项目内共享。实现思路是利用 VS Code 的扩展机制，在package.json里声明contributes.icons，然后在 Todo Tree 配置里引用你扩展提供的图标 ID，而不是文件路径。

一个可行的简化配置如下（假设你的扩展 ID 是my-org.custom-todo-icons）：

{ "contributes": { "icons": { "my-todo": { "description": "My custom TODO icon", "default": { "fontPath": "icons/custom-icon-set.woff", "fontCharacter": "\\E001" } } } } }

这里用的是字体图标方式。把 SVG 转成 woff 字体，再指定一个字符位置，VS Code 就会把它们作为产品图标使用。然后在 Todo Tree 配置里通过icon字段引用图标 ID：

"todo-tree.general.tags": { "TODO": { "icon": "my-todo", "iconColor": "#22ab24" } }

要注意的是，通过扩展贡献的图标，是否能被 Todo Tree 直接引用，取决于 Todo Tree 内部对 ThemeIcon 的处理方式。实测下来，部分版本的 Todo Tree 支持直接引用扩展图标 ID，部分版本只支持 codicon 或文件路径。所以如果你配置了发现不生效，最快的排查方法是切换到file://路径方式，保证能用再说。字体文件的转换可以使用任意 SVG 转字体工具，网上搜 "Icon Font Generator" 一大把，挑个支持 woff 导出的就行。

4.4 图标设计中的经验与注意

说了半天怎么做，最后聊聊我的图标设计心得，免得你花了半小时做出来一个丑得不忍直视的图标翻车。

第一，可视尺寸要饱满。VS Code 的 codicon 标准视觉尺寸是 16x16，SVG 画布建议 16x16，路径主体要占满 12~14px 的有效面积，不能画个小圆圈在正中间，否则渲染出来特别小，看都看不清。第二，图标语义要一眼懂。TODO 适合圆形、勾、时钟；FIXME 适合扳手、工具、警示三角；XXX 适合叉、红色感叹号。别把 TODO 画成一个文件夹——没人能一眼懂这个意思。第三，路径尽量简单。SVG 路径里 path 数量越少越好，节点越少越好，主要是因为染色的原因，复杂的渐变和 fill 规则在染了currentColor之后会变得很奇怪。能用一条 path 完成就别拆成 3 条。第四，写完记得测试两种状态：亮色主题和暗色主题下的显示效果。同一颜色在两种背景下观感差异很大，尤其浅色 iconColor 在暗色主题下可能一片模糊。

5. 常见问题与排查技巧实录

即使配置都按教程做完了，实际用起来总会碰到一些奇奇怪怪的问题。这里把我踩过坑和帮别人排查过的典型问题整理成一份速查表，再补充几个排查思路，这部分我认为才是最值钱的。

5.1 高频问题速查表

5.2 排查思路：从哪几层去看

如果遇到一个诡异问题，我建议你按"三层"来排查，不要瞎试。第一层是正则匹配层：确定你的注释文本本身能不能被 Todo Tree 的正则匹配到。最简单的验证方式：直接在全局搜索里搜TODO，看能不能搜到；如果搜到了但 Todo Tree 里没有，说明问题大概率出在正则的格式上，检查注释符号、标签之间是否有空格、标签是否拼写一致。第二层是配置生效层：确定你的 settings.json 语法正确、作用域正确。Todo Tree 的配置是支持工作区级覆盖的，如果项目里的.vscode/settings.json和用户级配置冲突，后加载的会覆盖前面的，排查时要把两个文件都看一遍。第三层是展示层：如果编译结果正确但 UI 上不对，那大概率是图标加载或主题颜色的问题。直接按 F1 输入 "Developer: Toggle Developer Tools"，打开控制台看看有没有针对todo-tree这个扩展的报错信息，有的话搜报错关键词比瞎猜快很多。

5.3 一个实际排查案例

讲个真事，某团队遇到过一个问题：同一个项目里，几个人装的 Todo Tree 显示结果不一样，A 同事能看到 120 个条目，B 同事只看到 80 个。一开始大家以为是谁的版本没更新，后来发现不是版本问题——B 同事的.vscode/settings.json里自己加过一段配置，把excludeGlobs写成了只排除node_modules，但他没有意识到这个配置会覆盖用户级设置里的 dist 和 build 排除项，导致 dist 里的编译产物被扫进来，反而更多才对…… 等一下，这里我举的例子和问题反了。实际这个案例里是 B 同事多加了**/dist/**到 exclude，但漏了**/test/**，而 test 目录里有大量 xxx.spec.ts 文件中带 TODO 注释。A 同事的用户级配置里把test目录也排除了，所以 B 同事多看到了 test 目录下的一个条目。这个案例的关键点在于：Todo Tree 的配置优先级是工作区 > 用户，工作区的 excludeGlobs 不会继承用户配置，而是整体覆盖。如果团队有统一标准，建议通过项目级.vscode/settings.json全量声明一次，而不是依赖每个人的本地配置。

5.4 让 Todo Tree 更强大的三个高阶技巧

日常用熟之后，三个高阶技巧能进一步把它的价值放大。

技巧一：把 Todo Tree 嵌入到工作流里。利用任务系统，在你 git commit 之前自动扫描一遍 TODO 清单，如果发现新的 FIXME 或者 XXX 就提示确认。具体做法可以借助 VS Code Tasks + 脚本，但更多人的做法是给 CI 加一条静态检查任务：把grep -r "TODO"的结果输出到一个告警文件，供人工 review。代码提交前自动感知"你正在带着债务上车"，很多问题就能消灭在早期。

技巧二：和 Git 集成判断债务归属。配合 Git Lens 或内置的 Git blame，你可以在 Todo Tree 里点击某条 TODO，切换出来看看这条注释是哪次提交加进去的，谁加的，代码当时是什么状态。如果你是团队组长，每周清点一次本周新增的 TODO/FIXME，找对应的人聊一句"这个注释你打算什么时候处理"，长期坚持下来，项目里的临时债务会少非常多。

技巧三：为自己维护"今日待清理"清单。在每天开始写代码之前，先打开 Todo Tree，审视一遍所有条目，把今天要处理的 3 到 5 个高优先级条目在心里排个序。写完代码以后没事刷一遍侧边栏，如果发现某个 FIXME 的数字比昨天少了，会特别爽。这种良性反馈会让你逐渐养成"留注释有成本，删注释有成就感"的习惯。

最后再分享一个小技巧

我自己用下来最上瘾的一个操作是：把 TODO 注释和标签着色绑定在一起做"项目体检"。每个月末尾，把 Todo Tree 视图截图，对比月初的截图，一眼看出哪个模块的债务没减少，哪个模块的遗留注释在慢慢变少。配合自己定义的HACK和TEMP标签，清掉一行注释发个小版本的时刻，是真的有一种"代码又干净了"的踏实感。

如果你只是一个刚开始使用 IDE 的新手，不要想着一口气把所有配置都配齐，先从默认配置开始用一周，感受一下侧边栏里那棵树怎么长出来的；再用第二周，开始定义自己团队的标签规范；第三周，再考虑折腾自制图标。这是一条循序渐进的路，也和所有工程化工具的规律一致——工具是放大器，你先有清晰的注释意识，才能放大出真正的效率。