这是「华为云码道实战」系列的第七篇。前六篇走了成长攻略、AI 智能体观点、安全审计、性能优化、容器化 CI/CD、数据分析。这一篇回到一个每个开发者都会遇到的场景——接手一个祖传项目，不知道坑在哪、有多深、先修什么。

传统的做法是凭经验翻代码、列个 TODO、然后淹没在日常需求里。这次我把一个 506 行的 Flask 订单服务丢给华为云码道的技术债盘点专家，让它做一次系统性体检——结果挖出 58 项技术债，其中 18 项严重。

一、造一个"够真实"的祖传项目

真实的技术债不是"故意写错的代码"，而是快速迭代中自然积累的妥协。我按这个思路造了一个 Flask 订单服务，7 个文件、506 行：

tech-debt-demo/
├── app.py            # 路由层（142行）
├── models.py         # 数据模型（122行）
├── services.py       # 业务逻辑（120行）
├── utils.py          # 工具函数（78行）
├── config.py         # 配置（32行）
├── requirements.txt  # 依赖（10行）
└── tests/
    └── test_placeholder.py  # 占位测试（2行）

这个项目看起来能跑，但每一层都埋了"祖传"才会有的债：

• config.py：密钥、数据库密码、支付密钥全部硬编码在源码里
• models.py：所有 SQL 都是字符串拼接，登录密码明文比对
• services.py：短信发送函数复制了三份（v1/v2/v3），密码用 MD5 哈希，折扣计算 10 级 if-elif
• app.py：管理接口无认证，生产开 DEBUG 模式
• requirements.txt：Flask 1.1.4、requests 2.20.0、cryptography 2.3——全是 5-8 年前的版本
• tests/：只有一个 assert True 的占位测试

这些不是"刻意造的 bug"，而是每个快速上线的项目都可能长成的样子。

二、把项目交给技术债盘点专家

我没有自己逐行审，而是调用了华为云码道的技术债盘点专家（tech-debt）子智能体。给它一句话需求：

"对 /workspace/tech-debt-demo/ 做系统性技术债盘点，产出优先级债务清单。"

它自己读完了全部源码，从 7 个维度逐文件逐行分析，最后产出一个 40KB 的结构化报告。下面每一个数字都是它真实盘出来的。

三、盘点结果：58 项技术债，7 个维度

3.1 总体概况

按严重程度分布：

🔴 严重  18 项 (31%)  ████████████████████   ← 可被直接利用
🟠 高    19 项 (33%)  █████████████████████
🟡 中    18 项 (31%)  ████████████████████
🟢 低     3 项 (5%)   ███

总预估工作量：约 175 人天。一个 506 行的项目，还清技术债要将近一个人年——这就是"祖传项目"的真实代价。

3.2 安全债最触目惊心

20 项安全债里，最致命的几个：

盘点专家给了一个很直接的判断：该项目处于"可被立即入侵"的状态。这不是夸张——DEBUG 模式 + 无认证管理接口 + SQL 注入，任何一个就足以拿 shell。

3.3 依赖债：全是"化石级"版本

Flask==1.1.4        (2021年，当前 3.0.x)
Werkzeug==1.0.1     (2020年)
requests==2.20.0    (2018年，有 CVE-2023-32681)
PyJWT==1.5.0        (2018年)
cryptography==2.3   (2018年，多个 OpenSSL CVE)

最老的是 2018 年的依赖，距现在 8 年。requests 和 cryptography 都有已知 CVE。

四、TOP 10 最严重债务

技术债盘点专家给每项债务算了优先级分数（严重度×20 + 影响度×10 - 成本×5），排出了 TOP 10：

一个值得注意的规律：TOP 10 里大部分修复成本是"低"。SQL 注入改参数化查询、MD5 换 bcrypt、DEBUG 关掉——每个都是几行代码的事。最危险的技术债往往不是最难修的，难的是"不知道它在那儿"。

五、4 阶段修复路线图

技术债盘点专家没有只给一个清单就完事，而是排了一个分阶段修复路线图：

🔴 第一阶段：紧急安全止血（1-2 周，~20 人天，25 项）

