引导、验证、求解——Anirban Chatterjee(Sonar)

• 讲者 Anirban Chatterjee 在 Sonar 做产品市场（product marketing），职业起点是给服务器写代码的软件工程师。他判断今年整个领域的转折是「从 experimentation（做实验）转向 engineering（做工程）」——开始给这些系统补上可复现、可扩展、可保持一致的能力，就像不久前云计算走过的路把 IT 红利推给了小企业；而前提是先给系统加上安全性和信任。→ 详细

▲ 图注：讲者引用的 CMU 研究幻灯片：AI 工具带来的是一次*临时的 3–5 倍速度飙升，到使用第三个月就消失；留下来的是静态分析告警 +30%、代码复杂度 +41%——右边两个红框正是这两项持续上升的指标。*

• 这组数据前一天已在同事 Tarik 的 keynote 上出现过（转写里两处拼作 Tarek，应为同一人），本场是往深里再讲一遍。卡内基梅隆（Carnegie Mellon）研究了发布在 GitHub 上的项目，用元数据把它们分成两类：一类只用传统工具写，一类用 AI 工具写。研究里用的是 Cursor，但讲者强调「换成任何一个 AI 工具其实都一样」。结论是：生产力确实出现过一次飙升，「但大概只持续了三个月，之后就掉回去了」。→ 详细
• 掉回去的原因不是模型变差，而是同期 static analysis 的告警数和代码复杂度出现了持续性上升。这项研究采集这部分数据用的正是 SonarQube，而这类问题并没有在三个月后消退，是「一路持续到很久以后」。→ 详细
• 讲者的因果链值得抄下来：新增的告警和复杂度反过来把开发者拖得更慢，于是前期省下的时间被后期的排查与返工吃回去——「正是这一点，让『用 AI 工具交付高质量代码』变成一件难事」。换句话说，三个月才是这条曲线的观察窗口，第一周的爽感不构成证据。→ 详细

▲ 图注：「质量缺口」示意：横轴是软件的关键程度（左＝内部/非关键，右＝企业级/关键任务），上面那条红线是*你需要的质量，下面那条平线是 agent 默认给的质量。越往右，两条线之间的缺口越大——那道缺口就是验证债。*

• 差距是相对的：一个人捣鼓的实验、只有几个用户的内部非关键应用、活不了多久的短期项目——AI 默认给的质量和你真正需要的质量之间「差距是很小的，你完全可以接受这个差距」。→ 详细
• 但当你要支撑成千上万用户、代码库更大、改动时时刻刻在发生、用户里还夹着「主动想搞垮你软件的攻击者」，需要的质量就比默认「高出一大截」。补这个缺口的成本就是「验证债」（verification debt）——你必须把软件工程师拉回来，在上生产之前把质量顶到可接受水位。→ 详细

• 讲者不贬低模型（他还说 Fable 刚发布、很期待去试试能从它那里拿到什么水准的代码），但强调「受限于技术本身、受限于这些模型的构建方式，它们仍然会犯错」；而放任这些错误进到生产代码里，可能给组织带来「灾难性的影响」。→ 详细
• 第二个漏因是上下文：模型「只知道你告诉它的那些」——不知道代码库其他地方在发生什么，不知道你的业务在发生什么，也不知道「你两周前跟某个人开的那场会说了什么、而那件事恰恰会影响你今天写的代码」。所以它并不总能像你一样清楚你的目标。→ 详细

• 因为「没有哪两个模型是一样的，它们的质量问题也各不相同」，Sonar 做了个公开榜单（官网的 LLM leaderboard）：市面上重要的新模型一发布就拿来评测，给它们约 4000 道编码任务，再用 SonarQube 评估代码的那一整套指标打分。→ 详细
• 打分维度共六项：正确性、复杂度、解决所派任务的速率，加上 Sonar 的经典三项——可维护性、可靠性、安全性。把模型放在这些轴上作图，就能看出各家强在哪、哪些方面还有提升空间。→ 详细
• 现场那张图是 Claude Opus 4.6 和 Claude Sonnet 4.6：Claude 用户常在两者之间来回切换来「控制 token 的燃烧速度」。数据显示 Sonnet 在正确性和解题上「表现其实相当不错」；但如果你要求更高的可维护性、更高的安全性、或者更低的代码复杂度，「那这类任务换成 Opus 可能会更划算」。他还提到最新的 Claude 和 OpenAI 模型很快也会跑一轮。→ 详细
• 这套数据的第二个作用是「把一件事摆到明面上」：没有哪个模型会做到完美，你永远都需要在流程里保留某种形式的验证，来确认拿到的代码就是你真正想发布的那份。→ 详细

