从今天开始：你的第一个 Harness Engineering 实践

不需要团队，不需要预算。今天就能开始。

你不需要 OpenAI 的条件

读到这里，你可能在想：这些道理我都懂了，但 OpenAI 有 3-7 个专职工程师、无限的 API 额度、从零开始的绿地项目。我只是一个人，手里有个现有项目。

好消息：驭缰工程对个人开发者同样有效。

deusyu 的学习指南里特别分析了个人开发者的适用性：

| 维度 | OpenAI | 个人开发者 | | --- | --- | --- | | 团队 | 3-7 人专职 | 1 人 | | 代码库 | 空仓库 | 通常有遗留代码 | | 反馈 | 团队成员兜底 | 只有自己 | | 适用性 | ✅ 六大概念全部 | ✅ 核心概念直接可用 |

你的最小可行 Harness 只需要四样东西。

第一步：写一个 AGENTS.md（30 分钟）

这是杠杆率最高的单个动作。

模板

bash 复制代码

# AGENTS.md

## 这是什么
[你的项目名] 是一个 [用一句话描述]，使用 [技术栈]。

## 仓库结构
src/
  components/ --- UI 组件
  services/ --- 业务逻辑
  utils/ --- 共享工具函数
  types/ --- 类型定义

## 核心规则
1. 所有 API 边界必须验证输入（用 Zod）
2. 组件不超过 200 行，超过就拆
3. 禁止 any 类型
4. 测试覆盖核心逻辑

## 开发流程
- 开发：npm run dev
- 测试：npm test
- lint：npm run lint
- 构建：npm run build

## 代码规范
- ESLint + Prettier 已配置
- 命名：camelCase 变量，PascalCase 组件，UPPER_SNAKE 常量
- 提交信息：conventional commits

## 更多
- 架构详情：docs/ARCHITECTURE.md
- API 文档：docs/API.md

检查清单

第二步：配置基础自动化（1 小时）

ESLint + Prettier

bash 复制代码

npm install -D eslint prettier eslint-config-prettier
npx eslint --init

在 ESLint 配置中加上你自己最容易犯的错的规则。不要用默认配置就完事------根据你项目的痛点定制。

基础测试

不需要追求高覆盖率。先覆盖核心业务逻辑------那些出 bug 代价最高的部分。

bash 复制代码

// 一个简单的测试示例
describe(&#x27;calculateRefund&#x27;, () => {
  it(&#x27;should handle partial refund&#x27;, () => {
    expect(calculateRefund(100, 30)).toBe(70);
  });
  it(&#x27;should reject negative amounts&#x27;, () => {
    expect(() => calculateRefund(-1, 0)).toThrow();
  });
});

Git Hooks（提交前自动检查）

bash 复制代码

npm install -D husky lint-staged
npx husky init
echo "npx lint-staged" > .husky/pre-commit

bash 复制代码

// package.json
{
  "lint-staged": {
    "*.{ts,tsx}": ["eslint --fix", "prettier --write"],
    "*.test.{ts,tsx}": ["npm test -- --related --bail"]
  }
}

现在每次 git commit 都会自动检查。husky + lint-staged 这套组合拳好用，就是因为提交之前能自动拦截问题。

第三步：设计先行的节奏（习惯改变）

错误的方式（Vibe Coding）

bash 复制代码

打开 AI → "帮我做一个 XX 功能" → 接受所有建议 → 提交

问题：设计和实现都委派给了 AI。你不知道你要什么，AI 也不知道。

正确的方式（Harness 模式）

关键区别：你做设计，AI 做实现。

lalitm 的 syntaqlite 项目（从 8 年的渴望到 3 个月实现）验证了这一点：

早期用 Aider/Roo Code/Claude Code 效果有限，代码质量不稳定
后来用 Harness 模式（先设计再实现、加自动检查）→ 成功发布

第四步：重构纪律（持续维护）

每周 15 分钟的"园艺时间"

bash 复制代码

周一早上：
1. 看 AI 上周改动的 diff（5 分钟）
2. 有重复代码？→ 提炼共享函数（3 分钟）
3. 有不一致的模式？→ 加 lint 规则（5 分钟）
4. 有过时的文档？→ 更新（2 分钟）
5. 新发现的坏模式？→ 记录到黄金规则

发现坏模式的标准流程

bash 复制代码

发现坏模式
  → 在 AGENTS.md 或 lint 中添加规则
  → 让 AI 按新规则重构已有代码
  → CI 验证重构没有破坏功能

你的第一个 Ralph 循环

准备工作

跑一次

bash 复制代码

Step 1: 写清楚任务（自己写，不要让 AI 写）
  - 目标是什么
  - 验收标准是什么
  - 不能改哪些东西
  - 需要改哪些文件（提示范围，不硬性限定）

Step 2: 让 AI 实现
  - 在 Claude Code / Cursor / Copilot 中描述任务
  - 让它自己读代码、写代码、跑测试
  - 不要每步都盯着------让它跑

Step 3: 检查结果
  - 看 diff
  - 跑测试
  - 跑 lint
  - 确认功能

Step 4: 如有问题，在 PR/文件中留评论
  - 让 AI 根据评论修复
  - 不用自己改------让 AI 改

Step 5: 合并

这就是一个简化版的 Ralph 循环。你可能花了 5 分钟写任务、5 分钟检查结果，AI 干了 1 小时的活。

30 天进阶路线图

bash 复制代码

第 1 天：写 AGENTS.md + 配置 ESLint/Prettier
第 2-7 天：每天用 AI 写代码，观察犯错模式
第 8 天：根据观察结果，加 3 条自定义 lint 规则
第 9-14 天：继续用 AI，注意新增规则的效果
第 15 天：第一次"园艺时间"------清理技术债
第 16-21 天：尝试让 AI 自己 review 代码
第 22 天：配置 CI 自动检查
第 23-28 天：开始用"设计先行"的方式工作
第 29 天：第二次"园艺时间"+ 更新 AGENTS.md
第 30 天：回顾总结，规划下一个 30 天

写在最后

驭缰工程不是一个你需要团队和预算才能实践的范式。

它的核心就是三件事：

从一个 AGENTS.md 开始。

人类掌舵，智能体执行。

*这是驭缰工程系列的第八篇（完）。上一篇：《AI 是最好的混乱放大器：代码熵管理实战》*彩蛋预告：《从 Claude Code 源码看 AI 编码的真相》

觉得有用？转发给你身边一个人写代码的朋友。驭缰工程系列合集正在持续更新，关注公众号「赛博虾条」不错过后续文章。