在AI开发飞速发展的今天，驾驭工程（Harness Engineering）已成为连接大模型与实际工程落地的核心桥梁。但很多一线开发工程师对其存在诸多疑惑，我自身也有不少困惑：Claude Code本身具备相关层级，为何写了Claude Code的md文件才能落地Harness？Harness与记忆层、执行层等层级是什么关系？一线开发只需写Skill和规则就够了吗？规则是不是就是Harness落地所需的md文档？结合我自身的疑惑及相关技术实践——AI Agent = 大模型 + Harness、最轻量的Harness落地是写入md文件、spec-kit与SSD流程（Spec Driven Development，规范驱动开发）、程序员核心任务是写规则和Skill等，本文将深度拆解这些疑惑，明确Skill与规则的本质区别，详解spec-kit落地Harness的逻辑、Claude Code的落地方法，以及程序员如何深耕规则与Skill，同时科普驾驭工程的核心逻辑，并给出程序员提升自身修养、复用技术Skill的实用方法。

一、AI开发三大核心工程概念梳理（先厘清基础，再解疑惑）

在理解驾驭工程（Harness）之前，需先明确它与提示词工程、上下文工程的区别与关联——三者层层递进，共同构成AI工程化落地的核心支撑，避免混淆概念导致理解偏差。

1. 提示词工程（Prompt Engineering）：让大模型“听懂指令”

大模型（LLM）的本质是“基于输入预测下一个字词”的超大参数文件，若输入指令宽泛、模糊，输出就会发散、偏离预期。提示词工程的核心作用，就是通过有意识地设计提示词（比如角色设定、背景说明、历史对话、输出格式限制等），让大模型稳定按照我们预期的内容和格式输出。

举个例子：让大模型修改一段代码时，若只说“修改这段代码”，模型可能会乱改逻辑、删除核心代码；但如果加上“提供完整函数代码，不修改原有核心逻辑，仅修复语法错误，输出修改后的完整代码及修改说明”，模型的输出就会更精准——这就是提示词工程的价值，解决大模型“无引导乱说话”的问题。

2. 上下文工程（Context Engineering）：让大模型“记对信息”

上下文是“打包发给大模型的所有信息”，提示词只是其中一部分。大模型存在“上下文窗口限制”，多轮对话、大量信息输入时，容易出现窗口打满的情况，此时需要压缩或丢弃部分信息，进而导致“上下文腐化”——比如模型记不住关键需求、回答前后矛盾。

上下文工程的核心，是通过外部程序动态管理大模型的上下文，核心步骤包括3点：

• 召回：从外部新闻、聊天记录、当前代码、运行环境、报错信息等中，筛选出与当前任务最相关的信息（涉及RAG、Memory等技术）；
• 压缩：将筛选出的信息交给大模型总结，减小体积，避免占用过多上下文窗口；
• 组装：按“越靠后越易被模型关注”的原则，重新组织信息顺序，让上下文更精简、更聚焦，确保模型输出稳定准确。

这里要注意：不同AI工具的上下文工程策略不同，这也是“同一个大模型，在不同工具中使用效果不一样”的核心原因。

3. 驾驭工程（Harness Engineering）：让大模型“做成事”（深度解析）

提示词工程解决“听懂指令”，上下文工程解决“记对信息”，但这两步之后，大模型依然无法主动执行任务——它只能输出建议、代码，却不能自己运行代码、测试结果、修复报错。而驾驭工程的核心，就是给大模型套上一个“工程外壳”，赋予它主动执行任务、闭环迭代的能力，这与我自身理解的“AI Agent = 大模型 + Harness”完全一致：大模型是核心大脑，Harness是实现任务落地的工程外壳，二者结合才能构成能自主完成任务的AI Agent。

这个“工程外壳”由四个核心层级组成，也是我自身最关心的重点，结合我对Claude Code、spec-kit、SSD流程的疑惑，我们逐一拆解，重点厘清“层级、Harness、Claude Code、spec-kit、SSD”的关系：

（1）四大核心层级：记忆层、执行层、反馈层、编排层——Harness的“基础能力框架”

