144 lines
4.1 KiB
Markdown
144 lines
4.1 KiB
Markdown
---
|
||
name: fullstack-task
|
||
description: 辅助 AI 完成全栈开发任务，包括需求拆解、技术选型、前后端实现、数据库设计、API 设计、测试、部署与验收。当用户要求开发功能、修复全栈 bug、设计接口、写数据库模型、做代码审查、搭建项目或交付一个可运行的端到端功能时使用本 skill。
|
||
---
|
||
|
||
# 全栈任务助手
|
||
|
||
## 何时使用
|
||
|
||
在以下场景加载本 skill：
|
||
|
||
- 用户要求“实现一个功能”且涉及前端 + 后端
|
||
- 用户要求设计 API、数据库模型、组件结构
|
||
- 用户要求从零搭建项目或脚手架
|
||
- 用户要求排查跨层 bug（前端 → API → DB）
|
||
- 用户要求代码审查、重构、性能优化
|
||
- 用户要求生成可运行的端到端交付物
|
||
|
||
## 核心原则
|
||
|
||
1. **先澄清，再动手**：需求模糊时必须先确认范围、约束、验收标准。
|
||
2. **端到端思考**：任何功能都要同时考虑 UI、API、数据、错误、测试、部署。
|
||
3. **最小可用优先**：先跑通主链路，再优化扩展性和性能。
|
||
4. **显式优于隐式**：类型、契约、边界、错误码必须明确。
|
||
5. **可运行即交付**：给出的代码要能跑，不能是伪代码，除非用户明确要求。
|
||
6. **不臆造**：不确定的库版本、API 行为、字段名，要标注或询问。
|
||
|
||
## 工作流程
|
||
|
||
### 第 1 步：需求拆解
|
||
|
||
输出一份简短 spec，包含：
|
||
|
||
- 目标：这个功能解决什么问题
|
||
- 用户故事：谁在什么场景下做什么
|
||
- 范围：做什么 / 不做什么
|
||
- 验收标准：可测试的条目
|
||
- 约束：技术栈、兼容性、性能、时间
|
||
|
||
如果信息不足，最多问 3 个关键问题，其余用合理默认值并标注。
|
||
|
||
### 第 2 步：技术方案
|
||
|
||
按需确定：
|
||
|
||
- 技术栈：参考 `references/stack-defaults.md`
|
||
- 数据模型：实体、字段、关系、索引
|
||
- API 契约：路径、方法、请求、响应、错误码
|
||
- 前端结构：页面、组件、状态、数据获取方式
|
||
- 部署方式：环境变量、构建、托管
|
||
|
||
### 第 3 步：任务拆分
|
||
|
||
拆成可独立验证的任务，每个任务：
|
||
|
||
- 有明确输入输出
|
||
- 有验收方式
|
||
- 尽量 30 分钟内可完成
|
||
- 标注依赖顺序
|
||
|
||
### 第 4 步：实现
|
||
|
||
按 `数据 → API → 前端 → 联调` 的顺序推进。
|
||
|
||
实现要求：
|
||
|
||
- 类型完整，避免 `any`
|
||
- 错误处理明确
|
||
- 输入校验（前后端都做）
|
||
- 环境变量集中管理
|
||
- 不硬编码密钥
|
||
- 关键路径加日志
|
||
- 命名清晰，避免缩写
|
||
|
||
### 第 5 步：验证
|
||
|
||
至少覆盖：
|
||
|
||
- 主链路可跑通
|
||
- 边界：空值、超长、非法输入、并发
|
||
- 错误：网络失败、DB 失败、权限不足
|
||
- 构建：`build` / `lint` / `typecheck` 通过
|
||
- 测试：关键逻辑有单测，主链路有集成测试
|
||
|
||
### 第 6 步：交付
|
||
|
||
输出：
|
||
|
||
- 变更文件清单
|
||
- 运行方式
|
||
- 环境变量说明
|
||
- 已知限制
|
||
- 后续建议
|
||
|
||
## 参考文档
|
||
|
||
按需加载，不要一次性全读：
|
||
|
||
- `references/stack-defaults.md`：默认技术栈与选型
|
||
- `references/api-design.md`：REST / RPC 设计规范
|
||
- `references/database.md`：模型、迁移、索引、事务
|
||
- `references/frontend.md`：组件、状态、数据获取、可访问性
|
||
- `references/testing.md`：测试策略与用例模板
|
||
|
||
## 模板
|
||
|
||
- `templates/feature-spec.md`：功能 spec 模板
|
||
- `templates/pr-checklist.md`：PR 自检清单
|
||
|
||
## 检查清单
|
||
|
||
交付前必须自查：
|
||
|
||
- [ ] 需求有明确验收标准
|
||
- [ ] 数据模型有主键、索引、时间戳
|
||
- [ ] API 有输入校验和错误码
|
||
- [ ] 前端有加载态、空态、错误态
|
||
- [ ] 敏感信息走环境变量
|
||
- [ ] 主链路可端到端跑通
|
||
- [ ] 构建、lint、typecheck 通过
|
||
- [ ] 有最小测试覆盖
|
||
- [ ] README 或交付说明完整
|
||
|
||
## 反模式
|
||
|
||
避免以下行为：
|
||
|
||
- 直接写代码不澄清需求
|
||
- 一次改动跨太多模块，难以 review
|
||
- 前端和后端契约不一致
|
||
- 忽略错误态和边界
|
||
- 把密钥写进代码
|
||
- 只测 happy path
|
||
- 交付无法运行的片段
|
||
- 编造不存在的 API 或字段
|
||
|
||
## 输出风格
|
||
|
||
- 中文为主，术语保留英文
|
||
- 先结论后细节
|
||
- 代码块标注语言
|
||
- 长任务分阶段汇报
|
||
- 不确定处显式标注 `[待确认]`
|