从零接触到悟出Claude Code类Harness模式
一、零接触
仍记得最初使用的是千问页面问答形式处理Bug，每次都贴代码或者上传文件，再向大模型解释需要处理什么问题。得到回答后，还需要自行验证方案是否可行。这一套执行完虽说比人工排雷要轻松，但也是耗时耗力的工作。
后来有了Cursor，试了试让它帮我开发网站。换了好几个号的免费试用额度，勉强完成了初版网站开发。说勉强，因为对于新项目而言，它写新代码确实是一把好手，速度让人惊讶，但调试问题时，大量时间花在了提示词工程上，反复调教才完成任务。这时，AI编程工具或者说AI Agent的能力已经初见成效，比页面问答好太多。
再后来AI编程工具遍地开花，我先试了Trae、CodeBuddy、WorkBuddy、Qcoder等，只能说各有所长，也各有所短。印象最深的是有些任务，Credits烧完了，事情都没做完。Agent会陷入混乱状态，俗称“瞎搞”。
于是，最终开始尝试Claude Code。实话实说，有种相见恨晚的感觉。因为初体验，也由于是国内环境，我选择了Deepseek v4作为大模型。从/init初始化开始，到完成任务，做完一个网站和一个小程序，整体感受是它用起来真是丝滑。不论写新代码，还是排查问题，它都可以妥善地处理完任务。
二、进化
我喜欢命令行的轻便以及不受系统平台限制，因此主要通过命令行来使用Claude Code。通过命令行也可以看到Claude Code比较原始的状态，这是我推荐使用命令行的原因之一。
下面从8个方面简单介绍一下我使用Claude Code的个人进化内容：
- 提示词的优化
提示词的优化是在与Claude Code命令行交互过程中，持续关注大模型的命中缓存情况时，不断领悟的。
# 最初常用提示词# Tips：十分不规范，十分随意，这样命中缓存会较低。请你根据《XXXX项目功能清单 - 完整》规划XXX项目的开发。 请继续规划。我添加了git和bin环境变量。 读取本地CLAUDE.md，核对全部项目进度，从暂停位置继续开发，不用重新规划。 如果需要开发前端页面，需使用frontend-design这个skill。# 使用一段时间后的提示词# 固定该固定的提示词读取本地CLAUDE.md，核对全部项目进度，从暂停位置继续开发，不用重新规划；如果需要开发前端页面，需使用frontend-design这个skill。继续完成任务，涉及数据库的使用本地docker完成测试。安装python包、conda包时需要使用虚拟环境，不能直接用base环境，保持base环境干净。docker的bin目录路径是C:\Program Files\Docker\Docker\resources\bin。使用docker安装必须的软件完成本地测试。docker的"registry-mirrors":["https://docker.1ms.run","https://docker.xuanyuan.me"]。 你是全栈工程师，请协助我测试代码。环境要求：1、python和conda使用虚拟环境，python虚拟环境路径是\backend\.venv；2、存储使用docker环境，docker pull的镜像源是docker.1ms.run；# 固化的提示词# 把系统架构、命令、配置、前端、编码风格等拆分到rules目录下，CLAUDE.md不超过200行请严格按照 CLAUDE.md 和 .claude/rules 中的所有规则执行：1、XXXXX 提示词工程，目的有两点：一个是未来清楚地指导AI完成具体的任务；另一个是不论上下文多脏，不论如何压缩上下文，该保留的提示词信息必须保留。
固化后的提示词简短精炼，而且可以多端使用，不同Agent使用同一套规矩。
- 开发环境的优化
在开发过程中，我发现大模型经常会忘了使用虚拟环境来完成软件安装、软件测试等工作，每次都需要通过提示词说明。而且提示词的效果也有时效性，如果不每次都把开发环境相关的提示词写进去，等上下文内容变大后，大模型会“忘记”。
因此，使用/init初始化Claude Code之后，我会立刻进行第二项固定操作：
# 格式化CLAUDE.md和rules文件的提示词规范化重构CLAUDE.md，保留不超过200行，梳理分类所有规则，合理拆分至.claude/rules文件夹分文件管理，统一格式精简内容，输出完整整理后文档。 格式化CLAUDE.md，拆分rules后，配合固定提示词，不论上下文如何变化，大模型该记住的东西都会记住。
- 上下文的优化
使用过大模型的都知道，对话次数多了，大模型会变“笨”，需要重新调教，这是很麻烦的事情。Claude Code有个命令很好用：
# 用于压缩对话历史、提取关键信息并释放上下文空间/compact 个人有几条经验之谈：
当对话轮次达到3次，我会手动使用该命令整理一下；或者，当命令行窗口右下角出现状态提示，比如：Context: 80%，应该立刻压缩上下文。
一次较大的开发任务使用一个上下文。每次使用/clear开启新的上下文之前，完成内容的保存、提交等存储工作。
- 上下文的恢复
有时候任务比较重，处理一整天都处理不完，或者仍未达到满意的地步，需要隔天工作时间再处理。这种场景下退出Claude Code是完全可以的。每次退出命令行时，Claude Code最后会输出一串字符串，比如：
# 带唯一标识，可直接复制执行会话恢复的命令claude--resume8bd847f1-xxxx-xxxx-xxxx-2e7d54xxxxxx 当然，如果忘记复制“序列号”也没关系，在同一台开发环境中使用–resume命令可以选择需要恢复的上下文。
- 多环境的使用
前面提到，恢复上下文需要同一台开发环境，这是因为Claude Code本身并不支持云端共享上下文。我们需要通过各种方式实现这个需求。
我有居家办公的情况，我采用两种解决方案：
- 远程连接：不论是电脑、云服务器、VDI等环境，都开启远程连接功能，支持到处访问。哪台机器上的Claude Code任务未完成，便远程连接到对应的服务器上。
- 使用CLAUDE.md记录进度：这种方式适用于本机器已经完成阶段性任务。使用提示词让大模型把计划的进度更新到CLAUDE.md文件内，并推送至代码库。其他机器拉取代码库后，可以提示词让大模型继续完成未完成的计划。需要注意的是：不要把CLAUDE.md文件写入.gitignore文件！
- 提交代码库的优化
在开发环境的优化中，我介绍了优化项目文档的提示词。这里补充介绍提交代码库之前，优化其他文档的提示词：
# 这句提示词可以补充更新项目文档，并执行推送代码库的确认任务。# 如需更新其他文档，均可补充提示词。清理项目，更新.gitignore、claude.md、readme.md等系统文件，推送至github。- 总结
综上，把整套提示词、文档优化、提交代码库的提示词整理如下：
# 步骤1：初始化Claude Code/init# 步骤2：格式化CLAUDE.md和rules文件规范化重构CLAUDE.md，保留不超过200行，梳理分类所有规则，合理拆分至.claude/rules文件夹分文件管理，统一格式精简内容，输出完整整理后文档。# 标准高缓存命中率Prompt写法：核心原则：固定前缀 + 可变参数[固定前缀模板]你是一个专业的产品文案撰写师，擅长撰写简洁明了、突出卖点的产品说明书。请根据以下产品信息，生成一份适合电商平台使用的产品说明书。[可变参数1]产品信息：[可变参数2]名称：智能保温杯[可变参数3]价格：99元[可变参数4]容量：500ml# 步骤3：固定提示词，可提高命中缓存，95%以上命中缓存属于正常# 可以把角色、系统架构、命令、配置、前端、编码风格等固化到CLAUDE.md和rules文件中# 每次提示词都复制执行，只修改可变参数部分请严格按照 CLAUDE.md 和 .claude/rules 中的所有规则执行：1、XXXXX；2、xxxxx# 步骤4：每完成一次阶段性的任务，都进行上下文压缩、项目清理、文档更新、代码保存等善后工作。/compact 清理项目，更新.gitignore、claude.md、readme.md等系统文件，推送至github。# 其他：# 如遇到任务中断，大模型请求无反应等情况，需要重启Claude Code，可以使用恢复命令claude--resume三、Harness模式
原本我想研究一下Harmes Agent开发，拼写错误，发现了Harness模式。再细细一读，这似乎和我操作Claude Code的工作流有点相似。
Harness模式是一种围绕 AI Agent 构建约束、反馈和控制系统的工程实践，用于确保模型输出可靠、可控并可持续改进。
Harness Engineering（驾驭工程）是指在 AI Agent 系统中，通过约束机制、反馈回路、工作流控制和持续改进循环来优化模型运行环境，而非直接优化模型本身。其核心哲学是 “人类掌舵，智能体执行（Human Steer, Agent Execute）”，强调通过系统设计引导 AI 高效、稳定地完成任务。
Harness 通常包括以下组件：
- 约束机制：限制模型行为，防止输出偏差或错误。
- 工具调用：集成外部 API、数据库或计算工具。
- 文档与上下文管理：确保模型获取正确信息。
- 反馈循环：记录错误并自动改进系统。
- 工作流控制：定义任务执行顺序和异常处理逻辑。
- 沙箱环境与钩子中间件：提供安全、可控的执行环境。
这里直接引用Copilot Search的回答是因为我确实暂未使用相关的开源工具、管理平台进行实践，无法给出什么心得与体会。但值得一提的是，因为其相关优化比我的工作流程更加规范，我认为是很值得推广和继续尝试的。同时，我自己也为悟出“类Harness模式”感到开心，后面将更加规范化自己的工作流程，更加深入学习Harness模式。