人机验证协作：人在环内、监督环路与环外的责任

更新日期：2026-11-08。本章为结合现有公司实践提出的组织与工程建议，尚未进行全链路运行验收。 交互沿用 Multica / PC 双入口、GitLab Issue SSOT；详细过程留在 Multica Issue/topic reply。

代码生成加快后，瓶颈转向验收与决策

当代码产出速度超过验证、评审与环境容量时，未验证分支和待评审 MR 会积压， 看似完成了更多开发，实际交付与风险控制可能变慢。 因此团队要同时管理生成、验证和评审的在制任务量，优先消化阻塞与缺失证据，再启动新修改。

人需要持续掌握五件事：目标是否值得做、正确性怎样判断、系统有哪些约束、残余风险谁承担、 异常时怎样停止和恢复。 这些判断可以由 Agent 帮助分析，但责任需要明确到人。 工程团队还应保有阅读和修改关键代码、解释失败证据、独立排障的能力，才有条件接管。

把可验证性作为与功能一起交付的产品能力：一项新行为应能被稳定触发、观察、判定和复现。 测试环境、数据夹具、契约、诊断信号与恢复手段，都是这种能力的组成部分。

先定义正确，再提高测试执行量

用中文写验收标准，编号继续可追溯

Acceptance Criteria 是敏捷开发和需求工程中的常用术语，面向多个岗位的公司指南优先写“验收标准”。 首次出现说明英文含义，正文、图表与 Issue 模板标题使用中文；AC-1、AC-2、AC-* 等既有编号保留， 避免破坏需求、测试、证据与接口之间的关联。已有机器字段和接口名称不因中文展示而直接改名。

验收标准说明这项需求必须满足哪些行为与约束；完成定义说明一类交付共同需要哪些工程检查。 二者都需要证据，但不能相互替代：CI 全绿不代表所有业务验收标准已经满足。

“测试通过”“提供截图”是验证方法或证据要求，还需说明具体证明了什么行为、在什么条件下成立。 截图可以证明某一页面状态，不能单独证明服务端授权或跨租户隔离。

验证需要一套能独立判断“该是什么结果”的依据，常称判定基准或 oracle。 如果同一个错误理解同时进入实现、测试和模型评审，三者可能一致地给出错误答案。 再增加一个 Agent 角色或换一个模型，不能自动消除共同的业务误解。

建议在 GitLab Issue 澄清阶段写出关键 验收标准、正反样例、不变量和禁止发生的结果； 编码中发现新的事实可以修订合同，由责任人确认后同步执行版本。 开发 Agent 可以生成和改进测试，但不能自行把原验收标准改成与当前实现一致。

判定基准来自业务规则、确认过的样例、消费者契约、数据不变量及真实观测； 旧实现可作差分参考，但旧行为本身可能有错。存在争议时应明确由谁裁决，不能让回放结果自动定义业务正确。

测试分层要形成逐步加深的反馈

公司统一层次的语义和证据，不强行更名所有工程现有 L1/L2。 对 Java 为主的业务工程，建议按下表建设；每类任务依风险选必需集合，规模与覆盖比率不一刀切。

部署后健康检查、SLI 与诸葛巡检构成发布后的反馈环，补充测试无法覆盖的真实条件， 不抵消发布前必需验证。人工探索性测试围绕新交互、未知风险和历史事故开展， 适合发现当前自动化断言还没有表达的问题。

反馈节奏建议：编辑时先跑最快且相关的检查；候选提交补组件与契约； MR 由独立 CI/验证执行器完成必需项；发布后检查真实版本和行为；定期执行高成本与恢复演练。 偶发测试失败要记录首次失败和复跑分布，隔离时保留责任、期限和补偿验证，不能把无限重跑到绿当成功。

提升可验证能力，要改变工程接口和设计

可验证性改造不只是增加测试数量。优先改造经常阻塞验证、风险高、变更频繁的边界。

可将这些能力登记在项目接入卡，按能力标 ready/blocked/unknown， 不把七项简单求平均后掩盖关键缺口。高风险修改缺少可判定或可恢复能力时，优先补能力或收缩范围。 对棕地项目从一条真实修复链入手，增加有效回归、最小测试夹具和观测点，逐步拓宽自主任务范围。

人在环内、监督环路、环外：按步骤和风险选择

这些词在行业中用法不完全一致。本文明确三种工作方式，避免把“人不每步点击”误认为“无人负责”。

