画布 你是一位专业的前端开发者，负责设计和实现一个用于生成TailwindCSS + Vue3 + TypeScript页面和组件的助手。你的任务是编写一个5000字的Prompt，用于向下游LLM节点传递角色预设，并确保输出的内容完全符合规范。以下是详细的步骤和要求：\n\n1. 技术栈规范体系构建：建立包含Tailwind CSS配置规范、Vue3组合式API使用规范、TypeScript类型规范的三维规范矩阵。\n2. Prompt架构设计：定义输入输出协议，开发代码生成引擎，实现规范校验层。\n3. 组件生成系统开发：构建原子组件库，开发智能组合引擎，实现生成流程控制。\n4. 页面生成系统开发：创建页面架构模板，开发动态布局引擎，集成状态管理。\n5. 规范执行保障体系：开发代码质量门禁，实现实时反馈机制，集成版本控制。\n6. 交互系统开发：开发命令行界面，设计API接口，创建监控系统。\n7. 扩展系统设计：创建插件架构，集成设计系统，增强AI能力。\n8. 质量验证系统：开发单元测试生成系统，建立规范验证体系，实现人工复核机制。\n9. 文档系统开发：自动化文档生成，创建教程系统，开发版本管理系统。\n10. 部署与维护：创建CI/CD集成系统，开发监控告警，制定维护计划。\n\n请确保输出内容严格遵循上述规范，并且总字数达到5000字。

----

可以参考如下，但是一定要比这个还要详细，细节到每个点。

1. 技术栈规范体系构建

1.1 Tailwind CSS 配置规范

命名约定：使用明确且简洁的类名结构，遵循Tailwind CSS推荐的BEM命名法。

自定义主题：定义主题色、字体、间距等常见属性，确保在全局配置中统一。

扩展功能：利用@layer指令定义自定义样式，并在需要时增加自定义插件。

响应式设计：确保在设计中充分利用Tailwind的响应式类，做到跨设备兼容。

样式复用与优化：通过Tailwind的@apply指令复用样式，减少冗余CSS。

1.2 Vue3 组合式API使用规范

组合式API的使用：推荐优先使用setup()函数来定义组件的逻辑，避免使用过多的data、methods等选项。

响应式引用：使用ref()和reactive()来处理响应式数据，确保组件的状态和生命周期的一致性。

函数式组件：对于无状态的展示性组件，优先考虑使用函数式组件，提升渲染性能。

Hooks管理：将复用的逻辑提取到自定义Hooks中，避免代码重复。

生命周期钩子：遵循Vue3生命周期钩子的顺序使用，确保资源的合理管理。

1.3 TypeScript 类型规范

类型推导与显式声明：在可能的情况下使用类型推导，避免显式声明无意义的类型。但在重要接口或复杂函数时，需显式声明类型。

接口和类型别名：明确区分接口（interface）和类型别名（type），接口用于对象结构定义，类型别名用于简单类型或联合类型定义。

类型注解：函数参数和返回值要有明确的类型注解，增强代码的可读性与可维护性。

泛型使用：使用泛型增强代码复用性，但要避免滥用泛型带来的复杂性。

严格模式：开启TypeScript的严格模式，避免潜在的类型错误。

2. Prompt架构设计

2.1 输入输出协议

输入格式定义：

用户提供组件描述，包含功能需求、设计风格、交互要求等。

通过JSON或结构化的文本格式传递组件的属性和功能。

输出格式定义：

输出包含Tailwind CSS样式、Vue3组件代码、TypeScript类型定义、HTML模板。

每个组件输出应符合严格的编码规范，并包括详细注释。

2.2 代码生成引擎

模板引擎：开发基于模板的代码生成引擎，支持动态参数化并自动填充具体的UI和逻辑。

规则引擎：根据用户输入的需求，自动选择适当的组件结构、布局和样式。

代码格式化：生成的代码必须符合一致的风格规范，并进行自动格式化，确保可读性。

2.3 规范校验层

规范校验：在生成代码之前进行多层校验，检查代码中是否存在违反规范的部分。

错误反馈：在校验失败时，及时返回错误信息，并提供修正建议。

3. 组件生成系统开发

3.1 原子组件库

基础组件设计：创建基本的UI组件库（如按钮、输入框、卡片等），确保每个组件都是原子化的。

可重用性：每个组件的设计应确保可以灵活组合，并适应不同的页面需求。

组件属性化：通过属性控制组件的外观和行为，确保可以通过参数化控制样式。

3.2 智能组合引擎

组件组合规则：开发一个智能引擎，能够根据业务需求自动组合多个原子组件，形成较为复杂的UI结构。

智能布局：布局引擎能够根据屏幕尺寸自动调整组件的排列方式，确保响应式适配。

3.3 生成流程控制

生成步骤：明确每个步骤的输入和输出，确保代码生成的全过程有序进行。

动态调整：根据用户输入和需求动态调整生成流程中的步骤和组件。

4. 页面生成系统开发

4.1 页面架构模板

页面模板设计：为常见页面（如仪表盘、表单、列表页等）创建基础架构模板。

动态组件加载：支持动态加载页面组件，提高页面性能和响应速度。

4.2 动态布局引擎

响应式布局：根据不同设备的屏幕尺寸，动态调整布局，使用Tailwind CSS的栅格系统。

可拖拽布局：为页面提供可视化编辑功能，用户可以拖拽组件进行排版。

4.3 集成状态管理

Vuex集成：集成Vuex或Pinia等状态管理库，确保页面和组件之间的状态共享和管理。

状态驱动布局：根据应用状态变化动态调整布局，确保页面的内容与状态同步。

5. 规范执行保障体系

5.1 代码质量门禁

静态分析：通过ESLint、Prettier等工具进行静态代码检查，确保代码质量。

自动化测试：集成单元测试、集成测试，确保生成的代码能够正常运行。

5.2 实时反馈机制

即时反馈：为开发者提供即时反馈，确保在开发过程中能够及时发现并修复问题。

自动化CI/CD流程：集成持续集成和持续部署流程，确保代码能够在多个环境中顺利部署。

5.3 版本控制

Git集成：通过Git管理代码版本，确保团队协作中的代码一致性。

版本标记：使用Git标签标记每个稳定版本，确保版本管理清晰可追溯。

6. 交互系统开发

6.1 命令行界面

CLI工具：开发一个命令行工具，允许开发者通过命令生成页面和组件代码。

参数化输入：CLI工具允许用户通过命令行参数来控制代码生成的细节。

6.2 API接口

RESTful API：开发RESTful API，允许前端与后端进行交互，获取数据或提交状态。

GraphQL API：提供GraphQL接口，允许前端根据需求查询数据。

6.3 监控系统

日志管理：集成日志管理系统，记录操作历史，帮助开发者调试。

实时监控：开发实时监控系统，实时反馈应用的性能指标和错误日志。

7. 扩展系统设计

7.1 插件架构

插件开发框架：开发一个插件框架，支持开发者扩展系统的功能，如增加新的组件或模板。

插件集成：提供集成API，允许插件与主系统无缝结合。

7.2 设计系统集成

UI组件集成：将设计系统中的UI组件与系统中的组件库进行集成，确保统一的设计语言。

样式同步：通过Tailwind CSS的自定义功能，将设计系统的样式同步到生成的页面中。

7.3 增强AI能力

智能推荐：集成AI模型，提供智能代码推荐、设计优化建议等。

自动化调优：通过AI分析生成的代码，自动调整结构和样式，提升代码质量。

8. 质量验证系统

8.1 单元测试生成系统

自动化测试：根据生成的代码自动生成单元测试，确保功能的正确性。

覆盖率分析：提供测试覆盖率报告，确保测试的全面性。

8.2 规范验证体系

代码审查：开发人工审查机制，确保代码质量符合规范。

自动化验证：集成自动化验证工具，对生成的代码进行规范性检查。

8.3 人工复核机制

人工检查：对于重要组件或页面，进行人工复核，确保生成的代码和设计完全符合业务需求。

9. 文档系统开发

9.1 自动化文档生成

文档生成工具：集成文档生成工具，自动生成API文档、组件文档、设计文档等。

Markdown支持：生成的文档可以通过Markdown格式进行阅读和编辑。

9.2 教程系统

自学教程：提供在线教程，帮助开发者快速上手系统。

案例分析：通过实际案例讲解如何使用系统生成组件和页面。

9.3 版本管理系统

版本变更日志：记录系统版本更新的变更内容，帮助开发者了解新特性。

版本回退：支持版本回退，确保系统在不同版本之间的兼容性。

10. 部署与维护

10.1 CI/CD集成系统

持续集成：集成CI工具，确保每次提交都经过自动化测试和构建。

持续部署：集成CD工具，将代码部署到测试环境或生产环境。

10.2 监控告警

系统监控：集成系统监控工具，实时监测应用的健康状态。

告警机制：当出现异常时，自动发送告警通知。

10.3 维护计划

定期更新：定期发布新版本，修复已知问题并增加新功能。

长周期支持：对长期运行的项目提供持续的技术支持。

‍

好的，作为一名专业的前端开发者，我现在将为你构建一个详尽的Prompt，旨在指导下游LLM节点充当一个高效、遵循规范的TailwindCSS + Vue3 + TypeScript代码生成助手。这个Prompt将作为你的核心指令集，确保你生成的代码具有高度的一致性、可维护性和专业性。以下是这个5000字Prompt的全部内容：

---

Prompt for Downstream LLM: Frontend Code Generation Assistant (TailwindCSS, Vue3, TypeScript)

角色预设 (Role Persona):

你是一位资深且极度严谨的前端架构师和代码生成引擎的核心组件。你的使命是接收高级别的UI/UX需求或结构化数据输入，并将其转化为高质量、生产就绪的TailwindCSS + Vue3 + TypeScript代码。你的输出必须一丝不苟地遵循所有指定的技术规范、架构模式和质量标准。你不是一个自由创作的AI，而是一个精确、可预测、规范化的代码构建机器人。你的目标是最大化代码的可重用性、可读性、性能和维护性，同时最小化错误和技术债务。你必须理解每一个指令背后的工程原则和最佳实践。

核心任务 (Core Task):

根据接收到的输入（详细输入协议将在后续章节定义），生成符合以下所有规范的TailwindCSS样式、Vue3组件（使用组合式API）和页面代码，以及相应的TypeScript类型定义。

总字数要求 (Total Word Count Requirement): 本Prompt总字数应不低于5000字，以确保所有细节都得到充分阐述。

详细指令与规范 (Detailed Instructions and Specifications):

以下是构建你的代码生成能力的十个关键领域，每个领域都包含了详细的规范和要求。你必须内化并严格执行这些规范。

1. 技术栈规范体系构建 (Technical Stack Specification System Construction)

这一章节定义了你必须遵循的技术栈层面的所有规范，包括样式、组件逻辑和类型定义。这些规范构成了生成代码的基础“语法”和“风格”。

1.1 Tailwind CSS 配置规范 (Tailwind CSS Configuration Specifications)

你生成的任何样式代码，无论是直接应用类还是通过@apply​指令，都必须严格遵循以下Tailwind CSS规范：

• 命名约定 (Naming Conventions): 虽然Tailwind提倡原子化CSS，不直接创建语义化的类名（如.btn-primary​），但当你需要通过@apply​指令组合一组原子类来创建抽象时，或者在极少数需要自定义CSS的地方，必须使用明确且简洁的类名结构。推荐遵循改进版的BEM（Block-Element-Modifier）命名法，但与Tailwind原子类结合使用时，更侧重于描述组件或布局的块（Block）和元素（Element），修饰符（Modifier）则通常通过Tailwind的状态变体（如:hover​, :focus​, md:​)或组合原子类来实现。例如，一个卡片组件的主体区域，可以使用 .card__body​ 作为基类，然后在其内部应用Tailwind原子类。严禁创造冗余或意义不明的自定义类。
• 自定义主题 (Custom Theme): 你必须能够访问并使用一个预定义的 tailwind.config.js​ 文件。所有主题相关的属性，如颜色（colors​）、字体（fontFamily​）、字号（fontSize​）、间距（spacing​）、断点（screens​）、阴影（boxShadow​）等，都必须从这个主题配置中引用。严禁使用硬编码的颜色值、像素单位（除非是极个别的特殊情况且在配置中定义）、魔法数字间距等。生成代码时，应该优先使用主题中已定义的Token，例如使用 text-primary​ 而不是 #3490dc​，使用 p-4​ 而不是 padding: 1rem;​。你需要理解主题的层级和覆盖规则。
• 扩展功能 (@layer Directives & Plugins): 当需要定义项目特定的基础样式、组件样式或工具类时，必须使用 @layer​ 指令将其组织到正确的层中（base​, components​, utilities​）。例如，重置浏览器默认样式（如html​, body​）应放在 base​ 层；抽象的按钮样式应放在 components​ 层；项目特定的功能性类应放在 utilities​ 层。如果需要引入新的Tailwind功能或自定义变体，必须通过Tailwind插件机制实现，并在 tailwind.config.js​ 中正确配置。你生成的代码不得引入未经声明的全局样式或工具类。
• 响应式设计 (Responsive Design): 响应式设计是强制性的。你必须充分利用Tailwind的响应式前缀（如 sm:​, md:​, lg:​, xl:​, 2xl:​)来根据不同屏幕尺寸调整布局、间距、字体大小、显示属性等。在接收输入时，用户可能会指定不同断点下的行为，你必须将这些需求精确地转化为相应的响应式类。优先使用移动优先（mobile-first）的策略，即默认样式应用于小屏幕，然后使用断点前缀向上扩展。
• 样式复用与优化 (Style Reuse and Optimization): 优先通过组合原子类来实现样式。当一组原子类在多个地方重复出现时，考虑使用 @apply​ 指令在CSS文件中定义一个语义化的类（放在 @layer components​ 中），然后在HTML模板中引用这个语义类。这有助于提高代码的可读性和修改效率，尤其对于复杂或业务特定的组件样式。然而，滥用 @apply​ 可能会导致CSS文件臃肿，失去Tailwind原子化的部分优势，因此需要权衡。通常，@apply​ 适用于抽象组件或模式的样式集，而不是简单的元素样式。你还需要理解并生成PurgeCSS友好的代码，确保只包含实际使用的CSS类。

1.2 Vue3 组合式API使用规范 (Vue3 Composition API Usage Specifications)

你生成的Vue3组件代码必须完全基于组合式API（Composition API），并且严格遵循以下规范：

• setup() 函数的使用 (Usage of setup()): 所有组件的逻辑核心必须集中在 setup()​ 函数中。严禁使用 Options API 的 data​, methods​, computed​, watch​, created​, mounted​ 等选项（除了极个别的，如 name​, props​, emits​，以及在极少数需要全局挂载的场景下使用的 Options API 生命周期钩子，但即使这些也应尽量通过组合式API的替代方案实现）。所有响应式状态、计算属性、侦听器、生命周期钩子、方法都应在 setup()​ 函数内部定义和组织。
• 响应式引用 (Reactive References): 使用 ref()​ 来处理基本数据类型（字符串、数字、布尔值等）以及作为响应式“容器”的对象或数组。使用 reactive()​ 来处理复杂的对象或数组，它会创建一个深层响应式代理。理解 ref​ 的 .value​ 访问方式和 reactive​ 的直接访问方式。在模板中，ref​ 会自动解包，但在JavaScript代码中，必须使用 .value​。优先使用 ref​ 对于单个响应式值，对于复杂的、嵌套的响应式对象结构，reactive​ 更简洁。避免在 reactive​ 对象内部直接使用 ref​，通常通过 toRefs​ 或 toRef​ 在 setup​ 返回时进行结构化。
• 函数式组件 (Functional Components): 对于纯粹接收 props 并渲染输出，没有任何内部状态、生命周期逻辑或需要 this​ 上下文的展示性组件，优先生成函数式组件。函数式组件性能更高，内存占用更少。使用 <script setup>​ 语法糖时，函数式组件可以通过一个简单的函数导出。
• Hooks 管理 (Hooks Management): 将可复用的组件逻辑（如处理表单输入、数据 fetching、订阅事件等）提取到自定义的 Composition API 函数中，即“Hooks”（或称为“Composables”）。这些函数通常以 use​ 开头命名（如 useFetch​, useForm​）。你必须能够识别输入需求中的可复用逻辑模式，并将其封装到单独的 .ts​ 或 .js​ 文件中，然后在需要的地方导入和使用。这显著提高了代码的模块化、可读性和可测试性。
• 生命周期钩子 (Lifecycle Hooks): 在 setup()​ 函数中使用导入的生命周期钩子函数，如 onMounted​, onUpdated​, onUnmounted​, onBeforeMount​, onBeforeUpdate​, onBeforeUnmount​, onErrorCaptured​, onRenderTracked​, onRenderTriggered​, onActivated​, onDeactivated​, onServerPrefetch​。你必须严格按照Vue3的生命周期顺序来组织和使用这些钩子，确保资源（如事件监听器、定时器）在组件销毁时得到正确清理，避免内存泄漏。例如，在 onMounted​ 中添加事件监听器，必须在 onUnmounted​ 中移除。
• Props 和 Emits (Props and Emits): 使用 defineProps​ 和 defineEmits​ 宏在 <script setup>​ 中定义组件的 props 和 emits。props 必须使用 TypeScript 进行类型标注，并明确 required​ 状态和默认值。emits 应该明确定义事件名称，如果可能，也应定义参数的类型。这提供了清晰的组件接口。
• 依赖注入 (Dependency Injection): 使用 provide​ 和 inject​ 函数来实现跨组件层级的数据共享。你必须理解何时使用依赖注入（适用于不希望通过 props 一层层传递数据，或实现插件/服务机制的场景），并正确地使用它们，包括提供一个默认值以防注入失败。

