路线图

AION 刻意做小、做专：扫描 Python 仓库，为一组高置信度的安全问题生成确定性补丁， 验证它们，并只为通过验证的修复开 Pull Request。

当前状态

项目已具备：

• 基于仓库画像与 Semgrep 初筛的、有上下文的 Python 安全扫描
• 针对七种安全问题类型的确定性修复，每种都配有 AST 层面的验证断言
• 一道验证门（语法 + 断言 + 可选 Semgrep 重扫），为每个 PR 把关
• auto-update：扫描、验证，并为已验证修复开 Pull Request
• 一个可复用的 GitHub Action
• 漂移检测（snapshot / drift）、持续 watch 循环，以及覆盖快照与修复历史的 status 视图

设计原则

• 可信优先于广度。 一小撮永远经过验证的修复，胜过一大堆偶尔会损坏代码的修复。
• 上报，而不是猜。 当某个修复无法被证明安全（例如缺失鉴权装饰器）时，AION 上报供复核， 而不是擅自改代码。
• 确定且可审计。 补丁基于模板，且每个补丁都会被一个独立的 AST 断言重新校验。

可能的下一步

以下是方向，不是承诺。每一项在动手前都应先用“可信优先于广度”原则来衡量。

• 可靠性透明化 —— 按问题类型公开确定性修复与验证的通过率，并提供能在 CI 中端到端跑通的范例。
• 再增加几种高置信度修复 —— 仅在能以与现有七种同等严格程度验证确定性补丁时才扩充问题类型。
• 更好的仓库测试选择 —— 用于验证，超越单文件的 AST 断言。
• 质量信号 —— 重新引入一份轻量的修复质量报告（成功率 / 验证通过率 / 误修率），跑在一组 fixture 上。

明确不在范围内

为了让项目可控，以下是非目标：

• 运行时控制平面能力（事件队列、webhook、inbox 处理）
• 分阶段发布 / release candidate 管理
• 运行时防护（WAF、网关、feature-flag、部署集成）
• 在线热修生产代码
• 非 Python 语言