ag-kit 移动设计思考协议防止 AI 落入默认模式的反记忆化移动设计决策框架【免费下载链接】ag-kit项目地址: https://gitcode.com/GitHub_Trending/an/ag-kit本文以 ag-kit 仓库mobile-design技能中的 mobile-design-thinking.md 为主体完整解读其深度移动思考协议Deep Mobile Thinking Protocol包括五步思考流程、AI 默认模式禁用清单、逐屏组件分解模板、模式质疑矩阵、上下文决策协议与手势交互拆解。读完后你将掌握一套可落地的方法论——在编写任何 React Native / Flutter / 原生移动代码之前如何强制自己或 AI Agent基于项目上下文做出导航、状态管理、列表实现与 UI 模式的取舍决策而非照搬训练数据中的安全港套路。一、这份文档在 ag-kit 中的定位移动技能包的第一优先级ag-kit 是一个面向 AI Agent 的开发套件其.agents/目录下组织了 agents专家角色、skills技能包、workflows工作流与 rules规则。mobile-design是其中一个针对移动端React Native、Flutter、原生 iOS/Android的技能包其入口 SKILL.md 的 frontmatter 明确了适用边界Mobile-first design thinking and decision-making for iOS and Android apps... Use when building React Native, Flutter, or native mobile apps.而 mobile-design-thinking.md 在该技能包中承担着特殊的角色——它不是参数速查表而是一份思维约束文件。SKILL.md 在必读参考文件一节中将其标注为最高优先级文件内容状态mobile-design-thinking.md⚠️ ANTI-MEMORIZATION: 强制思考、防止 AI 默认套路CRITICAL FIRST最先读该技能在 manifest.json 中以mobile-design: ^1.0.0版本约束注册入口指向skills/mobile-design/SKILL.md并附带运行期验证脚本scripts/mobile_audit.py调用方式为python scripts/mobile_audit.py project_path用于移动 UX 与触控审计。同时manifest.lock.json 对本文档保留了内容哈希说明 ag-kit 将技能文档视为受版本控制锁定的资产。从 Agent 编排角度看mobile-developer.md 是触发移动开发任务的专家角色。它把本文档列为开工前必读表格中的第一行并注明⚠️ ANTI-MEMORIZATION: Think, dont copy且给出了一句强制性说明mobile-design-thinking.md is PRIORITY! Prevents memorized patterns, forces thinking.这是优先级文件防止记忆化模式、强制思考。换句话说在 ag-kit 的体系里动笔写移动代码之前先过一遍这份思考协议是被系统级流程强制要求的。二、核心宗旨禁止记忆化模式强制真实思考文档开篇即给出它的存在理由引用原文语义This file prevents AI from using memorized patterns and forces genuine thinking.本文件防止 AI 使用记忆化模式并强制真实思考。 Mechanisms to prevent standard AI training defaults in mobile development.用于阻止移动开发中 AI 训练数据默认值的一套机制。The mobile equivalent of frontends layout decomposition approach.它是前端布局分解方法在移动端的对应物。这三句话概括了协议的设计动机问题LLM 在移动开发任务上存在强烈的训练数据惯性——Tab bar、Redux、FlatList、右下角 FAB 这些模式出现频率极高AI 会无意识地原样复现而不判断它们是否适合当前项目机制通过禁用清单 质疑矩阵 强制分解三层机制把每个默认选择都变成必须回答的决策问题定位与 ag-kit 前端技能frontend-design 的布局分解思路形成对偶——先分解结构再谈实现。三、深度移动思考协议DEEP MOBILE THINKING PROTOCOL文档将以下流程定义为每个移动项目开工前的强制流程Mandatory Before Every Mobile Project。五个步骤如下全部继承自原文档┌─────────────────────────────────────────────────────────────────┐ │ DEEP MOBILE THINKING │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 1. CONTEXT SCAN上下文扫描 │ │ └── What are my assumptions for this project? │ │ └── QUESTION these assumptions质疑这些假设 │ │ │ │ 2. ANTI-DEFAULT ANALYSIS反默认分析 │ │ └── Am I applying a memorized pattern? │ │ └── Is this pattern REALLY the best for THIS project? │ │ │ │ 3. PLATFORM DECOMPOSITION平台分解 │ │ └── Did I think about iOS and Android separately? │ │ └── What are the platform-specific patterns? │ │ │ │ 4. TOUCH INTERACTION BREAKDOWN触控交互拆解 │ │ └── Did I analyze each interaction individually? │ │ └── Did I apply Fitts Law, Thumb Zone? │ │ │ │ 5. PERFORMANCE IMPACT ANALYSIS性能影响分析 │ │ └── Did I consider performance impact of each component? │ │ └── Is the default solution performant? │ └─────────────────────────────────────────────────────────────────┘五个步骤各自解决的典型问题第 1 步上下文扫描先显式列出你对项目的全部假设用户画像、使用场景、网络环境然后逐条质疑。它直接服务于第六节的上下文决策协议——不同项目类型应有不同默认答案。第 2 步反默认分析识别我是不是在套用记忆化模式并追问这个模式对这个项目真的最优吗。这一步是全文档的枢纽禁用清单第四节提供识别对象质疑矩阵第五节提供追问方式。第 3 步平台分解强制把 iOS 与 Android 拆开想。这与同技能包 platform-ios.mdHIG、SF Pro、SwiftUI 模式和 platform-android.mdMaterial Design 3、Roboto、Compose 模式配套SKILL.md 明确要求iOS 项目先读 platform-ios.md跨平台项目两份都读并应用条件化平台逻辑。第 4 步触控交互拆解要求逐个交互分析并显式应用 Fitts Law 与 Thumb Zone拇指区。其细节由同技能包的 touch-psychology.md 支撑该文件给出触控版 Fitts Law 公式Touch acquisition time a b × log₂(1 D/W)D 为距离、W 为目标宽度触控要求 W 远大于桌面、最小触控目标尺寸表iOS 44pt / Android 48dp / WCAG 44px以及单手拇指弧线的分区图。第 5 步性能影响分析对每个组件追问性能代价并质疑默认方案本身就是高性能的吗。同技能包的 mobile-performance.md 提供 RN/Flutter 的 60fps、内存等具体规则。四、AI 移动端默认模式禁用清单AI MOBILE DEFAULTS / FORBIDDEN LIST这是协议的核心资产之一文档声明自动使用以下模式是 FORBIDDEN被禁止的因为它们是从训练数据中习得的默认值使用之前必须质疑并考虑替代方案。清单按四个维度组织以下为原文档完整内容┌─────────────────────────────────────────────────────────────────┐ │ AI MOBILE SAFE HARBOR │ │ (Default Patterns - Never Use Without Questioning) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ NAVIGATION DEFAULTS导航默认: │ │ ├── Tab bar for every project (Would drawer be better?) │ │ ├── Fixed 5 tabs (Are 3 enough? For 6, drawer?) │ │ ├── Home tab on left (What does user behavior say?) │ │ └── Hamburger menu (Is it outdated now?) │ │ │ │ STATE MANAGEMENT DEFAULTS状态管理默认: │ │ ├── Redux everywhere (Is Zustand/Jotai sufficient?) │ │ ├── Global state for everything (Isnt local state enough?) │ │ ├── Context Provider hell (Is atom-based better?) │ │ └── BLoC for every Flutter project (Is Riverpod more modern?) │ │ │ │ LIST IMPLEMENTATION DEFAULTS列表实现默认: │ │ ├── FlatList as default (Is FlashList more performant?) │ │ ├── windowSize21 (Is it really needed?) │ │ ├── removeClippedSubviews (Always?) │ │ └── ListView.builder (Is ListView.separated better?) │ │ │ │ UI PATTERN DEFAULTSUI 模式默认: │ │ ├── FAB bottom-right (Is bottom-left more accessible?) │ │ ├── Pull-to-refresh on every list (Is it needed everywhere?) │ │ ├── Swipe-to-delete from left (Is right better?) │ │ └── Bottom sheet for every modal (Is full screen better?) │ │ │ └─────────────────────────────────────────────────────────────────┘逐条解读其设计意图导航默认文档并不反对 Tab bar 本身而是反对不看目的地数量就用 Tab bar。括号内的追问即答案线索——抽屉菜单会不会更好固定 5 个 tab 合理吗3 个够不够、6 个以上是否该用 drawerHome 放左侧有什么用户行为依据汉堡菜单是否已过时状态管理默认针对 AI 最典型的过设计倾向。到处 Redux要对照 Zustand/Jotai 的轻量性万物皆全局状态要追问局部状态是否足够Context Provider 地狱要评估 atom 化的重渲染代价BLoC 也要对照 Riverpod 的样板代码量。这与 decision-trees.md 中的状态管理决策树简单应用、少量屏幕、极少共享状态 → Zustand甚至 useState/Context是同一思路的两种表达。列表实现默认注意它连windowSize21、removeClippedSubviews这类教科书参数也列入质疑——这正是针对背参数式 AI 输出的精确打击。SKILL.md 中给出的优化 FlatList 示例windowSize{5}、maxToRenderPerBatch{10}反而使用了更小的 windowSize印证了参数必须按项目调整而非照抄的主旨。UI 模式默认FAB 位置、下拉刷新、左滑删除、Bottom sheet 全部要求逐案判断。值得注意的是FAB 右下角被质疑的角度是可达性与惯用手bottom-left 是否对某些用户更易触达而非美观——这与 touch-psychology.md 的拇指弧线分析右手持机时屏幕右下更易够到相互呼应。需要强调这份清单是**未经质疑不得直接使用**而不是永远禁用。协议的目标是把每个默认值从无意识复现变成有意识的选择。五、逐屏组件分解COMPONENT DECOMPOSITION强制模板文档要求设计任何屏幕之前执行以下结构化分解。这是整份文档最接近可操作工件的部分原文模板完整保留如下SCREEN: [Screen Name] ├── PRIMARY ACTION: [What is the main action?] │ └── Is it in thumb zone? [Yes/No → Why?] │ ├── TOUCH TARGETS: [All tappable elements] │ ├── [Element 1]: [Size]pt → Sufficient? │ ├── [Element 2]: [Size]pt → Sufficient? │ └── Spacing: [Gap]pt → Accidental tap risk? │ ├── SCROLLABLE CONTENT: │ ├── Is it a list? → FlatList/FlashList [Why this choice?] │ ├── Item count: ~[N] → Performance consideration? │ └── Fixed height? → Is getItemLayout needed? │ ├── STATE REQUIREMENTS: │ ├── Is local state sufficient? │ ├── Do I need to lift state? │ └── Is global required? [Why?] │ ├── PLATFORM DIFFERENCES: │ ├── iOS: [Anything different needed?] │ └── Android: [Anything different needed?] │ ├── OFFLINE CONSIDERATION: │ ├── Should this screen work offline? │ └── Cache strategy: [Yes/No/Which one?] │ └── PERFORMANCE IMPACT: ├── Any heavy components? ├── Is memoization needed? └── Animation performance?该模板把思考协议的五步压缩到屏幕这个粒度上每个分支都对应一个必须书面的判断PRIMARY ACTION 拇指区检查主操作是否在拇指可达区回答否时必须给出理由。SKILL.md 的拇指区示意图把屏幕分为三层——顶部 HARD TO REACH放返回/菜单、中部 OK TO REACH次级操作、底部 EASY TO REACH主 CTA 与 Tab bar。TOUCH TARGETS逐项列出尺寸pt与间距并判断误触风险。配套阈值来自 touch-psychology.mdiOS 最小 44pt、Android 最小 48dp、目标间留白 8–12px图标按钮视觉 24–32px 但点击区必须 44–48px。SCROLLABLE CONTENT三问决定列表实现——用 FlatList 还是 FlashList为什么、条目规模是否需要考虑性能、高度是否固定固定则应提供getItemLayout避免异步布局导致滚动卡顿。这三问恰好命中 SKILL.md Performance Sins 表格中的三条ScrollView 渲染全部条目导致内存爆炸、缺失getItemLayout、缺失keyExtractor用 index 做 key 在重排时会出错。STATE REQUIREMENTS状态提升的三级阶梯——局部状态够吗 → 需要提升吗 → 真的需要全局吗要写理由。这是禁用清单中Global state for everything追问的模板化落地。PLATFORM DIFFERENCES / OFFLINE / PERFORMANCE分别对应思考协议第 3、4离线属于 SKILL.md 必问项Does this need to work offline?与第 5 步。六、模式质疑矩阵PATTERN QUESTIONING MATRIX第四节是列出要质疑什么本节则给出用什么问题质疑、替代方案是什么。文档要求对每个默认模式回答Assumption假设→ Question问题→ Alternative替代。以下为原文四张矩阵表完整继承导航模式质疑AssumptionQuestionAlternativeIll use tab barHow many destinations?3 → minimal tabs, 6 → drawer5 tabsAre all equally important?More tab? Drawer hybrid?Bottom naviPad/tablet support?Navigation rail alternativeStack navigationDid I consider deep links?URL structure navigation structure矩阵给出了一个可操作的量化判据目的地3 个用极简 tabs6 个以上转向 drawer平板场景考虑 Navigation rail以及一条容易被忽略的架构原则——URL 结构即导航结构深链deep links应在一开始就规划SKILL.md 的架构罪清单同样把Deep linking as afterthought列为禁忌。状态模式质疑AssumptionQuestionAlternativeIll use ReduxHow complex is the app?Simple: Zustand, Server: TanStackGlobal stateIs this state really global?Local lift, Context selectorContext ProviderWill re-render be an issue?Zustand, Jotai (atom-based)BLoC patternIs the boilerplate worth it?Riverpod (less code)注意第二行服务端状态单列为 TanStackQuery 类方案——这提醒读者很多全局状态其实只是缓存的服务器数据选型应分开考虑。列表模式质疑AssumptionQuestionAlternativeFlatListIs performance critical?FlashList (faster)Standard renderItemIs it memoized?useCallback React.memoIndex keyDoes data order change?Use item.idListViewAre there separators?ListView.separatedUI 模式质疑AssumptionQuestionAlternativeFAB bottom-rightUser handedness?Accessibility settingsPull-to-refreshDoes this list need refresh?Only when necessaryModal bottom sheetHow much content?Full screen modal might be betterSwipe actionsDiscoverability?Visible button alternativeSwipe actions → Discoverability?一问与后文 INTERACTION BREAKDOWN 中的手势必须提供按钮替代方案MANDATORY相互咬合滑动类操作天然缺乏可发现性矩阵直接要求准备可见按钮这一替代路径。七、反记忆化测试ANTI-MEMORIZATION TEST在给出任何具体方案之前文档要求执行以下 7 项自查清单。这是整套协议中唯一针对执行者本身AI 或工程师的元检查┌─────────────────────────────────────────────────────────────────┐ │ ANTI-MEMORIZATION CHECKLIST │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ □ Did I pick this solution because I always do it this way? │ │ → If YES: STOP. Consider alternatives. │ │ │ │ □ Is this a pattern Ive seen frequently in training data? │ │ → If YES: Is it REALLY suitable for THIS project? │ │ │ │ □ Did I write this solution automatically without thinking? │ │ → If YES: Step back, do decomposition. │ │ │ │ □ Did I consider an alternative approach? │ │ → If NO: Think of at least 2 alternatives, then decide. │ │ │ │ □ Did I think platform-specifically? │ │ → If NO: Analyze iOS and Android separately. │ │ │ │ □ Did I consider performance impact of this solution? │ │ → If NO: What is the memory, CPU, battery impact? │ │ │ │ □ Is this solution suitable for THIS projects CONTEXT? │ │ → If NO: Customize based on context. │ └─────────────────────────────────────────────────────────────────┘七问的设计有递进关系前三问识别惯性输出凭习惯选 / 训练数据高频模式 / 无意识自动补全第四问是硬约束——至少想出 2 个替代方案再决定这是思考过与复述过的可判定分界后三问把平台差异、性能影响内存/CPU/电池、项目上下文补成决策闭环。移动端之所以要把性能影响落到battery这一项是因为 SKILL.md 的技能哲学第一条就是Touch-first. Battery-conscious.触控优先、电量敏感。八、基于上下文的决策协议CONTEXT-BASED DECISION PROTOCOL不同项目类型用不同方式思考——本节以决策树形式给出五类典型项目的差异化默认。这是第四节禁用清单的答案库同样的问题导航列表离线在不同项目里有不同正确答案。原文档内容完整继承如下DETERMINE PROJECT TYPE: │ ├── E-Commerce App电商 │ ├── Navigation: Tab (Home, Search, Cart, Account) │ ├── Lists: Product grids (memoized, image optimized) │ ├── Performance: Image caching CRITICAL │ ├── Offline: Cart persistence, product cache │ └── Special: Checkout flow, payment security │ ├── Social/Content App社交/内容 │ ├── Navigation: Tab (Feed, Search, Create, Notify, Profile) │ ├── Lists: Infinite scroll, complex items │ ├── Performance: Feed rendering CRITICAL │ ├── Offline: Feed cache, draft posts │ └── Special: Real-time updates, media handling │ ├── Productivity/SaaS App效率/SaaS │ ├── Navigation: Drawer or adaptive (mobile tab, tablet rail) │ ├── Lists: Data tables, forms │ ├── Performance: Data sync │ ├── Offline: Full offline editing │ └── Special: Conflict resolution, background sync │ ├── Utility App工具类 │ ├── Navigation: Minimal (stack-only possible) │ ├── Lists: Probably minimal │ ├── Performance: Fast startup │ ├── Offline: Core feature offline │ └── Special: Widget, shortcuts │ └── Media/Streaming App媒体/流媒体 ├── Navigation: Tab (Home, Search, Library, Profile) ├── Lists: Horizontal carousels, vertical feeds ├── Performance: Preloading, buffering ├── Offline: Download management └── Special: Background playback, casting几个值得展开的差异点导航电商与媒体应用是标准 Tab且 tab 语义不同——购物车 vs 媒体库效率类应用倾向 Drawer 或自适应手机上 tab、平板上 rail工具类应用甚至可以只留栈导航。这直接回答导航质疑矩阵中How many destinations?背后的更深问题——项目类型决定目的地数量。性能重心电商的关键路径是图片缓存商品网格 图片优化社交应用是Feed 渲染无限滚动、复杂条目效率类是数据同步媒体类是预加载与缓冲。这为思考协议第 5 步性能影响分析提供了项目类型级别的锚点。离线策略五类项目的离线关注点各不相同购物车持久化 / Feed 缓存与草稿 / 全量离线编辑 / 核心功能离线 / 下载管理且效率类额外要求冲突解决与后台同步——这是离线编辑架构中最难的部分。九、交互拆解INTERACTION BREAKDOWN每个手势上线前的五问文档要求添加任何手势之前执行以下逐手势分析。原文模板完整继承GESTURE: [Gesture Type] ├── DISCOVERABILITY: │ └── How will users discover this gesture? │ ├── Is there a visual hint? │ ├── Will it be shown in onboarding? │ └── Is there a button alternative? (MANDATORY) │ ├── PLATFORM CONVENTION: │ ├── What does this gesture mean on iOS? │ ├── What does this gesture mean on Android? │ └── Am I deviating from platform convention? │ ├── ACCESSIBILITY: │ ├── Can motor-impaired users perform this gesture? │ ├── Is there a VoiceOver/TalkBack alternative? │ └── Does it work with switch control? │ ├── CONFLICT CHECK: │ ├── Does it conflict with system gestures? │ │ ├── iOS: Edge swipe back │ │ ├── Android: Back gesture │ │ └── Home indicator swipe │ └── Is it consistent with other app gestures? │ └── FEEDBACK: ├── Is haptic feedback defined? ├── Is visual feedback sufficient? └── Is audio feedback needed?五个分支的工程含义DISCOVERABILITY可发现性三个检查点中是否存在按钮替代方案被标为MANDATORY强制。这与 SKILL.md Touch/UX Sins 表中Gesture-only interactions → 运动障碍用户被排除 → Always provide button alternative是同一规则的两处落点也对应 mobile-developer agent 反模式表中的Skipping platform checks。PLATFORM CONVENTION平台惯例同一个手势在两平台语义可能不同例如从边缘右滑在 iOS 是返回、在 Android 可能与系统返回手势冲突自创语义会破坏用户肌肉记忆。SKILL.md 的Platform Decision Matrix把 Gestures 与 Back Navigation 明确划入DIVERGE平台分叉一侧即 iOS 用边缘滑动、Android 用系统返回。ACCESSIBILITY无障碍)覆盖运动障碍用户、VoiceOver/TalkBack 屏幕阅读替代、以及开关控制switch control。这解释了为什么 UI 质疑矩阵里 FAB 位置的追问是User handedness?惯用手而非美学问题。CONFLICT CHECK冲突检查显式列出三个系统级手势源——iOS 边缘滑动返回、Android 返回手势、Home indicator 上滑——任何自研手势都要先排除与它们的区域/方向冲突。FEEDBACK反馈闭环触觉haptic、视觉、听觉反馈是否定义。移动端的反馈成本远低于桌面 hover必须在设计期确定。十、重精神轻清单SPIRIT OVER CHECKLIST自查的最后一道防线文档专设一节警告通过清单不等于达标。它用一张自我欺骗 vs 诚实评估对照表把常见的清单式通过逐条拆穿❌ Self-Deception自我欺骗✅ Honest Assessment诚实评估Touch target is 44px但在屏幕边缘够不着Can user reach it one-handed?单手可及吗I used FlatList但没做记忆化Is scroll smooth?滚动真的流畅吗Platform-specific nav但只是图标不同Does iOS feel like iOS, Android like Android?iOS 像 iOS、Android 像 Android 吗Offline support exists但错误提示是通用的What can user actually do offline?离线时用户实际能做什么Loading state exists但只有一个 spinnerDoes user know how long to wait?用户知道要等多久吗每行都指向同一结论清单条目是必要条件而非充分条件。例如用了 FlatList只回答了组件选择性能体验取决于 renderItem 是否记忆化、key 是否稳定、动画是否走原生线程SKILL.md 要求useNativeDriver: true否则动画被 JS 线程阻塞。文档在此节末尾强调原文语义通过清单不是目标创造出色的移动 UX 才是目标。十一、移动设计承诺MOBILE DESIGN COMMITMENT与开工前验证项目启动时填写的承诺单文档要求在每个移动项目开始时填写以下承诺模板其设计意图是把思考协议的输出固化为可审查的文本 MOBILE DESIGN COMMITMENT Project: _______________ Platform: iOS / Android / Both 1. Default pattern I will NOT use in this project: └── _______________ 2. Context-specific focus for this project: └── _______________ 3. Platform-specific differences I will implement: └── iOS: _______________ └── Android: _______________ 4. Area I will specifically optimize for performance: └── _______________ 5. Unique challenge of this project: └── _______________ If I cant fill this commitment → I dont understand the project well enough. → Go back, understand context better, ask the user.五条承诺各自锁定一个决策维度本项目明确弃用的默认模式第 1 条直接消费禁用清单、上下文焦点第 2 条消费上下文决策协议、双平台差异实现第 3 条消费平台分解、性能优化重点第 4 条、项目独特挑战第 5 条。底部的兜底规则很关键填不出承诺 对项目理解不足正确动作是回去理解上下文、向用户提问——这与 SKILL.md 中ASK BEFORE ASSUMING平台、框架、导航、状态、离线、目标设备六问未指定时必须问用户以及 mobile-developer agent 的 Phase 1Requirements Analysis: If any of these are unclear → ASK USER完全一致。每次移动工作前的强制验证PRE-WORK VALIDATION最后一节把前述所有工件串成一道开工闸门┌─────────────────────────────────────────────────────────────────┐ │ PRE-WORK VALIDATION │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ □ Did I complete Component Decomposition? │ │ □ Did I fill the Pattern Questioning Matrix? │ │ □ Did I pass the Anti-Memorization Test? │ │ □ Did I make context-based decisions? │ │ □ Did I analyze Interaction Breakdown? │ │ □ Did I fill the Mobile Design Commitment? │ │ │ │ ⚠️ Do not write code without completing these! │ │ │ └─────────────────────────────────────────────────────────────────┘六个勾选项与本文第五、六、七、八、九、十一节的六套工件一一映射形成协议 → 工件 → 验证的闭环。文档的收尾句原文语义点明全部机制的哲学底座如果你选某个方案只是因为大家都这么做那你就是没有思考地选了它。每个项目都是独特的每个上下文都不同每个用户行为都是具体的。先思考再写代码THINK, then code。十二、在 ag-kit 中如何实际使用这套协议结合仓库源码结构这套协议在 ag-kit 中有清晰的执行路径触发当任务命中移动端关键词mobile、react native、flutter、ios、android、app store、expo时mobile-developer.md 定义的角色被启用其 frontmatter 声明依赖clean-code, design-spec, mobile-design三个技能。必读序按 mobile-developer 的必读表第一份必读文件就是 mobile-design-thinking.mdCRITICAL FIRST随后是 SKILL.md反模式、checkpoint、总览与 touch-psychology、mobile-performance 等 CRITICAL 文件平台文件platform-ios.md / platform-android.md按目标平台加读跨平台则两份都读。执行工件按本文第五至十一节的模板逐屏、逐手势产出分解与承诺文本SKILL.md 中另有一个并行的CHECKPOINT检查点平台 / 框架 / 已读文件 / 3 条将应用的原则 / 2 条将规避的反模式两者共同构成写码前的门禁。运行期验证设计与编码完成后可运行技能包附带的审计脚本python .agents/skills/mobile-design/scripts/mobile_audit.py project_pathSKILL.md 声明其用途为 Mobile UX Touch Audit并强调执行而非阅读。一致性保障manifest.lock.json 对 mobile-design-thinking.md 存了内容哈希任何对协议文本的改动都会与锁文件产生差异供 ag-kit 的校验体系检测。十三、适用前提与边界适用对象本技能明确面向 iOS/Android 移动应用React Native、Flutter 或原生。SKILL.md 的when_to_use写明NOT for web apps——网页项目不应套用本协议的触控与平台惯例结论。适用阶段文档定位为设计期/编码前的思考约束不替代具体的实现规范。参数级知识触控阈值、Fitts Law、60fps 规则、深链方案、框架选型树分散在同技能包的 touch-psychology.md、mobile-performance.md、mobile-navigation.md、decision-trees.md 等文件中本文档只负责逼你使用它们。判断依据的边界文中诸如6 目的地用 drawer3 个用极简 tabs等量化判据是文档给出的经验性决策锚点而非硬性标准仍需结合第六节的质疑矩阵逐案确认。与 ag-kit 体系的关系从源码结构看该文档的价值不在于被人类逐字阅读而在于作为 Agent 技能包中被编排加载的行为约束——它的强制语义MANDATORY、FORBIDDEN、PRIORITY只有在 SKILL.md 的必读机制与 mobile-developer 角色定义共同作用下才构成完整闭环。小结mobile-design-thinking.md 是 ag-kit 移动端技能包中的思维协议层以五步深度思考协议为骨架用默认模式禁用清单划定必须质疑的范围用逐屏组件分解与逐手势交互拆解把思考落到工件用模式质疑矩阵与上下文决策协议提供决策依据用反记忆化测试与SPIRIT OVER CHECKLIST防止检查流于形式最后以移动设计承诺单和开工前六项验证作为写码闸门。对于希望让 AI Agent或团队自身在移动项目中摆脱Tab bar Redux FlatList 右下角 FAB式惯性输出的开发者这份文档提供了一套完整、可执行、可审查的替代流程。【免费下载链接】ag-kit项目地址: https://gitcode.com/GitHub_Trending/an/ag-kit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ag-kit 移动设计思考协议防止 AI 落入默认模式的反记忆化移动设计决策框架【免费下载链接】ag-kit项目地址: https://gitcode.com/GitHub_Trending/an/ag-kit本文以 ag-kit 仓库mobile-design技能中的 mobile-design-thinking.md 为主体完整解读其深度移动思考协议Deep Mobile Thinking Protocol包括五步思考流程、AI 默认模式禁用清单、逐屏组件分解模板、模式质疑矩阵、上下文决策协议与手势交互拆解。读完后你将掌握一套可落地的方法论——在编写任何 React Native / Flutter / 原生移动代码之前如何强制自己或 AI Agent基于项目上下文做出导航、状态管理、列表实现与 UI 模式的取舍决策而非照搬训练数据中的安全港套路。一、这份文档在 ag-kit 中的定位移动技能包的第一优先级ag-kit 是一个面向 AI Agent 的开发套件其.agents/目录下组织了 agents专家角色、skills技能包、workflows工作流与 rules规则。mobile-design是其中一个针对移动端React Native、Flutter、原生 iOS/Android的技能包其入口 SKILL.md 的 frontmatter 明确了适用边界Mobile-first design thinking and decision-making for iOS and Android apps... Use when building React Native, Flutter, or native mobile apps.而 mobile-design-thinking.md 在该技能包中承担着特殊的角色——它不是参数速查表而是一份思维约束文件。SKILL.md 在必读参考文件一节中将其标注为最高优先级文件内容状态mobile-design-thinking.md⚠️ ANTI-MEMORIZATION: 强制思考、防止 AI 默认套路CRITICAL FIRST最先读该技能在 manifest.json 中以mobile-design: ^1.0.0版本约束注册入口指向skills/mobile-design/SKILL.md并附带运行期验证脚本scripts/mobile_audit.py调用方式为python scripts/mobile_audit.py project_path用于移动 UX 与触控审计。同时manifest.lock.json 对本文档保留了内容哈希说明 ag-kit 将技能文档视为受版本控制锁定的资产。从 Agent 编排角度看mobile-developer.md 是触发移动开发任务的专家角色。它把本文档列为开工前必读表格中的第一行并注明⚠️ ANTI-MEMORIZATION: Think, dont copy且给出了一句强制性说明mobile-design-thinking.md is PRIORITY! Prevents memorized patterns, forces thinking.这是优先级文件防止记忆化模式、强制思考。换句话说在 ag-kit 的体系里动笔写移动代码之前先过一遍这份思考协议是被系统级流程强制要求的。二、核心宗旨禁止记忆化模式强制真实思考文档开篇即给出它的存在理由引用原文语义This file prevents AI from using memorized patterns and forces genuine thinking.本文件防止 AI 使用记忆化模式并强制真实思考。 Mechanisms to prevent standard AI training defaults in mobile development.用于阻止移动开发中 AI 训练数据默认值的一套机制。The mobile equivalent of frontends layout decomposition approach.它是前端布局分解方法在移动端的对应物。这三句话概括了协议的设计动机问题LLM 在移动开发任务上存在强烈的训练数据惯性——Tab bar、Redux、FlatList、右下角 FAB 这些模式出现频率极高AI 会无意识地原样复现而不判断它们是否适合当前项目机制通过禁用清单 质疑矩阵 强制分解三层机制把每个默认选择都变成必须回答的决策问题定位与 ag-kit 前端技能frontend-design 的布局分解思路形成对偶——先分解结构再谈实现。三、深度移动思考协议DEEP MOBILE THINKING PROTOCOL文档将以下流程定义为每个移动项目开工前的强制流程Mandatory Before Every Mobile Project。五个步骤如下全部继承自原文档┌─────────────────────────────────────────────────────────────────┐ │ DEEP MOBILE THINKING │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 1. CONTEXT SCAN上下文扫描 │ │ └── What are my assumptions for this project? │ │ └── QUESTION these assumptions质疑这些假设 │ │ │ │ 2. ANTI-DEFAULT ANALYSIS反默认分析 │ │ └── Am I applying a memorized pattern? │ │ └── Is this pattern REALLY the best for THIS project? │ │ │ │ 3. PLATFORM DECOMPOSITION平台分解 │ │ └── Did I think about iOS and Android separately? │ │ └── What are the platform-specific patterns? │ │ │ │ 4. TOUCH INTERACTION BREAKDOWN触控交互拆解 │ │ └── Did I analyze each interaction individually? │ │ └── Did I apply Fitts Law, Thumb Zone? │ │ │ │ 5. PERFORMANCE IMPACT ANALYSIS性能影响分析 │ │ └── Did I consider performance impact of each component? │ │ └── Is the default solution performant? │ └─────────────────────────────────────────────────────────────────┘五个步骤各自解决的典型问题第 1 步上下文扫描先显式列出你对项目的全部假设用户画像、使用场景、网络环境然后逐条质疑。它直接服务于第六节的上下文决策协议——不同项目类型应有不同默认答案。第 2 步反默认分析识别我是不是在套用记忆化模式并追问这个模式对这个项目真的最优吗。这一步是全文档的枢纽禁用清单第四节提供识别对象质疑矩阵第五节提供追问方式。第 3 步平台分解强制把 iOS 与 Android 拆开想。这与同技能包 platform-ios.mdHIG、SF Pro、SwiftUI 模式和 platform-android.mdMaterial Design 3、Roboto、Compose 模式配套SKILL.md 明确要求iOS 项目先读 platform-ios.md跨平台项目两份都读并应用条件化平台逻辑。第 4 步触控交互拆解要求逐个交互分析并显式应用 Fitts Law 与 Thumb Zone拇指区。其细节由同技能包的 touch-psychology.md 支撑该文件给出触控版 Fitts Law 公式Touch acquisition time a b × log₂(1 D/W)D 为距离、W 为目标宽度触控要求 W 远大于桌面、最小触控目标尺寸表iOS 44pt / Android 48dp / WCAG 44px以及单手拇指弧线的分区图。第 5 步性能影响分析对每个组件追问性能代价并质疑默认方案本身就是高性能的吗。同技能包的 mobile-performance.md 提供 RN/Flutter 的 60fps、内存等具体规则。四、AI 移动端默认模式禁用清单AI MOBILE DEFAULTS / FORBIDDEN LIST这是协议的核心资产之一文档声明自动使用以下模式是 FORBIDDEN被禁止的因为它们是从训练数据中习得的默认值使用之前必须质疑并考虑替代方案。清单按四个维度组织以下为原文档完整内容┌─────────────────────────────────────────────────────────────────┐ │ AI MOBILE SAFE HARBOR │ │ (Default Patterns - Never Use Without Questioning) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ NAVIGATION DEFAULTS导航默认: │ │ ├── Tab bar for every project (Would drawer be better?) │ │ ├── Fixed 5 tabs (Are 3 enough? For 6, drawer?) │ │ ├── Home tab on left (What does user behavior say?) │ │ └── Hamburger menu (Is it outdated now?) │ │ │ │ STATE MANAGEMENT DEFAULTS状态管理默认: │ │ ├── Redux everywhere (Is Zustand/Jotai sufficient?) │ │ ├── Global state for everything (Isnt local state enough?) │ │ ├── Context Provider hell (Is atom-based better?) │ │ └── BLoC for every Flutter project (Is Riverpod more modern?) │ │ │ │ LIST IMPLEMENTATION DEFAULTS列表实现默认: │ │ ├── FlatList as default (Is FlashList more performant?) │ │ ├── windowSize21 (Is it really needed?) │ │ ├── removeClippedSubviews (Always?) │ │ └── ListView.builder (Is ListView.separated better?) │ │ │ │ UI PATTERN DEFAULTSUI 模式默认: │ │ ├── FAB bottom-right (Is bottom-left more accessible?) │ │ ├── Pull-to-refresh on every list (Is it needed everywhere?) │ │ ├── Swipe-to-delete from left (Is right better?) │ │ └── Bottom sheet for every modal (Is full screen better?) │ │ │ └─────────────────────────────────────────────────────────────────┘逐条解读其设计意图导航默认文档并不反对 Tab bar 本身而是反对不看目的地数量就用 Tab bar。括号内的追问即答案线索——抽屉菜单会不会更好固定 5 个 tab 合理吗3 个够不够、6 个以上是否该用 drawerHome 放左侧有什么用户行为依据汉堡菜单是否已过时状态管理默认针对 AI 最典型的过设计倾向。到处 Redux要对照 Zustand/Jotai 的轻量性万物皆全局状态要追问局部状态是否足够Context Provider 地狱要评估 atom 化的重渲染代价BLoC 也要对照 Riverpod 的样板代码量。这与 decision-trees.md 中的状态管理决策树简单应用、少量屏幕、极少共享状态 → Zustand甚至 useState/Context是同一思路的两种表达。列表实现默认注意它连windowSize21、removeClippedSubviews这类教科书参数也列入质疑——这正是针对背参数式 AI 输出的精确打击。SKILL.md 中给出的优化 FlatList 示例windowSize{5}、maxToRenderPerBatch{10}反而使用了更小的 windowSize印证了参数必须按项目调整而非照抄的主旨。UI 模式默认FAB 位置、下拉刷新、左滑删除、Bottom sheet 全部要求逐案判断。值得注意的是FAB 右下角被质疑的角度是可达性与惯用手bottom-left 是否对某些用户更易触达而非美观——这与 touch-psychology.md 的拇指弧线分析右手持机时屏幕右下更易够到相互呼应。需要强调这份清单是**未经质疑不得直接使用**而不是永远禁用。协议的目标是把每个默认值从无意识复现变成有意识的选择。五、逐屏组件分解COMPONENT DECOMPOSITION强制模板文档要求设计任何屏幕之前执行以下结构化分解。这是整份文档最接近可操作工件的部分原文模板完整保留如下SCREEN: [Screen Name] ├── PRIMARY ACTION: [What is the main action?] │ └── Is it in thumb zone? [Yes/No → Why?] │ ├── TOUCH TARGETS: [All tappable elements] │ ├── [Element 1]: [Size]pt → Sufficient? │ ├── [Element 2]: [Size]pt → Sufficient? │ └── Spacing: [Gap]pt → Accidental tap risk? │ ├── SCROLLABLE CONTENT: │ ├── Is it a list? → FlatList/FlashList [Why this choice?] │ ├── Item count: ~[N] → Performance consideration? │ └── Fixed height? → Is getItemLayout needed? │ ├── STATE REQUIREMENTS: │ ├── Is local state sufficient? │ ├── Do I need to lift state? │ └── Is global required? [Why?] │ ├── PLATFORM DIFFERENCES: │ ├── iOS: [Anything different needed?] │ └── Android: [Anything different needed?] │ ├── OFFLINE CONSIDERATION: │ ├── Should this screen work offline? │ └── Cache strategy: [Yes/No/Which one?] │ └── PERFORMANCE IMPACT: ├── Any heavy components? ├── Is memoization needed? └── Animation performance?该模板把思考协议的五步压缩到屏幕这个粒度上每个分支都对应一个必须书面的判断PRIMARY ACTION 拇指区检查主操作是否在拇指可达区回答否时必须给出理由。SKILL.md 的拇指区示意图把屏幕分为三层——顶部 HARD TO REACH放返回/菜单、中部 OK TO REACH次级操作、底部 EASY TO REACH主 CTA 与 Tab bar。TOUCH TARGETS逐项列出尺寸pt与间距并判断误触风险。配套阈值来自 touch-psychology.mdiOS 最小 44pt、Android 最小 48dp、目标间留白 8–12px图标按钮视觉 24–32px 但点击区必须 44–48px。SCROLLABLE CONTENT三问决定列表实现——用 FlatList 还是 FlashList为什么、条目规模是否需要考虑性能、高度是否固定固定则应提供getItemLayout避免异步布局导致滚动卡顿。这三问恰好命中 SKILL.md Performance Sins 表格中的三条ScrollView 渲染全部条目导致内存爆炸、缺失getItemLayout、缺失keyExtractor用 index 做 key 在重排时会出错。STATE REQUIREMENTS状态提升的三级阶梯——局部状态够吗 → 需要提升吗 → 真的需要全局吗要写理由。这是禁用清单中Global state for everything追问的模板化落地。PLATFORM DIFFERENCES / OFFLINE / PERFORMANCE分别对应思考协议第 3、4离线属于 SKILL.md 必问项Does this need to work offline?与第 5 步。六、模式质疑矩阵PATTERN QUESTIONING MATRIX第四节是列出要质疑什么本节则给出用什么问题质疑、替代方案是什么。文档要求对每个默认模式回答Assumption假设→ Question问题→ Alternative替代。以下为原文四张矩阵表完整继承导航模式质疑AssumptionQuestionAlternativeIll use tab barHow many destinations?3 → minimal tabs, 6 → drawer5 tabsAre all equally important?More tab? Drawer hybrid?Bottom naviPad/tablet support?Navigation rail alternativeStack navigationDid I consider deep links?URL structure navigation structure矩阵给出了一个可操作的量化判据目的地3 个用极简 tabs6 个以上转向 drawer平板场景考虑 Navigation rail以及一条容易被忽略的架构原则——URL 结构即导航结构深链deep links应在一开始就规划SKILL.md 的架构罪清单同样把Deep linking as afterthought列为禁忌。状态模式质疑AssumptionQuestionAlternativeIll use ReduxHow complex is the app?Simple: Zustand, Server: TanStackGlobal stateIs this state really global?Local lift, Context selectorContext ProviderWill re-render be an issue?Zustand, Jotai (atom-based)BLoC patternIs the boilerplate worth it?Riverpod (less code)注意第二行服务端状态单列为 TanStackQuery 类方案——这提醒读者很多全局状态其实只是缓存的服务器数据选型应分开考虑。列表模式质疑AssumptionQuestionAlternativeFlatListIs performance critical?FlashList (faster)Standard renderItemIs it memoized?useCallback React.memoIndex keyDoes data order change?Use item.idListViewAre there separators?ListView.separatedUI 模式质疑AssumptionQuestionAlternativeFAB bottom-rightUser handedness?Accessibility settingsPull-to-refreshDoes this list need refresh?Only when necessaryModal bottom sheetHow much content?Full screen modal might be betterSwipe actionsDiscoverability?Visible button alternativeSwipe actions → Discoverability?一问与后文 INTERACTION BREAKDOWN 中的手势必须提供按钮替代方案MANDATORY相互咬合滑动类操作天然缺乏可发现性矩阵直接要求准备可见按钮这一替代路径。七、反记忆化测试ANTI-MEMORIZATION TEST在给出任何具体方案之前文档要求执行以下 7 项自查清单。这是整套协议中唯一针对执行者本身AI 或工程师的元检查┌─────────────────────────────────────────────────────────────────┐ │ ANTI-MEMORIZATION CHECKLIST │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ □ Did I pick this solution because I always do it this way? │ │ → If YES: STOP. Consider alternatives. │ │ │ │ □ Is this a pattern Ive seen frequently in training data? │ │ → If YES: Is it REALLY suitable for THIS project? │ │ │ │ □ Did I write this solution automatically without thinking? │ │ → If YES: Step back, do decomposition. │ │ │ │ □ Did I consider an alternative approach? │ │ → If NO: Think of at least 2 alternatives, then decide. │ │ │ │ □ Did I think platform-specifically? │ │ → If NO: Analyze iOS and Android separately. │ │ │ │ □ Did I consider performance impact of this solution? │ │ → If NO: What is the memory, CPU, battery impact? │ │ │ │ □ Is this solution suitable for THIS projects CONTEXT? │ │ → If NO: Customize based on context. │ └─────────────────────────────────────────────────────────────────┘七问的设计有递进关系前三问识别惯性输出凭习惯选 / 训练数据高频模式 / 无意识自动补全第四问是硬约束——至少想出 2 个替代方案再决定这是思考过与复述过的可判定分界后三问把平台差异、性能影响内存/CPU/电池、项目上下文补成决策闭环。移动端之所以要把性能影响落到battery这一项是因为 SKILL.md 的技能哲学第一条就是Touch-first. Battery-conscious.触控优先、电量敏感。八、基于上下文的决策协议CONTEXT-BASED DECISION PROTOCOL不同项目类型用不同方式思考——本节以决策树形式给出五类典型项目的差异化默认。这是第四节禁用清单的答案库同样的问题导航列表离线在不同项目里有不同正确答案。原文档内容完整继承如下DETERMINE PROJECT TYPE: │ ├── E-Commerce App电商 │ ├── Navigation: Tab (Home, Search, Cart, Account) │ ├── Lists: Product grids (memoized, image optimized) │ ├── Performance: Image caching CRITICAL │ ├── Offline: Cart persistence, product cache │ └── Special: Checkout flow, payment security │ ├── Social/Content App社交/内容 │ ├── Navigation: Tab (Feed, Search, Create, Notify, Profile) │ ├── Lists: Infinite scroll, complex items │ ├── Performance: Feed rendering CRITICAL │ ├── Offline: Feed cache, draft posts │ └── Special: Real-time updates, media handling │ ├── Productivity/SaaS App效率/SaaS │ ├── Navigation: Drawer or adaptive (mobile tab, tablet rail) │ ├── Lists: Data tables, forms │ ├── Performance: Data sync │ ├── Offline: Full offline editing │ └── Special: Conflict resolution, background sync │ ├── Utility App工具类 │ ├── Navigation: Minimal (stack-only possible) │ ├── Lists: Probably minimal │ ├── Performance: Fast startup │ ├── Offline: Core feature offline │ └── Special: Widget, shortcuts │ └── Media/Streaming App媒体/流媒体 ├── Navigation: Tab (Home, Search, Library, Profile) ├── Lists: Horizontal carousels, vertical feeds ├── Performance: Preloading, buffering ├── Offline: Download management └── Special: Background playback, casting几个值得展开的差异点导航电商与媒体应用是标准 Tab且 tab 语义不同——购物车 vs 媒体库效率类应用倾向 Drawer 或自适应手机上 tab、平板上 rail工具类应用甚至可以只留栈导航。这直接回答导航质疑矩阵中How many destinations?背后的更深问题——项目类型决定目的地数量。性能重心电商的关键路径是图片缓存商品网格 图片优化社交应用是Feed 渲染无限滚动、复杂条目效率类是数据同步媒体类是预加载与缓冲。这为思考协议第 5 步性能影响分析提供了项目类型级别的锚点。离线策略五类项目的离线关注点各不相同购物车持久化 / Feed 缓存与草稿 / 全量离线编辑 / 核心功能离线 / 下载管理且效率类额外要求冲突解决与后台同步——这是离线编辑架构中最难的部分。九、交互拆解INTERACTION BREAKDOWN每个手势上线前的五问文档要求添加任何手势之前执行以下逐手势分析。原文模板完整继承GESTURE: [Gesture Type] ├── DISCOVERABILITY: │ └── How will users discover this gesture? │ ├── Is there a visual hint? │ ├── Will it be shown in onboarding? │ └── Is there a button alternative? (MANDATORY) │ ├── PLATFORM CONVENTION: │ ├── What does this gesture mean on iOS? │ ├── What does this gesture mean on Android? │ └── Am I deviating from platform convention? │ ├── ACCESSIBILITY: │ ├── Can motor-impaired users perform this gesture? │ ├── Is there a VoiceOver/TalkBack alternative? │ └── Does it work with switch control? │ ├── CONFLICT CHECK: │ ├── Does it conflict with system gestures? │ │ ├── iOS: Edge swipe back │ │ ├── Android: Back gesture │ │ └── Home indicator swipe │ └── Is it consistent with other app gestures? │ └── FEEDBACK: ├── Is haptic feedback defined? ├── Is visual feedback sufficient? └── Is audio feedback needed?五个分支的工程含义DISCOVERABILITY可发现性三个检查点中是否存在按钮替代方案被标为MANDATORY强制。这与 SKILL.md Touch/UX Sins 表中Gesture-only interactions → 运动障碍用户被排除 → Always provide button alternative是同一规则的两处落点也对应 mobile-developer agent 反模式表中的Skipping platform checks。PLATFORM CONVENTION平台惯例同一个手势在两平台语义可能不同例如从边缘右滑在 iOS 是返回、在 Android 可能与系统返回手势冲突自创语义会破坏用户肌肉记忆。SKILL.md 的Platform Decision Matrix把 Gestures 与 Back Navigation 明确划入DIVERGE平台分叉一侧即 iOS 用边缘滑动、Android 用系统返回。ACCESSIBILITY无障碍)覆盖运动障碍用户、VoiceOver/TalkBack 屏幕阅读替代、以及开关控制switch control。这解释了为什么 UI 质疑矩阵里 FAB 位置的追问是User handedness?惯用手而非美学问题。CONFLICT CHECK冲突检查显式列出三个系统级手势源——iOS 边缘滑动返回、Android 返回手势、Home indicator 上滑——任何自研手势都要先排除与它们的区域/方向冲突。FEEDBACK反馈闭环触觉haptic、视觉、听觉反馈是否定义。移动端的反馈成本远低于桌面 hover必须在设计期确定。十、重精神轻清单SPIRIT OVER CHECKLIST自查的最后一道防线文档专设一节警告通过清单不等于达标。它用一张自我欺骗 vs 诚实评估对照表把常见的清单式通过逐条拆穿❌ Self-Deception自我欺骗✅ Honest Assessment诚实评估Touch target is 44px但在屏幕边缘够不着Can user reach it one-handed?单手可及吗I used FlatList但没做记忆化Is scroll smooth?滚动真的流畅吗Platform-specific nav但只是图标不同Does iOS feel like iOS, Android like Android?iOS 像 iOS、Android 像 Android 吗Offline support exists但错误提示是通用的What can user actually do offline?离线时用户实际能做什么Loading state exists但只有一个 spinnerDoes user know how long to wait?用户知道要等多久吗每行都指向同一结论清单条目是必要条件而非充分条件。例如用了 FlatList只回答了组件选择性能体验取决于 renderItem 是否记忆化、key 是否稳定、动画是否走原生线程SKILL.md 要求useNativeDriver: true否则动画被 JS 线程阻塞。文档在此节末尾强调原文语义通过清单不是目标创造出色的移动 UX 才是目标。十一、移动设计承诺MOBILE DESIGN COMMITMENT与开工前验证项目启动时填写的承诺单文档要求在每个移动项目开始时填写以下承诺模板其设计意图是把思考协议的输出固化为可审查的文本 MOBILE DESIGN COMMITMENT Project: _______________ Platform: iOS / Android / Both 1. Default pattern I will NOT use in this project: └── _______________ 2. Context-specific focus for this project: └── _______________ 3. Platform-specific differences I will implement: └── iOS: _______________ └── Android: _______________ 4. Area I will specifically optimize for performance: └── _______________ 5. Unique challenge of this project: └── _______________ If I cant fill this commitment → I dont understand the project well enough. → Go back, understand context better, ask the user.五条承诺各自锁定一个决策维度本项目明确弃用的默认模式第 1 条直接消费禁用清单、上下文焦点第 2 条消费上下文决策协议、双平台差异实现第 3 条消费平台分解、性能优化重点第 4 条、项目独特挑战第 5 条。底部的兜底规则很关键填不出承诺 对项目理解不足正确动作是回去理解上下文、向用户提问——这与 SKILL.md 中ASK BEFORE ASSUMING平台、框架、导航、状态、离线、目标设备六问未指定时必须问用户以及 mobile-developer agent 的 Phase 1Requirements Analysis: If any of these are unclear → ASK USER完全一致。每次移动工作前的强制验证PRE-WORK VALIDATION最后一节把前述所有工件串成一道开工闸门┌─────────────────────────────────────────────────────────────────┐ │ PRE-WORK VALIDATION │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ □ Did I complete Component Decomposition? │ │ □ Did I fill the Pattern Questioning Matrix? │ │ □ Did I pass the Anti-Memorization Test? │ │ □ Did I make context-based decisions? │ │ □ Did I analyze Interaction Breakdown? │ │ □ Did I fill the Mobile Design Commitment? │ │ │ │ ⚠️ Do not write code without completing these! │ │ │ └─────────────────────────────────────────────────────────────────┘六个勾选项与本文第五、六、七、八、九、十一节的六套工件一一映射形成协议 → 工件 → 验证的闭环。文档的收尾句原文语义点明全部机制的哲学底座如果你选某个方案只是因为大家都这么做那你就是没有思考地选了它。每个项目都是独特的每个上下文都不同每个用户行为都是具体的。先思考再写代码THINK, then code。十二、在 ag-kit 中如何实际使用这套协议结合仓库源码结构这套协议在 ag-kit 中有清晰的执行路径触发当任务命中移动端关键词mobile、react native、flutter、ios、android、app store、expo时mobile-developer.md 定义的角色被启用其 frontmatter 声明依赖clean-code, design-spec, mobile-design三个技能。必读序按 mobile-developer 的必读表第一份必读文件就是 mobile-design-thinking.mdCRITICAL FIRST随后是 SKILL.md反模式、checkpoint、总览与 touch-psychology、mobile-performance 等 CRITICAL 文件平台文件platform-ios.md / platform-android.md按目标平台加读跨平台则两份都读。执行工件按本文第五至十一节的模板逐屏、逐手势产出分解与承诺文本SKILL.md 中另有一个并行的CHECKPOINT检查点平台 / 框架 / 已读文件 / 3 条将应用的原则 / 2 条将规避的反模式两者共同构成写码前的门禁。运行期验证设计与编码完成后可运行技能包附带的审计脚本python .agents/skills/mobile-design/scripts/mobile_audit.py project_pathSKILL.md 声明其用途为 Mobile UX Touch Audit并强调执行而非阅读。一致性保障manifest.lock.json 对 mobile-design-thinking.md 存了内容哈希任何对协议文本的改动都会与锁文件产生差异供 ag-kit 的校验体系检测。十三、适用前提与边界适用对象本技能明确面向 iOS/Android 移动应用React Native、Flutter 或原生。SKILL.md 的when_to_use写明NOT for web apps——网页项目不应套用本协议的触控与平台惯例结论。适用阶段文档定位为设计期/编码前的思考约束不替代具体的实现规范。参数级知识触控阈值、Fitts Law、60fps 规则、深链方案、框架选型树分散在同技能包的 touch-psychology.md、mobile-performance.md、mobile-navigation.md、decision-trees.md 等文件中本文档只负责逼你使用它们。判断依据的边界文中诸如6 目的地用 drawer3 个用极简 tabs等量化判据是文档给出的经验性决策锚点而非硬性标准仍需结合第六节的质疑矩阵逐案确认。与 ag-kit 体系的关系从源码结构看该文档的价值不在于被人类逐字阅读而在于作为 Agent 技能包中被编排加载的行为约束——它的强制语义MANDATORY、FORBIDDEN、PRIORITY只有在 SKILL.md 的必读机制与 mobile-developer 角色定义共同作用下才构成完整闭环。小结mobile-design-thinking.md 是 ag-kit 移动端技能包中的思维协议层以五步深度思考协议为骨架用默认模式禁用清单划定必须质疑的范围用逐屏组件分解与逐手势交互拆解把思考落到工件用模式质疑矩阵与上下文决策协议提供决策依据用反记忆化测试与SPIRIT OVER CHECKLIST防止检查流于形式最后以移动设计承诺单和开工前六项验证作为写码闸门。对于希望让 AI Agent或团队自身在移动项目中摆脱Tab bar Redux FlatList 右下角 FAB式惯性输出的开发者这份文档提供了一套完整、可执行、可审查的替代流程。【免费下载链接】ag-kit项目地址: https://gitcode.com/GitHub_Trending/an/ag-kit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