这四个层级是驾驭工程的“核心骨架”，是实现Harness的基础能力，具备这四个层级，不代表就是Harness；但Harness必须包含这四个层级——就像“汽车必须有发动机、车轮、方向盘”，但有这三个部件，不一定是完整的汽车（还需要车身、电路、驾驶规则等）。结合我自身的疑惑，这里重点明确：Claude Code的四层架构，就是这四个核心层级，它是Harness的“能力载体”，而非完整的Harness。

• 记忆层：提示词工程+上下文工程+规则，核心是“规则文件”（比如项目背景、做什么、不能做什么、测试要求、调用哪些Skill等，对应我所疑惑的md文件核心内容），可以拆分为多个短文件，按需路由加载。作用是确保核心信息持续存在于上下文，避免模型理解偏移（比如始终记住“不能使用某类框架”“代码必须符合PEP8规范”“调用FastAPI开发Skill”），规则文件可以解决上下文工程定义的目标和约束被多次循环ReAct之后被孵腐化的问题。
• 执行层：为模型赋予“动手能力”，比如接入bash、沙箱、文件系统等，让模型能直接操作外部工具——读写代码、执行命令、运行测试用例（我疑惑的“做完跑单测”相关场景）、查看报错日志等（Claude Code原生就能实现这些，所以它具备执行层能力，是Harness的基础载体）。
• 反馈层：将任务执行后的结果（比如单测输出、报错信息）重新加入上下文，驱动模型在下一轮循环中自动修复问题——比如模型执行代码后出现报错，反馈层会把报错信息传给模型，让模型针对性修改代码，形成“执行-反馈-修复”的闭环，这也是我疑惑的“让任务跑的更好、满足需求”的核心逻辑。
• 编排层：将复杂的大任务，拆解为有明确执行标准的子任务，按规划驱动Agent分步执行，避免无效死循环（对应我疑惑的spec-kit“拆解任务、指定计划”的功能）。比如“开发一个登录接口”，拆解为“编写接口代码→编写测试用例→执行单测→修复报错→部署测试环境”，一步一步推进。

（2）关键疑惑深度拆解（彻底厘清关系）

结合我自身的疑惑（md落地、spec-kit、SSD流程）和核心困惑，用“深度拆解+类比”的方式讲清楚，避免抽象难懂，重点解答：Claude Code的四层架构与Harness的区别、spec-kit和SSD是不是多出来的部分、Skill与规则的区别、为什么规则和Skill要写进md文件。

先明确核心结论（先记结论，再拆细节）：Claude Code的四层架构是Harness的“基础能力框架”（有了框架，才有落地的可能）；spec-kit和SSD不是“多出来的部分”，而是Harness落地的“具体工具和流程”，核心是帮我们高效梳理规则、拆解任务；Skill是“程序员的技术能力”，规则是“约束模型、拆解需求的规范”，二者是Harness落地的核心，写进md文件是为了让模型能精准加载、执行，实现Harness的闭环；程序员的核心任务就是写规则和Skill，深耕的也是这两者，spec-kit是辅助我们做好这件事的工具。

① 疑惑1：Claude Code的4层架构与Harness有啥区别？多了一个SSD吗？多了一个将需求拆解成md指导吗？

答：二者的核心区别是“能力框架”与“完整落地体系”的区别——Claude Code的4层架构，只是Harness的“能力基础”（相当于“有了汽车的发动机、车轮、方向盘”），但缺少“落地的规则和流程”（相当于“没有驾驶规则、没有路线规划，汽车无法正常行驶”）；SSD（Spec Driven Development，规范驱动开发）不是“多出来的部分”，而是Harness落地的“核心流程”，将需求拆解成md指导，是SSD流程的关键步骤，也是Harness落地的核心动作。

具体拆解：Claude Code具备记忆层、执行层、反馈层、编排层，能实现“读写代码、执行单测、反馈报错、拆解任务”的能力，但它不知道“要做什么项目、不能做什么、按什么标准做、调用哪些Skill、分几步做”——这些都需要“规则”来定义；而SSD流程，就是通过spec-kit工具，将项目需求拆成多个阶段，生成约束（规则）、明确需求、指定计划、拆解任务，每次完成一部分就更新Claude.md，让Claude Code的四层架构“有章可循”，这本质就是Harness的落地过程。

