当AI让代码生成的成本趋近于零时软件工程的核心耗时正从“编写代码”彻底转向“设计验证”。一个常见的误区是认为过去编码就是主要工作其实不然。在传统开发中编码后的验证、调试、重构循环本就占据了大量时间但由于编码本身的高心智负担和修改成本这个循环往往是沉重且缓慢的。在AI Coding下AI消解了“写出代码”的瓶颈反而将那个一直被压制的循环推到了前面。我认为传统开发与AI Coding能力的真正分水岭不在于谁能更快生成代码而在于谁能将“调试代码”的被动行为系统性地重构为“设计质量闭环”的主动工程能力。 这个闭环即用可验证的规则和自动化流程持续确保AI产出的正确性与可靠性。这个能力不仅仅是会编排自动化测试工具也不止是设计几个软件工程研发的 Skill 或 Workflow。我觉得这都还不够。工具和流程说到底是“术”。真正核心的那个东西是你从软件设计的第一天起就把“怎么验证它是对的”这件事儿当成工作里必要的一环。质量验证设计不是开发完再套上去的一层皮它是从架构阶段就长在血肉里的骨架。然后在具体的场景里你要做取舍。用什么工具不走什么流程哪里该自动化哪里该让人看一眼——这些都是在具体上下文里拍板的事。测试闭环怎么搭应用场景怎么跑通不同项目给出的答案完全不同。设计质量闭环的能力不是你会用某个工具而是你进到一个具体的场景里能看清什么东西该被验证、该用什么手段验证、然后亲手把这条链路搭起来、让它自己转下去。以AEAlert为例项目背景AEAlert 是一个 项目内部的C 告警算法库接收雷达航迹计算紧急代码、短期冲突、空域侵入、最低安全高度等告警并对外输出。核心资产就两样算法 对外接口——库会被嵌入别人的系统接口行为什么时候报、什么时候解除、复位后重不重报就是契约。围绕这两样资产搭了一套四层质量闭环。详细说明AEAlert质量测试闭环价值启示AI 让代码变便宜后验证资产应该「奢侈」一点。这套闭环给我的最大启示是AI 让代码变便宜之后验证资产应该「奢侈」一点——场景编排、可视化测试页这些以前的「奢侈工程」如今边际成本足够低值得按体系设计分层、同源、可进 CI。当核心资产是「算法 对外接口」时可执行的行为断言就是接口语义的护城河代码会重构、参数会调整只要断言全绿对外契约就没破这是敢改动的底气。其中最有价值的一维是「不该报的不报」——对告警这类误报即事故的系统静默正确性是生死线而可视化补上机器断言够不到的体验层顺带成为调参工具和最便宜的演示系统。归根结底一句话场景即文档、即用例、即回归单源化是复利的前提——测试资产一旦双份就会腐化一旦单源每次消费都在给它增值。延伸换个技术栈质量闭环换张脸前面的四层闭环不是通用模板而是一种「长相」。我在另外两类项目里做过同样的设计闭环的形态完全不同——因为质量闭环的形状由「这个系统的不确定性藏在哪里」决定。确定性越高的层越交给机器不确定性越高的层越要设计「让人判断成本最低」的方式。Agent 平台LLM是概率模型闭环评的是「嵌入方式」另一个项目GIS_Server_Agent是意图驱动的 GIS 数据发布 Agent把「校验 → 处理 → 配图 → 发布 → 出图 → 验收」六阶段固化为平台骨架Coding Agent 对话驱动数据自动发布成地图服务。它的质量闭环核心立场一句话编排去LLM化。运行层纯确定性六阶段由代码编排重试与回退不看 LLM 脸色由显式规则表驱动——错误签名映射到重试 / 中止 / 跳过未知错误「暂停求助不静默吞掉」。项目文档开宗明义「规则优先于 LLM保持闭环确定性」。LLM 只在生成层LLM 负责生长生成新管线脚手架、沉淀知识卡片但产出物要过三道闸才能进自动路由——契约校验fail-closed→ 显式首跑 →人工认证。路由只认已认证状态版本漂移自动降级。LLM 生成的东西永远不会未经人工就被自动执行。验证防自欺自动验收的判据针对「错误页也返回成功」的真实误绿事故设计事故本身被沉淀为知识卡片。知识层反向约束LLM数十张事故卡既是人的文档又是 Agent 的检索源硬规则「凡修复必沉淀卡否则不算完成」把每次踩坑转化为约束下次生成的结构化学问。这里的启示是Agent 质量评估评的不是模型多聪明而是LLM嵌入业务编排的方式本身。LLM 是概率模型它的输出必须永远经过确定性门禁才生效人的判断不是被省掉而是被精准安插在「认证」这个唯一卡口上。设计 Agent 系统的质量闭环本质是设计概率与确定性的边界。交付工作流不确定性在「过程」闭环把人机分工制度化第三个例子不是某个产品而是我用来交付产品的工作流本身——BWorkflow-V2一套「人 AI 编程助手」协作的交付规则层纯 Markdown 契约 一个小型 Node runtime skill 层本文的 AirEmergency 项目就跑在它上面。它要兜的不确定性不在系统内部而在交付过程AI 写得越快「方向对不对、成果真不真」越容易失控。它不是凭空造流程而是站在软件工程质量设计的肩膀上文档效力层级借鉴 SDD规约驱动开发constitution → spec → plan → changesS4 开发落地严格 TDD红-绿-重构测试必须覆盖所有 Must Have每个计划转绿后立即对其 diff 做只读审查复杂领域引入 DDD统一语言、限界上下文多模块共享领域概念时必须先出领域模型文档。关键不在「用了这些实践」——TDD、代码审查、设计先行都是教科书常识真正难的是人守不住。BWorkflow 做的转化是把每一项「应该做」都翻译成一条机器可裁决、或人必须显式拍板的门禁——TDD 落成测试命令的退出码代码审查落成审查通过项从「靠自觉」变成「过不了就进不了下一阶段」。三档判定机器能判的不问人机器项「退出码 0 即过不解读输出」——判定标准压到最不依赖 AI 解读的形式查证项默认不出现仅异常/缺口时动态生成判断项定级、设计批准、价值验收由 runtime 代码强制——落库必须以人的身份工具物理上无法代答。跨阶段只认结果块杜绝伪验证下一阶段门禁只读上游报告的判定结果明确禁止用「文件存在」冒充通过。循环熔断同一验收项两轮修复仍失败且同根因强制升级为人工判断——防止 AI 在同一方向上无限试错。Web 项目为什么更得心应手诚实地说runtime 没有任何 Web 专属内置没有截图对比、没有浏览器集成它的 Web 亲和是结构性的——默认配置即 npm 生态验收阶段的命令位天然挂 e2e 测试可交互原型是设计阶段的一等产出物。机制是「任意命令 退出码」契约所以Web 生态越成熟e2e、视觉回归、性能预算都有现成工具机器项能覆盖的面就越大留给人的就只剩硬门禁上的价值判断。反过来C 项目就得自己先造出回归工具才填得满机器项——这也解释了为什么这套工作流在 Web 开发里最顺手。三个项目三张脸规律只有一条先问「不确定性藏在哪里」再决定门禁设在哪一层、人守在哪一个口。C 库的行为是确定的机器断言能覆盖到「静默正确性」人只看体验Agent 的 LLM 输出是概率的确定性门禁必须挡在自动路由之前人只守认证卡口交付过程的不确定性最「虚」——它不藏在某个模块里于是闭环变成了流程本身人机分工被制度化人只在最贵的几个点上拍板。结语以前验证算法库问的是「接口通不通、边界崩不崩」。这套闭环问的是三个更进一步的问题行为对不对场景断言、体验像不像视觉闭环、长跑稳不稳端到端稳定性。代码便宜了问题反而可以更贵——这大概是 AI 时代软件研发最划算的一笔投资。下一次开发前不妨问问Coding Agent这个工程怎么设计质量闭环。其它原文在我的飞书知识库内研发质量验证闭环启示我的AI积累笔记也包含了其它的学习知识、思考笔记、实践记录Being的AI积累。​