工具多了以后更容易乱#

一个助手能调用很多工具，听起来很强。不过如果没有触发规则，它很容易出现两种问题。

第一种是不用。明明有测试生成、安全审计、日志分析、文档生成、API 测试、前端设计这些能力，实际工作时还是只靠通用对话硬想。

第二种是乱用。遇到一个小问题就启动重型流程，写一段文档也去拉满项目管理，查一个文件却调用外部搜索。工具越多，误触发的成本也越高。

所以我后来不再只整理名字，而是给每个能力补三项信息：

• 这个能力解决哪类问题。
• 什么时候应该自动触发。
• 什么时候不该触发。

没有这三条，工具清单只是收藏夹。

流程类能力应该优先#

清单里最前面是流程类能力：头脑风暴、测试驱动、系统调试、写计划、执行计划、完成前验证、工作区隔离、并行子代理、编写 skill、代码审查等。

这类能力不绑定某个技术栈，更多是在规定做事顺序。

比如遇到 bug，先进入系统调试流程；要实现功能，先考虑测试驱动；要声称完成，先做完成前验证；要并行多人工作，先考虑隔离工作空间和分派责任。

这比具体命令更基础。很多失败其实出在顺序上：还没理解问题就改代码，还没验证就宣布完成，还没隔离就并行修改。

所以我会把这类 skill 放在前面：先决定怎么做，再决定调用哪个具体工具。

代码质量类能力要按风险触发#

代码质量类包括代码审查、安全审计、重构建议、依赖审计、格式和 lint 修复等。

这类能力不该每次都全量运行。更合理的触发方式是按风险：

• 改动涉及权限、密钥、网络、文件系统时，触发安全审计。
• 改动跨模块或共享接口时，触发代码审查。
• 代码重复、函数膨胀、职责不清时，触发重构建议。
• 依赖升级或构建异常时，触发依赖审计。
• 提交前再做格式和 lint 检查。

这样不会让每个小改动都背上重流程，又能在风险明显上升时启用合适工具。

项目管理类能力要服务交付#

Git 工作流、提交、推送、PR、变更日志、CI 配置，这些能力很容易被当成“最后一步”。

但如果把它们放进能力清单，就能更早提醒自己：这次工作最后要交付什么？

是一个草稿？一个补丁？一个 PR？一个发布包？一个 changelog？一个 CI 工作流？

交付形态不同，工作方式也不同。比如博客草稿需要安全扫描和构建验证；代码补丁需要测试和 diff 审查；公开发布需要许可证、隐私、README 和 release note。

项目管理类能力不光负责敲 git 命令，也会提前提醒我这次到底要交付什么。

文档类能力要防止“写完没人能用”#

文档类能力包括 README、中文文档、DOCX、PPTX、官方文档查询等。

代码能跑只是第一层。别人要使用，自己未来要回看，都需要文档。尤其是本地工具和实验项目，如果不写清：

• 入口命令是什么。
• 配置示例在哪里。
• 哪些文件不该提交。
• 验证命令怎么跑。
• 常见失败怎么判断。

那项目很快就会变成“只有当时的我知道怎么用”。

文档类 skill 的触发条件应该很明确：一旦项目要公开、交付、复用或交给别人，文档就该一起补上。

开发辅助类能力要尽量局部#

开发辅助类能力很多：API 测试、日志分析、性能分析、数据库迁移、环境变量管理、错误翻译、数据结构映射、国际化、前端设计。

这些工具都好用，但我一般只在对应问题出现时再打开：

• 有 OpenAPI 或接口失败，再用 API 测试。
• 有真实日志，再做日志分析。
• 有慢路径证据，再做性能分析。
• 有 schema 变更，再做迁移。
• 有前端体验任务，再进入设计约束。

局部触发能降低噪声，也能让工具输出更具体。上下文不够时硬开辅助工具，出来的结果大多也帮不上具体忙。

MCP 插件是外部能力入口#

清单里也有 MCP 插件，例如查库或框架文档、官方文档、浏览器自动化、文件系统操作。

这些插件能连接外部世界，但成本更高，权限也更敏感。

所以我会把插件入口放得更靠后，先确认确实需要外部能力：

• 需要最新文档时再查外部文档。
• 需要真实页面行为时再用浏览器自动化。
• 能用本地文件解决的，不必先查网络。
• 涉及文件系统操作时要明确路径和限制。

这和博客素材扫描一样：能从本地公开仓库或脱敏摘要得到的素材，就不必把私有原文搬进正文。

清单应该随工作流更新#

能力清单不是一次性文档。随着项目增加、工具变更、旧工具失效，它会慢慢过期。

一个有用的清单至少要维护几类信息：

• 能力名称。
• 能力分类。
• 触发条件。
• 禁用或谨慎使用场景。
• 典型输入输出。
• 验证方式。

后来我真正会回看的，也基本是触发条件和验证方式，而不是名字本身。

这张表后来也影响了博客栏目#

这件事也反过来影响博客平台。

现在这个博客已经不只用来放文章了，我还会用它从本地项目和记忆里找可写素材。候选扫描、草稿审计、安全扫描、封面检查、构建验证，说白了也是一组能力。

它们同样需要路由：

• 发现素材时跑候选扫描。
• 公开源文章必须填 source。
• 本地素材必须做脱敏和抽象。
• 长文必须有本地封面。
• 发布前必须跑安全扫描和生产草稿泄漏检查。

换句话说，博客平台本身也需要能力清单。否则写作流程会靠记忆推进，迟早漏步骤。

后来我主要看触发条件#

工具越多，我越少按名字去记。

现在我更关心的是：遇到某类任务时先叫谁、做到哪一步停下、最后用什么方式确认结果。对我自己的本地助手来说，这比单纯攒更多 skill 有用得多。