我把 Anthropic 的 Harness 工程思想做成了一个 Skill

用AI写代码，难在哪儿？

用AI生成代码本身并不难，真正的挑战在于让它稳定地交付一个真正可用的东西。这篇文章，我们就来聊聊Anthropic工程团队是如何破解这个难题的，以及我如何将这套方法论落地成了一个可以复用的实战工具。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

用 AI 写代码有多难？不是写不出来难，是让它稳定交付可用的东西很难。这篇文章说说 Anthropic 工程团队的解法，以及我怎么把它落成了一个可以复用的 Skill。

今年三月，Anthropic的工程博客发表了一篇重磅文章：《Harness design for long-running application development》。

作者Prithvi Rajasekaran开篇就点明了核心：

Harness design is key to performance at the frontier of agentic coding.

说白了，框架设计的好坏，直接决定了AI在复杂代码任务上的表现天花板。

研读之后，我花了几天时间将这套思想工程化，落地为一个可以直接调用的WorkBuddy Skill，并开源在GitHub上。接下来，就详细说说背后的思考与具体的实现路径。

01 前沿团队遇到了什么“坑”？

但凡用过AI辅助编程的开发者，大概都经历过这种绝望：AI信誓旦旦地说代码写完了，可你一运行，界面没反应、数据没存上、错误不提示……功能根本跑不通。

更让人头疼的是，AI还特别善于“礼貌地敷衍你”。它总是回复“好的，已修复”，但下一轮迭代，同样的问题又会换个方式冒出来。

Anthropic的工程团队在用Claude进行长周期Web应用开发时，系统性地遇到了上述所有问题。他们一针见血地指出：AI执行长任务时，核心挑战早已不是“能否生成代码”，而是“生成的代码是否可靠”。

上下文溢出、自我评估失真、任务状态在对话中丢失——任何一个环节出错，都足以让整个开发流程崩盘。尤其是让同一个Agent既写代码又评估代码，结果往往是“自己给自己放水”，代码描述写得天花乱坠，实际功能一塌糊涂。

他们的解决方案，从生成对抗网络（GAN）中获得了灵感：将“生成”与“评估”这两个角色彻底分离。

一个智能体专心创造，另一个智能体专注挑刺。两者之间用明确的“迭代契约”来约定交付标准，并且，评估者必须通过Playwright等工具进行真实的端到端测试，而不是对着代码凭空臆测。

⚡ 核心洞察
将执行者和评判者分离，是解决AI自评估失真的关键杠杆。这相当于为开发流程引入了天然的制衡机制。

02 从理论到工具：如何构建可复用的技能？

Anthropic的文章精辟地阐述了设计原则，但并未提供开箱即用的工具。我的工作就是把这套原则“编码”成具体的约束条件，并结合规划、前端设计、全栈开发等其他技能，打包成一个完整的WorkBuddy Skill，让AI在任何新项目中都能自动遵循这套高可靠性的工作流。

整个框架围绕三个核心角色展开：

规划者（Planner）：负责将用户一两句话的模糊需求，扩展成完整的产品规格说明书，并拆解为结构化的功能清单。每个功能都明确包含描述、优先级、端到端测试步骤以及初始状态标记。

这里有一条硬性规则：草稿完成后必须暂停，输出结构化摘要等待用户明确确认。方向一旦跑偏，后续所有努力都可能白费。在规划阶段对齐，成本远低于开发到一半再推倒重来。

实现者（Generator）：按照严格的测试驱动开发节奏，增量式实现功能。每个功能的开发都必须经历六个不可跳过的步骤：选择功能、创建特性分支、先写失败测试、实现代码让测试通过、端到端验收、合并代码并打标签。

其中第三步——“先写失败的测试”——至关重要。这个TDD约束从根本上解决了“AI宣称完工”的问题：测试红灯，就是未完成；测试绿灯，才算真完成。状态完全通过仓库文件同步，不依赖脆弱的对话历史。

验收者（Evaluator）：这是一个完全独立的角色，使用浏览器自动化工具进行端到端测试、截图存证，并从四个维度进行打分。任何一项低于及格线，该功能就会被标记为失败，实现者无权自行评判。

这三个角色中，验收者的独立性是关键中的关键。代码好不好用，不是开发者自己说了算，而是由另一个“冷酷”的智能体，用真实的浏览器运行结果来裁决。

03 六道防线，堵住AI的“捷径”

设计一个工作流模型不难，难的是防止AI在各种现实场景中“偷懒”或“跑偏”。为此，框架内嵌了六道防线，每一道都针对一种常见的失败模式：

