Repository navigation
建议：import 提取代码知识时暴露 --max-files 参数（当前硬编码 200 且静默截断） #1194
Description
关联 issue
关联 #981（[feat] 支持 Scala 代码图谱导入，已 closed）
本问题是在验证 #981 修复效果时发现的后续问题：
#981 修复前：.scala 文件被静默丢弃 → 仓库采集文件数没到 200 → 上限问题被掩盖
#981 修复后：.scala 文件正常采集 → 文件数超过 200 → 上限问题暴露
即：#981 的修复让更多文件进入采集范围，从而使这个既有的 200 文件上限开始影响实际结果。
两者问题域不同（#981 是「采集类型缺失」，本 issue 是「采集数量截断」），故单独提出。
问题
teamai import --dir / --from-repo 提取代码知识图谱时，单个仓库最多采集 200 个文件，且该上限硬编码、无 CLI 参数、无配置文件入口。
超过 200 个文件的仓库会被静默截断 —— 不报错、不警告，输出看起来完全正常。
影响
实测（teamai-cli 0.28.0-beta.5，Windows 11，Node v22.23.2）：
| 仓库 | 实际文件数 | 提取文件数 | 覆盖率 |
|---|---|---|---|
| DataTools | 434 | 200 | 46% |
| FeDataFlink | 391 | 200 | 51% |
| FeDataFlink-master_ex | 372 | 200 | 54% |
| smp | 394 | 200 | 51% |
截断不只是「少」，而是可能「错」。
知识图谱的核心价值在于依赖关系。缺了约一半文件意味着：
- 查「谁调用了 X」→ 漏掉一半调用方
- 查「模块依赖」→ 依赖边是断的
这会让下游（recall / AI 问答）给出看似确定、实则错误的答案，比「没有图谱」更危险。
对比：把上限调到 2000 后，同一个仓库的产出：
| 仓库 | 上限 200 | 上限 2000 |
|---|---|---|
| 项目1 | 200 文件 / 616 节点 / 157 边 | 434 文件 / 1150 节点 / 775 边 |
| 项目2 | 200 / 350 / 53 | 372 / 980 / 391 |
| 项目3 | 200 / 475 / 8 | 394 / 721 / 8 |
复现
# 准备一个代码文件数 > 200 的仓库
teamai import --dir <repo> --skip-enrich --all
# 输出恒为：
# Files: 200 ← 无论仓库实际有多少文件根因
dist/cli.js：
const maxFiles = opts.maxFiles || 200;以及下游：
const limited = filtered.slice(0, options2.maxFiles ?? 200);opts.maxFiles 没有任何 CLI 参数或配置项可以设置 —— teamai import --help 中不存在 --max-files（只有无关的 --max-filesize）。
建议
按优先级：
- 暴露
--max-files <n>CLI 参数 —— 让使用者按需调整 - 提高默认值（如 1000）或按仓库规模自适应
- 至少在截断时输出显式警告 —— 当前静默截断是最容易误导人的部分
if (filtered.length > maxFiles) {
log.warn(`Repository has ${filtered.length} files; only the first ${maxFiles} were collected. Use --max-files to raise the limit.`);
}环境
| 项 | 值 |
|---|---|
| teamai-cli | 0.28.0-beta.5 |
| OS | Windows 11 Pro (10.0.22621) |
| Node | v22.23.2 |
| 场景 | Scala/Java 多仓知识图谱批量导入 |
Activity
hongchuwudi commentedon Oct 17, 2026
I'd like to take this one. I'll add
--max-filestoteamai import(default stays 200), pass it through to the codebase extractor, and open a PR againstmain.feat(import): expose --max-files and warn on truncated code collection (
GDUFZXP commentedon Oct 18, 2026
Thanks @hongchuwudi — that was a remarkably fast turnaround, PR #1196 landed the same day.
Confirming from the reporter side: the truncation warning is exactly what we needed.
Our case — importing 9 Scala/Java repos, 4 of which exceed 200 code files (434 / 391 / 372 / 394). Before the fix the graphs were silently cut to 200 files (~50% coverage), and the missing half produced broken dependency edges. That is arguably worse than having no graph at all: downstream queries (recall / AI Q&A) return confidently wrong answers rather than admitting ignorance.
--max-files+ the warning together cover both halves of the problem — the escape hatch and the visibility. We will pick it up once it ships in a release (still on 0.28.0-beta.5 here, which predates the merge).For reference, the effect of raising the limit on one repo: DataTools went from 200 files / 616 nodes / 157 edges to 434 files / 1150 nodes / 775 edges.
Thanks again.