在进行 5 万行代码的 Vibe Coding 实践中，我收获颇丰。首先，深刻体会到了代码量庞大带来的挑战与机遇，每一行代码都像是构建大厦的一块砖，需要严谨对待。我学会了如何高效地组织和管理代码，以确保其可读性和可维护性。通过不断调试和优化，提升了对代码逻辑的把控能力，能更敏锐地发现潜在问题。同时，也明白了团队协作在大型项目中的重要性，相互交流和学习让我们能够更好地应对复杂情况，提升整体开发效率。这一实践过程，让我的编程技能得到了极大的锻炼和提升。

本文来自一位大厂工程师的投稿，作为一位22年经验的资深工程师，他在最近几个月他深度体验了Cline AI，Cursor，GitHub Copilot等产品，投入3个月的假期和周末时间，完全依赖AI编写了约5万行代码、成功完成了3个不同功能的产品。

这篇文章不只是关于Coding Agent的使用体验，也包括对相关关键技术，例如语言搜索、MCP的探索和理解。Coding Agent结合MCP是一种值得探索的新的自动化方式。

除了这3个月的Vibe Coding体验，从2023年起，作者和团队就开始尝试开发一款代码测试Agent，并且在这个过程中探索人类经验和AI自由度之间的平衡，最终的结果很有趣：人类植入了过多的经验，反而限制了AI的发挥，锁死了产品上限。对于Agent开发者来说，The Bitter Lesson中的经验同样重要。

一、我的Vibe Coding之旅

2025年，Vibe Coding开始大火，Vibe Coding是指用户使用Coding Agent来编程，几乎100%代码都是AI生成。通常用户会使用Windsurf，Cursor，Cline，Devin等产品。

实践

为了验证“Vibe Coding”的真假，尤其是深入了解coding agent的真实效能，我投入了3个月的假期和周末时间，期间完全依赖AI编写了约5万行代码，成功完成了3个不同功能的产品。

我个人的技术背景主要集中在C/C++/汇编领域，对于前端开发常用的JavaScript（JS）和TypeScript（TS）没有经验。这种背景看似不利，但在AI编程时却恰好变成了优势：由于我缺乏相关经验，我不得不完全依赖AI进行开发。这段经历让我不仅理解了如何（how）有效利用Coding Agent，也初步领悟了其背后的原理（why）

有一个memory.txt贯穿全局，是一个sop内的task共享的全局memory。理论上每一个task的输出都要在memory中有记录。

最顶层是domain sop的抽象：domain sop（后续简称SOP）是针对一类型任务的最佳实践的抽象，sop数据结构中主要包含了tasks的集合。具体：crawler爬虫任务使用的是一种crawler sop，里面预定义了几个task：analyze html dom，coding，test。

中间是task的抽象：task是最核心的类，主要包含：tools（描述了做一个task需要的工具组合），prompt（描述了当前task的独特的system prompt，每个任务的prompt不同，并且与system.ts文件内容可以完全不一样），input（描述当前任务的输入），output（当前任务的输出）

最底层是tools的抽象：请你把system.ts中的所有tool抽象成数据结构，可以动态插拔，任意组合。每一个task动态选择tools，这样会极大减少ai处理多任务时候的token消耗。

user story:

以下是关于crawler sop的用户使用场景，请你仔细体会：

Cline启动后，user（我）输入任务：请你写一个爬虫程序，把musk的推文爬下来，做成日报，每天早上9点发给我邮箱xyz。

Cline调用crawler sop，从中读取tasks，针对每一个task组装tools，准备好prompt，类似如下：

task1:analyze html dom

tools:write_to_file，browser_action，domAnalyzer

input:url，memory.txt

output:把html dom写入memory.txt

prompt：你是一个分析网页dom的ai，你将为一个爬虫工程师提供写爬虫必须的信息，比如网页可视化内容，关键词信息，html dom的详细信息，你拥有以下工具。你的输出要写入memory.txt文件。

task2:coding

tools:write_to_file，replace，read_file，execute_command

input:user task，memory.txt

output:代码，状态写入memory.txt

prompt：你是一个ai coding助手，你将根据用户任务编写爬虫程序，你的重要信息来自于memory.txt中的html dom信息，请你必须遵守dom信息来写爬虫。

