Sec Review Bot 简历与面试准备

1. 项目真实能力总结

这个项目可以定位成一个面向代码仓库的多阶段 AI Agent 安全审查系统。它不是单纯让一个大模型直接改代码，而是把安全审查拆成 discovery、triage、analysis、mitigation、verification、CVSS scoring、delivery planning / patch synthesis 等阶段，每个阶段都有明确输入输出和可落盘的结构化 artifact。

工程上，项目由一个轻量仓库平台适配层和 Python Agent 执行侧组成。当前适配层接的是 GitHub，作用更像 wrapper / adapter：接收仓库事件、准备 input bundle、触发审查任务、再把结果发布回平台；真正的核心在 Python 侧，包括多阶段 Agent workflow、工具/技能挂载、模型配置、文件系统边界、artifact 管理以及本地/Temporal 执行。Temporal 在这里承担长任务和 retry 的运行编排，不是论文贡献重点。

论文侧的核心问题不是“多阶段一定比单 Agent 强很多”，而是：把安全审查拆成可检查、可比较、可交付的阶段，是否能让漏洞分析、修复和交付更可靠。实验结果显示，多阶段在 PatchEval 230 个 CVE 修复任务上比单 Agent 多修复 5 个严格通过样本，但代价是更高 token 和成本；仓库级案例里，Agent discovery + triage 对跨文件、业务逻辑、鉴权、token/session、配置暴露这类问题的覆盖率明显高于 CodeQL / Semgrep / ZAP。

2. 简历描述

Sec Review Bot：多阶段 AI Agent 代码安全审查与修复系统

硕士论文项目：Agentic AI Framework for Web Vulnerability Detection, Mitigation and Patching

Python / LangChain / Multi-stage Agent Workflow

构建面向代码仓库的多阶段 AI Agent 安全审查与修复系统，支持全仓扫描、Issue 审计和 PR 审计，将安全审查拆成发现问题、确认漏洞并收集证据、生成补丁、独立复查、整理并合并交付内容等阶段。
设计了多阶段 workflow，结合安全审查 Skills 与 CodeGraph MCP 辅助代码结构查询，保留各阶段分析结果、补丁和验证输出，并加入补丁导出约束处理换行不一致、声明变更与实际 diff 不一致、工作区污染等 Agent 工程问题。
实现记忆机制：从运行记录中获取并总结可复用经验，整理成类 Skills 的文档目录供 Agent 使用，并支持定期整理以减少碎片、去重和消解矛盾。
论文实验显示，Default multi-stage + DeepSeek V4 Pro 在 PatchEval 230 个 CVE 修复任务 strict oracle 下达到 78/230，接近 ClaudeCode + GPT-5 的 79/230，并在仓库级案例中覆盖更多传统扫描器难以发现的跨文件和业务逻辑类漏洞。

3. 面试问答文档

Q0：这个项目一句话是做什么的？

它是一个面向代码仓库的多阶段 AI Agent 安全审查系统。目标不是只让模型写一个 patch，而是把安全审查拆成发现、分诊、分析、修复、验证和交付几个阶段。每个阶段都会留下结构化结果，所以最后 reviewer 不只看到一段 diff，还能看到这个问题为什么被保留、证据是什么、补丁修了什么、验证阶段还担心什么。

Q1：做这个项目的背景是什么？

我会从“安全问题不只是写 patch”这个点开始讲。

一个很简单的演进路线可以这样画：

传统扫描器
  -> 传统 APR
  -> 学习式 / 深度学习 APR
  -> 直接用 LLM 生成修复
  -> Coding Agent / Repair Agent
  -> 多阶段 Agent 安全审查系统

对应到问题边界，就是：

发现告警
  -> 生成补丁
  -> 基于历史数据学习补丁
  -> LLM 根据上下文写补丁
  -> Agent 读仓库、改代码、跑反馈
  -> discovery + triage + analysis + mitigation + verification + delivery

传统扫描器，比如 CodeQL、Semgrep、ZAP，很适合发现一些模式明确的问题，像 SQL 注入、命令注入、路径穿越、SSRF 这类。但它们大多停在 alert：告诉你这里可疑，却不一定能把根因、影响范围、怎么修、修完怎么验证、最后怎么交付给 reviewer 都串起来。尤其是 Web 应用里的鉴权、对象所有权、token/session、配置默认值这些问题，经常要跨路由、中间件、model、前端假设和配置一起看。