简单类比：Claude Code的四层架构是“一个有工具、有动手能力的工人”，Harness是“这个工人+完整的工作流程+工作规范”，SSD流程就是“工人的工作步骤”，md文件就是“工作规范说明书”——工人有能力，但没有规范和步骤，就无法高效完成工作；有了规范和步骤，才能形成完整的工作体系（Harness）。

② 疑惑2：可不可以理解为，本身Claude Code就有Harness的思考了，只是落地还没做需要我们去维护？本质落地就是怎么把任务跑的更好，也就是基本层面上就是让他能做我的需求？

答：这个理解非常接近核心，但不够精准。准确来说：Claude Code具备“实现Harness的基础能力”（四层架构），也隐含了Harness“让模型自主执行任务”的核心思考，但它缺少“落地的核心要素——规则”，所以需要我们去维护（核心就是编写规则、梳理Skill，写入md文件）；而Harness的本质落地，就是“通过规则约束，让Claude Code的四层能力发挥作用，精准完成我们的需求，形成‘需求-执行-反馈-修复’的闭环，让任务跑的更稳、更符合预期”。

比如：Claude Code能执行单测（执行层能力）、能反馈报错（反馈层能力），但它不知道“要测什么、测到什么标准算通过、报错了怎么修复、要调用哪个Skill来修复”——这些都需要我们编写规则，写入md文件，让它知道“做什么、不能做什么、怎么做”，这就是我们需要维护的内容，也是Harness落地的核心。

③ 疑惑3：我一直疑惑，程序员能做的事情，是不是就是去写规则和Skill？这和spec-kit做的事情有什么关联？规则是不是指项目到落地有哪些规则，比如拆解任务、能做什么、不能做什么？这些规则是不是在代替程序员开发时遇到的规范类工作？规则更像是约束和拆解需求，但我又觉得它像程序员的开发技能（Skill），这两者到底有什么区别？——重点厘清：Skill和规则的本质区别（核心疑惑）

答：首先明确：程序员写规则和Skill，不是代替spec-kit做事情，而是spec-kit辅助程序员更高效地写规则、梳理Skill——spec-kit的作用是“拆解需求、生成约束、制定计划”，帮我们把模糊的需求，转化为清晰的规则框架，最终还是需要程序员结合自身Skill，完善规则、明确Skill的调用方式；其次，规则和Skill完全不同，二者是“规范”与“能力”的关系，核心区别如下（深度拆解，一眼分清）：

核心区别：Skill是“程序员的技术能力/经验”，是“能做什么、会做什么”；规则是“约束模型、拆解需求的规范”，是“让模型怎么用Skill、按什么标准做、做什么、不做什么”——简单说，Skill是“能力本身”，规则是“使用能力的说明书+约束条件”。

具体对比（结合开发场景，更易理解）：

• Skill（技能）：是你作为程序员，多年积累的“硬实力”，是“你会做什么”，是可复用的技术经验，无法被替代。比如：
  Skill的核心是“能力”，是你能解决什么技术问题，是Harness落地的“核心支撑”——没有Skill，规则就成了“空壳”（比如规则要求“优化接口性能”，但你没有“接口性能优化”的Skill，就无法把这个规则落地，也无法让模型调用相关能力）。
  • 你会用FastAPI开发接口（这是Skill）；
  • 你会排查Python代码的报错（这是Skill）；
  • 你会编写单测用例、优化接口性能（这是Skill）；
  • 你会用Redis缓存热点数据（这是Skill）。

规则（规范）：是你把自己的Skill，转化为“模型能理解、能执行的约束和步骤”，是“让模型怎么做事”，是Harness落地的“核心引导”。比如：
规则的核心是“约束和引导”，是把你的Skill“标准化、书面化”，让模型知道“怎么用你的Skill，按什么标准完成任务”——没有规则，Skill就无法被模型有效调用，Claude Code的四层能力也无法发挥作用。