目标：消除可被直接利用的入侵风险

• 修复全部 SQL 注入（参数化查询，涉及 models.py 全部 12 个方法）
• 关闭 DEBUG，密钥移至环境变量
• /admin/* 加 JWT 认证
• MD5 → bcrypt，修复登录密码比对逻辑
• 升级有 CVE 的依赖
• 数据库连接池化

🟠 第二阶段：核心质量修复（1-2 月，~25 人天，27 项）

目标：建立测试与工程规范，消除数据一致性风险

• 编写核心业务测试，覆盖率 ≥ 70%
• 添加事务管理，修复订单创建中途失败的数据不一致
• 消除重复代码（send_sms 三版本、create_payment 四分支）
• 统一错误处理 + 日志框架
• 编写 README 和 API 文档

🟡 第三阶段：架构优化（3-6 月，~20 人天，6 项）

目标：分层重构，提升可维护性

• Model / Service / Controller 三层分离
• 应用工厂模式 + 依赖注入
• Dockerfile + CI/CD 流水线

🟢 第四阶段：持续治理（持续进行）

目标：建立技术债长效管理机制

• 每次迭代预留 15-20% 容量还债
• CI 集成安全扫描（bandit/safety）和覆盖率门禁
• 每季度技术债盘点更新

这份路线图的核心思想是：先止血、再治病、后养生。不是一次性还清 175 人天，而是按风险等级分批处理，每个阶段都有明确的目标和退出标准。

六、复盘：技术债盘点专家替我做了什么

回看整个过程，我作为"接手者"只做了一件事：把项目路径给它。它自己完成了：

506 行代码
    │
    ├─ 逐文件逐行扫描 → 58 项债务，每项精确定位到文件+行号
    ├─ 7 维度分类     → 安全/代码/运维/架构/文档/依赖/测试
    ├─ 优先级排序     → 严重度×20 + 影响度×10 - 成本×5
    ├─ 修复建议       → 每项都给了具体修法和预估成本
    └─ 路线图         → 4 阶段，从止血到持续治理

这和"让 AI 帮我 code review"有三个本质区别：

最让我意外的是它对依赖债和文档债的盘点。普通 code review 很少会去查 requirements.txt 里的版本有没有 CVE，也不会关心有没有 README——但这些恰恰是"祖传项目"最典型的债。

七、哪些地方它还没法替代人

公平起见，也有它做不了的事：

1. 业务上下文判断：它说"订单创建有数据不一致风险"，但这个接口现在还有人在用吗？调用频率多高？改了会不会影响下游？这需要人去确认。
2. 修复优先级的业务权衡：路线图按技术风险排了序，但业务方可能更关心"先修那个让用户投诉的 bug"——技术优先级和业务优先级需要对齐。
3. 组织层面的推进：盘点出来 175 人天，但怎么跟产品经理争取到 20% 的还债容量？这是技术管理问题，不是工具能解的。

所以准确定位是：技术债盘点专家是"诊断层"的超级加速器——它把"项目健康度"从模糊感觉变成了精确数字，但"治疗"和"健康管理"仍需要人来做。

八、结语

这一篇解决的是一个经常被忽视但代价最大的问题：技术债。

新功能开发是"赚的钱"，技术债是"欠的债"。很多团队只看前者不看后者，直到某天一个安全漏洞打爆线上、一个依赖冲突卡死部署、一个"上帝函数"改一行崩三处——才发现债已经还不起了。

华为云码道的技术债盘点专家，让"摸清家底"这件事的成本低到——一句话需求 + 一个项目路径。而摸清家底，是还债的第一步。

系列七篇，刚好覆盖了一个开发者的完整工作环： 成长 → 观点 → 安全 → 性能 → 部署 → 数据 → 技术债。 从"怎么用工具"到"怎么管项目"，从"写代码"到"还技术债"。下一份见。

本文所有盘点结果均由华为云码道技术债盘点专家（tech-debt）对 /workspace/tech-debt-demo/ 真实执行。完整报告见 tech_debt_report.json（40KB，58 项债务明细）。