*▲ 图注：沃顿研究（Shaw & Nave, 2026）的两个数字：AI 说对时人跟着走 92.7%，AI 说错时人还是跟着走 79.8%。左边引文点出机制——认知卸载是一种策略性的省力，但认知投降是「对推理本身不加批判地放弃」。*

• 传统上「验证」就是你自己读代码、用自己的判断 review。但沃顿（Wharton）今年早些时候的一项研究说明人也会失守：他们找了相当多的参与者用一个 AI 工具完成任务，而参与者并不知道，研究人员事先要求这个 AI 在一部分时候「理直气壮地说假话」。→ 详细
• 结果：AI 说对的时候，参与者有 92.7% 会照做；AI 说错的时候，仍有接近 80% 照做。也就是说，人对 AI 建议的采纳率几乎不随建议对错而变——这道防线基本是敞开的。→ 详细
• 讲者把它直接套到代码评审上：「这件事几乎可以肯定也正发生在 code review 里。」尤其当代码量更大、多个 agent 在同时写代码、你还得把一堆碎片拼成完整应用时，「负担实在太重了。一天就那么点时间，而你还是得把东西发出去。」→ 详细
• 于是产生大量「盖个章就放行」（rubber stamping）的 review，他说这种事「你们各自的组织里」到处都在发生。结论很直接：必须用自动化的验证工具去兜底，而不是寄望于人下次更认真一点。→ 详细

• 代码的迷人之处在于确定性：只要写对了，「它每一次都会以同样的方式运行」，这带来一种清晰感和底气。但代码是人写的，人的需求和各种外部因素都会影响它的运行方式；代码越堆越多，彼此会以难以预料的方式互相影响；再把应用开放给用户，用户会做出你根本没预料到的事——所以软件不像代码那样可以被证明，它会「以各种离奇又新鲜的方式出问题」。→ 详细
• 推论：你用 AI 写的软件越多、要解决的问题越大，撞上这类局限的频率就越高。自动验证的作用，是在你把一部分代码控制权交出去之后，替你把风险收回来——所以验证是「一个关键的使能条件、一个关键的解锁点」。→ 详细

• 要素一 · 零信任（zero trust）：在这个语境下是指「这段代码可能来自任何地方」——人写的、这个 AI 写的、那个 AI 写的都一样，把关标准必须一模一样，用一套同样全面的验证机制通吃所有来源。→ 详细
• 零信任还有个更锋利的推论：不要用写代码的那个 AI 去校验它自己写的代码——「你会希望用一组多样化的工具，才能把各种可能出现的问题都捞出来」；他说得很直白，要「用一套跟『写代码』不同的方法论去审查代码」。→ 详细
• 验证过程本身必须「完全可审计、完全可解释」，能证明每一次都是用同样方式跑的，而且是算法化的、可重复的、一致的，不管在哪儿跑结果都一样。这几个词合起来其实就是一句话：门禁必须机器可判，不能靠「有人看过」。→ 详细
• 要素二 · 多层（multi-layered）：光靠一两种方法不可能把软件里所有可能出的问题都揪出来，所以要同时用 computational review（计算式审查——规则、数据流、控制流那类确定性分析）和 LLM 驱动的审查，「以及介于两者之间的各种手段」。两层的错误分布不同，才叫多层。→ 详细

▲ 图注：ACDC（Agent Centric Development Cycle）的三段闭环：Guide 先定上下文与约束、给 agent 护栏，Verify 多层复核（计算式、推理式、运行时——覆盖质量/安全/合规），Solve 再按验证反馈自动调试与修复。中间那圈是 agent 自己的 generate 循环。

