已有项目引入 Harness Engineering

发表于 分类于 Disqus： 本文字数： 1.3k 阅读时长 ≈ 5 分钟

虽然有一段时间没有写业务代码，但是使用 AI 写代码已经有一大段时间了，可以明显感受到 AI Coding 能力的提升，从最开始艰难且不专业的代码补全，到现在完全可以一行代码不写全靠 AI 实现一个庞大项目，不得不说还是挺让我惊叹。尤其是 Claude Code 完全通过工程化方式，是的模型能力不变的前提下使得任务质量产生质的飞跃，这还是让我十分佩服。

过去使用 AI Coding 其实还是比较粗放，虽然从最开始的密集 prompt 到有意识的 spec driven，但依旧没有形成太好的方法论，Harness Engineering 一经提出，我立刻意识到这个方法论的强大，以及在现有项目中引入 Harness Engineering 的必要性。

概述

核心思维模型：把 Claude Code 当成一个有纪律的工程团队

Harness engineering 的本质是把你的工程规范编码进系统，让它自动执行，而不是靠对话时每次重新叮嘱。四个支柱：

  • CLAUDE.md → 项目宪法（长期记忆 + 规范）
  • Hooks → 自动化卫兵（强制执行规范）
  • Commands/Skills → 可复用工程原语（标准化操作）
  • Worktrees → 隔离实验场（安全探索）

引入步骤

1. 初始化目录与结构

初始化 claude 标准的相关目录。

mkdir -p .claude/{docs/decisions,commands,hooks,rules}

进入 claude，目前使用的是司内的版本，所以命令行需注意。

cd {项目目录}
claude-internal

让 claude 生成一个 CLAUDE.md 的基础版本（目前已经在 claude 会话内了）。

claude > /init

让 claude 基于现有项目的架构与代码，生成对应的 architecture.md 以及 code-standard.md。

claude > 帮我基于现有项目以及代码生成对应的 architecture.md 以及 code-standard.md

2. 生成 Commands

为了让后续需求开发更为流程化与标准化，最好通过一系列的命令进行需求开发，而不是持续通过对话的方式进行。最佳以及最简单的建议，可以让 claude 基于模板生成这些命令，然后再自己进行微调。下面是一个 prompt 的例子

claude > 我希望后续的需求开发标准化，帮我生成以下命令

    /design： 需求分析与设计
    /feature: 基于 /design 的需求进行细化，技术考虑，实现设计，测试驱动，代码实现，归档
    /fix: 问题修复，归档
    /debt: 代码债务分析，处理，归档

执行之后在 .claude/commands 目录下会生成这些命令的 md 文件，根据自己需要进行调整。

3. 生成 Hooks

Hooks 是自动化的卫兵，用于执行一些自动化的操作，比如自动提交代码，自动创建分支，自动创建标签等。上面的那些 md 文件的约束只是软约束，agent 不一定会强制遵守，但是生产中有部分任务是需要强制遵守的，比如

  • 做出改动之后需要通过已有测试
  • 做出的改动需要符合代码规范
  • 重要的文件不能进行改动
  • 重要或者敏感信息不能再文件中明文展示
  • ...

有几个添加 hooks 的方式：

  • 让 claude 自己生成
  • 在网上查找自己需要的 hooks，然后自行导入
  • 随着项目的发展，慢慢发展起项目相关的 hooks

4. 整理与归档现有 spec

有些项目已经是使用 spec 的方式进行开发。据我观察，初步使用（或者是已经放弃 speckit 或者 openspec 的项目）都会有一个 spec 目录，可以先让 claude 阅读并整理这些 spec，然后根据项目的实现状态来将其转移到 docs/specs 目录下。

claude > 请阅读并整理 spec 下的需求描述，并结合项目确定其实现状态，并归档到对应位置

5. 补充单测

上面已经生成了开发流程的命令，所以补充单测可以直接通过“一个需求”进行。下面是一个需求描述的参考。

claude > /design 希望为本项目补充单测

- 结合现有文档与实现，找出关键的系统流程
- 划分好这些关键流程涉及到的模块，分步补充单测
- 先规划好整个单测补充的流程
- 对于功能性的部分以单测为主，对于前端界面来说，补充重要部分界面的单测即可
- e2e 测试可以先不管，优先补充单测以及集成测试

在生成单测的需求描述之后可以稍作审视与补充，然后就可以使用 /feature 命令进行单测的补充了。整个过程可能比较长，对于完全没有单测的项目来说，还是比较必要的。

补充单测之后，就可以进一步对 /feature 以及 /fix 命令进行修改，加上单测准入的机制。但是如前所述，这些都是软约束，agent 不一定会强制遵守，所以还需要加上 hook，比如 pre-commit-test 这种，这样可以确保在提交之前保证单测全部通过。