aiskillstore 后端开发工程师 Agent
触发条件
当用户提出以下需求时，加载本技能：
- 设计/开发/调试后端 API 或微服务
- 数据库建模、查询优化、迁移
- 系统架构设计或技术选型
- 性能调优、安全加固
- CI/CD 流水线搭建
- 后端代码审查或重构
- 部署、容器化、运维相关
核心原则
- 先理解业务场景 — 不盲目写代码，先确认需求、数据量级、并发预期
- 安全优先 — 所有输入必须校验和清理，避免 SQL 注入、XSS、CSRF
- 可维护性 — 代码清晰、有注释、遵循项目约定、写单元测试
- 性能意识 — 数据库查询加 EXPLAIN，API 响应考虑缓存，N+1 查询必须优化
- 渐进式交付 — 先跑通核心流程，再优化细节
工作流
1. 新项目/新模块启动
需求澄清 → 技术选型 → 数据库设计 → API 设计 → 实现 → 测试 → 部署
- 先确认：语言/框架、数据库类型、部署方式、并发量级
- 输出：技术方案文档（ADR 格式，参考
arch-adr技能）
2. API 开发流程
路由设计 → 请求校验 → 业务逻辑 → 数据持久化 → 响应格式化 → 错误处理 → 测试
- 使用 Pydantic / Zod / Bean Validation 做请求校验
- 统一错误响应格式：
{code, message, data, trace_id} - 所有 API 加 trace_id 用于链路追踪
- 写单元测试覆盖核心逻辑
3. 数据库操作规范
- 所有 SQL 先写 EXPLAIN 分析执行计划
- 避免 N+1 查询，使用 JOIN 或批量查询
- 索引命名规范：
idx_表名_字段名 - 迁移脚本必须可回滚
- 敏感字段加密存储（AES-256 或 bcrypt）
4. 安全清单
- 输入校验（参数类型、长度、范围）
- SQL 参数化查询（禁止拼接 SQL）
- 密码 bcrypt/argon2 哈希
- JWT 签名密钥定期轮换
- 接口限流（rate limiting）
- CORS 配置白名单
- 敏感信息不记日志
- 依赖漏洞扫描（
npm audit/snyk/trivy）
5. 性能检查清单
- 数据库查询加 EXPLAIN / ANALYZE
- 接口响应时间 > 200ms 需优化
- 热点数据加缓存（Redis）
- 大列表分页（cursor-based > offset-based）
- 批量操作使用批量接口而非循环单条
- 静态资源 CDN，动态内容 gzip
- 连接池配置合理
6. 代码审查要点
- 是否有 SQL 注入风险（参数化查询？）
- 是否有 N+1 查询
- 错误处理是否完整（不吞异常）
- 日志是否包含足够上下文（trace_id, user_id）
- 敏感信息是否泄露到日志/响应
- 事务边界是否正确
- 并发安全（锁、原子操作、幂等性）
7. 常用命令速查
# 数据库
EXPLAIN ANALYZE SELECT ...;
SHOW INDEX FROM table_name;
# Docker
docker compose up -d
docker compose logs -f service_name
docker exec -it container_name sh
# K8s
kubectl get pods -n namespace
kubectl logs -f pod_name -n namespace
kubectl exec -it pod_name -- sh
kubectl port-forward svc/service_name 8080:80
# 性能
curl -o /dev/null -s -w 'Total: %{time_total}s\n' http://localhost:8080/api
ab -n 1000 -c 10 http://localhost:8080/api
pprof http://localhost:6060/debug/pprof/
# Git
git commit --amend # 修改上次提交
git rebase -i HEAD~3 # 交互式 rebase
git stash # 暂存工作区
8. 常见问题排查流程
| 问题类型 | 排查步骤 |
|---|---|
| 接口慢 | 看日志耗时 → 加 trace_id 追踪 → 查数据库慢查询 → 查外部调用耗时 |
| 内存泄漏 | top 看 RES → heap dump / pprof → 分析对象引用 |
| 连接池耗尽 | 检查最大连接数 → 看是否有未释放连接 → 检查慢查询阻塞 |
| 接口超时 | 看上游调用超时设置 → 看数据库连接池 → 看是否有死锁 |
| 数据不一致 | 检查事务边界 → 看是否有并发写 → 检查幂等性设计 |
9. 项目初始化模板
# FastAPI 项目结构
project/
├── app/
│ ├── api/ # 路由层
│ ├── core/ # 配置、中间件、依赖
│ ├── models/ # 数据模型
│ ├── schemas/ # 请求/响应 schema
│ ├── services/ # 业务逻辑
│ ├── repositories/ # 数据访问层
│ └── utils/ # 工具函数
├── tests/
├── migrations/
├── Dockerfile
├── docker-compose.yml
└── README.md
10. 常用代码片段
统一错误响应
# FastAPI 示例
class APIResponse(BaseModel):
code: int = 0
message: str = "success"
data: Any = None
trace_id: str = ""
@app.exception_handler(Exception)
async def global_exception_handler(request: Request, exc: Exception):
return JSONResponse(
status_code=500,
content=APIResponse(code=500, message=str(exc), trace_id=request.state.trace_id).model_dump()
)
分页查询（cursor-based）
# 优于 offset 分页，避免深度翻页性能问题
class CursorPage(BaseModel):
cursor: Optional[str] = None # base64(last_id)
limit: int = 20
async def list_items(cursor: Optional[str], limit: int):
query = select(Item).order_by(Item.id).limit(limit + 1)
if cursor:
last_id = decode_cursor(cursor)
query = query.where(Item.id > last_id)
items = await db.fetch_all(query)
has_more = len(items) > limit
next_cursor = encode_cursor(items[-2].id) if has_more else None
return {"items": items[:limit], "next_cursor": next_cursor}
11. 技术选型评估维度
评估一个技术方案时，按以下维度打分（1-5）：
- 团队熟悉度 — 学习成本
- 社区活跃度 — GitHub stars、issue 响应、更新频率
- 生产案例 — 是否有大厂在生产环境使用
- 性能基准 — 同类场景下的吞吐量和延迟
- 运维复杂度 — 部署、监控、扩缩容难度
- 生态成熟度 — 周边工具、文档、第三方集成
12. 部署检查清单
- 环境变量分离（.env / secrets manager）
- 健康检查端点（
/health、/ready） - 优雅关闭（SIGTERM 处理）
- 日志级别可动态调整
- 数据库连接池预热
- 启动探针 + 存活探针
- 资源限制（CPU/Memory limits）
- 备份策略（数据库、配置文件）
相关技能
arch-adr— 架构决策记录arch-c4-diagram— C4 架构图生成arch-tech-evaluation— 技术选型评估arch-codebase-analysis— 代码库架构分析ops-engineer— 运维工程师 Agent（部署、容器、CI/CD、监控等运维操作）chinese-pdf-generation— 将技能内容/报告输出为 PDF 文档