• 项目需求拆解规则：“将用户管理模块拆分为‘注册、登录、查询、修改’四个子任务，先开发注册接口，再开发登录接口”（对应我疑惑的spec-kit拆解任务的功能）；
• 约束规则：“不能使用Python 2.x，接口响应时间≤500ms，密码必须加密存储，禁止使用未授权的依赖包”（对应我疑惑的“做什么、不能做什么”相关需求）；
• Skill调用规则：“开发接口时，调用‘FastAPI接口开发Skill’；排查ImportError报错时，调用‘Python包依赖排查Skill’；执行测试时，调用‘单测用例编写Skill’”；
• 测试规则：“每个接口开发完成后，必须运行单测，单测覆盖率≥80%，报错后需优先调用‘报错排查Skill’进行修复”（对应我疑惑的“做完跑单测”相关要求）。

补充：我之所以觉得“规则又像Skill”，是因为规则是基于Skill制定的——规则的内容，本质是我对自己Skill的“梳理和规范”，但二者不能混淆：Skill是“你会做”，规则是“让模型按你的方法做”。比如，你会用FastAPI开发接口（Skill），规则就是“让模型用FastAPI开发接口，遵循RESTful规范、添加类型注解”（规则）——Skill是能力本身，规则是能力的使用规范。

④ 疑惑4：规则和Skill为什么是Harness落地的核心？为什么要写到md里？

答：先解答“为什么是核心”：Harness的本质是“驾驭大模型按规范完成任务”，而大模型本身是“无规则、无经验”的——它需要两个核心支撑：一是“能做事的能力”（Skill，来自程序员的技术积累），二是“做事的规范和步骤”（规则，来自程序员的梳理）。没有Skill，模型就没有“做事的能力”（比如不会开发接口、不会排查报错）；没有规则，模型就不知道“怎么用能力、做什么、不做什么”（比如乱用药Skill、开发不符合需求的代码）。二者结合，才能让Claude Code的四层架构发挥作用，形成“需求-规则- Skill调用-执行-反馈-修复”的闭环，这就是Harness落地的核心逻辑——所以，规则和Skill是Harness落地的“两大支柱”。

再解答“为什么要写到md里”：这是我梳理出的“最轻量的Harness落地方式”，核心原因有3点（结合落地实际，通俗易懂）：

• 适配Claude Code的记忆层：Claude Code的记忆层，需要加载“结构化、清晰化”的信息，才能持续记住核心要求——md文件是纯文本、易编辑、可拆分的格式，能完美适配记忆层的“路由加载”功能（比如把规则拆分为“需求规则、Skill调用规则、测试规则”多个md文件，按需加载），避免核心信息丢失或混乱。
• 方便维护和迭代：Harness的落地不是“一劳永逸”的，需求会变、Skill会更新、规则会优化——md文件编辑简单，每次需求变更、Skill升级，我们可以直接修改md文件中的规则，无需修改Claude Code的四层架构本身；同时，spec-kit生成的约束、拆解的任务，也能直接写入md文件，实现“每次做部分、更新一次Claude.md”（对应我疑惑的SSD流程的核心动作）。
• 实现“人机共识”：md文件是“程序员与模型的沟通桥梁”——程序员把自己的Skill和规则，用md文件的形式写清楚，模型能通过记忆层精准加载、理解，避免“模型误解需求、误用Skill”；同时，其他程序员也能通过md文件，快速了解项目的规则和Skill调用方式，方便协作。

⑤ 疑惑5：人类程序员能深耕的就是这个规则和Skill？怎么深耕？怎么利用spec-kit落地Harness？怎么提升自己写这些东西？怎么用Claude Code落地实现这些？

答：完全正确——AI时代，大模型能替代我们做“重复性的编码、单测、简单报错修复”等工作，而程序员的核心价值，就是深耕“规则”和“Skill”（这是大模型无法替代的），具体深耕方法、spec-kit落地逻辑、Claude Code实现方式，我们逐一拆解（结合技术实践，落地性极强）：

