# 三层漏斗扫了两个热门 AI CLI：一些有意思的发现

> 最近 大厂AI 编程助手扎堆发布 CLI 形态的产品，代码量涨得快，质量怎么样？
> 来了兴趣，拿手头一个内部扫描工具（BugScan，三层漏斗方法论）对 ZCode（TypeScript，约 4,010 个源文件）和 Kimi Code（Python，约 540 个源文件）做了一次快速评测。
> 本文记录评测过程、几个真实的代码案例，以及一个意外的方法论收获。

**结论**：两个开源项目的代码质量都非常高， ZCode 约 4,000 个 TypeScript 源文件、Kimi Code 约 540 个 Python 源文件，均为活跃迭代中的 AI CLI 产品——在这次扫描里，安全卫生项近乎满分（ZCode 硬编码凭证与弱哈希算法 0 命中，Kimi Code 仅 2 条测试文件里的弱哈希摘要），告警总量集中在“类型收窄”与“防御式编程”这类熟练运用语言特性的痕迹上。下文出现的一切数字：是加固空间的参考，并非质量问题的清单。

## 一、为什么用"三层漏斗"

纯正则扫描快但误报多；纯 LLM 扫描准但贵，而且在"干净代码上找 bug"这个任务上容易编造问题（我们早期实验里，让 LLM 直接找 bug，产出接近 0% 的有效发现率——它太擅长"看出"根本不存在的问题了）。

所以这次用的漏斗是三层：

```
L1    正则模式扫描（零成本，秒级，29 条规则）
L1.5  AST 结构级检测（tree-sitter，零成本，毫秒级）
L2.5  LLM 验证（只判"这条告警是真是假"，~740 token/条）
```

关键设计：**LLM 不负责找 bug，只负责裁决**。让它做判官而不是侦探，幻觉空间小得多。

