尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

# Verification Engineering:ChatGPT 与 Codex 的下一道门槛,不是生成能力,而是验证能力(plus/pro/codex/)

# Verification Engineering:ChatGPT 与 Codex 的下一道门槛,不是生成能力,而是验证能力(plus/pro/codex/) ChatGPT 和 Codex 让很多人第一次感受到AI 可以快速生成语言、代码、结构、方案和任务路径。它能写文章。能解释代码。能生成函数。能拆解需求。能总结资料。能分析错误。能提出方案。能辅助工程执行。这些能力很直观也很容易让人兴奋。但如果从真实工作流和工程系统角度看AI 进入生产环境之后真正的核心问题并不是它能不能生成而是它生成的东西如何被验证因为生成只是开始。一个答案生成出来不代表它正确。一段代码生成出来不代表它安全。一个方案生成出来不代表它可执行。一份分析生成出来不代表它基于真实前提。一个任务计划生成出来不代表它符合系统边界。AI 最大的能力是生成。AI 最大的风险也是生成。它可以很快给出结果。但速度越快错误传播也越快。所以ChatGPT 和 Codex 未来真正要跨过的门槛不只是模型更强、上下文更长、回答更自然、代码更完整。真正的门槛是AI 生成的内容能不能进入一个可靠的验证系统。这就是 Verification Engineering验证工程。一、生成能力越强验证能力越重要在传统工作流里生成通常很慢。人写一篇文章需要构思、起草、修改。人写一段代码需要理解需求、查文档、调试。人做一个方案需要调研、思考、整理。因为生成成本高所以人会相对谨慎。但 AI 改变了这个结构。现在生成成本急剧下降。一篇长文可以很快生成。一个接口可以很快写出。一个模块可以很快重构。一个测试用例可以很快补齐。一个产品方案可以很快形成。一个架构设计可以很快画出来。这看起来是效率提升。但它也带来一个新问题当生成变得廉价错误结果也会变得廉价。过去一个人写错一段代码需要先花时间写。现在AI 可以一瞬间生成十段看似正确但存在隐患的代码。过去一个人写一篇空泛文章需要花时间组织。现在AI 可以很快生成大量结构完整但缺乏真实判断的内容。过去一个错误方案的形成需要成本。现在错误方案可以被快速包装成专业表达。所以AI 时代的核心矛盾发生了变化。过去的问题是产出不够快。现在的问题是产出太快之后如何判断什么值得保留。生成能力越强验证能力越重要。二、验证不是检查错别字而是判断结果是否可信很多人理解验证容易停留在浅层。文章有没有错别字。代码有没有语法错误。格式是否符合要求。回答是否完整。测试是否通过。这些当然属于验证但远远不够。真正的验证要回答更深的问题这个结果是否符合目标是否尊重约束是否基于正确上下文是否遗漏关键边界是否存在隐藏风险是否会在真实环境中失效是否能被复现是否能被别人审查是否能承担后果对于 ChatGPT验证重点是意义与事实。对于 Codex验证重点是行为与系统影响。一个 AI 生成的解释语言流畅不代表逻辑正确。一个 AI 生成的函数能运行不代表适合项目。一个 AI 生成的方案结构完整不代表能落地。一个 AI 生成的分析观点清晰不代表前提真实。所以验证不是“看起来有没有问题”。验证是建立一套标准让结果必须通过某些关卡才允许进入下一步。三、可以把 AI 输出分成四类验证对象AI 输出并不是一种东西。不同输出需要不同验证方式。可以简单分成四类1. 文本型输出 2. 代码型输出 3. 决策型输出 4. 行动型输出1. 文本型输出比如文章、总结、解释、说明、报告。它的验证重点是逻辑是否连贯 观点是否清楚 事实是否可靠 表达是否符合目标读者 是否存在空泛重复 是否偏离主题 是否遗漏关键条件2. 代码型输出比如函数、补丁、测试、脚本、配置。它的验证重点是语法是否正确 类型是否匹配 测试是否通过 是否符合项目风格 是否引入新依赖 是否破坏旧接口 是否存在安全风险 是否可维护3. 决策型输出比如商业判断、技术选型、架构方案、项目优先级。它的验证重点是前提是否成立 数据是否充分 选项是否完整 风险是否被说明 权衡是否清楚 结论是否过度确定 是否需要人工判断4. 行动型输出比如调用工具、修改文件、发送消息、部署、删除数据。它的验证重点是权限是否允许 操作是否可逆 风险等级是否明确 是否需要确认 是否有审计记录 失败后能否回滚不同输出不能用同一种验证方式。用检查文章的方法验证代码会漏掉系统风险。用跑测试的方法验证决策会忽略前提错误。用格式检查验证行动会忽略权限和后果。这就是 Verification Engineering 的第一条原则先识别输出类型再选择验证策略。四、验证系统应该像管道而不是一次性检查很多人使用 AI 时验证方式是一次性的。AI 输出结果。人看一眼。觉得差不多。接受。这种方式非常脆弱。真正的验证应该是管道式的。生成结果 ↓ 格式验证 ↓ 约束验证 ↓ 上下文验证 ↓ 逻辑验证 ↓ 风险验证 ↓ 人工验收可以写成一个简化结构classVerificationPipeline:def__init__(self,checks):self.checkschecksdefrun(self,output,context):reports[]forcheckinself.checks:reportcheck(output,context)reports.append(report)ifreport.severitycritical:returnVerificationResult(passedFalse,reportsreports)returnVerificationResult(passedall(r.passedforrinreports),reportsreports)一个输出不是“看起来可以”就通过。它应该经过多层检查。比如 ChatGPT 生成文章主题一致性检查 结构完整性检查 论证密度检查 重复内容检查 禁用内容检查 语气风格检查比如 Codex 生成补丁语法检查 类型检查 单元测试 回归测试 接口兼容检查 依赖变更检查 安全风险检查 diff 审查这就是从“人肉看一眼”升级到“流程化验证”。五、Codex 的验证不能只看代码能不能跑AI 编程最容易出现一个误区代码能运行就算成功。但在真实工程里能运行只是最低标准。一段代码可能能运行但仍然有问题它可能破坏历史兼容。可能绕过权限。可能吞掉异常。可能引入隐藏性能问题。可能让未来维护更困难。可能只是针对当前测试硬编码。可能让局部 bug 消失却制造全局技术债。所以 Codex 的验证至少要分成五层1. Syntax Verification 语法验证 2. Behavior Verification 行为验证 3. Contract Verification 契约验证 4. Regression Verification 回归验证 5. Maintainability Review 可维护性审查1. 语法验证代码是否能被解释器、编译器或静态检查工具接受。defsyntax_check(code):returnrun_linter(code)andrun_type_checker(code)2. 行为验证代码是否实现了目标行为。defbehavior_check(patch,tests):returnrun_tests(tests).passed3. 契约验证是否破坏接口、数据结构、返回格式、权限边界。defcontract_check(old_api,new_api):returnold_api.response_schemanew_api.response_schema4. 回归验证是否影响原有功能。defregression_check(test_suite):returnrun_full_regression(test_suite).passed5. 可维护性审查代码是否清晰、最小改动、符合项目风格。defmaintainability_check(diff):return{too_large:diff.lines_changed300,new_dependency:diff.has_new_dependency(),unrelated_changes:diff.has_unrelated_files(),style_mismatch:diff.violates_project_style()}这些验证合在一起才构成真正的代码可靠性。六、ChatGPT 的验证不能只看表达是否流畅ChatGPT 的输出也有类似问题。很多文章、方案、分析看起来很顺。标题清楚。结构完整。语言流畅。段落均匀。观点也像那么回事。但这不代表它有价值。文本型输出最危险的地方是它可以在没有真实判断的情况下生成“高级感”。比如AI 正在重塑生产力结构。 未来的竞争将从工具使用转向认知系统搭建。 人类需要重新理解智能协作的边界。这些句子看起来高级但如果没有具体论证就只是抽象堆叠。所以 ChatGPT 输出也需要验证。可以设计文本验证器classTextVerifier:defverify(self,text,task):return{topic_alignment:self.check_topic(text,task.topic),argument_density:self.check_argument_density(text),redundancy:self.check_repetition(text),specificity:self.check_specificity(text),structure:self.check_structure(text),constraint_compliance:self.check_constraints(text,task.constraints)}文本验证的核心不是“好不好听”。而是有没有真实观点。有没有足够展开。有没有新的角度。有没有逻辑推进。有没有避免空话。有没有服务目标读者。对于高质量内容来说流畅只是基础。真正有价值的是判断密度。七、验证的核心是建立“通过条件”一个任务如果没有通过条件就很难验证。比如用户说帮我写得高级一点。这很难验证。什么叫高级是概念更深结构更复杂语言更抽象案例更专业还是要有程序结构和系统设计如果没有通过条件AI 只能猜。更好的任务应该包含验收标准文章必须满足 1. 不写浅层功能介绍 2. 使用工程系统视角 3. 至少包含一个结构图 4. 至少包含三段伪代码 5. 每一节都要推进一个新观点 6. 避免重复结论对于 Codex 也是一样。模糊任务修一下这个 bug。可验证任务修复订单筛选在 status[] 时返回 500 的问题。 通过条件 1. status[] 返回全部订单 2. statusnull 返回全部订单 3. status[paid] 只返回已支付订单 4. 不改变原接口 response schema 5. 补充对应单元测试这就是 Verification Engineering 的核心思想任务定义时就要设计验证条件。不要等结果出来后才想怎么判断。验证应该前置。八、可以把任务设计成 Test-First Prompt在软件工程里有测试驱动开发。先写测试再写实现。AI 工作流也可以借鉴这个思想。可以叫Test-First Prompt。也就是在让 AI 执行任务之前先定义测试条件。普通提示帮我设计一个 AI Agent 架构。Test-First Prompt帮我设计一个 AI Agent 架构。 输出必须通过以下检查 1. 必须包含 Intent、Context、Planning、Action、Verification、Memory 六层 2. 必须解释每一层的职责 3. 必须给出伪代码 4. 必须说明错误传播机制 5. 必须指出高风险操作如何被人工接管 6. 不能只写概念必须有工程结构这样 AI 的输出会更稳定。因为验证条件本身也是上下文。Codex 场景更明显。请先不要写代码。 先根据这个 bug 生成测试用例。 等测试条件明确后再给最小修改方案。这比直接让 AI 修 bug 更安全。因为测试先于实现能减少“为了生成而生成”的风险。九、AI 生成内容需要可解释但可解释不等于可信很多人认为只要 AI 能解释自己的结果就更可信。这只对了一部分。解释确实重要。但解释不是证明。AI 可以解释正确结果。也可以解释错误结果。它可以为错误代码编出合理理由。也可以为错误判断组织一套漂亮逻辑。所以Verification Engineering 不能只依赖模型自我解释。更可靠的方法是把解释和证据分开。{claim:这个 bug 来自空数组没有被 service 层处理,reasoning:controller 收到参数后直接传递给 serviceservice 将数组拼接进查询条件,evidence:[日志显示 controller 收到 status[],service 中没有对空数组分支做处理,测试中 status[] 触发 500],verification:[新增空数组测试,运行 orderService.test.ts,确认 response schema 未变化]}这种结构比单纯解释可靠。因为它要求 AI 区分结论。理由。证据。验证方法。如果缺少证据就应该标记不确定。一个成熟的 AI 系统不应该只会说“为什么”。还应该说我基于什么证据这样判断 哪些信息还缺失 这个结论如何被验证 如果验证失败下一步是什么十、验证失败不是结束而是反馈信号很多人把验证失败看成失败。但在工程系统里验证失败其实是最有价值的反馈之一。测试失败说明假设不成立。逻辑检查失败说明结构需要调整。约束检查失败说明输出偏离目标。风险检查失败说明方案需要降级或拆分。所以 AI Agent 不应该害怕验证失败。它应该把验证失败当成输入重新规划。defagent_loop(task):contextbuild_context(task)outputgenerate(context)reportverify(output,context)whilenotreport.passed:contextupdate_context_with_report(context,report)outputrevise(output,context)reportverify(output,context)returnoutput这就是闭环。Generate ↓ Verify ↓ Revise ↓ Verify Again没有验证闭环的 AI是一次性生成器。有验证闭环的 AI才接近工程系统。Codex 尤其如此。一个 patch 第一次失败很正常。关键是它能否根据测试失败信息修正方向而不是继续猜。十一、验证系统也需要分级不是所有任务都需要同样强度的验证。写一段普通说明不需要像上线代码一样验证。生成一个内部草稿不需要像正式报告一样验证。修改 README不需要像修改支付模块一样验证。所以验证也要分级。可以按风险等级设计Level 0低风险生成 Level 1格式与约束验证 Level 2逻辑与一致性验证 Level 3外部工具验证 Level 4人工审查 Level 5上线前严格验证对应示例defchoose_verification_level(task):iftask.typedraft_text:return1iftask.typetechnical_analysis:return2iftask.typecode_patch:return3iftask.affects_core_system:return4iftask.affects_production:return5这很重要。过度验证会降低效率。验证不足会增加风险。成熟的 AI 系统不是所有任务都严查也不是所有任务都放开。而是根据风险匹配验证强度。十二、验证需要外部工具而不能只靠模型自己模型可以参与验证但不能作为唯一验证者。尤其在 Codex 场景中外部工具非常重要。编译器 类型检查器 单元测试 集成测试 静态分析 安全扫描 性能测试 日志对比 人工 review这些工具可以提供模型之外的客观信号。比如defverify_code_patch(patch):apply_patch(patch)results{lint:run_lint(),type_check:run_type_check(),unit_tests:run_unit_tests(),integration_tests:run_integration_tests(),security_scan:run_security_scan()}returnresults为什么不能只靠模型因为模型可能被自己的解释说服。它可能没有真实运行环境。它可能不知道某个依赖版本差异。它可能忽略系统实际行为。外部工具能让验证从“语言判断”变成“系统反馈”。这才是工程可靠性的基础。十三、文本输出也需要外部验证很多人以为只有代码需要工具验证。其实文本也需要。比如事实性文章需要资料核对。商业分析需要数据口径验证。技术文章需要概念准确性验证。法律、医疗、金融类内容更不能只靠模型生成。文本验证可以包括事实核查 引用核查 数据口径核查 逻辑一致性检查 读者适配检查 禁用词检查 原创性检查 风格一致性检查对于高阶内容甚至可以引入“反方验证”。让模型或人从反面攻击文章这篇文章有没有偷换概念 有没有空泛表达 有没有论证跳跃 有没有把假设当结论 有没有只是堆叠高级词 有没有缺少具体机制这类验证能显著提高内容质量。因为真正高级的文章不怕被质疑。它应该经得起反问。十四、验证工程会改变人类角色当 AI 负责越来越多生成人类的角色会发生变化。过去人主要负责生产。写内容。写代码。写方案。写文档。写测试。整理资料。未来人会更多负责验证。判断 AI 的输出是否符合目标。判断方案是否值得执行。判断代码是否安全进入系统。判断文章是否有真实观点。判断分析是否基于可靠前提。判断任务是否需要继续推进。这不是说人不再生产。而是说人的价值重心会上移。从直接生成转向定义标准和验收结果。这就像工业化之后手工制造减少但质量控制、流程设计、工程管理变得更重要。AI 时代也是如此。生成变得自动化之后验证会成为新的核心能力。谁能建立更好的验证标准谁就能更好地使用 AI。十五、真正成熟的 AI 工作流先定义标准再生成结果很多人使用 AI 的顺序是先让 AI 生成 再看结果怎么样 不满意再修改这当然可以。但更成熟的方式应该是先定义目标 再定义约束 再定义验证标准 再生成 再验证 再修正也就是Goal → Constraints → Verification Criteria → Generation → Validation → Revision这是一种更工程化的工作流。可以抽象成classAITask:def__init__(self,goal,constraints,verification):self.goalgoal self.constraintsconstraints self.verificationverificationdefrun_ai_task(task):outputgenerate(goaltask.goal,constraintstask.constraints)reportverify(outputoutput,criteriatask.verification)ifnotreport.passed:outputrevise(output,report)returnoutput这个结构非常简单但它代表了一种重要变化AI 不再是随意生成。AI 被放进了一个有标准的流程。十六、写在最后未来的核心不是谁生成更多而是谁验证更好ChatGPT 和 Codex 让生成变得容易。这是巨大进步。但当所有人都能快速生成内容、代码和方案之后真正的差距不会停留在“谁生成得快”。真正的差距会变成谁能定义更清楚的目标。谁能建立更严格的约束。谁能设计更可靠的验证。谁能识别看似正确的错误。谁能避免错误结果进入真实系统。谁能把 AI 输出变成可审查、可复现、可回滚的工作流。AI 时代最稀缺的能力不是生成能力。而是验证能力。ChatGPT 可以让语言生产变快。但人要验证观点是否成立。Codex 可以让代码生产变快。但人要验证系统是否安全。AI Agent 可以让任务推进变快。但人要验证每一步是否符合目标和边界。没有验证AI 是一个强大的生成器。有了验证AI 才可能成为可靠的协作者。所以未来真正成熟的 AI 使用者不会只问能不能帮我写能不能帮我改能不能帮我生成他会问这个结果怎么验这个结论依据是什么这个代码如何测试这个方案有什么风险这个动作能不能回滚这个输出是否符合最初目标这个系统有没有阻止错误继续传播这才是 AI 工作流的核心。生成解决的是效率问题。验证解决的是可靠性问题。效率让 AI 有用。可靠性让 AI 可用。ChatGPT 和 Codex 的下一阶段不只是更会生成。而是更能进入验证闭环。因为真正改变工作方式的不是一次漂亮输出。而是一个可以不断生成、验证、修正、沉淀的系统。这就是 Verification Engineering 的意义。
返回列表