页面生成器 (Page Generator Skill)

任务目标

本 Skill 用于：在 apps/web/src/pages 目录下快速生成符合项目架构规范的新页面。
核心理念：架构先行。先生成符合规范的代码骨架（脚手架），再由开发者或 AI 填充业务逻辑。
触发条件：当用户要求“创建新页面”、“增加路由页面”或“生成页面脚手架”时。

生成模式 (Generation Modes)

本 Skill 支持两种生成模式，用户可在开始时选择：

无监督生成 (Unsupervised)

适用场景：Anatomy 规范足够完备，AI 可自动推导完整结构。
特点：全自动运行，无需人工干预。
流程：直接使用 judgeHasStore.ts 的逻辑判断所有选项，生成完整结构。

有监督生成 (Supervised)

适用场景：存在选项判断的不确定性，需要人工确认。
特点：在关键节点（如是否需要 Store）提问确认，AI 提供推荐但由用户决策。
流程：使用 judgeHasStore.ts 的逻辑判断提供推荐值，提问用户确认是否采纳。

主动模式选择 (Active Mode Selection)

重要行为要求：本技能必须在开始任何生成工作前主动询问用户选择生成模式。

询问时机

触发条件：当用户请求创建新页面时
询问位置：在所有分析和判断之前
强制要求：不能跳过此步骤或默认选择模式

选择界面

提供清晰的选择界面，包含：

模式名称：无监督生成 / 有监督生成
简要描述：每种模式的特点和适用场景
推荐建议：基于页面复杂度的智能推荐（可选）

用户决策

等待确认：必须等待用户明确选择后再继续
不可跳过：如果用户未选择，不得继续执行
可取消：允许用户取消操作

UI 复杂度控制 (UI Complexity Control)

复杂度等级

简单模式 (Simple): 基础布局 + 基础组件，适合展示型页面
标准模式 (Standard): 搜索/过滤 + 列表展示，适合数据管理页面
复杂模式 (Complex): 多标签页 + 高级交互，适合功能丰富的页面

功能适配原则

基于需求生成: 根据页面实际需求选择合适的UI复杂度
避免过度设计: 不要添加用户不需要的功能
保持一致性: 遵循现有页面的设计模式和交互方式

复杂度判断逻辑

使用 judgeUIComplexity.ts 智能判断UI复杂度等级
基于页面名称、描述和功能需求自动推导
支持手动指定复杂度覆盖自动判断

使用示例 (Usage Examples)

典型使用场景

用户输入：创建一个用户管理页面，需要显示用户列表、支持搜索和筛选。

Skill 响应：

主动询问生成模式：显示模式选择界面，要求用户选择无监督或有监督生成
根据用户选择，自动分析需求，判断需要 Store 和标准复杂度
生成完整的页面结构和代码
提供路由注册指导

具体配置示例请参考 TEMPLATE_VIEW.md 中的配置示例部分。

生成结果示例

请参考 ANATOMY.md 的目录结构树部分。

核心规范 (Knowledge Base)

输入参数规范

pageName: 页面名称，必须为 PascalCase 格式
features.hasStore: 是否需要状态管理（系统自动判断）
features.uiComplexity: UI 复杂度等级（simple/standard/complex，系统自动判断）
description: 页面功能描述，用于智能判断复杂度

本 Skill 的执行完全依赖以下规范文档，请在生成代码时仔细参考：

整体结构: references/ANATOMY.md (目录结构、命名规范)
输入规范: references/schema.ts (参数校验)
Store判断逻辑: references/judgeHasStore.ts (智能判断是否需要Store)
UI复杂度判断: references/judgeUIComplexity.ts (智能判断UI复杂度等级)
Index模版: references/TEMPLATE_INDEX.md (入口文件写法)
Wrapper模版: references/TEMPLATE_WRAPPER.md (依赖注入层写法)
View模版: references/TEMPLATE_VIEW.md (UI层写法)
Store模版: references/TEMPLATE_STORE.md (状态层写法)

质量保证 (Quality Assurance)

代码生成原则