（3）Harness落地实践：结合spec-kit、SSD流程、Claude Code，一步到位

Harness的落地核心是“规则+Skill+md文件+四层架构”，而spec-kit是辅助我们高效落地的工具，SSD是落地流程，Claude Code是能力载体，三者结合，就能实现“规范驱动开发”，完成Harness落地，具体步骤（结合我梳理的实践逻辑）：

1. 第一步：用spec-kit拆解需求、生成初始约束（规则框架）——解决“需求模糊、任务混乱”的问题。

   • 操作：将项目需求导入spec-kit，spec-kit会自动将需求拆分为多个开发阶段（比如“需求分析→架构设计→接口开发→单测→部署”）；
   • 输出：生成初始的约束文件（比如“技术栈约束、需求边界约束”）、开发计划（分阶段任务安排）、子任务拆解（每个阶段的具体工作）；
   • 核心：这一步是“规则的初步梳理”，spec-kit帮我们搭建规则框架，减少我们手动拆解需求的工作量，避免遗漏关键约束。

2. 第二步：结合自身Skill，完善规则，写入md文件（Claude.md）——核心落地动作。

   • 操作：基于spec-kit生成的框架，补充3类核心内容，写入md文件：
     • 约束规则：做什么、不能做什么（比如“不能使用Django框架、密码必须加密”）；
     • Skill调用规则：每个子任务对应调用哪些Skill（比如“接口开发调用FastAPI开发Skill、单测调用单测编写Skill”）；
     • 标准规则：完成标准、测试标准（比如“单测覆盖率≥80%、接口响应时间≤500ms”）。
   • 关键：每次完成一个子任务，就更新md文件（对应我梳理的SSD流程的核心动作），比如“完成注册接口开发后，更新md文件，添加‘注册接口的测试规则、报错修复Skill调用方式’”。

3. 第三步：将md文件加载到Claude Code，依托四层架构执行任务——实现闭环。

   • 操作：把写好的Claude.md文件加载到Claude Code，利用其四层架构，实现“自主执行、闭环迭代”：
     • 记忆层：加载md文件中的规则和Skill调用说明，持续记住核心要求；
     • 编排层：按照spec-kit拆解的子任务、md文件中的计划，分步执行任务；
     • 执行层：调用md文件中指定的Skill，完成编码、单测等操作（比如调用FastAPI开发Skill编写接口，调用单测Skill运行测试）；
     • 反馈层：将单测结果、报错信息回传，模型根据md文件中的规则和Skill，自动修复报错，直到满足完成标准。
   • 核心：Claude Code的四层架构，是规则和Skill的“执行载体”，它让md文件中的规则落地，让Skill被有效调用，形成完整的Harness闭环。

4. 第四步：迭代优化规则和Skill——持续深耕，提升落地效果。

   • 操作：根据任务执行结果，优化md文件中的规则（比如“调整Skill调用顺序、补充新的约束条件”）；同时，提炼新的Skill（比如“遇到新的报错，总结排查方法，形成新的Skill，更新到md文件的Skill调用规则中”）；
   • 核心：Harness的落地不是一次性的，需要持续优化规则、积累Skill，让模型的执行更精准、更高效。

总结：spec-kit的作用是“辅助梳理规则、拆解任务”，Claude Code的作用是“执行规则、调用Skill”，md文件的作用是“存储规则和Skill调用说明”，三者结合，就是我梳理的“SSD流程”，本质就是Harness的完整落地。

二、一线开发工程师视角：深耕规则与Skill，实现自身价值（结合落地，讲清“怎么做”）

结合我自身的核心认知——“有了Harness之后，程序员的任务就是写规则和写Skill”，这里重点拆解：程序员如何深耕规则和Skill，如何提升自己写规则、梳理Skill的能力，以及如何利用Claude Code、spec-kit落地这些能力，彻底解决自身的疑惑。

1. 核心认知：程序员的核心任务，就是写规则和Skill（为什么？）

驾驭工程的出现，彻底改变了程序员的工作模式——从“亲自写每一行代码”，转向“定义规则、封装Skill、让大模型按规则执行代码”。原因很简单：