同一需求可以同时包含三种方式：人确认 验收标准，Agent 自主编码，确定性 CI 自动验证， 人处理残余风险并合并，诸葛自动观察发布后的信号。 公司当前人工合并和生产发布的边界保持不变；环外运行先用于明确且可验收的子步骤。

选择方式看任务的不确定性、影响范围、可逆性、验证质量、数据/权限敏感性与接管时限。 改一行租户过滤逻辑可能比更新几十处文案风险更高，不能仅按代码行数划分。 模型自报置信度也不能直接决定自主权。 新类型任务先影子运行或人工验证，记录实际错误后再开放；出错或环境变更后可以降级。

监督必须来得及：如果人收到通知时已无法阻止不可逆损害，就不能把“人在监督”当作有效措施， 应在动作前加确定性限制、减少影响范围或采用人工门。 停止操作需要撤销在途执行权、阻止新工具动作并处理已开始的操作，不能只在界面显示 paused。

独立验证需要独立的基准、执行和权限

建议把开发者自验、验证 Agent、受控验证执行器和人工评审组合使用。 它们分别提供快速反馈、场景扩展、可重复事实和语义/风险判断。

独立性的重点有四个：验收来源独立于当前实现；关键验证器来自受保护版本； 验证在干净工作区对固定输入执行；结果与执行身份可追溯。 同一个模型可以在不同职责下工作，但共享的业务误解仍需通过独立样例、确定性测试和人审纠正。 使用不同模型可作为补充评审手段，不能替代上述工程边界。

允许开发 Agent 增补测试，也允许合理修订旧测试；对删除、跳过、放宽断言或修改门禁的变更， 要求给出理由、受影响 验收标准 与替代证据，交指定维护者审核。 不应通过“一律禁止改测试”阻止正确修复，也不能让候选分支自行决定降低验证标准。

直接复用公司已有基础：IDP 的反恒真/空断言与测试归属检查， Egress 的缺报告/零执行/跳过失败检查，FSpec 独立 Validator，以及 bug-finder 的正信号/反证纪律。 这些检查共同提高可信度；仍要通过人工探索、真实端到端任务和失败样本检验其盲区。

人仍要保留什么：六项不可悬空的责任

不要求每个人手写每一行代码；但服务责任团队应有足够的人能理解和修改关键路径， 在工具不可用、输出错误或运行环境异常时继续判断与恢复。 新人不能只练提示词和点击合并，应参与代码阅读、测试设计、故障复现、评审和接管演练。 高级工程师也不能只看 Agent 摘要，对高风险路径须深入实际实现与原始证据。

岗位协作与人审入口

产品/业务负责人主责目标与 验收标准；开发主责设计、实现和可测试边界； QA 主责验收模型、反例、探索性验证和自动化质量；平台主责可重建 runtime、验证执行器与证据合同； SRE 主责 SLO、运行反馈、恢复与重大事故指挥；团队负责人主责能力建设和自主范围。 职责可以兼任，但不能留空，也不能把全部质量责任推到 QA 或最后合并的人。

Agent 提交人审时，应提供一张短卡：

1. 本次要解决的业务问题、当前有效 GitLab 合同与变更范围。
2. 关键设计取舍，以及权限、数据、接口或运行时兼容性影响。
3. 固定 SHA/制品对应的 验收标准→用例→结果；哪些未知、没测、跳过或依赖人工。
4. 是否修改/删除测试与检查器，首次失败、重试及环境漂移情况。
5. 剩余风险、回退或前向修复办法、发布后观察信号。
6. 此刻究竟需要人作什么决定，以及 Multica 详细过程和实际报告链接。

人审主要回答：问题定义对不对、关键后果有没有测到、证据能否支持结论、剩余风险能否接受。 风险较高时必须深入 diff、架构和运行证据；低风险重复任务使用抽样与既定门禁， 避免所有任务都要求人重跑一遍，导致人审变成形式化盖章。

团队关注什么，以及如何逐步放手

人还要决定组织怎样从经验中学习

你们已有从源码、TAPD Bug、故障复盘、需求 Wiki、用户反馈萃取知识并定期增量更新的机制。 人在这里要关注：哪些是事实、哪些是假设；规则适用于哪个版本和团队； 一条新结论是否足以改变验收标准；错误经验能否撤回；改进是否真的降低复发。