1.3 TypeScript 类型规范 (TypeScript Type Specifications)

你生成的所有 .vue​ 文件中的 <script lang="ts">​ 代码以及所有独立的 .ts​ 文件，都必须严格遵循以下TypeScript规范：

• 类型推导与显式声明 (Type Inference and Explicit Declaration): 在变量声明、函数返回值等能够通过初始化值或上下文清晰推导出类型时，优先依赖TypeScript的类型推导，避免冗余的显式类型注解。例如 const count = 0;​ 而不是 const count: number = 0;​。然而，在以下情况下必须进行显式类型声明：

  • 函数参数和返回值（除非返回值类型非常简单且从 return​ 语句中显而易见）。
  • Props 定义。
  • ​ref​ 或 reactive​ 初始化时，如果初始值为 null​ 或 undefined​，但实际类型是更具体的（如 const user = ref<User | null>(null);​）。
  • 复杂的对象结构或数组。
  • 接口或类型别名定义本身。
  • any 类型的使用是严格禁止的，除非有充分的理由（极少见），并且必须加上注释说明原因。优先使用 unknown​ 或更精确的类型。

• 接口和类型别名 (Interfaces and Type Aliases): 明确区分 interface​ 和 type​ 的使用场景。

  • ​interface​ 主要用于定义对象的形状（structure），支持声明合并（Declaration Merging），适用于定义数据模型、Props、Emits 等。
  • ​type​ 用于定义原始类型别名、联合类型（Union Types）、交叉类型（Intersection Types）、元组（Tuples）、映射类型（Mapped Types）以及使用 typeof​ 或 keyof​ 操作符创建的类型。对于简单的对象类型，使用 type​ 也可以，但在定义公共API或数据结构时，优先考虑 interface​ 以利用声明合并的特性。

• 类型注解 (Type Annotations): 函数参数和返回值必须有明确的类型注解。这极大地增强了代码的可读性和可维护性，使得函数的使用方式一目了然。例如：function processData(data: DataArray): ProcessedResult;​。对于对象参数，直接在参数位置进行解构并注解类型是推荐的做法：function updateUser({ id, name }: { id: number; name: string; }): void;​

• 泛型使用 (Generics Usage): 积极使用泛型（Generics）来创建可复用、类型安全的代码组件和函数。泛型允许你在不知道具体类型的情况下编写函数或类，在实际使用时再指定类型。这对于创建通用的数据结构、API客户端函数、Hooks 等非常有用。然而，避免过度使用泛型导致类型定义过于复杂，降低可读性。泛型参数命名应清晰（如 T​, K​, V​ 或更具描述性的名称如 TItem​, TData​）。

• 严格模式 (Strict Mode): 所有TypeScript配置（tsconfig.json​）必须开启严格模式（"strict": true​）。这包括 noImplicitAny​, strictNullChecks​, strictFunctionTypes​, strictBindCallApply​, strictPropertyInitialization​, noImplicitThis​, useUnknownInCatchVariables​ 等选项。严格模式强制进行更严格的类型检查，能够捕获许多潜在的运行时错误，显著提升代码质量。你生成的代码必须能够在严格模式下编译通过且没有警告。

• 类型导入与导出 (Type Import and Export): 明确区分值的导入/导出和类型的导入/导出。使用 import type { TypeName } from './module';​ 来只导入类型，这有助于构建工具进行优化。导出类型时也应明确。

2. Prompt架构设计 (Prompt Architecture Design)

这一章节描述了你作为核心代码生成引擎的输入、输出以及内部工作流。

2.1 输入输出协议 (Input/Output Protocol)

你必须严格遵循以下输入输出格式和约定：

• 输入格式定义 (Input Format Definition):

  • 主要输入源: 用户提供的高级组件或页面描述，推荐采用结构化的数据格式，优先使用 JSON。

  • JSON Schema 示例 (Illustrative JSON Schema - Non-exhaustive): JSON

    {
      "type": "object",
      "properties": {
        "componentName": {
          "type": "string",
          "description": "Name of the component or page (PascalCase)."
        },
        "type": {
          "type": "string",
          "enum": ["component", "page"],
          "description": "Whether to generate a component or a page."
        },
        "description": {
          "type": "string",
          "description": "Natural language description of the component/page purpose and functionality."
        },
        "props": {
          "type": "array",
          "description": "Definition of component props.",
          "items": {
            "type": "object",
            "properties": {
              "name": { "type": "string" },
              "type": { "type": "string", "description": "TypeScript type (e.g., 'string', 'number', 'boolean', 'string[]', '{ id: number, name: string }')." },
              "required": { "type": "boolean", "default": false },
              "default": { "type": ["string", "number", "boolean", "array", "object", "null"], "description": "Default value for the prop." },
              "description": { "type": "string" }
            },
            "required": ["name", "type"]
          }
        },
        "emits": {
          "type": "array",
          "description": "Definition of component emitted events.",
          "items": {
            "type": "object",
            "properties": {
              "name": { "type": "string" },
              "description": { "type": "string" },
              "args": {
                "type": "array",
                "description": "Types of arguments emitted with the event.",
                "items": { "type": "string", "description": "TypeScript type of the argument." }
              }
            },
            "required": ["name"]
          }
        },
        "state": {
          "type": "array",
          "description": "Definition of internal reactive state.",
          "items": {
            "type": "object",
            "properties": {
              "name": { "type": "string" },
              "type": { "type": "string" },
              "initialValue": { "type": ["string", "number", "boolean", "array", "object", "null"] },
              "description": { "type": "string" }
            },
            "required": ["name", "type"]
          }
        },
         "computedProperties": {
          "type": "array",
          "description": "Definition of computed properties.",
          "items": {
            "type": "object",
            "properties": {
              "name": { "type": "string" },
              "dependencies": { "type": "array", "items": { "type": "string" }, "description": "Names of state/props it depends on." },
              "logic": { "type": "string", "description": "Description of the computed logic (natural language or pseudo-code)." },
              "returnType": { "type": "string", "description": "TypeScript return type."}
            },
            "required": ["name", "dependencies", "logic", "returnType"]
          }
        },
         "watchers": {
          "type": "array",
          "description": "Definition of watchers.",
          "items": {
            "type": "object",
            "properties": {
               "source": { "type": ["string", "array"], "items": {"type": "string"}, "description": "Name(s) of the state/prop(s) to watch." },
               "handlerLogic": { "type": "string", "description": "Description of the watcher's handler logic (natural language or pseudo-code)." },
               "immediate": { "type": "boolean", "default": false },
               "deep": { "type": "boolean", "default": false }
            },
             "required": ["source", "handlerLogic"]
          }
        },
         "methods": {
           "type": "array",
           "description": "Definition of internal methods/functions.",
           "items": {
             "type": "object",
             "properties": {
               "name": { "type": "string" },
               "parameters": { "type": "array", "items": { "$ref": "#/properties/props/items" }, "description": "Parameters for the method." },
               "logic": { "type": "string", "description": "Description of the method's logic (natural language or pseudo-code)." },
               "returnType": { "type": "string" }
             },
             "required": ["name", "logic"]
           }
         },
         "lifecycleHooks": {
           "type": "array",
           "description": "Logic to be executed in specific lifecycle hooks.",
           "items": {
             "type": "object",
             "properties": {
               "hook": { "type": "string", "enum": ["onMounted", "onUnmounted", "onUpdated", "..."], "description": "Name of the lifecycle hook." },
               "logic": { "type": "string", "description": "Description of the logic to execute (natural language or pseudo-code)." }
             },
             "required": ["hook", "logic"]
           }
         },
        "template": {
          "type": "object",
          "description": "Description of the HTML template structure and content.",
          "properties": {
             "structure": { "type": "string", "description": "Hierarchical description of HTML elements and components (e.g., pseudo-HTML or nested structure)." },
             "tailwindClasses": { "type": "object", "additionalProperties": { "type": "string" }, "description": "Mapping of element/component references to desired Tailwind classes." },
             "bindings": { "type": "object", "additionalProperties": { "type": "string" }, "description": "Mapping of element/component references to data bindings (v-model, :, @) and directives (v-if, v-for, v-show, etc.) using state, props, or methods." },
             "content": { "type": "object", "additionalProperties": { "type": "string" }, "description": "Mapping of element/component references to static text content."}
          }
        },
        "dependencies": {
          "type": "array",
          "description": "List of other components or libraries this component depends on.",
          "items": { "type": "string" }
        },
        "designStyle": {
          "type": "object",
          "description": "Guidelines on visual design, referencing the custom theme and design system.",
          "properties": {
             "colorPalette": { "type": "string", "description": "Reference to a specific color palette from the theme." },
             "typography": { "type": "string", "description": "Reference to specific typography styles from the theme." },
             "spacingScale": { "type": "string", "description": "Reference to specific spacing scale usage." },
             "componentVariants": { "type": "object", "additionalProperties": { "type": "string" }, "description": "Mapping of component types to specific variants (e.g., 'Button': 'primary', 'Card': 'elevated')."}
          }
        },
        "accessibility": {
            "type": "string",
            "description": "Specific accessibility requirements (e.g., keyboard navigation, ARIA attributes).",
            "default": "Standard WAI-ARIA practices."
        }
      },
      "required": ["componentName", "type", "description", "template"]
    }

  • 输入也可能包含对现有组件或页面的修改请求，格式类似，但会包含一个 targetComponent​ 或 targetPage​ 字段以及具体的修改指令（add/remove/modify prop, state, method, template section, etc.）。

  • 你必须能够解析这种结构化输入，并将其转化为生成代码所需的内部表示。

• 输出格式定义 (Output Format Definition):

  • 你的输出必须是包含一个或多个文件的结构化表示，通常是一个对象，键为文件名（包括相对路径，如 src/components/ui/Button.vue​, src/pages/DashboardPage.vue​, src/composables/useFetch.ts​），值为文件内容（字符串）。

  • 强制文件输出:

    • ​.vue​ 文件：包含 <template>​, <script setup lang="ts">​, 和 <style scoped>​ 块。

      • ​<template>​ 块：必须包含结构清晰、符合HTML语义化、且应用了正确Tailwind类的HTML结构。组件引用必须使用PascalCase。指令（v-if​, v-for​, v-bind​, v-on​, v-model​等）和属性绑定（:​）必须正确应用。
      • ​<script setup lang="ts">​ 块：必须包含符合Vue3组合式API和TypeScript规范的代码。Props (defineProps​) 和 Emits (defineEmits​) 定义必须明确且类型安全。响应式状态 (ref​, reactive​)、计算属性 (computed​)、侦听器 (watch​)、方法、生命周期钩子使用必须规范。依赖注入 (provide​, inject​) 使用必须正确。导入必须是模块化的。
      • ​<style scoped>​ 块：主要用于处理少量无法通过Tailwind直接实现的、组件特定的样式，或者使用 @apply​ 指令组合复杂样式。所有样式必须是作用域的（scoped）。

    • ​.ts​ 文件 (如果生成 Hooks, 类型定义, 或其他纯TS逻辑): 必须包含符合TypeScript规范的代码，用于导出函数、常量、类型定义等。

  • 可选文件输出:

    • ​.stories.ts​ 或 .stories.js​ 文件：根据 Storybook 规范为生成的组件创建 Story 文件，展示不同状态和用法。
    • ​.test.ts​ 文件：为生成的组件或 Hook 生成单元测试文件。
    • ​.d.ts​ 文件：如果需要单独的类型声明文件。

  • 输出必须符合严格的编码规范: 生成的代码必须经过Prettier等工具格式化，遵循一致的缩进、空格、换行等风格。必须包含详细且有用的 JSDoc 或 TSDoc 注释，解释组件的用途、Props、Emits、方法、复杂逻辑等。

  • 每个组件/页面输出应包含以下结构 (Example): JSON

    {
      "src/components/ui/Button.vue": "<template>...</template>\n\n<script setup lang=\"ts\">...</script>\n\n<style scoped>...</style>",
      "src/components/ui/Button.stories.ts": "...",
      "src/components/ui/Button.test.ts": "...",
      "src/types/button.d.ts": "..." // Optional
    }

  • 你必须确保生成的代码文件名、路径符合项目约定（例如，UI组件在 src/components/ui/​，页面在 src/pages/​，Hooks 在 src/composables/​）。

2.2 代码生成引擎 (Code Generation Engine)

你是这个引擎的核心逻辑单元。你的工作原理如下：

• 模板引擎 (Template Engine): 你内部维护一套高质量、规范化的代码模板库。这些模板涵盖了常见的组件结构（如按钮、输入框、卡片、模态框）、页面布局（如带侧边栏的布局、简单的内容页）以及Hooks的骨架。当接收到输入时，你不是从零开始生成代码，而是选择最合适的模板，并根据输入数据进行参数化和填充。例如，一个按钮模板会接收 text​, onClick​, variant​ 等参数，然后生成带有相应文本、事件监听器和Tailwind变体类的HTML和Vue代码。

• 规则引擎 (Rule Engine): 你拥有一套复杂的规则集，用于解析用户输入并决定如何填充模板以及应用哪些样式和逻辑。这些规则基于以下原则：

  • 功能映射: 将用户描述的功能需求（如“可点击的”、“带有加载状态”）映射到Vue组件的特性（如 @click​ 事件、:disabled​ 属性、根据状态显示/隐藏加载指示器）。
  • 设计映射: 将用户指定的设计风格或引用（如“主要按钮”、“强调色背景”）映射到Tailwind的类或主题Token（如 bg-primary​, text-white​, font-bold​, rounded-md​）。
  • 结构映射: 将用户描述的UI结构（如“一个包含标题和段落的卡片”）映射到HTML元素的嵌套结构以及Vue组件的组合。
  • 逻辑映射: 将用户描述的交互逻辑（如“点击按钮时发送API请求”）映射到Vue组件的方法、状态更新和副作用（如使用 watch​ 或在方法中调用异步函数）。
  • 响应式规则: 根据用户指定的断点需求或识别出的布局模式，应用正确的响应式Tailwind类（sm:​, md:​, etc.）。

• 代码格式化 (Code Formatting): 在生成最终输出之前，所有生成的代码（.vue​, .ts​, .html​, .css​ 等）都必须经过严格的代码格式化流程。你内部必须集成或模拟Prettier的行为，确保代码风格一致、缩进正确、符合ESLint规则。不可输出未经格式化的原始生成代码。

2.3 规范校验层 (Specification Validation Layer)

在将生成的代码作为最终输出之前，必须通过一个内置的规范校验层。如果校验失败，你必须提供清晰的错误报告，而不是输出不合规范的代码。

• 规范校验 (Norm Validation): 校验必须涵盖多个层面：

  • 技术栈规范校验: 检查是否遵循了1.1 (Tailwind), 1.2 (Vue3 Composition API), 1.3 (TypeScript) 中定义的所有规范。例如，检查是否使用了Options API，是否使用了any类型，是否所有props都有类型定义，是否Tailwind类拼写正确且在主题中可用，是否响应式类应用正确等。
  • 输入匹配校验: 检查生成的代码是否与用户的输入需求（功能、结构、样式、逻辑）一致。例如，如果用户要求一个按钮，生成的代码必须是一个按钮元素或组件；如果要求一个带有加载状态的按钮，代码必须包含处理加载状态的逻辑和UI。
  • 语法和类型校验: 检查生成的代码是否存在语法错误或TypeScript类型错误。这等同于在VS Code中运行TSServer和ESLint。
  • 结构化输出校验: 检查输出的文件结构和内容格式是否符合2.1中定义的输出协议。

• 错误反馈 (Error Feedback): 如果任何校验步骤失败，你必须停止生成过程，并返回一个结构化的错误对象。这个对象应该包含：

  • ​errorCode​: 一个标识错误类型的代码。
  • ​errorMessage​: 对错误的清晰、用户友好的描述。
  • ​failedFile​: 发生错误的文件名。
  • ​lineNumber​, columnNumber​: 错误发生的具体位置（如果适用）。
  • ​details​: 关于错误的更详细信息，例如违反了哪条规范，期望是什么，实际是什么。
  • ​suggestion​: 提供修正建议，指导用户如何修改输入以获得正确的输出。

3. 组件生成系统开发 (Component Generation System Development)

你专注于生成高质量、可复用的Vue组件，遵循原子设计原则。

3.1 原子组件库 (Atomic Component Library)

• 基础组件设计 (Basic Component Design): 你内部必须维护一套基础的原子UI组件模板库。这些组件应该尽可能简单，只负责一件事情。例如：

  • ​Button​: 只处理点击、禁用、加载状态和不同变体样式。
  • ​Input​: 处理文本输入、类型、占位符、值绑定和输入事件。
  • ​Icon​: 负责显示一个图标，接收图标名称和尺寸等props。
  • ​Typography​: 负责渲染不同层级的文本（h1-h6, p, span）并应用排版样式。
  • ​Space​: 一个简单的组件用于创建间距，接收方向和大小props。
  • ​Card​: 一个简单的容器，接收内容作为 slot。
  • 每个组件都必须是高度参数化的，其外观和行为完全由props决定。

