98 lines
6.1 KiB
Markdown
98 lines
6.1 KiB
Markdown
|
||
|
||
1) 迁移前审计与准备（强烈建议先跑这个）
|
||
你是一名资深微信小程序前端架构师+CSS布局专家。我要把一套 Web 页面（HTML/CSS/少量JS）迁移为“原生微信小程序”（WXML/WXSS/JS/JSON），要求结构与样式细节还原度尽可能高。
|
||
|
||
输入（我将分段提供）：
|
||
- 页面HTML（可含多页面）
|
||
- 全量CSS（含reset/公共样式）
|
||
- 资源清单（图片/字体/图标svg等路径）
|
||
- 若有：目标效果截图/设计稿
|
||
|
||
请先不要写最终代码，先做《迁移审计与准备报告》，输出必须包含以下部分，并使用清晰的编号标题：
|
||
|
||
A. 页面结构清单：列出每个页面的主要区域（header/hero/list/card/footer等）及建议组件化边界（哪些抽组件、哪些保留页面内）
|
||
B. CSS复杂度审计：列出会影响小程序还原的高风险点（如 position: sticky、复杂选择器、伪元素、滤镜、背景混合、滚动容器、字体/line-height差异、overflow裁切、z-index层叠等），并给出在小程序里的替代策略
|
||
C. HTML→WXML映射规则：语义标签映射、事件绑定映射、表单控件映射、列表渲染（wx:for）策略
|
||
D. CSS→WXSS映射规则：单位策略（px→rpx换算方案、断点策略）、选择器扁平化策略、样式隔离策略（页面/组件wxss组织）、必要时是否引入原子化类（如仅用基础class，不引第三方）
|
||
E. 资源处理：图片/字体/图标（svg转png或iconfont方案）、2x/3x图、网络图片策略、包体与分包建议
|
||
F. 产物目录规划：给出建议的最终目录树（pages/、components/、styles/、assets/），并说明每个文件职责
|
||
G. 最小补充信息清单：如果缺少信息，列出“为了高还原必须补充的最小信息”（例如：页面宽度基准、设计稿字号、是否允许自适应裁切等）
|
||
|
||
输出要求：表格+要点并存；每个高风险点给出“原因 + 影响 + 处理方案 + 验收方式”。
|
||
|
||
2) 生成第一版代码（要求目录树+逐文件输出）
|
||
基于你刚才的《迁移审计与准备报告》，现在开始生成可运行的小程序第一版代码（优先保证结构与样式还原、其次是交互完整度）。
|
||
|
||
硬性要求：
|
||
A.输出完整目录树（含 pages、components、styles、assets）
|
||
B.按文件逐个输出内容：.wxml / .wxss / .js / .json
|
||
C.样式组织：公共样式抽到 styles/common.wxss（或等价方案），页面只放页面差异
|
||
D.尽量避免依赖第三方库；如必须引入，必须说明理由、替代方案、以及如何降低包体影响
|
||
E.对所有“Web里有但小程序不完全支持”的效果：必须写清替代实现与预期差异
|
||
|
||
我将提供：
|
||
- <PAGE_NAME_1> 的HTML：<<<...>>>
|
||
- 全量CSS：<<<...>>>
|
||
- 可选：截图/设计稿要点：<<<...>>>
|
||
|
||
请输出：
|
||
I. 目录树
|
||
II. 逐文件代码（从 app.json/app.wxss/app.js 开始）
|
||
III. 编译与运行说明（微信开发者工具中需注意的设置项）
|
||
IV. 第一版“已知差异清单”（按严重度排序：P0/P1/P2）
|
||
|
||
3) 高保真样式“对齐增强”专用提示词（第二轮开始用）
|
||
现在进入“高保真样式对齐”阶段。目标：在不破坏现有结构的前提下，把视觉细节尽量贴近 Web/设计稿。
|
||
|
||
我会提供：
|
||
- 当前小程序代码片段（相关 wxml/wxss）
|
||
- Web 参考（对应HTML/CSS片段）或截图差异描述
|
||
- 具体差异点列表（例如：间距、对齐、字体、行高、圆角、阴影、图片裁切、列表间距、按钮高度等）
|
||
|
||
你的任务：
|
||
A. 对每个差异点，给出：根因判断（布局/单位/行高/盒模型/层叠/渲染差异）+ 最小修改方案 + 修改后风险
|
||
B. 输出“补丁式修改”：只给出需要改动的文件与改动段落（像 git diff 一样），不要整文件重贴
|
||
C. 给出验收步骤：在微信开发者工具与真机预览分别怎么验证
|
||
|
||
约束：
|
||
- 优先使用 flex/盒模型的确定性方案，尽量减少依赖“碰运气”的魔法数
|
||
- px→rpx 的换算要统一，严禁同一类间距一会儿 rpx 一会儿 px
|
||
4) 结构还原与组件化质量提升（防止“越改越乱”）
|
||
请对当前小程序实现做一次“结构与可维护性重构”，目标是在不改变 UI 效果的情况下，提高组件化与样式可控性，从而提升后续对齐效率。
|
||
|
||
输出必须包含：
|
||
A.现状问题清单（重复样式、选择器过深、耦合、命名不一致、难以复用的结构）
|
||
B.组件拆分方案（组件名、props、slot策略、事件、数据流）
|
||
C.样式治理方案（BEM/命名规范、公共变量、间距/字号/圆角/阴影的设计token化）
|
||
D.重构后的目录树
|
||
E.逐文件补丁（diff风格），并说明每个改动为何不影响UI
|
||
|
||
约束：不引第三方UI库；不改变页面路由与业务数据接口（若有）。
|
||
|
||
|
||
5) 细致对比与验收清单（你要的“对比更细致”）
|
||
请为本次迁移输出《像素级对比与验收清单》，用于我逐项对照 Web 版本与小程序版本。
|
||
|
||
要求：
|
||
- 按页面输出（每页一个小节）
|
||
- 每页包含：布局结构、间距系统、字体系统、颜色、边框/圆角、阴影、图片裁切、交互态（hover/active/disabled等在小程序里等价态）、滚动与吸顶、列表与空状态
|
||
- 每条验收项必须可操作：说明“怎么看”“合格标准是什么”“常见失败表现是什么”
|
||
- 额外输出《差异追踪表》：字段包括【差异描述｜截图/位置｜严重度P0/P1/P2｜可能原因｜建议修复方案｜修复代价｜回归点】
|
||
|
||
输出用表格为主，保证我可以直接复制到文档里当验收用例。
|
||
|
||
|
||
6) 编译报错/真机差异快速修复（把 Opus 当“修复代理”）
|
||
你是微信小程序调试与兼容性专家。我会贴出：
|
||
- 微信开发者工具编译报错/警告日志
|
||
- 真机预览与模拟器表现差异描述
|
||
- 相关代码片段
|
||
|
||
请你：
|
||
A.先定位根因（按概率排序列出 1~3 个最可能原因）
|
||
B.给出最小修复补丁（diff风格）
|
||
C.给出回归测试点（防止修A坏B）
|
||
D.如果是基础库兼容问题，说明需要的最低基础库版本或降级方案
|
||
|