• 大模型能高效完成“重复性工作”（比如写基础代码、运行单测、修复简单报错），这些工作占用了程序员大量时间，却无法体现核心价值；
• 程序员的核心价值，在于“掌握技术逻辑、制定规范、解决复杂问题”——规则是“规范模型的行为”，Skill是“解决复杂问题的能力”，这两者都是大模型无法替代的（大模型能调用Skill，但无法创造Skill；能执行规则，但无法制定规则）。

所以，作为一线开发工程师，我们不需要再纠结“怎么写基础代码”，而是要聚焦于“怎么写好规则、怎么提炼好Skill”——这才是AI时代程序员的核心竞争力。

2. 如何深耕Skill？（落地性方法，直接能用）

Skill是“你的技术硬实力”，深耕Skill，就是“提升自己解决复杂技术问题的能力”，同时“将零散的经验，转化为可复用、可被模型调用的标准化Skill”，具体方法：

• 第一步：梳理零散经验，形成“Skill模块库”——解决“Skill零散、无法复用”的问题。

  • 操作：每次完成一个开发任务后，花10-15分钟梳理：
    • 这个任务中，我用到了哪些技术能力？（比如“用FastAPI开发接口、用Redis缓存、用Pydantic做参数校验”）；
    • 这些能力中，哪些是可以重复使用的？（比如“FastAPI接口开发模板、Redis缓存配置方法”）；
    • 把这些可复用的能力，整理成“Skill模块”，标注清楚“适用场景、使用方法、注意事项”（比如“FastAPI接口开发Skill：适用后端接口开发，使用方法：导入FastAPI框架，添加路由，使用Pydantic做参数校验，注意事项：需添加类型注解”）。
  • 核心：让零散的技术经验，变成“标准化、可复用”的Skill，为后续写规则、调用Skill打下基础。

• 第二步：深耕核心技术，提升Skill的深度——解决“Skill肤浅、无法解决复杂问题”的问题。

  • 操作：聚焦自己的核心技术领域，不要只停留在“会用”的层面，要深入研究“底层逻辑、优化方法、异常处理”：
    • 比如你擅长Python后端开发：不要只会用FastAPI写接口，还要深入研究“FastAPI的底层原理、性能优化方法、高并发场景的处理、异常捕获的最佳实践”；
    • 比如你擅长前端开发：不要只会用Vue写页面，还要深入研究“Vue的响应式原理、组件封装的最佳实践、性能优化、跨端适配”。
  • 核心：Skill的深度，决定了你能制定的规则的精准度，也决定了你能驾驭大模型的高度——大模型能帮你写基础代码，但无法帮你解决“高并发、底层bug、架构设计”等复杂问题，这些都需要你深耕Skill才能实现。

• 第三步：持续积累新Skill，适配技术迭代——解决“Skill过时、无法适配新需求”的问题。

  • 操作：关注行业新技术、新框架，比如“FastAPI更新了新特性、出现了新的报错排查工具、新的缓存方案”，及时学习并转化为自己的Skill，更新到自己的Skill模块库中；
  • 核心：技术在迭代，需求在变化，只有持续积累新Skill，才能制定出符合新需求的规则，让Harness落地更高效。

3. 如何深耕规则？（落地性方法，结合spec-kit、md文件）

规则是“模型的行为指南”，深耕规则，就是“让规则更精准、更具体、更具可执行性”，同时“利用spec-kit等工具，高效梳理规则”，具体方法：

• 第一步：掌握规则设计的核心原则——“具体、可量化、无歧义、可落地”（避免模糊规则）。

  • 错误示例（模糊、无歧义）：“接口要快、代码要规范、做完要测试”；
  • 正确示例（具体、可量化）：“接口响应时间≤500ms，QPS≥1000；代码符合PEP8规范，变量命名用蛇形命名法；每个接口开发完成后，必须运行单测，单测覆盖率≥80%，报错后优先调用‘报错排查Skill’”；
  • 核心：规则越具体，模型越能精准执行，避免“误解需求、无效执行”，这也是我梳理的“让任务跑的更好”的核心关键。

