审查建议加入组件目录导入，方向看起来更规范了；真正启动应用时，它却找不到组件类型。最终四个 QML 文件零警告，是修正和重新验收后的结果，不能反推中途故障的检查时序。
这不是一句"AI 又写错了"就能解释的失败。QML Review 建议加入组件目录导入，静态检查的方向没有错；资源别名仍把组件文件压平，运行时看到的路径和审查时假设的路径不是一回事。
那一刻我才确定，这次 Qt Agent Skills 实测最值得分享的不是绿色数字，而是：部分规则留下了读取证据，也不等于工程在真实环境里一定正确。
我没有从 12 个 Skill 开始堆上下文
为了让结果可回溯，我把 Qt 官方 Agent Skills 仓库固定在提交 71d6c10。这个快照中共有 12 个 Skill：Review 2 个、Process 5 个、Conceptual 3 个、Tool 2 个。
演示项目只需要项目结构、QML 实现、审查、测试生成和测试运行，所以我取了 5 个：
具体是 qt-cmake-project、qt-qml、qt-qml-review、qt-qml-test 和 qt-qml-test-run。
我的考虑并不是"少就是先进"，而是要知道每条规则为什么进入任务。把 12 个全装上，只能证明目录存在；只有保留读取和执行证据，才能说明它怎样参与了工作。
新会话记录确实证明生成源码前读取了 qt-cmake-project 和 qt-qml。另外三项不能从最终代码风格反推为"隔离会话已自动触发"，所以后续按官方 Skill 说明在本地完成。
这给我的第一个工程启发是：Skill 的使用也要可观测。否则我们很容易把"结果碰巧符合规则"误写成"规则实际驱动了结果"。
18→0 是起点，不是终点
项目是一个独立的 Qt 6、CMake、QML 小应用，只展示 Build、Test、Review 三张阶段卡片。点击 Run Demo 后，状态按 Pending、Running、Passed 变化，不读取私人项目数据。
生成后，确定性检查首次发现 18 条问题，修正后归零。Qt 6.8.3 下，最终四个 QML 文件的 qmllint 也达到 0 警告。
不能把最终静态检查通过，当成全过程一次写对。中途的资源别名故障提醒我：静态规则与运行时的资源布局必须分别验收。
因此我把测试和运行拆开核对：JUnit 10/10，其中包含框架初始化与清理用例；CTest 1/1；最后让应用真实运行 4 秒，并检查 QML 加载错误为 0。
第二个工程启发是：不同绿色结果有不同含义。18 → 0、qmllint 0、JUnit 10/10、CTest 1/1 和运行 4 秒无 QML 加载错误，分别覆盖规则、静态分析、测试报告、测试入口和启动行为。把它们压成一句"全部通过"，会失去定位回归所需的层级。
真正花时间的是四个失败分支
第一个失败来自 Ninja。构建停在编译器 ABI 的锁等待，换到另一套已经存在的构建入口后才继续。它提醒我，构建命令没结束不一定是源码错了，工具状态也属于证据链。
第二个失败来自中文源路径。qmlimportscanner 解析异常，最后在文件哈希一致的 ASCII 临时副本中完成构建。这里能证明的是"同一份源码在该临时路径中可构建"，不能偷换成"中文路径问题已经解决"。
第三个失败就是开头的资源别名回归。审查修正之后必须重新启动，因为静态规则不知道最终资源布局是否仍把组件压平。
第四个失败不是技术错误，而是授权边界。我尝试让隔离会话自动触发审查、测试和测试运行，但那条路径涉及把源码交给外部执行环境。没有获得授权，流程就停止了，没有为了凑齐自动化证据绕过去。
第三个工程启发是：失败需要分类。Ninja ABI、中文路径、资源别名、未授权外部写入分别属于环境、路径、运行和数据授权。把它们都归为"Skill 失败"并不准确，把它们从成功故事里删除同样不准确。
Skill 真正改变的是规则的载体
我现在更愿意把 Agent Skill 看成一份能跟着仓库演进的工程说明。Prompt 负责这一次要做什么，Skill 负责这类任务通常怎样做，MCP 则连接外部资料或工具。三者能组合，但谁都不替代最终验收。
这类说明的现实价值，是把项目结构、QML 约束、审查步骤和测试入口从临时对话移到可维护资产中。团队可以审查它、更新它，也能追溯某个版本下 Agent 接受了哪些规则。
它不会自动修复构建器锁，不会保证所有路径兼容，也不会让静态检查覆盖资源系统，更不能替人跨过未授权的数据边界。没有可运行环境和测试入口的项目，也不会因为加入 Skill 就突然拥有工程基础。
这一次，我只下一个有边界的结论
在固定提交 71d6c10、Qt 6.8.3 和这个独立最小演示中，选出的 5 个 Skill 覆盖了生成、构建、审查、测试和运行所需的主要规则；最终的确定性检查、qmllint、JUnit、CTest 与 4 秒运行验收都有明确结果。
但这只是一套环境里的一次实测。它不能外推成 12 个 Skill 永久不变，也不能保证大型项目、其他工具链或长期迭代得到同样结果。因为没有设置无 Skill 对照组，我也不会声称它提高了多少效率。
对我来说，Qt Agent Skills 最值得借鉴的不是"万能提示词"，而是把工程要求变成可观察、可审查、可版本管理的资产。绿色结果仍然要靠一层层重新跑出来。
如果下一篇只拆一个环节，我最想继续验证 qt-qml-review 能否稳定抓住真实回归。你更想看审查、测试生成、CMake 约束，还是 QML 性能分析？
可从公开演示仓库回看项目，也可对照 Qt Agent Skills 官方仓库与Qt 官方 AI 开发工具页。
补充说明：Build、Test、Review 的状态切换只是 UI 模拟，不是界面真的执行 CI。本文是 2026-08-30 历史实测复盘，本轮没有重新运行 Qt 测试。
插画为 AI 辅助生成的解释示意，不作为运行截图或数据原始证据。