用途
该技能用于在设计与审查类型、检查函数签名或编写任何静态类型语言代码时，应用一套类型系统纪律。其目标是让编译器拒绝不可能的状态、混用的基础类型和未处理的变体，并倾向于通过定义来消除错误与特殊情况，而不是不断增殖处理分支。
主要能力
- 品牌化语义基础类型：UserId 与 OrderId 底层都是字符串，但不应可互换。为每个概念赋予自己的类型，例如 TypeScript 中的品牌交叉类型，或其他语言中的 newtype。在创建时校验一次，下游信任该类型。如果两个参数共享同一基础类型但含义不同，就为它们建立品牌。
- 边界解析外部数据：外部数据在被解析前都是无类型的，包括 RPC 载荷、JSON、IPC 消息、CLI 参数、配置文件、环境变量、数据库行。在每个边界处设置解析函数，把非结构化输入转换为类型化模型。验证位置可参考 /principle-boundary-discipline。
- 从权威 schema 派生类型：当 protobuf、OpenAPI 规范、GraphQL schema、数据库迁移、设计令牌文件或其他文件拥有某个形状时，应从其派生，而不是手工编写一个平行的类型。可参考 /principle-encode-lessons-in-structure。
- 仅在出现部分性时加强类型：运行时断言、空值检查或“这不应发生”的抛出，标记了类型过弱的位置。把该检查上推到类型中，然后停止。类型系统的职责是追踪每个使用点必须处理的情况，而不是尽可能精确地描述数据。优先使用全函数：空列表的 sum 是 0，因此接受普通列表；空列表的 head 没有答案，因此要求非空列表。如果否则不会发生 panic，就保留普通类型。
使用方式
在设计与审查类型、检查函数签名或编写静态类型语言代码时应用上述原则。涉及 TypeScript 语法示例时，可调用 /typescript-best-practices。关于验证应放在何处，可参考 /principle-boundary-discipline；关于把经验编码进结构，可参考 /principle-encode-lessons-in-structure。
适用场景
适用于任何静态类型语言的类型设计、函数签名审查与代码编写，尤其是需要区分语义相近的基础类型、处理外部无类型数据、从权威 schema 派生类型，以及决定何时加强类型的场合。
限制
资料未提供该技能的具体安装命令、支持的平台、收费方式或价格信息，暂未提供。