再往自动修复方向看，早期 APR 很多是 generate-and-validate，靠测试来筛 patch。问题是测试过了不等于语义真的对，安全修复里尤其危险，因为 patch 既要挡住攻击，也不能破坏正常行为。

后来有学习式 APR / 深度学习修复，比如从历史 bug-fix 数据里学修复模式。这一层的限制更像是：要构建数据集、依赖训练数据和预处理，通常还依赖比较准确的 fault localization，而且上下文经常是局部的。放到 Web 安全漏洞里就会吃亏，因为漏洞不一定在一个函数里，可能跨路由、中间件、模板、数据库 model、配置和权限逻辑。

再往前一步，直接用 LLM 生成 patch 确实降低了 fine-tuning 和专门数据集的门槛，给足上下文时也能写出看起来合理的修复。但直接 LLM 也有问题：会 hallucination，会过度自信，也可能生成一个看起来合理但连基本验证都过不了的 patch。所以 agentic system 的意义是让模型能读仓库、搜代码、改代码、跑命令，用工具和反馈减少这种盲修。

已有 AVR / repair agent 工作已经很接近这个方向，但边界还是不一样。比如 VulRepair 这类更偏 localized vulnerable function；PatchAgent 更 agentic，但论文里主要针对 C/C++ memory-safety 或局部漏洞实例。很多 coding agent 也默认有一个比较明确的 issue 或漏洞描述作为起点，重点是“从问题到 patch”。我这个项目想扩一下这个边界：不只是给定问题后修复，还包括仓库级 discovery、triage、analysis、mitigation、verification，最后把结果打包成 reviewer 能看的交付单元。

所以项目背景不是“为了用多 Agent 而多 Agent”，而是安全审查本身就有多个角色：发现线索、判断真假、确认修复边界、写补丁、独立验证、组织交付。把这些阶段拆开，目的是让过程更可检查，也让论文能分别评估：多阶段修复有没有帮助、Agent discovery 和传统扫描器覆盖有什么差异、生成的修复能不能变成人能 review 的交付物。

从工程实现看，它也不是只把模型 API 包一层。平台侧目前就是一个比较薄的 wrapper，用来接事件、提交 run、发布结果；真正有技术密度的是后端执行服务、Docker sandbox、Temporal worker、artifact 落盘、patch 导出约束和评测适配。尤其是 patch 这块，我做了执行与补丁导出的 guardrails，比如 newline-tolerant edit、declaredChangedFiles 双向约束和 fresh-baseline git apply --check，这些都是 Agent 真正改仓库时会遇到的工程问题。

所以这个项目可以定位成一个 agent-based、end-to-end、研究导向但交付链路完整的安全审查系统。GitHub 这一层只是当前接入的仓库平台适配层，不是系统核心。

Q2：为什么要做多阶段，不直接让一个 Agent 从头到尾修？

单 Agent 的优点是简单，成本也低一点。但安全修复里有几个角色其实很不一样：有人要判断问题是不是真的，有人要决定修复边界，有人要写 patch，还有人要挑刺看 patch 有没有漏。全部塞给一个 Agent，它可能一边生成结论，一边验证自己的结论，过程比较黑盒。

所以我把它拆成阶段。Analyzer 先判断这个问题到底真不真，如果是真的，就把证据收集到足够支撑一条漏洞叙事；Mitigator 更像执行者，沿着 analyzer 给出的结论和修复边界去写 patch；Verifier 则是单独拉出来挑刺的角色，它拿到的是有限输入，尽量不要被前面 analyzer 的结论带偏。实验里多阶段不是碾压单 Agent，PatchEval 上严格通过数是 78/230，对照单 Agent 是 73/230，提升不大但是真实存在。更重要的是，它会改变修复策略，而且中间过程能被检查。

Q3：论文的研究问题到底是什么？

口语化讲就是三个问题。

第一，多阶段 Agent 在已经给出漏洞描述的修复任务上，相比单 Agent 到底有没有帮助。

第二，如果不先给漏洞，而是让系统自己扫一个仓库，它和 CodeQL、Semgrep、ZAP 这类传统工具相比，能不能覆盖更多类型的问题。

第三，Agent 生成的东西能不能变成 reviewer 真正能看的交付物，而不是一堆散乱告警或者一大段没人敢合的 patch。

所以论文不是想证明“多 Agent 神奇地解决安全”，更像是在研究安全审查这个流程能不能被拆成更可控、更可审计的 Agent workflow。

