0:00 / --:--
Chain of Thought · 10 月 5 日
Sonar CTO Andrea Malagodi 认为，AI 编码工具让 PR 和 token 用量暴涨，但判断工程师价值必须看任务难度、代码质量、审查能力和业务结果，而不能只看产出数量或单个 PR 的成本。
AI 让代码和 PR 的产出速度暴涨，但 Sonar CTO Andrea Malagodi 认为，判断工程师是否创造价值，必须看任务难度、代码质量、审查能力和业务结果，而不能只看产出数量或每个 PR 的成本。
这集还没有学习卡。生成后会保存在这一集，下次直接打开。
a16z Show· 2026-10-16AI 能写代码。它能运行系统吗？｜Grepr CEO Jad NaousAI Can Write the Code. Can It Run the System? | Grepr CEO Jad Naous内容相近
All-In Podcast· 2026-10-19Dylan Field：AI 正在取代设计师吗？设计是新的代码，以及让创造力大众化Dylan Field: Is AI Replacing Designers?, Design is the New Code & Democratizing Creativity内容相近a16z Show· 2026-09-28AI 能写代码，为什么软件没有变得更好？Chain of Thought
Your Best AI Engineer Might Have the Worst Metrics | Sonar CTO Andrea Malagodi
YouTube
音频
AI 编码工具使工程师能够同时推进更多任务，也让团队更容易统计 token 消耗、PR 数量和每个 PR 的成本。然而，这些数据描述的是活动与支出，不会自动说明代码是否解决了重要问题。
本集从 Malagodi 在 Sonar 团队里观察到的两名工程师谈起：一人以高度设计的 AI 智能体（Agent）工作流快速产出大量 PR；另一人花费较高、PR 很少，却在处理需要长时间分析的复杂 C 语言问题。访谈由此延伸至智能体式开发流程、代码审查、安全扫描，以及企业如何控制上下文读取的成本。
本集最有力的对照，是同一张成本看板上的两个极端：一名工程师在较短时间内提交超过 500 个 PR，单个 PR 的成本很低；另一名工程师消耗大量 AI 资源，却只产生少量 PR。若按“每个 PR 花了多少钱”排序，结论似乎显而易见；但 Malagodi 追查工作内容后发现，前者建立了从需求细化、设计到测试的精密流程，后者则在攻克难以直接转化为代码变更的复杂问题。指标可以帮助管理者发现异常，却不能替管理者解释异常。
讨论随后转向一个更棘手的瓶颈：当智能体可以持续生成代码、修复旧问题和搜索漏洞时，人类审查时间并不会同比增长。于是，“有人在环”可能只是形式上的保障——大型 PR 越难读，审查者越容易草草放行。Malagodi 主张把工作切成可理解的小块，在需求定义和提交前设置检查点，并用工具提前提炼变更重点。Sonar 所称的“引导、验证、解决”也是沿这条思路，把代码库上下文、变更验证与存量问题修复串成不同环节。
但更完整的流程并不免费。多模型、多智能体协作会增加 token、权限和财务管理负担；重复读取代码库也可能造成可避免的支出。节目没有给出能把 token 直接换算成收入的公式。它提出的更务实判断是：衡量 AI 工程效率时，既要核算成本，也要保留对任务价值、可审查性和风险的判断。
💬 他们说了什么：节目以一个审查悖论开场：五行代码可以争论数小时，五百行代码反而可能被一句“看起来不错”放行。Malagodi 随后指出，行业正关注统计数字和 token 用量，却可能忘记软件工程也是需要经验、练习与事故教训积累的手艺。
💡 为什么重要：AI 缩短了生成代码的时间，却没有消除判断需求、理解系统和承担后果的工作。管理者需要数据来决定投资方向，但不能把容易计量的活动直接等同于成果。
⚡ 争议点：“工程是手艺”提醒人们避免机械考核，却也可能过于抽象。若要用于团队管理，仍需明确哪些质量、可靠性或业务结果能够作为辅助证据。
💬 Malagodi 把工程师使用 AI 的成熟度，区分为停留在“高级提示”与能够交付完整任务两种状态。后者不只是让模型回答问题，而是设计技能、工具和步骤，让一项工作从需求推进到可提交、可发布的 PR；领导者同时要回答财务团队对支出的疑问。
💡 成熟度的关键不在提示词写得多漂亮，而在任务能否得到清晰定义、持续检查和可靠交付。个人效率与组织成本也必须一起考虑。
⚡ 并非所有任务都适合从头到尾交给智能体处理。探索性研究、架构取舍或高风险修改，可能需要比“最终产出 PR”更合适的完成标准。
💬 Malagodi 查看每个 PR 的成本时，发现一名工程师在“很短的时间内”产生了 500 多个 PR，单位成本很低；另一人花费很高，却只有少量 PR。前者建立了先细化规格、再做设计与架构审查、记录文档、编码和验证的个人流程；据他描述，产出中接近三分之二是测试和验证相关代码。后者处理的是复杂 C 语言问题，需要 AI 长时间分析，成果不一定马上表现为代码变更。
💡 两人的数字都值得追问，但不能仅凭排序判断谁更优秀。PR 数量既受工作流设计影响，也受任务性质影响；深度分析的价值尤其容易在产出看板上消失。
⚡ 节目没有交代“很短的时间”具体多久，也未给出这些 PR 的规模、合并后表现或两人的任务可比性。因此，这个案例适合说明指标的局限，不宜直接推出某种工作流普遍优于另一种。
💬 两人回顾工程组织曾用代码行数、敏捷故事点衡量产出，如今又出现 token 用量排行榜。Malagodi 提醒：删去代码的人有时恰恰最重要；故事点也可能因考核而膨胀。与此同时，不同软件承担的风险不同：银行等关键系统需要严格验证，短期使用的仪表盘也至少不能泄露数据库。
💡 每换一代开发工具，都容易重新把“做了多少”误认成“创造多少价值”。风险分级比统一追求速度更有用：关键系统与临时工具可以有不同审查强度，但都需要安全底线。
⚡ 不能因为某个应用预计只用几个月，就假设其影响一定很小。是否触及敏感数据、重要决策和外部用户，比预计寿命更能决定验证要求。
💬 受到高产工程师的启发，Malagodi 希望让更多工程师在终端里直接获得一套较成熟的工作方式。他介绍 Sonar Vortex：向智能体提供编码规范、代码图谱等代码库上下文，减少大模型反复读取同一批代码；团队还希望把文件级问题反馈前移到终端附近，而不是等完整 PR 流程走完。
💡 把有效实践产品化或模板化，比要求每个人独立摸索更容易推广。缩短“编写—发现问题”的内循环，也可能同时减少返工和不必要的 token 消耗。
⚡ 共享上下文并不自动保证正确。规范可能过期，代码图谱也可能遗漏动态行为；节省读取成本的同时，仍要验证智能体得到的上下文是否适用于当前改动。
💬 Malagodi 将 Sonar 的思路概括为 guide、verify、solve。引导阶段让终端中的智能体获得规范、既有架构和目标架构；验证阶段结合算法方法与基于大模型的分析，检查 PR 及其代码库语境；解决阶段则针对存量代码，使用修复智能体提出 PR，并用 Hunter 智能体寻找安全漏洞。他强调，许多企业维护的是持续变化的既有系统，而不只是新项目。
💡 这套划分把质量控制放在三个不同时间点：生成之前约束方向，合并之前检查变更，运行中的旧代码也持续接受检查。它避免把全部安全责任压到最后一道人工审查上。
⚡ 这些能力属于嘉宾对 Sonar 产品与方法的介绍。工具提出修复 PR，不等于修复已经安全上线；误报、漏报、功能回归及最终接受责任仍需单独处理。
💬 后台智能体可以按计划不断提出变更，但审查者往往会优先处理自己的 PR，使别人的 PR 堆积。Malagodi 认为，工具应先解释变更内容、指出该看哪里、标出明显问题；否则，当改动从 5 行变成 500 行，“有人在环”很容易退化为形式上的点击批准。
💡 代码生成能力提升后，限制系统吞吐量的可能是人的注意力。真正有效的人类监督，不是单纯保留审批按钮，而是让审查任务保持可理解、可排序，并有足够信息作判断。
⚡ 自动摘要与预检能帮助定位风险，也可能制造错误的安心感。高风险改动仍需要根据实际数据流、依赖和运行环境检查，而不能只阅读工具给出的摘要。
💬 主持人担忧，工程师可以同时开启许多智能体任务和 PR，却未必在推进最重要的工作。Malagodi 回应，多任务处理不会自然产生更好结果；优先级本来就难，AI 只是扩大了可同时开展的工作量。他说 Sonar 给予工程师较多自主权，同时要遵守漏洞处理等政策；对于智能体之间的统一优先级框架，他没有声称已经找到成熟答案。
💡 组织需要区分“可以启动”与“应该优先完成”。产品需求、缺陷、漏洞和监管时限会竞争同一批审查与执行资源，仅提高并行度可能加剧拥堵。
⚡ 把排序完全交给个人可能缺少跨团队一致性；反过来，僵硬的中央排序也可能忽略一线工程师掌握的系统细节。节目指出了张力，但没有给出可直接复制的治理方案。
💬 Malagodi 建议先限定问题范围、完成定义和权限边界，再让智能体或子智能体展开探索，并在自然检查点召回人类。他主张刻意设计相互质疑的流程，例如让编排智能体组织产品、工程与质量等角色，而不是让所有角色顺着同一结论走。高产工程师的任务也被拆成了仍可人工理解的小块；相比之下，他不建议让一个会话运行数天后一次交付假设中的 40 万行代码。
💡 多智能体的价值不只是并行执行，也可以是互相检查。但这种检查必须建立在明确职责、可拒绝的标准和可审查的交付单位之上。
⚡ 给智能体不同“角色”不保证其判断独立；它们可能共享错误上下文或同一模型偏差。分工与质疑应通过实际缺陷发现率和返工结果检验，而非仅凭流程图判断有效。
💬 主持人分享以不同模型家族交叉审查代码的做法，希望减少同类模型互相附和。Malagodi 认可尝试不同模型，但坦言尚不确定长期收益是否足够大；若组织有 1 万名工程师，模型接入、数据处理要求、权限与财务汇总都会变复杂。他举例说，若每名工程师每月额外花 1000 美元，团队必须有收入或其他回报覆盖支出；这一金额是说明成本压力的假设，并非 Sonar 的实际单人成本。他称，针对减少重复读取代码库上下文的研究，token 成本节省最高可达约 30%，但没有在访谈中展开研究方法。
💡 个人使用多模型时可自行承担配置负担；企业部署则要为所有人的费用、数据流向和一致性负责。节省上下文重复读取，是比单纯压低使用额度更有针对性的成本控制方向。
⚡ 跨模型审查是否显著改善质量、30% 的节省适用于什么基线，都需要更完整的实验条件。Malagodi 也明确说，token、PR 增长与客户或收入增长之间尚无现成的简单换算关系。
💬 Malagodi 介绍 Sonar 对依赖库漏洞的分析，以及使用 Hunter 智能体遍历代码库、寻找可能串联成风险的弱点。他特别提到输入清理和跨站脚本等并不新颖、却仍可能存在的问题。面对大量报告，他建议团队轮值安排一名负责分诊的“内部防守者”，先接收噪声、找出重要信号，让其他人保留深度工作时间；他还举例说，团队曾需处理数百条 CVE 报告，其中部分很可能是误报或无关噪声。
💡 攻击与防守都能借助 AI 扩大搜索规模，旧代码中的小问题也更值得持续检查。安全治理的瓶颈不只是发现问题，还包括判断哪些问题真实、紧急且应由谁修复。
⚡ 节目没有提供 Hunter 的检测准确率，也没有证明所有小漏洞都能被串联利用。轮值分诊能保护注意力，但如果缺少清晰的升级规则，也可能让真正紧急的报告滞留。
“五行代码的改动，我们可以争论几个小时。五百行代码，通常就变成了‘我觉得不错’。”——Andrea Malagodi，约 22:13
“如果你没有帮助那个‘在环中的人’，你实际上是在亏待他们，也可能有点天真。”——Andrea Malagodi，约 22:13
“不要在真正理解他们正在解决什么问题之前，就过早作出判断。”——Andrea Malagodi，约 07:57
“多任务处理是一种幻觉；它并不会带来更好的结果。”——Andrea Malagodi，约 24:00
以上为依据英文发言所作的中文意译。
把“工作量指标”与“结果指标”分层。 PR 数、token 和支出能够说明系统里发生了多少活动；上线后的故障、修复返工、用户使用或业务变化则更接近结果。两类数据都不应孤立使用：前者便于及时发现异常，后者用于判断投入是否有意义，但通常反馈更慢。
把可审查性视为工程产能的一部分。 如果生成速度上升，却把变更集中到人无法充分理解的大型 PR 中，瓶颈只是从编码转移到了审查。缩小任务边界、保留设计记录、解释变更意图，不只是流程负担，也是让更高产出得以安全吸收的条件。
区分模型审查的“不同意见”与“有效纠错”。 换用另一模型可能带来新视角，但真正值得记录的是：它是否发现了原流程遗漏的、经人工确认且有实际影响的问题。否则，更多审查者也可能只意味着更高费用与更多待处理意见。
将安全分诊视为注意力配置。 自动化搜索扩大了可见问题的范围，也会扩大告警量。轮值接收、明确升级条件，并让服务所有者参与修复，有助于避免全员频繁被打断；但前提是团队持续检查分诊是否漏掉重要信号。
