如何评估

从仓库到城市

四步，全部在你自己的机器上完成。

1. 仓库本地目录，或一次 clone。
3. 读取目录、行数、分支、git 历史、import。
5. 本地扫描Trivy · gitleaks · 技术债规则。
7. 城市 + 报告建筑、街区、问题，还有一个评级。

在本地版本中，除了聊天，没有任何东西离开你的机器。

一栋建筑的解剖

一个装着代码的目录。九件事一眼就能看出来。

“复杂度”数的是什么

每个文件里的决策点数量，再按目录求和。一个快速的启发式，不是完整的圈复杂度。

export function settle(orders, rates) {  let total = 0;  for (const order of orders) {    if (!order.paid || order.voided) continue;    const rate = rates[order.currency];    while (order.items.length && rate) {      const item = order.items.pop();      switch (item.kind) {        case 'refund': total -= price(item, rate); break;        case 'fee':    total += fee(item, rate);   break;      }      try { audit(item); } catch (e) { report(e); }    }  }  return total;}

点击一个决策点把它去掉，就像你简化了代码一样，看看塔楼如何变矮。

switch 和 try 不计入，只数 if for while case catch && ||。

问题从哪里来

三台仪器。两台是通用工具，第三台只是几条规则，背后没有任何工具。

• Trivy

  读取锁文件与清单（npm、yarn、pnpm、pip、poetry、go.mod、Cargo、pom、gradle），Java 还会扫已构建的 jar，以及 Dockerfile、compose、Kubernetes 和 Terraform。

  产出漏洞与配置问题。严重级别沿用 Trivy 的判定。

• gitleaks

  读取工作区文件，使用默认规则集。

  产出疑似密钥，目前一律按高危计：尚未区分“很可能”和“存疑”，这会抬高风险值。只保留规则名和文件:行号。

• 技术债规则

  读取所有源码文件，加上 git 里的 commit 次数。

  产出TODO/FIXME/HACK/XXX = 低 · 超过 500 行 = 中 · 每行超过 0.25 个分支且文件超过 50 行 = 中 · 热点（commit 数 × 复杂度排在仓库前 5%）= 高。

• SARIF 报告

  读取你放进 .codemap/ 的 .sarif 文件：Snyk、Semgrep、CodeQL、ESLint、Checkov，以及任何能导出 SARIF 2.1.0 的工具。

  产出带 security-severity：算漏洞（≥ 9 严重，≥ 7 高，≥ 4 中）。不带：算技术债，error 为中，其余为低。工具中已抑制的结果不会进入。

四个严重级别

• 严重
• 高
• 中
• 低

热点

每个点都是 expressjs/express 的一个真实目录：越靠右，最近 12 个月改动越多；越靠上，逻辑越多。两者乘积最高的 5 % 会得到一根红色桅杆。

一栋建筑的风险

实时评级

这些滑块直接喂给产品自己的评分函数 —— 和控制台导入的是同一个模块。动手拖一拖。

四种视角

同一座城市，四个数值，一条渐变。每种视角都归一化到 0–1，再给立面上色。

• 风险

  决定先修哪一个。

  无发现严重

  log(1 + 风险) / log(81)对数曲线：一个严重问题就能看出来，一百个也不会饱和。

• 债务

  安排重构，看清哪个街区正在腐烂。

  0 小时16 小时以上

  小时 / 1616 小时约等于两个工作日：超过就是全红。

• 脉搏

  分清活代码和睡着的代码。又睡着又有风险，是最危险的组合。

  一年前今天

  1 − 天数 / 365今天改过 = 1；一年没动 = 0。

• 流量

  找出整个团队天天都要走的那条主干道。

  0 次提交最繁忙

  提交数 / max(提交数)相对于仓库里最繁忙的那栋建筑。

同样的八栋建筑，由每种透镜分别上色。

街区与连线