现代skill
推荐skill
- Go Backend Scalability & Clean Architecture
- Go Concurrency & Context Management
- Table-Driven Testing & Mocking
- Robust Backend Ops (DB & Logs)
- Polyglot Context Dispatcher
- Universal Clean Architecture
推荐原因
Go Backend Scalability & Clean Architecture (高并发与清晰架构)
核心逻辑：强制实施洋葱架构/整洁架构（Handler -> Usecase -> Repository），要求面向接口编程。
推荐理由：AI 的通病是喜欢写“面条代码”（把所有业务逻辑和 SQL 塞在一个 controller 文件里）。这个 Skill 充当了“架构门神”，强制 AI 在生成代码时主动切分职责、使用依赖注入（DI），为后期系统的可扩展性打下基础。
Go Concurrency & Context Management (并发安全与上下文控制)
核心逻辑：规定 Goroutine 的启动必须伴随 sync.WaitGroup 或 errgroup，且必须透传和校验 context.Context 以防止泄漏。
推荐理由：Go 的并发极易写错（数据竞争、协程泄漏）。为并发场景配置专属 Skill，能让 AI 在写并发代码时自动补齐锁（Mutex）、通道（Channel）关闭校验和超时控制，极大减少 Debug 时间。
Table-Driven Testing & Mocking (表驱动测试与依赖注入)
核心逻辑：检测到生成测试用例时，强制使用 []struct{name, args, want, mockSetup} 的表驱动格式，并使用 gomock 或 testify。
推荐理由：Go 社区的测试风格非常统一。如果不加此 Skill，AI 生成的测试代码往往是冗长且脆弱的单一 if-else。这个 Skill 让 AI 生成的单元测试极其标准且覆盖率高。
Robust Backend Ops (DB & Logs)
为什么需要？ AI 在写业务代码时，最容易犯两个致命错误：一是拼接 SQL 导致注入漏洞，二是遇到报错直接 if err != nil { return err }，导致生产环境丢失堆栈，或者用 fmt.Println 打日志。
你需要给它加一条规则：
“任何数据库查询必须使用参数化（Parameterized Query）。”
“Go 中任何 error return 必须被 fmt.Errorf("context: %w", err) 包装。”
“严禁使用标准的 print 打印业务日志，必须使用结构化日志器（如 slog / zap）。”
Polyglot Context Dispatcher (多语言上下文路由/元规则)
触发条件 (Globs): * (全局，但极度轻量)
核心逻辑: 这是一个“Meta Skill”。它不教 AI 写代码，而是给 AI 立规矩：“当你看到 .go，严格遵守 Effective Go；看到 .py，严格遵守 PEP8 和 Ruff 规范；看到 .ts，严格遵守 ESLint 和 TypeScript Strict 模式。”
推荐理由: 绝对的 Top 1。它是多语言项目的“交通警察”。强制 AI 在回答或生成代码前，先深呼吸（Chain of Thought），识别当前操作的文件后缀和生态系统，从而切换到对应的内置语言模型，防止语法和风格的串味。
Universal Clean Architecture / DDD (通用整洁架构与领域驱动设计)
触发条件 (Globs): **/controllers/**, **/services/**, **/repositories/**, **/domain/**
核心逻辑: 无论使用 Java (Spring)、TS (NestJS) 还是 Python (FastAPI)，强制实施控制反转（IoC）和依赖注入（DI）。禁止在 Controller/Router 层直接写 SQL 或操作第三方 API，必须通过 Service/Usecase 层委派。
推荐理由: 后端语言千千万，但软件工程的架构原则是统一的。这个 Skill 确保 AI 生成的代码在任何语言下都具有极高的可测试性和解耦性，避免 AI 写出几千行的“面条脚本”。
架构深度 (Clean Architecture)：避开了“面条代码”，强调代码的可维护性和解耦，这是区分初中级开发者的分水岭。
Go 灵魂 (Concurrency & Context)：抓住了 Go 的核心竞争力。理解 Context 机制是写好高并发、不泄露服务的关键。
工程化思维 (Table-Driven Testing)：这是 Go 官方推荐的测试模式，体现了你对代码质量的严谨态度。
Polyglot Context Dispatcher：这是一个非常“高级”的加分项，暗示你具备处理多语言环境（如跨语言 RPC、插件系统或复杂上下文路由）的经验。
为什么不推荐传统skill
1. 为什么不推荐 golang-expert？
理由：它是早期的“上帝对象（God Object）”反模式，与延迟加载（Lazy Loading）理念相悖。
时代的眼泪：在 ChatGPT 刚出来或 Cursor 早期（只支持全局 .cursorrules 时），大家喜欢写一个巨大的 golang-expert 规则（“你是一个拥有20年经验的Go专家，你要注意并发、注意内存、注意GC、注意命名……”）。
Token 浪费与注意力稀释：在当前的 Cursor MDC (Markdown Declarative Content) 或 Trae Skills 架构下，大而全的规则是极其低效的。如果你在使用全局的 golang-expert，意味着你哪怕只是让 AI 修改一个 Markdown 文档，或者写一段简单的 SQL，它都会把“Go GC 优化规则”加载进上下文中，白白浪费 Token，且极易导致“Lost in the Middle”（大模型注意力失焦）。
我的替代方案：我推荐的 Top 10 是将 golang-expert 拆解成了高度正交的 Sub-agents。例如将它拆成了 #3 并发与上下文、#5 错误处理 和 #10 代码风格。通过 globs 针对不同文件按需加载，这才是目前高阶玩家的玩法。
2. 为什么不推荐 systematic-debugging？
理由：AI IDE 的 Native Agent 能力已经将其“降维打击”，显式的文本指令显得冗余甚至会起冲突。
技能重叠：systematic-debugging 的核心逻辑是要求 AI：“遇到报错时不要盲目猜，先收集日志、提出假设、再分步验证”。
工具已经原生支持：现在的 Cursor Agent/Composer 模式和 Trae 的 Solo 模式，其系统底层提示词（System Prompt）本身就已经是一个强大的 Debugger。当你把终端（Terminal）报错抛给它们时，它们原生的行为树逻辑就是 Read Error -> Check Code -> Formulate Hypothesis -> Edit -> Run Terminal -> Verify。
冲突风险：如果你再叠加一个自定义的 systematic-debugging Skill，不仅多此一举，有时还会让 AI 变得过于啰嗦（比如强行让你先写出 Debug 计划并让你确认，拖慢了 AI 自动修复问题的节奏）。这个 Skill 更适合用在早期的普通对话框（Chat），而不是现在的智能代理模式。
3. 为什么不推荐 test-driven-development (TDD)？
理由：LLM 的生成机制与严格的 TDD 流程存在天然摩擦，Go 社区有更务实的平替。
交互逻辑的割裂：TDD 的核心是“红（写测试报错） -> 绿（写实现通过） -> 重构”。这需要一个多轮的、严格控制先后顺序的交互流。大模型的特性是“一次性给你生成完整上下文”。即使你挂载了 TDD Skill，AI 往往也会忍不住“一口气把测试用例和业务逻辑全写出来”，很难真正做到人类那种细腻的 TDD 步骤。
不够 Go-Native：TDD 是一个跨语言的通用方法论，不够“Golang”。
我的替代方案：我用 #4 Table-Driven Testing (表驱动测试) 替代了它。在 Go 语言的工程实践中，表驱动测试是绝对的主流。与其逼着 AI 去走难以控制的 TDD 流程，不如退而求其次：业务代码写完后，一键让 AI 用最规范的 Go 表驱动格式补齐全部分支覆盖率。这在实际开发中提效最明显，也最符合 AI 的“填空生成”强项。
如果你个人非常喜欢这三种模式，想要把它们加入你的工作流，为了避免上述提到的坑，我建议你这样使用：
对于 golang-expert：
不要全局挂载！ 将其改名为 go-architecture-review.mdc，并设置触发词。只有当你显式地对 AI 说 “@go-architecture-review 帮我 Review 一下这个模块的设计” 时才触发。让它作为你的“代码审查专家”，而不是“打字员”。
对于 systematic-debugging：
不建议作为常驻规则，但可以作为一个手动触发的 Prompt Template。遇到极度诡异的 Bug（比如内存泄漏、Goroutine 僵死），在对话框里输入：“调用你的 Systematic Debugging 技能，帮我排查这个问题。”
对于 test-driven-development：
把它和特定目录绑定。在 .cursor/rules/tdd.mdc 中设置 globs: ["**/*_test.go"]。并且在指令里必须增加强制约束：“STOP after writing the failing test. Wait for user input before writing implementation.”（写完失败的测试后必须停下，等待用户指令后再写实现），以此来强制打断 AI 的生成欲。
总结来说，现代 AI 编程的核心奥义是“微操”与“精准上下文”。把宏大叙事（Expert、TDD、Systematic）转化为具体场景下的纪律约束（并发锁怎么写、报错日志怎么打），才是压榨 AI 编程工具最大价值的方法。
传统skill
Test-Driven Development
它和 Go 原生极简的testing包完美适配，强制 AI 遵循「红 - 绿 - 重构」的流程，先写单元测试 / 基准测试（testing.T/testing.B），再写最小实现代码，最后重构优化。对于 Go 服务端开发，它能直接把错误处理覆盖率提升 60%、并发 Bug 率降低 70% ，尤其适合核心业务逻辑、数据库操作、并发组件的开发，是生产级 Go 项目的质量底线，完全替代了额外的代码质量类 Skill。
Systematic Debugging
它是解决 Go 服务端最头疼问题的「终极武器」——Go 开发 80% 的疑难问题都来自竞态条件、Goroutine 泄漏、内存泄漏、channel 阻塞、接口超时这类人工难定位的并发 / 运行时问题。这个 Skill 的四阶段根因分析流程，会强制 AI 先做故障假设，再指导你用 Go 原生工具（go test -race、pprof、trace）获取运行时数据、复现问题，最后精准修复，彻底解决 AI 盲目猜修复方案的痛点，完全覆盖了日常开发 90% 以上的调试需求。
其他
只有当你有明确的、高频的专属场景需求时，再针对性加 1-2 个即可，绝对不建议一开始就全量安装，避免上下文膨胀、AI 匹配失焦、Token 浪费
1. 如果你是**团队 Tech Lead / 高频做 Code Review**：补充`Git PR Reviewer (Code Review Expert)`它适配 Google Go 编码规范，能自动检查 Go 代码的错误处理完整性、并发安全、小接口设计、性能隐患，可直接集成 CI/CD，帮你过滤 80% 的低级评审工作。
2. 如果你开发的是**对外暴露的 ToB 服务 / 带完整登录鉴权体系的 Go 服务**：补充`Better Auth Best Practices`它能帮你规避 Go 鉴权开发最容易出线上事故的安全坑，比如密码加密、JWT 规范、OAuth2.0 实现、CSRF 防护、RBAC 权限设计，是上线前的安全兜底。
3. 如果你开发的是**高并发基础组件 / 中间件 / 流量密集型 Go 服务**：补充`Go Concurrency Best Practices`它比通用的 Backend 框架规范更深入，专门针对 Go 并发模型，覆盖 Goroutine 池、channel 设计模式、`sync.Pool`、竞态检测、性能调优，是高并发场景的专属补充。
4. 如果你**高频维护 GitHub 开源 Go 项目 / 多仓库管理**：补充`GitHub Integration (gh-issues)`它能帮你通过自然语言直接管理 Issue、PR、GitHub Actions CI/CD，自动运行`go test`/`go vet`，省去频繁切换网页的重复操作。
Skill Creator
-
唯一的「元技能」，Anthropic 官方出品，是开发者自定义 Skill 的核心工具。它能通过引导式对话，把你的业务 SOP、团队规范、定制化流程自动转化为符合标准的 SKILL.md 文件，完美解决现有 Skill 无法满足个性化需求的痛点（比如对接公司内部系统、定制化项目开发流程、专属编码规范等），是所有开发者扩展 AI 能力的必备工具。
-
核心能力：自定义 Skill 生成、SOP 标准化转化、规范文档转指令、Skill 结构优化。