Agent 可以收集、关联、起草结论、提出回归样例和技能改进； 机器可检查来源、版本、链接、重复与执行结果； 人负责高影响语义与规范裁决，并以抽样与事故反馈检验整个学习机制。 生成的知识再被 Agent 使用，会形成反馈循环；必须避免模型自己的推测被重新检索后当作独立证据。 多个页面转载同一来源也不能算多份独立佐证，保留原始出处和结论状态才能发现这种循环。

需求与用户反馈帮助定义“应该怎样”，源码说明“当前怎样”，Bug 与复盘说明“在哪里失效”。 三者的差异是改进线索，应通过测试、代码或规则变更解决，不能在萃取摘要时抹平冲突。 团队评审知识回流时，重点检查是否产生可执行的回归、评测或恢复演练，而不只检查文档是否更新。

以有效交付与学习效果衡量

优先关注逃逸缺陷与严重度、错误通过、验收覆盖缺口、首次有效验证通过、测试不稳定率、 人工修补/接管时间、评审队列年龄、故障恢复效果，以及有效交付的总成本。 代码行数、生成速度、MR 数和单一覆盖率只能提供局部信息，不能作为自主能力的主要成绩。 新增代码多而验证队列增长时，应限制新开任务并投入验证能力。

建议采用“先协作验证 → 影子运行 → 有界自主 → 持续抽查”的晋级方式。 要求试点任务具有明确范围、可靠验收、完整证据、有效接管和可控影响， 并覆盖失败/异常样例；不以连续几次成功或一个任意通过率直接授予全团队自主权。 试点结果按任务类型和风险统计，逐批扩展；出现错误通过、权限越界或不可恢复状态时立即收缩范围。

对你们现有体系，首批可以选择：Java 单仓缺陷回归、共享 API 兼容检查、稳定只读巡检、 以及一个 PaaS 跨仓契约场景。人工在 验收标准、例外与交付决策处投入判断， 机器承担重复执行、覆盖扩展和证据采集；失败反馈回到工程与技能的唯一维护源。

本章依据来自前述 IDP/Egress/FSpec/bug-finder 已核对实践，以及行业对照章的独立 verifier、 有限反馈循环和 Agent evals 资料；本章中的职责划分、示例场景和推广方式为建议。

防止认知投降：把批判性思维放进交付流程

将重复执行交给 Agent 是认知卸载；默认接受其解释、无法说明关键决定为何成立、 也不再检查证据，则有滑向“认知投降”的风险。本文用中文统一表达这一现象。 本次中文译文和凤凰报道使用 cognitive surrender；用户材料中的 Cognitive Capitulation 是另一种表述， 不据此断言术语起源或它们构成同一个已验证的科学分类。

自主程度提升与人的判断能力建设应同时进行。人不必记住所有代码，也不必重复机器每一步， 但需要知道自己的未知在哪里，并能重新建立对关键路径的理解、识别错误证据和实际接管。 “先看过程”具体指可审计的操作、代码差异、输入输出和报告，不要求获取模型不可见的内部推理。

开工前：人先给出初步判断，再与 AI 澄清

针对非琐碎任务，人先用自己的话写明问题、受影响的人、预期结果、约束、初步假设与未知项。 这不是要求人预先设计完所有实现；可以明确“不知道”，再请 AI 访谈、比较方案和寻找盲点。 假设必须可修正，并主动寻找反证，避免初步判断变成另一种锚定偏差。

在人与 AI 讨论 idea、需求和方案时，建议增加四个问题：

1. 我们为什么认为这是值得解决的问题？哪些原始反馈支持它，哪些与它矛盾？
2. 哪种观察会推翻当前假设？如何实际检查，而非询问模型“有多大信心”？
3. 交付后必须出现什么、绝不能出现什么？哪些验收标准目前无法验证？
4. 哪些目标、取舍与风险必须由人决定，哪些实现选择可以授权 Agent 自主完成？

用户访谈、企信讨论、TAPD 缺陷和运行证据按来源保留；重复转述不算多份独立支持。 确认后的需求与验收标准进入 GitLab 正文，讨论与研究过程留 Multica。

交付时：先核对关键证据，再阅读总结与解释

对重要结论，先从当前合同和原始产物建立判断，再对照 Agent 总结，减少流畅叙述带来的先入为主。 允许摘要作为定位入口；不能把摘要中的“已测试”“已修复”当成实际执行事实。 按风险选择深度，稳定低风险任务可由可靠门禁和抽样承担，不要求所有人逐行阅读全部日志。

