在代码审查领域,多数工具产生的都是一份长长的PDF报告或一条不可操作的告警。但 BrassCoders 的做法截然不同:它每次扫描后都会在项目目录中生成一个名为 .brass/ai_instructions.yaml 的文件,而 Claude Code 正是直接消费这个文件来自动完成漏洞分诊和修复。二者之间不再有任何人工介入的环节,整个工作流就浓缩在这一读一写之间。
这份 YAML 文件的结构本身就是一套预处理的工作队列。severity 字段决定了审查顺序,line_number 将每一个发现精确锚定到源码的具体行,remediation 字段则在模型尚未读取一行源码之前就给出了修复方向。理解其中每个字段的职能,也就明白为什么这套结构能产生比开放式代码审查提示优秀得多的分诊效果。
实践中,BrassCoders 每次扫描后都会将发现按严重程度从高到低排序,每个发现作为一个独立条目存入文件,包含 id、severity、file_path、line_number、title、description 和 remediation 等字段。例如,一个位于 api/views.py 中的 SQL 注入问题会被写成:issues: - id: bandit-B608-001, severity: critical, file_path: api/views.py, line_number: 47, title: SQL Injection via String Formatting, description: 查询字符串使用 % 运算符将用户输入直接拼入 SQL,攻击者可篡改查询结构,remediation: 改用参数化查询,通过 ? 或 %s 占位符配合独立的值元组传递给 cursor.execute(),严禁在 SQL 查询字符串中使用 str.format()、f-string 或 % 格式化。
Claude Code 读取这个条目时,立即知道这是一项关键优先级,问题出在 api/views.py 的第 47 行,修复手段是参数化查询。它根本不需要通读整个文件,只需查看标记行及其前后极窄的上下文,就能确认问题真实存在并直接生成修复代码。
正是 severity 优先排序让每次会话都直奔要害:Claude Code 先遭遇的是致命的 SQL 注入,而不是中等严重级别的缺失超时,更不是低级别的代码风格建议。这种设计使得 AI 的时间和算力全部花在最能降低风险的地方,从而把代码审查从一场漫长的拉锯战变成了几秒钟内直抵漏洞核心的精准打击。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.