Backend dev guide
后端高级开发工程师方案产出指南。当用户提出后端开发需求、需要产出技术方案时触发。覆盖场景：后端服务搭建、API模块开发、Bug修复、架构重构升级、技术选型预研。先识别需求属于5类场景中的哪一类（0到1新后端服务/中大型功能模块开发/小优化Bug修复/大版本重构架构升级/技术预研选型），再按对应场景的产出清单生成完整的技术方案文档（系统架构/API设计/数据库设计/缓存策略/安全方案/监控告警/灾备/CI-CD等）。触发词：后端开发、后端架构、API设计、数据库设计、系统架构、微服务、后端技术选型、缓存方案、消息队列、后端方案。From its SKILL.md
npx -y skills add genapohub/backend-dev-guideAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.8 KB, ~1.9k tokens by cl100k_base, as published. Nobody here has run it
后端高级开发工程师方案产出指南
Overview
本技能将后端开发领域的方法论转化为可执行的工作流。当用户提出任何后端开发需求时，先识别该需求属于 5 类场景中的哪一类，再按对应场景的产出清单生成完整的技术方案——从系统架构到灾备方案，覆盖后端工程的完整生命周期。
详细的方法论、各场景产出清单、API设计规范、数据库设计规范、分布式设计原则、安全清单、性能KPI、AI工具建议、质量检查清单均存放在 references/后端开发方法论.md，在执行前必须读取对应章节。
触发条件
当出现以下任一情况时触发本技能：
- 用户需要搭建新后端服务，涉及技术选型
- 用户需要开发新API模块，涉及多表/多服务联动
- 用户需要修复Bug或做小范围优化
- 用户需要做架构重构/升级（单体拆微服务、技术栈迁移）
- 用户需要做技术预研、选型评估、PoC验证
- 用户提到"后端架构""API设计""数据库设计""系统架构""微服务""缓存""消息队列""后端方案"等关键词
执行流程
按以下 5 步顺序执行，不可跳步。
Step 1: 需求理解
- 解析用户输入的后端开发需求
- 提取关键信息：项目类型（Web API/微服务/数据处理/实时服务）、语言偏好、功能范围、现有技术基础、团队规模、QPS预估
- 识别缺失的关键信息，主动向用户提问补全（一次最多 2-3 个最关键的问题）
Step 2: 场景识别
读取 references/后端开发方法论.md 的"一、场景识别"章节，用下表判断：
| 场景 | 名称 | 判断条件（满足任一） | 产出量 |
|---|---|---|---|
| 场景一 | 0→1 新后端服务 | 全新服务/系统、需从技术选型开始、涉及基础设施搭建 | 10-12类 |
| 场景二 | 中大型功能/模块开发 | 已有服务新增API模块、涉及多表/多服务联动 | 6-8类 |
| 场景三 | 小优化/Bug修复 | 单接口优化、单Bug修复、配置调整 | 2-3类 |
| 场景四 | 大版本重构/架构升级 | 单体拆微服务、技术栈迁移、数据库迁移、全局架构变更 | 8-10类 |
| 场景五 | 技术预研/选型 | 新技术栈评估、PoC验证 | 3-4类 |
识别流程：是否全新服务？→ 场景一；是否架构重构/大版本升级？→ 场景四；是否为技术评估？→ 场景五；是否涉及多表/多服务/新API模块？→ 场景二；否则 → 场景三。
Step 3: 与用户确认场景
输出场景判断结果，包含：
- 场景判断：场景X
- 判断依据
- 建议产出清单
- 预估周期
向用户确认后进入产出阶段。
Step 4: 按清单产出技术方案
读取 references/后端开发方法论.md 中对应场景的章节，按场景获取必备产出清单。
产出要求：
- 架构图使用 Mermaid 或 ASCII 描述（C4模型：Context→Container→Component）
- API设计给出完整的 OpenAPI/Swagger 规范（请求/响应/错误码）
- 数据库设计给出完整DDL语句 + 索引设计 + ER关系说明
- 业务逻辑流程含完整异常分支 + 补偿/回滚逻辑
- 安全方案覆盖认证/授权/输入校验/传输加密/存储加密/日志脱敏
- 遵循"七、后端通用规范"中的API规范、数据库规范、分布式设计原则
- 产出后保存为 Markdown 文件
Step 5: 质量检查
读取 references/后端开发方法论.md 的"九、产出质量检查清单"章节，对照检查：
架构： 架构图清晰、分层明确、通信方式有理由、CAP选择明确 API： 规范完整、请求/响应/错误码定义清晰、版本策略明确 数据库： ER图完整、索引设计合理、迁移方案含回滚、无外键/JSON滥用 安全： 认证授权完整、输入校验、HTTPS、加密/脱敏 性能运维： 缓存策略含防护、QPS预估+压测、监控告警完整、灾备方案
识别遗漏内容并补充，最后输出交付清单。
资源说明
references/后端开发方法论.md
完整的方法论文档，包含：
- 5个场景的详细产出清单与技术要点
- API设计规范（命名/HTTP语义/统一响应/错误码/分页）
- 数据库设计规范（必备字段/索引原则/软删除/避坑）
- 分布式系统设计原则（CAP/幂等/事务/限流熔断/降级）
- 安全清单（认证/授权/输入/传输/存储/运维 6维度）
- 性能KPI（API延迟/慢查询/缓存命中率/可用性）
- AI工具使用建议
- 产出质量检查清单
注意事项
- 不要跳过 Step 3 的用户确认
- 技术选型必须给出"为什么选A不选B"的理由，不是只列结论
- 安全是硬性要求，6个维度（认证/授权/输入/传输/存储/运维）缺一不可
- CAP选择必须明确：CP还是AP，不能说"都要"
- 幂等性设计覆盖所有关键写操作
- 缓存方案必须包含穿透/击穿/雪崩防护
- 场景四（架构升级）的回滚预案和数据回滚方案是硬性要求
What ships with it: 5 files
22.6 KB alongside SKILL.md
references/
- 后端开发方法论.md12.4 KB
- 记忆规则.md6.6 KB
- .gitignore78 B
- LICENSE1.0 KB
- README.md2.6 KB
Gives 0 of the 12 instructions most data backend skills give in ~1.9k tokens
Counted across 229 of the 229 authors here whose files we hold, read 2026-08-07
- Separate business logic into service layersin 22 of 229, across 15 files
- Retry failures with exponential backoffin 21 of 229, across 14 files
- Select only needed database columnsin 20 of 229, across 13 files
- Abstract data access into repository classesin 19 of 229, across 12 files
- Use centralized error handlersin 17 of 229, across 10 files
- Use AsNoTracking for read-only queriesin 16 of 229, across 4 files
- Use async/await for all I/O operationsin 16 of 229, across 5 files
- Implement structured loggingin 15 of 229, across 4 files
- Use dependency injection for all servicesin 14 of 229, across 2 files
- Use resource-based URLs for REST APIsin 13 of 229, across 7 files
- Invalidate cache after data changesin 13 of 229, across 9 files
- Use a dependency injection containerin 12 of 229, across 4 files
Said here and by no other author read
- read the methodology document before proceeding
- ask to clarify missing information
- classify the request into one scenario
- confirm the identified scenario with the user
- follow the checklist for the specific scenario
- describe architecture using Mermaid or ASCII
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.