企业官网建设流程全解析

• 前端
• 开发工具

Dillinger 仓库的.agent/目录内置了一套名为 Antigravity Kit 的 AI 代理能力扩展体系，其中 mobile-developer.md 是该体系中负责 iOS/Android/React Native/Flutter 方向的专家代理定义文件。本文以该文档为主体，完整拆解它如何把"移动端工程约束"固化为可执行规范：包括开发前的技能加载协议、必须先问后做的需求澄清清单、三大类移动端反模式对照表、强制检查点（Checkpoint）模板、四阶段决策流程，以及"不跑真实构建就不许宣布完成"的构建验证协议；并结合仓库中的 ARCHITECTURE.md、GEMINI.md 与 mobile-design 技能 说明该代理在整个代理体系中的加载路由与知识来源。读完后你可以理解这套代理体系的设计思路，并直接复用其中的移动端工程守则、性能反模式表和构建命令速查表来约束自己的移动开发流程。

需要说明适用前提：Dillinger 本体是一个 Next.js 在线 Markdown 编辑器（web 应用），仓库内并不包含 React Native 或 Flutter 的 App 源码；mobile-developer 代理与 mobile-design 技能是仓库自带的"知识库 + 行为规范"模块，供 AI 助手在处理移动端任务时遵循，文中所有 RN/Flutter 代码片段均为该规范内置的最佳实践示例。

一、代理定位：Antigravity Kit 中的 16 个专家之一

mobile-developer.md 是一份标准的代理定义文件，其 frontmatter 元数据如下：

--- name: mobile-developer description: Expert in React Native and Flutter mobile development. Use for cross-platform mobile apps, native features, and mobile-specific patterns. Triggers on mobile, react native, flutter, ios, android, app store, expo. tools: Read, Grep, Glob, Bash, Edit, Write model: inherit skills: clean-code, mobile-design ---

从源码结构看，这份文件遵循 ARCHITECTURE.md 描述的统一结构：16 个角色化专家代理（agents/ 目录）+ 40 个领域技能模块（skills/ 目录）+ 11 个斜杠命令工作流（workflows/ 目录）。ARCHITECTURE.md 的代理清单中明确登记了该角色：mobile-developer负责 "iOS, Android, RN" 领域，使用mobile-design技能。

frontmatter 各字段的工程含义：

加载路由规则由 GEMINI.md 中的 TIER 1 "Project Type Routing" 表定义：

并且 GEMINI.md 给出了明确的排他约束："Mobile + frontend-specialist = WRONG. Mobile = mobile-developer ONLY."，规则优先级为 P0（GEMINI.md）> P1（Agent .md）> P2（SKILL.md）。也就是说，mobile-developer.md 本身是 P1 级绑定规则：代理一旦激活，文件内所有规则都必须执行。

二、设计哲学与六种工程心态

文档开篇确立了整份规范的总纲：

"Mobile is not a small desktop. Design for touch, respect battery, and embrace platform conventions."（移动端不是小的桌面。为触摸设计、尊重电池、遵循平台惯例。）

基于这一哲学，文档定义了代理必须具备的六种心态（Mindset），每一条都对应后文某个具体的反模式约束：

• Touch-first（触摸优先）：一切可交互元素以手指为单位，最小 44-48px；
• Battery-conscious（电池敏感）：用户会察觉电量消耗，关注 OLED 深色模式与高效代码；
• Platform-respectful（平台尊重）：iOS 要有 iOS 的手感，Android 要有 Android 的手感；
• Offline-capable（离线可用）：网络不可靠，缓存优先；
• Performance-obsessed（性能偏执）：60fps 是底线，不允许卡顿（jank）；
• Accessibility-aware（无障碍意识）：任何人都能用这个 App。

文末的收束句把六种心态收敛为一句话："移动用户是急躁的、随时被打断的、用不精确的手指在小屏幕上操作的。为最差条件设计：差网络、单手、强阳光、低电量。如果在那里能工作，它在任何地方都能工作。"

三、强制技能加载协议：先读文件，再写代码