• Sonar 把自己做 agentic loop 的框架叫 ACDC，即 agent-centric development cycle（以 agent 为中心的开发循环），分三个阶段。→ 详细
• verify（验证） 是三步里「现在最快能落地」的一步，也是最关键的一环——它让 agentic loop 里写出来的代码真的能顺利上线。要求是：多层的、基于推理的，而且要横跨质量、安全、合规三类问题，「确保你交付的质量是你敢背书的」。→ 详细
• guide（引导） 在验证之前：提供护栏、上下文和约束，确保 agent 在动手之前就拿到写好代码所需要的一切，「争取第一次就写对」——把纠错成本前移。→ 详细
• solve（解决） 在验证之后：理想做法不是把问题列表丢给人，而是把工具开放给 agent、给它自主权，让它自己定位问题、自己修，然后重复这个循环。一句话收口：「以 verification 为核心的 agentic loop，就是你用 AI agent 交付高质量软件的方式。」→ 详细

▲ 图注：客户落地验证的四个驱动力，就是幻灯片上这四格：一致地验证*所有 AI 代码、确认 AI 工具是否真的有效、尽早抓住安全问题、维持可证明的合规。*

• ① 一致性：不希望不同项目、不同团队各用一套验证方法，而要「一本统一的规则手册，不管用什么工具都适用」。→ 详细
• ② 把 AI 工具用得高效：很大一部分是 token 效率，也包括让合适的模型去做合适的项目、做它擅长的事。→ 详细
• ③ 安全左移（shift left）：在今天这个「CVE 一公布、往往当天就被坏人利用」的世界里，尽早抓住安全问题极其关键。（CVE = 公开披露的安全漏洞编号。）→ 详细
• ④ 合规：受监管行业必须能证明验证是持续、一致地在全线跑的，因此保留一份审计轨迹（audit trail）极其重要。→ 详细

• SonarQube：零信任的多层验证平台，覆盖语法、数据流、架构、控制流问题，基本支持你会用到的任何语言；并做了深度挂载点，让 agent 能以「第一方（first party）」身份直接调用它的验证能力。→ 详细
• Gitar：几周前刚收购、位于 San Mateo 的 AI code review 公司。它不只找问题，还把整条 CI workflow 搭起来并自动化——能在问题构成质量隐患时自动拦截，能写修复、批准修复，甚至完全自动地合掉 PR。但默认不这么干：默认只把问题摆给你看、跟你对话，「这份信任得慢慢挣来」，用得越久、信心越足才逐步打开更多自动化。→ 详细
• Sonar Vortex（本周发布）：在内循环里给 agent 提供工具——动手前给约束和护栏，写的过程中实时跑验证，让它当场发现并修掉正在产生的问题。→ 详细
• remediation agent（修复 agent，本周 GA）：专门啃积压问题和技术债，「那个规模可能是你现在靠人类开发者的人力根本吃不下的」——把技术债、陈年老问题、遗留代码指给它，它在后台默默改进代码库，你专心做手头的创新活儿。→ 详细

• 无论内循环还是外层 CI/CD 循环，开跑之前都得先有 specification（规格）：架构约束和你想要的目标架构、能接受的编码规范与模式、哪些依赖可以用哪些不许用、组织遵守的语法规范，甚至日志、可观测性和链路追踪的实践——「所有这些都进到你的 specs 里」。→ 详细
• 然后还要单独定义质量标准：Sonar 出厂自带一套、可按组织调整。它回答的问题很具体——「你推到生产环境的代码，在安全性、质量、可维护性上你愿意接受什么水位」。→ 详细
• 关键动作是最后半句：「你得把它写下来、编码固化（write that down and encode it）」——标准只有变成机器能读、能判的东西，后面那道 gate 才有依据可依。写在文档里、靠人记得，等于没有。→ 详细