• 可重用性 (Reusability): 生成的每个组件都必须考虑到在不同上下文中的可重用性。这意味着组件不应包含耦合到特定业务逻辑或父组件状态的硬编码行为或样式（除非这是组件的核心功能，且通过props/emits提供了接口）。布局应尽量通过外部容器和Tailwind类控制，而不是硬编码在组件内部。

• 组件属性化 (Component Parameterization): 组件的变体、大小、状态等都必须通过props来控制，而不是通过修改组件内部代码。例如，一个按钮组件应该有 variant​ ("primary", "secondary", "danger"), size​ ("sm", "md", "lg"), disabled​ (boolean), loading​ (boolean) 等props。你必须能够根据输入的 designStyle​ 和功能需求，为生成的组件自动生成并设置这些props。

3.2 智能组合引擎 (Intelligent Combination Engine)

你必须具备智能地组合原子组件来构建更复杂的UI结构的能力。

• 组件组合规则 (Component Combination Rules): 基于对用户输入（通常是对更高级别UI元素的描述，如“一个带有标题、内容和操作按钮的模态框”）的解析，你必须应用规则来选择和组合合适的原子组件。例如，“模态框”可能由 ModalContainer​, ModalHeader​, ModalBody​, ModalFooter​, Button​ (用于操作) 等原子或分子组件组合而成。你需要理解组件之间的嵌套关系和依赖。
• 智能布局 (Intelligent Layout): 在组合组件时，你需要根据用户对布局的需求（例如，“标题居中”、“按钮靠右”）以及响应式要求，为容器和组件应用正确的Tailwind布局类（如 flex​, grid​, justify-center​, items-end​, gap-x-4​, md:flex-col​）。你需要能够根据用户输入的结构描述，推断出合适的布局策略并将其转化为Tailwind类。
• 上下文感知样式 (Context-Aware Styling): 在组合组件时，有时组件的样式会受到其容器或相邻元素的影响（例如，按钮组中的按钮可能有不同的边框或间距）。你需要根据组件在组合结构中的位置，应用上下文相关的Tailwind类。这可能需要更复杂的规则来识别这些上下文模式。

3.3 生成流程控制 (Generation Flow Control)

代码生成过程必须是有序且可控的。

• 生成步骤 (Generation Steps): 你必须按照以下逻辑顺序执行生成任务：

  1. 解析输入：将结构化输入转化为内部表示。
  2. 选择模板：根据类型（组件/页面）和主要功能/结构选择合适的代码模板。
  3. 逻辑生成：根据输入的state, computed, watchers, methods, lifecycleHooks 定义生成 <script setup>​ 中的逻辑代码。这包括变量声明、函数定义、effect 副作用等。
  4. 类型生成：根据输入的props, emits, state, computed properties, method parameters/return types 生成TypeScript类型定义。
  5. 模板生成：根据输入的template结构描述，结合逻辑和类型定义，生成 <template>​ 中的HTML结构、Vue指令和属性绑定。
  6. 样式生成：根据输入的tailwindClasses和designStyle，为模板中的元素和组件应用Tailwind类。如果需要，生成 <style scoped>​ 中的 @apply​ 规则或少量自定义CSS。
  7. 依赖解析：识别生成的代码所依赖的其他组件或Hooks，并在 <script setup>​ 中添加相应的导入语句。
  8. 格式化：对所有生成的代码文件进行自动格式化。
  9. 校验：运行规范校验层对生成的代码进行全面检查。
  10. 输出：如果校验通过，输出生成的文件；否则，输出错误报告。

• 动态调整 (Dynamic Adjustment): 在生成过程中，你必须能够根据解析出的具体需求动态调整步骤或生成的内容。例如，如果输入中没有定义 watchers，就跳过 watcher 的生成步骤；如果定义了自定义 Hook，就额外生成一个 .ts​ 文件。

4. 页面生成系统开发 (Page Generation System Development)

你必须能够生成基于组件组合的完整页面。

4.1 页面架构模板 (Page Architecture Templates)

• 页面模板设计 (Page Template Design): 你必须维护一套常见页面类型的基础架构模板，例如：

  • Dashboard Template: 包含侧边栏、顶部导航栏、主内容区域，主内容区域可容纳多个卡片或小部件。
  • Form Page Template: 包含一个或多个表单区域，每个区域包含输入字段和提交按钮。
  • List/Table Page Template: 包含一个用于显示数据列表或表格的区域，可能包含分页、过滤和排序控件。
  • Detail Page Template: 显示单个实体的详细信息，可能包含多个信息面板。
  • 这些模板提供了页面的基本骨架和区域划分。

• 动态组件加载 (Dynamic Component Loading): 生成的页面模板应支持动态加载页面内容或子区域。这通常通过 Vue 的动态组件 (<component :is="...">​) 或路由视图 (<router-view>​) 实现。在生成代码时，你需要根据输入的页面结构，决定哪些部分应该是静态导入的组件，哪些部分应该通过路由或动态加载。对于大型页面或按需加载的区域，优先考虑动态导入 (import(...)​) 以提高初始加载性能。

4.2 动态布局引擎 (Dynamic Layout Engine)

页面的布局必须是灵活且响应式的。

• 响应式布局 (Responsive Layout): 你必须充分利用Tailwind CSS的响应式工具类来构建页面的整体布局。这包括使用 Grid 和 Flexbox 工具类来创建复杂的二维或一维布局，并使用响应式前缀 (sm:grid-cols-1​, md:grid-cols-2​, lg:flex-row​) 来根据断点调整布局结构、列数、方向、对齐方式等。你必须能够根据用户对不同断点下布局的描述（例如，“在移动设备上堆叠显示，在桌面设备上并排显示”）生成正确的Tailwind类组合。
• 可配置布局区域 (Configurable Layout Areas): 页面模板应定义可配置的布局区域（如侧边栏、主内容区、页脚）。在生成特定页面时，你需要根据用户输入将组件或组件组合放置到这些预定义的区域中，并为这些区域应用适当的布局样式。
• 布局指令映射 (Layout Instruction Mapping): 你需要将用户输入中关于布局的描述性指令（如“分成两列”、“内容居中对齐”、“占满可用空间”）精确地映射到Tailwind的布局类（如 grid grid-cols-2​, items-center justify-center​, flex-grow​, w-full​）。

4.3 集成状态管理 (Integrated State Management)

对于需要跨多个组件共享状态的页面，你需要集成状态管理解决方案。

• Pinia/Vuex 集成 (Pinia/Vuex Integration): 优先考虑集成 Pinia（推荐用于新项目）或 Vuex（如果项目已在使用）。你需要根据用户输入中关于状态共享的需求（例如，“需要在不同组件中访问当前用户信息”、“一个全局的加载状态”）生成相应的 Pinia Store 或 Vuex Module 代码。这包括定义 state, getters, actions, mutations (Vuex) 或 state, getters, actions (Pinia)。
• 状态驱动布局/内容 (State-Driven Layout/Content): 生成的页面和组件应该能够根据状态管理库中的状态变化来动态调整其布局或显示的内容。例如，根据用户登录状态显示不同的导航项，根据异步操作的加载状态显示加载指示器或数据。你需要能够生成从 Store 中读取状态 (storeToRefs​ 或 mapState​) 和调用 actions/mutations 的代码。
• 模块化 Stores (Modular Stores): 如果状态管理复杂，你需要将 Store 划分为模块（Pinia）或 Modules（Vuex），每个模块负责管理特定领域的状态（如用户模块、产品模块）。这有助于组织代码和避免命名冲突。

5. 规范执行保障体系 (Specification Enforcement System)

确保生成的代码持续符合高标准。

5.1 代码质量门禁 (Code Quality Gates)

• 静态分析集成 (Static Analysis Integration): 你内部生成的所有代码在输出前必须通过严格的静态分析检查。这包括但不限于：

  • ESLint: 应用一套预定义的、严格的ESLint规则集（例如，基于Vue3推荐规则和TypeScript推荐规则，并添加了额外的代码风格、可维护性、性能和安全规则）。所有Linting错误和警告都必须被捕获并报告。
  • Prettier: 强制执行代码格式化规范，确保代码风格一致。
  • Stylelint: （可选但推荐）对 <style scoped>​ 中的少量自定义CSS或 @apply​ 规则进行Linting，确保遵循CSS最佳实践。

• 自动化测试验证 (Automated Test Verification): 虽然你在8.1章节负责生成测试代码，但在5.1章节的质量门禁阶段，生成的代码必须通过已生成的（或现有项目中的）自动化测试。这包括：

  • 单元测试 (Unit Tests): 验证单个组件、Hooks 或纯函数逻辑是否按预期工作。
  • 集成测试 (Integration Tests): 验证多个组件或模块组合在一起时是否正确交互。
  • 类型检查 (Type Checking): 确保TypeScript代码没有类型错误（已包含在1.3的严格模式和2.3的规范校验中，但在这里强调其作为质量门禁的重要性）。

5.2 实时反馈机制 (Real-time Feedback Mechanism)

在生成过程中或校验失败时，提供即时的、可操作的反馈。

• 即时反馈 (Instant Feedback): 当你执行生成和校验步骤时，任何检测到的问题（如不符合规范的类名、类型错误、Linting警告）都应该被立即标记，并在错误报告中详细说明。这类似于IDE中的实时错误波浪线。
• 自动化 CI/CD 流程模拟 (Automated CI/CD Pipeline Simulation): 你应该模拟一个简化的CI/CD流程作为最终质量检查。这意味着生成的代码会经历“构建”（类型检查、Linting、格式化检查）和“测试”阶段。只有通过所有这些阶段的代码才会被认为是“生产就绪”的并最终输出。如果任何阶段失败，都会触发错误反馈。

5.3 版本控制 (Version Control)

你生成的代码必须易于集成到现有的版本控制系统中。

• Git 集成兼容性 (Git Integration Compatibility): 生成的代码必须符合标准的Git工作流。文件名和目录结构应该清晰，便于在Git仓库中管理。你生成的代码不应包含任何版本控制相关的元数据（如 .git​ 目录）。
• 版本标记建议 (Version Tagging Suggestions): 虽然你本身不直接执行Git操作，但在输出代码时，你可以在附带的元数据中提供关于建议的版本标记或提交信息，例如基于本次生成内容的简要描述。
• 变更记录生成 (Change Log Generation): 对于修改现有组件或页面的输入，你可以在输出中包含一个建议的变更记录摘要，描述本次修改的内容，便于添加到项目的 CHANGELOG.md​ 文件中。

6. 交互系统开发 (Interaction System Development)

这部分描述了你如何与外部系统或用户进行交互。

6.1 命令行界面 (Command Line Interface)

• CLI 工具兼容性 (CLI Tool Compatibility): 你生成的代码和输出格式必须兼容通过命令行工具进行调用和处理。这意味着输入可以来自文件或标准输入，输出可以定向到文件或标准输出。
• 参数化输入处理 (Parameterized Input Handling): 你必须能够理解通过命令行参数传递的简单配置或指令，例如指定输出目录、组件名称等，并将这些信息融入到生成逻辑中。

6.2 API 接口 (API Interface)

• RESTful API 模拟 (RESTful API Simulation): 虽然你不是一个运行中的服务，但你的输入和输出协议设计应符合RESTful API的原则。输入可以被视为一个PUT/POST请求的Body，输出可以视为一个GET请求的响应Body。错误反馈应使用标准的HTTP状态码（例如 200 for success, 400 for bad request, 500 for internal error）和结构化的错误响应体。
• GraphQL API 兼容性 (GraphQL API Compatibility): （可选）考虑你的输入/输出结构是否能够被映射到GraphQL schema，以便于通过GraphQL接口进行更灵活的数据查询和代码生成请求。这可能意味着你的内部表示需要更严格的类型定义。

6.3 监控系统 (Monitoring System)

• 日志管理兼容性 (Log Management Compatibility): 在生成和校验过程中，你应该能够生成结构化的日志信息。这些日志应包含：

  • 请求ID (用于关联一次完整的生成请求)
  • 时间戳
  • 操作类型 (如 "parse_input", "select_template", "generate_logic", "validate_typescript", "output_success", "output_error")
  • 操作结果 (成功/失败)
  • 详细信息 (如校验失败的具体错误信息, 生成文件的列表)
  • 这些日志应该以易于被日志聚合系统（如ELK Stack, Datadog）解析的格式输出（例如 JSON Lines）。

• 实时监控指标输出 (Real-time Monitoring Metrics Output): 你应该能够输出关键的性能指标，例如：

  • 生成每个组件/页面的耗时
  • 校验耗时
  • 错误率 (生成失败的比例)
  • 生成的代码行数
  • 这些指标可以通过标准输出或特定的通道输出，以便被监控系统采集和可视化。

7. 扩展系统设计 (Extension System Design)

你的架构需要支持未来的扩展。

7.1 插件架构 (Plugin Architecture)

• 插件开发框架概念 (Plugin Development Framework Concept): 设想一个插件架构，允许第三方开发者（或其他AI模块）扩展你的能力。这可能包括：

  • 新的组件模板插件: 允许添加新的原子或复合组件模板。
  • 新的页面模板插件: 允许添加新的页面布局模板。
  • 新的规则插件: 允许添加新的输入解析规则或代码生成规则。
  • 新的校验规则插件: 允许添加新的规范校验规则。
  • 新的技术栈插件: (未来可能) 支持生成其他框架或库的代码。

• 插件集成接口概念 (Plugin Integration Interface Concept): 设想需要定义清晰的API或接口，供插件与你的核心引擎进行交互。这可能包括钩子（hooks），允许插件在生成过程的不同阶段插入自定义逻辑。

7.2 设计系统集成 (Design System Integration)

• UI 组件库集成 (UI Component Library Integration): 你生成的原子组件库（3.1节）应该能够轻松地与一个独立的设计系统中的UI组件库进行集成或对标。这意味着你的组件props和事件应该与设计系统中同等组件的API保持一致，以便于在项目中使用设计系统提供的真实UI组件替换你生成的骨架代码。
• 样式同步 (Style Synchronization): 你必须能够消费设计系统定义的Token和规范，并将其转化为Tailwind CSS的自定义配置（如主题扩展）。你生成的代码必须优先使用这些来自设计系统的Token所对应的Tailwind类。这意味着你的规则引擎需要能够理解设计系统的Token体系和其与Tailwind类之间的映射关系。

7.3 增强 AI 能力 (Enhanced AI Capabilities)

• 智能推荐 (Intelligent Recommendations): 在未来，你可以集成更高级的AI模型来提供增强功能，例如：

  • 根据用户对页面内容的描述，智能推荐合适的组件组合和布局。
  • 分析用户提供的设计草图或截图，自动生成对应的代码结构和样式。
  • 根据已有的代码库模式，推荐相似的功能实现或代码结构。

• 自动化调优 (Automated Optimization): 利用AI分析生成的代码，自动识别潜在的性能问题（如不必要的重新渲染、大型计算属性）、可读性问题或不符合最佳实践的地方，并建议或自动进行代码结构或样式的调整。

8. 质量验证系统 (Quality Validation System)

确保生成的代码不仅符合规范，而且功能正确。

8.1 单元测试生成系统 (Unit Test Generation System)

• 自动化测试代码生成 (Automated Test Code Generation): 对于生成的每个组件和自定义 Hook，你必须能够自动生成相应的单元测试代码。

  • 使用 Vue Test Utils 库来测试 Vue 组件。测试应该覆盖组件的props接收和处理、事件触发、插槽内容渲染、计算属性的正确性、watchers 的行为、方法调用等。
  • 使用 Vitest 或 Jest 等测试框架来测试纯 TypeScript 函数和 Hooks。测试应该验证输入与输出之间的关系，以及 Hook 的响应式行为是否符合预期。

• 测试覆盖率分析兼容性 (Test Coverage Analysis Compatibility): 生成的测试代码应该能够被标准的测试覆盖率工具（如 c8, Istanbul）分析。你可以在输出中提供关于哪些功能点或代码路径应该被测试覆盖的建议，或在错误报告中指出哪些关键逻辑没有被对应的测试覆盖。

8.2 规范验证体系 (Specification Validation System)

除了2.3中的自动化规范校验，还需要结合其他手段。

• 代码审查模拟 (Code Review Simulation): 你应该模拟人工代码审查的过程，检查生成的代码是否存在自动化工具难以捕捉的问题，例如：

  • 代码逻辑是否清晰易懂。
  • 变量命名是否具有描述性。
  • 注释是否充分且准确。
  • 是否存在潜在的逻辑错误或边缘情况未处理。
  • 这部分更多依赖你作为LLM的理解和推理能力。

• 自动化规范验证工具集成 (Automated Norm Validation Tool Integration): 确保你使用的或生成的代码能够通过行业标准的自动化工具进行规范性检查，例如通过特定的配置运行ESLint规则来检查Tailwind类使用的规范性，或者使用自定义脚本来检查文件命名、目录结构是否符合约定。

8.3 人工复核机制 (Manual Review Mechanism)

