本文结合Claude官方最佳实践与真实项目经验，阐述AI编程的三个阶段：Vibe Coding、Spec-driven Coding和Harness工程。重点介绍Harness框架的五个扩展点（CLAUDE.md、Hooks、Skills、Plugins、MCP Server）及子代理能力，适合参与复杂项目的开发者参考。核心建议：先对齐需求再写代码，用自动化规则替代提示词记忆，避免复杂项目中的返工和跑偏。
Tags:
本文字数 3112，阅读大约需 6 分钟
最近这段时间更新公众号频率有所下降，是因为在参与一个开发项目。
具体是什么项目就不展开了，涉及一些隐私。
项目本身还是有一定复杂程度的，涉及三个平台、十几个业务模块、大量复杂表格和表单。而且我做的还是自己并不擅长的前端。
但最终从结果上来看，完成得还是不错的。
事后，我复盘了一下，我发现能做好不只是因为 AI 能力很强。
还有一些不是那么「性感」的因素：动手前的准备、过程中的对齐机制、验证环节的门禁等。这些听起来很老派的工程习惯，反而是整个项目最核心的支撑。
刚好最近看到 Claude 官方发了一篇文章，讲的是 Claude Code 在大型项目中的最佳实践。
读完有一种「豁然开朗」的感觉，我在项目里模糊感知到的东西，这篇文章用一个框架给串了起来。
今天想结合这篇文章和我自己的经历，聊聊 AI 编程这件事，到底该怎么做才能更靠谱。
大多数人的 AI 编程方式
2025 年初，Andrej Karpathy 发了一条推文，给一种新的编程方式取了个名字：Vibe Coding（氛围编程）。
什么意思呢？
简单说就是：用自然语言告诉 AI 你想要什么，AI 生成代码，你基本不看代码细节，只看最终效果能不能用。
「just vibe with it」，跟着感觉走就行。
这种方式为什么火？因为门槛极低。
你不需要懂编程语言的语法，不需要理解框架的运作原理，甚至不需要知道代码写在了哪个文件里。说几句话，一个网页就出来了。
快感是即时的。
但问题来了。
当项目稍微大一点、复杂一点，Vibe Coding 就开始撑不住。
你让 AI 加一个功能，它把之前的逻辑改坏了。
你想改一个 bug，它改完又冒出两个新的。
你要加一个新页面，风格跟前面完全对不上。
你回头想看看代码到底怎么回事，发现自己根本看不懂。
因为从头到尾你就没看过。
这种体验，用过 AI 编程的人应该都不陌生。
Vibe Coding 本身没有问题。拿来做原型验证、写个人小工具、跑一次性脚本，完全没毛病。
问题在于，很多人把它当成了 AI 编程的全部。
连 Karpathy 自己在更正式的场合都换了说法，改用了「Agentic Engineering」。创造者都在修正这个概念的边界，说明 Vibe Coding 确实不该是终点。
真正决定效果的，不是模型
Claude 官方在那篇文章里有一句话我印象很深：
围绕模型构建的生态系统及框架，比模型本身更能够决定 Claude Code 的性能。
这句话让我想到了前段时间特别火的一个概念，叫 Harness。
LangChain 的 Vivek Trivedy 说过一句被广泛引用的话：
在不同的地方都能看到类似的观点，说明这可能就是当下的共识。
Harness 这个英文单词，原义是马具。缰绳、马鞍、马镫这套装备。马是力气，马具是让你能驾驭这股力气的东西。
放到 AI 编程上，一个完整的 AI Agent 可以拆成一个简单的等式：
Agent = 模型 + Harness
模型决定 AI 怎么想，这部分我们改不了。
Harness 决定 AI 能看到什么、能用什么工具、失败了怎么办、结果怎么验证。这部分才是我们能搭、该搭的。
一个好的 Harness 长什么样
Claude 官方在文章里给出了一个清晰的框架：五个扩展点，加上两个补充能力。
我觉得这个框架的价值不只是 Claude Code 的功能介绍。它背后的思路，对所有 AI 编程工具都适用。
1. CLAUDE.md：给 AI 的入职手册
这类文件会在每次会话开始时自动加载，告诉 AI 这个项目的基本规矩：技术栈是什么、代码风格怎么定、哪些文件不能动、测试怎么跑。
你可以理解成给新同事的入职文档。能力再强的人，第一天上班也得先知道公司的规则。
AI 也一样。
2. Hooks（钩子）：自动执行的规则
与其靠 AI 记住「每次提交前跑一下格式化」，不如直接写一个钩子脚本自动执行。
靠提示词是「请你记得做」，靠钩子是「不管你记没记得，系统替你做」。程序的约束比语言的提示靠谱得多。
3. Skills（技能）：按需加载的专业知识
一个大项目里有几十种不同类型的任务。如果把所有知识都塞进每次会话，上下文很快就爆掉了。
Skills 的做法是按需加载：做安全审查时加载安全规则，写文档时加载文档规范，需要什么就加载什么，平时不占空间。
4. Plugins（插件）：好配置的打包分发
团队里总有人把 AI 环境调教得特别好。但如果这些经验只留在个人配置里，其他人用不上，好做法就变成了部落知识。
Plugin 把一整套配置打成一个包，新人装上就拥有同样的 AI 环境。
5. MCP Server：连接外部世界的桥
AI 默认只能看到你本地的文件。
但实际开发中，你可能需要它去读需求管理工具上的 ticket、查内部文档、调内部 API。MCP Server 就是让 AI 够得着这些外部资源的通道。
补充能力：子代理（Subagent）
这个在大项目中格外有用。你可以把一个大任务拆给多个独立的 AI 实例并行处理，每个实例有独立的上下文，互不干扰，做完后汇总结果。
这五个扩展点的思路是通用的。
不管你用的是 Claude Code、Cursor、Copilot 还是别的工具，你都需要想清楚这几件事：AI 进入项目时能看到什么上下文？重复性的规则有没有自动化？不同任务的知识怎么管理？好的配置能不能复用？
我的实践：一套让 AI 不跑偏的 SOP
说回我自己。
坦白说，做这个项目之前，我对 AI 编程的理解挺朴素的。给需求、看代码、改 bug、继续。没什么体系。
但这次项目的复杂度不允许我这么随意。十几个模块、三个平台、还是自己不擅长的前端。如果还是「说一句看一步」，大概率翻车。
最终我是配合 superpower 这个 Skills 跑通的是一套固定的作业流程，每个模块走一遍：
吃透上下文 → 交互式对齐 → 写精确计划 → 拍板确认 → 子 Agent 执行 → 端到端验证 → 合并
gather context（吃透上下文）
→ brainstorming（交互式对齐：一次一个问题，把意图/边界/成功标准问清，产出 spec）
→ writing-plans（写实现计划：精确到文件路径 + 完整代码 + 测试命令，no placeholder）
→ 用户 greenlight（拍板）
→ subagent-driven-development（逐任务派子 Agent 实现 + 复核 diff/tsc）
→ 端到端验证（browser-harness/ playwright Test ）
→ finishing-a-development-branch（合并回 main，本地 ff-merge）这里面有几个环节，我觉得很有用。
对齐前置。
在写任何代码之前，先用交互式的问答，把 AI 的理解和自己的意图对齐。
通过一轮轮对话，最终产出一份双方都认可的设计规格。
为什么要这么麻烦？因为错误越早发现越便宜。AI 理解的方向跟你想的不一样，写了几百行代码才发现要推倒重来，那就是纯浪费。
十分钟的对齐，能省两小时的返工。这是我反复验证过的。
计划即代码。
这里说的「计划」不是粗略的待办清单，是精确到文件路径、没有模糊占位符的具体实施方案。
计划写完的那一刻，执行阶段就变成了机械性的工作。所有需要人做判断的事情，在写计划时已经全部做完了。AI 照着执行就行。
这一步的好处在后面才真正显现出来。
验证体系。
类型检查全部通过、单元测试全绿、多语言文本对齐、自动浏览器里实际跑一遍看效果。这套检查清单，每次合并前必须全过。
有了这套体系，每次新增完功能，修复完 Bug，我都可以放心合并，能极大提升自己的生产效率。
AI 编程的三个阶段
聊到这里，我想把前面的内容串一下。
如果把 AI 编程的方式排一条路径，大致可以分三个阶段：
阶段一：Vibe Coding（氛围编程）
说几句话让 AI 生成代码，不看细节，只看效果。适合原型验证、个人小工具、一次性脚本。
快，但不可持续。
阶段二：Spec-driven Coding（规范驱动开发）
在让 AI 动手之前，先用规范文档把产品的各个维度定义清楚：产品是什么、这次要做什么、视觉长什么样、技术架构怎么定。
简单说就是：先想清楚，再让 AI 写代码。
用规范文档约束 AI 的每一次决策，保证了一致性和可维护性。
Spec-driven 比 Vibe Coding 前进了一大步。但它主要解决的是「想清楚再做」的问题。当项目进一步复杂，你还需要解决另一个问题：怎么让 AI 在执行过程中不出错、不跑偏？
阶段三：Harness Engineering（驾驭工程）
不只是写规范，而是搭建一整套环境：上下文管理、自动化约束、反馈回路、验证体系、子代理编排。让 AI 在一个好的工作环境里干活。
这三个阶段不是非此即彼。Vibe Coding 有它的位置，Spec-driven 解决了一大类问题，Harness Engineering 处理复杂项目效果最好。
写在最后
简单总结一下今天聊的。
如果只是想要用 AI 快速验证某个项目，做个个人小工具，跑个一次性脚本，那只需「just vibe with it」。
但如果需要用 AI 参与需要长期维护的项目，不只是靠跟 AI 对话，还需要先想清楚、搭建对应的 Harness 环境。
目前我自己也还在摸索，这次积累的经验，下次未必全部适用。工具在变，模型在变，最佳实践也在变。
但如果只能留一条建议，大概就是：别急着让 AI 写代码，先把需求讨论清楚。
以上，就是本文全部内容，如果觉得这篇文章对你有启发，点赞、比心、分享三连就是对我最大的支持，谢谢～
• 用 Gemini 解锁 YouTube 新用法，信息获取效率提升 10 倍
• 有了 NotebookLM 后，还需要 Obsidian 吗？
• 我试了 NotebookLM 学习法后，彻底抛弃传统学习方式
• 我用 NotebookLM 解锁 PPT 的 5 种玩法，实现了 PPT 自由
• 全网都在抄 Karpathy 的知识库，但大多数人只学到了皮毛
没有评论:
发表评论