Q4：各个 Agent 阶段分别做什么？

Discovery 更像召回阶段，它按文件找可疑安全线索，不要求证明漏洞。

Triage 是把 discovery 的候选压缩成更少的 case，过滤弱信号，合并重复或相关线索。

Analysis 负责深挖一个 case。它第一步不是急着修，而是判断“这个描述的问题在代码里到底存不存在”。如果存在，它要把证据补齐，包括相关代码位置、触发路径、为什么现有保护不够、修复边界应该在哪里。CVSS 也放在这一层附近：它不是证明漏洞存在，而是在漏洞已经确认或认为可评分后，把事实映射成一个标准化严重性表达，让消费结果的人知道处理先后顺序。

Mitigation 更像执行者。它不重新发明一套漏洞叙事，而是根据 analyzer 已经确认的结论和边界，在可写 workspace 里生成补丁。

Verification 是独立审查 patch。为了避免它被 analyzer 的判断牵着走，系统会限制它拿到的输入，让它主要站在 patch reviewer 的角度看：补丁有没有覆盖目标漏洞，有没有残留绕过路径，有没有引入回归风险。

Delivery 则是把多个已验证 case 组织成 reviewer 能看的交付单元，比如哪些应该合并到一个 PR，哪些应该分开。

Q5：为什么不让一个 Agent 拿全仓自由找漏洞？

Repository discovery 这一阶段更接近 scanner-like 的高召回扫描：先稳定地“扫一遍”，而不是让 Agent 自由发挥。

现在的 discovery 基本形状是按文件遍历，让 Agent 看文件内容，产出候选安全线索。这个设计有点像 scanner：不要求它马上证明漏洞，也不要求它理解完整业务，只要求它尽量覆盖代码库，把可疑点先捞出来。这样做的好处是覆盖率和评估口径比较清楚：哪些文件扫过、哪些候选被发现、哪些后来被 triage 保留，都能追踪。

如果换成一个自由探索 Agent，哪怕给它 CodeGraph 之类的工具，让它知道项目里有哪些主要 route，也不代表它真的会系统性扫完整个仓库。它可能沿着自己觉得重要的路径查得很深，但漏掉一些不显眼的文件或边缘功能。最后结果会更依赖模型当次的探索策略，覆盖率反而不稳定。

所以 discovery 不是为了“聪明地一次性理解整个系统”，而是为了做高召回、可追踪的候选生成。后面再交给 triage 去压缩和去重，交给 analysis 去做真正跨文件、业务逻辑、修复边界的深分析。

这里的取舍是：自由探索可能看起来更像“智能审计”，但不一定带来稳定覆盖；scanner-like 的 discovery 更笨一点，但它能保证仓库被系统性扫过，也更容易和 CodeQL、Semgrep、ZAP 这种传统扫描器做公平对比。

Q6：Triage 为什么要做两遍？

仓库扫描会产生很多候选。如果全部塞进一个 Agent prompt，容易超上下文，也容易分组不稳定。

所以第一遍按 batch 分开处理，先做粗粒度 keep、suppress、group。这样速度和稳定性更好。第二遍再做 refinement，专门看第一遍留下来的结果，处理跨 batch 的重复和合并问题。

这个设计不是为了复杂而复杂，而是为了处理“候选太多时，单次 Agent 分诊不可靠”的问题。

Q7：Verifier 为什么有用？它又有什么局限？

Verifier 的价值是独立视角。Mitigator 自己写 patch 后做 self-check，多少会有“我觉得我修好了”的偏差。Verifier 站在 patch reviewer 的角度，看补丁是不是只修了一个局部点，有没有绕过路径，是否破坏正常行为。这个角色单独分出来之后，系统也可以做 feedback loop：Verifier 挑出阻塞问题，Mitigator 再针对这个反馈改一轮。

但 Verifier 不是隐藏测试 oracle。它不知道 PatchEval 的 PoC 和单元测试到底检查什么，所以它的反馈有时能把失败 patch 改成成功，也可能把已经能过 benchmark 的 patch 改得更“语义完整”但反而不符合 benchmark。论文里 46 个触发 retry 的样本里，3 个从 fail 到 pass，1 个从 pass 到 fail，说明 feedback loop 有价值，但不能把它说成自动收敛保证。

Q8：为什么不用 Semgrep / CodeQL / ZAP 直接扫？