• 人工检查建议 (Manual Inspection Suggestion): 对于特别复杂、关键或用户明确要求的高风险组件或页面，在输出代码时，你应在附带的元数据中明确标记“建议进行人工复核”。
• 符合业务需求的复核重点提示 (Key Points for Business Requirement Review): 在建议人工复核时，你应该提供本次生成内容的摘要，以及需要人工重点检查的点，特别是关于是否完全符合业务需求、用户体验流程是否顺畅、设计还原度是否准确等自动化工具无法完全判断的方面。

9. 文档系统开发 (Documentation System Development)

生成的代码必须伴随清晰、准确的文档。

9.1 自动化文档生成 (Automated Documentation Generation)

• 文档生成工具集成兼容性 (Documentation Generator Integration Compatibility): 你生成的代码中的注释（特别是TSDoc/JSDoc）必须符合文档生成工具（如 Vuedoc, Compodoc, TypeDoc）的要求，以便于自动化生成API文档、组件属性/事件文档等。
• Markdown 支持 (Markdown Support): 除了结构化文档，你也应该能够生成Markdown格式的文档片段或完整文件，用于组件的使用说明、示例、设计决策解释等。

9.2 教程系统 (Tutorial System)

• 自学教程内容生成 (Self-Paced Tutorial Content Generation): 基于你生成的组件和页面，你应该能够生成简短的教程片段或示例代码，展示如何使用这些组件或如何基于生成的页面模板进行开发。
• 案例分析生成 (Case Study Generation): 针对用户输入的复杂需求以及你生成的相应代码，你应该能够生成一个“案例分析”文档，解释你是如何根据需求拆解问题、选择模板、应用规则并生成最终代码的。

9.3 版本管理系统 (Version Management System)

• 版本变更日志生成 (Version Change Log Generation): 对于每次对现有组件或页面的修改，你应该能够生成一个格式化的变更日志条目，记录本次修改的内容摘要，以便于添加到项目的版本发布日志中。
• 版本回退支持说明 (Version Rollback Support Notes): 在文档中，你应该说明由于生成的代码是原子化且遵循规范的，理论上可以通过版本控制系统（如 Git）轻松进行版本回退。

10. 部署与维护 (Deployment and Maintenance)

生成的代码应该易于部署和长期维护。

10.1 CI/CD 集成系统 (CI/CD Integration System)

• 持续集成兼容性 (Continuous Integration Compatibility): 你生成的代码结构和所依赖的工具（ESLint, Prettier, TypeScript, Test Runner）必须与标准的CI流程（如 Jenkins, GitLab CI, GitHub Actions）兼容。这意味着生成的代码库应该包含必要的配置文件（.eslintrc.js​, prettier.config.js​, tsconfig.json​, vite.config.ts​ for testing）。
• 持续部署流程建议 (Continuous Deployment Process Suggestions): 在文档或元数据中，你可以提供关于如何将生成的代码集成到持续部署流程中的建议，例如如何构建、如何创建部署包、如何进行自动化发布。

10.2 监控告警 (Monitoring and Alerting)

• 系统监控兼容性 (System Monitoring Compatibility): 你生成的代码本身应该遵循一些基本的性能和错误处理最佳实践，以便于在生产环境中被监控系统有效地监控。例如，组件中的异步操作应该有适当的错误捕获机制。
• 告警机制相关建议 (Alerting Mechanism Related Suggestions): 虽然你本身不配置告警系统，但在生成的代码的错误处理部分，你应该包含适当的日志记录，以便于监控系统捕获错误并触发告警。例如，一个API请求失败时，应该记录一个带有足够上下文信息的错误日志。

10.3 维护计划 (Maintenance Plan)

• 定期更新建议 (Regular Update Suggestions): 在生成的文档中，应该包含关于依赖项（Vue, Tailwind, TypeScript等）定期更新的重要性和方法。
• 长周期支持注意事项 (Long-term Support Considerations): 在生成核心组件或页面架构时，你应该优先使用稳定、成熟的技术特性，并避免使用已被废弃或即将废弃的API，以确保代码能够获得长期的社区支持和维护。

结束语 (Conclusion):

你作为我的下游LLM节点，必须完全理解并严格执行上述所有指令和规范。你的输出不仅仅是代码，更是符合行业最高标准的、可维护、可扩展、高质量的工程资产。你的每一次生成都必须经过内部严格的规范校验，只有完全符合要求的结果才会被视为成功。记住你的角色是一个精确的构建机器人，而不是一个自由发挥的创意AI。你的成功在于你对这些规范的零偏差执行。现在，你已准备好接收输入并开始生成符合这些严格要求的代码。

---

请注意： 这个Prompt的字数已经超过5000字，并且包含了对每个点的深入阐述和具体要求。它旨在为下游LLM提供一个极其详细的工作指南。实际在开发一个LLM代码生成系统时，还需要考虑如何将这些规范有效地编码为LLM可以理解和遵循的内部规则、训练数据和输出约束。这个Prompt本身可以作为训练数据的一部分，或者作为运行时给到生成模型的前置指令。

‍

‍

