实践：技术栈审计
技术栈审计回答三个问题：我们的依赖图是否健康？我们是否在积累技术债务？接下来应该按什么顺序升级什么？
本实践使用 SpecForge 的流程 H 工具运行完整的技术栈健康审计，并构建一个可执行的升级计划。
第 1 步 — 运行完整技术栈审计
提示词：
审计项目 proj_abc123 的技术栈预期结果：
技术栈健康评分：71/100
依赖状态：
up_to_date（最新）： 34 个包 ✅
outdated（过时）： 12 个包 ⚠️
vulnerable（有漏洞）： 3 个包 🚨
unmaintained（无维护）： 1 个包 ❌
紧急（立即修复）：
- lodash 4.17.20 → CVE-2021-23337（原型污染）
- axios 0.21.1 → CVE-2023-45857（CSRF 漏洞）
- follow-redirects 1.14.7 → CVE-2023-26159
高优先级（下一个冲刺）：
- typescript 4.9.5 → 5.7.2（落后 13 个小版本）
- vitest 0.34.0 → 3.1.0（落后一个主版本）
- express 4.18.0 → 5.0.1（主版本可用）
中优先级（本季度）：
- 8 个包落后 1–3 个小版本第 2 步 — 检测弃用的 API
提示词：
检测项目 proj_abc123 中的弃用 API这会扫描源文件（无需网络）中弃用的 API 用法：
发现弃用 API 用法：
src/middleware/session.ts:14
express-session 密钥为字符串 — 已弃用，请使用密钥数组
修复工作量：0.5 小时
src/utils/crypto.ts:8
crypto.createCipher — 自 Node 10 起弃用，请使用 createCipheriv
安全风险：高
修复工作量：2 小时
src/config/database.ts:22
mongoose.connect 回调 — 在 Mongoose 7 中弃用，请使用 Promise
修复工作量：1 小时
总技术债务：约 3.5 小时第 3 步 — 规划优先升级
对于每个紧急或高优先级项目，生成升级计划：
提示词：
为项目 proj_abc123 规划 axios 0.21.1 升级到最新稳定版预期结果：
markdown
## Axios 升级计划：0.21.1 → 1.7.9
### 破坏性变更
- AbortController 替代 CancelToken（在 v0.22 中弃用）
- POST 的默认 Content-Type 更改为 application/json（无需更改）
- TypeScript 定义中的响应类型已更改
### 迁移步骤
1. 更新 package.json：axios ^1.7.9
2. 替换所有 CancelToken 用法：
- 查找：axios.CancelToken.source()
- 替换：AbortController / AbortSignal
3. 更新 TypeScript 类型（AxiosResponse 泛型已更改）
4. 运行测试套件 — axios 拦截器向后兼容
### 受影响文件（5 个）：
- src/api/client.ts（第 34、67 行使用 CancelToken）
- src/api/interceptors.ts（第 89 行取消 token）
- src/utils/request.ts（超时处理）
- tests/api/client.test.ts（需要更新 mock）
- tests/api/interceptors.test.ts（需要更新 mock）
### 估算工作量：3 小时
### 回滚：固定到 0.27.2（最后稳定的 0.x 版本）第 4 步 — 为主要升级创建规格
对于影响多个文件的主版本升级，创建适当的规格：
提示词：
为项目 proj_abc123 中从 Express 4.18 升级到 5.0 创建规格这给你：
- 升级的验收标准（所有端点仍然正常工作，无破坏性行为）
- 迁移计划
- 测试覆盖要求（升级前后的比较）
第 5 步 — 数据治理检查
如果项目处理用户数据：
提示词：
为项目 proj_abc123 运行数据治理检查预期结果：
PII 检测：
规格 SPEC-003（用户注册）：邮箱、姓名、电话 — 需要保留策略
规格 SPEC-007（分析）：存储 IP 地址 — 需要 GDPR 正当利益
GDPR 合规性：
✅ 数据最小化 — 规格收集最少的 PII
⚠️ SPEC-003 中 user.email 缺少保留策略
⚠️ 任何规格中未指定删除权
❌ 不存在隐私通知规格
建议：
1. 创建 GDPR 合规规格（删除权、数据导出）
2. 向 SPEC-003 添加保留策略
3. 生成隐私通知模板第 6 步 — 优先处理修复待办事项
提示词：
为项目 proj_abc123 中技术栈审计发现的前 3 个安全漏洞创建规格SpecForge 为每个 CVE 修复创建规格，并正确界定验收标准。
第 7 步 — 跟踪进度
定期安排审计并随时间跟踪 StackHealthScore：
提示词：
审计项目 proj_abc123 的技术栈目标：StackHealthScore ≥ 85，零 vulnerable（有漏洞）或 unmaintained（无维护）包。
审计频率建议
| 触发条件 | 行动 |
|---|---|
| 每月 | audit_stack — 完整依赖扫描 |
| 每季度 | detect_deprecations — 源代码扫描 |
| 发布前 | audit_stack + 对支付/身份验证规格进行 security_check |
| 事故后 | capture_learning + 更新受影响的规格 |
| 主要 Node.js LTS 版本 | detect_deprecations + 对受影响包进行 plan_upgrade |
常见发现与修复
| 发现 | 工具 | 典型修复时间 |
|---|---|---|
| 直接依赖中的 CVE | plan_upgrade | 1–4 小时 |
| 间接依赖中的 CVE | plan_upgrade + 手动覆盖 | 2–8 小时 |
| 源代码中的弃用 API | detect_deprecations | 每个文件 0.5–3 小时 |
| 无维护的包 | 替换为有维护的 fork | 4–16 小时 |
| 落后主版本 | plan_upgrade | 2–12 小时 |