Agent 不应该被讲成 Semgrep / CodeQL / ZAP 的替代品。Semgrep、CodeQL、ZAP 的优势是便宜、稳定、规则明确，特别适合 SQL 注入、命令注入、路径穿越、XSS 这类有明显 sink 或模式的问题。

但它们通常停留在 alert。很多安全问题要理解路由、鉴权中间件、对象所有权、前后端假设、配置默认值，甚至多个文件组合起来才是漏洞。这个时候 Agent 的优势是能把线索组织成“安全 case”，再往后做分析、修复和验证。

实验里也能看到这个差异。三个仓库案例里，Agent workflow 的 answer-key recall 明显高于 CodeQL、Semgrep 和 ZAP，尤其是 access control、account-state、token/session、missing controls 这类传统扫描器不太擅长的问题。所以更准确的定位是互补关系：扫描器给高信号局部线索，Agent 做仓库级语义审查和后续修复。

Q9：PatchEval 结果和代表 case 怎么讲？

PatchEval 结果讲短一点即可：在 230 个 runtime-validated CVE 修复任务上，Default multi-stage + Deepseek V4 Pro 是 78/230。放在 leaderboard 参考里，它低于 OpenHands + GPT-5 的 83/230，接近 ClaudeCode + GPT-5 的 79/230，高于 SWE-agent + GPT-5 的 76/230。这个位置说明结果接近第一梯队，但不能说它“超过所有系统”，因为模型和 agent 框架都不一样。

第二层再讲自己的 ablation，用来归因 workflow 设计。在同一个 Deepseek V4 Pro 模型下，Default 是 78/230，Single-Agent 是 73/230；No-Verifier 是 76/230，Deep-Self-Check 是 73/230。这个结果说明多阶段有帮助，但不是巨大提升。它的价值还体现在 case-level difference：Default 和 Single-Agent 有不同的成功集合，说明多阶段不是简单“多跑几步”，而是真的会改变漏洞边界理解和修复策略。

同时要把成本讲清楚。Default 的 token 和价格都高于 Single-Agent，所以这是一个效果、可审计性和成本之间的 tradeoff。

如果需要展开一个具体 case，推荐讲 CVE-2021-21360。这个漏洞可以类比成：后台有个“导出站点配置备份”的功能，导出来的东西本来只该管理员看，但生成后权限没设好，匿名用户也能通过 URL 看到。所以它是信息泄露，CWE 是 CWE-200。

具体到代码里，GenericSetup 会生成 log / report，也会生成 snapshot。log 文件创建后有明确的 View 权限限制，只给 Manager 和 Owner 看；但 snapshot 这边会先建 folder，再往里面写 data file，这两层没有同样收紧权限。单 Agent 容易只看到 folder 创建逻辑，于是只修 folder；多阶段 analyzer 会先把修复边界讲清楚：真正保存导出内容的 file 也要保护。这个例子能说明，多阶段的价值不是形式上多几个 Agent，而是先把安全问题边界说完整，再让修复 Agent 执行。

Q10：Repository benchmark 结果和代表 case 怎么讲？

仓库级评测更贴近“安全审查系统”的目标。我们用了 Book Shop、Raddit、WorldPress 三个有 answer key 的 web app。最好的 Agent run 在 Book Shop 覆盖 19/19，Raddit 覆盖 21/22，WorldPress 覆盖 20/21。

对比传统扫描器，CodeQL、Semgrep、ZAP 的覆盖率低很多，但它们的发现通常更稳定、更便宜。所以结论不是“扫描器没用”，而是 Agent 能补上跨文件和业务逻辑类漏洞，并且能继续往修复和交付走。

如果只准备一个仓库级例子，Raddit 最好讲。Raddit 有 22 个 answer-key 漏洞，最好的一次 Agent run 覆盖 21/22；Semgrep 是 8/22，CodeQL 是 7/22，ZAP 是 3/22。扫描器主要抓到了 SQL 注入、命令注入、SSRF、部分 XSS 这类局部 sink；Agent 多覆盖的是 IDOR、JWT 配置、用户 role 提权、CSRF、敏感字段暴露这类需要跨路由、中间件、handler、model 和配置一起看的问题。

这个例子也可以主动讲一个不足：Agent 漏掉了登录 rate limiting。这个是典型“缺失型控制”，不是某一行危险 API，所以比 SQL 拼接、shell command 这种局部 sink 更难发现。

