作业二：学习Skill和MCP
Codex 已经很强了，但它有一堵墙。
推荐练习
使用任何一款 CLI 工具，阅读官方说明书，尝试用它迭代你的项目。
在前面的课程里，你用 Codex 做了很多事情。
但有一件事，你可能隐约感觉到过，只是没说出口：Codex 很聪明，但它的世界有点小。
你打开浏览器，页面崩了，控制台报了一堆红色的错误。你截图给 Codex，它分析得头头是道，但给出的方案试了三个都不对。为什么？因为它看到的不是「真实的报错」，而是你截图里的报错。它没有办法直接读你浏览器的控制台。
MCP 是什么？从一个生活中的类比说起
你在用 Next.js 开发，问 Codex 某个新特性怎么写，它给了你一段代码，你一跑，直接报错：API 根本不存在。为什么？因为 Next.js 更新太快，Codex 学的那版文档早就过期了，它不知道最新的写法。
这些问题，都指向同一个根源：
Codex 的「感知边界」，只到代码文件为止。浏览器里发生了什么，数据库里存了什么，某个框架最新版本改了什么——这些它全都看不到。
这节课，我们要打破这堵墙。
MCP 的全名是 Model Context Protocol，翻译过来叫「模型上下文协议」。这个名字听起来很技术，但你完全不需要理解它的字面意思。我用一个更好懂的类比来解释它。
你想想 USB 接口出现之前的世界是什么样的。键盘有键盘的接口，鼠标有鼠标的接口，打印机有打印机的接口，U 盘那时候还不存在。每接一个新设备，你都要搞清楚它用什么接口，买对应的线，还不一定能用。整个世界一团乱。
后来有了 USB。一个标准接口，所有设备都往上靠。你不用再关心「这个设备用什么接口」，你只需要知道「它支不支持 USB」。插上就能用，不支持就换一个，就这么简单。
一句话类比
MCP 对 AI 来说，就是 USB。
在 MCP 出现之前，AI 工具想接入外部能力，每家都要自己造轮子。Codex 想支持浏览器操作，就要自己开发；想支持数据库查询，就要自己开发；想支持文档读取，还是要自己开发。而且你用的是 Codex，他用的是 Cursor，用的工具不同，配置方式完全不一样，学了 Codex 的用法，换个工具又要从头来。
MCP 里有三个角色，你需要知道
有了 MCP 之后，整个生态就不一样了。任何人都可以按照 MCP 标准，做一个「工具插件」——比如「读浏览器 DevTools 的插件」、「查 PostgreSQL 数据库的插件」、「拉最新 Next.js 文档的插件」。而所有支持 MCP 的 AI 工具，包括 Codex、Claude Code、Cursor，都可以直接用这些插件，配置方式大同小异。
这就是 MCP 的本质：一套让 AI 和外部工具「对话」的通用标准。
理解 MCP 的工作方式，你需要认识三个角色。
MCP Client（客户端）：就是你正在用的 AI 工具，比如 Codex。它的角色是「提需求的人」。它知道自己想要什么，但它不直接干活，它通过 MCP 协议去找能干活的工具。
MCP Server（服务端）：是真正干活的工具。比如「读浏览器 DevTools 的 MCP Server」、「查 PostgreSQL 的 MCP Server」。它们各自有自己的专长，按照 MCP 标准对外提供服务。
MCP Tool（具体能力）：每个 MCP Server 里，有若干个具体的工具，比如「截图」、「读控制台日志」、「执行 SQL 查询」等等。Codex 在需要的时候，会调用对应的工具来完成任务。
这三个角色的协作方式，用一个场景来理解最直观：你对 Codex 说「帮我看看浏览器控制台现在报了什么错」。Codex（客户端）就会去找 DevTools MCP Server（服务端），调用它的「读取控制台日志」工具（MCP Tool），拿到结果，再告诉你。你完全感知不到这个过程，你就只看到 Codex 给了你答案。
怎么给 Codex 装 MCP？
Codex 的用户体验非常好：自带的 MCP 市场，已经内置了市面上大部分主流 MCP。需要什么 MCP，我们先到这里搜索，搜索到的内容可以直接安装。要让codex使用浏览器，需直接点击Chrome图标进行安装。
提示
后面我们要安装的每一个 MCP，都走这个流程，不会有太大区别。学会一次，后面都一样。
作业练习
我们试试看，在 Codex 的 AI 窗口里输入一些浏览器自动化的工作。你也可以自己试试打开小红书、其他网站。
输入这样一条指令：
使用 chrome 插件，打开推特 x.com 看最新的精华帖子，总结给我
可能会弹出提示，一般来说，对于靠谱的 MCP，我选择自动运行。勾选「下次开始自动运行 MCP 工具」，然后点击「运行」。
接下来我们可以观察 MCP 工具的思考过程，发现它就和人一样在工作。此时它遇到了问题：需要登录。我选择由我人工介入，帮它登录；登录后，告诉它：我已经登录了，请你继续。它继续工作了。
浏览器 MCP 能用来做什么
- 浏览器自动化操作。比如理论上，可以用它自动发公众号、自动发小红书、自动阅读大量网页分析内容，等等。
- 用 Codex 等 AI 编程工具开发网页类产品的时候，浏览器 MCP 就是给 AI 增加眼睛，让 AI 自己测试功能、发现问题。
为什么要用Skill？
从你第一次打开 Codex开始，你就一直在做一件事：教 AI。告诉它你想要什么，告诉它你的项目是什么技术栈，告诉它你喜欢什么风格，告诉它不要这么写、要那么写，告诉它我们团队有这个规范、那个限制。你花了大量时间，一遍又一遍地跟它解释你是谁、你在做什么、你希望它怎么配合你。然后，对话一结束，它就全忘了。下次打开，你得重新说一遍。
你可能已经习惯了这件事，觉得这就是用 AI 的正常方式。你可能已经攒了一个「常用 Prompt 文档」，每次开始新任务之前，先把那段话复制进去。你可能已经把这个动作内化成了肌肉记忆，就像开工前先泡杯咖啡一样，感觉是正常流程的一部分。
但我想让你停下来想一想：这件事，真的应该这样吗？
你雇了一个助理，每天早上他来上班，你要从头给他讲一遍公司的规矩、你的工作习惯、今天项目的背景。他听完，帮你干了一天活，下班走了。第二天他来，你再从头讲一遍。第三天，再讲一遍。
这个助理，不是在帮你，是在消耗你。
AI 不应该是这样的。问题不在 AI 本身，AI 其实很聪明。问题在于你一直在用一种「临时交代」的方式跟它沟通——说一次，管一次，下次从头说。这种方式有个名字，叫 Prompt。Prompt 很好用，但它有一个天生的局限：它是一次性的。
Codex 和一年前用 ChatGPT，有什么不同？
在我们继续之前，我想先讲一件事，这件事很多人没有意识到，但它非常重要。
你现在用 Codex 的方式，跟你一年前用 ChatGPT 的方式，其实没有本质区别。你打开对话框，输入一段话，AI 回复你，你再输入，AI 再回复。整个过程是「你说一句，它做一句」。Prompt 就是你说的那句话，它决定了 AI 这一次的行为。
这种模式非常适合探索性的工作：你不确定想要什么，你在跟 AI 头脑风暴，你在试错，你在一步步把想法变清晰。这种场景下，Prompt 是完美的工具。
但开发这件事，有大量的部分不是探索性的。你已经知道你的项目用 React，不用 Vue。你已经知道你的团队用 TypeScript，不用 JavaScript。你已经知道你们的 API 要遵循 RESTful 规范。你已经知道数据库里的表结构是什么样的。你已经知道命名规范、代码风格、注释要求、测试要求……
这些东西，你每次都要重新告诉 AI 吗？
如果你每次都要说，那你就是在用「探索性工具」做「规范性工作」。这就像你每次去超市买同样的东西，都要重新查一遍哪个货架在哪里，不是因为你不记得，而是因为你没有一个固定的购物清单。
你需要的不是更好的 Prompt。你需要的是一种让 AI 记住规则、记住上岗 SOP 的机制。
这个机制，就是今天这节课的主题：Skill。
Skill 是什么？Skill 和 Prompt 的区别
在讲怎么用之前，我先用一句话告诉你 Skill 是什么，然后我会用好几个角度反复解释这句话，直到你真的理解它为止。
一句话定义
Skill 是一份写给 AI 的长期工作说明书。
注意这里有两个关键词：长期，和工作说明书。
先说「工作说明书」。你入职一家公司，HR 会给你一份文件，上面写着你的岗位职责、工作流程、行为规范、禁止事项。这份文件不是给你临时布置一个任务的，它是告诉你「以后在这家公司工作，你就按这套来」。Skill 对 AI 来说，就是这个东西。
再说「长期」。Prompt 是一次性的，说完这次就没了。Skill 不是。Skill 写好之后，只要你启用它，它就一直在那里，AI 每次遇到相关任务，都会自动参考它。你不需要每次都重新说，因为它已经记住了。
所以合在一起：Skill 是一份你写一次、AI 永久记住的工作说明书，告诉 AI 在特定类型的任务里，应该按照什么方式、什么标准、什么流程来工作。
我们换个方式打个比方。想象你是一个餐厅老板，你雇了一个厨师。
第一种方式：每天早上你跟他说，「今天做这道菜，用这些食材，按这个步骤做，注意火候」。他做完，明天你再重新说一遍。这是 Prompt 的方式——每次临时交代，每次从头开始。
第二种方式：你给他一本菜谱，上面写着你餐厅所有菜的做法、标准、要求。他来上班，直接看菜谱，按照菜谱做，不需要你每天重复解释。这是 Skill 的方式——一次写清楚，永久有效。
当然，你还是可以每天跟他说「今天的特别要求是……」，这是 Prompt。但菜谱是基础，是底层，是不变的部分。Skill 就是那本菜谱。
Skill 和 MCP 的区别
你在上一节课里刚学了 MCP，我知道你现在脑子里可能有点乱，搞不清楚 Skill 和 MCP 是什么关系。
一句话区分
MCP 是给 AI 装工具。Skill 是教 AI 用工具的方法。
比如你给 AI 装了 Playwright MCP，它现在有了「控制浏览器、模拟用户操作」的能力。这是工具。但光有工具不够，你还需要告诉 AI：当你用 Playwright 做测试的时候，应该按照什么结构来组织测试文件？应该遵循什么命名规范？应该先测什么、后测什么？遇到失败应该怎么处理？这些是方法，是规范，是流程。这就是 Skill 的工作。
有一句话，我觉得说得非常准确：
技能用于向 Codex 描述如何完成任务，而 MCP Server 负责向 Codex 提供可以调用的工具。
一个给能力，一个给方法。两者不是竞争关系，而是配合关系。
这节课真正想让你记住的三件事作业
第⼀件事：Skill是写给AI的⻓期⼯作说明书，不是⼀次性的Prompt。
Prompt解决"这次任务怎么做"，Skill解决"这类任务永远怎么做"。两者不是替代关系，⽽是分⼯关系。
第⼆件事：Skill的核⼼价值是稳定性，不是能⼒。
AI已经很有能⼒了，它缺的是⽅向感和⼀致性。Skill给了AI明确的⽅向，让它的输出从"随机发挥"变成"按规矩来"。这对真正做项⽬来说，⽐任何新功能都重要。
第三件事：先⽤，再写。
在你⾃⼰写Skill之前，你需要先⽤⼏个现成的Skill，感受⼀下它是怎么⼯作的，感受⼀下有 Skill和没有Skill的区别。等你真的感受到"这个Skill不够⽤，我需要⼀个更符合我项⽬的版本"的时候，你就有了写Skill的真实需求，写出来的东⻄才会真正有⽤。
作业练习
- 创建第一个金融分析相关的skill
- 触发验证：分析相关标的，确认该skill是否被正确触发。
- 把你的体验发到群⾥，说说：没Skill之前是什么感觉，有了之后⼜是什么感觉。
- 网页发布：使用该分析结果生成一个网页，并将其发布到公网上。
- 群内分享：把网页分享到群里
- 安装我的金融分析skill，分析为什么它能写出好的研报https://github.com/Qmeasure/codex-financial-cn/tree/main