Cline开始一次执行每一个domain sop中的task。这里的task其实对应的是Cline现有架构中的user task。新架构相当于在更高维度抽象出来了task结构。在现有架构下，Cline ai处理一个用户的端到端任务，而在新架构下，每一个ai只处理属于它的那部分task，多个ai组合起来完成用户任务，这就是multi agent架构！

Cline执行完成task1之后，让ai执行task_completion工具，然后新架构自动选中下一个task2开始执行，直到最后一个task执行完成为止。

请你在实现新架构的时候：

不要修改Cline.ts，这个文件太大了，你改不动。如果要修改，请你给我建议，我来手动修改。

新增一个domainsop文件夹，把新架构文件放到里面去。不要修改任何现有的文件！尽可能通过新增文件实现新功能。

注意模块化，每一个文件尽可能小，单一原则。

尽可能向后兼容，新架构与旧架构用一个开关可以自由切换

利用好Cline现有的处理user task的大逻辑，不要绕开它去与ai交互。Cline旧架构的user task逻辑，要映射成为新架构中domain sop下的一个task。

请你一步一步来，不要尝试一次性输出所有代码。

第一步任务：先把现有的Cline的tools抽象出来，变成可以动态插拔注册。等你完成tools抽象，再实现sop和task的抽象。

AI Coding最佳实践

要充分发挥coding agent的潜力，并使其真正成为提升工作效率的得力伙伴，掌握正确的使用方法和培养积极的心态至关重要。

• 实践出真知：这是学习和掌握任何新工具不变的真理。只有亲身实践，才能深刻理解coding agent的特性、优点和局限性。建议从实际工作中的小任务开始尝试，逐步挑战更复杂的场景。

• 理论联系实践：读一读Cline的源代码，单步调试一下核心的流程，打印一次api调用中AI的input和output message分别是什么，会非常有助于你理解coding agent的原理，从而更好地指导你的实践。其中，system.ts和src/core/task/index.ts2个文件是必读的

• 选用最强模型：在条件允许的情况下，尽量选择当前能力最强的AI模型。例如，在Cursor中，优先使用Claude 3.7 Max或Gemini 2.5 Pro Max等顶级模型，它们通常能提供更准确、更智能的辅助；

• 提供充分的上下文：与coding agent交流，本质上与人沟通类似。当遇到AI执行任务失败或结果不理想时，首先应反思是否提供给AI的上下文信息不够充分或存在歧义。清晰、完整、准确的上下文是获得高质量输出的关键；

• 拥抱“Agent模式”：如下文所述，务必开启并坚持使用Agent Mode。这能让你体验到coding agent工具的核心功能，并在实践中积累宝贵的经验。

• 培养积极的协作心态：关键在于思考“如何才能让AI更好地为我所用？”，而不是试图证明“AI在某些方面不行”。要找出AI的不足之处很容易，每个人都能举出很多例子，但这种做法对于提升认知和解决问题并无益处。更有效的方法是分析AI失败的原因，并尝试配合AI一起解决问题。

二、Coding Agent的关键技术

Coding Agent的代表有Cursor，Cline，GitHub Copilot，Windsurf（刚被OpenAI收购）等。注意：有些coding agent产品默认并没有开启Agent模式，请根据使用方式来区分你是否真的在使用这些产品的agent能力。

强烈建议大家在实践中开启并坚持使用Agent模式。虽然初期可能需要一定的适应和学习，但这种投入对于掌握未来编程范式而言是值得的。其中，Cline本身就是Agent模式，不用选择模式，直接用就可以，GitHub Copilot和Cursor则需要专门设置。

GitHub Copilot打开Agent模式：vscode-settings，在搜索栏里输入agent，在出现的选项中，把Agent:Enabled打勾

Cursor打开Agent模式：很简单，在输入窗口下拉中直接选择模式

我个人判断：Coding Agnet关键技术是：Model，Context和Tools。

为什么我认为这三点最重要？可以将Coding Agent类比为一个公司，而其背后的AI模型则是一位员工。

一个公司要让员工发挥最大价值，通常需要：招聘最强的员工，在布置任务时提供“充分且必要，外加反馈闭环”的上下文信息，并为其配备一套强大的工具链。

以上是“公司如何发挥人类员工最大价值”的答案，Coding Agent的关键技术也遵循同样的逻辑：

• AI的“大脑”：模型（Model）