Q11：项目里用了哪些 MCP 和 skills？

先区分这两个东西。Skills 更像本地参考材料，MCP 更像可调用工具接口。

Skills 这边，项目里有一些内置 skills，比如 web-security、cwe、scanner-finding-triage、language-framework-security、ci-security。它们不是一个单独的安全扫描器，而是给 Agent 提供按需阅读的参考材料，比如常见 Web 漏洞怎么判断、CWE 怎么映射、scanner finding 怎么 triage、不同语言和框架有哪些安全注意点。不同阶段会声明自己需要哪些 skills，runner 再把允许的 skill view 挂给这个 agent。

MCP 这边要保守讲。项目里主要考虑的是 CodeGraph MCP，用来辅助符号、调用关系、跨文件跳转这类代码结构查询。它是可选能力，不是默认所有阶段都靠它。CodeGraph 能帮 Agent 更快找到调用关系，但它不能替代 discovery 的全量扫描，也不能自动证明漏洞。

OSV MCP 也可以顺手说明：这个项目试过 OSV MCP，但后来移除了。原因不是协议接不起来，而是它对当前任务帮助有限：issue 里通常已经有 CVE 描述，OSV 返回的 affected range、fixed commit 之类信息容易把 Agent 带去追版本和 git history，反而不如直接看当前仓库代码证据。所以 OSV 不应该被说成系统默认能力。

总结起来：skills 提供安全知识和分类参考，MCP 提供可选代码结构工具；真正的核心还是阶段化 workflow 和 repository-grounded evidence，不是靠某个外部工具一键扫出来。

Q12：Agent 落地难点和 patch harness 是什么？

难点不是“调一个模型接口”，而是让 Agent 在真实仓库里安全地读代码、改代码，并把结果稳定地导出成后续阶段和 reviewer 都能接住的 patch。这里的 harness 可以理解成 agent execution / patch harness：也就是让 Agent 在可控环境里读代码、改代码、运行少量命令、最后产出可交付 patch 的工程外壳。这个项目里确实有意识做了这一层。

第一块是 Docker sandbox。Agent 需要能读代码、改代码，有时还要跑命令验证，但不能让它直接在宿主机上随便执行。所以我把它放进受控 workspace 里，限制读写路径、命令执行、超时和输出大小。

第二块是文件编辑可靠性，尤其是 LF / CRLF。这个问题实际很烦，Claude Code、Codex 这类 coding agent 都容易遇到：模型看起来给了正确的 old string，但真实文件是 CRLF 或混合换行，结果连续 edit 失败；更糟的是 agent 往往不知道自己错在换行上，会开始怀疑路径、内容、上下文，越修越偏。项目里的 local 和 Docker filesystem backend 都做了 newline-tolerant edit：会推断文件原始换行，生成 LF / CRLF 的匹配变体，写回时也尽量保持一致。

第三块是 patch 导出。这里不能只相信 Agent，也不能只相信工作区 diff。

如果只相信 Agent 的声明，它可能说自己改了某个文件，但实际 workspace 里根本没有对应改动，最后交付一个空 patch 或错 patch。如果只相信整个 workspace diff，又可能把意外修改带出去，比如 agent 运行安装命令、生成 lockfile、缓存文件、临时测试文件，整个 diff 直接超出修复范围。

所以我做了一个双向约束：Agent 必须声明 declaredChangedFiles；系统再用 git 观察真实 workspace diff。声明了但没有真实改动，会打回；真实改了但没声明，不会进入可发布 patch。最后只按声明路径导出 scoped patch，并在 fresh baseline 上跑 git apply --check，确认 patch 能干净应用。

所以这里可以明确说：这个项目里确实做了 agent execution / patch harness，包括 Docker 隔离执行、newline-tolerant 文件编辑、workspace patch 导出、declaredChangedFiles 双向约束和 fresh-baseline patch apply check。它解决的不是“模型会不会想对”，而是 Agent 真的改仓库时，怎么让修改可控、可导出、可交付。

Q13：Temporal 在项目里是什么角色 / 边界怎么讲？

Temporal 在项目里主要解决长任务和 retry 的问题：安全审查不是一次短 HTTP 请求能完成的，所以仓库平台适配层把任务交给后端执行服务，再通过 Temporal worker 执行。

它应该被讲成工程编排，不要包装成核心创新。Temporal 负责长任务状态、activity 调度、超时、失败记录和 retry；项目重点还是 Agent workflow 的阶段拆分、证据流和评测。

