1实现原理 · 为什么它能做到

先把边界钉死：本 skill 只出图像，并三处显式禁止切换到编码模式或写实现说明——这是与同仓库 web 版最明显的差别，也是防止移动端参考图被拉成代码的关键。

skills/imagegen-frontend-mobile/SKILL.md

Do not switch into coding mode.

同一禁令在文首 §CORE DIRECTIVE、§36 RESPONSE BEHAVIOR 流程末、§38 FINAL GOAL 各出现一次（后两处形如 'Do not write implementation instructions.' / 'It should not write code.'），形成三重复述的高服从设计。

平台模式必须先决定（iOS-native / Android-native / cross-platform 三选一），并各自给出对应的组件与导航倾向，避免混搭出四不像。

skills/imagegen-frontend-mobile/SKILL.md

Always decide the platform mode first.

§2 对三种模式分别列出偏好项：iOS 讲 safe-area 与克制 chrome、Android 讲组件节奏与 app bar/sheet 逻辑、跨平台讲通用移动导航——选定后要求全篇贯彻。

数量纪律：屏幕数由请求决定且只许多不许少，模糊或『概念』类请求默认给成套屏幕，明确禁止因省事削减数量。

skills/imagegen-frontend-mobile/SKILL.md

Do not be lazy with screen count.

§4 用逐条映射写死（1→1、3→3、7→7、onboarding flow→多屏、auth flow→登录/注册/找回分屏），并给出取舍原则：宁可多张清晰屏，不要一张压缩小字板。

禁止裁剪复用：需要细节视图时必须重新单独生成，而不是从已有大图里裁一块。

skills/imagegen-frontend-mobile/SKILL.md

generate a fresh standalone screen image

理由在 §5 写明：裁剪会破坏间距、比例与排版（'rely on cutouts if they distort spacing, proportions, or typography'），且小字裁出来不可读。这条直接推高了生成成本，属于有意为之的质量取舍。

多屏一致性靠一份内部『设计圣经』锁死：出图前先固化平台模式、设备框、色板逻辑、字阶、间距、圆角、图标风格、纹理强度、导航模型等十余项。

skills/imagegen-frontend-mobile/SKILL.md

Do not let screen 3, 4, or 5 drift into a different app.

§6 列出圣经必须固定的 16 项属性；§7 再区分『可变的』（构图/功能侧重/图像位置/节奏）与『不可变的』（产品身份/设计系统/框体质量），把一致性从形容词变成属性表。

流程逻辑被强制：多屏必须构成可信的用户旅程，出图前要自问『为什么第 2 屏在第 1 屏之后、什么操作通向下一屏』。

skills/imagegen-frontend-mobile/SKILL.md

Do not generate random unrelated screens.

§8 给出行进范式（onboarding → auth → home、cart → checkout → confirmation 等）并要求 UI 状态在屏间可延续，避免出现『一组好看但无关联的图』。

默认必须带设备框，并把框体规格写细：一套设备样式、统一缩放、上下左右边距视觉均匀、不让手机贴边、阴影柔和、内容优先于设备。

skills/imagegen-frontend-mobile/SKILL.md

keep top, bottom, left, and right canvas margins visually even

§9/§10 同时给出例外条件（用户明确要屏幕原图、或概念本身适合无框呈现），并规定这种情况下也要保持等边距与受控留白。

反 AI 默认的移动端清单被点名到具体症状：假金融图表、玻璃拟态滥用、贴边无安全区、手机里的网站、小到不可读的字、克隆式 onboarding、漂移成不同设计系统的屏组、框体喧宾夺主。

skills/imagegen-frontend-mobile/SKILL.md

- generic developer-tool icon sets

文首 §CORE DIRECTIVE 一次性列出二十余条失败默认，后续 38 节里有 20 节是在逐条修这些症状（干净首屏、安全区、导航、文字尺寸、图标、质感等）。

允许『不总是极简』：明确允许更丰富的层次、纹理与图像导向，只要保持干净——把『留白 = 高级』的单一路径打开。

skills/imagegen-frontend-mobile/SKILL.md

It should actively allow:

结尾清单列出允许项（更强图像、背景纹理、噪声质感、图后文字带渐变遮罩、装饰性 SVG 式点缀、更表达的配色）与禁止项（随机亮色、浑浊色板、小字、Lucide 式默认图标、模板感、不一致屏组、草率框体）。

引入重生成纪律与 27 项质量自检，把『第一版平庸结果』作为明确不予接受的对象。

skills/imagegen-frontend-mobile/SKILL.md

Do not settle for the first mediocre render.

§34 列出 20 条触发重生成的条件（字太小、间距不清、导航假、像网站、太拥挤、onboarding 重复、框体不均等）；§35 用 27 问收口（'Does this feel like a real mobile app, not a website in a phone?'）。

2核心能力

01平台模式三选一与对应组件/导航倾向（iOS / Android / 跨平台）

02屏幕数量纪律与默认成套（含 onboarding/auth/概念类请求的加量要求）

03禁止裁剪复用：细节视图必须重新生成以保住可读性

04内部设计圣经 + 多屏一致性（可变量/不变量分离）

05可信流程编排（屏间因果关系与状态延续）

