技能介绍

要解决什么问题

团队里常见断层：Forge 或 PoC 跑得很快，但一上生产就缺类型、边界校验和可测试结构；Scout 把根因说清楚，实现却仍在症状层打补丁；API 集成在 429/5xx 上无限重试，或在 HTTP 边界用 Zod 的 .parse() 把进程打挂。Builder 定位是纪律严明的编码工匠：把上游的原型、计划、调查结果落成生产就绪的业务逻辑、数据模型与 API 代码，而不是再写一版「能跑就行」的草稿。

如何工作

工作流固定为 SURVEY → PLAN → BUILD → VERIFY → PRESENT。实现前先定接口与类型；领域侧坚持构造即有效（实体/值对象拒绝半构造状态）；系统边界用 解析而非重复验证（如 safeParse、Result/铁路导向），TypeScript 侧强调严格模式且禁用 any。按场景走配方子命令，例如：fix（有界 Bug 修复）、api（错误分类、有界重试、幂等键、按端点断路器）、ddd（先限界上下文再战术模式）、harden（Forge 原型生产化）、pair（结对：你导航、Builder 驾驶，逐增量确认）。交付时会为 Radar 留测试骨架，并可交接 Guardian（PR）、Judge（审查）、Tuner/Sentinel（性能/安全）。

适用边界与注意点

适合：类型安全的业务逻辑、REST/GraphQL/WebSocket 集成、验证层（Zod/Pydantic 等）、状态管理与复杂领域实现（在需要时 DDD）。
不适合：纯 UI/页面 → Artisan；只求速度的 PoC → Forge；只写测试 → Radar；无行为变更的重构 → Zen；只调查不修 → Scout。
硬性习惯：VERIFY 阶段做五轴影响范围检查（调用方、测试、类型/契约、配置、文档），未检查不得宣称完成；pair 模式必须增量获批，不能一次性堆代码再要一次确认。

截图预览

使用场景

Forge 原型已能演示后，要在不扩需求的前提下补齐严格类型、`safeParse` 边界与 Radar 测试骨架再合入主干。
Scout 已写明 Bug 根因与复现路径，需用 `fix` 配方做有界修复（目标 <50 行）并附回归测试从红变绿。
对接 Stripe、Slack 或自建 Webhook 时，按沙箱联调、密钥进 env/Vault、签名校验与重放幂等完成 `integrate` 交付。
新功能采用垂直切片（如取消订阅）时，用 `pair` 模式逐增量提议验证方式、实施 diff 并获确认后再写下一块逻辑。

适合人员

维护 SaaS 计费后端的工程师，要把 OpenAPI 生成类型与 Zod 边界校验接到 Express/Hono 路由且 5xx 有界重试。
接过 Forge L0–L2 输出的全栈开发，上线前需走 `harden` 清除 `any`、HTTP 边界 `.parse()` 与硬编码密钥。
on-call 工程师在 Scout 交接后负责生产缺陷，需完成 `fix`/`patch` 并在 VERIFY 五轴（调用方/测试/类型/配置/文档）全记录后才能关单。
按功能交付的 Tech Lead，希望与 Agent 结对逐段实现聚合不变量与 API 弹性，而不是一次性生成无法审查的大 diff。