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 开始，一层层拼装到 L3：
L0 components/ui/ — shadcn/ui 基础组件（Button、Dialog、Select 等）L1 foundation/ — 共享基础设施（hooks、lib、providers、types）L2 domains/生成过程是从左往右：先有 L0 基础组件 → 再有 L1 基础设施 → 再有 L2 领域逻辑 → 最后拼出 L3 页面。依赖方向只能上层依赖下层，不能反过来：
依赖方向是单向的，只能上层调用下层，但是传递过程是底层往外传：
比如 L2 的 user 模块直接 import 了 L0 的 Button，dependency-cruiser 会直接报错。
各层的目录结构：
- L1 foundation/ 放跨领域共享的 components、hooks、lib、providers、types
- L2 domains/ 放某个资源专属的逻辑，每个资源一个目录，types.ts 放在根目录
- L3 pages/ 放路由视图，每个资源有 list、create、edit、show 四个文件
一个功能应该写在哪一层，有明确规则：
- 新的 shadcn/ui 基础组件 → L0
- 跨领域共享的 form/table/type → L1
- 某个资源专属的逻辑 → L2
- CRUD 页面和表单 → L3
这就是 Generator 和 Evaluator 共同引用的那份spec——它不只是规范，更是代码的物理布局规范。
Generator 知道往哪写，Evaluator 知道去哪查。
规则：用户模块属于 L2 → 路径：src/domains/user/ → 允许引用：L1 foundation、L0 components/ui → 禁止引用：L3 pages// Generator 读规格 → 知道往哪写生成("用户模块") → 查规格：用户模块 → src/domains/user/ → 在 src/domains/user/ 下生成文件// Evaluator（dependency-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 专门扫这些，扫出来就删，不用人工判断。
biome：lint + 格式 + i18n 检查
对应 Craft（代码质量）。三合一工具，取代 ESLint + Prettier。除了基本的代码风格检查，还有一条自定义规则：禁止直接用 refine 的 useTranslate，必须统一走项目的 useTranslation。这是项目自己的 i18n 规范，不是默认规则。
vitest：单元测试
对应 Functionality（功能正确性）。模型说功能实现了——但模型自己说的不算，得有测试来验证。测纯函数、hooks、表单验证逻辑，不测组件布局。模型默认会把功能"看起来写对了"，单元测试是最低成本的验证手段。
Playwright：E2E 测试
对应 Functionality（功能正确性）。vitest 只测函数和 hooks，Playwright 测的是"用户真的能用这个页面完成一个任务吗"。它会启动真实的浏览器，模拟用户操作——打开页面、填表单、点按钮、等待响应——验证整个流程能不能走通。
i18n-tracker：翻译规范检查
对应 Craft（代码质量）。AI 写代码经常把中文提示字符串直接写在代码里，没走翻译流程。它记录哪些文件已经过了翻译检查，CI 对比这次 PR 修改了哪些文件，如果文件没在记录里就说明有新增字符串没翻译，直接 fail。
CI：github提交前强制检测
对应 Sprint合同（事后检查）。上面所有工具的检查，都会在 CI 里汇总。代码跑不过任何一个，对不起，不能 merge。这个约束是硬的，不是软的。
完整 Harness Engineering 流程：
有几个关键点要说一下：
- 1.需求和规范是两回事。
在 AI Coding 的实践里，有几个相关的工具和框架可以帮助你把这套思路落地：
Spec-Kit（spec-kit skill）——帮你把需求文档结构化，定义清晰的规格标准，让 AI 生成的内容有据可依。
Superpowers（superpowers 相关技能）——提供了 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时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