防线一：对抗上下文溢出。 多轮对话后，AI开始“遗忘”早期决策。解法是每一轮任务都开启全新的上下文窗口，所有状态通过版本库中的文件传递，让上下文负担归零。

防线二：杜绝虚假完工。 AI口头承诺已完成，实则功能残缺。解法是强制进行端到端测试，只有验收者签字确认，功能状态才能被标记为完成。

防线三：破除自评估放水。 自己评价自己，标准必然放松。解法是设立完全独立的验收者，并要求其提供浏览器截图作为客观证据。

防线四：打破设计模板化。 AI生成的界面往往千篇一律。解法是在前端设计引导中明确要求“规避通用AI模板”，鼓励加入定制化设计细节。

防线五：纠正方向跑偏。 规划阶段若自作主张，后期代价巨大。解法是规划草稿完成后强制暂停，必须获得用户对结构化摘要的明确确认。

防线六：化解合并冲突。 多智能体并行开发易产生代码冲突。解法是通过模块所有权划分、接口契约冻结和串行合并队列三层机制，来系统化管理并行开发。

04 实战检验：一个极简待办应用的诞生

框架设计得再好，也需要真刀真枪的实战检验。我使用这套框架完整开发了一个极简的待办清单Web应用，技术栈选用了React 18 + TypeScript + Vite，设计上追求极简的黑白灰风格，零UI库依赖。

在规划阶段，需求被拆解为10个功能，并划分了优先级。用户确认规格后，实现者开始增量开发。

最终，7个核心功能全部交付，验收者运行了17条端到端测试全部通过，给出了10分的满分评价。

整个过程中，没有一次代码被直接提交到主分支，也没有依赖对话历史来传递任务状态。

最直观的感受是，每一轮任务的边界都异常清晰。你清楚地知道这一轮要做什么、完成的标志是什么、由谁来确认。这种确定性，让AI的输出从“碰运气”变成了“可预期”。

项目完整代码和Skill本身均已开源，可供参考与实践。

05 来自前沿的两句箴言

Anthropic原文中有两句话，尤为值得铭记。

第一句，关于工程本质：

The key insight is that long-running agent tasks are not just “bigger” versions of single-turn interactions. They require fundamentally different engineering primitives: state management, error recovery, progress tracking, and independent evaluation.

长周期智能体任务，绝非单轮交互的简单放大。它需要一套完全不同的工程基础组件：状态管理、错误恢复、进度跟踪以及独立评估。而我们构建的框架，正是将这些“原语”转化为AI开发中的默认规则。

第二句，关于未来方向：

The space of interesting harness combinations doesn’t shrink as models improve. Instead, it moves, and the interesting work for AI engineers is to keep finding the next novel combination.

随着模型能力进化，有价值的框架组合空间不会缩小，而会发生转移。AI工程师的有趣工作，就在于持续寻找下一个新颖而有效的组合方式。

说到底，框架设计不是一劳永逸的解决方案。每一次模型能力的跃迁，都会让旧框架的某些部分过时，同时开启新的可能性。这是一个需要持续演进和创新的工程领域。

如果你也在使用AI进行全栈开发，并曾深受文章开头那些问题的困扰，那么这套框架或许值得一试。

把握AI浪潮：系统化学习路径参考

当前，AI大模型的浪潮已席卷各行各业。无论是企业转型还是个人职业发展，掌握相关技能都显得尤为重要。对于有技术背景，尤其是后端开发经验的朋友来说，转向AI大模型应用开发是一个高潜力的选择。

即便不考虑立即转岗，理解大模型、RAG、智能体等核心概念，并能动手完成简单项目，也无疑是简历上亮眼的加分项。

一份系统化的学习路径通常涵盖以下几个关键模块：

基础认知： 了解大模型核心原理、发展历程及主流模型特点。
核心技术： 深入掌握RAG、Prompt工程、智能体开发等实战模块。
开发基础： 巩固Python，学习API调用与大模型开发框架。
场景应用： 尝试开发智能问答、知识库、AIGC工具等实际项目。
全流程实践： 走通从需求拆解、技术选型到模型调优、上线运维的完整流程。
求职准备： 解析岗位要求，打磨项目经历，应对高频面试题。

上述每个模块都有扎实的内容需要消化。抓住时代机遇，系统化地构建知识体系，是在这波AI浪潮中保持竞争力的关键。

相关学习资料已整理，可通过官方渠道免费获取。