← Home NO.135
第 135 期 · AGENT 工程 · 收录于 2026 年 8 月 15 日
验证债
TL;DR · 三句话
- 一卡内基梅隆（Carnegie Mellon）的研究发现：用 AI 工具写代码带来的生产力提升只持续约三个月就掉回原位，但 static analysis（静态分析——不运行程序、直接扫源码找隐患的自动检查）的告警数和代码复杂度却是持续上升的。省下的时间被后面的返工吃回去了，这笔账就叫「验证债（verification debt）」。→ 详细
- 二指望人工评审兜底不成立：沃顿（Wharton）的研究里，AI 说对时参与者 92.7% 照做，AI 说错时仍有近 80% 照做——采纳率几乎不随对错变化。讲者判断 code review 里大量是「盖个章就放行」。→ 详细
- 三解法是把验证做成机器可判、且方法论与"写代码"不同源的一道门：零信任 + 多层，同时嵌进 agent 的内循环（边写边验）和 CI/CD 外循环（不达标不放行）——这就是 Sonar 的 ACDC：guide（引导）→ verify（验证）→ solve（修复）。→ 详细
01
开场：今年是「从做实验转向做工程」的转折点
- 讲者 Anirban Chatterjee 在 Sonar 做产品市场（product marketing），职业起点是给服务器写代码的软件工程师。他判断今年整个领域的转折是「从 experimentation（做实验）转向 engineering（做工程）」——开始给这些系统补上可复现、可扩展、可保持一致的能力，就像不久前云计算走过的路把 IT 红利推给了小企业；而前提是先给系统加上安全性和信任。→ 详细
02
卡内基梅隆的研究：AI 带来的生产力增益，大约三个月就耗尽
▲ 图注：讲者引用的 CMU 研究幻灯片：AI 工具带来的是一次*临时的 3–5 倍速度飙升，到使用第三个月就消失；留下来的是静态分析告警 +30%、代码复杂度 +41%——右边两个红框正是这两项持续上升的指标。*
- 这组数据前一天已在同事 Tarik 的 keynote 上出现过（转写里两处拼作 Tarek，应为同一人），本场是往深里再讲一遍。卡内基梅隆（Carnegie Mellon）研究了发布在 GitHub 上的项目，用元数据把它们分成两类：一类只用传统工具写，一类用 AI 工具写。研究里用的是 Cursor，但讲者强调「换成任何一个 AI 工具其实都一样」。结论是：生产力确实出现过一次飙升，「但大概只持续了三个月，之后就掉回去了」。→ 详细
- 掉回去的原因不是模型变差，而是同期 static analysis 的告警数和代码复杂度出现了持续性上升。这项研究采集这部分数据用的正是 SonarQube，而这类问题并没有在三个月后消退，是「一路持续到很久以后」。→ 详细
- 讲者的因果链值得抄下来：新增的告警和复杂度反过来把开发者拖得更慢，于是前期省下的时间被后期的排查与返工吃回去——「正是这一点，让『用 AI 工具交付高质量代码』变成一件难事」。换句话说，三个月才是这条曲线的观察窗口，第一周的爽感不构成证据。→ 详细
03
要多高的质量，取决于应用的「关键程度」——验证债就在这个缺口里
▲ 图注：「质量缺口」示意：横轴是软件的关键程度（左＝内部/非关键，右＝企业级/关键任务），上面那条红线是*你需要的质量，下面那条平线是 agent 默认给的质量。越往右，两条线之间的缺口越大——那道缺口就是验证债。*
04
模型为什么一定会漏：技术本身 + 缺上下文
05
Sonar 的 LLM leaderboard：约 4000 道编码任务，六个维度给模型体检
- 因为「没有哪两个模型是一样的，它们的质量问题也各不相同」，Sonar 做了个公开榜单（官网的 LLM leaderboard）：市面上重要的新模型一发布就拿来评测，给它们约 4000 道编码任务，再用 SonarQube 评估代码的那一整套指标打分。→ 详细
- 打分维度共六项：正确性、复杂度、解决所派任务的速率，加上 Sonar 的经典三项——可维护性、可靠性、安全性。把模型放在这些轴上作图，就能看出各家强在哪、哪些方面还有提升空间。→ 详细
- 现场那张图是 Claude Opus 4.6 和 Claude Sonnet 4.6：Claude 用户常在两者之间来回切换来「控制 token 的燃烧速度」。数据显示 Sonnet 在正确性和解题上「表现其实相当不错」；但如果你要求更高的可维护性、更高的安全性、或者更低的代码复杂度，「那这类任务换成 Opus 可能会更划算」。他还提到最新的 Claude 和 OpenAI 模型很快也会跑一轮。→ 详细
- 这套数据的第二个作用是「把一件事摆到明面上」：没有哪个模型会做到完美，你永远都需要在流程里保留某种形式的验证，来确认拿到的代码就是你真正想发布的那份。→ 详细
06
沃顿的研究：人工评审这道防线，漏得比你以为的厉害
*▲ 图注：沃顿研究（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，他说这种事「你们各自的组织里」到处都在发生。结论很直接：必须用自动化的验证工具去兜底，而不是寄望于人下次更认真一点。→ 详细
07
「代码是可证明的，软件不是」
08
成功的自动化验证只有两个核心要素：零信任 + 多层
- 要素一 · 零信任（zero trust）：在这个语境下是指「这段代码可能来自任何地方」——人写的、这个 AI 写的、那个 AI 写的都一样，把关标准必须一模一样，用一套同样全面的验证机制通吃所有来源。→ 详细
- 零信任还有个更锋利的推论：不要用写代码的那个 AI 去校验它自己写的代码——「你会希望用一组多样化的工具，才能把各种可能出现的问题都捞出来」；他说得很直白，要「用一套跟『写代码』不同的方法论去审查代码」。→ 详细
- 验证过程本身必须「完全可审计、完全可解释」，能证明每一次都是用同样方式跑的，而且是算法化的、可重复的、一致的，不管在哪儿跑结果都一样。这几个词合起来其实就是一句话：门禁必须机器可判，不能靠「有人看过」。→ 详细
- 要素二 · 多层（multi-layered）：光靠一两种方法不可能把软件里所有可能出的问题都揪出来，所以要同时用 computational review（计算式审查——规则、数据流、控制流那类确定性分析）和 LLM 驱动的审查，「以及介于两者之间的各种手段」。两层的错误分布不同，才叫多层。→ 详细
09
ACDC：guide → verify → solve 的 agent 循环
▲ 图注：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 交付高质量软件的方式。」→ 详细
10
客户为什么要落地验证：四个驱动力
▲ 图注：客户落地验证的四个驱动力，就是幻灯片上这四格：一致地验证*所有 AI 代码、确认 AI 工具是否真的有效、尽早抓住安全问题、维持可证明的合规。*
11
Sonar 的四条产品线
- SonarQube：零信任的多层验证平台，覆盖语法、数据流、架构、控制流问题，基本支持你会用到的任何语言；并做了深度挂载点，让 agent 能以「第一方（first party）」身份直接调用它的验证能力。→ 详细
- Gitar：几周前刚收购、位于 San Mateo 的 AI code review 公司。它不只找问题，还把整条 CI workflow 搭起来并自动化——能在问题构成质量隐患时自动拦截，能写修复、批准修复，甚至完全自动地合掉 PR。但默认不这么干：默认只把问题摆给你看、跟你对话，「这份信任得慢慢挣来」，用得越久、信心越足才逐步打开更多自动化。→ 详细
- Sonar Vortex（本周发布）：在内循环里给 agent 提供工具——动手前给约束和护栏，写的过程中实时跑验证，让它当场发现并修掉正在产生的问题。→ 详细
- remediation agent（修复 agent，本周 GA）：专门啃积压问题和技术债，「那个规模可能是你现在靠人类开发者的人力根本吃不下的」——把技术债、陈年老问题、遗留代码指给它，它在后台默默改进代码库，你专心做手头的创新活儿。→ 详细
12
动手写代码之前，先把 specs 和质量标准「写下来、编码固化」
- 无论内循环还是外层 CI/CD 循环，开跑之前都得先有 specification（规格）：架构约束和你想要的目标架构、能接受的编码规范与模式、哪些依赖可以用哪些不许用、组织遵守的语法规范，甚至日志、可观测性和链路追踪的实践——「所有这些都进到你的 specs 里」。→ 详细
- 然后还要单独定义质量标准：Sonar 出厂自带一套、可按组织调整。它回答的问题很具体——「你推到生产环境的代码，在安全性、质量、可维护性上你愿意接受什么水位」。→ 详细
- 关键动作是最后半句：「你得把它写下来、编码固化（write that down and encode it）」——标准只有变成机器能读、能判的东西，后面那道 gate 才有依据可依。写在文档里、靠人记得，等于没有。→ 详细
13
内循环：管住上下文窗口 + 边写边验
- 每次给 agent 派编码任务时，第一件该帮它做的事是喂上下文和约束，让它「从一开始就理解这个代码库、以及此刻跟它相关的护栏是什么」。→ 详细
- 但不能一上来把整个代码库全砸给它——那样它会「花大量时间来回折腾、四处探索，还一路烧 token」。正确做法是按它接到的活儿，高效地只给刚好需要的那部分上下文，让它很快开始写有产出的代码。→ 详细
- in-loop verification（循环内验证）：agent 一边写，一边回调验证服务，实时拿到「我们在它正在写的代码里发现的问题列表」。妙处在于这些问题能被当场修掉，不会继续传播到后面那些为了把整个项目搭完而要跑的 agentic loop 里——同一个错误，早期只是一个 bug，晚期是一堆互相依赖的 bug。这个能力由 Sonar Vortex 提供。→ 详细
14
外循环：PR 里的双重审查 + 不达标就不放行的质量门禁
- 内循环跑完，就进正式的评审与发布流程（CI/CD）：发起 PR，Gitar 和 SonarQube 都活在这条流程里，对 PR 里的全部代码跑一遍广泛的自动化审查和一次自动化验证，把质量、安全、可维护性三方面的问题返回给你。→ 详细
- 两种审查并排跑：Gitar 的 LLM 驱动「超人级审查（superhuman review）」，加上 SonarQube 的计算式审查——后者会给这三项分别打分。→ 详细
- 门禁的硬度体现在这句：「除非各项都达标，否则不让这个 PR 往生产环境走」。有问题就用 fix agent 把发现的问题全修掉；真正过了这道质量门禁，才能继续走应用的测试、构建和部署。→ 详细
- 结论是两处都要：「验证既要在内层的 agentic loop 里跑，也要在外层的 CI/CD 循环里跑。」少了一处，另一处就得替它擦屁股。→ 详细
15
现场 demo 与集成面
16
Sonar 的体量数据（厂商自述）
- 讲者的一句话主张：「一套治理与验证的机制极其关键，它才能解锁我们下一个层级的成功」，让人靠 AI 编码工具去解决越来越大的问题；据 Sonar 自己的数据，其客户和用户确实能从 AI 编码工具里拿到更高的成功率。→ 详细
- 规模：SonarQube 是「当今世界上采用最广泛的验证工具之一」，全球超过 700 万开发者在用，各条产品线每天分析近 7500 亿行代码；同时是 Gartner 魔力象限（Magic Quadrant）的领导者。（以上均为讲者在自家演讲中给出的数字。）→ 详细
▲ 图注：收尾的四条：① 给有界的自主权——放手让 AI 写，但把验证与约束集中化；② 落地 ACDC；③ 给开发者做编排的工具，把上下文工程当成最有价值的发力点；④ 统一到一个独立、多层的验证平台，别让工具各自为政造出盲区。
闪电问答：（本期无——会议单人演讲，没有问答环节。）
收尾 · 讲者要你带走的四条关键要点：
- 给你的 AI agent 立一套「有边界的自主权（bounded autonomy）」准则——给它们生成代码的自由，但同时强制执行一套集中式的验证与约束方案。→ 详细
- 把 ACDC 落地：给 agent 上下文 → 用独立的度量去验证它们做的活儿对不对 → 让 agent 去解决它们自己犯的错，并且真的把这个权限给它们。→ 详细
- 确保开发者手里有他们需要的编排（orchestration）工具，好让他们能设计出那些让自己成功、把 AI 用到最有效的上下文框架和流程。→ 详细
- 统一到一个独立的、多层的验证平台上，在所有项目、所有团队、所有开发者、所有 AI 编码工具上都一致地使用它——这样才能消除组织里因为工具各自为政、形成孤岛而产生的盲区。→ 详细
🎯 于你何益 为你定制 · 非通用结论
本期相关度：高。 这场演讲讲的是「AI 生成物的验证机制」，正对上你 PRD 工厂两个最疼的地方——真人评审意见回炉缺一个真的会拒绝的闭环，以及agent 产出拿不出可验证的证据。下面按项目对。（家居号 xiaohongshu_momorain 这次确实没有可对的点，略过不写。）
一、Codex Holdwell ERP work · 多-Agent PRD 工厂
1. 「评审意见回炉缺闭环」这个痛点，本期给了它的形状
- 怎么做的：Sonar 反复强调，验证必须「完全可审计、完全可解释」，而且是「算法化的、可重复的、一致的」。但真正让门禁成为门禁的是那句最朴素的话——「除非各项都达标，否则不让这个 PR 往生产环境走」。他们的做法是把质量、安全、可维护性三项分别打分，不过就卡住，然后交给 fix agent 去修，修完重跑。
- 你可以怎么做：你的碰撞协议每一步流转（独立初稿→碰撞→合成定稿→真人评审），现在多半是「agent 给出意见 → 人或下一个 agent 自己决定要不要理」。挑最贵的那一道（我押合成定稿前那一道），把它改造成能返回「通过 / 不通过」的机器检查：先定 3–5 条机器判得了的硬条件——比如每个需求点是否都有配套的验收标准、引用的实体是否与产品线现有口径对得上、是否列出了受影响的上下游产品线——任何一条不过就不许进下一步。agent 的自然语言意见照旧输出，但从此不再持有放行权。
2. 「不要用写代码的 AI 去验它自己写的代码」——这条直指多-Agent 自评的软肋
- 怎么做的：零信任的定义里有一句很硬的推论：「你不会想用同一个 AI 去校验它自己写的代码」，要「用一套跟『写代码』不同的方法论去审查代码」；所以他们坚持多层——计算式审查（规则/数据流/控制流那类确定性分析）+ LLM 审查同时上，因为「光靠一两种方法，你不可能把所有问题都揪出来」。
- 你可以怎么做：你的三驾马车碰撞（补强/修正/第 3 案）目前基本是「LLM 评 LLM 的产出」，方法论同源，能发现的错误类型也同源。给每一路意见配一条非 LLM 的确定性检查做底：术语一致性用词表比对（而不是问模型「术语一致吗」）、实体与字段引用对着产品线现有口径做存在性校验、跨线影响用依赖表跑一遍闭包。让 LLM 负责「发现你没想到的问题」，让脚本负责「保证该有的东西一定有」——这两层的失效方式不一样，才配叫多层。
3. 「agent 产出缺可验证证据」：卡内基梅隆那条三个月曲线告诉你该量什么、什么时候量
- 怎么做的：CMU 用 GitHub 元数据把项目分成用 AI 和不用 AI 两组，发现生产力飙升只持续约三个月就回落，而静态分析告警数和代码复杂度是持续上升的。也就是说：只看短期收益指标，试点结论必然乐观；成本是滞后出现的，而且不会自己消失。
- 你可以怎么做：给 PRD 工厂补一个同构对照——一组用三驾马车产出的 PRD，一组走原流程；短期指标（PRD 产出周期、评审轮次）和滞后指标（需求返工率、开发端提问次数、上线后变更单数）一起采；并且现在就把三个月后的复测日期写进日程。你目前手上大概率只有头几周的爽感数据，那恰恰是 CMU 曲线里最会骗人的那一段。
二、app_incubator · 7-Agent 造 App 链路
1. 规格必须「写下来并编码固化」，才轮得到谈「强制契约」
- 怎么做的：Sonar 说无论内外循环，开跑前都得先有规格：架构约束、编码规范与模式、哪些依赖可以用哪些不许用、日志与可观测性实践；外加一套单独定义的质量标准（安全 / 质量 / 可维护性各愿意接受什么水位）。落点是那半句「你得把它写下来、编码固化」。
- 你可以怎么做：你的「设计稿即工程强制契约」现在强在设计一侧，弱在它是不是机器判得了。把契约拆成一份机器可读清单——token 名、组件白名单、允许引入的依赖、无障碍与点击区底线——在 agent 生成代码后自动比对，不符就退回重写。「强制」这两个字，只有在存在一个会真的拒绝的地方时才成立，否则它只是一份措辞很严肃的建议。
2. 边写边验，比事后大扫除便宜一个量级；顺带还省 token
- 怎么做的：Sonar Vortex 的做法是让 agent 一边写一边回调拿问题列表、当场修，理由是这些问题「不会继续传播到后面那些为了把整个软件项目搭完而要跑的 agentic loop 里」。同时他强调不能把整个代码库砸给 agent，否则它会「花大量时间来回折腾、四处探索，还一路烧 token」。
- 你可以怎么做：把 lint、类型检查、契约比对做成 agent 自己能调用的工具，而不是流程末尾的人工把关，让它写完一屏就自查一屏；同时把喂进去的上下文按当前任务裁一遍，别整包塞。这两件事一起做，省的是同一笔钱——返工和 token 是一回事。
三、onehuman_company · 一人公司 build-in-public
1. 「AI 写代码的生产力增益三个月就没了」是一条现成的验证体选题
- 怎么做的：CMU 这个结论有出处、有明确时间窗（约三个月）、有明确的反向指标（静态分析告警 + 代码复杂度持续上升），而且反直觉——正是「大佬说 X 我试了」这个支柱最好的原料。
- 你可以怎么做：拿 drizzle tech 的 agent 链路做一次真实回测：把过去三个月里 AI 生成代码的返工次数、被推翻的方案数、每个功能从开工到能用的实际周期拉出来，看你自己的曲线是不是也在第三个月拐头。这条能过弹药库闸门——删掉你的实测数据，这篇就不成立。按你的规矩把标题和封面前置：把那个拐点数字直接放标题上。
2. 「验证债」这个词很好用，但别只做转述
- 怎么做的：讲者用一个词（verification debt）把一堆模糊的不适感命名了——AI 帮你写得更快，但把「确认它没问题」这份活儿留给了未来的你，而且是带利息的。
- 你可以怎么做：这条适合「观点短评」支柱，但按你自己的闸门，纯转述不发。可发的版本是你自己的验证债账单：这个月你为 AI 产出补的验证工时占了多少、你主动砍掉了哪几道验证、代价具体是什么。名词借来，数据必须是你的。
四、Personal Thinking / 播客流水线
「只提示不拦截」的检查，效果接近于零——你的流水线里正有一个
- 怎么做的：Sonar 的质量门禁，关键不在于检查得多细，而在于不达标就不放行；再对照沃顿那组数字——人对 AI 建议的采纳率几乎不随对错变化（对时 92.7%，错时仍近 80%），把最后一道防线交给「我会认真看一眼」是最不可靠的安排。
- 你可以怎么做：播客流水线里，
lint_script.py不过就中止（这是真门禁），而fact_check.py只提示不拦截——按本期的逻辑，那道检查实际上依赖你每次都认真扫一遍。给它加一档硬失败：报告里完全找不到出处的数字或人名直接中止合成，其余（缩写展开、数字口语化那类必然误报）仍然只提示。这是今天下午就能改完的一条规则。
五、StockHelp / 投资视角
- 怎么做的：Sonar 把自己定位成 AI 编码时代的「验证层」，并给了体量证据：超过 700 万开发者、每天分析近 7500 亿行代码、Gartner 魔力象限领导者，还刚把做 AI code review 和 CI 自动化的 Gitar 收进来。它的商业逻辑很干净：模型越强、生成的代码越多，需要被验证的东西就越多——它的需求随上游技术进步而增长，而不是被上游替代。
- 你可以怎么做：这是个可以放进能力圈的生意模式模板——「卖给淘金者的不只是铲子，还有验金石」。找那些收益随 AI 变强而增长、而不是被 AI 吃掉的环节：合规、审计、测试、监控、结算。Sonar 未上市、买不了，但这条筛选逻辑可以直接写进 StockHelp 的选股备注，看每家公司时多问一句「AI 再强十倍，它是被吃掉还是被喂饱」。注意：本期所有市占与规模数字都是厂商在自家演讲里说的，可以当线索，不能当尽调证据。
更深一层
该反着用：Sonar 最后一条建议是「统一到一个独立的多层验证平台，覆盖所有项目、团队、开发者、工具」——那是给几千人工程组织和受监管行业开的药方，顺便也是他们的生意。你是一个人 + 8 人 PM 团队，先建「统一平台」大概率会死在建设本身。反过来做：先找出你最贵的那一类错误（大概率是「PRD 少写了一个跨线影响，开发到一半才发现」），只给它写一道会拒绝的检查，跑满三个月证明有效，再谈第二道。他追求的是覆盖面，你该追求的是命中率。
和你现在做法冲突：你正在建的是「多角色互审、层层碰撞」的体系，本质是加人（加 agent）来提质量；本期的立场恰恰相反——加人不解决问题，加「一个会说不的机器」才解决问题，沃顿那个近 80% 就是「加人」这条路的天花板。更刺的一点：你的三驾马车碰撞里，评审方和被评审方是同一类智能，按零信任的标准那不算独立验证。这个张力我不替你下结论，但值得你在下次给碰撞环节加码之前先问一遍：我是在增加验证，还是在增加同源的意见？
对你的镜子：你缺的不是更严的标准，是一个会拒绝的地方。你已经写下了很多标准——宪法、契约、SOP、红线，它们都不差；但只要没有任何一处会真的把不合格的东西挡回去，它们全都只是建议。「验证债」这个词也适用于你的知识库和副业：每一次「先跑起来、回头再校」，都是在给未来的自己开一张带利息的欠条。
所以呢
- 【耐用】验证债：任何提速工具的账都要看三个月后的曲线，不是第一周的爽感——提速的收益和它推迟的验证成本，是同一笔钱的两端。
- 【耐用】零信任：验的方法论必须和造的方法论不同源；同源的检查只能发现同源的错。
- 【耐用】机器可判 > 有人看过：门禁的价值不在标准多细，在于它会不会真的拒绝。
- 【会过期】具体产品与榜单排名（Sonar Vortex / Gitar / leaderboard 上 4.6 代模型的强弱分布），半年后基本要重查。
- 判断更新：你以前多半默认「重要的地方我会认真看」。沃顿的 92.7% 对 近 80% 说明，人的采纳率几乎不随建议对错变化——「我会认真看」不是一项控制措施，它只是一个愿望。
- 这周一个赌注：在 PRD 工厂里挑一道关口，把它从「评审意见」改成「三条机器可判的硬条件 + 不过不放行」，同时给正在跑的流水线补上一个三个月后的复测日期。一道就够——这周要验证的是「能不能真的拒绝」，不是「能不能覆盖全」。