越聪明越好，目前最强的编程模型是Cursor官方调教的模型：Claude 3.7 Max（作者注：本篇文章写于2025年5月初），以及Gemini 2.5 Pro Max，两者都在Cursor收费版中可以使用。

• AI的“工作记忆”：上下文（Context）

对于AI来说，Context相当于是AI看到的信息全集，context由很多部分组成：

1.System prompt：告诉AI，你是什么角色，你有什么工具（write to file，read file，shell，browser use）可以使用，Cline的system prompt有1000多行，节选如下：

2.User prompt：用户输入的任务，用户临时给的反馈，等。

3.Feedback loop：每一次tool使用的result，用户的反馈等，Cline的user prompt节选如下，assistant代表AI说的话和做的事情，user代表用户给AI的反馈：

• AI的“工具链”：工具（Tools）

常规的tool比如write to file，read file，execute shell等，是各大产品的标配。但有一些tool是各自的特色，也是各种Coding Agent之间能力的本质区别，比如：

1.Cursor自带了互联网搜索工具：web_search，当你想要Coding Agent处理一个非常新的技术（比如MCP），AI模型有可能没有pre-train这个知识，于是他会胡乱回答。这时候你可以让他搜索互联网确认最新的技术文档和最新的开源代码，他会迅速掌握这个新知识，接下来就可以写出正确的代码了。

2.Cursor拥有语义搜索工具：codebase_search，这是Cursor能够驾驭10w行代码以上大型工程的核心能力之一。

3.MCP：各家都支持，但是有优劣，Cline支持最好，Cursor其次，GitHub Copilot有待优化。

4.Cline自带browser use工具：browser action工具让Cline可以访问互联网，基于浏览器进行工作，底层基于puppeteer。

理解这三个核心组成部分（强大的模型、充分的上下文以及高效的工具）是掌握和有效利用coding agent的关键。

接下来我会展开讲一下Coding Agent的几个关键的tool：语义搜索和MCP

语义搜索工具：codebase_search

AI要掌握一份中大型代码，搜索是一个很重要的能力。在编程领域，代码搜索大致分两种技术：关键词搜索和语义搜索。

关键词搜索就是大家今天每天都在用的搜索方式，我们可以在Vscode或者Cursor，点击搜索按钮，输入关键字进行搜索。但假设我们要在上万行的Cline代码中查找“Cline的浏览器配置是什么？”，如果直接输入这个查询语句，vscode无法返回任何结果：

与关键词搜索不同，语义搜索侧重于理解用户查询背后的上下文含义和意图，而不仅仅是匹配关键词。

它力求像人一样理解查询的深层含义，从而提供更相关的结果。例如，当用户搜索“什么AI可以做视频通话？”，搜索引擎返回的结果并非基于“视频通话”的字面完全匹配，而是理解了用户的真实需求。

搜索引擎用的就是语义搜索技术，如果我们用Google搜索：“什么AI可以做视频通话？”，结果如下：

Cursor的语义搜索工具

Cursor总共给AI配置了5个search工具：

其中本地文件搜索的主要是2个：

• 语义搜索工具codebase_search（Cline没有这个工具）

• 传统的文本搜索工具grep_search（Cline拥有类似的工具）

Cursor的语义搜索有什么用？

做一个简单的测试，用Cursor打开Cline的源代码，index完毕后，提出一个纯语义的模糊指令“我想请你搜索一下：Cline的浏览器参数是如何指定的？”

Cursor直接调用了codebase_search工具，输入的参数是纯语义级别的模糊自然语言“How are Cline browser parameters specified or configured？”，Cursor返回了相关的语义级别的代码片段给AI看，然后AI总结出了答案，如下：

Cursor的AI往往会结合list+codebase_search+grep_search多种工具查找他需要的代码片段，这种能力使得AI能够更高效地理解复杂的代码结构。

Cursor的index设置

Cursor的索引功能默认是开启的。对于特别庞大的工程，例如超过10万行级别的代码库，可以尝试按子模块进行索引，这可能会获得更好的效果。

Cursor语义搜索的实现原理

所谓的语义搜索，本质类似于百度的搜索，或者说是一种RAG技术，我们可以把Cursor的codebase_search能力类比成：Cursor在云端为每一个人的每一个工程建立了一个专属的百度搜索，语义搜索背后的技术，在行业中一般称为：index，index一旦完成之后，Cursor背后的那个AI就可以使用语义来搜索你的工程中所有源代码，类似于你可以用语义搜索百度信息。

