Solo Unicorn我怎么用 AI 管理三个产品的技术债 — 一人多产品线的生存指南
我怎么用 AI 管理三个产品的技术债 — 一人多产品线的生存指南
2025 年 8 月的一个周五下午，ArkTop AI 的生产环境突然报了一连串 500 错误。排查了两个小时，发现原因是一个 Python 依赖包（pydantic）从 1.x 自动升级到了 2.0，API 不向后兼容。我没锁版本号。
修完 ArkTop AI，我下意识去查了 JewelFlow 的依赖。同样的问题，只是还没触发——因为 JewelFlow 那周没部署。
那天晚上我算了一笔账：ArkTop AI 用 Python + FastAPI，JewelFlow 用 TypeScript + Next.js，一人独角兽俱乐部的 Bot 系统用 Python + Discord.py。三个技术栈，三套依赖树，加起来超过 400 个直接依赖和几千个间接依赖。而管理这些的人只有我一个。
那个周末，我开始搭一套用 AI 驱动的技术债管理系统。跑了六个月，这篇文章把具体做法、工具选型和踩过的坑完整记录下来。
背景：一人多产品线，技术债是定时炸弹
技术债不是大公司的专利。一人公司因为没有 code review 环节、没有 QA 流程、开发节奏快，积累技术债的速度反而更快。
我的三个产品的技术债主要分三类：
依赖债：过时的包版本、已知漏洞未修复、版本锁定不规范。这是最危险的一类——你不主动管理，它就在某天给你一个惊喜。
代码债：早期赶功能时留下的 hack、重复代码、缺失的类型标注、过于复杂的函数。不影响当前功能，但每次改东西的时间成本在递增。
架构债：模块耦合度高、测试覆盖率不足、部署流程手动步骤多。这类债还起来最慢，但长期影响最大。
三个产品同时积累这三种债。如果全靠手动管理，每周光看依赖更新和代码质量就得花 8-10 小时。这还不算实际修复的时间。
三条原则
原则一：依赖管理 100% 自动化，零人工干预
依赖更新是最适合自动化的技术债管理环节——规则明确、频率高、手动做极其无聊。
我用 Renovate（完全免费）做自动化依赖更新。配置方式：
- patch 和 minor 版本：自动创建 PR，CI 通过后自动合并。我不看，不管。
- major 版本：自动创建 PR，但不自动合并。我每周五花 30 分钟集中处理三个项目的 major 更新。
- 安全漏洞修复：无论版本级别，立即创建 PR 并标记为高优先。
为什么选 Renovate 而不是 Dependabot？两个都免费，但 Renovate 支持 monorepo 和跨仓库的统一配置。我用一个 renovate.json 管三个项目的更新策略，Dependabot 做不到。
这套配置跑起来后，依赖债基本变成了"被动消化"模式——我不用主动去检查哪个包过时了，系统自动帮我保持在最新稳定版本。
原则二：AI Code Review 补上"第二双眼睛"的缺失
一人公司最大的代码质量风险是没有 code review。你自己写的代码自己合并，盲区是系统性的。
我用 CodeRabbit 做 AI code review。它是每个 PR 自动触发的——包括我自己写的代码和 Renovate 创建的依赖更新 PR。
CodeRabbit 对开源仓库免费，私有仓库 Pro 计划 $24/用户/月。我三个产品都是私有仓库，但只有一个开发者（我），所以月费 $24。
实际体验：
它擅长的：发现明显的 bug（空指针、未处理的异常）、标注代码风格不一致、检测依赖更新后的 breaking change、指出缺失的测试用例。大约 60% 的评论是有价值的。
它不擅长的：业务逻辑层面的判断。比如 JewelFlow 的定价计算逻辑改了，CodeRabbit 能看到代码变了，但不知道新逻辑是否符合商业需求。这部分永远是我自己的责任。
一个意外收获：CodeRabbit 的 review 记录本身变成了一份活文档。三个月后当我回头改某个模块时，PR 上的 AI 评论帮我快速回忆了当时的设计决策和潜在风险。
原则三：集中还债，不要边开发边修
技术债修复如果混在日常开发里，永远排不上优先级。我的做法是每两周固定一个"还债日"——整天不写新功能，只处理技术债。
还债日的流程：
- 跑
ruff check（Python 项目）和eslint（TypeScript 项目），收集所有 warning - 用 Claude Code 做自动化重构——它能直接读代码、改代码、跑测试。典型任务：拆分超过 200 行的函数、补类型标注、消除重复代码
- 处理积压的 major 版本依赖更新
- 更新测试用例，确保覆盖率不低于 70%
Claude Code 在重构环节的效率提升是最显著的。以前手动重构一个复杂函数需要 1-2 小时（改代码 + 改测试 + 验证），现在 Claude Code 能在 10-15 分钟内完成初版重构，我花 15-20 分钟做 review 和微调。一个还债日能处理的工作量大约是以前的 3 倍。
工具栈详解
| 场景 | 工具 | 月费 | 为什么选 |
|---|---|---|---|
| 依赖自动更新 | Renovate | $0 | 免费，支持跨仓库统一配置，自动创建 PR |
| AI Code Review | CodeRabbit Pro | $24/月 | 每个 PR 自动 review，私有仓库支持好 |
| 代码重构 + 技术债修复 | Claude Code（Max 计划） | ~$20/月均摊 | 直接读代码改代码跑测试，重构效率提升 3 倍 |
| 静态分析（Python） | ruff | $0 | 速度快，规则全，替代 flake8 + black |
| 静态分析（TypeScript） | eslint + prettier | $0 | 社区标准 |
| 安全漏洞扫描 | Snyk（免费计划） | $0 | 200 次/月开源测试够用，补充 Renovate 的安全检测 |
| CI/CD | GitHub Actions | $0（免费额度） | 三个项目的 CI 全在上面跑 |
| 合计 | ~$44/月 |
为什么没选更重型的方案？Qodo（原 CodiumAI）和 Zencoder 功能更多，但月费 $50-$100/用户，对一个人管三个小项目来说投入产出不合理。当前这套组合覆盖了我 90% 的需求。
实际数据
系统从 2025 年 9 月上线到现在，六个月的数据：
依赖管理：
- Renovate 自动创建的 PR 总数：287 个
- 其中自动合并（patch/minor + CI pass）：241 个（84%）
- 需要我手动处理的 major 更新：46 个
- 安全漏洞修复 PR：12 个（全部在 24 小时内合并）
- 六个月内零依赖相关的生产事故
代码质量：
- CodeRabbit 提出的 review 评论总数：约 480 条
- 我采纳并修改的：约 290 条（60%）
- 三个项目的平均测试覆盖率：从 52% 提升到 74%
- 平均函数行数：从 45 行降到 28 行
时间投入：
- 技术债管理的周均时间：从 8-10 小时降到 3 小时
- 还债日效率：每次处理 12-18 个技术债 item（以前是 4-6 个）
生产稳定性：
- 依赖相关生产事故：从上线前 6 个月的 4 次降到 0 次
- 部署回滚次数：从月均 1.5 次降到 0.3 次
踩坑经验
坑一：Renovate 自动合并差点引入 breaking change
有一次 Renovate 把一个 minor 版本更新（某 npm 包从 4.2.1 到 4.3.0）自动合并了，CI 测试全绿。但这个包修改了一个方法的默认参数，导致 JewelFlow 的报表生成结果和之前不一致。CI 测试没覆盖到这个边界场景。
教训：自动合并的前提是测试覆盖率足够高。我现在的规则是，测试覆盖率低于 60% 的模块相关的依赖更新不走自动合并。
坑二：CodeRabbit 的误报让人疲劳
上线第一个月，CodeRabbit 平均每个 PR 给 15-20 条评论，其中一半以上是风格建议（变量命名、注释格式）。Review 疲劳很快出现——我开始跳过 AI 评论，等于工具白装了。
解决方式：在 CodeRabbit 配置里把 severity 调到 medium 以上，只保留 bug、安全、性能相关的评论，风格类的全部静音。评论数降到每个 PR 4-6 条，每条都值得看。
坑三：Claude Code 重构时偶尔改变业务逻辑
让 Claude Code 拆分一个 180 行的函数时，它"顺便"优化了一段价格计算逻辑——把四舍五入改成了银行家舍入。如果我没仔细看 diff，这个变更会直接影响客户账单。
教训：AI 重构后必须逐行看 diff，尤其是涉及金额计算、权限判断、数据转换的代码。这是"人做主"的底线。
给想开始的人的建议
第一步：先装 Renovate。 10 分钟配置，立刻见效。把依赖管理这个最无聊但最危险的任务自动化掉。
第二步：给你的项目装 CodeRabbit。 如果是开源项目，完全免费。私有项目 $24/月。先用一个月，看 AI 评论里有多少条是你自己 review 时会漏掉的——这就是它的价值。
第三步：每两周固定一个还债日。 不要等到系统出问题才想起来修。技术债和金融债一样，利滚利。定期小额偿还永远比积累到崩溃后一次性还要划算。
写在最后
一人公司管多个产品的技术债，本质上是一个"注意力分配"问题。你的注意力是稀缺资源，应该花在业务决策和产品方向上，而不是花在检查依赖版本和修复 lint warning 上。
$44/月，三个产品的技术债从失控状态变成了可预测、可管理的常态。不是说技术债消失了——它永远不会消失——而是我不再被它追着跑了。
一人独角兽俱乐部里有好几个做独立产品的成员，最怕的都不是没用户，而是代码烂到自己都不敢碰。技术债管理不性感，但它是产品能长期活下来的基础。
你的产品现在有多少技术债？你有固定的还债节奏吗？