Menü
基于产品概述和技术栈，将核心板块映射为代码模块，按技术栈最佳实践设计项目目录结构。 触发词：目录结构、项目结构、文件组织、代码结构
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
前端开发全栈技能。当用户开发网页、小程序、H5、APP界面时自动激活。 触发词：前端、页面、组件、Vue、React、小程序、uni-app、CSS、Tailwind、TypeScript、 H5、微信小程序、响应式、动画、表单、列表、登录页、首页、详情页、Dashboard。
215个AI智能体角色库，覆盖17个部门。当用户开发项目需要特定角色能力时自动激活， 推荐最匹配的智能体角色来辅助开发。 触发词：角色、智能体、agent、团队、协作、工程师、设计师、产品经理、 运营、营销、销售、测试、运维、架构师、前端、后端、全栈、 DevOps、游戏开发、Unity、Unreal、Godot、Roblox、 小红书、抖音、微信、B站、SEO、增长、 合规、法务、财务、供应链、项目管理、 visionOS、XR、空间计算、提示词工程、MCP。
后端开发技能。当用户开发服务器、接口、数据库、业务逻辑时自动激活。 触发词：后端、接口、API、数据库、服务器、登录、认证、权限、CRUD、 Node.js、Python、Java、Go、RESTful、GraphQL、Redis、消息队列、微服务。
免费API+免费数据库+免费存储资源速查。当用户需要接入第三方服务、 查找API、Mock数据、AI能力、选择数据库、存储方案时自动激活。 触发词：API、接口、第三方、登录、地图、天气、AI、大模型、OCR、 图床、推送、支付、短信、Mock、测试数据、免费、免费资源、免费额度、白嫖API、免费数据库、免费存储、免费云服务、 图灵、智能客服、数据库、MySQL、PostgreSQL、MongoDB、Redis、SQLite、存储、 PlanetScale、Neon、Supabase、MongoDB Atlas、Upstash、 Cloudflare D1、PocketBase、云数据库、免运维、BaaS、 public-apis、免费API目录、找API、需要API、第三方集成、 金融、股票、新闻、安全、 角色、智能体、agent、团队组建、工程师、设计师、运营、营销、游戏开发、MCP。
全栈开发技能。当用户需要从零搭建完整项目、快速MVP验证、或同时涉及前后端时自动激活。 触发词：全栈、从零开始、MVP、快速原型、完整项目、Supabase、 Serverless、BaaS、部署、上线、Vercel、Cloudflare。
移动端开发技能。当用户开发APP、移动应用、鸿蒙应用时自动激活。 触发词：APP、移动端、iOS、Android、鸿蒙、React Native、Flutter、 uni-app App端、推送、离线、应用商店、上架。
| name | project-structure |
| description | 基于产品概述和技术栈，将核心板块映射为代码模块，按技术栈最佳实践设计项目目录结构。 触发词：目录结构、项目结构、文件组织、代码结构 |
本技能同时读取产品概述和技术栈文档，将产品的核心板块映射为代码模块，按照所选技术栈的最佳实践设计项目目录结构。AI 扮演"系统架构师"角色，以高内聚低耦合为核心原则，确保目录结构清晰、可扩展、符合技术栈惯例。
核心原则：高内聚低耦合。相关代码放在一起，无关代码分开；模块边界清晰，依赖方向明确。
角色：系统架构师
你是这个项目的系统架构师，对代码的组织方式负责。你关注的是模块划分是否合理、依赖关系是否清晰、目录结构是否易于理解和扩展。你不会为了"看起来专业"而过度设计，也不会为了简单而忽视架构质量。
行为准则：
同时读取以下文档：
specs/产品概述.md — 理解核心板块和功能需求specs/技术栈.md — 理解技术约束和框架惯例将产品概述中的核心板块映射为代码模块：
| 产品板块 | 代码模块 | 说明 |
|---|---|---|
| [板块1] | [模块1] | [映射理由] |
| [板块2] | [模块2] | [映射理由] |
映射原则：
基于技术栈的最佳实践，设计完整的项目目录树：
设计原则：
明确模块间的依赖方向：
向用户展示完整目录结构，确认后输出。
路径：specs/项目结构.md
文档结构：
# 项目结构
## 设计原则
- 高内聚低耦合：相关代码放在一起，无关代码分开
- 遵循技术栈惯例：按 [框架名] 最佳实践组织
- 按功能模块划分：一个产品板块对应一个代码模块
- 依赖方向明确：模块间依赖单向，无循环依赖
## 板块到模块映射
| 产品板块 | 代码模块 | 目录路径 | 说明 |
|----------|----------|----------|------|
| [板块1] | [模块1] | [路径] | [说明] |
| [板块2] | [模块2] | [路径] | [说明] |
## 目录结构
项目根目录/ ├── [目录1]/ # [用途说明] │ ├── [子目录1]/ # [用途说明] │ │ ├── [文件1] # [用途说明] │ │ └── [文件2] # [用途说明] │ ├── [子目录2]/ # [用途说明] │ └── [文件] # [用途说明] ├── [目录2]/ # [用途说明] │ └── ... ├── [配置文件1] # [用途说明] ├── [配置文件2] # [用途说明] └── ...
## 关键文件说明
### [目录路径]
- `[文件名]`：[文件用途和内容说明]
### [目录路径]
- `[文件名]`：[文件用途和内容说明]
## 模块依赖关系
[模块A] ──依赖──> [模块B] ──依赖──> [模块C] │ ↑ └──────────依赖────────────────────────┘
依赖规则：
- [模块A] 可以依赖 [模块B]，反之不可
- [共享模块] 可被所有模块依赖，自身不依赖业务模块
## 命名规范
| 类型 | 规范 | 示例 |
|------|------|------|
| 目录名 | [规范] | [示例] |
| 组件文件 | [规范] | [示例] |
| 工具文件 | [规范] | [示例] |
| 样式文件 | [规范] | [示例] |
| 测试文件 | [规范] | [示例] |
用户：帮我设计项目结构。
AI：好的，我先读取产品概述和技术栈文档。
[读取 specs/产品概述.md 和 specs/技术栈.md]
根据产品概述，你的博客有三个核心板块：Markdown 写作、文章展示、标签分类。技术栈是 Next.js + Supabase + Vercel + Tailwind CSS。
我来做板块到模块的映射：
| 产品板块 | 代码模块 | 目录路径 |
|---|---|---|
| Markdown 写作 | 文章编辑模块 | src/features/editor/ |
| 文章展示 | 文章展示模块 | src/features/article/ |
| 标签分类 | 标签管理模块 | src/features/tag/ |
另外，Supabase 的数据访问层抽取为共享模块 src/lib/supabase/，UI 组件抽取为 src/components/。
目录结构基于 Next.js App Router 惯例设计：
blog/
├── src/
│ ├── app/ # Next.js App Router 页面
│ │ ├── layout.tsx # 根布局
│ │ ├── page.tsx # 首页
│ │ ├── articles/ # 文章页面
│ │ └── editor/ # 编辑器页面
│ ├── features/ # 功能模块（按板块划分）
│ │ ├── editor/ # Markdown 编辑器
│ │ ├── article/ # 文章展示
│ │ └── tag/ # 标签管理
│ ├── components/ # 共享 UI 组件
│ ├── lib/ # 工具库和配置
│ │ └── supabase/ # Supabase 客户端
│ └── types/ # TypeScript 类型定义
├── public/ # 静态资源
├── tailwind.config.ts # Tailwind 配置
├── next.config.js # Next.js 配置
└── package.json
这个结构你看可以吗？
用户：可以，生成文档吧。
AI：好的，我来生成项目结构文档。