前言真正耗时的是构建一个“能测”的组件页面在前端组件测试的完整流程中最耗时的环节往往并不是“执行测试”本身。无论是验证新功能、完成版本回归还是复现真实用户场景自动化测试开始前都必须先构建一个完整的组件测试页面。它的作用是将抽象的组件能力还原为可运行的真实场景准备测试数据、组合相关组件、配置 API 参数、实现交互逻辑并将关键状态暴露给自动化断言。测试页面准备不足测试脚本便缺少稳定、可靠的验证对象。组件产品的通用性会进一步放大这项工作的复杂度。以 Wijmo 等企业级前端组件库为例即使只是“验证表格编辑功能”也可能需要覆盖嵌套编辑器、筛选、排序、冻结等 API 组合处理事件边界和真实用户场景中的交互顺序并兼顾 PureJS、Angular、React、Vue 等框架差异。组件越通用功能与 API 的组合空间越大测试页面的构建成本也越高。因此测试页面并非普通的功能 Demo。Demo 只需展示功能可用测试页面则必须做到结果可重复、状态可观察、行为可断言。它既要符合组件 API 的标准使用方式也要适配现有测试工程的依赖管理、目录结构与自动化测试规范。我们的测试环境采用由 SystemJS 在运行时加载模块的无构建方案。通用大模型更熟悉 Vite、Webpack 等现代前端构建流程生成的代码往往“符合通用前端开发习惯”却无法直接适配现有工程体系。每次开发前工程师都要重复同步组件知识、工程约束和测试规范效率因此被进一步拖慢。这正是 AI 代码生成容易失效的场景它很容易生成一个“看起来像 Demo 的页面”却难以直接产出一个“能接入工程体系、能稳定回归、能自动断言”的合格测试页面。为解决这个问题我们先用一个多月搭建了基于 LangGraph 的自定义 Agent希望实现端到端流程的完全可控随后又用约两周将组件测试页面生成与验证这条核心生产链路切换到 Skill 方案。在随后的一个季度内我们完成了 30 个任务并观察到复杂场景的首轮通过率从约 60% 提升至 92%典型页面的交付周期从约 4 小时缩短至约 30 分钟。需要先说明边界这并非将同一批任务在两种方案上重复运行的严格 A/B 实验。两个阶段的模型、文档、样例和验证能力都在持续演进因此下文数据反映的是生产链路整体演进后的阶段性结果不能将全部增益简单归因于 Skill 本身。即便如此这次演进仍回答了一个具体的工程问题面对规则密集的组件测试任务应该先自建复杂的 Agent 运行时还是先将领域知识和验收标准沉淀为可执行能力1. 为什么一开始要搭 LangGraph Agent最初选择 LangGraph 并非一时冲动。我们需要处理的是一条完整的端到端链路理解自然语言需求、查询组件资料、生成测试页面、准备并运行工程、分析错误甚至将外部问题的最小复现 Demo 转换为回归测试页面。当时团队决定自建一套可控的 Agent 流程。我们希望每一步都能接入相应的资料和工具并能根据结果分支、重试或进入失败处理流程。因此我们选择了 LangGraph它可以将模型、工具和业务逻辑拆分为独立节点再用状态和条件边描述流程如何继续、结束或回退。自然语言需求 - 需求分析 - 组件/API 查询 - 测试页面生成 - 构建与运行 - 结果判断 / 下一步处理在一个多月里我们围绕这条链路搭建了一个自定义 Agent主要能力包括自然语言生成测试页面输入组件、功能与交互描述Agent 即可分析需求并生成相应的页面代码。组件知识查询将组件 API 和使用说明纳入检索范围辅助模型理解属性、事件和实现方式。自主构建与运行处理示例工程或生成结果的依赖准备、运行和地址提取遇到构建失败时尝试由模型分析错误并给出修复方向。缺陷场景转换将外部问题的最小复现 Demo 转换为自动化测试工程中的回归测试页面。1.1 当时真正需要维护的是一份状态契约图结构本身并不难难在让每个节点对同一任务形成一致理解。这类 Agent 的状态可以抽象为TaskState requirement // 结构化需求与验收范围 apiFacts // 已查证的 API 事实及来源 constraints // 工程、框架、可测性约束 artifact // 生成的文件与测试接口 assertionPlan // 不随修复阶段改写的验收项 assertionResults // 每项断言的实际结果和日志 repairBudget // 剩余修复次数这份契约带来两个直接好处问题可以沿状态链路追踪失败不再只剩一段模糊的自然语言描述文件操作、构建和测试等确定性步骤也可以封装为受限工具无须让模型临场猜测执行命令。但它也暴露了后来的问题将apiFacts、constraints写入状态并不意味着生成节点一定会将其视为不可违背的前提。如果“生成代码”节点未被要求以这些事实和约束为输入并产出可检查的执行证据那么即使在图上增加检索或反思节点也无法自动让代码变得更正确。LangGraph 的检查点与恢复能力也需要被正确理解配置持久化存储checkpointer后它可以保存流程状态便于调试、回溯和恢复但解压、安装依赖、启动服务等外部副作用仍需由业务代码设计为幂等、可检测或可清理。恢复状态并不能自动消除外部世界中已经发生的操作。即便后来没有继续以 LangGraph 作为默认入口这段探索仍留下两条值得保留的工程经验为关键状态定义清晰的输入/输出契约以及为工具调用划定受限边界。后续的 Skill 设计并未抛弃这些原则而是将其纳入更轻量的任务封装。2. Agent 能跑起来但核心问题没有消失2.1 隐性领域知识没有变成硬约束为了让 Agent 理解组件 API我们加入了向量检索。但组件资料来源并不统一网页与离线文档的同步、切分和更新都需要维护不同的切片算法和检索逻辑也可能得到不同结果。检索只能提高资料的可获得性无法将这些分散经验自动转化为工程约束。问题的根源不在于缺少一个反思节点而在于组件测试依赖大量隐性领域知识什么样的数据才能保证结果可重复哪些状态必须以可读方式对外暴露哪些样例可以跨任务复用以及不同框架下哪些工程结构绝不能改动。这些知识零散分布在提示词、检索结果和开发者经验中模型每次生成代码时都可能遗漏其中一部分。2.2 RAG 能检索资料却未必驱动代码生成RAG 面临的问题并不止于资料维护。即使检索到了正确内容也无法保证生成阶段会将其视为必须遵守的事实。这暴露了一个常见误区“有 RAG”不等于“代码生成时拥有可靠知识”。如果资料未被组织成明确的规则、模板或输入契约检索结果仍只是上下文中的一段普通文本。更具体地说若生成节点无需列出所依据的 API 事实后续也没有断言检查这些事实是否被正确使用那么检索链路只能提高“模型看见资料”的概率无法保证“模型按资料实现”。2.3 页面能启动不等于功能已经被验证Agent 可以完成构建和运行并得到可访问的页面地址但这只能说明环境链路已经走通。它无法证明筛选功能确实改变了数据状态、编辑操作确实写回了数据模型或冻结和事件逻辑确实符合需求。早期流程缺少完整的自动检测闭环生成结果仍需人工逐项检查。对测试工程而言最核心的验收工作并未消除页面“能打开”不代表它已是可交付的合格测试页面。2.4 自建运行时放大了维护成本自定义 Agent 的灵活性背后是大量需要自行负责的部分状态字段、节点职责、路由逻辑、工具权限、错误分支、知识库更新、模型行为变化、日志和回归测试。每增加一项规则或功能都可能牵动流程、状态和提示词中的多个位置。这一个多月里我们完成的并非一份简单配置而是一套需要长期维护的运行时系统。对于动态、跨系统的任务这种投入可能值得但面对当前高频、规则密集的组件测试页面生成任务它逐渐显现出过度设计的特征流程很灵活代码生成的准确性和验证问题却没有被优先解决迭代速度也被维护成本拖慢。3. 复盘后的转折不是继续加节点而是换一个问题复盘后我们不再优先追求“能处理一切的通用 Agent”而是先解决“如何稳定生成符合组件测试规范的页面”这一核心问题。这里需要澄清LangGraph 与 Skill 并不是同一抽象层的直接替代品。LangGraph 是自定义 Agent 的流程编排层主要负责状态、路由、工具调用和失败分支Skill 则是面向领域任务的能力封装方案将任务说明、知识、规则、模板、脚本和评测组织为可复用能力由宿主 Agent 执行。第一阶段我们将“企业级”理解为尽可能多地自建编排能力完成这轮探索后才更清楚地看到当前核心任务的约束大多稳定且重复。随着通用编码 Agent 和工具链已能承担通用执行动作业务团队不必再为每个领域任务重建一层运行时。于是注意力从“让流程无所不能”转向“让领域约束可验证”。维度LangGraph 自定义 AgentSkill 方案团队主要维护什么节点、状态、路由、工具、重试、检索和监控知识、规则、模板、脚本、评测与领域适配擅长解决什么跨系统、长流程、动态路由、审批与恢复高频重复、边界稳定、上下文密集的领域任务稳定性的来源团队自行建设检查点、权限、观测和回归体系由任务契约、模板、规则和验证保证领域上下文与验收的一致性运行时可靠性仍依赖宿主环境主要限制运行时维护面广迭代一个领域规则常会牵动多处受宿主 Agent 和工具权限边界限制不适合承载所有动态流程本项目的适配度灵活但超出了核心任务的复杂度直接围绕“生成并验证规范测试页面”沉淀能力这并非“LangGraph 不如 Skill”的结论。真正的选型依据在于任务的不确定性来自哪里如果不确定性主要来自跨系统流程和动态决策编排层的投入值得如果不确定性主要来自领域知识、工程约束和验收规则优先将这些资产产品化通常更有效。4. 用 Skill 把隐性经验变成工程资产Skill 不等于把长提示词简单保存成文件。针对组件测试页面生成这一场景我们将前一阶段反复出现的知识和约束沉淀为四类工程资产并额外增加了一个横切的工具适配层。每类资产都直接对应 LangGraph 阶段的一个痛点。4.1 知识体系化内置先查证再生成我们将数百个组件和 API 条目、架构说明以及经过生产验证的使用模式整理成可按需读取的结构化参考资料。生成代码前系统会先核验 API 签名、语义、多框架差异和使用边界明确关键前提。关键不在于“资料很多”而在于将查询输出转化为结构化事实。例如一个生成任务在编码前至少要明确目标框架、组件版本、需要使用的属性/事件、已验证的样例模式、不可改动的工程入口以及必须暴露的测试状态。资料查询阶段只负责确认这些事实不直接产出代码代码生成阶段则必须以这些事实为依据完成实现。这样一来知识不再只是 RAG 返回的一段背景文本而会成为生成前的强约束事实依据团队也减少了为代码生成单独维护复杂向量知识库链路的投入。4.2 行为规则化约束缩小错误的自由度复杂组件生成效果不佳本质上是因为模型的可选解空间过大容易偏离工程规范。我们将易被遗漏的经验写成清晰、可执行的规则测试数据必须确定依赖来源必须受控全局事件必须限定作用域关键的非可视状态必须具备可读取的测试接口。规则当然不能神奇地保证结果正确却能有效缩小模型自由发挥的范围。面对组件嵌套、事件联动和数据状态等复杂场景AI 无须每次重新猜测项目约定而是在固定边界内实现需求特有的差异部分。一条好的规则最好同时说明“为什么”和“如何验”。例如“数据必须确定”不能只写成禁止随机数还要使验证能够重放同一组数据“状态可读”也不等同于随意读取组件私有字段而应约定使用公开 API 或显式暴露的测试接口。只有这样规则才是可执行的约束而非空泛的愿望清单。4.3 产出模板化驱动让模型只处理真正变化的部分我们为 PureJS、Angular、React、Vue 等技术栈分别准备了基础模板。模板负责统一目录结构、初始化骨架和共同约束模型只需处理本次需求特有的组件组合、数据和交互逻辑。这使生成过程中的错误集中在真正需要针对性思考的功能实现上而不再反复出现在文件结构、基础初始化等通用环节。模板也不应只是可复制的样板文件它需要保留稳定的测试挂点、生命周期位置、依赖加载方式和清理逻辑使生成结果从一开始就进入可验证的轨道。4.4 流程标准化管控把验收标准锁在代码生成之外我们将流程固定为一条可检查的闭环环境预检 - 需求与特性拆解 - API/模式查证 - 样例与模板定位 - 模板约束下生成 - 基于 Playwright 的测试脚本执行预定义断言 - 通过结构化结果报告 - 失败根因分析 - 定向修复 - 回到同一组断言这里最重要的设计不是“多跑几轮”而是让验收标准独立于实现代码。需求会预先拆分为带优先级的特性清单P0 是阻断交付的核心行为P1 是高复杂度任务必须覆盖的关键路径P2 是补充优化项。代码生成后修复可以参考既定需求、断言结果和错误日志但不得改写原始需求、期望值或验收脚本。未执行的验收项必须在报告中标记为“未覆盖”不能计作通过环境错误和超时同样属于“未完成验证”而非任务成功。“独立”不等于一定要换一套模型而是要保证被测实现代码无法反向改写验收依据。为使这一边界可执行P0 特性及其断言需要在生成代码前由需求方或经评审的固定模板确认并存入受版本保护的只读资产修复环只允许改动页面实现和明确允许修改的生成文件。每轮修复后执行器都会先校验验收资产的哈希或 diff 白名单再重跑完整的 P0/P1 基线。模型可以提出功能实现的候选方案却不能既定义 P0 的期望值又在失败后自行改写它。对于高复杂度任务验证清单会在生成代码前确定并固化对于低、中复杂度任务则只验证核心路径。这样可以避免让同一个生成过程临时发明实现、临时修改测试再宣布自己通过。验证也不只是检查页面能否加载而要检查三个层次动作是否发生、状态是否变化、最终行为是否符合预期。筛选输入框可以输入文字不代表筛选功能已经实现程序化断言还需检查筛选后的记录数和数据状态是否确实发生变化。失败不是流程终点而是下一轮修复的输入。我们会将失败归为环境/依赖、框架生命周期、API 语义、测试接口或业务交互等类别再将失败断言、实际状态和错误日志带回相应的实现环节。每次修复都应更贴近原始需求、保持代码质量并解决根因不得通过删除功能、修改预期结果或绕过异常制造“通过”的假象。自动修复最多尝试 3 轮。这个数字是防止无意义循环的安全上限而非通用的最优参数若达到上限后任务仍失败系统会保留失败项、已尝试的修复方案和未覆盖范围交由人工接管。一个典型的端到端例子以一个典型的表格测试页为例原始需求应拆分为下面的特性契约而非直接将一段自然语言交给模型特性验收条件验证方式F1确定性数据页面加载后固定展示 10 行、6 列数据读取公开数据源或表格公开 APIF2初始冻结初始冻结前 2 行和第 1 列读取组件公开的冻结配置F3行冻结切换点击按钮后冻结行在约定的两种状态间切换真实点击后读取冻结行数F4列冻结切换点击按钮后冻结列在约定的两种状态间切换真实点击后读取冻结列数F5冻结区域样式冻结区域使用约定的背景色定位代表性单元格并校验计算样式一次典型失败可能是页面可以正常打开行冻结按钮也能被点击但 F3 的实际值仍为 0。根因不应被笼统描述为“按钮不工作”后就让模型盲改而要落到可验证的具体类别例如初始化发生在目标框架的组件实例就绪之前或按钮只更新了局部变量而未更新真实的表格实例。修复完成后系统会重新运行 F1–F5 的全量断言而非只重跑 F3从而及时发现修复是否意外破坏了初始冻结或样式逻辑。这个例子说明一份合格的 AI 测试页任务至少应具备“自然语言需求 - 特性契约 - 实现 - 独立断言 - 根因修复 - 全量回归”这条可追踪的完整链路。4.5 通用浏览器工具不够时为被测对象补上领域语义Skill 的正常运行离不开浏览器测试工具的支撑。实践中我们评估了 Playwright 的两类接入方式通过 Model Context ProtocolMCP暴露通用工具能力或在 Skill 中组织工具调用、探测脚本和领域断言。二者并不互斥Skill 也可以调用 MCP我们调整的是工具抽象边界并非否定 MCP 协议本身。MCP 解决的是工具与 Agent 的连接方式并不会自动补齐领域语义。本文中的断言由 Playwright 测试脚本执行Playwright MCP 只是让 Agent 调用浏览器操作的可选传输层不能与 Playwright Test 的断言运行时混为一谈。以 Playwright MCP 服务为例它适合页面导航、点击、输入和 DOM 查询但其默认抽象以浏览器和 DOM 为中心。面对 SpreadJS 等以 Canvas 渲染为主的组件单元格、选区和工作表状态未必能从 DOM 中可靠推导仅靠通用点击和 DOM 结构也很难完成具备业务语义的编辑与验证。部分 Canvas 组件也会提供 ARIA、DOM 代理或公开 API问题不在于“Canvas 必然不可测”而在于不能仅凭通用 DOM 可靠推导全部领域状态。当然我们也可以为这类能力单独开发自定义 MCP 服务。但在这个聚焦的测试工作流中我们选择让领域适配器随 Playwright Skill 一起版本化而非维护一个独立服务。这并未消除探针的契约、权限和兼容性成本只是降低了当前单一工作流的接口协调成本如果同一能力需要被多个 Agent 或应用复用自定义 MCP 服务反而可能是更合适的边界。在 Playwright Skill 中我们将 Playwright 的浏览器操控能力与领域探针一并封装在受控的页面上下文中执行专门的查询/编辑脚本并将结果以结构化数据返回给断言步骤。一个 Canvas 组件的领域探针可以提供类似下面的契约readSelection() - { row, column, rowCount, columnCount } readCell(row, column) - { value, formula, displayText } setCell(row, column, value) - { changed, currentValue }探针只能调用组件公开 API 或显式暴露的测试接口不能读取或修改私有实现。需要验证真实用户输入路径时仍优先使用鼠标、键盘等真实浏览器交互探针用于准备可重复的前置状态或作为状态判定依据oracle检验交互后的业务结果。这样既不会将 Canvas 测试退化为“直接改内部状态”也避免仅凭像素或 DOM 猜测业务状态。工具形态适合的能力在本场景中的边界通用 Playwright MCP页面导航、DOM 交互、通用浏览器操作不能天然理解 Canvas 内部的工作表、选区、单元格等领域语义Playwright Skill 领域探针浏览器操控 组件状态查询/编辑 专项断言需要维护探针契约并随组件版本和测试规范持续更新这次尝试带来的经验是工具“能调用”不等于它“理解被测对象”。当被测产品超出通用 DOM 模型时应为其补充领域适配层。这里为 SpreadJS 构建的是独立的 Canvas 领域探针其他内部组件或业务层前端测试也可以按同样方式扩展而不必等待通用浏览器工具覆盖所有语义。4.6 运行边界可执行不等于可无限授权在企业工程中Skill 还需要在宿主 Agent 之外划定清晰的运行边界。生成和验证只能在目标工作区内读写环境检查、启动和测试应使用明确的脚本或命令白名单工具输出应尽量结构化避免将无关目录、凭据或配置带入上下文任务结束后无论成功或失败都要清理浏览器和临时进程。这些约束不属于“提示词优化”而是工程职责分层Skill 负责领域能力宿主负责工具权限、上下文隔离、重试和报告。没有这层边界任何看似方便的自主构建或浏览器控制都会重新带来维护和安全风险。5. 最终切换更快落地也更接近核心验收标准最终我们将组件测试页面生成与验证这条核心生产链路切换至 Skill。这里的“切换”并不表示 LangGraph 在所有场景都不再需要而是指日常高频的页面生成与验证不再以自建 Agent 图作为默认入口。5.1 相关成效阶段性运营观察统计范围为一个季度内完成的 30 个前端组件测试页面任务。我们将涉及多组件协作、API 组合、嵌套编辑或跨框架适配的任务归为“复杂场景”。下文的“首轮通过”按任务统计指首轮产出在未修改代码的情况下通过该任务规定的运行检查、工程规范、核心组件交互/API 组合及验证检查。仍需强调两个限制第一LangGraph 阶段的验证自动化覆盖并不完整早期结果包含人工核对Skill 阶段则将更多核对项转为可执行断言。第二30 个真实需求并非成对的同源样本模型版本、知识和模板资产的成熟度、组件版本及任务结构变化都可能共同影响结果。指标阶段性运营观察LangGraph 自定义 Agent 阶段Skill 阶段统计口径与边界复杂场景首轮通过率约 60%92%首轮无需人工修改代码即可通过该任务约定验收的任务占比前期含人工核对后期更多由断言执行典型测试页面交付周期约 4 小时约 30 分钟从需求确认到页面首次通过验收的端到端耗时来自固定类型页面的代表性可比任务不代表所有任务的平均值人工复核投入约 2 小时约 5 分钟仅统计工程师阅读产物、处理验证结果并决定是否需要修改代码的有效工作时间自动化执行、环境启动和等待时间不计入该项也不包含前期资产建设成本这组数字中最值得关注的不是“生成速度”而是工程师的人工复核投入由约 2 小时降至约 5 分钟。这意味着更多判断由可执行断言承担并不等同于整套验证流程的机器执行耗时也只有 5 分钟。相应地Skill 的维护成本并未消失只是从维护图节点和运行时转移为维护知识、规则、模板、断言和领域探针。5.2 代表性案例覆盖 50 组件的 Vue 到 Angular 测试页面迁移除单个页面生成外我们还完成过一项跨框架迁移将一个覆盖 50 组件的测试页面从 Vue 迁移至 Angular。这并非简单的语法替换迁移过程中需要同时处理两种框架在组件组织、数据绑定和生命周期上的差异并逐一排查组件 API、页面结构和测试行为带来的错误。团队估算的纯人工工期至少为 5 个工作日在 Skill 辅助下实际用 2 个工作日完成。Skill 在其中承担的并非“一键转换”角色而是将框架模板、组件知识、既有实现模式和验证步骤串成可重复执行的流程先识别原页面的组件和功能点再匹配目标框架的模板与实现方式生成迁移结果最后通过自动化断言发现并修复差异。一个典型的框架差异是组件实例的可用时机。Vue 页面中依赖ref和挂载后回调的初始化逻辑不能机械地替换为 Angular 的类字段若在视图子节点尚未就绪时读取组件实例页面虽能渲染、按钮也可显示但实例配置和测试接口未必真正就绪。特性验收会将“组件已初始化”和“交互后实例状态变化”拆成独立断言失败后再将初始化逻辑迁移到正确的生命周期或组件就绪回调并重新执行整页验收清单。这正是迁移中最耗时的部分不是简单替换模板语法而是识别框架生命周期、绑定语义和组件实例边界。在这次迁移中Skill 将高频排错路径固化下来减少了团队重新查找资料和试错的次数这一案例用于说明工作方式不代表其他框架或组件组合都能获得同等收益。6. 可迁移的工程原则这次实践的价值不只在于换了一套方案。无论使用哪种组件库、Agent 或 Skill下面几条都可作为通用经验。先固定验收合同再让模型写代码。将自然语言需求拆成可验证特性区分 P0/P1/P2并将 P0/P1 的期望值固定在修复环之外。代码生成与测试生成不能共用一份可随意改写的“答案”。把确定性动作交给脚本和模板。环境检查、模板初始化、格式检查和测试执行不应每次都由模型临场决定。将它们封装为受限脚本在前提不满足时快速失败并返回结构化结果能减少随机性和无效重试。把知识拆成事实、规则和样例而不是堆进长 Prompt。将 API 事实放入参考资料将工程边界写成规则将代码结构固化为模板并将已验证页面作为模式参考。每类资产都有独立的更新节奏也更容易定位某次质量回退的来源。按复杂度分配验证深度并诚实报告覆盖范围。简单任务验证核心路径复杂组件组合先生成检查清单再逐项执行。已验证通过、验证失败和未覆盖项必须分开报告超时和环境错误不能默认成功。为非 DOM 组件建立公开、受控的领域探针。优先使用真实用户交互再通过公开 API 或显式测试接口读取业务状态不要靠截图判断全部逻辑也不要通过组件私有字段“验证”成功。把 Skill 当作需要版本化的工程资产。每次改动知识、规则、模板或探针都应在一组脱敏或合成的基准任务上回归同时限制可访问的工作区和命令范围。没有评测和权限边界Skill 很快也会变成另一种难维护的自定义系统。结语从自建 LangGraph Agent 到 Skill我们经历的不只是一次技术迭代更是一次问题聚焦从追求完全可控的通用流程转向优先解决高频、稳定、规则密集的组件测试任务。LangGraph 仍适合跨系统协调、复杂审批、长时运行和动态任务路由Skill 则更适合将稳定的领域知识和验收流程封装为可重复执行的能力。两者也可以组合由编排层处理真正复杂的跨系统流程由 Skill 负责具体领域任务。关键不在于一开始搭出所有能力而在于先判断瓶颈究竟在流程还是在领域知识与验收。对前端组件测试而言最终衡量的不是 Agent 是否拿到了运行地址而是测试页面能否接入工程、需求是否真正实现、断言是否真实执行以及失败是否被完整保留。这也是我们用两周切到 Skill 的原因它更直接地解决了当时最昂贵的问题。扩展链接葡萄城产品 MCP 服务