类型安全: 所有生成的代码必须通过 TypeScript 编译
性能优化: 强制使用 Zustand selectors，避免不必要的重渲染
架构一致性: 严格遵循项目的技术栈和模式
可维护性: 生成的代码应易于理解和扩展

错误处理

生成前验证目标路径不存在，避免覆盖
提供清晰的错误信息和修复建议
支持回滚机制（如果生成失败）

操作步骤 (Workflow)

0. 模式选择 (Mode Selection) - 必须主动询问

重要：在开始任何生成工作前，必须主动询问用户选择哪种生成模式。不要默认使用无监督模式。

主动询问：显示清晰的选择界面，让用户选择生成模式
选项说明：
- 无监督生成 (Unsupervised): 全自动判断所有参数，适合标准场景
- 有监督生成 (Supervised): 在关键决策点询问用户确认，适合不确定或复杂场景
用户决策：等待用户明确选择后再继续

0.1. 现有代码分析 (Existing Code Analysis)

检查目标路径是否已存在页面文件
如果存在，分析现有代码结构、样式和组件使用
询问用户是否要：
- 重构现有代码：保留业务逻辑与样式，只规范化架构
- 重新生成：完全替换为新架构
- 增量改进：在现有基础上添加缺失的架构元素

1. 意图解析与校验

读取用户指令，确定生成模式
使用 schema.ts 中的规则校验参数

1.1. Store 判断逻辑

无监督模式：直接调用 judgeHasStoreFromDescription() 自动判断
有监督模式：调用 judgeHasStoreSupervised() 获取推荐，询问用户确认

1.2. UI 复杂度判断

无监督模式：直接调用 judgeUIComplexity() 自动判断
有监督模式：调用 judgeUIComplexitySupervised() 获取推荐，询问用户确认

2. 规划文件列表

根据 ANATOMY.md 和 hasStore 参数，规划需要创建的文件路径。

基础文件：index.ts, [PageName].tsx, [PageName]Content.tsx
可选文件：_store/index.ts, _store/provider.tsx, _store/[camelCase]Slice.ts, _store/[camelCase]Store.ts (仅当 hasStore=true)

3. 代码生成 (按顺序)

请复用 References 中的模版，将 {{PageName}} 和 {{camelCasePageName}} 替换为实际值。

步骤 3.1: 生成 Store 模块 (可选)

如果 hasStore=true，参考 TEMPLATE_STORE.md 生成 4 个文件（Slice 模式）。
注意 provider.tsx 中必须包含 @/hooks/useInit 的引用。
重要验证：确保 Store 仅存储 UI 状态，不存储业务实体数据。

步骤 3.2: 生成 UI 视图 (Content)

参考 TEMPLATE_VIEW.md。
根据 uiComplexity 参数选择合适的UI复杂度：
- simple: 基础布局，无搜索/排序功能，仅基础展示
- standard: 添加搜索和排序功能，适合数据管理页面
- complex: 添加标签页、高级过滤、批量操作等，适合功能丰富的页面
如果有 Store，保留 Store 连接的 TODO 注释。
使用 cn 和 Flex 布局生成基础骨架。
重要: 避免过度设计，只生成实际需要的功能

步骤 3.3: 生成包装器 (Wrapper)

参考 TEMPLATE_WRAPPER.md。
关键: 如果生成了 Store，Wrapper 必须正确引入并嵌套 <StoreProvider>。如果没生成 Store，则不要引入。
布局处理: 优先使用路由层面的统一布局，仅在页面需要独特布局时在 Wrapper 中包含布局组件。

步骤 3.4: 生成入口 (Index)

参考 TEMPLATE_INDEX.md。
只导出包装器组件，不导出Content组件

步骤 3.5: 质量验证 (新增)

验证 Store 模块是否符合 TEMPLATE_STORE.md 的规范
检查是否仅存储 UI 状态，不存储业务数据
确认依赖注入和类型安全

4. 输出确认

告知用户页面已生成至指定路径。
提醒用户需在路由文件（如 routeTree 或 router.tsx）中注册该页面。
提供生成的组件使用示例。
建议运行测试验证生成代码。

page-generator