• 第二步：利用spec-kit，高效梳理规则框架——减少手动工作量，避免遗漏。

  • 操作：将项目需求导入spec-kit，借助其“需求拆解、约束生成”功能，先搭建规则的基础框架（比如“阶段划分、核心约束、任务拆解”），再结合自己的Skill，补充细节规则；
  • 核心：spec-kit不是“替代你写规则”，而是“帮你梳理思路、搭建框架”，让你能更专注于“规则的细节优化”，提升规则的质量。

• 第三步：结合执行反馈，持续优化规则——让规则更适配需求。

  • 操作：Claude Code按规则执行任务后，关注执行结果：
    • 如果模型执行不符合预期（比如调用了错误的Skill、未遵守约束），说明规则不够清晰，需要修改规则（比如“明确Skill的调用场景、补充约束细节”）；
    • 如果需求变更，及时更新md文件中的规则（比如“新增‘接口需支持分页’的约束，补充‘分页Skill’的调用规则”）；
    • 每次优化后，重新加载md文件到Claude Code，验证执行效果，形成“规则优化-执行验证-再优化”的闭环。

• 第四步：学习优秀规则案例，提升规则设计能力——借鉴经验，少走弯路。

  • 操作：查看行业内优秀的Harness落地案例，重点关注其md文件中的规则设计（比如“如何拆解任务、如何定义约束、如何关联Skill”），借鉴其思路，结合自己的项目和Skill，优化自己的规则；
  • 核心：规则设计是“能力”，需要不断学习、借鉴，才能提升，让自己写的规则更高效、更落地。

4. 如何利用Claude Code，落地规则和Skill？（具体操作，贴合一线开发）

Claude Code是规则和Skill的“执行载体”，核心是“让模型按md文件中的规则，调用你的Skill，完成任务”，具体操作步骤（简单易上手）：

1. 准备工作：整理好自己的Skill模块库，编写好md文件（包含规则、Skill调用说明、任务拆解等内容）；
2. 加载md文件：打开Claude Code，将写好的Claude.md文件加载到其记忆层（部分版本支持直接上传md文件，或复制粘贴md内容）；
3. 明确任务指令：向Claude Code下达核心任务（比如“开发用户注册接口”），无需过多细节，因为md文件中已经明确了规则和Skill调用方式；
4. 监控执行过程：Claude Code会依托执行层、编排层，按md文件中的规则，调用指定的Skill，分步执行任务（比如“调用FastAPI开发Skill编写接口→调用单测Skill运行测试→调用报错排查Skill修复问题”）；
5. 验证与优化：任务执行完成后，验证结果是否符合md文件中的标准，若不符合，修改md文件中的规则或Skill调用方式，重新执行，直到满足需求。

核心提示：Claude Code的落地，关键是“md文件的质量”——规则越清晰、Skill调用越明确，执行效果越好；同时，要善用其反馈层，让模型自动修复问题，减少你的手动干预。

三、程序员提升自身修养：以规则和Skill为核心，实现高效成长

驾驭工程的兴起，不仅改变了开发模式，也对程序员的自身修养提出了新的要求——不再是“写代码越快越好”，而是“能提炼Skill、制定规则、复用能力”，成为“会驾驭大模型的高效工程师”。结合前面的内容，给你3个具体的提升方向，帮你更好地深耕规则和Skill，提升自身价值：

1. 培养“模块化思维”：让Skill可复用、规则可落地

很多程序员的Skill是“零散的”——会写接口、会排查报错，但没有把这些经验拆解开、标准化；规则是“混乱的”——没有清晰的框架，想到什么写什么。而有模块化思维的程序员，会把“Skill拆分为标准化模块，规则拆分为清晰的分类”（比如“规则分为需求约束、Skill调用、测试标准三类”），让Skill能被反复调用，规则能被模型精准理解。

建议：每次完成一个任务后，花10分钟梳理——这个任务中，哪些部分是可以重复使用的（提炼Skill模块）？哪些约束是可以标准化的（梳理规则）？把这些内容记录下来，逐步积累自己的“Skill模块库”和“规则模板”，后续开发可以直接复用，提升效率。