语义搜索的核心技术

1.ast语义切分：把整个工程按照代码结构进行分块

2.向量嵌入：对代码块进行压缩后存入向量数据库

3.向量搜索：AI输入语义，得到语义最接近的几个代码片段

codebase_search工具描述，也就是AI视角看到的语义搜索工具长什么样

Cline的缺陷：缺少语义搜索

个人体验：Cline处理的代码量超过1w行通常会有点吃力，超过5万行之后就更困难了。

其中一个原因是：缺失了关键的codebase_search工具，无法进行语义级别的搜索。但好消息是：Cline是开源的，我们可以做一个语义搜索给它用。

如何在Cline上复现Cursor的语义搜索？

为Cline做一个demo级别的本地index系统，代码量在2000行以上，我用Cursor 3.7 max来编程实现100%代码，大概用了30个来回搞定。其中的关键技术如下：

1.用OpenAI的text-embedding-ada-002模型生成文本嵌入

2.使用ChromaDB做本地embedding数据库

3.搜索的时候，用余弦距离计算相似度

要在公司级别做成一个稳定的线上index系统，需要投入更大人力和时间，实现的功能包括但不限于：

1.基于ast的代码分块

2.云端embedding

3.云端cache，共享

4.基于哈希树的diff查询

5.各种工程优化

MCP工具

为什么需要MCP？

MCP是现在非常火的技术，Cursor，Cline以及GitHub Copilot都已经支持MCP。

但因为这个协议很新，大部分AI对这个技术的理解非常浅，因此让Coding Agent写出高质量的MCP需要一定的技巧。

思考这样一个问题：如何让Cline这个Coding Agent可以使用你们公司的某一个现成的工具链？

如果没有MCP，Cline的开发是这样的：

1.针对AI的使用习惯封装工具链的api

2.在system.ts里面加一段关于工具链接口的描述

3.在Cline.ts（3.5版本，最新版本改到index.ts里面了）里面增加工具链api的handler

4.在3-5个前后端文件中添加：参数描述，ui展示信息，工具描述，等

这种开发模式存在2个问题：

1.效率问题：整个流程有些琐碎，需要改动3-5个Cline的源代码文件

2.通用性问题：这个工具链的MCP工具只能给Cline用，Cursor不能用，GitHub Copilot也不能用

如果有MCP，开发就变得非常简单：

1.封装工具的api，成为一个MCP工具；

2.编辑Cline_MCP_settings.json，添加一段工具链MCP的描述；

有了MCP后，对应的优点是：

1.整个流程很简洁，除了封装api之外，只需要改动一个json

2.这个工具链MCP工具能同时在Cursor，Cline，GitHub Copilot上使用，就像usb设备一样通用

如果你想让Coding Agent使用公司已有的工具链，那么MCP提供了一种高效且标准化的途径。

Coding Agent结合MCP是一种值得探索的新的自动化方式。

MCP的原理

大家有兴趣可以看一下Cline源代码，有助于理解MCP的host，client，server的概念，代码位置在：src/services/mcp/mcphub.ts，在Cline的AI的视角，MCP本质上也是一种tool，在Cline中，MCP具体的名称叫：use_mcp_tool。

use_MCP_tool与read_file这个tool没有本质区别，AI从system prompt中得到tool的描述，AI输出针对这个tool的调用，如下：

用Coding Agent开发MCP的要点

理论上，你可以用coding agent来开发任意的MCP工具，但MCP是一个非常新的生态，各大coding agent对于MCP的支持能力参差不齐，截止到25/05/03，我感觉Cline对于MCP的支持是最佳的，Cursor其次，而GitHub Copilot处于苦苦追赶的阶段。

大致对比如下，但也许这些结论在1个月后就会过时（作者注：Cursor截止到25年3月还不支持AI看到MCP返回图片，但是25年4月迅速支持了claude 3.7看到MCP返回的图片）

如何增强Cursor开发MCP的能力？

虽然Cursor对于MCP的支持不如Cline，但是由于Cursor拥有更强大的模型claude 3.7 max，以及强大的互联网搜索能力，因此我尝试让Cursor提升开发MCP的能力，最终让Cursor与Cline一样优秀，方法如下：

1.把Cline的system prompt中MCP相关的内容给Cursor的3.7 max参考一下。