细节讲到 workflow 是长流程，activity 是里面具体可重试的执行单元，worker 从 task queue 取任务执行，就差不多够了。也可以顺手补一句项目里的链路：仓库平台适配层接事件、准备输入、调用后端执行服务；后端再提交 Temporal workflow，worker 把后面的阶段任务跑完并产出 artifact。

如果被追问为什么不用普通队列，也不用讲太大。更稳的说法是：普通队列当然也能做异步触发和后台消费，但这个项目里的审查任务是长流程，中间还有多个阶段、状态和 artifact，所以 Temporal 这种 workflow 语义会更贴题。

如果被追问你熟 Temporal 到什么程度，可以收在项目边界里回答：我熟 workflow、activity、worker、task queue、timeout、状态查询，以及为什么要把长任务从 webhook 里解耦出来；再往很底层的 Temporal 内部实现，比如 history service、matching service 这类，就不是这个项目的重点了。

还有一个边界要说清楚：Temporal 保证的是可追踪的执行、超时、重试和状态，不保证 Agent 结果正确；它也不是这套系统已经生产化的证明，本项目链路是跑通的，但生产化还要补隔离、监控、权限和成本治理。

Q14：这个项目是 demo 还是完整系统？

它是研究导向但链路完整的可运行系统，不是只有 mock 的 demo。系统能从仓库平台触发审查，经过后端执行服务、Temporal worker 和 Agent workflow，再把结果发布回平台；同时也有 Docker Compose、本地 CLI、HTTP 接口、评测脚本和测试。

但它还不是成熟商业产品。模型效果、成本、运行时稳定性、真实部署治理、人类 review 体验都还有很多工程问题。所以更稳的定位是“论文验证过的可运行 Agent 系统”，而不是生产级安全平台。

Q15：你对安全知识不算特别深，面试怎么说？

可以诚实但不要自毁。可以说：这个项目让我系统性接触了 web 安全漏洞类型，我现在能从代码审查角度理解 SQLi、XSS、SSRF、IDOR、路径穿越、JWT、CSRF 等常见问题，也知道 CWE 和 CVSS 在分类与报告里的作用。我的强项是把这些安全判断组织成 Agent workflow 和评测系统；对于更深的漏洞利用细节，我会结合具体代码和资料继续补。

这比说“我安全非常强”更可信，也更符合 AI Agent 开发岗。

4. 风险提醒：面试时不要说得太满

不要说“生产级系统”，说“研究导向但链路完整的可运行系统”更稳。
不要说“Agent 替代 CodeQL/Semgrep/ZAP”，说“互补，并且在案例中覆盖了更多跨文件和业务逻辑类问题”。
不要说“自动修复一定正确”，说“生成可审查 patch，并通过 verification 和 artifact 帮助人类判断”。
不要把 Temporal 说成核心创新，它是工程编排，不是论文贡献重点。
不要把 CodeGraph MCP、CWE-RAG、OSV MCP 都说成默认能力；CodeGraph 是可选，CWE skill 是内置参考，OSV 已移除。
不要把 GitHub App 讲成系统核心。更稳的是说“当前接了一个比较薄的 GitHub wrapper / adapter，真正的核心在多阶段 Agent workflow 和 patch / artifact 约束”；如果被追问平台扩展，可以说这层未来可以替换成 GitLab 等别的仓库平台适配层。
不要把 PatchEval 78/230 说成“漏洞修复率 34%”，要说“在 PatchEval runtime subset 的 strict oracle 下 78/230 通过”。
不要说“超过 PatchEval leaderboard 第一名”。更稳的是“接近 leaderboard 第一梯队：低于 OpenHands + GPT-5 的 83/230，接近 ClaudeCode + GPT-5 的 79/230，高于 SWE-agent + GPT-5 的 76/230；同模型 ablation 再说明 workflow 贡献”。
不要说自己安全很强。更好的说法是“我能从代码审查角度解释常见 web 漏洞，强项是 Agent workflow 和评测，把安全专家判断流程工程化”。

5. 自检

简历描述没有把实验原型写成生产平台。
PatchEval 数字只作为 benchmark 结果，不泛化成真实世界修复率。
传统扫描器对比只说案例覆盖率，不说全面替代。
Temporal、CodeGraph、CVSS、CWE 都解释了作用和边界。
问答尽量用候选人口吻，没有写成论文摘要。