• 每次给 agent 派编码任务时，第一件该帮它做的事是喂上下文和约束，让它「从一开始就理解这个代码库、以及此刻跟它相关的护栏是什么」。→ 详细
• 但不能一上来把整个代码库全砸给它——那样它会「花大量时间来回折腾、四处探索，还一路烧 token」。正确做法是按它接到的活儿，高效地只给刚好需要的那部分上下文，让它很快开始写有产出的代码。→ 详细
• in-loop verification（循环内验证）：agent 一边写，一边回调验证服务，实时拿到「我们在它正在写的代码里发现的问题列表」。妙处在于这些问题能被当场修掉，不会继续传播到后面那些为了把整个项目搭完而要跑的 agentic loop 里——同一个错误，早期只是一个 bug，晚期是一堆互相依赖的 bug。这个能力由 Sonar Vortex 提供。→ 详细

• 内循环跑完，就进正式的评审与发布流程（CI/CD）：发起 PR，Gitar 和 SonarQube 都活在这条流程里，对 PR 里的全部代码跑一遍广泛的自动化审查和一次自动化验证，把质量、安全、可维护性三方面的问题返回给你。→ 详细
• 两种审查并排跑：Gitar 的 LLM 驱动「超人级审查（superhuman review）」，加上 SonarQube 的计算式审查——后者会给这三项分别打分。→ 详细
• 门禁的硬度体现在这句：「除非各项都达标，否则不让这个 PR 往生产环境走」。有问题就用 fix agent 把发现的问题全修掉；真正过了这道质量门禁，才能继续走应用的测试、构建和部署。→ 详细
• 结论是两处都要：「验证既要在内层的 agentic loop 里跑，也要在外层的 CI/CD 循环里跑。」少了一处，另一处就得替它擦屁股。→ 详细

• demo 演示的是 Sonar Vortex 的内循环，跑的实际是 Cursor：Cursor 先调用 Sonar Vortex 的 context 工具拿上下文、理解该怎么写；写完初版后调用验证流程拿问题列表；标出问题、给出计划、当场修、再跑一遍分析——「在它真正从我们这边拿到验证通过的评级之前，它不会往下走」。→ 详细
• 同样的直接集成也做给了 Claude Code、Codex、Antigravity，以及「基本上你会用到的任何主流 AI 编码工具」。→ 详细

• 讲者的一句话主张：「一套治理与验证的机制极其关键，它才能解锁我们下一个层级的成功」，让人靠 AI 编码工具去解决越来越大的问题；据 Sonar 自己的数据，其客户和用户确实能从 AI 编码工具里拿到更高的成功率。→ 详细
• 规模：SonarQube 是「当今世界上采用最广泛的验证工具之一」，全球超过 700 万开发者在用，各条产品线每天分析近 7500 亿行代码；同时是 Gartner 魔力象限（Magic Quadrant）的领导者。（以上均为讲者在自家演讲中给出的数字。）→ 详细

▲ 图注：收尾的四条：① 给有界的自主权——放手让 AI 写，但把验证与约束集中化；② 落地 ACDC；③ 给开发者做编排的工具，把上下文工程当成最有价值的发力点；④ 统一到一个独立、多层的验证平台，别让工具各自为政造出盲区。

闪电问答：（本期无——会议单人演讲，没有问答环节。）

收尾 · 讲者要你带走的四条关键要点：

1. 给你的 AI agent 立一套「有边界的自主权（bounded autonomy）」准则——给它们生成代码的自由，但同时强制执行一套集中式的验证与约束方案。→ 详细
2. 把 ACDC 落地：给 agent 上下文 → 用独立的度量去验证它们做的活儿对不对 → 让 agent 去解决它们自己犯的错，并且真的把这个权限给它们。→ 详细
3. 确保开发者手里有他们需要的编排（orchestration）工具，好让他们能设计出那些让自己成功、把 AI 用到最有效的上下文框架和流程。→ 详细
4. 统一到一个独立的、多层的验证平台上，在所有项目、所有团队、所有开发者、所有 AI 编码工具上都一致地使用它——这样才能消除组织里因为工具各自为政、形成孤岛而产生的盲区。→ 详细

• 演讲中没有给出个人邮箱或社媒账号；讲者两次请听众到会场楼下 Sonar 的「大红色展台」当面聊。→ 详细
• 公开可查的资源：Sonar 官网的 LLM leaderboard（约 4000 道编码任务的模型代码质量榜单，新模型发布后持续更新）。→ 详细