2.让Cursor的AI先做这个任务：“请你搜索互联网，了解Anthropic MCP（model context protocol）的实现原理，查找Cursor MCP的源代码，总结到。cursor/MCP.md文档里面，要求：1。描述MCP是什么？2.描述MCP的协议是什么？3.描述anthropic官方的MCP参考代码是什么？4.描述在Cursor这个ide中实现MCP的官方参考代码是什么？”

3.然后重新启动一个新任务（刷新context windows，防止爆炸）：“请你参考。cursor/MCP.md文档，进行新MCP tool的开发，目标：……要求：……”

MCP与传统的工具链开发对比

• 传统模式：工具链团队要负责工具开发，同时也要为用户开发使用工具的业务逻辑，比如让编译系统与仿真系统打通，等。缺点是当用户需求众多的时候要排队开发，无法做到随时响应需求

• MCP模式下：工具链团队把现有工具封装成MCP，用户用自然语言描述任务SOP，由coding agent背后的AI来自动串联各种MCP，比如：“帮我解决这个bug，然后编译，然后做一个仿真测试”这样的需求可以让AI用1个或者多个MCP来完成。优点是：在端到端SOP并不是特别确定的时候，用户自己就能完成全流程任务，没必要排队等工具链团队开发代码

MCP工具开发实战

Manus背后有技术是：browser use，也就是让AI操作浏览器完成任务。但当我下载browser use开源代码实验的时候，发现它很难攻破Cloudflare的人机验证，也无法在公司内网下使用，我换成playwright MCP工具，发现这些问题仍然没有解决。

受到智谱轻言的AutoGLM产品的启发，我发现可以做一个增强版本的browser use MCP，完全绕过人机验证和内网检查。原理是：直接使用

用户的浏览器来完成任务，ai发出的浏览器指令通过chrome插件来执行，这种方式很难被反爬虫发现。

它的效果如下：左边是playwright MCP，右边是我开发的codingbaby browser MCP，playwright在访问一个需要权限的网页的时候被人机验证拦截了，而codingbaby这个MCP完全复用用户的浏览器，没有触发人机验证，于是就可以全自动完成浏览器任务：

如果有兴趣的话可以体验一下browser use MCP，也可以看一下AI写的MCP代码长啥样：https://github.com/buyitsydney/CodingBaby-Browser-MCP

三、Coding Agent对比

我从个人的体验（与网上的任何评测无关），对三个产品进行了综合对比：

详细解读：

• Cursor-“现阶段的王者”

当使用Cursor并选择Claude 3.7 Max模型时，用户可以体验到当前最顶尖的coding agent能力。对于10万行代码级别的项目，完全从零开始，100%由Cursor生成代码是可行的。

用好Cursor的关键在于：多实践、选用最强模型、以及在提问时提供充分的上下文信息。与AI交流的本质和与人沟通类似，当AI执行任务失败时，应该反思是否是提供给AI的上下文不够充分。

在充分的上下文支持下，Cursor和Claude 3.7 Max往往能在10-30轮以内对话正确完成一个相当复杂的任务。

• Cline-“潜力巨大，公司应考虑深度定制”

Cline的最大优势在于其开源特性，允许进行深度定制和二次开发。此外，它对MCP的支持是三者中最佳的，是第一个支持MCP的产品，并且截至目前（2025/05/08）是唯一能让Gemini 2.5模型看到MCP返回截图的工具。然而，Cline存在明显的优化方向：

1.缺乏语义搜索：如前所述，这使其难以驾驭中大型工程。

2.上下文管理：Cline的对话历史会无限累积，达到阈值后采取简单的“砍半”策略，极易导致AI“失忆”，这也是Cline运行成本较高的主要原因之一。针对上下文管理问题，大致的解决思路包括：实现一个历史摘要（historySummarizer）功能，当历史记录超过一定阈值后，用AI进行总结，有损压缩成一段历史摘要；对于特别消耗历史记录空间的工具（如Cline调用一次curl可能返回大量文本），要及时精简工具结果。

以上两大问题（增加语义搜索、优化上下文管理）不难解决，理论上Cline完全有能力处理10万行甚至更大规模的代码工程，潜力巨大。

• GitHub Copilot

在对Cline进行二次开发的体验中，GitHub Copilot的表现相较于Cursor+Claude 3.7 Max稍逊一筹。其上下文管理能力较差，MCP支持也有待优化。

