「AI 调试接入」预研结项报告（冈子 · 2026-09-17）

目标：研究「微信开发者工具 AI 调试」如何接入我们的工作流（走查/验收自动化）。

结论：两线已探清——①「agent.skills」= 小程序 AI 开发模式（产品级·单独立项）②「自动走查」暂无成熟通路（SDK 不兼容）——眼下验收走机位人工，AI 线列为中期机会。

一、发现 1：agent.skills 的真实身份（重要认知修正）

• 它不是「调试小工具」，而是微信「小程序 AI 开发模式」的接入体系：将小程序功能抽象为原子接口/原子组件，封装成 SKILL，供 AI（智能体）调用——配合 AGENTS.md（小程序智能体定义）构成「小程序即智能体」的新形态；
• 官方生态已有配套工具（npx mp-skills：把现有小程序改造为支持 AI 开发模式；skillhub 的生成/校验 Skills）；
• 判定：这是产品级机会（让「神山秘境」可以被 AI 调用/提供 AI 服务——与抖音端/多端同级），建议单独立项评估，不并入当前验收工作流。

二、发现 2：「自动走查」通路实测

• miniprogram-automator（官方自动化 SDK）：最新版 0.12.1——与新版开发者工具（2.02.2607271）实测不兼容（connect 报内部错误 / launch 挂起）——「脚本自动走查」暂无成熟通路（降级 IDE 不划算）；
• 微信生态重心已转向 agent 体系——老自动化通道在弱化——建议作为「工具生态观察项」（若 automator 更新或 agent 体系开放普通项目接入，再启用）。

三、可用工具链（CLI·已实测可用）

四、结论与建议

1. 验收路径（不变）：机位真机回归（人工·协调包已备）——不等任何 AI 工具；
2. AI 线（中期机会）：「小程序 AI 开发模式」立项评估（产品级——可让平台长出「AI 服务」能力）；
3. 观察项：automator/agent 体系对普通项目的开放进展——有更新即复测；
4. 可选顺手项：如团队需要，「预览版一键分发」脚本我可以做（cli preview 封装）。

边界声明：本预研全程只读（未上传/未发布/未改项目文件）；cli upload 未触碰。

-- 冈子 2026-09-17（预研结项）

六、补充实测（当日深夜 · 探到底）

用户追问后补测最后两个未闭合点，结论完全清晰：

1. agent get-dom 的 target 仅限 card / detail-page——即：取的是「Agent 对话卡片/详情半屏」的 DOM——cli agent 整个体系服务对象 = 小程序的「AI 界面（Agent UI）与技能（skills）」——不是通用页面调试器；
2. agent tool 系一切子命令均要求 agent.skills 项目配置（实测复现）；
3. 完整图景（最终版）：

| 需求 | 通道 | 状态 |

|------|------|------|

| 普通页面（93 页）运行时自动走查 | automator（老）/ agent（不走普通页） | ❌ 暂无直路——归机位人工 |

| 提交级静态验收（规范/接线/占位/违禁词） | 验收机器人（本日已上线） | ✅ 可用 |

| AI 功能/Agent UI 的自动验证（未来） | cli agent（需项目接入 AI 模式+skills） | ⏳ 随「AI 模式」立项启用 |

| 深度业务验收（金路径/真机） | 机位真机回归 | 🔄 计划中 |

1. 给用户的一句话：「微信工具接口」的正确位置=未来 AI 功能的上线质检；眼下「不用人工检查」的解法=验收机器人（静态）+机位（运行时/业务）。

-- 冈子 2026-09-17（六节补录）