有两个 Vibe Coding 项目让我印象很深。
一个是 Simon Willison（Django 框架的联合创始人），他一边陪家人装饰圣诞树、看电影，一边用 Codex CLI + GPT-5.2，把 Emil Stenström 的 JustHTML（一个纯 Python 的 HTML 解析库）迁移成了纯 JS、零依赖的版本，跑过了 9200 多个 html5lib-tests 用例，产出大约 9000 行代码、43 次提交。整个过程他自己只发了 8 条左右的提示词。
《I ported JustHTML from Python to JavaScript with Codex CLI and GPT-5.2 in 4.5 hours》https://simonwillison.net/2025/Dec/15/porting-justhtml/
另一个是 Cloudflare，一个工程经理带着 AI，用不到一周时间，在 Vite 上重新实现了 Next.js 的 API，做出了 vinext 这个项目。1700 多个单元测试、380 个端到端测试、覆盖 Next.js 94% 的 API，已经有客户跑在生产环境了。总花费大约 1100 美元的 Token。
《How we rebuilt Next.js with AI in one week》https://blog.cloudflare.com/vinext/
这两个项目的规模和复杂度都不低，但 Coding Agent 的完成质量出奇地好。为什么？
因为它们都精准命中了 Coding Agent 的舒适区——或者说甜蜜点。
有明确的参照物：让 Agent“翻译”而不是“创造”
大语言模型最擅长的事情之一是“翻译”，无论是自然语言还是编程语言。给它一个明确的参照物，它能做到又快又好。
Simon 的项目就是典型的翻译型任务。已经有一个写好的 Python 版 HTML 解析库，API 设计是现成的，代码逻辑是现成的，Agent 要做的就是把这些“翻译”成 JavaScript。不需要凭空设计架构，不需要做产品决策，照着画就行。
Cloudflare 的 vinext 项目看起来更复杂，但底层逻辑一样。Next.js 的 API 是公开的、文档极其完善，Stack Overflow 上积累了海量问答，这些内容早就进了大模型的训练数据。Cloudflare 团队不是让 AI 发明一个新框架，而是让它照着 Next.js 的规格说明书，在 Vite 上重新实现一遍。
第一个条件：给 Agent 一个明确的参照物。 不管是一个已有的开源项目、一份 API 文档、还是你之前写过的旧版本代码，都可以当参照物。让 Agent 做翻译而不是创造，成功率会高很多。
在你自己的工作中，动手之前先问一句：有没有现成的东西可以参考？一个开源实现、一段竞品代码、甚至一份伪代码，都能让 Agent 的表现跨一个台阶。
XIMGPH_2
有自动化验证：让 Agent 能自己验证对不
Coding Agent 和人类程序员一样，写完代码需要验证。区别在于：如果验证必须靠人工，效率就会断崖式下降；但如果 Agent 能自己跑测试、自己看结果、自己修 bug，它就能进入一个高速循环，不知疲倦地迭代下去。
Simon 的项目能成功，很大程度上因为 HTML5 标准有一套叫 html5lib-tests 的测试集，9200 多个用例，输入是 HTML，输出是正确的解析结构。Agent 不需要你告诉它哪里写错了，它跑一遍测试就知道。Simon 把 GitHub Actions 配好之后，Agent 就进入了这个循环，用了 140 多万个 Token，提交了 43 次，直到所有测试亮绿灯。
Simon 把这个过程叫做 “设计智能体闭环”（Designing the Agentic Loop），他认为这是释放 AI 编程潜力的关键技能。
Cloudflare 那边也一样。Next.js 仓库里有几千个端到端测试，团队直接把这些测试搬过来当验收标准。工作流程就是：定义任务，让 AI 写代码和测试，跑测试，过了就合并，没过就把报错扔回给 AI 让它改。几乎全自动的反馈闭环。
你可能会说：我的项目哪有这么完美的测试套件。确实，大多数项目没有。但你可以往这个方向靠：
先写测试再让 Agent 写实现（测试驱动开发和 Agent 是天然搭配）
配好 Lint 和类型检查
给它接上浏览器开发工具让它能看到运行结果
哪怕只是让 Agent 能自动跑一个 npm test，都比你自己肉眼审代码强得多
给 Agent 的自动验证工具越多，它能自我修复的能力就越强。
XIMGPH_3
有架构蓝图：让 Agent”填空”而不是”作文”
Agent 受上下文窗口的限制，一次任务能处理的信息量是有上限的。你把一个复杂项目的整个代码库扔给它，它消化不了。你让它从头到尾一口气做完一个大功能，它做到后面就忘了前面。
所以架构设计特别重要。把大任务按架构拆成小任务，每个任务刚好在 Agent 的上下文窗口内能完成，这是高手和新手使用 Agent 最大的区别之一。
Simon 的做法很聪明。他的第一条提示词不是让 AI 写代码，而是让它读完 Python 项目后写一份 JavaScript 版本的设计文档（spec.md）。这份文档包含了 API 设计、实现步骤和验收标准。然后他让 Agent 从最简单的冒烟测试开始，一步步按计划推进。架构是现成的（参照 Python 版），路线图也规划好了，Agent 只需要按部就班地“填空”。
Cloudflare 团队的做法更系统。工程经理先花了几个小时和 Claude 反复讨论架构方案，定好整体蓝图，然后按模块拆任务。每个任务的边界清晰，AI 写完一个模块就能独立测试，不用等整个项目做完才能验证。
你不需要是架构大师才能做这件事。哪怕是花 10 到 30 分钟和 AI 聊一下你打算怎么做，让它帮你列个实现计划，再按计划分步执行，效果都会好很多。先设计再实现，这个道理对人类程序员适用，对 Agent 同样适用，甚至更适用。
有人把控方向：Agent 执行，人来决策
Cloudflare 的博客里有一句话：
给 AI 好的方向、好的上下文、好的护栏，它就能高产；但方向盘必须在人手里。
AI 有一个让人头疼的特点：它经常写出看起来完全正确、但实际行为不对的代码。语法没问题，逻辑看着也通顺，跑起来就是不对。识别这种“高置信度的错误”，目前还是需要人来做。
Simon 让 Agent“commit and push often”（频繁提交代码），这样他在手机上刷 GitHub 提交记录就能追踪进度。Cloudflare 团队把代码审查也交给了 AI Agent，但架构决策、优先级判断、识别 AI 走偏了，这些仍然由人来把控。
这两个项目的操作者都不是新手。Simon 是 Django 的联合创始人，Cloudflare 那位是工程经理。他们知道怎么把一个大问题拆成 AI 能消化的小问题，知道什么时候该介入，什么时候该放手。
你不需要是他们那样的高手，不需要盯着 Agent 写的每一行代码，但也需要在关键节点检查方向对不对。给 Agent 一个太大的任务然后自己走开，通常不会有好结果。小步快跑、阶段性验收，是目前最靠谱的协作方式。
XIMGPH_5
这四个条件不是什么高深的理论，回头看都是常识：有参考、能自测、有规划、有人管。但正是因为它们太像常识，很多人在使用 Agent 时直接跳过了。
Cloudflare 团队自己说，几个月前这事还做不了，不完全是因为模型变强了多少，而是他们找到了正确的方法。
既然知道了 Coding Agent 的舒适区在哪，就可以有意识地把自己的项目往这个方向靠：
先看看有没有参考项目/代码再动手。 别急着让 Agent 从零开始写。看看有没有类似的开源实现、有没有现成的 API 规范、有没有可以参考的代码库。给 Agent 一个参照物，比给它一段需求描述有效得多。
给 Agent 配上自动验证的能力。 手动测试是 Agent 效率的最大瓶颈。尽量把验证环节自动化：单元测试、集成测试、Lint、类型检查，甚至浏览器自动化测试。让 Agent 能自己跑、自己看结果、自己改。Cloudflare 用了 agent-browser 来验证浏览器端的渲染和交互，这种思路很值得借鉴。
先设计后实现。 在让 Agent 动手之前，先把架构想清楚、任务拆好。每个任务的范围要小到 Agent 的上下文窗口能装下，大到足够产出一个有意义的模块。这个拆分能力本身就是高手和新手的分水岭。
建立反馈闭环。 Simon 的做法很典型：配好 CI，每次提交自动跑测试。Agent 写代码、提交、CI 报错、Agent 读日志、修复、再提交。人只需要在关键节点介入。这个闭环跑起来之后，Agent 的产出效率会远超你坐在那里一行行审代码。
知道什么时候 Agent 不行。 不是所有项目都在舒适区里。没有明确规范的探索性项目、需要大量领域知识的业务逻辑、涉及复杂人际沟通的需求梳理，这些 Agent 做不好。识别边界和利用优势同样重要。
