锐利边缘

要解决什么问题

生产代码里不少故障并非来自「写错一行逻辑」，而是 API 用对了签名却踩了隐含契约，或 配置在文档里合法但默认不安全。这类问题在审查里容易被当成「风格问题」放过，直到线上出现数据损坏、权限绕过或间歇性崩溃。

本技能面向工程师做 易出错 API 与 危险配置 的定向排查：参数组合复杂、失败模式不直观、资源/时序/并发边界模糊、错误处理语义不清的调用点，以及会绕过安全控制、打开危险功能或削弱可靠性的配置项。

技能如何工作

技能把审查拆成四条可重复的路径，便于在 PR、发布前检查或专项审计里对齐口径：

1. API 分析：对照常见陷阱模式，标记非显然失败、资源生命周期和并发相关的用法。
2. 配置审查：对照配置文件与环境变量，找出默认不安全、过度放权或损害性能的选项。
3. 模式识别：把重复出现的反模式归类（复杂参数面、隐式副作用等），避免只修单点。
4. 风险评估：对已识别项估计影响面（安全、可靠性、性能），便于排修复优先级。

检测上可结合 代码审查、静态分析、配置审计、官方文档中的警告段落，以及团队积累的「踩坑清单」。产出侧建议 记录锐利边缘、给出安全用法与对错示例，并指向更稳妥的替代 API 或配置。

适用边界

• 适合：API 滥用审查、配置安全审计、架构/库选型时的风险对话，以及 onboarding 时补「文档里没写清」的约束。
• 不替代：完整的威胁建模、渗透测试或合规认证；也不保证覆盖某语言/框架的全部专有坑，需结合项目上下文与上游变更说明。
• 若仓库仅提供概要指令而无具体规则库，结论仍依赖审查者经验，宜与 CI 规则、lint 策略一并使用。