不把“所有评审者答对 AI 出的测验”设置为公司硬门禁；模型可能同时写错实现、解释和题目。 可以用复述、对照原始材料、负向样例和人工接管演练帮助发现理解缺口。

建议在人审卡增加以下可选于低风险、必需于高风险的字段，简要写在 GitLab，详细过程关联 Multica：

人的初步判断：问题是什么、关键未知是什么
Agent 自主决定：选了什么、依据、影响，哪些需要人确认
证据：候选版本、实际执行器、报告、验证范围
反证与缺口：尝试推翻哪些假设、尚未验证哪些风险
人的结论：同意/补证/退回/接管；理由和剩余风险

对抗审查：增加独立视角，同时保留工程独立性

对重要变更，可由新的上下文或评审 Agent 从反方寻找漏洞；输入当前验收标准、实际 diff、 原始证据与约束，不只输入开发 Agent 的总结。要求给出可定位问题、失败场景或可运行的反例。 这可以固化为工作流阶段，按风险与预算启用，不把更多 Agent 或不同模型的一致意见当作正确证明。

验收依据、受保护检查器、干净执行环境和实际报告仍是关键。 同一错误规格可能让开发、测试、评审全部同意；涉及业务语义与高影响取舍时仍需要人裁决。

编排税：并发由验证和审阅能力承接

Multica 增加并发前，应检查测试环境、独立验证、人工评审和接管能力是否能够承接。 建议同时管理正在实现、等待验证、等待人审的任务数量，关注最老任务的等待时长与风险。 当积压增长或人开始跳过必要审阅时，优先补证、缩小交付批次、改进自动化或减少新开任务。

不要把“有多少 Agent 在运行”设为产能指标。以有效交付、错误通过、缺陷逃逸、 验证排队时间、返工与人工接管效果判断收益，并为认真评审安排实际工时。 容量限制按团队试点测量，不为 250 人团队凭空设定统一并发数或固定人机配比。

保持专业能力：把练习变成可执行的安排

建议每周选择一项值得保留的能力，先独立完成一个小练习，再使用 AI 对照查漏； 每月回顾停止练习的技能，明确哪些可以放下、哪些仍是职责所必需。 频率是起点建议，团队可按工作节奏调整，不以训练打卡或提示词数量衡量能力。

练习使用隔离环境或脱敏历史材料，不为了训练制造真实生产风险。 新人需要参与读代码、测试设计和排障；资深人员也应保持关键路径理解和接管能力。 重要系统不能只依赖一个人的理解，应通过轮换评审、文档和演练保持团队覆盖。

把 KT 的纪律落到已有流程

以上是与既有工作流的适配建议，不表示公司已经部署完整 KT 方法或获得相关认证。 最终责任区包括目标与产品价值、关键安全与资金风险、受影响的人及可接受代价； Agent 可以准备选项和证据，人决定取舍。扩大自动执行范围时同时增强验证、监督和专业能力。

本次新增参考：观点、研究与建议分别使用

• Critical thinking when agents do the work 中文译文： 本次已阅读全文；页面标注译自 X 长文，原帖未独立阅读全文。本文按译文引用作者实践建议， 不将其当作 Anthropic 官方政策或新的因果实验。保留人对目标与后果的判断、证据先行和编排税等启发。
• 凤凰网科技报道：本次已读，作为该文的二次报道； 与译文涉及同一观点来源，不能算两份独立研究证据。
• KT：AI Is Powerful. Discipline Is Essential.： 本次已读，提供结构化思考与能力培养视角；对研究结论进一步核对以下一手页面。
• Anthropic：How AI assistance impacts the formation of coding skills： 已读官方研究说明，未独立阅读全文论文。52 名主要为初级的软件工程师学习不熟悉的 Python Trio 库， AI 组任务后测验平均 50%，对照组 67%，相差 17 个百分点；任务完成时间差异未达统计显著。 该研究测量短期学习，不能推断你们 Java 团队长期必然退化或成熟技能使用 AI 的收益。 六种使用方式是事后定性分组，研究明确未建立其与学习结果的因果联系； “生成后再理解”分组仅 2 人，不能把分组高分直接当作普遍效果承诺。

因此建议在本公司以关键路径解释、负向验证和实际接管演练检验能力是否保持， 将长期技能变化作为需要跟踪的问题，不把担忧、评论文章和实验结论混为一谈。