尽管目前在某些方面暂时落后，但coding agent领域是微软的必争之地，凭借其强大的研发实力和生态整合能力，未来完全有可能实现反超。

总体看，Coding Agent就像程序员的十八般兵器，有人喜欢短剑，有人喜欢长枪，没有绝对的“最佳”兵器，只有最适合自己的兵器。但在这个pre-AGI时代，赤手空拳一定是不行的。

四、Agent开发中的The Bitter Lesson

强化学习之父Sutton在2019年写的一篇短文The Bitter Lesson来概括，被称为是“AI领域的圣经”，从2023年2月份接触ChatGPT，到2025年5月，这2年来我使用AI的最深刻的感受也可以被The Bitter Lesson总结。

2023年，我和团队尝试在一款quality agent产品的早期版本中更多利用好AI的能力来写单元测试、发现bug，但是由于GPT-4能力较弱，AI还搞不定这些需求。

2024年，我们开始更多植入人类经验，让AI（GPT-4o）只做简单的事情，产品效果不错，单元测试覆盖率能够做到70%左右，一度觉得找到了AI时代做Agent的正确方法。

但这样的架构设计带来了一个严重的问题：虽然外界AI能力不断提升，但产品的测试覆盖率却无法同步提升，用Claude 3.7和用GPT-4o的覆盖率数字几乎相同，显然不合常理，因为Claude 3.7的编程能力是远超GPT-4o的。

这个反常现象很直接地展示了bitter lesson：人类植入了过多的经验，反而限制了AI的发挥，锁死了产品上限。

2025年，团队开始重构这个产品，让AI能力占主导地位，尽量减少人类的经验。最新的数字证明：测试覆盖率可以做到99%以上。

因此，对于做Agent的同学来说，Sutton的这篇文章也值得经常读一读，提醒自己是不是正在犯同样的错误。

这里我把The Bitter Lesson的节选翻译如下：

这个“苦涩教训”基于以下历史观察：

1）AI研究人员经常尝试将知识直接构建到智能体中；

2）这种做法在短期内确实有所帮助，并给研究者带来个人满足感；

3）但从长远看，这种方法会遇到瓶颈，甚至阻碍进一步发展；

4）真正的突破性进展最终来自于一种对立的方法——通过搜索和学习来扩展计算能力。这种最终的成功常常伴随着一丝苦涩，且往往未被完全接受，因为它战胜的是一种备受青睐的、以人为中心的方法。

我们应该汲取的一个重要启示是通用方法的强大力量——那些能够随着计算资源增加而不断扩展的方法，即使在可用计算资源已经非常庞大的情况下仍然如此。

能够以这种方式无限扩展的两种方法是search和learning。

第二个要点是，心智的实际内容极其复杂，这种复杂性是不可避免的。我们应当停止尝试寻找简单方法来理解心智内容，比如简单地思考空间、物体、多智能体系统或对称性。

这些都只是任意复杂的外部世界的一部分。我们不应该将这些内容直接内置到系统中，因为它们的复杂性是无穷无尽的；相反，我们应该只内置那些能够发现并捕捉这种任意复杂性的元方法。这些方法的关键在于它们能够找到良好的近似解，但寻找这些近似解的过程应该由我们的方法完成，而非我们自己。我们需要的是能够像我们一样进行发现的人工智能系统，而不是简单包含我们已发现知识的系统。将我们的发现内置到系统中只会使理解发现过程本身变得更加困难。

五、结语

世界发展太快，我以上说的所有内容，仅2025年5月10日这个时间点成立，也许半年后，绝大多数的内容都将是错误的。

Reference

1. Cursor CTO的访谈：https://mp.weixin.qq.com/s/IiJ24HfKCdXQ-6rm9T4iqw

2. Cursor index官方介绍：https://www.Cursor.com/security#codebase-indexing

3. Cursor index的实现介绍：https://www.xmsumi.com/detAIl/281

4. Cline源代码：

https://github.com/Cline/Cline

5. Browser use MCP:

https://MCP.so/server/codingbaby-browser-MCP/buyitsydney

6. Browser use chrome extension:https://chromewebstore.google.com/detAIl/codingbaby-extension/pjadpjgapfnmaaabkjbeldmjdmcfgcco?hl=zh-CN&utm_source=ext_sidebar

7. The bitter lesson:https://www.cs.utexas.edu/~eunsol/courses/data/bitter_lesson.pdf