北京
一个模型写下需求意图、提示词、代码、测试和测试结果，整条链路看起来完整可追溯，但一个误解可能贯穿始终。IntDEx 框架给出的判断很直接：正确性的声明，只有在证据来自编写模型之外的来源时才成立。
这套框架由 IntDEx.org 提出，讨论的是 AI 辅助软件开发生命周期里那些不属于任何单一阶段的改动——工作怎么流动、团队怎么配、谁来做决定、什么算证据、谁来看账单、框架要采纳多少。框架把核心转变描述为从"以代码为中心"走向"以行为为中心"。
两个改动扛下了大部分重量
七个跨阶段改动中，证据和监管被单独拎出来强调。
证据这一条针对的是自证循环。当同一个模型既写代码又出测试结果，可追溯性看上去完备，链条本身却可能是错的。框架因此只承认四类证据：实际执行的证据、人的证据、跨模型证据，或与既有基线的对比。这一条与 Huang 等人 2024 年的研究结论相呼应——大语言模型在没有外部反馈的情况下，难以自我纠正回答。
监管这一条的前提是：检查点只有能拦住工作，才算控制。人因研究早就记录过人类使用自动化辅助工具时的自动化偏见与自满（Parasuraman & Manzey, 2010）。欧盟《人工智能法案》第 14 条第 4 款 b 项要求高风险系统的人类监督者"保持对自动依赖或过度依赖输出这一可能倾向的警觉"。框架的应对是具名负责人、记录在案的决策，以及一个债务阈值——越过就停下引擎，而不是让未评审的工作堆起来。
NIST 人工智能风险管理框架 GOVERN 2.1 要求管理 AI 风险的角色、职责和沟通线路"被记录在案，且对全组织的人员和团队清晰"，这在小型、领域对齐的团队里更容易做到。ISO/IEC 42001 则把 AI 治理视为持续改进的管理体系，适合分层采纳。
一个假设性的四人理赔团队
框架给了一个明确标注为示例的推演。四人理赔团队按流动方式工作：一条修改欺诈标记规则的意图被标记为就绪，当天就被拉入处理，而不是等下一个冲刺。引擎报告"所有测试通过"，且这项工作花费很少。
这个"通过"在测试套件真正运行之前被记为未验证，测试人员接受的是执行结果，不是引擎的陈述。成本数字在交付经理对照供应商遥测数据核实之前，被标注为自报。当第三个未评审的高严重度检查点越过引擎清单里设定的阈值，引擎停下并报告阻塞条件，具名负责人清空队列，工作恢复，每个决策都有记录。
评估标准是提议，不是结果
框架列出的可测指标包括：从意图就绪到发布的交付周期、人工检查点的等待时间、有独立（非自证）证据支撑的发布占比、引擎报告成本与遥测实测成本之间的差距，以及检查点债务阈值触发引擎停机的频率。
这些只是提议的评估口径，没有附带任何结果。量化发现将另行报告。
局限也写得清楚：这些改动尚未经过独立案例研究或对照比较的检验；极小的团队在职责分离上会吃力；负责人不在场时，阻塞式检查点会拖慢交付；流动式工作需要待办事项的纪律；跨模型证据能减少共享盲区，但不能消除。
如果要迈出第一步，框架的建议是：把引擎的每一份自报都标注为未验证，并给一个阻塞式检查点指定具名负责人。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
