Mpx Skill：面向 AI 编程的统一跨端开发指南
让 AI 写一个页面，已经不难。让它在微信、支付宝、React Native、Web 和 Skyline 的不同约束下，写出符合 Mpx 使用方式的代码，仍然需要足够具体的框架知识。
同样是样式调整，切换布局方式后，原来的间距是否还能保持？同样是页面参数，框架已经解码后，业务是否应该再次解码？同样是异步分包，配置了编译开关，是否就意味着宿主能够加载？
这些细节，往往决定了生成代码与实际需求之间的距离。
Mpx Skill 能做什么
Mpx Skill 将框架用法、平台差异和适配经验组织成 AI 可以按需查阅的知识，让这些判断更有依据。 它覆盖 .mpx 页面与组件开发、存量跨端迁移、方案设计、编译运行排障和代码评审，支持在一个任务中同时处理多个目标端。
对于已经使用 mpx2rn Skill 的开发者，新版延续了 RN 开发与适配经验，并将这些经验纳入统一的 Mpx 知识体系。后续使用 mpx 即可进入相应平台的指引。
从 RN 专项到统一入口
随着 mpx2rn Skill 在业务中落地，我们发现，仅关注 RN 还不够：同一份代码往往也要运行在其他端，生成结果却可能遗漏 Skyline 或支付宝的兼容要求，例如文本溢出打点效果不符合预期，仍需开发者逐端补齐。结合这些反馈，我们沿着此前的升级规划，将 RN 专项经验整合到统一的 Mpx Skill 中，覆盖微信、RN / DRN、支付宝、Web 和 Skyline，让业务涉及的多端要求在生成代码时就被一起考虑，减少后续适配返工。
统一架构：公共语义与平台差异分层
SKILL.md 负责任务识别和知识路由，先判断任务涉及的目标端与能力维度，再通过导航索引读取 references/ 中的相关内容。Mpx 与微信的公共语义集中维护在基础层，各端参考只补充自身的支持差异、约束和专属扩展。
这让公共知识有了唯一的维护来源，也让一个业务任务可以同时读取多个目标端的指引。使用者只需说明业务需求和输出目标，由 Skill 组织所需知识。
升级延续了规划中的三项设计约束：
- 按需加载：通过导航索引定位相关主题，基础知识只读一次，再补充实际目标端的差异，避免每次任务加载全部平台资料。
- 规则冲突治理：明确每条规则的适用范围，避免把 RN 的样式限制套到 Web，或把微信渲染模式差异当作编译目标差异。多端任务优先采用共用实现，再处理必要的平台分支。
- Benchmark 验证：将统一 Skill 与原专项 Skill 放到对应任务中对照，检查知识整合后是否遗漏单端能力，并持续观察质量与执行开销。后文评测同时覆盖综合任务和各端专项任务。
与旧版 mpx2rn 的对比
旧版 mpx2rn 围绕模板、脚本、样式和 JSON 四个维度积累的 RN 开发经验，在新版中继续保留；变化主要体现在知识归属和任务组织方式上。
| 对比维度 | 旧版 mpx2rn Skill | 新版 mpx Skill |
|---|---|---|
| 适用范围 | Mpx 输出 RN / DRN 的开发、迁移、排障与评审 | Mpx 基础开发，以及支付宝、RN / DRN、Web / SSR、Skyline 适配 |
| 知识组织 | 主入口集中列出 RN 约束，参考目录包含基础知识与 RN 专项资料 | 基础知识集中维护，各平台分别维护差异和专属扩展 |
| 任务入口 | 从 RN 约束出发，按问题查阅专项参考 | 先识别实际目标端与任务范围，再配对读取基础主题和平台差异 |
| 多端任务 | 重点检查 RN 适配，并保留原平台行为 | 同时读取实际涉及的各端指引，避免将某端限制套到其他端 |
| RN 能力覆盖 | 模板、脚本、样式、JSON、环境 API、原子 CSS、混合开发等 | 继续覆盖上述主题，由统一入口路由到 RN 知识库 |
| 验证方式 | 检查原平台与 RN 编译，结合项目检查和宿主验证 | 按实际目标执行编译、适用检查与运行验证，并说明验证边界 |
对已有 RN 用户，统一入口延续了熟悉的专项能力；当业务扩展到其他端时，可以沿用同一套基础知识与任务入口，减少重复说明项目背景和组合多份指引的工作。
评测结果：实现质量与执行开销
综合评测：与不使用 Skill 对比
我们通过对照评测观察 Skill 对实际任务的帮助。综合评测使用同一模型 gpt-6.1-sol / high，两组处理相同的业务需求，分别使用 Mpx Skill 和不使用 Skill。每个场景每组执行一次，共完成 16 次任务，每组检查 48 条断言。
| 综合评测场景 | 使用 Mpx Skill（通过数 / 总数） | 不使用 Skill（通过数 / 总数） |
|---|---|---|
| 构建目标、条件文件与配置归属 | 6/6 | 5/6 |
| 图文布局、间距与样式作用范围 | 7/7 | 6/7 |
| 刷新、吸顶与节点定位 | 7/7 | 6/7 |
| 弹层、键盘与窗口尺寸 | 5/5 | 4/5 |
| 登录适配、任务句柄与请求取消 | 6/6 | 5/6 |
| 响应式动态组件与首次渲染能力 | 7/7 | 3/7 |
| 路由参数、部署与异步分包 | 5/5 | 0/5 |
| 共享业务的 Web SSR 请求隔离 | 5/5 | 4/5 |
| 合计 | 48/48 | 33/48 |
同一批任务的平均 Token 消耗和耗时如下：
| 指标（单任务平均） | 使用 Mpx Skill | 不使用 Skill |
|---|---|---|
| Token 消耗 | 127.81 万 | 30.43 万 |
| 耗时 | 400.0 秒 | 470.3 秒 |
文中平均 Token 为各组任务累计输入与输出 Token 总量除以任务数，包含缓存输入，不代表单次上下文长度或实际计费量；平均耗时为单任务实际执行时间，包含工具调用与等待。
从失败项看，Skill 的价值集中在补足框架专有知识。 通用模型可以写出布局和业务逻辑，但在动态组件、路由和分包等依赖 Mpx 具体约定的任务中，更容易出现“写法合理、接入错误”的问题。例如，定义了宿主加载方法，却没有接入框架实际调用的入口。针对这些约定提供参考，能够帮助模型把业务意图落实到正确的实现上。
这也说明，评估 Skill 应同时考虑实现质量与执行开销。更多的知识读取可能增加 Token 用量，能否换来更少的人工纠错、缩短从需求到可用交付的时间，才是团队实际使用时值得持续观察的收益。
DSH 复测：在另一模型下验证 Skill 收益
我们在 DeepSeek Harness（DSH）0.2.1-rc.5 的 desktop profile 子 Agent 中，使用 deepseek-official 提供的 DeepSeek-V4.1-Flash（构建号 1017，别名 deepseek-flash，推理等级 High）进行了复测。本轮沿用上述 8 类综合场景与 48 条断言，两组各执行 8 次任务。
| 指标 | 使用 Mpx Skill | 不使用 Skill |
|---|---|---|
| 静态设计断言通过数 | 48/48（100%） | 29/48（60.4%） |
| 单任务平均 Token | 563.00 万 | 260.31 万 |
| 单任务平均耗时 | 497.7 秒 | 516.6 秒 |
本轮使用 Skill 后，静态设计符合率提高约 39.6 个百分点，框架专有知识仍是主要收益来源。 例如，登录适配、任务句柄与请求取消从 3/6 提升到 6/6，响应式动态组件与首次渲染能力从 3/7 提升到 7/7，路由参数、部署与异步分包从 1/5 提升到 5/5。平均耗时略有下降，但 Token 消耗明显增加，延续了前一轮“实现质量改善、知识读取开销增加”的现象。
专项评测：与各端 Skill 对比
除综合评测外，我们还比较了统一 Mpx Skill 与原有专项 Skill。以下均按通过断言数统计，执行模型为 gpt-6.1-sol / high。
| 专项评测 | 用例数 | 统一 Mpx Skill | 对应专项 Skill |
|---|---|---|---|
| RN | 6 | 61/61（100%） | mpx2rn：59/61（96.72%） |
| Web | 4 | 26/26（100%） | mpx2web：24/26（92.31%） |
| Skyline | 4 | 39/40（97.5%） | mpx2skyline：39/40（97.5%） |
| 支付宝 | 3 | 15/15（100%） | mpx2ali：15/15（100%） |
对应的单任务平均 Token 消耗与耗时对比如下，专项 Skill 与上表一一对应：
| 专项评测 | Mpx 平均 Token | 专项 Skill 平均 Token | Mpx 平均耗时 | 专项 Skill 平均耗时 |
|---|---|---|---|---|
| RN | 84.70 万 | 73.34 万 | 203.4 秒 | 180.7 秒 |
| Web | 206.04 万 | 206.45 万 | 344.5 秒 | 380.7 秒 |
| Skyline | 144.97 万 | 137.60 万 | 489.3 秒 | 514.9 秒 |
| 支付宝 | 257.85 万 | 151.51 万 | 546.1 秒 | 362.6 秒 |
这些结果支持将统一 Skill 作为多端开发的共同入口：在已覆盖的场景中，知识整合保留了专项适配能力。 对已有 RN 用户，迁移可以延续熟悉的开发任务；对同时维护多个目标端的团队，统一入口则减少了选择和组合不同 Skill 的工作。
统一后的执行开销没有呈现一致优势，因此迁移价值更适合从知识维护和任务覆盖来衡量。团队可以统一维护公共规则与平台差异，再结合自己的高频任务观察质量、Token 和耗时，判断是否需要进一步收窄任务范围或优化知识读取。
从 mpx2rn 迁移到 mpx
迁移主要调整 Agent 的知识入口和调用名称，可以独立于业务代码与框架版本升级进行。先确认新版可用，再移除旧版即可。
安装并确认新版可用。 Mpx Skill 地址：SkillsHub · Mpx。如果已经配置
d-skills，执行以下命令安装新版，然后确认当前 Agent 的可用技能列表中能够找到mpx。其他安装方式应遵循所用 Agent 的技能加载机制，并保留完整 Skill 目录中的参考资料与脚本。shd-skills add mpx更新日常调用与团队规则。 将提示词、团队开发说明或 Agent 配置中“使用 mpx2rn Skill”的任务入口改为“使用 mpx Skill”，同时保留明确的 RN / DRN 目标和原平台要求。不要全局替换业务代码中的 Mpx2RN 名称、包名或平台配置。
移除旧版 Skill。 确认新版
mpx可用后，通过d-skills移除已安装的mpx2rn：shd-skills remove mpx2rn用一个代表性任务确认迁移。 选择已有组件做一次 RN 适配或评审，确认 Agent 使用新版入口、识别正确的目标端，并执行相关检查。涉及
.mpx修改时主要检查实际 RN 目标的编译，涉及原平台行为变化时再补充原平台编译；滚动、键盘、原生桥接和动态样式等交互仍需在对应容器验证。
例如，可以将原来的任务提示改为：
使用 mpx Skill，将这个微信组件适配到 RN。
目标为 wx、ios 和 android，保留微信端现有交互。
重点检查布局、事件传参、生命周期和动态样式，
执行相关编译、ESLint 与现有测试，并说明尚未完成的宿主验证。尚未迁移的用户也可以继续完成当前任务：旧版入口会提示升级，新版可用时自动转入其 RN 指引，否则继续使用旧版。
从真实任务开始使用
安装并加载后，支持自动匹配的 Agent 会按任务调用 Mpx Skill，日常使用通常无需显式声明；首次验证安装或希望指定 Skill 时，可以加上“使用 mpx Skill”。描述需求时，明确目标端、任务范围和需要保留的行为即可。
检查 Skyline 兼容性
检查这个 Mpx 页面在微信 WebView 和 Skyline 下的兼容性，
列出具体问题、影响和修改建议，本次先不修改代码。新建微信与 Web 共用页面
使用 Mpx 新建一个同时支持微信和 Web 的任务列表页面，
支持筛选、状态切换和空态，复用项目已有组件。选择一个团队熟悉的组件开始试用，既容易判断 AI 是否保留了原有行为，也便于发现项目特有约束。把这些约束补充到项目规则中，再逐步用于更复杂的页面和跨端任务，让框架知识与团队经验共同参与开发。