2. 提升“规则设计能力”：让你的规则能被模型理解、能落地

规则设计，是连接你和大模型的关键——你写的规则，既要符合自己的Skill，也要让大模型能精准理解（避免模糊、歧义）。这需要你多站在“大模型的角度”思考：这样的规则，它能看懂吗？能按规则执行吗？

建议：写规则时，遵循“具体、可量化、无歧义”的原则，多做“测试验证”——写完规则后，加载到Claude Code，下达简单任务，看看模型的执行效果，根据反馈调整规则；同时，多借鉴优秀的规则案例，学习别人的设计思路，提升自己的规则设计能力。

3. 保持“技术深耕”：Skill的深度，决定你能驾驭的高度

驾驭工程不是“让程序员不用学技术”，而是“让程序员从重复性工作中解放出来，深耕更核心的技术”。大模型能帮你写代码、排查简单报错，但无法帮你解决复杂的技术难题——比如高并发场景的架构设计、底层bug的排查、技术选型的决策。

建议：在复用Skill、写规则的同时，持续深耕自己的核心技术领域——比如你擅长后端开发，就深入研究分布式系统、微服务架构、数据库优化；你擅长前端开发，就深入研究性能优化、跨端开发、工程化部署。你的Skill越深入，制定的规则就越精准，驾驭大模型的能力就越强，自身的核心竞争力也就越强。

四、总结（解决所有疑惑，梳理核心重点）

结合我自身的所有疑惑和技术梳理，这里做一次全面总结，确保彻底理解：

1. Claude Code的四层架构与Harness的关系：Claude Code的记忆层、执行层、反馈层、编排层，是Harness的“基础能力框架”（有能力，但无规范）；Harness是“四层架构+规则+Skill+md文件+闭环流程”的完整落地体系——二者是“能力载体”与“完整体系”的关系，不是“多了某一部分”，而是“补全了落地所需的规则和流程”。
2. spec-kit与SSD流程的作用：spec-kit是Harness落地的“辅助工具”，核心是拆解需求、生成规则框架；SSD（规范驱动开发）是Harness落地的“核心流程”，核心是“用spec-kit拆解需求→写md规则→加载到Claude Code执行→更新md迭代”，本质就是Harness的落地过程。
3. Skill与规则的核心区别：Skill是“程序员的技术能力/经验”（会做什么），是Harness落地的“能力支撑”；规则是“约束模型、拆解需求的规范”（让模型怎么用Skill、按什么标准做），是Harness落地的“引导核心”——规则基于Skill制定，Skill通过规则被模型调用，二者缺一不可。
4. 规则和Skill写进md文件的原因：适配Claude Code的记忆层，方便加载和维护；实现“人机共识”，让模型精准理解；适配SSD流程，实现“每次迭代更新规则”，让Harness落地更高效。
5. 程序员的核心任务与深耕方向：核心任务是写规则和Skill；深耕Skill，就是梳理零散经验、深耕核心技术、积累新Skill，形成可复用的Skill模块库；深耕规则，就是遵循“具体、可量化”原则，利用spec-kit梳理框架，结合执行反馈持续优化；同时，善用Claude Code，让规则和Skill落地，实现高效开发。
6. 核心认知：Harness的本质是“驾驭大模型按规范完成任务”，Claude Code是能力载体，spec-kit是辅助工具，md文件是沟通桥梁，规则和Skill是核心支柱；AI时代，程序员的价值不在于“写多少代码”，而在于“能制定多少精准的规则、能提炼多少有价值的Skill”——这才是我们能持续成长、不被替代的核心竞争力。

最后要明确：驾驭工程不是“替代程序员”，而是“解放程序员”——它让我们从繁琐的重复性编码中解脱出来，聚焦于更有价值的技术深耕、规则设计和问题解决。作为一线开发，学会提炼Skill、制定规则，善用spec-kit和Claude Code落地Harness，不仅能适配AI时代的开发模式，更能实现自身能力的复用和快速成长。