pythia-review

审查 PL/SQL

开始时宣布：“正在使用 pythia-review——先检查数据库发出的信号。”

**阶段：**了解 → 询问——先看数据库自身的信号，再向开发者反馈发现

分两轮审查：先看数据库知道哪些地方有问题，再看检查清单指出哪些地方可能有问题。先看机器信号——它们免费且准确。

第一轮——机器的判定

0. pythia lint <file>（拟议的文件）——内置规范以及 LEAD 在 conventions.json 中制定的规则，并标注行号。将其中的错误作为发现报告；不要手动重新推导。
1. pythia errors NAME——编译错误和警告，附带行:列。对象无法编译时，暂时无需审查其风格。
2. pythia src NAME——读取带有编译器行号的源代码，以便标注发现位置（line 47: ...）。
3. pythia impact NAME --depth 2——了解此对象的影响范围；有 40 个依赖对象的代码中的问题，优先级高于叶节点中的同类问题。
4. 对于拟议的文件（尚未应用）：编译判定要等到应用时才会得出——明确说明编译状态仍未经验证。

第二轮——反模式检查清单

逐项检查 reference/antipatterns.md——如果项目存在 .pythia/conventions.md，也要检查；它的优先级高于通用清单。七项内容，每项都说明错误做法 → 正确做法 → 原因：逐行处理游标的循环、通过字符串拼接构建的动态 SQL、WHEN OTHERS THEN NULL、循环内的 COMMIT、不使用 %TYPE/%ROWTYPE 而手动复制类型、大型 OUT 参数不使用 NOCOPY，以及偏离代码库惯例（pythia similar 可展示项目风格）。

报告发现

• 为每项发现标注位置：line N: <问题> — <影响原因> — <修复方法>。
• 严重性顺序：破坏正确性 → 悄无声息地丢失数据或产生错误 → 大规模运行时的性能问题 → 风格偏差。
• 写下结论前先验证：使用 src 查看实际代码行；切勿仅凭对差异的记忆进行报告。
• 审查结果无问题时，应说明检查了哪些内容，而不只是说“看起来不错”：编译通过，没有新增 INVALID，检查清单已通过。

不应使用此技能的情况

• 审查某项更改是否可以安全应用——这应使用 pythia-impact，并查看 pythia-apply 的预览；此技能审查的是代码本身。
• 审查非 PL/SQL 应用代码——不属于此技能的范围。