同一个登录 Skill，Trae 和 WorkBuddy 各跑了一遍
我有一个登录 skill：打开云大低代码平台，走统一身份认证登录，进指定应用的 IDE。它是给 WorkBuddy 写的，一直挺稳。这次用 Trae 把同样的流程实测了一遍，对比差异。
对比结果
| 环节 | WorkBuddy | Trae |
|---|---|---|
| 等登录 | 每 5 秒轮询页面标题 | browser_wait_for 条件等待，满足即返回 |
| 调用方式 | 一次调用做一件事，登录前约 8~10 次 | Exec 沙箱批量执行，登录前只用 2 次 |
| 页面感知 | 可见 DOM，内容大 | 可访问性快照，compact 模式 |
| 移交登录 | 文字提示 + 轮询检测 | 正式移交工具，用户操作完自动交回 |
结论：流程骨架不用改（登录必须人工、已知 appName 直达 IDE、SSO 复用），差距在编排层，Trae 调用次数约省一半。但真正值钱的是实测暴露的坑。
实测暴露的四个坑
-
标签页漂移：移交控制权时没锁定标签页，我登录后从开发中心点进应用开了新标签页，AI 的上下文就跟着活动标签漂走了。修复：移交时显式传 viewId。
-
恢复控制权后静默：控制权交回后，AI 发现目标已达成，一个动作没做直接输出总结——用户视角就是「AI 没接管」。修复：交回后先快照 + 播报，再继续。
-
AI 的假设被实测打脸：Trae 声称可用一次 JS 提取从页面解析 appName。实测开发中心卡片不是
<a>链接，DOM 里根本没有 appName。原 skill「点击卡片读 URL」的兜底是必要设计。 -
自作主张跳过确认：清单里只有一张卡片，AI 判断「询问是多余往返」，没问我就直接进了应用。被抓包后承认：「快照只见一张卡片」不等于「只有一个应用」——筛选、分页都可能藏着别的。修复：应用选择必经确认，单应用也不例外。
最终方案
坑修完，把 skill 重构成 WorkBuddy / Trae 双运行时兼容：Step 0 探测运行时自动选模式，能力映射表给每个操作两种绑定，6 条不变量两种运行时都遵守。流程：导航 → 三态判定（登录页 / 开发中心 / IDE）→ 登录页则锁定标签页移交用户、交回后先播报 → 开发中心则确认选择应用、点卡片读 appName → 直达 IDE 并验证。
skill 已更新到仓库：https://github.com/na57/skills/tree/main/ynu-primeton/ynu-lowcode-login
写在最后
速度差异是真实的，但它快在编排，不在本质——登录该人工还是人工。真正可复用的是这 5 条规则：
- 多标签场景显式锁定上下文
- 状态变化要播报，静默正确等于没反应
- AI 的假设要实测，别直接写进 skill
- 交互确认不能省
- 行动之后要验证
这些写在 skill 的「不变量」里，换什么工具都成立。