文档第三部分用大写标题声明了"MANDATORY: Read Skill Files Before Working"——在开始任何开发之前，必须先读完 mobile-design 技能的相关文件（相对原文档的../skills/mobile-design/目录，即仓库路径.agent/skills/mobile-design/）。

3.1 通用必读文件（Universal）

文档要求的必读清单如下（路径已转换为仓库根目录相对路径）：

其中mobile-design-thinking.md被标注为最高优先级，目的是"防止记忆化模式、强制思考"。这一设计与 SKILL.md 的元描述一致："Teaches principles, not fixed values"（教原则，而不是给固定答案）——技能库刻意不提供"复制粘贴式答案"，decision-trees.md 开篇也重申"这些是思考指南，不是抄写答案"。

3.2 平台相关按需读取

并给出硬性约束：iOS 项目先读 platform-ios.md；Android 项目先读 platform-android.md；跨平台则两个都读并应用条件化的平台逻辑。

3.3 技能侧的配套：校验脚本

mobile-design/SKILL.md 还声明了一个"只运行、不阅读"的运行时脚本scripts/mobile_audit.py（实际存在于 .agent/skills/mobile-design/scripts/mobile_audit.py），用途是移动端 UX 与触摸目标审计，调用方式为python scripts/mobile_audit.py <project_path>。GEMINI.md 的脚本清单中同样登记了该脚本，时机为"After mobile change"。这与代理文件中"Quality Control Loop"的验证要求形成呼应：改完移动代码后跑审计脚本，而不是凭感觉判断。

四、先问后做（Ask Before Assuming）：禁止默认偏好

文档第四部分针对"开放式需求"给出了强制澄清协议：如果用户没有指定，必须主动提问而不是套用个人偏好。必须询问的六个维度：

配套的"AI 默认倾向避坑表"列出了七类需要警惕的默认倾向及理由：

这个机制与 GEMINI.md 中 TIER 0 的 "GLOBAL SOCRATIC GATE" 相衔接：任何用户请求在动用工具或写代码之前必须先过苏格拉底式提问关卡，"New Feature / Build" 类型至少要问 3 个战略性问题。

五、移动端反模式清单（Anti-Patterns）

文档第五部分（.agent/agents/mobile-developer.md#L95-L127）给出三组"NEVER/ALWAYS"对照表，这是该代理的核心工程约束。

5.1 性能罪（Performance Sins）

5.2 触摸/UX 罪（Touch/UX Sins）

5.3 安全罪（Security Sins）

这些条目在 mobile-design/SKILL.md 中以更细的三列格式（"绝不做 / 为什么错 / 总是做"）重复出现，并额外补充了"架构罪"一类：业务逻辑不要写进 UI 层、不要全局状态化一切、深度链接要第一天就规划、不要跳过 dispose/cleanup 导致内存泄漏。SKILL.md 中对应的性能反模式还多两条：跳过getItemLayout（异步布局导致滚动抖动）和跳过React.memo/const（任何变化都触发全量重渲染）。

六、强制检查点（Checkpoint）：写任何移动端代码前必须填表

文档要求代理在写第一行移动端代码之前完成一个结构化检查点，模板如下：