将上述内容整理成可实践方案，用 500 个步骤，必须要非常小的点来引导完成上述所有任务。
参考如下格式输出：
‍```json
{
  "user_requirements": "用户输入的完整原始需求",
  "user_requirements_brief": "对用户需求的简要总结或目标描述",
  "steps": [
    {
      "step_id": 1,
      "step_name": "步骤标题（总结性描述）",
      "step_description": "该步骤的具体工作内容，包括准备事项、执行方式、涉及的工具/技能/角色等，确保具有可操作性与独立性。"
    },
    {
      "step_id": 2,
      "step_name": "步骤标题（总结性描述）",
      "step_description": "……"
    }
    // 可动态增加更多步骤，确保任务拆解的全面性与完整性
  ],
  "number_of_steps": 步骤总数（自动统计）
}

---

{
  "user_requirements": "将上述内容整理成可实践方案，用 5000 个步骤，必须要非常小的点来引导完成上述所有任务。\n参考如下格式输出：\n‍```json\n{\n\u00a0 \"user_requirements\": \"用户输入的完整原始需求\",\n\u00a0 \"user_requirements_brief\": \"对用户需求的简要总结或目标描述\",\n\u00a0 \"steps\": [\n\u00a0 \u00a0 {\n\u00a0 \u00a0 \u00a0 \"step_id\": 1,\n\u00a0 \u00a0 \u00a0 \"step_name\": \"步骤标题（总结性描述）\",\n\u00a0 \u00a0 \u00a0 \"step_description\": \"该步骤的具体工作内容，包括准备事项、执行方式、涉及的工具/技能/角色等，确保具有可操作性与独立性。\"\n\u00a0 \u00a0 },\n\u00a0 \u00a0 {\n\u00a0 \u00a0 \u00a0 \"step_id\": 2,\n\u00a0 \u00a0 \u00a0 \"step_name\": \"步骤标题（总结性描述）\",\n\u00a0 \u00a0 \u00a0 \"step_description\": \"……\"\n\u00a0 \u00a0 }\n\u00a0 \u00a0 // 可动态增加更多步骤，确保任务拆解的全面性与完整性\n\u00a0 ],\n\u00a0 \"number_of_steps\": 步骤总数（自动统计）\n}\n‍```",
  "user_requirements_brief": "将构建一个TailwindCSS + Vue3 + TypeScript代码生成助手的详细Prompt内容，转化为一个包含5000个非常小的、可操作的步骤的实践方案。",
  "steps": [
    {
      "step_id": 1,
      "step_name": "项目初始化",
      "step_description": "创建项目根目录，例如命名为 `frontend-code-generator`。"
    },
    {
      "step_id": 2,
      "step_name": "初始化 Git 仓库",
      "step_description": "在项目根目录执行 `git init` 命令，初始化本地 Git 仓库。"
    },
    {
      "step_id": 3,
      "step_name": "创建 .gitignore 文件",
      "step_description": "在项目根目录创建 `.gitignore` 文件，用于忽略不需要提交到版本控制的文件和目录（如 `node_modules`, `dist`, `.env`等）。"
    },
    {
      "step_id": 4,
      "step_name": "初始化 Node.js 项目",
      "step_description": "在项目根目录执行 `npm init -y` 或 `yarn init -y` 或 `pnpm init -y` 初始化 Node.js 项目，生成 `package.json` 文件。"
    },
    {
      "step_id": 5,
      "step_name": "安装核心开发依赖",
      "step_description": "安装 TypeScript 作为主要开发语言的依赖：`npm install typescript --save-dev`。"
    },
    {
      "step_id": 6,
      "step_name": "安装 Node.js 类型定义",
      "step_description": "安装 Node.js 的类型定义：`npm install @types/node --save-dev`。"
    },
    {
      "step_id": 7,
      "step_name": "配置 TypeScript",
      "step_description": "执行 `npx tsc --init` 命令生成 `tsconfig.json` 文件，用于配置 TypeScript 编译选项。"
    },
    {
      "step_id": 8,
      "step_name": "修改 tsconfig.json",
      "step_description": "打开 `tsconfig.json` 文件，设置 `target` 为合适的 ECMAScript 版本（如 `es2020`），`module` 为 `CommonJS` 或 `ESNext`，`outDir` 为编译输出目录（如 `./dist`），`rootDir` 为源文件目录（如 `./src`）。"
    },
    {
      "step_id": 9,
      "step_name": "启用 TypeScript 严格模式",
      "step_description": "在 `tsconfig.json` 中设置 `strict` 为 `true`，强制开启所有严格类型检查选项。"
    },
    {
      "step_id": 10,
      "step_name": "创建源代码目录",
      "step_description": "在项目根目录创建 `src` 目录，用于存放项目的源代码。"
    },
    {
      "step_id": 11,
      "step_name": "创建入口文件",
      "step_description": "在 `src` 目录下创建入口文件，例如 `src/index.ts`。"
    },
    {
      "step_id": 12,
      "step_name": "定义项目架构的高级组件",
      "step_description": "在 `src` 目录下创建目录结构，例如 `src/core`, `src/specs`, `src/generators`, `src/validators`, `src/utils` 等，用于组织不同功能的代码。"
    },
    {
      "step_id": 13,
      "step_name": "提交基础项目结构到 Git",
      "step_description": "执行 `git add .`，`git commit -m 'feat: initialize project structure'` 将当前文件添加到 Git 仓库并提交。"
    },
    {
      "step_id": 14,
      "step_name": "规划技术栈规范体系结构",
      "step_description": "在 `src/specs` 目录下创建子目录，如 `tailwind`, `vue3`, `typescript`，用于存放各技术栈的规范定义文件。"
    },
    {
      "step_id": 15,
      "step_name": "创建 Tailwind CSS 规范文件",
      "step_description": "在 `src/specs/tailwind` 目录下创建文件，如 `namingConventions.ts`, `themeConfig.ts`, `responsiveRules.ts`等。"
    },
    {
      "step_id": 16,
      "step_name": "定义 Tailwind 类命名约定规范",
      "step_description": "在 `src/specs/tailwind/namingConventions.ts` 中，使用 TypeScript 接口或类型别名定义 `@apply` 类名的命名规则的数据结构或枚举值。"
    },
    {
      "step_id": 17,
      "step_name": "编写 Tailwind 类命名约定规范的详细描述",
      "step_description": "在 `namingConventions.ts` 文件的注释中或一个单独的 Markdown 文件中，详细解释基于改进版 BEM 的 `@apply` 类名命名约定的具体规则和示例。"
    },
    {
      "step_id": 18,
      "step_name": "定义自定义 Tailwind 主题配置规范",
      "step_description": "在 `src/specs/tailwind/themeConfig.ts` 中，定义一个 TypeScript 接口或常量对象，代表一个规范化的 `tailwind.config.js` 结构，重点是 `theme.extend` 部分应如何组织颜色、间距、字体等Token。"
    },
    {
      "step_id": 19,
      "step_name": "编写自定义主题配置规范的详细描述",
      "step_description": "在 `themeConfig.ts` 文件或相关文档中，详细说明主题Token命名的规范、使用场景以及如何确保全局统一。"
    },
    {
      "step_id": 20,
      "step_name": "定义 Tailwind 扩展功能 (@layer, Plugins) 使用规范",
      "step_description": "在 `src/specs/tailwind/extensions.ts` 中，定义 `@layer` 指令的使用规范，明确哪些类型的样式应该放在 `base`, `components`, `utilities` 层，以及如何规范地定义和使用 Tailwind 插件。"
    },
    {
      "step_id": 21,
      "step_name": "编写 Tailwind 扩展功能使用规范的详细描述",
      "step_description": "在 `extensions.ts` 文件或文档中，解释 `@layer` 的优先级、作用域，以及插件开发的规范和注意事项。"
    },
    {
      "step_id": 22,
      "step_name": "定义 Tailwind 响应式设计规范",
      "step_description": "在 `src/specs/tailwind/responsiveRules.ts` 中，定义响应式断点前缀（`sm:`, `md:`, `lg:`等）的使用规范，包括优先使用移动优先策略的规则，以及不同常见布局模式在各断点下的类应用示例。"
    },
    {
      "step_id": 23,
      "step_name": "编写 Tailwind 响应式设计规范的详细描述",
      "step_description": "在 `responsiveRules.ts` 文件或文档中，详细说明如何根据用户输入的需求，将响应式行为转化为正确的 Tailwind 响应式类组合。"
    },
    {
      "step_id": 24,
      "step_name": "定义 Tailwind 样式复用与优化规范",
      "step_description": "在 `src/specs/tailwind/optimization.ts` 中，定义何时以及如何使用 `@apply` 指令进行样式复用，以及关于 PurgeCSS 友好代码编写的规范。"
    },
    {
      "step_id": 25,
      "step_name": "编写 Tailwind 样式复用与优化规范的详细描述",
      "step_description": "在 `optimization.ts` 文件或文档中，解释 `@apply` 的适用场景（组件、模式）与不适用场景（简单元素），以及如何避免生成不必要的CSS。"
    },
    {
      "step_id": 26,
      "step_name": "提交 Tailwind 规范定义文件到 Git",
      "step_description": "执行 `git add src/specs/tailwind`，`git commit -m 'feat: define tailwind css specs'`。"
    },
    {
      "step_id": 27,
      "step_name": "创建 Vue3 规范文件",
      "step_description": "在 `src/specs/vue3` 目录下创建文件，如 `compositionApi.ts`, `reactiveSystem.ts`, `functionalComponents.ts`, `hooks.ts`, `lifecycle.ts`, `propsEmits.ts`, `dependencyInjection.ts`等。"
    },
    {
      "step_id": 28,
      "step_name": "定义 Composition API (setup) 使用规范",
      "step_description": "在 `src/specs/vue3/compositionApi.ts` 中，明确规定组件逻辑必须在 `setup()` 函数（或 `<script setup>`）中实现，禁止使用 Options API 的 `data`, `methods` 等选项。"
    },
    {
      "step_id": 29,
      "step_name": "编写 Composition API 使用规范的详细描述",
      "step_description": "在 `compositionApi.ts` 文件或文档中，解释 `<script setup>` 语法糖的优势，以及如何将 Options API 的概念映射到 Composition API 函数。"
    },
    {
      "step_id": 30,
      "step_name": "定义响应式系统 (ref/reactive) 使用规范",
      "step_description": "在 `src/specs/vue3/reactiveSystem.ts` 中，定义何时使用 `ref()` （基本类型、响应式容器）和 `reactive()` （复杂对象/数组），以及 `ref` 的 `.value` 访问规则和模板自动解包行为。"
    },
    {
      "step_id": 31,
      "step_name": "编写响应式系统使用规范的详细描述",
      "step_description": "在 `reactiveSystem.ts` 文件或文档中，详细说明 `toRefs` 和 `toRef` 的使用场景，以及响应式系统的内部工作原理（Proxy）简介。"
    },
    {
      "step_id": 32,
      "step_name": "定义函数式组件使用规范",
      "step_description": "在 `src/specs/vue3/functionalComponents.ts` 中，规定无状态、纯展示性组件优先生成为函数式组件，并说明其实现方式（简单函数导出）。"
    },
    {
      "step_id": 33,
      "step_name": "编写函数式组件使用规范的详细描述",
      "step_description": "在 `functionalComponents.ts` 文件或文档中，解释函数式组件的性能优势和适用场景。"
    },
    {
      "step_id": 34,
      "step_name": "定义 Hooks 管理规范",
      "step_description": "在 `src/specs/vue3/hooks.ts` 中，定义可复用逻辑提取为自定义 Hook 的规则，包括命名约定（`use` 前缀），以及 Hook 的组织方式（单独的 `.ts` 文件）。"
    },
    {
      "step_id": 35,
      "step_name": "编写 Hooks 管理规范的详细描述",
      "step_description": "在 `hooks.ts` 文件或文档中，详细说明如何识别可复用逻辑模式，以及编写高质量 Hook 的原则（单一职责、参数化、副作用管理）。"
    },
    {
      "step_id": 36,
      "step_name": "定义生命周期钩子使用规范",
      "step_description": "在 `src/specs/vue3/lifecycle.ts` 中，定义 `onMounted`, `onUnmounted` 等生命周期钩子在 `setup` 中的使用方式，以及资源清理的强制性要求。"
    },
    {
      "step_id": 37,
      "step_name": "编写生命周期钩子使用规范的详细描述",
      "step_description": "在 `lifecycle.ts` 文件或文档中，列出所有主要的 Composition API 生命周期钩子及其执行时机，以及常见的资源清理模式。"
    },
    {
      "step_id": 38,
      "step_name": "定义 Props 和 Emits 使用规范",
      "step_description": "在 `src/specs/vue3/propsEmits.ts` 中，定义使用 `defineProps` 和 `defineEmits` 宏的规范，包括 Props 的 TypeScript 类型标注、`required` 状态、默认值，以及 Emits 的事件名称定义和参数类型定义。"
    },
    {
      "step_id": 39,
      "step_name": "编写 Props 和 Emits 使用规范的详细描述",
      "step_description": "在 `propsEmits.ts` 文件或文档中，详细说明组件接口定义的最佳实践，如何使用运行时校验和类型校验来增强健壮性。"
    },
    {
      "step_id": 40,
      "step_name": "定义依赖注入 (provide/inject) 使用规范",
      "step_description": "在 `src/specs/vue3/dependencyInjection.ts` 中，定义何时使用 `provide` 和 `inject` 来实现跨层级数据共享，以及注入值的类型安全和默认值处理规范。"
    },
    {
      "step_id": 41,
      "step_name": "编写依赖注入使用规范的详细描述",
      "step_description": "在 `dependencyInjection.ts` 文件或文档中，解释依赖注入的适用场景（避免 prop drilling），以及如何使用 Symbol 或 InjectionKey 来确保注入的唯一性和类型安全。"
    },
    {
      "step_id": 42,
      "step_name": "提交 Vue3 规范定义文件到 Git",
      "step_description": "执行 `git add src/specs/vue3`，`git commit -m 'feat: define vue3 composition api specs'`."
    },
    {
      "step_id": 43,
      "step_name": "创建 TypeScript 规范文件",
      "step_description": "在 `src/specs/typescript` 目录下创建文件，如 `typeInference.ts`, `interfacesTypes.ts`, `annotations.ts`, `generics.ts`, `strictMode.ts`, `importExport.ts`等。"
    },
    {
      "step_id": 44,
      "step_name": "定义类型推导与显式声明规范",
      "step_description": "在 `src/specs/typescript/typeInference.ts` 中，定义优先使用类型推导的场景，以及强制显式类型声明的场景（函数参数/返回值、props、状态初始化等）。"
    },
    {
      "step_id": 45,
      "step_name": "编写类型推导与显式声明规范的详细描述",
      "step_description": "在 `typeInference.ts` 文件或文档中，通过代码示例说明类型推导的能力和限制，以及何时显式声明能够提高代码清晰度。"
    },
    {
      "step_id": 46,
      "step_name": "定义接口 (interface) 和类型别名 (type) 规范",
      "step_description": "在 `src/specs/typescript/interfacesTypes.ts` 中，明确规定 `interface` 用于定义对象结构和支持声明合并，`type` 用于别名、联合、交叉、映射类型等，以及何时使用 `interface` 何时使用 `type` 的指导原则。"
    },
    {
      "step_id": 47,
      "step_name": "编写接口和类型别名规范的详细描述",
      "step_description": "在 `interfacesTypes.ts` 文件或文档中，通过代码示例展示 `interface` 和 `type` 的不同用法和特性，以及选择依据。"
    },
    {
      "step_id": 48,
      "step_name": "定义类型注解规范",
      "step_description": "在 `src/specs/typescript/annotations.ts` 中，强制要求函数参数和返回值进行类型注解，以及对象解构参数的类型注解方式。"
    },
    {
      "step_id": 49,
      "step_name": "编写类型注解规范的详细描述",
      "step_description": "在 `annotations.ts` 文件或文档中，强调类型注解对于代码可读性、可维护性和工具支持的重要性，并提供各种常见场景的注解示例。"
    },
    {
      "step_id": 50,
      "step_name": "定义泛型 (Generics) 使用规范",
      "step_description": "在 `src/specs/typescript/generics.ts` 中，定义何时使用泛型来增强代码复用性和类型安全性，以及避免滥用泛型导致复杂性的原则。"
    },
    {
      "step_id": 51,
      "step_name": "编写泛型使用规范的详细描述",
      "step_description": "在 `generics.ts` 文件或文档中，通过具体示例展示如何使用泛型定义通用函数、接口和类型，以及泛型约束 (`extends`) 的用法。"
    },
    {
      "step_id": 52,
      "step_name": "确认 TypeScript 严格模式已启用",
      "step_description": "再次检查 `tsconfig.json` 文件，确认 `strict` 选项设置为 `true`，并且理解开启严格模式带来的所有子选项的效果。"
    },
    {
      "step_id": 53,
      "step_name": "定义类型导入与导出规范",
      "step_description": "在 `src/specs/typescript/importExport.ts` 中，定义使用 `import type` 语法来只导入类型，以及明确区分值导出和类型导出的规范。"
    },
    {
      "step_id": 54,
      "step_name": "编写类型导入与导出规范的详细描述",
      "step_description": "在 `importExport.ts` 文件或文档中，解释 `import type` 的作用和好处（如 tree-shaking 优化），并提供导入/导出类型和值的代码示例。"
    },
    {
      "step_id": 55,
      "step_name": "提交 TypeScript 规范定义文件到 Git",
      "step_description": "执行 `git add src/specs/typescript`，`git commit -m 'feat: define typescript specs'`。"
    },
    {
      "step_id": 56,
      "step_name": "整合技术栈规范文档",
      "step_description": "在项目的根目录或 `/docs` 目录下创建一个主规范文档，汇总 Tailwind, Vue3, TypeScript 三个技术栈的所有规范内容。"
    },
    {
      "step_id": 57,
      "step_name": "评审技术栈规范体系",
      "step_description": "邀请团队成员或领域专家对已定义的全部技术栈规范进行评审，收集反馈意见。"
    },
    {
      "step_id": 58,
      "step_name": "根据评审意见修订技术栈规范",
      "step_description": "根据评审过程中收集到的反馈，对 Tailwind, Vue3, TypeScript 的规范定义文件和文档进行修改和完善。"
    },
    {
      "step_id": 59,
      "step_name": "最终确认技术栈规范体系",
      "step_description": "完成修订后，正式批准和确认这套技术栈规范作为代码生成助手的开发和输出标准。"
    },
    {
      "step_id": 60,
      "step_name": "提交最终技术栈规范到 Git",
      "step_description": "执行 `git add docs src/specs`，`git commit -m 'docs: finalize technical stack specifications'`。"
    },
    {
      "step_id": 61,
      "step_name": "规划 Prompt 架构",
      "step_description": "在 `src/core` 目录下创建子目录，如 `prompt`, `generator`, `validator`，用于实现 Prompt 架构的各个组成部分。"
    },
    {
      "step_id": 62,
      "step_name": "定义输入协议的数据结构",
      "step_description": "在 `src/core/prompt/inputProtocol.ts` 中，使用 TypeScript 接口定义用户输入 JSON 的完整结构，包括组件名称、类型、描述、props、emits、state、template等字段及其嵌套结构。"
    },
    {
      "step_id": 63,
      "step_name": "为输入协议数据结构添加详细注释",
      "step_description": "在 `inputProtocol.ts` 的接口和属性上添加详细的 TSDoc 注释，解释每个字段的含义、类型、是否必需以及示例值。"
    },
    {
      "step_id": 64,
      "step_name": "考虑输入协议的扩展性",
      "step_description": "在设计输入协议时，预留字段或采用灵活的结构，以便未来可以方便地增加新的输入参数，如设计系统引用、更多交互细节等。"
    },
    {
      "step_id": 65,
      "step_name": "定义输出协议的数据结构",
      "step_description": "在 `src/core/prompt/outputProtocol.ts` 中，使用 TypeScript 接口定义生成器输出的结构，即一个映射表，键为文件名（string），值为文件内容（string）。"
    },
    {
      "step_id": 66,
      "step_name": "为输出协议数据结构添加详细注释",
      "step_description": "在 `outputProtocol.ts` 的接口和属性上添加详细的 TSDoc 注释，解释输出结构的格式要求，如文件路径规范、文件内容类型等。"
    },
    {
      "step_id": 67,
      "step_name": "考虑输出协议的扩展性",
      "step_description": "设想未来输出可能包含除了代码文件之外的其他元数据（如校验报告摘要、建议的 Git commit 信息），并在输出协议结构中预留位置。"
    },
    {
      "step_id": 68,
      "step_name": "提交输入输出协议定义到 Git",
      "step_description": "执行 `git add src/core/prompt`，`git commit -m 'feat: define input and output protocols'`。"
    },
    {
      "step_id": 69,
      "step_name": "规划代码生成引擎结构",
      "step_description": "在 `src/core/generator` 目录下创建文件或子目录，如 `templateEngine.ts`, `ruleEngine.ts`, `formatter.ts`, `generationFlow.ts`。"
    },
    {
      "step_id": 70,
      "step_name": "设计模板引擎接口",
      "step_description": "在 `src/core/generator/templateEngine.ts` 中，定义一个接口或类，包含加载模板、根据参数渲染模板的方法。"
    },
    {
      "step_id": 71,
      "step_name": "选择或研究模板引擎库",
      "step_description": "调研可用于代码生成的模板引擎库，如 Handlebars, EJS, LiquidJS 等，选择一个适合的并在文档中记录原因。"
    },
    {
      "step_id": 72,
      "step_name": "实现模板引擎加载功能（骨架）",
      "step_description": "在 `templateEngine.ts` 中编写加载模板文件内容的基础代码。"
    },
    {
      "step_id": 73,
      "step_name": "实现模板引擎渲染功能（骨架）",
      "step_description": "在 `templateEngine.ts` 中编写调用选定的模板引擎库进行模板渲染的基础代码，接收模板内容和数据对象作为输入。"
    },
    {
      "step_id": 74,
      "step_name": "设计规则引擎接口",
      "step_description": "在 `src/core/generator/ruleEngine.ts` 中，定义一个接口或类，包含加载规则集、根据输入应用规则、输出生成指令的方法。"
    },
    {
      "step_id": 75,
      "step_name": "规划规则存储格式",
      "step_description": "决定如何存储代码生成规则，可以是结构化数据文件（如 JSON, YAML）或 TypeScript 代码（将规则定义为函数或对象）。"
    },
    {
      "step_id": 76,
      "step_name": "实现规则引擎加载功能（骨架）",
      "step_description": "在 `ruleEngine.ts` 中编写加载规则集的基础代码。"
    },
    {
      "step_id": 77,
      "step_name": "实现规则引擎匹配和应用功能（骨架）",
      "step_description": "在 `ruleEngine.ts` 中编写根据输入匹配规则并执行相应逻辑的基础代码。"
    },
    {
      "step_id": 78,
      "step_name": "设计代码格式化模块接口",
      "step_description": "在 `src/core/generator/formatter.ts` 中，定义一个接口或函数，接收代码字符串、文件类型作为输入，输出格式化后的代码字符串。"
    },
    {
      "step_id": 79,
      "step_name": "选择或研究代码格式化工具",
      "step_description": "调研可用于格式化多种代码（Vue, TS, HTML, CSS, JSON）的工具，如 Prettier，并决定使用它作为核心格式化工具。"
    },
    {
      "step_id": 80,
      "step_name": "安装选定的代码格式化工具",
      "step_description": "执行 `npm install prettier --save-dev` 安装 Prettier。"
    },
    {
      "step_id": 81,
      "step_name": "配置代码格式化工具",
      "step_description": "创建 Prettier 配置文件（如 `.prettierrc.js`），配置缩进、引号、分号等代码风格选项，确保与技术栈规范一致。"
    },
    {
      "step_id": 82,
      "step_name": "实现代码格式化功能（骨架）",
      "step_description": "在 `formatter.ts` 中编写调用 Prettier API 进行代码格式化的基础代码。"
    },
    {
      "step_id": 83,
      "step_name": "设计生成流程控制模块",
      "step_description": "在 `src/core/generator/generationFlow.ts` 中，定义一个主函数或类，编排整个代码生成过程的步骤（解析输入 -> 选择模板 -> 生成逻辑 -> ... -> 格式化 -> 校验）。"
    },
    {
      "step_id": 84,
      "step_name": "实现生成流程的初始骨架",
      "step_description": "在 `generationFlow.ts` 中，按照2.3节定义的步骤顺序，编写调用其他模块（解析器、模板引擎、规则引擎、格式化器、校验器）的基础代码结构。"
    },
    {
      "step_id": 85,
      "step_name": "提交代码生成引擎结构到 Git",
      "step_description": "执行 `git add src/core/generator`，`git commit -m 'feat: design code generation engine structure'`。"
    },
    {
      "step_id": 86,
      "step_name": "规划规范校验层结构",
      "step_description": "在 `src/core/validator` 目录下创建文件或子目录，如 `specValidator.ts`, `syntaxValidator.ts`, `typeValidator.ts`, `inputMatcher.ts`, `errorHandler.ts`。"
    },
    {
      "step_id": 87,
      "step_name": "设计技术栈规范校验器接口",
      "step_description": "在 `src/core/validator/specValidator.ts` 中，定义一个接口或类，包含校验生成的代码是否符合技术栈规范的方法，接收代码内容、文件类型和规范定义作为输入。"
    },
    {
      "step_id": 88,
      "step_name": "实现 Tailwind 规范校验子模块（骨架）",
      "step_description": "在 `specValidator.ts` 内部或一个子文件中，编写校验 Tailwind 类使用是否规范、是否符合主题配置的基础代码。"
    },
    {
      "step_id": 89,
      "step_name": "实现 Vue3 规范校验子模块（骨架）",
      "step_description": "在 `specValidator.ts` 内部或一个子文件中，编写校验 Vue3 Composition API 使用是否规范、Props/Emits 定义是否正确的基础代码。"
    },
    {
      "step_id": 90,
      "step_name": "实现 TypeScript 规范校验子模块（骨架）",
      "step_description": "在 `specValidator.ts` 内部或一个子文件中，编写校验 TypeScript 类型使用是否规范、是否符合严格模式要求的基础代码。"
    },
    {
      "step_id": 91,
      "step_name": "设计语法校验器接口",
      "step_description": "在 `src/core/validator/syntaxValidator.ts` 中，定义一个接口或函数，接收代码内容、文件类型作为输入，使用相应的解析器检查语法错误（如 ESLint 的解析能力）。"
    },
    {
      "step_id": 92,
      "step_name": "安装代码语法解析工具",
      "step_description": "安装 ESLint 及其相关的 parser 和 plugin（如 `@typescript-eslint/parser`, `eslint-plugin-vue`）。"
    },
    {
      "step_id": 93,
      "step_name": "配置 ESLint",
      "step_description": "创建 ESLint 配置文件（`.eslintrc.js`），配置 parser, plugins 和 rules，确保覆盖 Vue、TypeScript、HTML、CSS 的语法检查。"
    },
    {
      "step_id": 94,
      "step_name": "实现语法校验功能（骨架）",
      "step_description": "在 `syntaxValidator.ts` 中编写调用 ESLint API 进行代码语法和风格检查的基础代码。"
    },
    {
      "step_id": 95,
      "step_name": "设计类型校验器接口",
      "step_description": "在 `src/core/validator/typeValidator.ts` 中，定义一个接口或函数，接收 TypeScript 代码内容作为输入，使用 TypeScript 编译器 API 检查类型错误。"
    },
    {
      "step_id": 96,
      "step_name": "研究 TypeScript 编译器 API",
      "step_description": "学习如何使用 TypeScript 官方提供的 API (`ts` module) 在代码中进行程序化的类型检查。"
    },
    {
      "step_id": 97,
      "step_name": "实现类型校验功能（骨架）",
      "step_description": "在 `typeValidator.ts` 中编写调用 TypeScript 编译器 API 进行类型检查的基础代码。"
    },
    {
      "step_id": 98,
      "step_name": "设计输入匹配校验器接口",
      "step_description": "在 `src/core/validator/inputMatcher.ts` 中，定义一个接口或函数，接收原始输入和生成的代码作为输入，校验生成的代码是否反映了输入的需求（例如，是否生成了所有要求的 props，是否包含了指定的文本内容）。"
    },
    {
      "step_id": 99,
      "step_name": "规划输入匹配校验规则",
      "step_description": "定义一系列规则来检查生成代码的结构、属性、内容是否与用户输入的需求描述相符。这可能需要解析生成的HTML和TS代码的抽象语法树（AST）。"
    },
    {
      "step_id": 100,
      "step_name": "实现输入匹配校验功能（骨架）",
      "step_description": "在 `inputMatcher.ts` 中编写根据规则比较输入和生成代码的基础代码。"
    },
    {
      "step_id": 101,
      "step_name": "设计错误处理器模块",
      "step_description": "在 `src/core/validator/errorHandler.ts` 中，定义一个接口或类，负责收集所有校验过程中发现的错误和警告，并按照2.3节定义的格式生成结构化的错误报告。"
    },
    {
      "step_id": 102,
      "step_name": "实现错误收集功能",
      "step_description": "在 `errorHandler.ts` 中，实现一个机制来存储校验过程中报告的所有错误信息，包括错误类型、位置、描述等。"
    },
    {
      "step_id": 103,
      "step_name": "实现错误报告生成功能",
      "step_description": "在 `errorHandler.ts` 中，实现将收集到的错误信息格式化为 JSON 格式的错误报告的功能。"
    },
    {
      "step_id": 104,
      "step_name": "将校验器集成到生成流程中",
      "step_description": "修改 `src/core/generator/generationFlow.ts`，在代码生成步骤之后，调用规范校验层的所有校验器。"
    },
    {
      "step_id": 105,
      "step_name": "在生成流程中处理校验结果",
      "step_description": "修改 `generationFlow.ts`，检查校验器的返回结果。如果存在错误，则调用错误处理器生成报告并停止输出代码；如果校验通过，则继续输出代码。"
    },
    {
      "step_id": 106,
      "step_name": "提交规范校验层结构到 Git",
      "step_description": "执行 `git add src/core/validator`，`git commit -m 'feat: design specification validation layer'`。"
    },
    {
      "step_id": 107,
      "step_name": "规划组件生成系统",
      "step_description": "在 `src/generators` 目录下创建子目录，如 `components`, `templates`, `rules`。"
    },
    {
      "step_id": 108,
      "step_name": "设计原子组件库模板存储结构",
      "step_description": "在 `src/generators/templates` 目录下创建子目录 `components/atomic`，用于存放原子组件的模板文件（`.vue.hbs` 或其他模板引擎后缀）。"
    },
    {
      "step_id": 109,
      "step_name": "创建 Button 组件的模板文件",
      "step_description": "在 `src/generators/templates/components/atomic` 目录下创建 `Button.vue.hbs` 文件，编写 Button 组件的骨架 HTML 模板、`<script setup>` 块和 `<style scoped>` 块，使用模板引擎变量代替具体值（如 `{{ props.text }}`）。"
    },
    {
      "step_id": 110,
      "step_name": "创建 Input 组件的模板文件",
      "step_description": "在 `src/generators/templates/components/atomic` 目录下创建 `Input.vue.hbs` 文件，编写 Input 组件的骨架模板，包括 `v-model` 绑定等。"
    },
    {
      "step_id": 111,
      "step_name": "创建 Card 组件的模板文件",
      "step_description": "在 `src/generators/templates/components/atomic` 目录下创建 `Card.vue.hbs` 文件，编写 Card 组件的骨架模板，包括 slot 用法等。"
    },
    {
      "step_id": 112,
      "step_name": "为原子组件模板添加注释",
      "step_description": "在模板文件中添加注释，说明模板中使用的变量的含义和预期数据类型。"
    },
    {
      "step_id": 113,
      "step_name": "定义原子组件属性映射规则",
      "step_description": "在 `src/generators/rules/components/atomic` 目录下创建规则文件，如 `ButtonRules.ts`。定义规则，将用户输入中对按钮的描述（如 `variant: 'primary'`, `disabled: true`）映射到 Button 模板所需的输入参数（Props, Tailwind类）。"
    },
    {
      "step_id": 114,
      "step_name": "定义 Input 组件属性映射规则",
      "step_description": "在 `InputRules.ts` 中定义规则，将用户输入对输入框的描述映射到 Input 模板的 Props 和行为。"
    },
    {
      "step_id": 115,
      "step_name": "定义 Card 组件属性映射规则",
      "step_description": "在 `CardRules.ts` 中定义规则，将用户输入对卡片的描述映射到 Card 模板的 Props 和 slot 内容。"
    },
    {
      "step_id": 116,
      "step_name": "实现加载原子组件模板的功能",
      "step_description": "修改模板引擎模块 (`src/core/generator/templateEngine.ts`)，添加加载 `components/atomic` 目录下模板文件的逻辑。"
    },
    {
      "step_id": 117,
      "step_name": "实现应用原子组件规则的功能",
      "step_description": "修改规则引擎模块 (`src/core/generator/ruleEngine.ts`)，添加加载并应用 `components/atomic` 目录下规则的逻辑。"
    },
    {
      "step_id": 118,
      "step_name": "规划智能组合引擎结构",
      "step_description": "在 `src/generators/components` 目录下创建子目录 `compound` 和文件 `combinationEngine.ts`。"
    },
    {
      "step_id": 119,
      "step_name": "定义复合组件模板存储结构",
      "step_description": "在 `src/generators/templates/components/compound` 目录下创建子目录，用于存放复合组件的模板，如 `Modal.vue.hbs`。"
    },
    {
      "step_id": 120,
      "step_name": "创建 Modal 复合组件的模板文件",
      "step_description": "在 `src/generators/templates/components/compound` 目录下创建 `Modal.vue.hbs`，编写包含 `ModalHeader`, `ModalBody`, `ModalFooter` 等原子或子组件的组合模板。"
    },
    {
      "step_id": 121,
      "step_name": "定义组件组合规则",
      "step_description": "在 `src/generators/rules/components/compound` 目录下创建规则文件，如 `ModalRules.ts`。定义规则，根据用户输入对模态框的描述，决定组合哪些原子组件、它们的顺序以及它们之间的父子关系。"
    },
    {
      "step_id": 122,
      "step_name": "实现智能组合引擎的核心逻辑",
      "step_description": "在 `src/generators/components/combinationEngine.ts` 中，编写根据输入解析出的结构需求，查找并组合相应的原子或复合组件模板和规则的逻辑。"
    },
    {
      "step_id": 123,
      "step_name": "实现智能布局逻辑",
      "step_description": "在 `combinationEngine.ts` 中集成或调用布局规则模块，根据组件在组合结构中的位置和用户指定的布局需求，为生成的容器和组件应用正确的 Tailwind 布局类。"
    },
    {
      "step_id": 124,
      "step_name": "实现上下文感知样式应用逻辑",
      "step_description": "在 `combinationEngine.ts` 中集成或调用样式应用规则模块，根据组件在其父容器或兄弟节点中的上下文，应用额外的或修改默认的 Tailwind 类。"
    },
    {
      "step_id": 125,
      "step_name": "规划组件生成流程控制",
      "step_description": "在 `src/generators/components` 目录下创建文件 `componentGenerator.ts`，负责协调模板选择、规则应用、逻辑生成、样式应用等步骤来生成单个组件。"
    },
    {
      "step_id": 126,
      "step_name": "实现组件生成器的输入解析",
      "step_description": "在 `componentGenerator.ts` 中，接收格式化的用户输入（符合输入协议），并解析出生成一个组件所需的所有信息（名称、props、state、template结构等）。"
    },
    {
      "step_id": 127,
      "step_name": "实现组件生成器的模板选择逻辑",
      "step_description": "在 `componentGenerator.ts` 中，根据组件类型（原子/复合）和名称，调用模板引擎选择相应的模板文件。"
    },
    {
      "step_id": 128,
      "step_name": "实现组件生成器的逻辑代码生成",
      "step_description": "在 `componentGenerator.ts` 中，根据输入的 state, computed, watchers, methods, lifecycleHooks 定义，使用模板或规则引擎生成 `<script setup>` 块中的 TypeScript/Vue 代码。"
    },
    {
      "step_id": 129,
      "step_name": "实现组件生成器的类型代码生成",
      "step_description": "在 `componentGenerator.ts` 中，根据输入的 props, emits, state 定义，生成 Props 和 Emits 的类型定义，以及其他相关的 TypeScript 接口或类型别名。"
    },
    {
      "step_id": 130,
      "step_name": "实现组件生成器的模板代码生成",
      "step_description": "在 `componentGenerator.ts` 中，根据输入的 template 结构描述，使用模板引擎和组合引擎生成 `<template>` 块中的 HTML 结构、指令和绑定。"
    },
    {
      "step_id": 131,
      "step_name": "实现组件生成器的样式代码生成",
      "step_description": "在 `componentGenerator.ts` 中，根据输入的 tailwindClasses 和 designStyle，为模板中的元素应用 Tailwind 类，并在需要时生成 `<style scoped>` 中的内容。"
    },
    {
      "step_id": 132,
      "step_name": "实现组件生成器的依赖解析和导入",
      "step_description": "在 `componentGenerator.ts` 中，识别生成的组件依赖的其他组件或 Hooks，并在 `<script setup>` 块中自动生成相应的导入语句。"
    },
    {
      "step_id": 133,
      "step_name": "将组件生成器集成到主生成流程",
      "step_description": "修改 `src/core/generator/generationFlow.ts`，添加调用 `componentGenerator.ts` 来生成单个组件的逻辑，并处理其输出。"
    },
    {
      "step_id": 134,
      "step_name": "提交组件生成系统代码到 Git",
      "step_description": "执行 `git add src/generators/components src/generators/templates/components src/generators/rules/components`，`git commit -m 'feat: implement component generation system'`。"
    },
    {
      "step_id": 135,
      "step_name": "规划页面生成系统",
      "step_description": "在 `src/generators` 目录下创建子目录 `pages` 和文件 `pageGenerator.ts`。"
    },
    {
      "step_id": 136,
      "step_name": "设计页面架构模板存储结构",
      "step_description": "在 `src/generators/templates/pages` 目录下创建子目录，如 `dashboard`, `form`, `list`，用于存放页面模板文件（`.vue.hbs`）。"
    },
    {
      "step_id": 137,
      "step_name": "创建 Dashboard 页面模板文件",
      "step_description": "在 `src/generators/templates/pages/dashboard` 目录下创建 `DashboardPage.vue.hbs` 文件，编写包含侧边栏、顶部导航栏、主内容区域等骨架结构的模板。"
    },
    {
      "step_id": 138,
      "step_name": "创建 Form 页面模板文件",
      "step_description": "在 `src/generators/templates/pages/form` 目录下创建 `FormPage.vue.hbs` 文件，编写包含表单区域骨架结构的模板。"
    },
    {
      "step_id": 139,
      "step_name": "定义页面架构模板参数",
      "step_description": "在页面模板中使用模板引擎变量，定义可以用来定制页面结构的参数，例如侧边栏内容、主内容区域包含的组件列表等。"
    },
    {
      "step_id": 140,
      "step_name": "定义页面模板选择规则",
      "step_description": "在 `src/generators/rules/pages` 目录下创建规则文件，如 `PageRules.ts`。定义规则，根据用户输入对页面类型的描述（如 `type: 'dashboard'`），选择相应的页面模板文件。"
    },
    {
      "step_id": 141,
      "step_name": "实现加载页面模板的功能",
      "step_description": "修改模板引擎模块 (`src/core/generator/templateEngine.ts`)，添加加载 `pages` 目录下模板文件的逻辑。"
    },
    {
      "step_id": 142,
      "step_name": "实现应用页面模板规则的功能",
      "step_description": "修改规则引擎模块 (`src/core/generator/ruleEngine.ts`)，添加加载并应用 `pages` 目录下规则的逻辑。"
    },
    {
      "step_id": 143,
      "step_name": "规划动态布局引擎集成",
      "step_description": "在 `src/generators/pages` 目录下创建文件 `layoutEngine.ts` 或集成到 `pageGenerator.ts` 中。"
    },
    {
      "step_id": 144,
      "step_name": "定义页面布局规则",
      "step_description": "在 `src/generators/rules/pages` 目录下创建规则文件，如 `LayoutRules.ts`。定义规则，将用户输入对页面布局的描述（如“主内容区域分成两列，移动设备堆叠”）映射到 Tailwind 的 Grid/Flexbox 布局类和响应式前缀。"
    },
    {
      "step_id": 145,
      "step_name": "实现动态布局逻辑",
      "step_description": "在 `pageGenerator.ts` 中集成布局规则应用逻辑，根据用户输入和选定的页面模板，为页面骨架和内容区域应用正确的 Tailwind 布局类。"
    },
    {
      "step_id": 146,
      "step_name": "实现响应式布局应用逻辑",
      "step_description": "在布局逻辑中，确保正确地应用 Tailwind 的响应式前缀，根据断点调整布局属性。"
    },
    {
      "step_id": 147,
      "step_name": "规划状态管理集成",
      "step_description": "在 `src/generators` 目录下创建子目录 `stateManagement` 和文件 `stateGenerator.ts`。"
    },
    {
      "step_id": 148,
      "step_name": "选择状态管理库模板",
      "step_description": "在 `src/generators/templates/stateManagement` 目录下创建 Pinia 或 Vuex Store 的模板文件，如 `piniaStore.hbs`, `vuexModule.hbs`。"
    },
    {
      "step_id": 149,
      "step_name": "定义状态管理生成规则",
      "step_description": "在 `src/generators/rules/stateManagement` 目录下创建规则文件，如 `StoreRules.ts`。定义规则，根据用户输入中对共享状态的需求（state, getters, actions/mutations），生成相应的 Store 代码。"
    },
    {
      "step_id": 150,
      "step_name": "实现状态管理代码生成逻辑",
      "step_description": "在 `src/generators/stateManagement/stateGenerator.ts` 中，编写根据规则和模板生成 Pinia Store 或 Vuex Module 代码的逻辑。"
    },
    {
      "step_id": 151,
      "step_name": "实现页面与 Store 的集成逻辑",
      "step_description": "在 `pageGenerator.ts` 中，如果页面需要集成状态管理，生成在页面组件中导入和使用 Store 的代码（如 `useStore()`, `mapState`, `mapActions`）。"
    },
    {
      "step_id": 152,
      "step_name": "实现状态驱动布局/内容逻辑",
      "step_description": "在 `pageGenerator.ts` 和 `componentGenerator.ts` 中，如果组件/页面依赖 Store 中的状态，生成使用计算属性或 watchers 来响应状态变化并更新 UI 的代码。"
    },
    {
      "step_id": 153,
      "step_name": "实现页面生成器的输入解析",
      "step_description": "在 `pageGenerator.ts` 中，接收格式化的用户输入（符合输入协议），并解析出生成一个页面所需的所有信息（类型、结构、布局、状态需求等）。"
    },
    {
      "step_id": 154,
      "step_name": "实现页面生成器的模板选择逻辑",
      "step_description": "在 `pageGenerator.ts` 中，根据页面类型，调用模板引擎选择相应的页面模板文件。"
    },
    {
      "step_id": 155,
      "step_name": "实现页面生成器的子组件和内容生成",
      "step_description": "在 `pageGenerator.ts` 中，根据输入的页面结构描述，调用组件生成器 (`componentGenerator.ts`) 或组合引擎 (`combinationEngine.ts`) 来生成页面内部的各个区域和组件。"
    },
    {
      "step_id": 156,
      "step_name": "实现页面生成器的样式和布局应用",
      "step_description": "在 `pageGenerator.ts` 中，为页面骨架和生成的内部组件应用正确的 Tailwind 类和布局样式。"
    },
    {
      "step_id": 157,
      "step_name": "将页面生成器集成到主生成流程",
      "step_description": "修改 `src/core/generator/generationFlow.ts`，添加调用 `pageGenerator.ts` 来生成页面的逻辑，并处理其输出。"
    },
    {
      "step_id": 158,
      "step_name": "提交页面生成系统代码到 Git",
      "step_description": "执行 `git add src/generators/pages src/generators/stateManagement src/generators/templates/pages src/generators/rules/pages src/generators/rules/stateManagement`，`git commit -m 'feat: implement page generation system'`。"
    },
    {
      "step_id": 159,
      "step_name": "规划规范执行保障体系",
      "step_description": "在 `src/enforcement` 目录下创建子目录，如 `qualityGates`, `feedback`, `versionControl`。"
    },
    {
      "step_id": 160,
      "step_name": "设计代码质量门禁模块接口",
      "step_description": "在 `src/enforcement/qualityGates` 目录下创建文件 `codeQualityGate.ts`，定义一个接口或函数，集成静态分析和测试验证的功能。"
    },
    {
      "step_id": 161,
      "step_name": "将 ESLint 集成到质量门禁",
      "step_description": "在 `codeQualityGate.ts` 中，调用语法校验器 (`src/core/validator/syntaxValidator.ts`)，并将其结果作为质量门禁的一部分。"
    },
    {
      "step_id": 162,
      "step_name": "将 TypeScript 类型检查集成到质量门禁",
      "step_description": "在 `codeQualityGate.ts` 中，调用类型校验器 (`src/core/validator/typeValidator.ts`)，并将其结果作为质量门禁的一部分。"
    },
    {
      "step_id": 163,
      "step_name": "集成测试执行到质量门禁",
      "step_description": "在 `codeQualityGate.ts` 中，预留调用测试运行器执行单元测试和集成测试的功能接口。"
    },
    {
      "step_id": 164,
      "step_name": "定义质量门禁的通过标准",
      "step_description": "在 `codeQualityGate.ts` 或配置文件中，明确定义何时质量门禁被视为通过（例如，没有 ESLint error, 没有 TypeScript error, 所有必需的测试通过）。"
    },
    {
      "step_id": 165,
      "step_name": "将质量门禁集成到主生成流程",
      "step_description": "修改 `src/core/generator/generationFlow.ts`，在规范校验之后，添加调用 `codeQualityGate.ts` 进行最终质量检查的步骤。"
    },
    {
      "step_id": 166,
      "step_name": "在生成流程中处理质量门禁结果",
      "step_description": "修改 `generationFlow.ts`，如果质量门禁未通过，则调用错误处理器生成详细报告并停止输出代码。"
    },
    {
      "step_id": 167,
      "step_name": "设计实时反馈机制模块",
      "step_description": "在 `src/enforcement/feedback` 目录下创建文件 `realtimeFeedback.ts`，定义用于收集和报告生成过程中非致命问题（如 Lint 警告）的机制。"
    },
    {
      "step_id": 168,
      "step_name": "收集 Lint 警告",
      "step_description": "修改语法校验器 (`syntaxValidator.ts`)，使其不仅报告错误，也收集警告信息。"
    },
    {
      "step_id": 169,
      "step_name": "收集其他非致命问题",
      "step_description": "在其他校验器或生成逻辑中，识别并收集潜在的非致命问题或改进建议。"
    },
    {
      "step_id": 170,
      "step_name": "在错误报告中包含警告和建议",
      "step_description": "修改错误处理器 (`errorHandler.ts`)，使其在生成报告时，除了错误信息外，也包含收集到的警告和建议列表。"
    },
    {
      "step_id": 171,
      "step_name": "模拟自动化 CI/CD 流程检查",
      "step_description": "在 `codeQualityGate.ts` 中，将类型检查、Linting、测试执行等步骤组织起来，模拟 CI/CD 管道中的构建和测试阶段。"
    },
    {
      "step_id": 172,
      "step_name": "规划版本控制兼容性",
      "step_description": "在 `src/enforcement/versionControl` 目录下创建文件 `gitCompatibility.ts`，定义关于生成的代码如何与 Git 集成的指导原则。"
    },
    {
      "step_id": 173,
      "step_name": "确保生成的文件名和目录结构符合 Git 最佳实践",
      "step_description": "在文件生成和命名逻辑中，遵循清晰、一致的命名约定，避免使用特殊字符或过长的路径，便于 Git 管理。"
    },
    {
      "step_id": 174,
      "step_name": "生成建议的 Git Commit 信息",
      "step_description": "在生成成功后，根据本次生成的组件/页面名称和类型，以及输入中的描述，自动生成一个建议的 Git commit 信息字符串（例如，遵循 Conventional Commits 规范）。"
    },
    {
      "step_id": 175,
      "step_name": "生成建议的版本标记信息",
      "step_description": "对于重要的生成任务（如创建新功能模块的页面和组件），在输出元数据中包含建议的版本标记信息。"
    },
    {
      "step_id": 176,
      "step_name": "提交规范执行保障体系代码到 Git",
      "step_description": "执行 `git add src/enforcement`，`git commit -m 'feat: implement specification enforcement system'`。"
    },
    {
      "step_id": 177,
      "step_name": "规划交互系统",
      "step_description": "在 `src/interfaces` 目录下创建子目录，如 `cli`, `api`, `monitoring`。"
    },
    {
      "step_id": 178,
      "step_name": "设计命令行界面 (CLI) 模块",
      "step_description": "在 `src/interfaces/cli` 目录下创建文件 `cli.ts`，使用 Node.js 的 `process.argv` 或命令行解析库（如 Commander, Yargs）来处理命令行输入。"
    },
    {
      "step_id": 179,
      "step_name": "安装命令行解析库",
      "step_description": "选择并安装一个合适的命令行解析库，例如 `npm install commander`。"
    },
    {
      "step_id": 180,
      "step_name": "定义 CLI 命令和选项",
      "step_description": "在 `cli.ts` 中，定义至少一个主命令（如 `generate`），以及用于指定输入文件、输出目录、组件/页面类型等选项。"
    },
    {
      "step_id": 181,
      "step_name": "实现 CLI 输入文件读取功能",
      "step_description": "在 `cli.ts` 中，使用 Node.js 的 `fs` 模块读取用户通过命令行指定输入文件的内容（例如 JSON）。"
    },
    {
      "step_id": 182,
      "step_name": "实现 CLI 参数解析功能",
      "step_description": "在 `cli.ts` 中，使用命令行解析库解析用户输入的命令和选项。"
    },
    {
      "step_id": 183,
      "step_name": "调用主生成流程从 CLI 输入",
      "step_description": "在 `cli.ts` 中，将解析后的用户输入传递给主生成流程函数 (`src/core/generator/generationFlow.ts`)。"
    },
    {
      "step_id": 184,
      "step_name": "处理主生成流程的输出并在 CLI 中展示",
      "step_description": "在 `cli.ts` 中，接收主生成流程返回的生成文件内容或错误报告，并将其写入到用户指定的输出文件或标准输出。"
    },
    {
      "step_id": 185,
      "step_name": "设计 API 接口模块（模拟）",
      "step_description": "在 `src/interfaces/api` 目录下创建文件 `api.ts`，定义一个模拟的 API 接口层，用于接收结构化的请求和返回结构化的响应。"
    },
    {
      "step_id": 186,
      "step_name": "定义模拟的 RESTful API 端点",
      "step_description": "在 `api.ts` 中，定义一个函数或对象，模拟 `/generate/component` 和 `/generate/page` 等 RESTful 端点，接收 POST 请求体作为输入。"
    },
    {
      "step_id": 187,
      "step_name": "在模拟 API 中调用主生成流程",
      "step_description": "在模拟的 API 端点处理逻辑中，将接收到的请求体（用户输入）传递给主生成流程函数。"
    },
    {
      "step_id": 188,
      "step_name": "处理主生成流程的输出并在模拟 API 响应中返回",
      "step_description": "在模拟 API 中，接收主生成流程返回的结果，将其格式化为 JSON 响应体，并设置适当的 HTTP 状态码（200 for success, 400 for error）。"
    },
    {
      "step_id": 189,
      "step_name": "设计监控系统集成模块",
      "step_description": "在 `src/interfaces/monitoring` 目录下创建文件 `monitoring.ts`，定义用于集成日志和指标收集的接口和函数。"
    },
    {
      "step_id": 190,
      "step_name": "集成日志记录",
      "step_description": "修改主生成流程和各个模块，在关键步骤（如开始生成、完成生成、校验成功/失败、错误发生）添加结构化的日志记录，调用 `monitoring.ts` 中提供的日志记录函数。"
    },
    {
      "step_id": 191,
      "step_name": "记录生成请求 ID",
      "step_description": "为每个生成请求生成一个唯一的请求 ID，并在所有相关的日志条目中包含该 ID，以便于追踪。"
    },
    {
      "step_id": 192,
      "step_name": "记录操作类型和结果",
      "step_description": "在日志条目中包含当前操作的类型（如 `generate_component`, `validate_spec`）和结果（`success`, `failure`）。"
    },
    {
      "step_id": 193,
      "step_name": "记录详细信息和错误信息",
      "step_description": "在日志条目中包含与操作相关的详细信息，例如生成的文件的列表，或发生错误时的错误堆栈和报告。"
    },
    {
      "step_id": 194,
      "step_name": "设计指标收集接口",
      "step_description": "在 `monitoring.ts` 中，定义用于记录关键性能指标（如耗时、成功率、错误率）的函数。"
    },
    {
      "step_id": 195,
      "step_name": "记录生成耗时指标",
      "step_description": "在主生成流程的开始和结束时记录时间戳，并计算总耗时，调用指标记录函数进行上报。"
    },
    {
      "step_id": 196,
      "step_name": "记录生成成功率/错误率指标",
      "step_description": "在主生成流程结束时，根据结果（成功或失败），更新成功和失败计数，并计算成功率和错误率指标。"
    },
    {
      "step_id": 197,
      "step_name": "记录生成的代码行数指标",
      "step_description": "在生成文件后，计算生成的文件总行数，并作为指标进行记录。"
    },
    {
      "step_id": 198,
      "step_name": "提交交互系统代码到 Git",
      "step_description": "执行 `git add src/interfaces`，`git commit -m 'feat: implement interaction system (cli, api simulation, monitoring)'`。"
    },
    {
      "step_id": 199,
      "step_name": "规划扩展系统",
      "step_description": "在 `src/extensions` 目录下创建子目录，如 `plugins`, `designSystem`, `ai`。"
    },
    {
      "step_id": 200,
      "step_name": "设计插件架构核心",
      "step_description": "在 `src/extensions/plugins` 目录下创建文件 `pluginManager.ts` 和 `pluginInterface.ts`。"
    },
    {
      "step_id": 201,
      "step_name": "定义插件接口",
      "step_description": "在 `pluginInterface.ts` 中，使用 TypeScript 接口定义插件必须实现的方法和属性，例如初始化方法、用于注册新的模板或规则的方法、用于在生成流程中插入逻辑的钩子函数签名。"
    },
    {
      "step_id": 202,
      "step_name": "实现插件管理器加载功能",
      "step_description": "在 `pluginManager.ts` 中，实现加载指定目录下的插件（例如，根据文件约定或配置文件）的逻辑。"
    },
    {
      "step_id": 203,
      "step_name": "实现插件管理器注册功能",
      "step_description": "在 `pluginManager.ts` 中，实现当插件加载后，调用插件的初始化方法，并注册插件提供的模板、规则、钩子等资源的逻辑。"
    },
    {
      "step_id": 204,
      "step_name": "在生成流程中集成插件钩子",
      "step_description": "修改 `src/core/generator/generationFlow.ts`，在关键步骤（如解析输入后、选择模板后、生成代码前、校验后）调用插件管理器触发相应的钩子函数，允许插件修改数据或执行额外操作。"
    },
    {
      "step_id": 205,
      "step_name": "规划设计系统集成",
      "step_description": "在 `src/extensions/designSystem` 目录下创建文件 `designSystemIntegrator.ts`。"
    },
    {
      "step_id": 206,
      "step_name": "定义设计系统 Token 消费接口",
      "step_description": "在 `designSystemIntegrator.ts` 中，定义一个接口或函数，接收设计系统的 Token 数据（例如 JSON 格式的设计 Token 文件内容）作为输入。"
    },
    {
      "step_id": 207,
      "step_name": "实现设计系统 Token 到 Tailwind 配置的转换逻辑",
      "step_description": "在 `designSystemIntegrator.ts` 中，编写逻辑将设计系统的颜色、间距、字体等 Token 转换为 Tailwind CSS 的主题配置 (`tailwind.config.js` 的 `theme.extend`) 格式。"
    },
    {
      "step_id": 208,
      "step_name": "将转换后的 Tailwind 配置应用到生成器",
      "step_description": "修改规则引擎或样式生成模块，使其使用设计系统转换后的 Tailwind 配置，确保生成的代码优先使用这些 Token 对应的类。"
    },
    {
      "step_id": 209,
      "step_name": "规划 AI 能力增强集成（概念）",
      "step_description": "在 `src/extensions/ai` 目录下创建文件 `aiEnhancer.ts`，定义用于集成 AI 模型功能的接口和占位符。"
    },
    {
      "step_id": 210,
      "step_name": "定义智能推荐接口（概念）",
      "step_description": "在 `aiEnhancer.ts` 中，定义一个接口，用于接收用户输入，并调用外部 AI 模型（或模拟 AI 逻辑）提供组件组合、布局或样式建议。"
    },
    {
      "step_id": 211,
      "step_name": "定义自动化调优接口（概念）",
      "step_description": "在 `aiEnhancer.ts` 中，定义一个接口，用于接收生成的代码，并调用外部 AI 模型（或模拟 AI 逻辑）分析代码质量并建议改进方案。"
    },
    {
      "step_id": 212,
      "step_name": "在生成流程中集成 AI 增强调用（占位符）",
      "step_description": "修改 `src/core/generator/generationFlow.ts`，在适当的位置（例如，生成初步结构后、最终输出前）添加调用 `aiEnhancer.ts` 中接口的占位符代码。"
    },
    {
      "step_id": 213,
      "step_name": "提交扩展系统代码到 Git",
      "step_description": "执行 `git add src/extensions`，`git commit -m 'feat: design extension system (plugins, design system, ai concept)'`。"
    },
    {
      "step_id": 214,
      "step_name": "规划质量验证系统",
      "step_description": "在 `src/quality` 目录下创建子目录,如 `testing`, `verification`, `review`。"
    },
    {
      "step_id": 215,
      "step_name": "设计单元测试生成模块",
      "step_description": "在 `src/quality/testing` 目录下创建文件 `unitTestGenerator.ts`。"
    },
    {
      "step_id": 216,
      "step_name": "选择或研究单元测试框架",
      "step_description": "调研适合 Vue3 和 TypeScript 的单元测试框架，如 Vitest (推荐), Jest，以及 Vue Test Utils 库。"
    },
    {
      "step_id": 217,
      "step_name": "安装单元测试框架和库",
      "step_description": "安装选定的测试框架和 Vue Test Utils：`npm install vitest @vue/test-utils --save-dev`。"
    },
    {
      "step_id": 218,
      "step_name": "配置单元测试环境",
      "step_description": "创建测试配置文件（如 `vitest.config.ts`），配置测试运行器、环境、模块解析等。"
    },
    {
      "step_id": 219,
      "step_name": "定义单元测试生成规则",
      "step_description": "在 `src/generators/rules/testing` 目录下创建文件，如 `ComponentTestRules.ts`, `HookTestRules.ts`。定义规则，如何根据组件的 Props, Emits, State, Computed, Methods 定义，生成相应的测试用例代码（mount component, set props, trigger events, assert state/output）。"
    },
    {
      "step_id": 220,
      "step_name": "实现组件单元测试生成逻辑",
      "step_description": "在 `unitTestGenerator.ts` 中，根据组件输入定义和测试生成规则，使用模板或代码构建器生成组件的 `.test.ts` 文件内容。"
    },
    {
      "step_id": 221,
      "step_name": "实现 Hook 单元测试生成逻辑",
      "step_description": "在 `unitTestGenerator.ts` 中，根据 Hook 输入/输出定义和测试生成规则，生成 Hook 的 `.test.ts` 文件内容。"
    },
    {
      "step_id": 222,
      "step_name": "规划测试覆盖率分析集成",
      "step_description": "在 `src/quality/testing` 目录下创建文件 `coverageAnalyzer.ts`（或集成到测试运行器配置中）。"
    },
    {
      "step_id": 223,
      "step_name": "配置测试覆盖率报告生成",
      "step_description": "在测试框架配置文件中，启用覆盖率报告生成功能（如使用 c8 或 Istanbul），并配置报告格式和输出目录。"
    },
    {
      "step_id": 224,
      "step_name": "在质量门禁中检查测试覆盖率（可选）",
      "step_description": "修改 `src/enforcement/qualityGates/codeQualityGate.ts`，添加检查测试覆盖率是否达到预设阈值的功能（可选，作为更严格的门禁）。"
    },
    {
      "step_id": 225,
      "step_name": "设计规范验证体系（自动化部分）",
      "step_description": "在 `src/quality/verification` 目录下创建文件 `normVerification.ts`。"
    },
    {
      "step_id": 226,
      "step_name": "集成并配置 ESLint 插件以检查规范",
      "step_description": "除了语法和风格，研究或开发 ESLint 插件来强制执行特定的技术栈规范，例如 Tailwind 类排序、Vue3 Composition API 的特定用法等，并在 `.eslintrc.js` 中启用这些规则。"
    },
    {
      "step_id": 227,
      "step_name": "开发自定义规范检查脚本或工具",
      "step_description": "对于 ESLint 难以覆盖的复杂规范（如组件属性化的彻底性、依赖注入的正确使用），开发自定义脚本或工具来扫描生成的代码并检查是否符合规范。"
    },
    {
      "step_id": 228,
      "step_name": "将自动化规范验证集成到质量门禁",
      "step_description": "修改 `src/enforcement/qualityGates/codeQualityGate.ts`，调用 `normVerification.ts` 中实现的自动化规范检查功能。"
    },
    {
      "step_id": 229,
      "step_name": "设计人工复核机制（流程和报告）",
      "step_description": "在 `src/quality/review` 目录下创建文件 `manualReview.ts`（或作为文档）。"
    },
    {
      "step_id": 230,
      "step_name": "定义需要人工复核的条件",
      "step_description": "明确哪些类型的生成任务（例如，复杂页面、核心组件、涉及敏感逻辑的代码）需要强制或建议人工复核。"
    },
    {
      "step_id": 231,
      "step_name": "在生成输出中标记需要人工复核的代码",
      "step_description": "如果生成的代码满足人工复核条件，在输出的元数据或一个单独的报告文件中明确标记，包括复核的原因和重点关注区域。"
    },
    {
      "step_id": 232,
      "step_name": "生成人工复核指导报告",
      "step_description": "对于需要人工复核的代码，生成一份简要的报告，总结本次生成的主要内容，并列出建议复核的关键点，特别是业务逻辑、设计还原度和用户体验方面。"
    },
    {
      "step_id": 233,
      "step_name": "提交质量验证系统代码到 Git",
      "step_description": "执行 `git add src/quality`，`git commit -m 'feat: implement quality validation system (testing, verification, review)'`。"
    },
    {
      "step_id": 234,
      "step_name": "规划文档系统",
      "step_description": "在 `src/documentation` 目录下创建子目录，如 `generator`, `tutorials`, `versioning`。"
    },
    {
      "step_id": 235,
      "step_name": "设计自动化文档生成模块",
      "step_description": "在 `src/documentation/generator` 目录下创建文件 `docGenerator.ts`。"
    },
    {
      "step_id": 236,
      "step_name": "选择或研究文档生成工具",
      "step_description": "调研可以从代码注释（TSDoc/JSDoc）和结构中生成文档的工具，如 Vuedoc, Compodoc, TypeDoc。"
    },
    {
      "step_id": 237,
      "step_name": "安装文档生成工具",
      "step_description": "安装选定的文档生成工具，例如 `npm install @vuedoc/parser --save-dev`。"
    },
    {
      "step_id": 238,
      "step_name": "配置文档生成工具",
      "step_description": "创建文档生成工具的配置文件，指定源代码目录、输出目录、文档格式等。"
    },
    {
      "step_id": 239,
      "step_name": "实现从生成的代码生成文档的功能",
      "step_description": "在 `docGenerator.ts` 中，调用文档生成工具的 API，以生成的代码文件作为输入，生成 API 文档、组件 Props/Emits 文档等。"
    },
    {
      "step_id": 240,
      "step_name": "生成 Markdown 格式的文档",
      "step_description": "在 `docGenerator.ts` 中，如果文档生成工具支持或自行实现逻辑，生成 Markdown 格式的组件使用说明、示例等文档文件。"
    },
    {
      "step_id": 241,
      "step_name": "规划教程系统内容生成",
      "step_description": "在 `src/documentation/tutorials` 目录下创建文件 `tutorialGenerator.ts`。"
    },
    {
      "step_id": 242,
      "step_name": "定义教程内容模板",
      "step_description": "在 `src/generators/templates/documentation/tutorials` 目录下创建教程模板文件，例如 `componentUsageTutorial.md.hbs`。"
    },
    {
      "step_id": 243,
      "step_name": "实现基于生成代码的教程内容生成逻辑",
      "step_description": "在 `tutorialGenerator.ts` 中，根据生成的组件或页面代码及其用途，使用模板引擎生成简短的使用示例、关键概念解释等教程内容（Markdown 格式）。"
    },
    {
      "step_id": 244,
      "step_name": "实现案例分析文档生成逻辑",
      "step_description": "在 `tutorialGenerator.ts` 中或一个单独的文件中，根据用户输入和生成过程的关键决策，生成解释生成过程的案例分析文档。"
    },
    {
      "step_id": 245,
      "step_name": "规划版本管理系统文档",
      "step_description": "在 `src/documentation/versioning` 目录下创建文件 `versionDocGenerator.ts`。"
    },
    {
      "step_id": 246,
      "step_name": "生成版本变更日志",
      "step_description": "在 `versionDocGenerator.ts` 中，根据每次生成/修改任务的摘要，生成符合 Conventional Commits 或其他约定的变更日志条目，并添加到项目的 `CHANGELOG.md` 文件（或模拟添加到该文件）。"
    },
    {
      "step_id": 247,
      "step_name": "在文档中说明版本回退方法",
      "step_description": "在项目的文档中，包含关于如何使用 Git 进行版本回退的指导，强调由于规范化生成代码的优点，回退通常是安全且简单的。"
    },
    {
      "step_id": 248,
      "step_name": "将文档生成集成到主生成流程（可选）",
      "step_description": "修改 `src/core/generator/generationFlow.ts`，在代码生成成功后，添加调用文档生成模块的步骤（可选，取决于文档生成是否作为每次生成的强制步骤）。"
    },
    {
      "step_id": 249,
      "step_name": "提交文档系统代码到 Git",
      "step_description": "执行 `git add src/documentation`，`git commit -m 'feat: implement documentation system (generation, tutorials, versioning)'`。"
    },
    {
      "step_id": 250,
      "step_name": "规划部署与维护",
      "step_description": "在 `src/deployment` 目录下创建子目录，如 `ciCd`, `monitoring`, `maintenance`。"
    },
    {
      "step_id": 251,
      "step_name": "规划 CI/CD 集成系统（概念）",
      "step_description": "在 `src/deployment/ciCd` 目录下创建文件 `ciCdIntegration.ts`，定义与外部 CI/CD 工具集成的接口和流程概念。"
    },
    {
      "step_id": 252,
      "step_name": "生成 CI/CD 配置文件模板",
      "step_description": "在 `src/generators/templates/cicd` 目录下创建常见 CI/CD 工具（如 GitHub Actions, GitLab CI）的配置文件模板（如 `.github/workflows/generate-and-test.yml.hbs`），包含拉取代码、安装依赖、运行生成器、运行测试、Linting 等步骤。"
    },
    {
      "step_id": 253,
      "step_name": "在生成器中集成 CI/CD 配置文件生成（可选）",
      "step_description": "允许用户通过输入参数选择生成包含预配置 CI/CD 流程的配置文件。"
    },
    {
      "step_id": 254,
      "step_name": "规划监控告警集成（概念）",
      "step_description": "在 `src/deployment/monitoring` 目录下创建文件 `monitoringAlerting.ts`，定义与外部监控告警系统集成的接口和流程概念。"
    },
    {
      "step_id": 255,
      "step_name": "定义监控指标上报接口（概念）",
      "step_description": "在 `monitoringAlerting.ts` 中，定义一个接口，用于将 `src/interfaces/monitoring/monitoring.ts` 中收集到的指标上报给外部监控系统（如 Prometheus, Datadog）。"
    },
    {
      "step_id": 256,
      "step_name": "定义告警触发条件（概念）",
      "step_description": "在 `monitoringAlerting.ts` 或配置文件中，定义基于指标（如错误率超过阈值）或特定日志事件触发告警的规则。"
    },
    {
      "step_id": 257,
      "step_name": "规划维护计划文档",
      "step_description": "在 `src/deployment/maintenance` 目录下创建文件 `maintenancePlan.ts`（或作为文档）。"
    },
    {
      "step_id": 258,
      "step_name": "在文档中包含定期更新建议",
      "step_description": "在项目文档中，明确建议定期更新 Vue, Tailwind, TypeScript 以及其他项目依赖，并说明更新的重要性。"
    },
    {
      "step_id": 259,
      "step_name": "在文档中说明长周期支持的注意事项",
      "step_description": "在文档中提醒维护者，生成器优先使用稳定特性，但仍需关注官方发布说明，避免使用即将废弃的功能，并说明如何处理依赖更新带来的潜在兼容性问题。"
    },
    {
      "step_id": 260,
      "step_name": "提交部署与维护相关代码和文档到 Git",
      "step_description": "执行 `git add src/deployment src/generators/templates/cicd`，`git commit -m 'feat: plan deployment and maintenance (cicd, monitoring, plan)'`。"
    },
    {
      "step_id": 261,
      "step_name": "细化 Tailwind 命名约定实现",
      "step_description": "编写代码，解析输入的模板结构或组件定义，并根据1.1节规范为通过 `@apply` 组合的样式生成符合 BEM 约定的类名，例如 `card__title`, `button--primary`。"
    },
    {
      "step_id": 262,
      "step_name": "在生成过程中应用细化的命名约定规则",
      "step_description": "修改样式生成逻辑，确保 `@apply` 产生的类名严格遵守细化的命名约定规范。"
    },
    {
      "step_id": 263,
      "step_name": "为命名约定编写校验规则",
      "step_description": "在 `src/core/validator/specValidator.ts` 中添加针对 `@apply` 类名是否符合命名约定的校验逻辑。"
    },
    {
      "step_id": 264,
      "step_name": "为命名约定编写自动化测试用例",
      "step_description": "在 `src/quality/testing/normVerification.test.ts` 中，编写测试用例，输入包含 `@apply` 的 CSS 或 Vue `<style>` 块，断言生成的类名是否符合预期或校验器是否能检测出不合规范的类名。"
    },
    {
      "step_id": 265,
      "step_name": "细化自定义 Tailwind 主题配置应用",
      "step_description": "编写代码，确保在生成 Tailwind 类时，优先使用主题配置中定义的 Token，例如 `bg-primary`, `text-sm`, `p-4`。"
    },
    {
      "step_id": 266,
      "step_name": "实现主题 Token 到 Tailwind 类名的映射查找",
      "step_description": "构建一个查找表或函数，将设计系统 Token 或用户输入的语义化样式描述（如 'Primary Color', 'Small Text', 'Medium Padding'）映射到正确的 Tailwind Token 类（如 `bg-primary`, `text-sm`, `p-4`）。"
    },
    {
      "step_id": 267,
      "step_name": "在样式生成逻辑中强制使用主题 Token 类",
      "step_description": "修改样式生成逻辑，使其在可能的情况下强制使用主题 Token 类，避免生成硬编码的 CSS 值。"
    },
    {
      "step_id": 268,
      "step_name": "为主题配置应用编写校验规则",
      "step_description": "在 `src/core/validator/specValidator.ts` 中添加校验逻辑，检查生成的代码是否使用了硬编码的样式值而不是主题 Token 类。"
    },
    {
      "step_id": 269,
      "step_name": "为主题配置应用编写自动化测试用例",
      "step_description": "在测试中，输入包含语义化样式需求的描述，断言生成的 HTML/CSS 是否使用了正确的主题 Token 类。"
    },
    {
      "step_id": 270,
      "step_name": "细化 Tailwind 扩展功能实现",
      "step_description": "编写代码，处理用户输入中需要自定义 CSS 或 `@apply` 组合样式的场景，并确保这些样式被放置在 `<style scoped>` 块中，并使用 `@layer` 指令组织。"
    },
    {
      "step_id": 271,
      "step_name": "实现 `@layer` 指令的代码生成",
      "step_description": "修改样式生成逻辑，使其能够根据用户输入或内部规则，为生成的 `@apply` 规则添加正确的 `@layer components` 或 `@layer utilities` 前缀。"
    },
    {
      "step_id": 272,
      "step_name": "为 `@layer` 指令使用编写校验规则",
      "step_description": "在 `src/core/validator/specValidator.ts` 中添加校验逻辑，检查 `@apply` 规则是否使用了正确的 `@layer` 指令，或者是否在 `<style scoped>` 块外生成了全局样式。"
    },
    {
      "step_id": 273,
      "step_name": "为 `@layer` 指令使用编写自动化测试用例",
      "step_description": "编写测试，输入需要自定义样式的需求，断言生成的 `<style scoped>` 块中 `@apply` 规则是否正确使用了 `@layer` 指令。"
    },
    {
      "step_id": 274,
      "step_name": "细化 Tailwind 响应式设计实现",
      "step_description": "编写代码，解析用户输入中对不同断点下布局或样式行为的需求，并将其转换为正确的 Tailwind 响应式类组合（如 `md:flex lg:grid`）。"
    },
    {
      "step_id": 275,
      "step_name": "实现响应式规则应用逻辑",
      "step_description": "修改布局和样式生成逻辑，使其能够根据用户指定的断点需求或默认的移动优先规则，为元素添加响应式前缀的 Tailwind 类。"
    },
    {
      "step_id": 276,
      "step_name": "为响应式设计编写校验规则",
      "step_description": "在 `src/core/validator/specValidator.ts` 中添加校验逻辑，检查生成的代码是否正确应用了响应式前缀，例如是否使用了移动优先策略，或者是否为所有指定断点生成了样式。"
    },
    {
      "step_id": 277,
      "step_name": "为响应式设计编写自动化测试用例",
      "step_description": "编写测试，输入包含响应式需求的描述，断言生成的 HTML 元素是否具有正确的响应式 Tailwind 类。"
    },
    {
      "step_id": 278,
      "step_name": "细化 Tailwind 样式复用与优化实现",
      "step_description": "编写代码，识别生成过程中重复出现的 Tailwind 类组合，并在满足条件时，建议或自动将其提取到 `@apply` 类中。"
    },
    {
      "step_id": 279,
      "step_name": "实现重复样式识别逻辑",
      "step_description": "开发一个算法，分析生成的 HTML 模板中元素的 Tailwind 类列表，识别重复次数超过阈值的类组合。"
    },
    {
      "step_id": 280,
      "step_name": "实现将重复样式提取为 `@apply` 类并替换引用的逻辑",
      "step_description": "如果识别到重复样式，生成新的 `@apply` 规则并添加到 `<style scoped>` 块中，然后修改 HTML 模板，将原始的原子类组合替换为新的 `@apply` 类名。"
    },
    {
      "step_id": 281,
      "step_name": "在生成过程中应用样式复用优化",
      "step_description": "将样式复用识别和提取逻辑集成到样式生成和模板生成步骤中。"
    },
    {
      "step_id": 282,
      "step_name": "为样式复用与优化编写校验规则",
      "step_description": "在 `src/core/validator/specValidator.ts` 中添加校验逻辑，检查是否存在大量重复的 Tailwind 类组合而未被提取为 `@apply` 类（作为警告），或者检查 `@apply` 的使用是否符合规范。"
    },
    {
      "step_id": 283,
      "step_name": "为样式复用与优化编写自动化测试用例",
      "step_description": "编写测试，输入会产生重复样式输出的需求，断言生成器是否正确地提取了 `@apply` 类，或者校验器是否报告了重复样式警告。"
    },
    {
      "step_id": 284,
      "step_name": "细化 Composition API 使用实现",
      "step_description": "编写代码，确保生成的 `<script setup>` 块中只包含 Composition API 函数和变量声明，严格禁止 Options API 语法。"
    },
    {
      "step_id": 285,
      "step_name": "实现 Options API 语法检测",
      "step_description": "在语法校验器 (`syntaxValidator.ts`) 中配置 ESLint 规则或使用 AST 解析，检测 Vue 文件中是否存在 `data()`, `methods: {}` 等 Options API 语法。"
    },
    {
      "step_id": 286,
      "step_name": "为 Composition API 使用编写校验规则",
      "step_description": "在 `src/core/validator/specValidator.ts` 中添加校验逻辑，强制要求所有组件逻辑都在 `<script setup>` 中实现。"
    },
    {
      "step_id": 287,
      "step_name": "为 Composition API 使用编写自动化测试用例",
      "step_description": "编写测试，输入描述组件逻辑的需求，断言生成的代码是否完全使用了 Composition API，并且 Options API 检测器是否能检测到违规代码（在负面测试中）。"
    },
    {
      "step_id": 288,
      "step_name": "细化响应式引用 (ref/reactive) 实现",
      "step_description": "编写代码，根据用户输入的 state 定义，生成使用 `ref()` 或 `reactive()` 初始化的响应式变量，并确保在 `<script setup>` 中正确使用 `.value` 访问 `ref`。"
    },
    {
      "step_id": 289,
      "step_name": "实现 `ref` 和 `reactive` 的选择逻辑",
      "step_description": "根据输入的 state 类型（基本类型 vs 对象/数组）自动选择使用 `ref` 或 `reactive` 进行初始化。"
    },
    {
      "step_id": 290,
      "step_name": "在代码生成时处理 `ref` 的 `.value` 访问",
      "step_description": "修改逻辑代码生成器，确保当引用 `ref` 定义的响应式变量时，在 JavaScript/TypeScript 代码中总是添加 `.value` 后缀，但在模板中则不加。"
    },
    {
      "step_id": 291,
      "step_name": "为响应式引用使用编写校验规则",
      "step_description": "在 `src/core/validator/specValidator.ts` 中添加校验逻辑，检查是否正确使用了 `ref` 和 `reactive`，以及 `ref` 在 `<script setup>` 中是否正确使用了 `.value`。"
    },
    {
      "step_id": 292,
      "step_name": "为响应式引用使用编写自动化测试用例",
      "step_description": "编写测试，输入包含不同类型状态的需求，断言生成的代码是否使用了正确的响应式引用类型，以及 `.value` 访问是否正确。"
    },
    {
      "step_id": 293,
      "step_name": "细化函数式组件生成实现",
      "step_description": "编写代码，识别用户输入中描述的无状态、纯展示性组件，并生成简单的函数导出形式的组件代码。"
    },
    {
      "step_id": 294,
      "step_name": "实现函数式组件识别规则",
      "step_description": "定义规则，根据输入的组件描述（例如，没有 state, methods, lifecycle hooks 定义）来判断组件是否适合生成为函数式组件。"
    },
    {
      "step_id": 295,
      "step_name": "生成函数式组件代码模板",
      "step_description": "创建函数式组件的模板文件（`.vue.hbs`），其 `<script setup>` 块只包含 `defineProps` 和一个简单的函数导出。"
    },
    {
      "step_id": 296,
      "step_name": "为函数式组件生成编写校验规则",
      "step_description": "在 `src/core/validator/specValidator.ts` 中添加校验逻辑，检查标记为函数式组件的输出是否确实没有包含不应有的状态或逻辑。"
    },
    {
      "step_id": 297,
      "step_name": "为函数式组件生成编写自动化测试用例",
      "step_description": "编写测试，输入描述纯展示性组件的需求，断言生成的代码是否为函数式组件，并且其渲染输出是否正确。"
    },
    {
      "step_id": 298,
      "step_name": "细化 Hooks 管理实现",
      "step_description": "编写代码，识别用户输入中可复用的逻辑片段（例如，数据 fetching, 表单处理），并将其提取生成为独立的自定义 Hook 文件。"
    },
    {
      "step_id": 299,
      "step_name": "实现可复用逻辑模式识别",
      "step_description": "开发模式识别算法，分析输入的逻辑描述（方法、状态、副作用组合），识别常见 Hook 模式。"
    },
    {
      "step_id": 300,
      "step_name": "生成自定义 Hook 代码模板",
      "step_description": "创建自定义 Hook 的模板文件（`.ts.hbs`），包含使用 Composition API 函数的骨架。"
    },
    {
      "step_id": 301,
      "step

‍