技能介绍

要解决的工程问题

写 gRPC 服务时，*.proto 往往只是接口定义的一份输入；真正进入多语言仓库、CI 和联调环境之前，还要生成各语言的客户端与服务端桩代码。如果每次改字段、删字段、改服务名都靠手工抄一遍生成物，仓库里很容易出现版本漂移：Go 客户端拿到的 message 字段和 Rust server 的定义不一致，Java stub 漏掉了新 enum，或者 breaking change 直到发布前才被人肉发现。这个技能要把这件事收回到可重复的编译流程里：以 Protocol Buffer 定义为事实源，产出语言相关 stub，并在生成前后做校验。

它如何工作

技能的核心动作是编译 proto 定义，而不是改写业务语义。它通过 buf CLI 和 protoc plugins 驱动 Protocol Buffers / gRPC 的常规工具链：读取 *.proto 中的 message、service、rpc 定义，调用对应语言的 protoc 插件生成 client/server 桩代码，并把结果落到项目约定目录。生成前会用 Buf lint 规则检查 proto 文件，例如命名、字段组织、注释、重复定义和常见约束；这步先拦住“能编过但不好维护”的定义。生成后可以基于同一份 schema 做 breaking change 检测，重点回答一个工程问题：旧客户端能否继续理解新服务，或者服务端能否继续服务旧调用方。对需要 Node.js 运行环境的项目，资料里列出的 @grpc/grpc-js、grpc、@grpc/proto-loader、grpc-tools 指向 gRPC on Node.js 的工具与实现选择；使用时应把它们理解为生成物落地后的运行时/工具链依赖，而不是替代 buf 或 protoc。

适用边界与注意点

这个技能适合“schema 驱动”的开发方式：proto 已经纳入版本管理，服务接口需要跨语言共享，CI 能接受生成代码检查或基线比对。它不负责证明服务设计正确，也不会自动修复 breaking change；Buf lint 命中的是规则和常见风险，breaking change 命中的是兼容性信号，最终仍要人判断这是不是可发布的变更。输出质量依赖可用的 buf、protoc 和目标语言插件：缺少某个 plugin 时，对应语言的 stub 无法凭空产生；插件版本、protobuf edition、module/import 路径不匹配时，也会得到不可用或不一致的生成结果。生成代码应纳入仓库或明确生成基线，避免各端各自重跑导致签名漂移；同时不要把生成物当作可编辑的业务层，手工补丁很容易在下次生成时丢失。