我首次涉足线束工程师领域

Source: Dev.to

介绍

当我们的团队着手构建 BypassHire —— 一款将求职申请时间从 45 分钟缩短到不足 5 分钟的 AI 工具时，我们很快意识到有趣的工程挑战并不在模型本身。模型是容易的那部分。困难的部分是围绕它的所有东西。

Martin Fowler 最近将这层外围称为 harness engineering。在编码‑代理设置中，harness 包括除模型本身之外的所有内容——指南、传感器、规则以及脚手架，这些决定了代理产生的结果是否值得信赖。我们在冲刺期间花了大量时间专门设计这些内容，本文将描述我们构建的内容以及背后的原因。

线束机制

Fowler 将线束机制分为两类。

引导（前馈控制）

引导会预见问题并在一开始就塑造行为。

• 项目级指令文件：CLAUDE.md 编码我们的约定，强制工作流顺序（/plan → /tdd → /build‑fix → /code‑review → /verify），安全规则以及覆盖率阈值。每个会话都以 Claude 读取此文件开始，在生成任何代码之前就确定游戏规则。

• 专用子代理：

  • architect
  • planner
  • tdd‑guide
  • code‑reviewer
  • security‑reviewer（OWASP 范围，针对任何涉及认证路由、数据库查询或 Claude API 提示的 PR 触发）
  • build‑error‑resolver

  与其让一个通用代理决定一切，我们构建了一个由狭窄专家组成的委员会。专业化降低了每个代理需要推理的表面面积，从而提升可靠性。

• MCP 服务器集成：GitHub、Playwright、Vercel 将代理的触及范围扩展到外部系统，同时不放宽其护栏。代理可以检查部署状态或运行浏览器测试；但它不能对生产环境进行未审查的更改。

传感器（反馈控制）

传感器观察已生成的内容并发出修正信号。这正是 Claude Code 的钩子系统成为基础设施的地方。

我们运行四个钩子，绑定到会话生命周期：

1. 编辑时 lint – 在任何 .ts 或 .tsx 文件被触碰后，ESLint 和 Prettier 立即触发。反馈循环压缩到毫秒级。
2. 退出时测试运行守卫 – 当 Claude 试图结束会话时，npm test 自动运行。如果测试失败，会话将被阻止关闭。“我稍后再修复”在结构上变得不可能。
3. 绿色测试提交信号 – 任意测试运行的 Bash 调用返回 0 后，钩子注入一个提示，询问是否进行检查点。该信号仅为建议；Claude 决定是否提交，钩子本身从不执行 git commit。
4. 任务完成提交信号 – 当一个 todo 转为 已完成 时，快照差异触发相同的提示，针对该工作片段。

Fowler 区分 计算传感器（快速、确定性：linter、类型检查器、测试）和 推理传感器（AI 驱动、较慢，但语义更丰富）。我们的钩子属于计算传感器。我们的 code‑reviewer 与 security‑reviewer 子代理属于推理传感器——它们捕获 linters 看不到的架构和行为问题。

可利用性 (Harnessability)

并非所有代码库都同样适合使用“harness”。Fowler 将其称为 harnessability —— 使系统对代理可读的结构属性。

我们有意选择了 TypeScript、Prisma、Zod 和 Next.js App Router。强类型、经过模式验证的 ORM，以及在每个 API 边界进行的运行时输入校验，为人工审查者和代理感知器提供了精确、机器可读的契约。harness 的效果取决于它所抓取的表面有多好。

引导循环

Fowler 最重要的洞见是，工具需要一个 引导循环 —— 人类监控重复的失败并相应地收紧控制。

在我们的第一个冲刺后，我们注意到 Claude 有时在身份验证模式上出现漂移；我们添加了一个 ESLint 规则，禁止直接从 @clerk/nextjs/server 导入，强制所有身份验证通过我们的 src/lib/auth 包装器。由于我们观察到它的失败点，工具变得更聪明了。

这个循环 —— 观察 → 编码 → 强制 —— 正是引导工程师的实际工作。模型负责生成。我们负责保持生成诚实的系统。