从Anthropic论文到工程落地：Harness engineering结合claude code，讲解四层前端架构规范

AI 时代许多人都体验过了vibecoding但结果不同。同一个需求不同的人用 AI 写出来的代码质量可能差很远。有的人能跑出一个中型功能PR 干干净净的有的人用 AI 写出来的架构乱、命名乱、功能能跑但改不动。AI编程时有一个结果叫 drift漂移——模型在长周期任务里每个 step 都在做看起来合理的局部决策但这些局部最优累积起来就慢慢偏离了最初的目标。上下文越来越长的时候模型对最初目标的记忆会越来越模糊对架构约束的遵守也会越来越松。就像开车方向盘慢慢歪了车身跑偏自己还察觉不到。AI 编程的结果大致分三种on-track在轨道上符合预期、bonus超预期、以及 drift。出现这种情况很正常因为现阶段的AI就是基于transformer架构来生成的一个推理模型。很多人其实并没有掌握 AI 编程 的技巧——靠提示词调靠运气这些是远远不够的。二、把感觉不错变成可量化标准我们通常觉得AI 编程质量不稳定是 AI 的问题但实际上这是我们自己的问题——因为我们从来没有告诉过 AI好到底长什么样。你跟 AI 说写一个高质量的模块这句话对 AI 来说是一个无效指令。LLM 本质上是一个无情的高分计算机器。它返回给你的内容不是它真的想出来的是概率最高的几个答案里挑一个。它不是不想做好它是真不知道你心里的高质量是啥。前两天我看到了一篇Anthropic工程师的论文《Harness Design for Long-Running Application Development》https://www.anthropic.com/engineering/harness-design-long-running-apps。里面讨论Harness Engineering并且提出一个问题“Is this design good?” → “Does this design follow our principles?”翻译成人话就是不说你要做好而是明确好的标准是什么。这就是工程化思维。你把主观质量评判翻译成可量化的规则AI 才能真正执行。标准越具体AI 的输出越稳定。三、Anthropic 论文里的三套实践论文的核心思路很清晰总共提出三套实践方案第一套角色分离互相对抗三个角色各干各的事Planner把一句话需求展开成完整的产品规格说明书。Generator一次做一个功能做完自我评估再交出去。Evaluator独立裁判用确定性程序评分低于阈值就打回重来。关键点就一个——Generator 和 Evaluator 必须分离。模型有一个根深蒂固的问题评估自己工作的时候总是过度宽容。你让模型自己写代码再自己打分它大概率会给自己打较高的分数偶尔谦虚下说还有提升空间。这是由于agent它本身就记录了之前的上下文在它的思考链路里得出最后的结果是合情合理的。开发和审查的人一定要分离只有以第三者的视角才能看出其中不通顺的地方。分离之后Evaluator 可以被独立调优。评审的过程可以尽量按照你的思路来不受前面开发过程的干扰。更新提示词反复迭代直到打分靠谱为止。第二套四维标准给设计质量打分论文里做前端设计实验设了四个评分维度。我把它映射到代码工程是这样的Design Quality 架构一致性模块之间是不是真的对齐还是东一块西一块拼起来的模型在架构设计上很容易 drift如果不加约束的话它只会跟着你的上下文接着写不是在按架构写。架构中一定要强调在压缩的时候不能被上下文所遗忘。Originality 架构创新举个例子你写的网页是不是蓝白画风你拿AI生成的文字文章是不是堆双引号模型默认走最安全的路输出很容易变成AI 味道。在设计时。一定得强调自己所偏好的范式。最好是能给出实际的例子。Craft 代码质量命名规范、类型安全。这个维度模型本来就能做好不需要特别强调。目前的开发工具中有很多代码审查的工具比如eslint。Functionality 功能正确性用户能不能真的用起来首先需要agent去做大量的单元测试以及自动化测试并且最终借助于一些容器化部署的手段比如docker让用户的环境和你保持一致。论文结论是Design Quality 和 Originality 是需要被明确约束的因为模型默认在这两项上表现平庸。第三套Sprint 合同动手之前先对齐Generator 动手之前先说清楚自己要做什么功能验收标准是什么Evaluator 审核这个计划双方达成一致再开始写代码。简单说就是事前对齐事后不返工。翻译一下说白了就是开发的实际文档和审查的实际文档要来自同一份文档也就是项目的产品文档。这个思路在目前的很多规范驱动开发中已经有所体现也就是 spec-kit你有没有发现上述这些问题实际上在正常的开发团队中不使用AI也是会经常出现只能说AI现在是越来越像人了我们要拿更多工程化的思维来管理。四、一个工程实例harness怎么落地说完了理论来看看一个真实工程是怎么把这个框架落地的。这个工程叫 Neutree UI是一个基于 React Refine shadcn/ui 构建的管理后台。它的特别之处在于用一整套确定性程序来约束 AI 的行为。让 AI 在没有人盯着的情况下也能按照架构规范写代码。先说一个已经达成共识的东西就是spec文档的对齐现在有很多的解决方案。Generator 要做什么、Evaluator 怎么评分这两个东西在开发之前就基于同一份规格文档各自生成。Generator 从 spec 里提取要实现的功能Evaluator 从同一份 spec 里提取验收标准两者天然同源不需要人工介入对齐。这个工程的做法是把这份规格文档写成了一份四层架构规范后面会提到明确了每一层的职责和依赖规则。Generator 知道要做什么Evaluator 知道要检查什么两者引用的是同一套标准。Evaluator 的职责被拆分成了一个个具体的确定性程序。下图是三套实践和工具的完整对照这六种工具在 CI 里是怎么串联的代码提交 ↓1. dependency-cruiser 架构一致性检查最宏观发现 drift 最早 ↓2. knip 死代码检测 ↓3. biome lint 格式 i18n 检查 ↓4. vitest 单元测试最微观验证具体逻辑 ↓5. Playwright E2E 测试端到端验证完整流程 ↓6. i18n-tracker 翻译规范检查 ↓全部通过 → merge任一失败 → 打回越靠前的工具检查维度越宏观、修复成本越低越靠后越微观。每个工具对应四维标准里的不同维度互相补充不是替代关系。在说工具之前先把这个工程的核心规格文档说清楚——它是怎么把四维标准变成可执行规则的。四层架构规范这个工程最终产出物是一个 React 管理后台页面。它的开发过程是从 L0 开始一层层拼装到 L3L0 components/ui/ — shadcn/ui 基础组件Button、Dialog、Select 等L1 foundation/ — 共享基础设施hooks、lib、providers、typesL2 domains/生成过程是从左往右先有 L0 基础组件 → 再有 L1 基础设施 → 再有 L2 领域逻辑 → 最后拼出 L3 页面。依赖方向只能上层依赖下层不能反过来依赖方向是单向的只能上层调用下层但是传递过程是底层往外传比如 L2 的 user 模块直接 import 了 L0 的 Buttondependency-cruiser 会直接报错。各层的目录结构L1 foundation/ 放跨领域共享的 components、hooks、lib、providers、typesL2 domains/ 放某个资源专属的逻辑每个资源一个目录types.ts 放在根目录L3 pages/ 放路由视图每个资源有 list、create、edit、show 四个文件一个功能应该写在哪一层有明确规则新的 shadcn/ui 基础组件 → L0跨领域共享的 form/table/type → L1某个资源专属的逻辑 → L2CRUD 页面和表单 → L3这就是 Generator 和 Evaluator 共同引用的那份spec——它不只是规范更是代码的物理布局规范。Generator 知道往哪写Evaluator 知道去哪查。规则用户模块属于 L2 → 路径src/domains/user/ → 允许引用L1 foundation、L0 components/ui → 禁止引用L3 pages// Generator 读规格 → 知道往哪写生成(用户模块) → 查规格用户模块 → src/domains/user/ → 在 src/domains/user/ 下生成文件// Evaluatordependency-cruiser读规格 → 知道要检查什么检查(src/domains/user/UserList.tsx) → 查规格L2 的规则是禁止引用 L0 → 发现 import 了 L0 组件 → 报错这里先回答一个问题各个工具是怎么在不同的时候知道要跑上述的四层架构分两套机制1.CI 自动跑 — GitHub Actions 钩子配置文件在.github/workflows/test.yml。PR 提交就自动触发失败就拦着不让合入这是硬性约束。2.AI Agent 自动跑 — Claude Code 启动时会自动读项目根目录的 CLAUDE.md这是它的行为准则。它长这样## ArchitectureThis project uses a **4-layer model**:L0 components/ui/ shadcn/ui primitives onlyL1 foundation/ Shared infrastructureL2 domains/name/ Resource-specific logicL3 pages/name/ Route-level views**Dependency direction**: Higher layers import lower layers only. Never the reverse.## Harness / Quality Gates1. **Architecture** — dependency-cruiser enforces L0→L1→L2→L3 dependency direction2. **Dead code** — knip detects unused files, dependencies, exports3. **Code quality** — biome lint format (replaces ESLint Prettier)4. **I18n enforcement** — i18n-tracker CI ensures all user-facing text is translated5. **Unit tests** — vitest for pure functions, hooks, form validation logic6. **E2E tests** — Playwright for full-page workflows## Commandsyarn dep-check # 架构一致性检查yarn knip # 死代码检测yarn lint # Biome lintyarn test # 单元测试yarn test:e2e # E2E 测试yarn dep-check、yarn knip 不是 React 自带的东西它们都是 Node.js 的包装在项目里当开发依赖。这些命令本质上是「静态代码分析工具」只是恰好这个工程用了 React TypeScript所以它们分析的是 TypeScript 代码。换一个 Node.js 后端项目、或者 Vue 项目只要用了 TypeScript一样能用这些工具检查代码质量。下面逐个说每个工具怎么配合起来形成链路。详细讲第一个其他都差不多让AI去找相关的包就可以了。dependency-cruiser架构一致性它解决什么问题模型在长周期任务里会 drift明明架构文档里写了四层模型它就是会在某个续上下文的瞬间把依赖关系写反——L2 模块直接 import 了 L0 的组件。它扫一遍所有源码构建出完整的依赖图拿规则去核对。规则写在 .dependency-cruiser.cjs 里本质上就是正则匹配哪些路径的模块不能 import 到哪些路径。{ name: no-L1-import-L2-L3, // L1 不能引用 L2/L3 from: { path: ^src/foundation/ }, to: { path: ^src/(domains|pages)/ },}跑出来报错是这样的error src/domains/user/UserList.tsx → src/components/ui/Button.tsx Rule violation: no-L2-import-L0 L2 modules are not allowed to import L0 components报错说清楚了哪个文件的哪一行破了哪条规则。AI 看到就知道要把那个 import 删掉。结合前面的映射图每个工具对应的是四维标准里的不同维度knip死代码检测对应 Craft代码质量。AI 写代码经常产生看起来存在但实际没用的东西——写了但从没调用的函数、import 了但没用的模块、依赖装上了但整个没用上。knip 专门扫这些扫出来就删不用人工判断。biomelint 格式 i18n 检查对应 Craft代码质量。三合一工具取代 ESLint Prettier。除了基本的代码风格检查还有一条自定义规则禁止直接用 refine 的 useTranslate必须统一走项目的 useTranslation。这是项目自己的 i18n 规范不是默认规则。vitest单元测试对应 Functionality功能正确性。模型说功能实现了——但模型自己说的不算得有测试来验证。测纯函数、hooks、表单验证逻辑不测组件布局。模型默认会把功能看起来写对了单元测试是最低成本的验证手段。PlaywrightE2E 测试对应 Functionality功能正确性。vitest 只测函数和 hooksPlaywright 测的是用户真的能用这个页面完成一个任务吗。它会启动真实的浏览器模拟用户操作——打开页面、填表单、点按钮、等待响应——验证整个流程能不能走通。i18n-tracker翻译规范检查对应 Craft代码质量。AI 写代码经常把中文提示字符串直接写在代码里没走翻译流程。它记录哪些文件已经过了翻译检查CI 对比这次 PR 修改了哪些文件如果文件没在记录里就说明有新增字符串没翻译直接 fail。CIgithub提交前强制检测对应 Sprint合同事后检查。上面所有工具的检查都会在 CI 里汇总。代码跑不过任何一个对不起不能 merge。这个约束是硬的不是软的。完整 Harness Engineering 流程有几个关键点要说一下1.需求和规范是两回事。在 AI Coding 的实践里有几个相关的工具和框架可以帮助你把这套思路落地Spec-Kitspec-kit skill——帮你把需求文档结构化定义清晰的规格标准让 AI 生成的内容有据可依。Superpowerssuperpowers 相关技能——提供了 AI 编程任务拆解和执行的工作流框架和这里讲的 Planner/Generator/Evaluator 三角色思路是同一套逻辑的不同实现。spec-kit / superpowers 帮你把需求说清楚CLAUDE.md 帮你把开发规范定清楚。前者管「做什么」后者管「怎么做」。是可以完全共存的。还有个更简单的方式。可以把claude.md中的内容直接迁移到spec-kit或者superpowers的plan阶段2.AI 写完代码和提交前都会检查。写完代码 AI 自己会主动跑检查命令看到报错当场就修不等到提交之后。3.CI 失败的信息可以传给AI。目前这个项目中的一个小缺点GitHub CI 不会自动通知 AI需要你把错误信息告诉 AI或者在下一轮对话里说「帮我看看 CI 报了什么错」。但是我觉得思路上有各种方法。这个项目目前只是简单的口述化让它依照claude.md进行开发。还没有用到spec-kit完全可以在提示词中去规定它检查git提交的输出。失败了就根据原因去修复。甚至可以让他自己在pr阶段就审核代码添加一条评论评论里开发的subagent进行修改。你看方法总比困难多AI真是太好用了~~尾声好了这一篇讲Hannes Engineering落地的文章也相当的干~~说清楚你想要什么把主观质量翻译成量化标准——架构文档、依赖规则、lint 规则、测试覆盖要求。建一套系统来验证就是把 Evaluator 的职责拆成具体的确定性程序让机器替你执法而不是靠 AI 自觉。Harness Engineering 要做的事把人的判断力编码进机器可以执行的标准里。模型是强是弱是不确定的。新的模型肯定越来越强。但标准是确定的工具是确定的反馈是确定的。越会编排的开发者与AI人机协作就会越强。Harness Engineering必然是今后的重点探讨方向。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】