代码仓库分类：生成文件职责与人工检查清单
产出是一张带原路径、职责建议和待检查原因的地图。它帮助人安排阅读顺序，不保证代码安全、架构优雅或重构成功。
适用场景把一个窄而明确的判断接进代码或工作流
从代码仓库分类案例出发，整理文件职责与待检查项；不让一个标签替你重构或删除文件。按公开来源整理，非本站实测；判断≠自动执行。
来源 · vogel · @ryanvogel · X 原帖伴读
2026-09-21 · 编辑整理，未调用真实模型
背景 / 问题
Section titled “背景 / 问题”AI 编程能很快增加文件，却不总能让你知道每个模块为什么存在。原作者展示过用 Jev 分类代码库的想法。本教程把范围缩小：只读几个文件的非敏感摘要，形成 UI、数据访问、测试和职责不明的检查地图。
地图不是代码审计报告，更不是自动删除清单。模型可以建议你先看哪里，重构决定仍应根据实际引用关系、测试和业务行为。
分类辅助审查，不直接改代码 小范围源码 → 真实职责摘要 → 角色建议 → 打开原文件 → 单独审查变更
不删除、不重构、不伪装安全扫描。
-
选一个示例仓库或你有权分析的项目。
-
先排除 .env、密钥、客户数据、依赖目录与生成文件。
-
为 5–10 个文件保留路径、用途摘要和人工预期类别。
1. 只读取一小块，不扫描全部仓库
Section titled “1. 只读取一小块，不扫描全部仓库”选择一个功能目录，例如上传模块。为每个文件写一句来自真实代码的职责摘要。路径只是身份，不能仅凭文件叫 service 就断言它一定负责业务服务。
如果摘要由其他模型生成，记录这一额外步骤。错误摘要会把错误传给分类器，不能全部归因给 Jev。
2. 先定义分类标准与模糊出口
Section titled “2. 先定义分类标准与模糊出口”UI 指负责可视界面和用户交互；Data access 指数据库或外部 API 访问；Tests 指测试夹具与断言；Unclear 给混合职责或信息不足的文件。
人工先标注几个文件。一个组件里同时请求接口和处理展示，不应该被强制贴成「设计不好」；要先确认项目约定。
3. 保存建议，而不是让分类器改代码
Section titled “3. 保存建议，而不是让分类器改代码”输出保持 path、suggested_role、review_reason。把每个建议链接回原文件，使复核人可以打开真实实现。
未知或多个职责应进入检查队列。不要把一个词条直接映射到删除、移动文件或更改导入路径。
4. 验证地图是否真的帮助审查
Section titled “4. 验证地图是否真的帮助审查”换一组未参与规则设计的摘要，让维护者检查分类，并记录哪些帮助定位问题、哪些属于误报。最终比较的是审查是否更清楚，而非「某类别文件变少」。
需要重构时另起一个任务，先跑测试、审查依赖与行为，再实施代码变更。
从「看不懂仓库」缩小到五个文件
下面是虚构模块清单，最有价值的一行通常是职责混合的文件，而不是显而易见的按钮组件。
| 文件 | 可见职责 | 建议 |
|---|---|---|
| UploadButton.tsx | 选择文件并发出事件 | UI |
| uploadRepository.ts | 保存上传记录 | Data access |
| upload.test.ts | 断言空文件被拒绝 | Tests |
| processUpload.ts | 解析、调用接口、更新界面 | Unclear，人工检查边界 |
教学示例，不是原作者的代码扫描结果。
产出是一张带原路径、职责建议和待检查原因的地图。它帮助人安排阅读顺序，不保证代码安全、架构优雅或重构成功。
- 不要将代码内容或环境文件直接发到未经批准的服务。
- 分类不是静态安全扫描或测试替代品。
- 代码文件名和目录名只是线索，不是结论。
- 你能说明输入来自哪里、哪些字段会参与处理。
- 你保留了原始记录及不确定、失败和人工修改的结果。
- 你能区分本地练习、作者演示与自己真实调用后的测试。
来源边界：依据所列公开来源整理；本站未复现演示。分类结果需人工复核，不会自动执行。
能直接判断 AI 写的代码有没有用吗？
Section titled “能直接判断 AI 写的代码有没有用吗？”不能。是否需要某个模块取决于调用关系、业务需求和测试。分类只是阅读辅助。
为什么不发送整个仓库？
Section titled “为什么不发送整个仓库？”最小范围更容易理解输入、费用和数据风险，也便于人工建立参考答案。