06默认手机框体规格（统一样式与缩放、四边等距、不贴边、柔和阴影、内容优先）

07移动端专用布局纪律：安全区/状态栏/home indicator、禁盒中盒、单焦点首屏、导航逻辑

08可读性优先与重生成循环（字阶下限、图文叠加需遮罩、坏屏重做）

4管控建议与判定依据

建议配套管控措施

面向 Agent

可自动加载

面向管理者

登记来源与版本

判定依据（文件路径与关键语句摘要）

SKILL.md: 纯提示词指令与规则文本，无脚本执行与外部影响

审计说明： 。纯指令型 skill：无脚本执行、无网络外发、无凭证读取、无本地文件写入、无外部依赖，全部行为发生在宿主的图像生成通道内。它甚至是主动『减风险』的设计——正文三处禁止进入编码模式，等于明确拒绝越界去改用户代码。可注意点是成本与产物用途：未指定屏幕数时默认成套生成（可能远超用户预期张数），且 App 界面稿若非自用需注意与既有产品/他人设计的相似度。

5第二遍独立确认

[ok] 『generates images only / does not write code』是否有正文支撑 — 正文三处复述：§CORE DIRECTIVE 'This skill generates images only.' + 'Do not switch into coding mode.'；§36 'Do not write implementation instructions.'；§38 'It should not write code.'。声明与正文一致，甚至比 README 更强。
[ok] 外部依赖与网络调用为空 — 全文无 URL、无端点、无包名、无安装命令、无图片源；对比 gpt-taste/taste-skill-v1 会写 picsum.photos，本文件确实零外链。与 imagegen-frontend-web 结论一致。
[ok] 档位数值读取是否被我误引（含尾随空格陷阱） — §1 配置行如 '- DESIGN_VARIANCE: 8 '（行尾双空格，markdown 换行）——引文取 '- DESIGN_VARIANCE: 8' 子串，已用脚本逐条校验通过，非凭记忆。
[discrepancy] 与 imagegen-frontend-web 的口径差异 — mobile 版正文有显式『禁编码模式』禁令，web 版正文没有（web 仅把可编码当质量标准）。同一仓库两个姊妹 skill 对同类边界措辞不一致；推测因 mobile 更易被误当成可实现 UI 规格。不影响本 skill 结论，但跨 skill 混用时会表现出不同的越界倾向，已记录。
[ok] 是否与 brandkit/web 的职责重叠 — §CORE DIRECTIVE 明列 out of scope：websites、landing pages、desktop dashboards、image-to-code、frontend implementation、code generation；llms.txt 亦分工为 mobile screens vs website comps vs brand boards，三者无重叠。
[ok] 是否有隐藏脚本、混淆内容或载荷 — 纯 markdown；grep exec/subprocess/bash/python/npm install/base64 等零命中；代码块内容均为 UI 描述性清单，无可执行片段。
[ok] 元数据（license / stars / last_push / 路径 / commit） — gh api：MIT、87309 stars、pushed_at 2026-08-24T15:23:56Z；git ls-files 确认 skills/imagegen-frontend-mobile/SKILL.md；HEAD == origin/main == ccbc15639c97057cbfcf32ecebc38ef716e4bb37。

6结论

边界最硬：三处禁止进入编码模式，明确拒绝把 App 参考图变成代码任务（out of scope 六项列明）。

数量与流程双纪律：屏幕数只多不少、屏间必须有因果关系，杜绝『一张概念图交差』与『一堆无关美图』。

一致性靠设计圣经属性表锁死，而非形容词，跨 5 屏以上仍能读作同一产品。

把移动端特有现实写进规则：安全区/状态栏/home indicator、44px 触控、边框四边等距、文字最小尺寸、图文叠加遮罩。

自反式质量机制：20 条重生成触发条件 + 27 问自检，明确拒绝第一版平庸产出；零外部依赖，可离线使用。

适合： 移动端产品的早期视觉探索：iOS/Android/跨平台 App 的概念稿、onboarding 与 auth 流程、投资人 pitch 用多屏 mockup；需要可读、成套、可交付评审的 App 界面图的独立开发者与设计团队；把图交给后续工程实现（React Native / SwiftUI / Flutter）之前的『图先行』环节；用 ChatGPT Images 一类通道但要抑制『一屏交差』『框体喧宾夺主』默认行为的用户。

不适合： 网页与落地页（应选 imagegen-frontend-web）；品牌识别/logo 系统（应选 brandkit）；desktop dashboard 与多步产品 UI 的可实现规格；需要直接产出 SwiftUI/RN/Flutter 代码的任务（本 skill 明确拒绝进入编码模式）；按次计费敏感、只想快速出一张图看感觉的场景；需要精确像素可复现与设计 token 交付的正式设计工作（文生图随机性不可控，且本 skill 不产出 token/规格文件）。

Install Agent-Ready

① Verified Mirror 2026-09-15

Option A · Direct DownloadDownload imagegen-frontend-mobile.tar.gz

sha256: da0e5342b7f8896a…

Option B · Copy Guide for Agent

install.json

agent 读 JSON 指南后会自动从本站下载安装，无需更多说明。

② Upstream GitHub

GitHub Repo ↗

Pinned to commit ccbc15639c.