企业官网建设流程全解析

Skylos 是一个开源、本地优先的 Python 项目扫描与 PR 门禁工具，能在代码合并前找出死代码、安全漏洞、密钥泄露、质量回退和 AI 生成代码的错误。它的作者用一套公开账本记录了实战成果：10 个由 Skylos 辅助的死代码清理 PR 已合并进 9 个知名开源项目的默认分支，另有 26 份真实世界验证记录（含被拒、被回滚的失败案例）完整可查。

📊 26份真实世界记录：结果全拆解

这份"成绩单"覆盖 2026 年 3 月至 6 月间，在22 个开源项目中提交的 26 个清理与质量修复 PR，详细记录见 REAL_WORLD_RESULTS.md。结果分布如下：

作者刻意把失败也写进账本——这在工具宣传中很少见。所有 PR 状态均于 2026 年 10 月 9 日人工核实，且明确声明：合并的 PR 只是维护者的清理决定，不代表这些项目背书或采用了 Skylos。

🏆 10个合并的死代码清理PR：都删掉了什么

10 个 PR 的最终累计变更：45 个文件，+7 行，−366 行，净减 359 行。典型的"只删不加"式清理——这正是维护者最乐于接受的贡献形态。

❌ 另外 16 个 PR 为什么没成？失败案例的价值

账本中最有参考价值的部分，是那些没有走通的 PR：

• Flagsmith：改动只合并进了维护者自己的暂存分支。维护者解释：私有包在构建时可能依赖被删代码，公开仓库看不到全部调用方。后续 PR 获另一维护者批准后仍被无理由关闭，最终未进 main。
• Glances：合并当天即被回滚——"你的提交弄坏了 Glances（大量缩进问题）"。教训：提交前必须跑项目的格式化工具、linter 和测试。
• turboAPI：维护者审查发现 PR 删除了仍在 20+ 处使用的导入，启动即报NameError。修正后也因"分支过旧，标记为死代码的部分在当前 main 上已不再安全"被关闭。
• flask、crewAI：被维护者无评论关闭；csp的维护者则明确表态不欢迎此类 AI 辅助的清理 PR。
• celery：原始扫描产出 300 条发现，人工确认 56 条，最终只有 15 条进 PR——绝大多数原始发现根本不值得删。
• twine：获一位维护者批准，但对方指出被删名称属于对外公开 API，至今仍在等待第二位维护者。

这些"miss"共同指向几条铁律（原文归纳见 REAL_WORLD_RESULTS.md 的 "What the misses taught us" 章节）：

1. 公开仓库里没人调用 ≠ 不是公开 API；
2. 私有依赖可能藏着你看不见的调用方；
3. 提交当天必须基于最新 main 重新核验；
4. 标准库/第三方基类的覆写方法，静态扫描常会误判为"未使用"。

⚙️ 候选是怎么找出来的：扫描 → LLM 复核 → 人工确认

每个 PR 都遵循同一流程，没有任何一步是纯自动的：

1. 静态扫描：对目标项目跑 Skylos 死代码扫描，拿到全部候选发现；
2. LLM 复核（至少 9 个 PR 执行了此步，包括 Black 和 isort）：使用skylos agent verify，由 LLM 逐条对照源码复核静态发现；
3. 人工确认：作者亲手核实每个候选后才开 PR。即便如此仍有漏网之鱼（Glances 回滚、turboAPI 的NameError），所以人工核验不可省略。

🚀 新手上手：一条命令开始死代码扫描

如果你想在自家项目上体验同样的流程：

pip install skylos skylos . # 查找死代码：未使用的函数、类、导入与空文件 skylos . -a # 追加安全漏洞、硬编码密钥、依赖 CVE、质量与 AI 代码检查

也可以从仓库源码体验完整功能，仓库地址为https://gitcode.com/gh_mirrors/sk/skylos（git clone 使用）。扫描结果按Risk（风险）/ Maintainability（可维护性）/ Dead code（死代码）/ Gate（门禁）四个读数呈现，每条发现都附带源码位置与支撑性分析证据——"能展示自己工作过程"正是 Skylos 的核心卖点。

📚 延伸阅读

• REAL_WORLD_RESULTS.md：26 份记录的完整账本与经验教训
• BENCHMARK.md：内置回归基准套件说明
• docs/dead-code-review.md：死代码审查指南
• benchmarks/dead_code/：死代码检测基准语料

💡 总结：一份诚实的账本比十篇宣传更有说服力

Skylos 的这份实战记录之所以值得读，是因为它同时展示了工具能做什么（45 个文件、净减 359 行的干净清理）和不能做什么（公开 API 误判、私有依赖盲区、分支过期导致的"死而复生"）。对想给开源项目贡献死代码清理的开发者来说，这 26 条记录就是一份现成的避坑清单：静态扫描负责发现问题，人类负责承担责任——在这个前提下，Skylos 被证明是一个切实可行的候选发现器。