工具优化的目标不是收集更多插件，而是减少切换、减少重复配置、缩短从问题到证据的时间。一个成熟的工作流应该能在几分钟内回答：项目如何构建、如何运行、如何检查、如何调试，以及结果如何记录。
本文将多篇工具笔记重组为流程建议。编辑器插件、快捷键和扩展安装方式可能变化，请以当前版本和组织安全策略为准。
1. 先固定项目入口
在编辑器里配置快捷键和主题之前，先确保项目有稳定的入口：
configure
build
test
run
debug
format
lint
CMake 和 CMake Tools 的历史记录可以用于建立这些入口。IDE 面板是便利层，项目本身仍应能通过命令行完成构建和测试；否则换一台机器就无法复现。
2. 编辑器只保留“有用”的自动化
VS Code 基础记录、快捷键 和 工作台布局 适合整理个人操作习惯。建议按用途分组：
- 编辑与导航：跳转、重命名、符号搜索；
- 质量：格式化、静态检查、测试；
- 构建：CMake、编译器和调试配置；
- 文档：Graphviz、Markdown、知识图谱；
- 协作：Git 和 Issue 工具。
扩展管理 和 自定义语言/提示 提醒我们：扩展也会带来供应链、权限和版本兼容成本。不要让关键构建逻辑只能通过某个未锁定版本的扩展运行。
3. 把质量工具接进同一循环
推荐的轻量循环：
编辑 → 格式化 → 编译 → 单元测试 → 静态检查 → 调试/运行
静态分析 和 Valgrind 不需要每次都全量运行，但应该有明确的触发时机：提交前运行快速检查，合并前运行完整测试，发布前运行更重的动态检查。
4. 图表和文档是理解的输出
Graphviz 适合把调用关系、模块边界或数据流变成可审查的图。图不是装饰：如果节点、箭头和图例无法解释，读者只会得到另一张难维护的图。
Graphify 和 VitePress 指南 提醒我们，知识库和文档站也需要版本、导航和可检索性。工具生成的文档应保留来源和更新时间，不要把自动摘要误当作最终结论。
5. 一次故障排查的最短路径
现象 → 最小复现 → 版本/环境 → 构建日志 → 调试器 → 修复验证
每一步都保存命令、输出和结论。这样可以避免“重新试了很多命令，但不知道哪一条改变了结果”。当同类问题再次出现时，故障记录和自动化检查会比记忆中的快捷键更有价值。
工具选择的四个问题
- 它解决的是高频痛点，还是只增加界面？
- 配置能否提交、审查和复现？
- 它在无 GUI、无网络或受限权限下能否工作？
- 出错时能否给出可理解的诊断，而不是只弹一个按钮？
把答案写进团队的 CONTRIBUTING 或开发文档，工具链才会从个人技巧变成可交接的工程能力。