
AI 编程工具、研发智能体、自动化生成平台正在越来越多地进入真实研发流程。但很多团队真正落地之后会发现一个问题AI 能生成不代表生成得稳定。 AI 能完成任务不代表过程可控。 AI 最后结果看起来对不代表中间链路没有风险。 Agent 执行了很多步骤但每一步为什么这么做、调用了哪些 Skill、消耗了多少 Token、在哪个环节出现质量波动往往仍然是一个“暗箱”。当 AI 开始参与需求分析、代码生成、测试设计、缺陷分析、研发协同之后企业真正需要解决的已经不只是“AI 能不能用”而是AI 的结果能不能评测 AI 的过程能不能观测 AI 的质量问题能不能回溯 AI 的执行数据能不能反哺下一轮优化在本次大会中中兴通讯 AI 技术教练刘振凯将带来主题分享《从暗箱到透镜——SpecDrivenDev 的评测与可观测性全链路闭环工程实践》这场分享将系统拆解 SpecDrivenDev 场景下如何通过评测、评审与可观测性构建一套可闭环、可追溯、可持续优化的 AI 工程质量体系。一、AI 工程化落地不能只看最终结果过去的软件质量体系更多关注测试结果、缺陷数量、覆盖率、上线质量等指标。但 AI Agent 参与研发之后质量问题变得更加复杂。因为 AI 的输出不是简单的确定性程序执行而是由模型能力、上下文质量、Prompt 设计、Skill 调用、工具链协同、任务拆解方式等多个因素共同决定。同样一个需求AI 今天可能生成得很好明天换一个上下文就开始跑偏。同样一个 Agent在线下评测中表现不错进入真实研发流程后可能因为日志缺失、工具调用异常、上下文污染、Skill 编排不稳定导致整体质量下降。所以AI 工程化真正要解决的不是“能不能生成”而是生成质量是否有稳定基线执行过程是否能被实时评审Agent 的调用链路是否可观测质量问题是否能定位到具体环节线上数据是否能回流到评测体系整个系统是否能持续进化这也是本次分享中 SpecDrivenDev 评测与可观测性闭环要回答的核心问题。二、“锚-盾-眼”SDD 评测体系的三重奏模型刘振凯老师将在分享中系统阐述 SDD 评测的 “锚-盾-眼”三重奏模型。这套模型可以理解为 AI 工程质量治理中的三个关键支点。线下评测是“锚”线下评测用于建立质量基线。它帮助团队判断当前模型、Agent、Skill、Prompt、流程编排到底处于什么水平。只有先建立基线后续模型升级、工具调整、流程优化才有可比较、可验证的依据。线上评审是“盾”线上评审用于守住过程质量。AI 在真实研发流程中运行时输入更复杂任务更动态风险也更难提前覆盖。这时就需要在线上通过实时评审机制形成质量门禁避免低质量产物直接进入后续研发环节。可观测性是“眼”可观测性用于看清 Agent 的执行过程。包括任务拆解、上下文使用、工具调用、Skill 执行、Token 消耗、异常节点、链路时序等。它让原本不可见的 AI 执行过程变成可分析、可度量、可优化的数据资产。这三者不是孤立存在的。线下评测解决“有没有质量标准” 线上评审解决“过程是否可控” 可观测性解决“问题是否看得见、追得回、改得动”。最终形成一个完整闭环评测 → 评审 → 观测 → 回流这也是 AI 研发质量体系从“事后验证”走向“全程体检”的关键路径。三、从“结果导向”到“过程可溯”很多团队刚开始做大模型评测时容易把评测理解为“看最终答案对不对”。但在真实工程场景中只看结果远远不够。尤其是在 SpecDrivenDev 这类围绕规格、需求、设计、实现、验证展开的研发模式中AI 不只是生成一段文本或代码而是在参与整个研发链路。这意味着评测维度必须从单一结果扩展到过程质量。比如需求理解是否准确 任务拆解是否合理 上下文引用是否充分 Skill 调用是否匹配任务目标 工具执行结果是否被正确理解 生成内容是否符合规格约束 异常场景是否有识别和处理 中间步骤是否可追踪 最终结果是否能回溯到输入依据当 AI Agent 介入研发流程之后真正有价值的评测不应该只停留在“这次答案对不对”而要进一步回答它为什么会得到这个答案 这个答案是否稳定可复现 如果错了错在哪一个环节 下一轮如何让系统自动变得更好这也是从“暗箱”走向“透镜”的核心变化。四、线下评测先建立质量基线在线下评测阶段重点是构建可复用、可对比、可持续迭代的评测体系。其中有两个关键能力。第一个是 评估器设计。评估器不是简单的打分器而是要把业务规则、工程规范、质量标准和模型判断能力结合起来。不同任务需要不同评估器。比如需求分析任务关注的是完整性、准确性、歧义识别能力 测试用例生成任务关注的是场景覆盖、边界条件、异常路径、可执行性 代码生成任务关注的是可读性、可维护性、安全性、规范一致性 Agent 执行任务关注的是任务拆解、工具调用、状态流转和最终产物质量。第二个是 评测集构建。评测集决定了评测体系的上限。一个好的评测集不只是堆样本而是要覆盖真实研发场景中的高频问题、复杂问题、边界问题和历史质量问题。如果评测集只覆盖简单任务评测结果就很容易“好看但不可信”。所以线下评测的价值不只是给模型打分更是帮助团队建立一套稳定的质量基准。有了基线后续模型升级、Prompt 调整、Skill 改造、Agent 编排优化才有可靠的对比依据。五、线上评审用 Skill 驱动实时质量门禁线下评测解决的是基准问题但 AI 真正运行在研发流程中还需要线上评审机制。因为真实场景中的输入更复杂任务更动态很多风险无法只靠离线评测提前覆盖。这时线上评审就像一道“盾”。它不是等到最终产物完成后再做一次检查而是在 AI 执行过程中通过 Skill 驱动的方式进行实时质量门禁。例如当 AI 生成需求分析结果时可以触发规格一致性检查 当 AI 生成测试用例时可以触发覆盖率、边界值、异常场景检查 当 AI 调用工具链执行任务时可以触发权限、路径、上下文、调用结果校验 当 AI 输出研发产物时可以触发规范性、可维护性、安全性评审。这种机制的价值在于AI 不再是“生成完再说”而是在生成过程中就被持续约束。这对于企业级 AI 工程落地非常重要。企业真正关心的不是一次 Demo 能不能跑通而是当 AI 进入真实研发链路后能不能稳定、可控、可治理。六、可观测性让 Agent 的每一步都看得见本次分享中一个非常值得关注的重点是 CC-Observe 的可观测性实践。AI Agent 的执行过程往往涉及多轮对话、工具调用、上下文读取、Skill 执行、结果汇总和异常处理。如果没有可观测性团队只能看到最终输出却很难知道中间发生了什么。CC-Observe 重点解决的就是这个问题。本次分享将展示包括以下方向在内的工程实践日志全自动转换将 Agent 运行过程中的日志、调用链路、执行状态转化为可分析的数据结构降低人工排查成本。六维 Token 量化不只是看总消耗而是从多个维度拆解 Token 使用情况帮助团队识别成本浪费、上下文冗余、关键步骤消耗异常等问题。多智能体协作分析当多个 Agent 或多个 Skill 共同完成任务时可观测体系能够帮助团队看清不同角色之间的协作关系、责任边界与问题来源。Skill 时序可视化把 Skill 调用顺序、执行耗时、输入输出、异常节点可视化让复杂链路不再依赖人工猜测。这些能力的意义在于AI Agent 不再是一个只给结果的黑盒而是变成一个可以被观察、被分析、被优化的工程系统。七、从评测到回流让质量体系自己转起来真正成熟的 AI 工程体系不应该只停留在“发现问题”。更重要的是把问题转化为可持续改进的数据资产。这也是“评测 → 评审 → 观测 → 回流”闭环飞轮的价值。线下评测发现模型或流程的基线问题 线上评审拦截真实过程中的质量风险 可观测性定位问题出现的具体环节 回流机制再把这些问题沉淀到评测集、规则库、Skill 优化、Prompt 策略和 Agent 编排中。这样AI 质量体系就不再是一次性项目而是可以持续进化的工程机制。每一次异常、每一次低质量输出、每一次调用失败、每一次 Token 消耗异常都可以变成下一轮优化的输入。这也是 AI 研发从“靠经验调 Prompt”走向“靠体系做治理”的关键分水岭。八、为什么这场分享值得研发、测试、效能团队重点关注这场分享的价值不只在于介绍一个评测平台或一个可观测工具。更重要的是它回答了企业在 AI 工程化落地中必然会遇到的几个核心问题AI 参与研发之后质量基线如何建立 Agent 执行过程如何被看见 线上过程质量如何实时守住 评测结果如何反哺系统优化 从需求、规格、代码到测试如何形成完整闭环 大模型应用如何从“能用”走向“可信、可控、可持续优化”对于正在推进 AI 编码、AI 测试、智能研发平台、Agent 工程化、研发效能平台建设的团队来说这些问题都非常现实。尤其是在企业内部AI 工具如果无法评测、无法观测、无法追溯、无法治理就很难真正进入核心研发流程。从这个角度看SpecDrivenDev 的评测与可观测性实践本质上是在探索一条更工程化、更可信的 AI 落地路径。九、讲师介绍刘振凯中兴通讯技术教练中兴通讯 AI 技术教练拥有近 10 年中兴通讯无线研发经验。目前主导公司级大模型评测平台和可观测工程建设工作同时参与大模型语料工程、模型训练等相关工作。本次分享将结合中兴通讯在 AI 工程化、模型评测、可观测工程与 SpecDrivenDev 实践中的真实经验系统拆解从“暗箱”到“透镜”的全链路闭环建设方法。