核心用法
Feature Forge 是一款面向 Next.js App Router 生态的智能代码生成技能，专为使用 Supabase、Firebase Auth、Tailwind CSS 和 TypeScript 的全栈项目设计。用户只需用自然语言描述所需功能，该技能即可自主完成从需求分析到代码交付的完整垂直切片开发。
其工作流程严格遵循七步规划协议：首先深度理解用户请求，将功能拆解为 UI 层、数据层、业务逻辑和权限控制四个维度；随后全面扫描现有代码库，确保新生成的代码与既有架构风格保持一致；接着制定详细的执行计划，按依赖顺序（schema → 数据访问层 → API 路由 → UI 组件 → 测试）逐步实施；每完成一个文件即进行编译验证，最终通过完整测试套件并提交规范化的 Git 提交。
具体技术实现涵盖：SQL 迁移文件与 RLS 策略生成、类型安全的 Supabase 客户端封装、Zod 校验的 API 路由、Server/Client 组件分离的页面架构、Server Actions 表单处理，以及基于 Vitest 的单元测试。所有输出均遵循 TypeScript 严格模式、命名导出、Tailwind 独占样式等代码规范。
显著优点
1. 端到端自动化：区别于单一层的代码补全工具，Feature Forge 覆盖数据库 Schema、数据访问层、API 路由、前端组件和测试用例的全链路生成，实现真正的"所想即所得"。
2. 架构一致性保障：强制性的规划协议要求先调研现有代码模式，有效避免技术债积累，确保新功能与既有代码库无缝融合。
3. 生产级代码质量：内置严格的类型安全策略（禁用 any）、Zod 运行时校验、RLS 权限控制、错误边界和加载状态处理，输出代码可直接用于生产环境。
4. 现代技术栈深度整合：对 Next.js App Router、Server Components/Actions、Supabase 实时订阅等前沿特性有原生支持，而非简单模板拼接。
5. 渐进式验证机制：每个文件生成后即执行类型检查，阻断错误向下游传播，大幅降低调试成本。
潜在缺点与局限性
1. 技术栈锁定：专为 Next.js + Supabase + Tailwind + TypeScript 组合优化，若项目使用 Prisma、GraphQL、Vue 或其他后端服务，需大量人工调整。
2. 复杂业务逻辑边界：对于涉及多表事务、分布式锁、异步工作流等复杂场景，生成的代码骨架仍需开发者填充核心算法。
3. 无运行时 API 调用：该技能仅生成源代码文件，不执行实际数据库操作或外部 API 调用，无法验证生成的 SQL 迁移是否能在真实数据库运行。
4. 设计决策依赖输入质量：若用户描述模糊，生成的 UI 可能过于通用；虽有一次澄清机制，但无法替代产品经理的详细 PRD。
5. 大规模重构风险：对现有 Schema 的破坏性变更（如列类型修改、表删除）需人工评估数据迁移策略，技能本身不处理数据备份与恢复。
适合的目标群体
- 全栈开发者：希望加速 CRUD 功能开发，将精力聚焦于核心业务逻辑
- 技术负责人：需要快速搭建 MVP 或演示原型，同时保持代码规范统一
- Next.js 迁移团队：从 Pages Router 向 App Router 迁移时，需要符合新架构范式的代码生成参考
- 初创公司技术团队：人员配置紧张，需要一人覆盖前后端数据库多角色的场景
- 教育场景：作为全栈开发最佳实践的活教材，学习现代 React 生态的工程化标准
使用风险
1. 依赖项版本冲突：生成的代码假设特定版本的 Next.js、Supabase-js、Zod 等库 API 存在，若项目版本落后或超前，可能出现类型不匹配。
2. 环境变量配置遗漏：技能生成代码引用 NEXT_PUBLIC_SUPABASE_URL 等变量，但不会自动创建或验证 .env.local 文件，运行时可能因变量缺失报错。
3. RLS 策略过度宽松风险：若用户描述未明确权限要求，生成的 RLS 策略可能默认允许所有认证用户访问，需人工审计生产环境权限。
4. 测试覆盖盲区：自动生成的测试主要覆盖 Schema 校验和基础 CRUD，对边界条件、并发场景、降级逻辑等仍需人工补充。
5. Git 历史污染：建议用户审查生成的提交信息，避免自动生成的"feat: add xxx"提交混入不符合团队规范的提交历史。