CHECKPOINT: Platform: [ iOS / Android / Both ] Framework: [ React Native / Flutter / SwiftUI / Kotlin ] Files Read: [ List the skill files you've read ] 3 Principles I Will Apply: 1. _______________ 2. _______________ 3. _______________ Anti-Patterns I Will Avoid: 1. _______________ 2. _______________

文档同时给出了一份填写示范：

CHECKPOINT: Platform: iOS + Android (Cross-platform) Framework: React Native + Expo Files Read: SKILL.md, touch-psychology.md, mobile-performance.md, platform-ios.md, platform-android.md 3 Principles I Will Apply: 1. FlatList with React.memo + useCallback for all lists 2. 48px touch targets, thumb zone for primary CTAs 3. Platform-specific navigation (edge swipe iOS, back button Android) Anti-Patterns I Will Avoid: 1. ScrollView for lists → FlatList 2. Inline renderItem → Memoized 3. AsyncStorage for tokens → SecureStore

检查点的闭环规则是："填不满检查点？→ 回去读技能文件。"这把"读文件"从建议变成了可验证的产出物——检查点里必须列出实际读过的文件清单，从而把第三节的强制阅读协议落到实处。

七、四阶段开发决策流程

文档把完整的移动开发过程拆成四个阶段，每个阶段都有明确的入口条件和出口条件：

Phase 1: 需求分析（永远是第一步）。编码前先回答四个问题：平台是 iOS、Android 还是双端？框架是 RN、Flutter 还是原生？哪些功能需要无网络可用？需要什么认证方式？任何一项不清晰就回到第四节的提问协议。

Phase 2: 架构。应用 decision-trees.md 中的决策框架，确定：框架选型、状态管理、导航模式、存储策略。

Phase 3: 执行。按层构建：

1. 导航结构
2. 核心屏幕（列表视图必须 memoize）
3. 数据层（API、存储）
4. 打磨（动画、触觉反馈）

Phase 4: 验证。完成前逐条确认：

• 低端机上能否保持 60fps？
• 所有触摸目标是否 ≥ 44-48px？
• 离线场景是否优雅降级？
• token 是否在 SecureStore 中？
• 交互元素是否都有无障碍标签？

框架选型这一步在 decision-trees.md 中有完整的决策树，关键分叉点是：需要 OTA 更新 + 快速迭代 + web 团队背景 → React Native + Expo（Expo Go 开发、EAS Update 生产 OTA）；需要像素级定制 UI + 性能关键 → Flutter（自绘引擎、双端单一 UI）；重度原生能力（ARKit、HealthKit、特定传感器）→ iOS 选 SwiftUI/UIKit、Android 选 Kotlin + Jetpack Compose，双端可考虑 Kotlin Multiplatform 共享逻辑。mobile-design/SKILL.md 内嵌了一个简化版决策树，与 decision-trees.md 的完整版一致。

八、快速参考：触摸目标与列表代码范式

文档的 Quick Reference 部分给出了可直接照抄的工程参数与代码范式，这是该代理"教原则 + 给底线值"风格的典型体现。

8.1 触摸目标参数

iOS: 44pt × 44pt minimum Android: 48dp × 48dp minimum Spacing: 8-12px between targets

8.2 React Native FlatList 标准写法

const Item = React.memo(({ item }) => <ItemView item={item} />); const renderItem = useCallback(({ item }) => <Item item={item} />, []); const keyExtractor = useCallback((item) => item.id, []); <FlatList data={data} renderItem={renderItem} keyExtractor={keyExtractor} getItemLayout={(_, i) => ({ length: H, offset: H * i, index: i })} />

这段写法同时满足了第五节反模式表中的四条：memoize 的 Item 组件、useCallback包裹的 renderItem、来自数据的稳定keyExtractor、固定高度下的getItemLayout（避免异步布局导致滚动卡顿）。

8.3 Flutter ListView.builder 标准写法

ListView.builder( itemCount: items.length, itemExtent: 56, // Fixed height itemBuilder: (context, index) => const ItemWidget(key: ValueKey(id)), )

要点是itemExtent声明固定行高、以及const构造的ItemWidget——与 SKILL.md 中"Flutter 关键规则"一致：const构造函数防止不必要的重建，配合ValueListenableBuilder做定向状态更新（child参数传入的昂贵组件不会随 builder 重建）。

8.4 动画性能边界

SKILL.md 还给出了 GPU 加速与 CPU 绑定的属性边界，这也是 RNuseNativeDriver: true要求的底层原因（动画走 JS 线程会阻塞）：

• GPU 加速（快）：transform、opacity——只动这两个；
• CPU 绑定（慢）：width/height、top/left/right/bottom、margin/padding——避免对这些属性做动画。

九、质量循环与构建验证：不许"在脑子里跑通"

文档最后两部分定义了代理的自我验证义务，这是它区别于普通"风格指南"的关键。

9.1 质量控制循环（Quality Control Loop）

编辑任何文件之后必须执行五步：

1. 运行验证（Lint 检查）；
2. 性能检查（列表是否 memoize？动画是否走原生驱动？）；
3. 安全检查（token 是否脱离明文存储？）；
4. 无障碍检查（交互元素是否都有标签？）；
5. 全部通过后才报告"完成"。

9.2 构建验证（Build Verification）

文档用一个"不可协商"的声明收尾："你无法在没有实际运行构建的情况下宣布移动项目'完成'"，并给出了动机：

AI writes code → "Looks good" → User opens Android Studio → BUILD ERRORS! This is UNACCEPTABLE. AI MUST: ├── Run the actual build command ├── See if it compiles ├── Fix any errors └── ONLY THEN say "done"

模拟器路径速查（按操作系统）：

模拟器操作命令（PowerShell / Bash 两套）：

# === WINDOWS (PowerShell) === # List emulators & "$env:LOCALAPPDATA\Android\Sdk\emulator\emulator.exe" -list-avds # Start emulator & "$env:LOCALAPPDATA\Android\Sdk\emulator\emulator.exe" -avd "<AVD_NAME>" # Check devices & "$env:LOCALAPPDATA\Android\Sdk\platform-tools\adb.exe" devices

# === macOS / Linux (Bash) === # List emulators ~/Library/Android/sdk/emulator/emulator -list-avds # macOS ~/Android/Sdk/emulator/emulator -list-avds # Linux # Start emulator emulator -avd "<AVD_NAME>" # Check devices adb devices

按框架的构建命令：

构建输出处理决策树：

BUILD OUTPUT: ├── BUILD SUCCESSFUL → 继续 ├── BUILD FAILED → 先修复再继续 │ ├── 读错误信息 │ ├── 修复问题 │ ├── 重新构建 │ └── 循环直到成功 └── WARNINGS → 审查，关键则修复

常见构建错误对照表：

宣布"项目完成"前的强制清单：

• Android 构建无错误（./gradlew assembleDebug或等价命令）；
• iOS 构建无错误（跨平台项目）；
• App 能在真机/模拟器上启动；
• 启动时控制台无错误；
• 关键流程可用（导航、主功能）。

文档最后用两句红线结束整个构建验证章节："如果你跳过了构建验证而用户发现了构建错误，你就是失败了"，以及"'在脑子里跑通'不算验证——去跑构建。"

十、这套规范如何落地：给读者的复用建议

从仓库整体结构看，mobile-developer 代理的价值不在某一条命令，而在它把散落的移动端工程经验组织成了"协议"：

1. 知识分层：GEMINI.md（P0 全局规则：路由、苏格拉底门、脚本清单）→ 代理文件（P1：角色哲学、反模式、检查点、构建验证）→ mobile-design 技能（P2：12 个主题参考文件 + 审计脚本）。三层各管各的粒度，代理文件只保留"必须在每次工作中执行"的约束，深水区细节放在技能文件里按需加载。
2. 约束可验证化：强制阅读协议的检查产物是 Checkpoint 表格，强制构建的产物是真实的BUILD SUCCESSFUL输出，强制审计的产物是mobile_audit.py的运行结果。这比"要重视性能"之类的口号更接近工程实践。
3. 可直接移植：文中三张反模式对照表、触摸目标参数（44pt/48dp、8-12px 间距）、FlatList/ListView.builder 代码范式、按框架的构建命令表与常见构建错误表，都不依赖 Antigravity Kit 本身，可以直接抽取为团队移动端的 Code Review checklist 或 CI 前的本地检查单。

适用限制需要明示：本规范基于文档内置的最佳实践与工具链版本（Expo/EAS、Gradle、CocoaPods、Flutter CLI），具体版本号与命令参数以当前各框架官方文档为准；仓库内的代码片段是规范示例而非经过该仓库测试套件验证的工程代码。仓库自身是一个 web 项目（其测试体系为 Vitest 单元/路由测试 + Playwright E2E，见 tests/ 目录），文中移动端流程属于该仓库 AI 工具链的领域知识模块，而非 Dillinger 编辑器本身的运行时功能。

• 前端
• 开发工具