难道现在写技术文章的评判标准变成了 “越排版混乱、越语无伦次就越像人写的” 吗？😂

        全文每一个字都是我自己敲的，连段首的缩进空格都是我一个个手动调的，“笔者” 也是我一贯的行文习惯。辛苦梳理的干货被一句 “AI 味” 盖章，确实挺让人哭笑不得。

        不过我也反思了一下，可能是我这篇逻辑理得太顺、排版修得太齐了、截图给的太好了、链接给的太全了。下次要不故意敲错几个字、少打个标点，是不是就符合您对 “人类手写” 的刻板印象了？

        最后呀，我特意去拜读了一下您过往的文章，发现您在排版上似乎稍微有点……不拘小节。为了提升您以后的阅读体验，送您一个段首缩进空格的排版呀，不用感谢我：
“        ”

        哈哈，这话有点像"既然有 IDE 自动补全，干嘛还学写代码"。

        我非常支持用 skill-creator 来加速写 Skill，这叫"善假于物也"。但你要是连 Skill 的门道都不懂，丢给 skill-creator 的需求不是太模糊就是太随意，最后生成的 Skill 也就是个"能跑但不好用"的东西。

        我的看法很简单：先搞懂 Skill 怎么设计（这篇文章讲的），再用 skill-creator 帮你实现和迭代。这样才叫 1+1>2。

        AI 写 skill 当然是可以的，但是实际工作中的 skill 沉淀，在由 AI 参与的基础上，非常有必要人类去反复测试 skill 的效果。而这个过程中，你可以结合 AI 测试，但是你不能不懂 skill 吧，一个优秀的 skill 是需要雕琢的，不是一蹴而就的。
        当然了，我非常支持在写 skill 的时候结合 AI，skill 本质上就是 AI，而你写 skill 结合 AI 固然也是你 AI 意识的外显。

        这两个问题确实硬。

        轨迹每次不一样怎么测？我中篇那张断言类型表其实就是答案。轨迹断言断的不是"第 N 步必须调 tool_A"，那跟写死脚本没区别。断的是语义属性，比如 must_order 要求"必须先 Read 再 Edit"，中间插几个 GrepTool 无所谓，只关心 FileReadTool 出现在 FileEditTool 之前就行。这跟 Google Agent Quality 白皮书里的 Outside-In 思路一致：先看结果对不对，不对再打开黑箱查轨迹。LangSmith 现在也是这么干的，记录完整轨迹然后用 LLM-as-Judge 打分，我下篇的 TrajectoryCollector 做的事差不多。

        没调 tool 直接返回怎么测？这个用我中篇 7.1 的语义等价断言。Agent 没调 tool 不等于没干活，关键看答案对不对。Ragas 的 faithfulness 和 answer relevance 就是干这个的，不关心你中间调没调 tool，只看最终答案是否忠实于上下文。DeepEval 的 G-Eval 同理。所以无 tool 调用的场景，跳过轨迹层，直接在结果层做 LLM-as-Judge 就行。不过有个坑，下篇踩坑实录里提过：LLM-as-Judge 有裁判偏差，GPT-4 偏保守，Claude 偏宽松。我现在的做法是 3 个模型投票取多数（成本可控，稳定性也够）。

        通用方案的话，目前没有"装上就能用"的，但思路在收敛。核心就是三层：统一轨迹格式（把各平台的日志抽象成 reason→act→observe 循环，写个适配器翻译）、平台适配器（LangSmith 帮你做了，自研平台自己写，我下篇的 TrajectoryCollector 就是 Claude Code 的适配器）、评估策略层（轨迹断言 + LLM-as-Judge + 效率评估，跟平台无关）。AgentBench 和 MCP-AgentBench 在做类似的标准化，但目前还是学术阶段，离工程落地有距离。

        哈哈，又被你蹲到了。你这追更速度确实快 😂

        DeepEval 我之前文章里提过，但只是选型对比层面，没深入。要出实践专题的话，我自己得先踩够坑才行，现在素材还不够。手上还有几个选题排着，短期内排不上。

        这个选题我记着了，等踩完坑再来写。

        顺着你这个思路再想一层：如果现在真是 AI 泡沫期，泡沫破了之后，哪个工种 hc 反而能涨？

        我赌测试。

        泡沫期大家都在说"AI 都能写代码了还要测试干嘛"，测试被严重低估。但泡沫一破，你要面对的问题就不是"能不能写得快"了，是你根本不知道 AI 写了多少有坑的代码在里面。

        AI 吐出来的代码量一大，藏在里面的逻辑缺陷、幻觉引入的奇怪分支、压根没法靠读代码发现的问题全冒出来了。到时候团队才会意识到，验证这些代码花的成本，比手写高到不知道哪里去了。测试就不是可有可无了，你的系统靠不靠谱，最后都得从测试这道门过。

        而且 AI 系统本身的不确定性还带出来一批新活儿——模型鲁棒性怎么测、对抗样本怎么防、数据质量怎么验证，这些 AI 自己干不了，得人来。既懂测试方法论又懂模型行为的人，现在市场上就没几个。

        所以你说的"AI 没减轻测试工作反而添乱"，我太同意了。但正因如此，测试可能是少数几个泡沫破了之后 hc 会结构性反弹的方向。现在被踩得多狠，到时候弹得就多高。

        感谢，GEP 这套意图 - 路径分离加环境指纹比对的思路不错，维护的坑直接交给机制兜底，比靠人填靠谱多了。我之前搞 AI 自愈也在解决类似问题——页面一变脚本就挂，我们当时在用例层做了自动修正，定位变了能自己改回来，但路径规划那层没下这么重的手，没想着把不好使的路径直接淘汰掉。evomap 周末我去啃一啃。

        感谢解答，思路很实用，我得慢慢消化下。

        我们之前也做过类似 get_page_snapshot 的提取，但没做到 getBoundingClientRect 可见性过滤那一步，信息冗余确实大。压到 40-50 个关键元素这个数字挺有参考价值，回头我们试试按这个方向调过滤策略。

        Canvas 单独建感知通道这个做法我没想到，我们之前一直想在通用方案里硬塞 Canvas 的处理。降级链让 Agent 自己选层级，比人工定优先级灵活——我们之前脚本容易坏，很大一个原因就是定位策略写死了，环境一变就挂。

        另外想问下，Canvas 里如果有分层或者遮罩，app.stage 遍历能直接拿到层级关系吗？点击穿透和视觉遮挡的情况你们怎么处理的？

        感谢分享，读下来跟我们项目的经历一模一样。元素定位我们也是抛弃纯截图，走 DOM 提取 + 视觉辅助的路子。

        想请教个实际碰到的头疼问题：你们用无障碍树的时候，Canvas 里自定义组件嵌套深了、或者页面 DOM 层级特别多，树的稳定性还能扛住吗？定位准不准？我们在这块反复踩坑，优化了几轮还没完全搞利索。

你好，我最近一直在写一个开源项目，也是和 skill 相关的，但是偏向于 Agent。你提到的 skill 和 MCP 我深有体会，后面可以单独拎出来讲一讲，敬请期待～