AI替代软件战略（一）：从 CCleaner 到 MCP 架构重构 —— TigerCleaner 的工程实践
一、背景：工具软件正在被“吸收”，而不是升级
在 PC 时代，CCleaner 代表了一类非常典型的软件：
- 清理垃圾文件
- 修复系统问题（Fix glitches）
- 检测软件漏洞 / 过期版本
- 提供一键优化
这些工具曾经是“装机必备”。
但今天，在 AI + Vibe Coding 时代，它们正在快速失去独立存在的必要性。
核心原因只有一句话：
工具软件 ≠ 产品 工具软件 = 可被调用的能力二、从需求文档看本质：TigerCleaner 的设计思路
在这份 TigerCleaner 需求中，有一个非常关键的设计原则：
“以规则为中心 + 安全优先 + 用户确认”
这其实已经天然脱离了传统工具软件模式，而进入：
规则驱动系统（Rule-driven system）TigerCleaner 的核心拆解
根据需求，可以抽象为四个核心模块：
1. Rule Engine（规则引擎） 2. Scanner（扫描器） 3. Cleaner（执行器） 4. Safety Guard（安全控制）关键设计差异（对比 CCleaner）
| 维度 | CCleaner | TigerCleaner |
|---|---|---|
| 操作方式 | UI点击 | 规则驱动 |
| 安全策略 | 隐式 | 显式路径限制 |
| 删除控制 | 一键 | 必须确认 |
| 扩展性 | 低 | JSON规则 |
| 架构 | 软件 | 能力系统 |
👉 结论：
TigerCleaner 不是 CCleaner 的替代品 而是 CCleaner 的“结构重构”三、Fix glitches 的工程实现（去“玄学化”）
传统工具里的 “Fix glitches” 往往是黑盒。
TigerCleaner 的做法是：
Fix glitches = 可验证的 Health Check + 可控的 Fix Action可实现的 Fix 类型
1. 临时目录异常（过大 / 堆积） 2. 浏览器缓存损坏 3. WebView2 / 自动化测试缓存 4. 崩溃 dump 文件堆积 5. 启动项异常 6. 系统服务异常架构设计
HealthCheck → 发现问题 FixAction → 修复问题C# 实现（核心模型）
public interface IHealthCheck { string Name { get; } Task<HealthIssue?> CheckAsync(); } public interface IFixAction { Task<FixResult> FixAsync(HealthIssue issue, bool dryRun); }示例：Temp 目录异常
public class TempHealthCheck : IHealthCheck { public string Name => "Temp Size Check"; public Task<HealthIssue?> CheckAsync() { var temp = Path.GetTempPath(); long size = Directory.EnumerateFiles(temp, "*", SearchOption.AllDirectories) .Select(f => new FileInfo(f).Length) .Sum(); if (size > 1024 * 1024 * 1024) { return Task.FromResult<HealthIssue?>(new HealthIssue( "TEMP_TOO_LARGE", "Temp folder too large", "Recommend cleaning" )); } return Task.FromResult<HealthIssue?>(null); } }👉 关键点：
Fix glitches ≠ 自动修复 Fix glitches = 可解释 + 可回滚 + 可控四、漏洞扫描：从“杀毒”转向“版本风险检测”
TigerCleaner 明确：
不做完整 CVE 库，仅做本地规则扫描
这是一个非常正确的工程决策。
实际实现方式
漏洞扫描 = 1. 获取已安装软件 2. 获取版本 3. 和规则库对比 4. 输出风险示例规则（JSON）
[ { "product": "Google Chrome", "safeVersion": "124.0.6367.207", "severity": "High" } ]C# 核心扫描逻辑
if (VersionHelper.IsOlderThan(app.Version, rule.SafeVersion)) { findings.Add(new VulnerabilityFinding { Product = app.Name, Severity = rule.Severity }); }👉 本质：
漏洞扫描 ≠ 安全软件 漏洞扫描 = 版本合规检测五、关键升级：从 Agent 到 MCP 化
TigerCleaner 需求中有一个非常重要的点：
Core / UI / CLI 不依赖 MCP，MCP 是独立进程
这实际上定义了一个非常先进的架构：
架构分层
Core（纯业务逻辑） UI / CLI（用户入口） MCP（AI入口）MCP 的作用
不是执行清理 而是提供能力接口示例 MCP Tool
scan_health_issues scan_vulnerabilities list_rules get_data_path为什么不允许 MCP 删除文件？
需求明确：
不提供一键删除接口
这是一个关键安全策略：
AI 不应直接修改用户系统👉 结论：
MCP = 能力查询 + 辅助决策 UI/CLI = 真正执行六、OpenClaw / MCP 生态：工具软件的终局
类似 OpenClaw 这样的系统正在形成新的软件生态：
传统模式
打开 CCleaner → 点击扫描 → 点击清理MCP 模式
用户：系统很卡，帮我清理一下 AI：调用 scan → 分析 → 给出建议 → 用户确认 → 执行工具角色变化
CCleaner → 应用 TigerCleaner → MCP Tool多工具协同
Cleaner + Browser + Test + DevOps👉 本质变化：
软件 → 能力节点七、为什么这个方向更适合你
结合你的背景（MARS + 自动化测试），TigerCleaner 可以升级为：
Test Environment Cleaner MCP特有价值
清理 Playwright / Selenium cache 清理 WebView2 数据 清理测试日志 清理截图 清理 dump 文件这不是 CCleaner 能做的，而是：
企业级测试环境治理工具八、关键结论
1️⃣ CCleaner 类软件一定会被替代
因为：
规则清晰 + 可自动化 + 无复杂交互2️⃣ 替代方式不是“重写软件”
而是：
拆成 MCP 能力3️⃣ TigerCleaner 的核心价值
不是 UI，而是：
规则引擎 + 安全模型 + 可控执行4️⃣ MCP 是未来入口
未来用户不会：
打开工具软件而是：
让 AI 调用能力九、源码地址
tigerStl/TigerCClean
如果大家有兴趣一起将工具软件用vibe coding重构，不如一起加速软件的世界的重构。
运行界面：