![fig1_funnel.png](https://developer.qcloudimg.com/http-save/yehe-8674888/adedb55afef831bf89329a238f02640b.png)

## 二、先说一个方法论坑：正则会被"假代码"骗

扫描 ZCode 时，L1 正则报了 3 条"空 catch 块吞异常"（high 级）。人工核对时发现它们长这样：

```typescript
const ARMS_BROWSER_PERF_LOAD_NUDGE_SCRIPT = `(function () {
  function dispatchLoad() {
    try {
      window.dispatchEvent(new Event("load"));
    } catch (e) {}   // ← 正则在这行报警
  }
  ...
```

这段 `catch (e) {}` 在**模板字符串内部**——它是要注入浏览器的脚本文本，不是真实执行的代码。正则逐行扫，分不清"代码"和"长得像代码的字符串"。

换成 tree-sitter 做 AST 级检测后，这 3 条自动消失：语法树里模板字符串是一个叶子节点，内部不会被解析成 catch_clause。**这是这次评测里 AST 层最直接的价值实证**——不用任何规则，天然免疫这类误报。

（顺带一提，合并去重时我们让 AST 通道对结构类发现拥有优先裁决权，正则同类型告警在 AST 扫过却未命中的直接丢弃。ZCode 上这一条规则消化了全部 3 条模板字符串误报。）

## 三、ZCode（TypeScript）实测：691 个非空断言，但大部分不冤

合并扫描后 ZCode 的结构类发现：

| 类型 | 数量 | 备注 |
|---|---|---|
| 非空断言 `x!` | 691 | 见下文守卫分析 |
| 显式 `any` | 47 | 类型注解 + 数组 `any[]` 场景 |
| `as any` 强转 | 13 | |
| 硬编码凭证 | **0** | 凭证管理模式干净 |
| 弱哈希 md5/sha1 | **0** | |

691 个 `x!` 听起来吓人，但直接扔给 LLM 验证太贵（约 48 万 token），而且大多有上游守卫。我们加了一层**作用域预筛**再送验，效果是这次评测最有意思的发现：

**预筛逻辑**（简化版）：向上遍历函数级作用域，检查断言表达式是否已被守卫——

```typescript
// 场景 A：真值守卫，断言是安全的
if (!readString(data.url) || !readString(data.token)) {
  throw new CliOAuthError('invalid');
}
const a = readString(data.url)!;   // ← 上游已守卫，suppress

// 场景 B：try-catch 覆盖，语义模糊
try {
  return new URL(data.endpoint!);  // ← null 会抛错被捕获——是守卫还是缺陷？
} catch (e) { return null; }
```

这里我们踩过一个坑，值得展开：最初版本把 A、B 两类都直接过滤（suppress），交叉验证显示 denied 方向零误杀，看起来很美。后来补了 **confirmed 方向**的交叉——发现 5 条已知实存的非空断言里，有 1 条被错误压制了（它恰好在一个"LLM 都拿不准"的 try 块里）。

只验证一个方向的教训：**交叉验证必须双向**——你验证了"没误杀"，不代表"没漏放"。

修正后的规则做了分级路由：

- 真值守卫 / fallback（`??`/`||`）→ 结构性可靠，suppress，省 token
- try-catch 覆盖 → 语义模糊，**仍送 LLM 仲裁**，只附上守卫证据做提示

路由后 ZCode 的 691 条：25 条结构性 suppress + 73 条 try 提示送验 + 593 条直送。LLM 抽样裁决里，非空断言类确认率 0%（denied 理由清一色"上游守卫已存在"），而 `any` 类型确认率 17%——与纯正则通道的历史确认率（21%）基本持平。

**分型确认率这个数据本身比"总确认率"有用得多**：它直接告诉你哪类告警值得花钱送 LLM、哪类应该在结构层就压掉。

## 四、Kimi Code（Python）实测：一次教科书级的零误报验证

Python 侧的收获是 bare except 检测。最初版本的判定有个双误报：`except (A, B):`（元组）和 `except X as e:`（as 模式）都会被误判成裸 except。

修完之后怎么确认修好了？我们的验收标准是"**验证必须覆盖被修的那个通道**"——不能拿没坏的功能凑数。于是对 Kimi Code 全量跑了实测：

- `except Exception as e` 46 条 + `except Exception as exc` 24 条 + `except Exception:` 128 条 + 元组形式 82 条
- **bare_except 告警：0 条**
- 反向用正则全项目搜真裸 `except:`——也是 0 条

零误报 + 零漏报同证（都锚定在"项目里本来就没有真裸 except"这个事实上）。380 个带类型的 except 子句一个都没误伤，这个数字比"准确率 99%"之类的百分比实在。

其余分布：`.get()` 无 None 检查类 408、裸 assert 279、吞异常 43——都是 Python 生态的经典谱系，量级正常。

## 五、两个项目的缺陷谱对比

![fig2_spectrum.png](https://developer.qcloudimg.com/http-save/yehe-8674888/d1ac29d6185e220956eec1558c542581.png)

| 维度 | ZCode (TS) | Kimi Code (Python) |
|---|---|---|
| 主噪声源 | 非空断言（有守卫语义，需甄别） | 类型安全类（`.get()` 链式风险） |
| 安全卫生 | 凭证/弱哈希 0 命中 | 弱哈希 2 条（测试文件里的 md5 缓存摘要，无豁免标记） |
| 结构类误报 | 模板字符串 3 条（AST 免疫） | 0 |
| 整体印象 | 类型收窄用得凶但有章法 | 防御式编程密度高 |

两家都是 2026 年活跃迭代的 AI CLI，这个质量水位明显高于一般同规模开源项目。ZCode 的 691 个 `!` 里 82% 有明确守卫路径，说明团队是在"知道自己在干什么"的前提下使用非空断言，而不是拿它当类型系统的逃生门。

## 六、教训

1. **LLM 别当侦探。**"在干净代码上找 bug"是幻觉重灾区；"裁决一条已有告警"是把开放式生成收敛成二分类——任务形态决定了可靠性。
2. **AST 层的价值不是"更多规则"，是免疫力。** 模板字符串案例里我们没有写任何新规则，只是换了看待代码的方式，3 条误报自然消失。
3. **验证自己工具和验证目标代码一样重要。** 双向交叉、覆盖被修通道、分型统计确认率——这些元验证做完，工具的输出才敢拿去下结论。

工具本身的方法论细节（三层漏斗的规则集、守卫预筛的实现、双盲评审协议）未来有时间再补充。

---

*评测数据：ZCode 4,010 文件 / Kimi Code 539 Python 文件；扫描在本地完成，LLM 验证消耗约 3 万 token。样本与判定明细均有留存，欢迎讨论。*


最近 大厂AI 编程助手扎堆发布 CLI 形态的产品，代码量涨得快，质量怎么样？ 来了兴趣，拿手头一个内部扫描工具（BugScan，三层漏斗方法论）对 ZCode（TypeScript，约 4,010 个源文件）和 Kimi Code（Python，约 540 个源文件）做了一次快速评测。 本文记录评测过程、几个真实的代码案例，以及一个意外的方法论收获。

ZCode & Kimi Code开源代码质量兴趣分析

最近 AI 编程助手扎堆发布 CLI 形态的产品，代码量涨得快，质量怎么样？ 笔者拿手头一个内部扫描工具（BugScan，三层漏斗方法论）对 ZCode（TypeScript，约 4,010 个源文件）和 Kimi Code（Python，约 540 个源文件）做了一次快速评测。 本文记录评测过程、几个真实的代码案例，以及一个意外的方法论收获。

农民伯伯

开发工具

人工智能

三层漏斗扫描ZCode与KimiCode两款AICLI：ZCode 691个非空断言82%有守卫路径，安全项零命中；KimiCode bare except零误报零漏报。LLM只做告警裁决而非侦探，AST层免疫模板字符串误报，双向交叉验证防漏放。

代码解释

TypeScript 

AI编程

路由

Python

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

ZCode & Kimi Code开源代码质量兴趣分析-腾讯云开发者社区-腾讯云

ZCode & Kimi Code开源代码质量兴趣分析

ZCode & Kimi Code开源代码质量兴趣分析

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