Fe Cli

核心用法

fe-cli 是一个智能路由型脚手架工具，作为 6 种前端项目类型的统一入口（Web SPA、后台管理、移动 H5、Electron 桌面端、SSR、小程序）。用户可通过一句话快速启动（如"初始化 React + Tailwind + Zustand 后台项目 my-admin"），或进入交互模式逐步配置。

类型识别后自动路由至子技能（fe-cli-admin/fe-cli-h5 等），生成类型专属文件的同时，注入标准化共享公共层：

• 工程化配置：Vite + TypeScript + ESLint + Prettier，pnpm 强制锁定
• 请求与日志：原生 fetch 封装（非 axios）、结构化日志系统（分级/轮转/持久化）、日志导出与上报
• 样式体系：Sass (SCSS) + CSS 变量 + design tokens + 响应式断点规范
• 工具库：storage/format/validate 等高频工具函数
• AI 可读文档：自动生成 .ai/PROJECT.md，便于后续 AI 代理快速理解项目

显著优点

1. 标准化与一致性：强制 @/ 路径别名、统一的环境变量文件、Logger.child("Module") 模式，消除团队项目间的配置漂移
2. 技术栈覆盖全面：从 SPA 到 SSR 到小程序，覆盖主流前端场景，技术组合灵活（React/Vue × Tailwind/Ant Design/MUI × Zustand/Redux）
3. 防御性设计：完善的降级策略（网络失败、版本不存在、目录冲突等）、输入澄清机制（矛盾请求、越界请求自动拦截）
4. AI 友好：自动生成结构化的项目文档，降低后续 AI 辅助开发的上下文成本
5. 日志与可观测性：内置生产级日志系统，支持分级、自动清理、导出，弥补多数脚手架的空白

潜在缺点与局限性

• 技术栈锁定：强制 pnpm + Sass + fetch，axios/styled-components 等偏好需手动调整
• Node 版本门槛：目标 Node 18+，老旧环境需升级
• 子技能依赖：核心能力分散在子技能中，单一文件无法完整运行，需配合 fe-cli-* 系列使用
• Electron 特殊处理：主进程需单独 tsc 编译，增加认知负担（文档已明确标注）
• 部署环节缺失：明确拒绝部署相关请求，CI/CD 需额外工具链

适合人群

• 团队技术负责人：需要统一多项目工程规范、降低新人 onboarding 成本
• 全栈开发者：频繁切换 React/Vue/Next.js/Electron 多种项目类型
• AI 辅助开发用户：依赖 AI 代码生成，需要结构化项目上下文
• 中后台/企业级应用开发者：对日志、环境管理、类型安全有硬性要求

常规风险

• 版本漂移风险：模板引用的包版本可能不存在，需关注 references/ 下模板文件的维护
• pnpm 生态依赖：国内网络环境需配置镜像，否则安装失败率高
• 日志持久化：生产环境日志上报端点为占位符（TBD），需自行接入监控平台
• 覆盖操作风险：目标目录已存在时提供"覆盖"选项，误操作可能导致数据丢失

安全与来源评估

• 来源可信度：T2（GitHub 开源项目，有明确版本号 1.1.0 和主页，但未提供作者身份验证）
• 安全等级：S（纯本地 CLI 工具，无网络请求、无敏感权限、无代码注入风险；生成代码遵循标准开源模式）

核心用法

fe-cli 是一款面向现代前端开发的智能脚手架 CLI，作为统一入口支持 6 种主流项目类型：Web SPA、后台管理（Admin）、移动 H5、Electron 桌面端、SSR（Next.js/Nuxt）以及小程序（微信/Taro）。用户可通过自然语言指令快速触发——无论是精确指定技术栈的"一句话启动"模式（如"初始化 React + Tailwind + Zustand 后台项目 my-admin"），还是模糊的"新建前端项目"交互式引导，系统均能智能识别项目类型并路由至专属子技能完成深度定制。

该技能的核心工作流程包含三层：类型识别层（关键词匹配与歧义澄清）、子技能路由层（读取 fe-cli-admin/h5/electron 等子技能配置）、共享公共层生成（统一输出 services、styles、utils、types 等标准化目录）。生成的项目严格遵循既定技术规范：强制使用 pnpm 作为包管理器、Sass 作为 CSS 预处理器、@/ 路径别名、原生 fetch 请求封装、结构化日志系统（含 5MB 自动清理与分级输出），以及完整的多环境配置（.env.development/test/production）。

此外，fe-cli 具备"项目审查"能力——可针对已有前端工程执行规范性检查，输出包含 ✅ 符合项、❌ 缺失项、⚠️ 建议项的三段式审计报告，并生成 .ai/PROJECT.md 供 AI 代理快速理解项目架构。

显著优点

1. 技术栈覆盖全面：单工具覆盖 React/Vue/Next.js + Tailwind/Ant Design/MUI + Zustand/Redux + i18n 全组合，满足从简单官网到复杂后台、从移动端小程序到桌面端 Electron 的多元化场景。

2. 工程规范标准化：强制输出企业级目录结构、统一请求封装（fetch wrapper 替代 axios）、设计令牌管理、TypeScript 严格配置、ESLint/Prettier 集成，从源头规避"千人千面"的代码风格问题。

3. 开发者体验优化：支持"一句话启动"跳过交互、智能降级策略（网络失败时提示手动命令/镜像切换）、目录冲突处理（覆盖/合并/取消），以及为 AI 代理设计的项目自描述文档。

4. 可维护性设计：内置结构化日志与导出能力、多环境脚本分离（dev:dev/test/build:prod）、类型检查独立脚本，为 CI/CD 集成与线上问题排查预留充分空间。

潜在缺点与局限性

1. 技术栈锁定效应：强制使用 pnpm、Sass、Vite 特定版本及原生 fetch，对于习惯 yarn/npm、Less/PostCSS、Webpack 或 axios 的开发者存在迁移成本。

2. 子技能依赖复杂：核心功能分散于 6 个子技能目录，需保证子技能 SKILL.md 与共享模板（references/shared-base.md 等）的版本同步，维护链条较长。

3. 日志上报待完善：log-export.ts 中的上报端点为占位符（TBD），生产环境需开发者手动配置，存在"半成品"体验。

4. Electron 特殊处理：主进程需独立 tsconfig.electron.json 与 tsc 编译，与渲染层的 Vite 处理逻辑分叉，增加心智负担。

适合的目标群体

• 前端团队 Tech Lead：需要快速统一团队脚手架规范、降低新项目启动成本
• 全栈开发者/独立开发者：追求开箱即用的工程配置，不愿在工具链选型上消耗时间
• 教学/培训场景：标准化项目结构便于学员理解现代前端工程化最佳实践
• 已有项目治理：需要对遗留代码库进行规范性审查与渐进式改造

使用风险

1. T3 来源可信度：技能由个人开发者（z-Zihan）维护，无知名企业/基金会背书，版本更新与长期维护依赖社区贡献，建议生产环境使用前行人工代码审查。

2. 依赖供应链风险：生成的项目依赖 npm 生态，建议定期执行 pnpm audit 并配置 Dependabot/Renovate 自动化更新，警惕 typosquatting 攻击。

3. 环境变量泄露风险：多环境配置文件（.env.*）若误提交至版本控制可能导致密钥泄露，需确保 .gitignore 配置正确并配合 .env.local 本地敏感配置。

4. 日志敏感信息风险：开发者需在日志上报前自行脱敏，避免记录用户密码、Token、PII 等敏感数据。

5. Node 版本兼容性：目标 Node 18+，旧环境需升级，Electron 主进程编译逻辑特殊需额外关注。