编程
快来分享你的内容吧～
4 天前·后端- 07-24 10:26·后端GitHub 上大火的 AI Agent 项目 grill-me 技能 Skill 深度拆解，帮你在 AI 编程前把需求搞清楚。核心只有几句话，却能让 AI 反过来拷问你的需求。实战演示从模糊想法到完整桌面应用的开发全过程，解析决策树追问、单次提问、人机分工三层设计思想。查看全文加油鸭：太惊艳了！几句话的提示词竟能撬动60万次安装，这种化繁为简的洞察力和对AI协作本质的把握，真·高手思维！1358分享
- 07-22 10:39·后端GitHub 大神开源的 18 万 Star 的 Skills 仓库揭秘！手把手教你安装使用，带你看懂这套 AI 编程标准操作流程，包括 grill-me 需求拷问、TDD 测试驱动开发、Bug 诊断、AI 辅助学习、大项目规划、代码架构改进等核心技能，把经典软件工程方法论变成 AI 能执行的指令。查看全文加油鸭：鱼皮分享得太棒了！把工程方法论转化为可执行的AI技能，既有深度又有实操性，这份洞察力和分享精神真让人佩服！17427分享
- 07-21 12:11·后端怎么用 Claude Code 跑大规模代码迁移？Anthropic 官方的《六步迁移法》保姆级教程来了，手把手讲透规则驱动、试跑验证、多 Agent 流水线，几万行项目重构直接套用。查看全文加油鸭：太棒了！这篇深度解读干货满满，逻辑清晰、案例震撼，把AI代码迁移的方法论讲得透彻又实用，感谢鱼皮老师无私分享！1037分享
- 07-18 00:21·后端新模型 Kimi K3 实战项目测评，跟 Claude Fable 5 和 GPT-5.6 相比到底怎么样？前端和全栈工程能力如何？DeepSeek 2.0 时刻来了？查看全文加油鸭：鱼皮老师这波深度测评太硬核了！7个项目全跑通，K3的稳定性、前端表现和性价比确实惊艳，国产模型迈出关键一步，为你点赞！444分享
07-17 18:55·Java后端- 07-16 22:42·后端
- 07-16 16:01·后端Claude Code 动态工作流保姆级科普，高频 AI 应用开发面试题，从 Claude 官方五种多 Agent 系统模式讲起，拆解动态工作流的运作机制、上下文隔离设计、交叉验证策略，对比传统多 Agent 框架的本质区别查看全文加油鸭：太棒了！把动态工作流讲得既透彻又接地气，逻辑清晰、案例扎实，真是技术分享的标杆！8310分享
27 岁，我终于做出了自己的游戏！但是一行代码都没写
大家好，我是程序员鱼皮。 这是我在小孩儿时期最喜欢玩的游戏，做梦我都想不到，现在我竟然一个人从 0 做出了这个游戏，而且我只投入了 10 分钟！  没错，这是我用目前最新的 AI 大模型做的游戏，《以撒的结合》网页版！  大家猜猜看，我用的是什么大模型？跟 AI 对话了多少轮？又花了多少 money 呢？  ⭐️ 推荐观看本期视频版，演示效果更好：[https://bilibili.com/video/BV1sQGA6EEjp](https://bilibili.com/video/BV1sQGA6EEjp) 先揭晓前两个答案。我用的是 Claude Opus 5 模型，虽然 A ÷ 老是封禁账号、搞各种花里胡哨的骚操作，喂饱了我们这些 AI 编程博主。 **但我测试下来，这个模型是真的强。** 我是在 Cursor 这个 AI 编程工具中使用的，双剑合璧，让我完完全全从 0 开始，**只跟 AI 进行了一轮对话**，就开发出了你现在看到的成品游戏。  你肯定很好奇：一轮对话就搞定了？那提示词写的肯定很牛呗吧？！  来给你们看下完整的提示词，虽然又臭又长，但基本全是 AI 生成的，原始需求就那么两段，然后我让 AI 逐步迭代优化，扩展成了现在这样。  细品这段提示词，你会发现几个亮点。 - 需求写得足够明确具体 - 让 AI 利用联网技能搜索原作的游戏机制作为参考 - 还用了 Loop Engineering 循环工程的思路，让 AI 每完成一步就自己测试验证，发现问题自己修复，不断循环推进直到交付成品。 你肯定很好奇：AI 会不会是联网搜到了原版游戏的源码，然后直接抄下来改巴改巴就完事儿了？  来，我带大家看下 AI 的执行过程。 AI 搜索的是原本游戏的机制和美术风格，然后自己从零写了 5000 多行代码，所有图形素材都是用代码画出来的！  接下来 AI 会自己打开浏览器运行游戏、通过截图检查效果，甚至写了一个机器人去试玩自己的游戏！ 然后发现难度太大、根本玩不了，于是自己定位和修复问题，调整了几个小时才终于交付。  这就是 Opus 5 恐怖的工程能力，虽然慢了点儿，但这个过程完全不需要我人工花时间，睡了一觉，游戏就做好了~  而且成品质量相比其他模型，真的是降维打击！！！（不信你们自己试试）  接下来，我又开了个新对话，让 AI 帮我进一步扩展游戏，自主测试验证，并且要直接给我交付成品！  一觉醒来，AI 完成了任务，激动的心，颤抖的手，咱们来玩玩看。  怎么样，怎么样，怎么样？ 虽然比不上原版，但 AI 独立做到这个完成度，确实超出我的想象了，我自己试玩了半个小时都停不下来。  还没完！ 我想让大家都能玩上我做的游戏，怎么办？ 我只要再跟 AI 说一句话，让它用 EdgeOne Makers 网站部署技能直接上线。  很快 AI 就搞定了，还可以绑定一个自己的域名。  好了，现在大家都可以玩了~  还没完！ 我想让更多人帮我一起扩展游戏，怎么办？ 我只要再跟 AI 说一句话，让它帮我生成带有截图的项目介绍文档，并使用 GitHub MCP 插件直接把代码完全开源。  好了，现在大家都可以拿去二次开发了。 > 开源指路：[https://github.com/liyupi/binding-of-isaac-webgame](https://github.com/liyupi/binding-of-isaac-webgame)  六不六？ 玩着自己做的游戏，我真是感慨万千，小时候我做梦都想自己做一个游戏，但那时候完全不可能，没技术、没时间。而现在 AI 帮我圆梦了，不需要关注任何技术，就能一把梭搞定从开发到测试到上线的全流程。  虽然这次给大家展示的游戏作品只是两轮对话搞出来的 Demo，但完成度已经很高了。负责任地说，如果我再多花点时间，完全可以利用 AI 打磨出一个商业级产品，甚至让你看不出来是 AI 做的。 所以，都这个时候了，别再觉得 AI 搞不定复杂的项目了。 **老实说，我现在真的想不到还有什么想法是 AI 不能实现的。** 如果有，那就是没有驾驭好 AI，或者 tokens 不够。 大家肯定也有一直想做但做不了的东西，不管是一个产品、一个游戏、还是帮自己提升效率的工具，现在真的可以大胆尝试了。  最后揭晓开发这个游戏消耗的金额。 大概 400 多块钱，你觉得贵不贵？ 如果搁以前我去请一个程序员来做，最少也得好几万吧，而且估计得做一个多月。 不过 Opus 5 的价格还是挺贵的，不是所有任务都需要用这种级别的模型，大家还是要根据具体任务选择合适的模型。  那这个项目的完整提示词我放到了自己免费开源的 [《AI 编程零基础入门教程》](https://ai.codefather.cn/vibe) 里，上千张图、几十万字，带你从 0 开始快速学会 AI 编程，做出自己的产品、跑通变现全流程，一次拿捏。 > 开源指路：https://github.com/liyupi/ai-guide  我是鱼皮，关注我，轻松学会更多 AI 编程干货。 对了，你觉得 AI 能够取代程序员么？评论区聊聊。
A÷ 你还我账号！Claude 封号事件完整复盘
前几天，看到很多人免费薅到了价值 200 刀的 Claude Max 账号，我好羡慕。  这两天，又看到很多人的 Claude 被无故封号，我好同情。  **万幸的是，我没被封号。** 因为我早就对 Anthropic 失去信任了，根本没有 Claude 账号！  事情是这样的。 7 月 26 号，社群里突然传出一套操作方法，声称可以零元白票 Claude Max 20x 的订阅。 这是 Anthropic 官方最贵的套餐，月费 200 刀，能爽用 Claude 最强的模型。 还有这么好的事情？  然后你懂的，消息迅速传遍了推特、微信群和各种技术社区，甚至连闲鱼上都有人在卖教程。 虽然我没去薅，但出于对技术的热情（不是），还是探索了一下这个漏洞。 到底是怎么回事呢？ 简单来说，Claude 官网的支付页面存在一个安全缺陷。有人写了一段浏览器插件脚本，运行之后能篡改网页的结账页面，强行调出一个原本不对外开放的欧洲银行转账支付通道。然后用户只需要在网上随便生成一组虚假的银行卡号和地址信息，填进去点击订阅，系统就会判定支付成功，直接给你开通最高档的会员权限。  整个过程不需要花一分钱，立刻就能用上 Claude 最强的 Fable 5 模型，没有任何限制。 之所以出现这个漏洞，本质上是因为 Anthropic 的后端服务器太相信前端提交过来的信息了。 正常来说，用户在网页上选了什么套餐、用什么方式付款，服务器应该自己再校验一遍。但 Claude 的系统没有做这一步，前端说付了就是付了。再加上那个欧洲银行转账通道本身是异步扣款的模式，系统在确认到账之前就已经把会员权限发放出去了。 两个漏洞叠在一起，就成了零元购。  就好比一家自助餐厅的收银系统出了 Bug，门口的闸机不需要付款就能打开，这不得有一堆人涌进去吃霸王餐？ 据说当天好几家 API 中转站直接打出了跳楼价折扣，毕竟人人都能零元购了，谁还花钱找中间商啊。 可惜，好景不长。。 7 月 27 号，也就是漏洞曝光后的第二天，Anthropic 的工程师紧急上线修复，那个脚本彻底失效了。 **但修完漏洞只是第一步，紧接着就是大规模封号。** 众所周知，Anthropic 非常擅长封号。而这次被薅了带着恨，封号力度肯定非常狠，不只是封利用漏洞的账号，而是把关联的所有东西一起封。只要你的设备曾经登录过参与漏洞操作的账号，哪怕你另一个正常付费的老账号也在同一台电脑上用过，也会被连带封禁。 而且设备的硬件信息会被平台永久标记，之后再想注册新号用 Claude 都很困难。  更离谱的是，有些人根本没去薅这个漏洞，只是恰好跟薅漏洞的人用了同一个代理节点，结果也被封了。 宁可错杀，不能放过。 于是，很多无辜用户遭了殃。。。  漏洞本身确实是 A÷ 自己的技术问题，但在修复之后，他们选择了最激进的方式来止损。不仅封掉了利用漏洞的账号，还把能关联到的设备、IP 一起拉黑。 至于这个过程中误伤了多少正常用户，从之前 3.3% 的申诉成功率来看，他们似乎并不在意。 不过肯定有很多小伙伴好奇，这么离谱的漏洞是怎么发现的？A÷ 自己的模型这么强，怎么连这种漏洞都检测不出来？  所以，有人怀疑这次漏洞其实是 A÷ 的阳谋，故意留个口子让人来钻，趁机收集设备指纹和 IP 信息。还有人觉得 A÷ 本来就想清理一批账号，正好借这个漏洞事件把薅过羊毛的设备和 IP 一网打尽。 这个说法没有实锤，但考虑到他们之前在 Claude Code 里植入隐蔽追踪代码的前科，很多人宁愿信其有。 不管怎么说，对普通用户来说，最现实的问题就是接下来怎么办，用什么模型呢？  如果你预算有限，我觉得 Codex + GPT 系列模型是目前性价比又高又智能的均衡选择。OpenAI 经常毫无理由地赠送重置额度，根本蹬不完，很多办公自动化、网站开发任务用 GPT 5.6 完成度都很不错。  而且国产模型今年进步飞快，很多场景已经不比国外的差了。比如 Kimi K3 做前端开发和视觉效果很强，DeepSeek V4 性价比极高、是我做 AI 应用开发项目的首选底层模型，GLM 5.2 的全栈开发能力也很能打。  不过我敢说，虽然你会看到很多博主因为这次事件发文怒喷 Claude，但他们背后肯定还会继续用 Claude 的模型，只不过换一种接入方式罢了。 毕竟 Claude Opus 5 的编码能力确实是目前最强的，这一点我在之前的 [测评文章](https://mp.weixin.qq.com/s/NMHSFUq8lpY2inlWN7LFaA) 里已经详细验证过了，我用一轮提示词就能开发出下面这种游戏。  如果你预算充足，还是想用 Claude 系列模型的话，建议走 Cursor 这种官方合作方，比直接订阅 Claude 更稳定。何必整天跟 Anthropic 斗智斗勇呢？ 这次事件也给所有人提了一个醒。不管你用哪家的 AI，你的账号、你积累的对话历史、你的工作流，可能就在一封邮件之后全部归零。  所以，关键的工作流一定要有备用方案，能跑在本地的尽量跑在本地，不能因为一家公司的抽风，就决定你明天还能不能正常干活吧？ OK 就分享到这里，本文会收录到我免费开源的 [《AI 编程零基础入门教程》](https://ai.codefather.cn/vibe)，上千张图、几十万字，带你从 0 开始快速学会 AI 编程，做出自己的产品、跑通变现全流程，一次拿捏。 > 开源指路：https://github.com/liyupi/ai-guide  你怎么看待这件事，你的 Claude 还活着么，打算用什么替代方案？
Claude Opus 5 全新发布，7 大项目实测，夯还是拉？半价吊打 Fable 5？
大家好，我是程序员鱼皮。 前几天 Anthropic 发布了 Claude Opus 5，我第一时间写了一篇小短文，说 Claude Opus 5 宣称只用一半的价格，能力追平 Claude Fable 5 旗舰模型。 这个模型的跑分还是很能打的，比如 Frontier-Bench 这个测试，考察模型能不能在命令行里独立做完一整套编程任务。 Opus 5 拿了 43.3%，上一代 Opus 4.8 只有 18.7%，顶配的 Fable 5 是 33.7%，而 OpenAI 的 GPT-5.6 Sol 是 37.5%，可以说是遥遥领先了。  但是不能完全相信跑分，模型好不好用，还得拿真实项目来检验。 之前我写过一篇 [Kimi K3 模型测评文章](https://mp.weixin.qq.com/s/wsYtXWkl-2WYPSHVhYjZMQ)，为了便于跟 Kimi K3 等模型对比，接下来我会用跟之前一模一样的提示词，通过 **7 个不同类型的项目** 来测试 Opus 5 的实际编程能力。 测试方法很简单，我在 Cursor 里同时开了多个子 Agent，每个 Agent 一个独立的项目目录、一个独立的端口，全程不需要人工干预。等过段时间我回来一个一个验收就好。  激动的心，颤抖的手，点个收藏，咱们开始~ ## 项目实战测评 这次我准备了 **7 个项目** 来测试 Opus 5 的编程能力，从简单的前端动画、到复杂的全栈产品、甚至是企业级工程项目，由浅入深。 1. 交互式动画讲解网站 2. 3D 版动画知识讲解 3. 文案拆解为网页 PPT 4. 网页 PPT 生成工具（内置 AI 大模型） 5. 足球对战网页游戏（横评对比） 6. 以撒的结合肉鸽游戏 7. 全栈 AI 编程工具（复刻 Cursor） 大家可以猜猜看，跑完这些任务要花多少钱呢？ 答案在结尾揭晓~ ### 1、交互式动画讲解网站 第一个项目，让模型做一个用交互式动画讲解知识的网站，讲的知识点是「注意力残差」。 提示词里我要求它先用 Firecrawl 联网搜索技术细节，做完之后自己打开截图验证效果，不满意就自主调整，改到满意再交付。  来看成品，界面科技感满满，背景还有漂浮的光点特效。 而且整个网站很清晰、很结构化，用户可以像阅读教程一样连贯地学会这个知识，也可以通过左侧的章节导航快速跳转、查漏补缺。  不过页面上存在一些瑕疵，比如出现了文字被遮挡的情况，这点比 Kimi K3 的前端效果差了一些。  不过大多数的动画效果和元素位置都是准确的，个人感觉比 Opus 4.8 做动画网站的体验好太多了！  甚至给出了几道题目来检测学习效果，选错了还会告诉你为什么错，真是太贴心了，可以给到顶级。  ### 2、3D 版动画知识讲解 还是同一个知识点，这次换成 3D 场景来呈现。 提示词里除了联网搜索，我还要求它用 Context7 查一下所用 3D 库的最新文档，别拿过时的 API 来写。  来看成品，我刚打开页面就被惊艳到了，我 chovy！ 科技感爆棚，而且动画非常流畅生动。  可以自由切换视角、放大缩小，还能并排对比多种不同的残差模式。  从事教育行业的工作者有福了，可以让 AI 把枯燥的知识点通过动画栩栩如生地展示清楚，让学生更快理解。 单从前端的角度，我真的挑不出缺点，给到夯！ ### 3、文案拆解为网页 PPT 我做视频教程的时候，偶尔需要把文章内容做成演示画面，但手动做 PPT 太慢了。 这次我干脆把一篇技术文章丢给它，让它按照文章的讲解顺序，拆成一个能全屏演示的网页 PPT，后续可以当做视频录制的画面素材。  先看封面，完犊子了，这大标题…… 现在怎么 Claude 也一股子 GPT 味儿了。。。  整个 PPT 的效果跟其他模型差不多，毕竟我没给 AI 提供图片等素材，无非就那么几种布局。  整个 PPT 的科技感还是很足的，我觉得对于很多场合下的 PPT 讲演都是够用的。比如做毕业设计的同学，直接把自己的项目甩给 AI，毕设答辩 PPT 就搞定了，真爽死了……  从整体前端风格来看，给到顶级。 ### 4、网页 PPT 生成工具（内置 AI） 前面 3 个都是开胃小菜，接下来该测测它的全栈工程能力了。 上一个案例是给定一篇文章生成 PPT，那能不能把这个能力做成一个通用工具呢？ 用户粘贴任意文案，后端调用大模型拆解内容，前端渲染成可演示的网页 PPT，还要支持切换配色主题和导出成独立的 HTML 文件。 明确需求后，提示词就很简单了，由于涉及到 AI 能力，这里我用新出的 Kimi K3 模型作为给后端调用的模型（注意，项目本身的代码还是 Opus 5 生成的）。  来看看成品，之前用 Kimi K3 生成 PPT 工具的时候，成品非常精简，主页基本上就只有文案输入框和按钮。  但 Claude Opus 5 做的更像一个成熟的工具产品，你看左下角那一排配色主题就知道了，极光、象牙、暮色、青薄，这名字起的还挺文艺。而且每个主题下面还配了一句定位说明，细节做得非常好。 而且还可以填写生成 PPT 的额外要求。注意，我并没有在提示词中讲到这点，AI 自己帮忙锦上添花了。  随便拿我之前的一篇文章来制作 PPT，可以实时看到生成进度，直接查看效果，质量很高。  **说真的，现在这种全栈项目一把梭对于 AI 已经完全没有难度了。** 来切换个主题试试，效果不错吧，还能直接全屏演示或者导出为 HTML：  整体来说，无论是前端细节、还是后端生成逻辑做的都很好，一段提示词直接梭哈一个商业产品出来了，给到夯。 ### 5、足球对战网页游戏 经常看我文章的朋友应该知道，这个项目是老熟人了。 之前 GPT-5.6 发布的时候，我写过一篇 [《顶级国外模型横评对比》](https://mp.weixin.qq.com/s/jHHDR6J4ACj8cSY3UMltDQ)，用同一段提示词让 GPT-5.6 Sol、Claude Fable 5、Grok 4.5 三个模型同时开发了一个叫「2066 决战世界杯」的足球游戏。这次的提示词跟那时候完全一致，正好拿来做个对比。 先看赛前设置界面，做得还不错。浅绿主题色跟足球场是匹配的，相得益彰。  踢球、换人功能都是正常的，非常流畅。 而且注意到细节了没？9 号球员下方有个红色的蓄力槽，给了玩家更多的操作空间。  游戏的人机也非常智能，不像其他模型开发出来的人机只会防守，这次的人机甚至还能踢出配合。而且作为玩家，也不是完全没有机会赢过人机，游戏体验非常好。 对比一下之前几个模型的表现。GPT-5.6 Sol 开发的那版，人机不会主动进攻，我打满一整场中等难度，只能以 0 比 0 收场。  Grok 4.5 模型开发的那版，球场渲染有硬伤，换人逻辑也很不顺畅，经常切换到离球最远的那个队友身上。  Claude Fable 5 开发的那版，球的物理引擎翻车了，球经常会瞬移，根本没法正常玩耍。  而 Opus 5 不仅在人机智能上突破了，左侧还会实时展示赛况，这也是之前的模型都没有做到的。  美中不足的是，足球场的白线是不是有点儿问题？禁区前面那道罚球弧两端拐进了禁区里面。综合来看给到顶级。 ### 6、以撒的结合肉鸽游戏 接下来是一个更有挑战性的游戏项目。 以撒的结合是我小孩儿时代很爱玩的一款肉鸽游戏，包括随机地牢生成、射击战斗、道具系统、多种敌人和 Boss。 之前我让 Kimi K3 开发了这个游戏，提示词中要求先用 Firecrawl 搜索以撒的结合的游戏机制和美术风格资料，用 Context7 查询所用游戏框架的文档：  当时 K3 开发出的效果是这样的，虽然界面看起来简陋，但基本玩法是完全跑通的，可以发射子弹打击怪物：  再来看看这次 Opus 5 用同样的提示词开发出的成品，前方高能！ 打开网页，光是看到这个游戏主页，我的 DNA 就动了！有没有玩过这个游戏的同学，这个形象跟原版还是很接近的吧？   之前我用 Kimi K3 做这个游戏的时候，整个游戏的玩法链路已经跑通了，我当时都已经觉得很满足了。。。  结果没想到 Claude Opus 5 的效果这么好！很多小怪都是原版游戏中存在的。  而且角色的数值清晰、道具丰富多样，可以说是还原了《以撒的结合》游戏的精髓。 我甚至都玩进去了，导致这篇文章发布时间晚了 20 分钟。。。  BOSS 的机制也跟原版《以撒的结合》游戏中的 BOSS 神似！  大家觉得怎么样？ 说真的，完全超出我的预期了，给到夯爆了！以后我也有戏做一些游戏了，skr~ ### 7、全栈 AI 编程工具 最后一个项目，直接把难度拉满！ 我让 AI 基于 VS Code 的开源代码，开发一个类似 Cursor 的 Web AI 编程工具，要支持 Editor Window 代码编辑器和 Agents Window 对话工作台两种模式，两个窗口之间可以自由切换。 看看成品，几乎完整地保留了 VSCode 的精髓，比如代码高亮、代码小地图、管理面板、代码搜索等等。  来让 AI 执行个任务试试，你能清晰地看到 AI 的思考信息、工具调用等等。  AI 甚至能够调用终端、自主测试开发出的代码，还能清晰地看到本次改动的文件！  怎么样，你敢相信我只跟 AI 对话一次，就开发出了自己的 Cursor 么？简历上又多了蓬荜生辉的一笔。 我的评价是夯爆了！ ## 我的感受 7 个项目全部跑完了，让我印象最深刻的一点是，Claude 没有完全机械地、用最简单直接不绕弯子的方式完成任务，你让它做什么它就只做什么，而是会在你提示词需求的基础上加一点自己的想法，尽量达到理想的效果。 它不仅后端逻辑强、前端视觉效果也强，还非常注重细节，真的是六边形战士了。 **至少对我来说，我暂时想不到什么开发任务 AI 完不成了。** 如果有，那就是我没有驾驭好 AI，或者 tokens 不够。 另外一个让我印象深刻的点是，Opus 5 确实像官方说的那样，特别爱自己检查作业。Anthropic 甚至专门提醒开发者把提示词里那句「最后记得验证一遍」删掉，你越叮嘱它反而越容易检查上瘾。他们后来干脆把 Claude Code 的系统提示词删掉了 80% 以上，编程跑分一点没掉。 以后用这种级别的模型，该给你的提示词做做减法了，把精力花在明确需求和目标上就好，不用事无巨细地规定每一步该怎么做。  当然，这个特性是一把双刃剑，Opus 5 很容易把简单的任务搞复杂，这是 Claude 一贯的通病，也就更废 tokens。 如果你想更好地利用 Opus 5 这种级别的模型，还是要在提示词上多下下功夫，不是说要写的又臭又长，**而是把需求描述清楚、限制好 AI 的边界**，否则它搞不好就浪飞边子了。 最后，揭晓谜底，这 7 个任务打包加起来，一共花了我 900 多块。 这就是效果好相应的代价，之前我用 Kimi K3 等国产模型做同样的项目，加起来套餐额度才动了百分之几。 所以还是要根据你的实际需求来选择模型。 - 如果是追求 90 分效果的任务，可以交给 Opus 5 - 只需要 80 分的任务，可以交给 GPT 或者 Kimi K3 / GLM 5 这类模型，快、稳、便宜 - 如果任务只要及格就好，那就用性价比极高的 DeepSeek 吧 OK 就分享到这里，本文会收录到我免费开源的 [《AI 编程零基础入门教程》](https://ai.codefather.cn/vibe)，上千张图、几十万字，带你从 0 开始快速学会 AI 编程，做出自己的产品、跑通变现全流程，一次拿捏。 > 开源指路：https://github.com/liyupi/ai-guide  我是鱼皮，持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~ 也欢迎在评论区聊聊：你觉得这钱花得值么？你现在主力用的是哪个模型？
全网安装量前 3 的神级 Skill，竟然只有几句话？！
大家好，我是程序员鱼皮。 最近有一个 Skill 很火，已经被安装了 60 多万次，还登上了《技能安装量排行榜》的第 3 名。 **可是你敢信么，这个 Skill 的核心内容居然只有几句话！** 它就是 `/grill-me`，一个让 AI 反过来拷问你的技能。  在如今新 Skill 层出不穷、已经跟鱼皮头发一样卷的时候，这个只有几句话的 Skill 凭什么能杀出重围呢？ 下面我先给大家介绍一下这个技能，然后通过一个项目实战带你了解它的功效，最后再分析一下这个技能的底层原理，给大家一些 AI 编程上的启发。 ## grill-me 是什么？ 所谓 Skill 技能，就是一份写给 AI 的操作说明，安装之后可以让 AI 按照指定的流程做事。 grill-me 这个技能 **只有一个文件**，文件里写的全部内容就是下面这些。  翻译过来是这样的： > 针对我的计划，反复追问每一个细节，直到我们形成共同理解。沿着决策树的每个分支往下走，逐一理清各项决策之间的依赖关系，有些选择必须等前一个问题确定了才能回答，AI 会按这个先后顺序逐个问清楚。每个问题都要给出你的推荐答案。 > > 每次只问一个问题，等我回答了再问下一个。一次抛出一堆问题会让人不知所措。 > > 能通过查看环境（文件系统、工具等）找到的事实，直接去查，不用问我。但决策是我来做的，每个决策都要等我拍板。 > > 确认双方理解一致之前，不要开始行动。 你可能会好奇：就这么几句话也能叫 Skill？不就是提示词吗，能好使吗？  来，下面我用一个实战项目试试看！ ## grill-me 实战体验 首先安装 grill-me，打开终端输入一行命令就搞定了： ```bash npx skills add https://github.com/mattpocock/skills --skill grill-me ```  装好之后，我随便打开一个 AI 编程工具，就以 Cursor 为例吧。 我给 AI 提出了一个很模糊的需求，并且使用 `/grill-me` 技能：  执行！ AI 先思考了一下，然后开始一步步拷问我…… 首先 AI 问我要做的东西具体是指什么，同时给出了它的建议。我甚至不用自己组织需求描述，直接回复「你的建议是对的」就好。  然后 AI 问我要把这个东西做成什么形态，并提供了几个选项。我觉得做成 Web 应用更方便，直接输入序号 3。  接着 AI 问我需要哪些功能。正常来说应该先从核心功能开始做，但我觉得这些需求都不复杂，AI 应该能一把梭。 所以贪心一点，我全都要！  需求明确之后，AI 开始询问技术方案。这里我选了 Electron 桌面端应用，因为可以直接访问本地文件，用起来更方便。  然后 AI 就开始跟我依次确认具体的技术细节了，比如用什么开发框架、什么组件库、怎么存储数据之类的。  不了解 AI 说的技术、或者没什么特别想法的时候，直接按照 AI 的建议来就行。 「接受你的建议」可能是我整个过程里说得最多的一句话。  经过了十多轮问答，很多我之前根本没想到的细节都被 AI 逼着想清楚了。 最后 AI 给出了一份完整的方案总结，等我确认后就启动开发。  确认之后，我让 AI 直接开始写代码。因为前面已经把需求和方案讨论得足够清楚了，AI 写代码的过程比直接让它猜需求顺畅不少。  10 分钟左右，一个管理 Skill 的桌面应用就搞定了，就问夯不夯？  回过头看整个过程，你会发现：这不正是企业开发中的经典流程吗？ 从一个模糊的想法开始，先明确需求，列出功能点，再确认技术选型和设计方案，最后才进入开发。 只不过以前这套流程需要产品经理、架构师、开发者一起开会讨论，现在 AI 全包了，整个过程就像有个经验丰富的技术导师带着你一步步把事情理清楚，无比轻松。 ## grill-me 背后的思考方式 体验完 grill-me 之后，我带大家拆解一下 grill-me 的设计。 别看只有短短几句话，里面其实暗含了好几层思考，这些是 grill-me 大火的原因。 **首先，grill-me 瞄准了 AI 编程中最关键的环节。** 现在 AI 写代码的能力已经很强了，给它一个清晰的需求，大部分情况下都能写出来。 但大多数人让 AI 写代码的时候，自己都还没想清楚到底要做什么，AI 只能靠猜，猜错了就得反复返工。 grill-me 做的事情就是在开发之前，帮你把需求逼清楚。 **其次，grill-me 的追问方式很有章法。** 它会按照决策树的逻辑来走，所谓决策树就是把一个大问题拆成一连串的选择，先确定一个再根据答案追问下一步，环环相扣，能大大减少关键细节被遗漏的概率。 而且它要求每次只问一个问题，不会一股脑抛出一堆让你不知所措。 **还有，grill-me 的人机分工非常清晰。** 能从项目文件和工具中查到的事实，AI 自己去找，不会浪费你的时间。只有需要你拿主意的设计决策，才会停下来等你回答。 「给出推荐答案」这个要求是作者后来特意加上去的，如果 AI 不给建议，你还得自己想半天怎么回答，有了推荐答案之后，如果你表示认同，直接说 yes 就行，对话效率高了很多。  这个技能让我想到了程序员界的「小黄鸭调试法」，就是在桌上放一只橡皮鸭，把你的想法一步步讲给它听，讲着讲着就能发现自己思路里的漏洞。grill-me 相当于给你一只会追问、会推荐、还能自己查资料的智能赛博鸭鸭 🦆。  **不管做什么事，把想法说清楚这一步本身就是最有价值的**，而 grill-me 把这件事变成了一个可执行的流程。 它不仅能应用到 AI 编程，还能用到你日常生活中需要做决策的任何场景，比如规划学习路线、选择电脑配置、制定健康计划等等，都可以用同样的思路让 AI 来拷问你。  相信我，次数多了，你会爱上这种感觉，也能让你的逻辑思维更清晰。  对了，这两天我更新了一波自己免费开源的 [《AI 编程零基础教程》](https://ai.codefather.cn/vibe)，把项目实战部分的 20 多个项目进行了分类整理，阅读体验更好了~ 上千张图、几十万字，带你从 0 开始学会 AI 编程。 > 开源指路：https://github.com/liyupi/ai-guide  我是鱼皮，持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~ 评论区聊聊，你有没有用过 grill-me 这个技能，感觉效果怎么样？
揭秘 GitHub 最火的开源 Skills 仓库，夯爆了！30 秒带你用上，让 AI 效率起飞
大家好，我是程序员鱼皮。 如今的 GitHub 真是太魔幻了，有个 AI 相关的项目，几乎全是 Markdown 文本文件，但是不到半年就拿到了 **18 万 Star**！ 这个仓库叫 [skills](https://github.com/mattpocock/skills)，作者 Matt Pocock 是前端 TypeScript 领域很有名的教育者，在 YouTube 上有大几十万粉丝。 他把自己日常用 AI 编程的工作方法总结成了一套技能，也就是一组可以直接装进 Claude Code、Codex 等 AI 编程工具里的指令集，然后开源了出来。  那么这套 Skills 到底有什么？为什么能受到这么大的欢迎？ 这篇文章我就带大家揭秘这个仓库，看看怎么安装使用、里面有哪些值得学习的 AI 编程技巧。 点个收藏，咱们开始 🐟 ## Skills 仓库介绍 这个仓库的 Slogan 是「Skills for Real Engineers」，意思是这套东西不是给 Vibe Coding 氛围编程用的，而是给真正要做工程的人用的。 简单来说，这个仓库提供了一套 AI 编程的 **标准操作流程**。 用过 Claude Code 的同学应该知道，你可以通过写 `CLAUDE.md` 文件来告诉 AI 该怎么做事。但大多数人写的要么是一些零碎的注意事项，要么就是从网上抄来的通用提示词，效果一般。 Matt Pocock 做的事情是把真实的软件工程方法论，比如测试驱动开发、代码评审、领域建模这些，浓缩成一个个 Skill 文件。你装到自己的电脑上后，在 AI 编程工具里输入类似 `/grill-me`、`/tdd` 这样的斜杠命令，AI 就会按照对应的工程方法来工作，而不是像平时那样想到哪写到哪。  截止到我写这篇文章时，整个仓库里有大几十个 Skill 文件，其中正式推荐使用的有 22 个，剩下的是一些还在开发中的、作者个人专用的、以及已经废弃的。  这 22 个正式 Skill 分成两大类。 一类是工程类，包括测试驱动开发、代码评审、Bug 诊断这些跟写代码直接相关的；另一类是生产力类，比如头脑风暴、上下文交接，甚至还有一个让 AI 教你学东西的。 下面我先教大家怎么把这些 Skill 装到自己的项目里，然后再挑几个最实用的详细讲讲。 ## 30 秒快速使用 这个仓库的安装很简单，打开终端，输入一行命令就能搞定： ```bash npx skills@latest add mattpocock/skills ```  运行之后它会让你选想要哪些 Skill，以及装到哪个 AI 编程工具里。选完之后，对应的 Skill 文件会被复制到你的项目目录或者 AI 工具的本地配置目录（比如 `~/.claude/skills/`）。  建议选上 `/setup-matt-pocock-skills` 这个初始化 Skill，装完后在 AI 编程工具里运行一次，比如我在 Claude Code 中运行：  AI 会问你几个问题来适配你的项目。比如用什么工具来管理 Issue、项目文档保存在哪个目录。 我这里为了简单，选择了用本地 Markdown 文件来管理 Issue，文档保存在默认的 `docs/` 目录下，规则保存到 `CLAUDE.md` 文件中。  如果你不想手动管理这些安装到项目里的 Skill 文件，也可以用 Claude Code 的插件方式来安装，这样它会自动保持最新版本，不过就不能自己修改了。  装好之后，接下来我带大家看看这个仓库里最实用的几个 Skill。 ## `/grill-me` 需求拷问 这是整个仓库最火的一个 Skill，也是 Matt Pocock 本人反复推荐的。 它的作用是让 AI 反过来对你进行「灵魂拷问」，帮你在让 AI 写代码之前把需求和设计想清楚。 **但是，它的核心内容加起来竟然只有 3 句话！** 翻译过来大概是这样的： > 针对我的计划或设计，一个问题一个问题地追问我，直到我们达成共识。沿着决策树的每个分支走下去，逐个解决分支之间的依赖关系。每个问题要给出你的推荐答案。 > > 每次只问一个问题，等我回答完再问下一个。一次抛出一堆问题会让人不知所措。 > > 能通过查看环境（文件系统、工具等）找到的事实，直接去查，不用问我。但决策是我来做的，每个决策都要等我拍板。  没错，就是这么简单粗暴。 但实际用起来后，你会发现效果确实很牛 X。 有用户分享说，他第一次用 `/grill-me` 的时候，AI 一口气问了 38 个问题。等问完之后，他发现很多自己之前根本没想到的设计细节都被 AI 逼着想清楚了。  其实对我们程序员来说，这个思路并不新鲜，有点像「小黄鸭调试法」，就是通过把你的想法讲给别人听，来帮助自己发现问题。只不过以前这只鸭子不会说话，现在 AI 这只鸭子能够刁难你了。 而且 `/grill-me` 的设计有一个很关键的细节，**它要求 AI 一次只问一个问题，等你回答了再问下一个**。这样可以避免 AI 一下子抛出一堆问题让你不知所措的情况，整个对话体验会更像一场真正的需求评审。  如果你在做的是一个有代码仓库的项目，可以用升级版的 `/grill-with-docs` 技能。它在拷问你的同时，还会把讨论过程中确定下来的术语和决策记录到 `CONTEXT.md` 和架构决策记录文件里，给你的项目建一份专属术语表。 这个术语表有什么用呢？ 大家应该都有过这种经历，每次跟 AI 描述项目里某个操作的时候，都要写一大段话来解释，因为 AI 并不了解你们项目内部的叫法。 Matt Pocock 的做法是在 `CONTEXT.md` 里提前定义好这些术语。比如他自己有个课程管理项目，针对「把课程章节中的某节课创建到文件系统」这个操作，他定义了一个术语叫「物化级联」，之后跟 AI 沟通的时候只需要说这个词，AI 就知道他在说什么了。 因为 AI 每次对话都会读 `CONTEXT.md`，所以这些术语积累得越多，AI 对项目的理解就越精准，沟通也越来越高效。  ## `/tdd` 测试驱动开发 大家有没有遇到过这种情况？ 当你要求 AI 用测试驱动的方式来开发时，它会一口气先把所有测试写完，然后再写所有代码。 **这种方式看起来效率很高，但实际上有个很坑的问题。** AI 在写测试的时候，代码还不存在，所以它只能靠想象来设计测试的结构。等真正开始写代码的时候，实际的 API 可能跟它想象的完全不一样，结果就是一堆测试要推倒重写。 `/tdd` 这个 Skill 就是来解决这个问题的。它强制 AI 用「垂直切片」的方式来工作，也就是先写一个测试让它失败 ❌，然后只写刚好能让这个测试通过的代码 ✅，通过之后再写下一个测试。这就是经典的 Red-Green-Refactor 循环，一次只走一小步，每一步都是实打实验证过的。  除了循环本身，这个 Skill 里还有几条值得注意的规则。 比如它要求 **只在预先商定的接缝处测试**。所谓接缝（Seam）就是代码的公开接口，比如一个函数的入参和返回值。在写任何测试之前，AI 会先跟你确认在哪些接缝处写测试，而不是到处乱写，这样测试的覆盖重点才能落在真正重要的地方。  另外这个 Skill 还列出了几种 AI 写测试时容易犯的反模式，相当于给 AI 定了规矩，一旦发现自己写出了这类测试就必须改掉。 最典型的一种叫「同义反复测试」，就是把被测代码的逻辑在测试里重新写一遍，比如 `expect(add(a, b)).toBe(a + b)`，这样的测试永远都能通过，毫无意义。 正确的做法是用独立的数据源来做期望值，比如一个确定的字面量、一个手工算好的例子。 对于团队项目来说，让 AI 按照 TDD 的方式来写代码，代码质量会有明显的提升。 ## `/diagnosing-bugs` Bug 诊断 遇到 Bug 的时候，很多人的第一反应都是先看代码，猜一个可能的原因然后试着改。AI 也是这样的，大家应该有过这种经历，让 AI 修 Bug，结果它改了半天越改越乱。 Matt Pocock 认为问题的根源在于 AI 跳过了最关键的一步，就是先建立一个 **能稳定重现 Bug 的反馈循环**。 什么叫反馈循环呢？ 简单来说就是一条能稳定重现 Bug 的命令。可以是一个会失败的测试用例、一个 curl 请求、甚至一个 Playwright 浏览器自动化脚本，只要能一键运行并且明确告诉你 Bug 到底有没有触发就好。 `/diagnosing-bugs` 这个 Skill 把 Debug 过程拆成了 6 个阶段，其中「建立反馈循环」是第一步，也是整个流程的核心。  **在这步完成之前，AI 不允许跳到「猜原因」的阶段**。如果 AI 在还没有一条能重现 Bug 的命令的时候就开始分析代码，Skill 会直接打断它。 等有了一条稳定重现的命令之后，接下来的步骤就比较常规了。最小化重现场景、提出假设并逐一验证、修复并写回归测试。  这个思路跟 Cursor 内置的 Debug 模式有点异曲同工。Cursor 的 Debug 模式也是先通过自动检测和分析错误来定位问题，而不是让 AI 上来就瞎猜和乱改。 不过 `/diagnosing-bugs` 更偏向于流程规范，它用一套严格的分阶段方法来约束 AI 的调试行为。先让 AI 建一个靠谱的重现方式，后面的修复效率反而会高很多。 ## `/teach` AI 辅助学习 前面几个 Skill 都跟写代码有关，但这个仓库里还有一些通用的生产力工具。比如 `/teach` 技能，作用是让 AI 变成你的私人教师。 按照作者 `/grill-me` 技能的尿性，我以为这个 Skill 也就几句话，比如我自己经常写的： ```markdown 用傻子都能懂的语言，帮我学习 XX 知识点，通过联网搜索获取最新信息 ``` 但其实，这个技能不只是让 AI 给你讲个知识那么简单，它背后有一套相当完整的教学方法论。 当你运行 `/teach` 并告诉 AI 你想学什么之后，AI 会先问你为什么想学这个东西？  然后 AI 会把你的学习目标记录到一个叫 `MISSION.md` 的文件里。  接着它会去搜索高质量的学习资源，整理成 `RESOURCES.md` 资源文件。  最后基于收集到的资源给你设计课程，每堂课是一个精美的 HTML 文件，保存在 `lessons/` 目录下。  值得一提的是，AI 会区分「流畅度」和「存储强度」这两种学习效果。流畅度就是你当场能回忆起来的感觉，但这不代表你真的记住了。存储强度才是真正的长期记忆。所以它会刻意设计有一定难度的练习，用间隔重复和交错练习等方法来帮你加深记忆，而不是让你产生「我已经学会了」的错觉。 还有个很妙的设计是「最近发展区」，这是教育学里的经典理论。AI 会根据你之前的学习记录来判断你现在的水平，然后设计刚好超出你能力一点点的课程内容，不会太简单让你感到无聊，也不会太难让你放弃。 而且你的所有学习过程都被保存在当前目录下，下次打开同一个目录继续学的时候，AI 就能接着上次的进度来，有种 AI 时代的个性化教育的感觉。 ## `/wayfinder` 大项目规划 这个 Skill 专门解决一个问题：当项目大到一个 AI 对话装不下的时候，该怎么办？ 用过 AI 编程的同学应该都有感受，如果你强行在一个很长的对话里完成所有事情，AI 的思考质量会随着上下文变长而明显下降。Matt Pocock 把 AI 表现最好的上下文范围叫做「智能区间」，大概在 120K tokens 以内。 `/wayfinder` 的做法是把一个大需求拆成一张「决策地图」。当你面对一个大而模糊的需求时，AI 会先跟你一起把最终目标定义清楚，然后在 Issue 管理工具里创建一张地图，上面列出需要做的一系列决策，每个决策是一个独立的 Issue。  这些决策之间有依赖关系，所以它会自动标注哪些可以先做、哪些要等前置决策完成才能开始。  每次你打开一个新的 AI 对话来处理一个决策的时候，上下文都是干净的，不会被之前的内容污染。 这个思路其实跟企业开发中的「模块化」很像，把一个大项目拆成多个模块分给不同的开发者，每个人只需要关注自己负责的部分。 这里面还有一个很有趣的设计叫「战争迷雾」，就像游戏里没探索过的地图区域一样。你现在能看到的决策只是一部分，随着前面的决策逐步完成，后面的决策才会逐渐清晰起来。这样可以避免一开始就过度规划那些还想不清楚的事情。  不过这个 Skill 的门槛相对比较高，更适合有一定工程经验的开发者来使用。如果你的项目规模不大，前面提到的 `/grill-me` 就够用了。 ## `/improve-codebase-architecture` 代码架构改进 除了日常的开发流程，Matt Pocock 还建议每隔几天就跑一次 `/improve-codebase-architecture` 技能，相当于定期给代码做一次体检。它会深度扫描你的代码库，找出那些结构上可以优化的地方。  代码扫描完成后，AI 会生成一个可视化的 HTML 报告，而不是枯燥的文字。报告里用 Tailwind 美化样式、用 Mermaid 画架构图，每个优化建议都是一张卡片，上面写着涉及的文件、当前的问题、建议的改进方案，还有改进前后的对比图。  每个建议还会标注推荐程度，有些是强烈推荐的，有些是值得探索的，有些只是试探性的。你选一个感兴趣的之后，它就会启动一轮新的 grilling 对话来跟你讨论具体怎么改。 这个 Skill 背后的核心理念来自《A Philosophy of Software Design》这本书。打个比方，一个好的模块就像微波炉，你只需要按几个按钮就能加热食物，内部的电磁波原理完全不用管。这种叫做「深」模块，接口简单，实现复杂。  但如果一个模块用起来跟自己写一个差不多费劲，那就是「浅」模块了。这个 Skill 要找的就是代码库里那些「浅」模块，帮你把它们变成「深」模块。 ## `/handoff` 上下文交接 大家用 AI 编程的时候应该都遇到过这个问题：在一个对话里讨论了很多内容，积累了大量上下文，但是要开一个新对话的时候，之前的所有讨论就全丢了。 虽然可以手动复制粘贴，但是比较麻烦，还容易遗漏关键信息。 `/handoff` 技能就是来解决这个问题的。在你当前对话结束前，它会让 AI 把整个对话的核心内容压缩成一份交接文档，保存成一个 Markdown 文件。  下次开新对话的时候，只要让 AI 读一下这个文件，它就能接着上次的进度继续工作。 这个交接文档还会标注建议在新对话中使用哪些 Skill，并且会自动去除敏感信息，比如 API 密钥之类的。  这样一来，多轮对话之间可以无缝协作了。 ## 最后 学习完这个仓库后，我感受最深的一点是，这些 Skill 本质上不是提示词技巧，而是把经典的软件工程方法论封装成了 AI 能执行的格式。 像测试驱动开发、领域建模、架构评审，这些理念在软件工程领域已经存在了二十多年，但以前你得靠团队协作和代码评审来落地，现在通过 Skill 文件就能让 AI 自动按照这些方法来工作。 而且通过这个仓库，你会发现，AI 时代做开源从未如此简单！ Matt Pocock 本质上就是把自己电脑里 `.agents` 目录下的工作方法分享了出来，然后持续迭代打磨，就成了十几万 Star 的项目。也许你也可以把自己积累的 AI 编程工作流或提示词模板整理一下开源出来，持续优化，说不定也能帮到很多人。 **果然，行动才是第一生产力。** 对了，今天我更新了一波自己免费开源的 [《AI 编程零基础教程》](https://ai.codefather.cn/vibe)，把项目实战部分的 20 多个项目进行了分类整理，阅读体验更好了~ 学 AI 编程从这里开始 🛫  我是鱼皮，持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~ 也欢迎在评论区聊聊：你有用过这些技能么？你在 AI 编程时，有哪些好用的方法和技能推荐？
用 Claude Code 重构百万行代码？官方教程终于来了！
大家好，我是程序员鱼皮。 前几天 Anthropic 官方发了 [一篇博文](https://claude.com/blog/ai-code-migration)，讲的是他们内部如何用 Claude Code 跑大规模代码迁移。 这篇文章的含金量非常高，因为里面的两个案例实在太炸裂了！  第一个案例，前端圈很火的工具 Bun 的创始人 Jarred Sumner（目前也是 Anthropic 的技术员工），用 Claude Code 把 Bun 从 Zig 语言重写到 Rust。整整 53 万行代码，只用 11 天就完成了，而且 100% 测试通过后合并上线。 第二个案例，Anthropic Labs 的联合负责人 Mike Krieger 只用了一个周末，把一个 Python 项目迁移成了 16.5 万行 TypeScript，全平台构建时间从 30 分钟降到了约 2 秒。 **一个周末，重构 16.5 万行代码，什么概念？** 以前这种量级的工程，再牛的团队也得干上一两年，还不一定能做到 100% 兼容。现在一个人加一个 AI，几天就搞定了。 大家肯定很好奇，他们是怎么做到的，这背后有什么方法和技巧吗？ 下面我会结合官方博文的内容，加上 Bun 官方的技术博客、以及我自己使用 AI 编程的经验，给大家做一个完整的中文深度解读。 学会这套方法之后，几万行代码的项目重构、技术栈升级、老项目翻新，你都可以用同样的思路高效完成。 ## AI 迁移代码的核心思路 用 AI 迁移代码时，你的工作不是修改代码，是在设置「产出代码的流程」。 传统的代码迁移思路是一个文件一个文件地翻译，翻译完了逐个检查，发现问题逐个修复。 这种方式在几十个文件的规模还可行，但如果文件数量成百上千，基本就不可能了。 正确的思路是 **把注意力放在流程上**。 当你发现 AI 在某类翻译上反复犯同样的错，不要一个一个去修那些错误的代码，而是去修复规则手册，让所有后续翻译都不再犯这个错。随着规则越来越完善，你需要人工干预的次数会越来越少。  我刚开始用 AI 编程的时候，经常是一个个修复 Bug。AI 犯了一个错，我纠正一次，下次又犯同样的错，我再纠正一次。反反复复，非常低效。 后来我开始把踩过的坑写进 CLAUDE.md / AGENTS.md 或者 Rules 文件里，每次纠正 AI 的错误都顺手沉淀成规则。 随便举个例子，比如我发现 AI 生成 Spring Boot 接口时总是忘记加参数校验注解，我就加了一条规则： ```markdown 所有 Controller 层的请求参数必须使用 @Valid + DTO 校验，禁止在 Service 层手动 if 判空 ``` 从此再也没出现过这个问题。 所以无论是百万行代码迁移，还是你平时 Vibe Coding 项目，都应该有这个意识：**出了问题不要只盯着问题本身，要修复产出问题的源头**。 ## 六步迁移法 Anthropic 总结了一套完整的大规模代码迁移流程，总共六步。 开局一张图，你就知道这套方法论大概有多 NB 了。  ### 0、搞定验证机制 在动手迁移之前，你必须有一个可靠的验证机制。没有验证机制，你都不知道什么时候可以收工。 最理想的情况是像 Bun 一样，已经有一套完整的测试套件，而且测试是用第三方语言写的（Bun 的测试用的是 TypeScript），不依赖被迁移的语言本身。 但如果你的测试跟源代码是同一种语言写的呢？ 建议是先把测试分类。哪些测试是通过外部接口验证行为的？哪些是依赖内部实现细节的？ 外部接口的测试可以直接复用，内部实现的测试需要重写成跟语言无关的形式。 开头提到的例子中，Mike 的项目没有现成的测试套件，他的做法是让 Claude 创建了一个 **对比脚本**，跑 7 个真实场景，把 Python 版本和 TypeScript 版本的输出做 diff，任何行为差异都算 Bug。 这个思路对小项目也完全适用。哪怕你只是把一个 Python 脚本迁移到 TypeScript，也可以让 AI 帮你准备几组真实的输入输出样本，迁移完了跑一遍，看看结果一不一样。 ### 1、制定规则手册和依赖图 这一步是整个流程里人工投入最多的阶段。  Bun 创始人 Jarred 光是跟 Claude 讨论怎么把 Zig 的模式映射到 Rust 就花了 3 个小时，最终产出了一份 576 行的规则手册，里面详细规定了每种类型怎么映射、每种惯用法怎么转换。 规则手册的内容取决于一个关键策略：**新代码是保持原有架构逐行翻译，还是完全重新设计？** Jarred 选择的是保持架构不变的机械翻译，所以他的规则手册主要是一个对照表。他还让 Claude 跑了一个工作流，分析代码库里每个 struct 字段的生命周期，输出成一个 `LIFETIMES.tsv` 文件给后续翻译参考。  而 Mike 选择的是重新设计架构，所以他的规则手册更像是一份设计文档，描述新系统应该长什么样。 除了规则手册，依赖图也很重要。你得知道哪些文件依赖哪些文件，这样才能决定迁移的顺序、哪些文件可以放在同一批处理。 对于像 Python 这种依赖关系不显式声明的语言，可以让 Claude 写一个脚本去分析和生成依赖图。Anthropic 还开源了一个 [代码迁移工具包](https://github.com/anthropics/code-migration-kit-with-claude-code)，里面就包含了现成的依赖分析脚本，拿来直接用就行。  此外，还要做一份「差异清单」，列出源语言和目标语言之间那些不能简单翻译的地方。 比如 Zig 到 Rust 的核心差异是手动内存管理变成了所有权系统，Python 到 TypeScript 的核心差异是动态类型变成了需要显式声明接口。这些差异点是 AI 最容易犯错的地方，必须在规则手册里重点标注。 ### 2、小范围试跑 规则手册写好之后，不要急着全量执行，先拿 3 个文件试试水。  我觉得 Bun 创始人 Jarred 的做法很机智。他让一个 Claude 实例按照规则手册翻译 3 个文件，同时让另一个 Claude 实例以「高级 Rust 工程师」的身份翻译同样的 3 个文件。然后再开一个全新的 Claude 对话，专门用来对比两个版本的差异，从差异中提取新的翻译规则。 这一步他发现了 2 个关键问题，如果直接铺开到全部 1448 个文件，后果不堪设想。 对于重新设计架构的项目，做法不太一样。Mike 是让多个 Claude 实例从不同角度挑设计文档的毛病，看有没有逻辑漏洞或考虑不周的地方。然后跑一次完整的端到端翻译，看看设计在实际执行中有没有问题，发现了问题就改规则、重跑。 有趣的是，他实际上跑了三次完整迁移，**前两次都丢弃产出，只保留对规则的改进，直到第三次才正式保留结果。**  我看到这里，第一反应是：前两次直接丢弃，这不是浪费 Tokens 么？ 但其实，对于复杂的项目来说，这么做是合理的。试跑阶段的目标就是打磨规则，试跑出来的代码未必正确可用，如果直接应用这些代码，搞不好会影响整个项目迁移。 这点对普通开发者也很有启发。很多人用 AI 做项目的时候，总想着一步到位。其实不妨先让 AI 做一个粗糙的版本，看看哪里不对，完善好提示词和规则之后再正式开始，磨刀不误砍柴工。 ### 3、全量翻译 规则经过试跑验证之后，就可以全量执行了。 这一步的核心架构可以理解为一个流水线，分为 3 个角色：负责翻译的 Agent、负责找茬的 Agent、负责修复的 Agent。  每个翻译好的文件由 2 个独立的「找茬 Agent」来检查，它们的唯一任务就是挑毛病。发现问题后交给「修复 Agent」来处理。  这里的找茬 Agent 就是前面提到的「对抗性审查」。 为什么叫对抗性呢？ 因为审查者被明确要求「假设这段代码是有 Bug 的，你的任务是找出 Bug 在哪」。 这种心态跟人做代码审查是一个道理，审查者不能先入为主觉得「他写的应该没问题吧」？而是要带着怀疑的态度去看，才能发现问题。  听起来很简单，但是要注意几个实操细节。 1）工作队列要机械化。比如什么文件翻译了、什么文件没翻译，可以通过检查磁盘上有没有目标文件来判断。这样整个流程天然可恢复，中断了重启就行，不需要维护什么状态。 2）翻译 Agent 和审查 Agent 的对话必须隔离。写代码的 AI 总是倾向于认为自己的代码没问题，所以审查者必须在一个全新的独立对话里工作，只看翻译结果，不看翻译过程中的推理。 3）模型要分层使用，不需要所有步骤都用最强的。实现翻译这种高并发的工作可以用相对便宜的模型（比如 Claude Sonnet），而审查和规则制定用最强的模型（比如 Claude Fable、Claude Opus）。Mike 在全量翻译阶段就是用 12 个 Sonnet 子代理并行工作的。 翻译时如果有拿不准的地方，直接标上 `// TODO(port): <原因>`，不要在这一步纠结，后面编译器和测试会告诉你到底对不对。 ### 4 ~ 6、编译 + 运行 + 对齐行为 接下来的 3 步套路都一样：先跑一遍得到错误列表，然后让一批修复 Agent 并行处理这些错误，修完了再跑一遍，循环往复直到没有错误为止。人工介入的程度越来越低。  1）编译阶段，把编译器报出的所有错误整理成一份待修复清单，然后让 AI 按照这份清单逐个修复。 Jarred 的做法是让编排脚本对整个工作区跑一次编译器，把错误按模块分组输出到文件，然后 64 个「修复 Agent」并行处理错误列表。每个修复 Agent 有 2 个对抗性审查者盯着。修复完再编译，反复循环。 这一步他遇到了一个大问题。 原来的 Zig 代码是一整坨放在一起编译的，他想把 Rust 代码拆成 100 个独立模块来加快编译速度，但这引入了大量循环依赖问题。 于是，他跑了一个专门的工作流来分类哪些代码该挪到哪里，修复循环依赖之后暴露出约 16000 个编译错误。16000 个错误对人来说是天文数字，但对 64 个并行的 Claude 来说，也就是几个小时的事。 2）冒烟测试阶段，把所有崩溃信息整理成待修复清单。 编译通过之后，先让各个子命令跑起来，把每个崩溃的报错信息和对应的子命令保存到文件，用同样的「修复 + 审查」循环处理。 3）行为对齐阶段，把所有失败的测试整理成待修复清单。 把测试套件分片跑，每个失败的测试交给一个修复 Agent，修复之后由对抗性审查者检查。  Jarred 还有一个巧妙的设计，只允许一个专门的构建守护进程来编译整个项目。修复 Agent 只提交代码，守护进程定期把所有补丁批量编译、跑受影响的测试、把结果反馈回去。这样避免了多个 Agent 各自触发编译导致的资源冲突和重复工作。 整个过程中，Bun 的 CI 从 972 个测试文件失败到全部通过，花了大约 4 天。Linux 最先变绿，Windows 是最后一个。合并之后一共出现了 19 个回归 Bug，全部已修复。  其实 Airbnb 之前也做过类似的事情。他们用 AI 把 3500 个 React 组件测试从 Enzyme 迁移到 React Testing Library，原本估计要一年半，最终 6 周就完成了，用的也是类似的方法。 ## 我的感受 看完 Anthropic 这套六步迁移法，说几个我自己比较有感触的点。 首先是对抗性审查这件事，大家日常用 AI 编程时完全可以做。比如让一个 Agent 写完代码之后，开一个新的对话让另一个 Agent 做 code review。在 Claude Code 里面可以直接用内置的 `/code-review` 命令，或者用 Subagent 来做审查。哪怕不做代码迁移，这个习惯也值得养成。 然后是 AI 的成本问题。你敢信？Bun 的迁移花了 **16.5 万美元**的 API 费用！  这个数字乍一听很吓人，但对比 3 个高级工程师干一年的薪资加机会成本，便宜太多了。 对于个人开发者来说，一个几万行的项目迁移用 Pro 或者 Max 的订阅额度基本就够了。至于这个钱花的值不值，自己用人力成本算一笔账就好。 不过不要盲目跟风迁移。如果现有代码跑得好好的、也不难维护，就没必要折腾了。 **迁移的前提是你确实有一个持续的痛点需要解决。** 像我之前在 Claude Fable 5 限时可用的那几天里，疯狂优化自己的工作流，结果纯粹是为了优化而优化，也没什么效果，主要是之前 Opus 做的已经很好了。 还有很关键的一点，**人的判断力仍然不可替代**。 Jarred 在整个迁移过程中，每天都在监控工作流的输出、手动检查 AI 的行为、发现系统性问题后调整流程。 虽然 AI 执行力很强，但决策权还是在人这边。 AI 能节省成本，但不代表完全不需要人。 ## 最后哔哔 最后帮大家总结一下本文提到的方法，你立刻就能用起来： 1）做任何稍大的重构或迁移之前，先跟 AI 聊出一份规则文档，把「什么该怎么改」定义清楚，别上来就动手。 2）先拿 3 个文件试跑一轮，看看 AI 会犯什么错。发现的问题不要逐个修代码，而是补到规则文档里，然后重新生成。 3）写代码的 AI 和审查代码的 AI 一定要分开。可以用 Claude Code 的 `/code-review` 命令，或者开一个新对话做独立审查。 4）善用「错误即清单」的思路。编译报错、测试失败、Lint 警告，这些都是天然的任务列表，让 AI 按清单逐个修复就好。 想想看，连几十万行、上百万行代码都能用 AI 完成迁移了，我们平时几千行、几万行的项目重构，还有什么不敢动的呢？ 关键不在于 AI 有多聪明，现在模型的能力已经足够了，更多的要看你给 AI 设计的流程够不够好。 希望这篇文章能帮你建立起这个信心，学好如何驾驭 AI！  本文已收录到我免费开源的 [《AI 编程零基础入门教程》](https://ai.codefather.cn/vibe)，上千张图、几十万字，带你从 0 开始快速学会 AI 编程，做出自己的产品、跑通变现全流程，一次拿捏。 > 开源指路：https://github.com/liyupi/ai-guide  我是鱼皮，持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~ 也欢迎在评论区聊聊：你现在最常用的是什么 AI 模型？用 AI 做过的最复杂的工作是什么？
刚刚 Kimi K3 炸裂发布，号称 Claude 和 GPT 的国产平替，夯爆了！
大家好，我是程序员鱼皮。 刚刚 Kimi 发布了他们迄今为止最强的模型 K3，这是全球首个 3T 级别的开源大模型，主打编程能力。 亮点包括 2.8 万亿参数 + 百万 token 上下文 + 原生多模态，而且将于 7 月 27 日 **开源**。  本来我的内心是很平静的，因为前段时间刚刚经过了 Claude Fable 5 和 GPT-5.6 的轮番轰炸，现在对新模型已经无感了。 **但是，这次的 K3 好像没那么简单……** 今天我一打开推特，发现首页已经被 Kimi K3 刷屏了。 其中最让人惊讶的是，K3 在 Arena.ai 前端代码竞技场中 **登顶第一**，甚至超越了 Claude Fable 5 和 GPT-5.6 Sol！ 这是首次有开源模型登顶该榜单，Kimi 真的为国争光了！  再来看看其他跑分。测试终端编程和 Agent 工作流能力的 Terminal-Bench 2.1 中，K3 拿到了 88.3%，接近 GPT-5.6 Sol 的 88.8%，超越 Fable 5 的 84.6%。测试多步骤编程任务完成度的 Program Bench 中，K3 拿到了 77.8%，超越了 GPT-5.6 Sol 的 77.6% 和 Fable 5 的 76.8%！ 不过在 DeepSWE 和 FrontierSWE 这类更复杂的工程基准上还跟 Fable 5 和 Sol 有差距。  不过跑分归跑分，模型好不好用，还得拿真实项目来检验。 这篇文章我会使用 Kimi 自家的 AI 编程工具 Kimi Code，通过 **7 个不同类型的项目** 来测试 K3 模型的实际编程能力，从简单的前端动画到复杂的全栈产品，由浅入深。 激动的心，颤抖的手，点个收藏，咱们开始~ ## 安装 Kimi Code 先到 [Kimi Code 官网](https://www.kimi.com/code) 复制一行安装命令，在终端执行就好：  安装完成后，在终端输入 `kimi` 进入 Kimi Code，然后输入 `/login` 命令通过网页登录：  登录成功后，输入 `/model` 切换模型为 K3。目前 K3 的 thinking 仅支持 `max` 模式，后续会开放 `low` 和 `high`：  切换成功，可以在下方看到当前模型已经是 K3，上下文窗口显示 1M，这下可以狠狠造了~  Kimi Code 跟 Claude Code 一样，支持 Skills 技能扩展。由于我之前很多技能都装在了 AI 编程工具通用的 `~/.agents/skills/` 目录下，Kimi Code 会自动扫描加载，不用再重新安装了。 在 Kimi Code 中输入 `/skill` 可以查看已安装的技能：  接下来的测评中，我会用到 Context7 的文档搜索技能、Firecrawl 的联网搜索和网页抓取技能、browser-use 浏览器操控技能等等。 环境准备完毕，下面开始实战。 ## 项目实战测评 这次，我准备了 **7 个项目** 来测试 K3 的编程能力，从简单的前端页面逐步升级到复杂的全栈产品： 1. 交互式动画讲解网站 2. 3D 版动画知识讲解 3. 文案拆解为网页 PPT 4. 网页 PPT 生成工具（内置 AI 大模型） 5. 足球对战网页游戏（横评对比） 6. 以撒的结合肉鸽游戏 7. 全栈 AI 编程工具（复刻 Cursor） 下面挨个儿来看。 ### 1、交互式动画讲解网站 第一个项目，让 K3 生成一个用交互式动画讲解知识的网站。 以讲解 K3 模型引入的「注意力残差」机制为例，让模型自己用动画解释自己的核心技术。 提示词中，我告诉 AI 先用 Firecrawl 技能联网搜索注意力残差的技术细节，确保讲解内容准确，不会因为训练数据的时效性而瞎编：  K3 完成任务后，可以看到它确实调用了 Firecrawl 联网搜索了相关论文和解读，还通过截图验证了桌面端和移动端的渲染效果，发现问题后自主修复了布局细节。 这其实就是 K3 的多模态工程能力在发挥作用，官方博客里管这个叫「vision in the loop」，开发完截图看一眼效果对不对，不对就改，相当于 AI 自带了一双眼睛来检查自己的作品。  来看看成品效果，K3 把注意力残差的原理拆分成了几个阶段来讲解，每个阶段配有交互式动画。 第一部分用了「煮汤」的类比来解释问题。标准 Transformer 的残差连接会把每一层的输出都等权加到信息流里，层数一多，早期层的信号就被后面的信息淹没了。网站把这个过程类比成 100 位厨师接力往一个大锅里加调料，到最后第一位厨师加的高汤原味几乎尝不到了。 用户可以通过滑块控制加料速度，实时看到信息如何被稀释：  第二部分进入核心机制的交互演示。用户可以拖动滑块给不同层分配注意力权重，实时看到 softmax 归一化后的注意力分布变化：  最后还有分块注意力残差的工程落地方案可视化，用户可以调节总层数和块数，直观感受分块策略对显存的影响：  一个提示词就搞定了，前后不到 5 分钟。 我对这个效果是很满意的，点和线之间的连接很准确，动画过渡也很流畅，审美在线。 之前我都是用 Claude 做这种交互式动画网站，还经常会有元素错位的情况。K3 在前端这块确实有两把刷子，难怪能在 Arena 前端榜拿第一，之后这种动画完全可以放心交给它来做了。 ### 2、3D 版动画知识讲解 还是用跟第一个测试同样的知识点，这次换成 3D 场景来呈现。 提示词中除了让 AI 联网搜索，还要求用 Context7 查询所用 3D 库的最新文档，避免用过时的 API：  这次执行前，我先开启了 `/yolo` 模式。 开启后，AI 会自动批准安全的工具调用，不用我一个个手动点确认了，适合跑这种已知安全的开发任务：  来看看成品效果。界面没有多余的元素，重点全在 3D 动画演示上。左下角有步骤控制面板，可以逐步推进讲解：  我可以通过鼠标拖拽自由调整视角，3D 空间中的节点和连线把 Transformer 各层的信息流动展示得很清晰：  两个动画讲解网站都是单次提示词就搞定的，速度很快，效果也不错。 这类前端创意项目本来就是 AI 编程最擅长的场景，Kimi 在前端生成方面的口碑一直不错，K3 延续了这个优势。 ### 3、文案拆解为网页 PPT 我做视频教程时，偶尔会需要把文章内容做成演示画面。 但手动做 PPT 太慢了…… 这次，我干脆直接把技术文章丢给 K3，让它按照文章讲解顺序，拆解成一个可以全屏演示的网页 PPT，后续可以当做视频录制的画面素材。 提示词很简单：  很快 AI 就搞定了，成品效果很有科技感。你会发现，K3 自动识别了文章的结构层次，每页 PPT 都标记出了重点内容，代码块也用了高亮显示：  以后要给别人讲东西的时候，比起甩一篇密密麻麻的文章过去，用这种 PPT 来辅助表达清晰多了。 此外，翻页动画比较丝滑，支持键盘左右键和空格翻页。移动端的布局也很合理：  如果你希望 PPT 中有图片，跟 AI 说一下把文章中的图片添加到合适的位置就好。 ### 4、网页 PPT 生成工具（内置 AI） 前面 3 个都是开胃小菜，更看重的是 K3 的前端创意和信息拆解能力。 接下来要测测它的全栈工程能力了，让 AI 开发一个集成大模型的完整应用。 上一个案例是给定一篇文章生成 PPT，那能不能把这个能力做成一个通用工具呢？ 用户粘贴任意文案，后端调用 AI 大模型拆解内容，前端渲染成可演示的网页 PPT，还支持切换主题和导出 HTML。 这次使用 Kimi Code 内置的 `/goal` 命令来执行，完整提示词如下：  这个命令会让 AI 进入自主目标模式，跨多轮持续工作直到任务完成，不需要人工干预，很适合这种复杂的长程开发任务。 注意，提示词里我直接把 Kimi Code 的 API Key 写进去了，这样 AI 能自主调通大模型接口完成测试：  K3 完成后，从日志中可以看到它做了两组端到端的 Playwright 测试，桌面端和移动端都验证通过了。API Key 也很贴心地写入了 `.env` 并加入了 `.gitignore`，不会泄露到版本控制里：  看下成品界面。非常精简，核心就是一个粘贴文案的输入框。我把之前写过的 Loop Engineering 教程粘进去，点击生成 PPT：  AI 把文案拆成了 11 页 PPT，每页都有标题和要点：  可以随时切换内置的主题配色，全屏演示和导出 HTML 功能也都能正常运行：  美中不足的是，开发出来的应用比较简单，没有给大模型加工具调用等 Agent 能力，所以得到的 PPT 有点过于精简了。 不过至少核心业务流程是完全跑通的，从粘贴文案到生成、预览、切换主题、导出，每个环节都能正常工作。作为初版 demo 已经够用了，后面再让 AI 迭代优化就好。 ### 5、足球对战网页游戏 之前 GPT-5.6 发布的时候，我写过一篇 [《顶级国外模型横评对比》](https://mp.weixin.qq.com/s/jHHDR6J4ACj8cSY3UMltDQ) 的文章，用同样的提示词让 GPT-5.6 Sol、Claude Fable 5、Grok 4.5 三个模型同时开发了一个「2066 决战世界杯」足球游戏。 这次用完全一致的提示词让 K3 来做，来一波横向对比，看看国产模型能不能问鼎巅峰？ 同样用 `/goal` 模式执行，提示词要求用 Loop Engineering 的方式推进，先搭最小可玩版本，每完成一个功能就自测，发现问题就修，交付前做完整验收。  过了大约 17 分钟，K3 完成了目标。 技术选型上选了 Node.js + Express + SQLite 做后端，前端用 Canvas 手写了物理引擎，这个选择跟之前 GPT-5.6 Sol 的思路一致，对于这种量级的游戏来说是合理的：  来试玩一下，西班牙大战阿根廷！ 赛前设置界面做得中规中矩，能选择比赛难度、时长、队名和颜色：  进入比赛，球场布局还算标准，也能够正常切换球员和踢球。 不过人机的算法有点简单，我方只有当前控制的球员单枪匹马往前冲，其他队友全在后方观战吃瓜。而人机对手的策略就是造人墙堵着我：  守门员的防守可以说是滴水不漏，总是能卡在我射门的方向。结果我玩了好几局中等难度，都是 0 比 0 平局：  跟之前测的其他模型对比一下。 先说好的方面。K3 的操控和物理引擎没有明显 Bug，球不会瞬移也不会穿模。对比一下 Claude Fable 5，物理引擎翻车了，球经常会瞬移，根本没法正常玩耍。  对比 Grok 4.5，存在球场渲染的硬伤，而且换人逻辑不顺畅，经常切换到离球最远的队友身上：  K3 在「能不能正常玩」这一点上是稳稳过关的，体验比 Fable 5 和 Grok 4.5 都好。 不过跟 GPT-5.6 Sol 比，还是有差距的。GPT-5.6 Sol 只用了 9 分钟就完成了开发，人机虽然也不太聪明，但至少有些进球的机会。  K3 的人机对手战术智能明显不如 Sol，从游戏性角度来说离「好玩」还有距离。 整体来看，K3 在这个项目上处于中上游的水平，一个国产模型能做到这样，已经是超出我的预期了。 ### 6、以撒的结合肉鸽游戏 接下来是一个更有挑战性的游戏项目。 以撒的结合是我小孩儿时代很爱玩的一款肉鸽游戏，这次让 K3 来复刻它的核心玩法，包括随机地牢生成、射击战斗、道具系统、多种敌人和 Boss。 提示词中要求先用 Firecrawl 搜索以撒的结合的游戏机制和美术风格资料，用 Context7 查询所用游戏框架的文档：  K3 完成目标后，反馈说它用了 Firecrawl 研究了游戏机制与美术风格，用 Context7 查了所选游戏引擎的最新文档，并且通过 Playwright 在每一步完成后自动试玩、截图验证，修复了好几个问题。最终测试已实现从开局到击败三层 Boss 通关的完整流程：  来试玩一下。 虽然界面看起来简陋，但基本玩法是完全跑通的，可以发射子弹打击怪物：  玩过原版的朋友应该会注意到一个小细节，AI 生成的人物形象是有眼泪的，致敬了原版以撒的角色设计：  游戏中可以杀怪、吃道具、开宝箱，拾取道具后角色的攻击力、射速等属性会实时变化，屏幕上方还会显示当前状态：  敌人方面做了多种不同类型，有追着你跑的、有远程射击的、有对着你横冲直撞的，甚至还有会放弹幕和召唤小怪的 Boss！  总的来说，整个游戏的玩法链路已经跑通了，从开局到清房间、捡道具、打 Boss 都没问题。 **别忘了，我们现在只用了一轮提示词，没有做任何后续迭代。** 如果后面想正儿八经地做这个游戏，只需要再多提供一些美术素材，增加更多道具、怪物和关卡的设计就行了。 ### 7、全栈 AI 编程工具 最后一个项目，直接把难度拉满！ 我让 K3 基于 VS Code 的开源代码，开发一个类似 Cursor 的 Web AI 编程工具，支持 Editor Window 代码编辑器和 Agents Window 对话工作台两种模式。 提示词中要求先用 Firecrawl 搜索 Cursor 3 的产品设计，再用 Context7 查询 VS Code 扩展 API 文档：  这个任务跑了半个多小时。K3 先克隆了 VS Code 源码作为参考，通过 Firecrawl 搜索了 Cursor 官方博客和第三方指南了解产品设计，然后一步步构建了完整的 Web IDE，每完成一步都通过浏览器截图来验证效果：  来看成品。 默认打开的是 Editor Window，也就是代码编辑器界面。有文件树、多标签页和语法高亮，可以正常浏览和编辑代码：  切换到 Agents Window，这就是我们非常熟悉的 AI 对话工作台了。 我让它开发一个贪吃蛇游戏，可以看到 AI 调用了 `RUN_COMMAND` 工具，先执行 `ls -la` 来了解当前项目结构：  接下来 AI 会执行更多命令，分析当前项目的文件结构，然后在当前工作空间基础上完成开发任务：  虽然跟 Cursor 这种成熟产品比还有很大差距，但核心的 Editor + Agent 双窗口能力是跑通的。 这个项目是 7 个 Case 里最复杂的长程任务，K3 能够理解 VS Code 这么庞大的代码库，从联网搜索产品设计、查阅 API 文档到独立完成开发，半个多小时一路跑下来没有卡死或跑偏，这对模型的长上下文稳定性和自主规划能力要求很高。 ## 我的感受 7 个项目全部跑完了，聊聊我的真实感受。 首先，**K3 最让我惊喜的地方是稳定性**。7 个项目全部直接跑起来就能用，前后端启动没有报错、核心功能都是通的。 之前我测其他国产模型的时候，经常会遇到依赖装不上、服务启动报错、还得再让 AI 修一轮才能跑的情况。 K3 在这方面明显更稳了，让我想到了 Claude Opus 刚出的时候，「能用」这一关稳稳过了。 模型的执行速度也还不错，简单项目基本都在几分钟内搞定，最复杂的 AI IDE 项目用了半个多小时。 **前端能力是 K3 最能打的方向。** 从 Arena 前端竞技场的数据来看，K3 确实在前端领域超越了 Fable 5 和 Sol。我自己实测下来也有同感，动画网站的审美和准确度比我之前用 Claude 做的还好，PPT 的排版和配色也很有设计感。 **但是，整体工作完成度跟海外顶尖模型还是有差距的。** 比如让它做个游戏，虽然能玩，但跟能发布的成品有距离。想做出 Kimi 官方演示的这些游戏大作，还需要再进行多轮迭代优化。  再看看大家最关心的成本。[K3 官方博客](https://www.kimi.com/zh-cn/blog/kimi-k3) 公布的 API 定价： | 模型 | 输入（缓存命中） | 输入（缓存未命中） | 输出 | | -------------- | ---------------- | ------------------ | ----------------- | | Kimi K3 | $0.30/百万 token | $3.00/百万 token | $15.00/百万 token | | Claude Fable 5 | $2.50/百万 token | $10.00/百万 token | $50.00/百万 token | 由于 Kimi 的 Mooncake 分离式推理架构在编程场景下缓存命中率超过 90%，相当于绝大多数输入只按 $0.30 计费，这个价格比 Fable 5 便宜了一个数量级。 我自己是 Kimi Code 的满配套餐（Vivace），跑完这 7 个项目，包括半小时的 AI IDE 开发、17 分钟的足球游戏、各种前端动画和全栈应用，本周用量才花了 **2%**。以后真的是随便 Vibe Coding 了，百万上下文随便造。  对于国内开发者来说，不用折腾海外支付、不用担心封号，直接订阅就能用上百万级上下文的编程模型。而且大多数日常开发任务根本用不到 Claude Fable 5 这种模型，写个工具、做个网站、搭个原型、办公自动化，K3 的能力完全够用。 顺便提一下，K3 除了在 Kimi Code 中使用，也可以在 VS Code 插件中使用，或者通过 CC Switch 接入 Claude Code 和 Codex 等工具，可以跟着 [我之前的教程](https://mp.weixin.qq.com/s/IyB5vFWFNiDS7uT-TKdydA) 操作。  最后说点心里话。 我测过很多国产模型，大部分时候的感受是凑合能用、还差点意思。但这次测 K3，是我第一次觉得一个国产编程模型真的能让我在日常工作中用起来，而且用得挺舒服的。 稳定性足够、前端能力甚至超越了海外顶尖模型、成本只有 Claude 的几分之一，还支持百万上下文和多模态能力。 虽然在复杂任务的精细度上跟 Fable 5 和 Sol 还有差距，但 K3 的发布，给了我们信心：**国产模型在编程领域终于站起来了！** 大家也可以自己试试，觉得好用、有需求的同学最好订阅个套餐。 每月 99 元的 Moderato 套餐就能用上 K3（256K 上下文），每月 199 元的 Allegretto 能解锁 K3 的满配 1M 上下文。Kimi 的会员套餐是 Kimi Code + Agent + 网页端共享一个额度池，性价比很高。 而且算力资源是有限的，趁现在 K3 刚发布赶紧下手，后面用的人多了搞不好就得像 GLM 一样排队抢了。  我是鱼皮，持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~ 也欢迎在评论区聊聊：你现在都用什么 AI 编程模型？有试过 Kimi K3 的朋友来说说感受？
把 RAG 从“能跑”做到“能上线”：一套基于 PostgreSQL/pgvector 的生产化实践
# 把 RAG 从“能跑”做到“能上线”：一套基于 PostgreSQL/pgvector 的生产化实践 > 摘要：一个真正可用的企业知识库，难点通常不在“调用一次 Embedding，再把 Top-K 塞给大模型”，而在数据质量、权限隔离、召回策略、失败降级和版本切换。本文复盘一套 RAG v2 的完整构造过程：从多格式文档解析，到混合召回、Rerank、父文档扩展，再到反馈闭环和影子索引灰度。 > > 标签：`RAG` `pgvector` `PostgreSQL` `知识库` `大模型应用` `工程实践` > > 说明：文中的召回率和延迟数字是上线验收门槛，不是虚构的线上成绩；具体结果需要由业务评测集验证。 很多 RAG 教程的流程都很相似：读取文件、切块、生成向量、Top-K 检索，最后把内容交给大模型。 这个流程用来做 Demo 没问题，但一旦进入真实系统，问题会迅速变多：Word 里的表格和图片怎么办？扫描 PDF 怎么处理？切块命中了摘要却没命中答案怎么办？Embedding 服务挂了是不是整个问答也要挂？用户没有权限看的资料，会不会通过向量检索泄露？新索引效果不好，又该怎么无损回滚？ 最近我把一个已有的 RAG 链路重新做了一次生产化改造。我们没有为了“架构看起来更高级”而引入新的向量数据库，而是保留 PostgreSQL/pgvector，把精力放在更影响最终效果的环节：数据、检索、安全和可运营性。 这篇文章不讲 RAG 的基础概念，重点讲这套链路为什么这样设计，以及哪些细节决定了它能不能真正上线。 ## 一、先确定边界：不是所有事情都应该交给 Agent 这套系统分成四个核心部分： - Backend：身份认证、资料权限、候选召回、引用校验的唯一真源。 - Agent：文档语义增强、Query Rewrite、Embedding、Rerank 和答案生成。 - PostgreSQL/pgvector：业务数据、向量、词法索引、处理记录和反馈数据。 - MinIO：原文件、规范 Markdown 和图片资产。 Redis 只承担非权限缓存，例如查询分析、Embedding 和 Rerank 结果。用户能看到哪些资料，不进入缓存，也不交给 Agent 自己判断。 ```mermaid flowchart LR U["用户上传/提问"] --> B["Backend<br/>鉴权与权限真源"] B --> M["MinIO<br/>原文件与图片"] B --> A["Agent<br/>解析、改写、Embedding、Rerank"] A --> P["PostgreSQL + pgvector<br/>向量、全文索引、运行记录"] B --> P P --> B B --> G["生成上下文与可信引用"] G --> U ``` 这里最重要的原则是：**任何“用户可见资料范围”的判断，只能发生在 Backend 的 Repository 层。** Agent 可以重排候选，却不能扩大候选范围；前端可以展示引用，却不能自己拼接对象存储地址。这样做看似保守，但它直接避免了最危险的一类问题：模型链路绕过业务权限。 ## 二、为什么继续使用 PostgreSQL/pgvector 项目未来一年的资料量预计在一万份以内，原系统已经使用 PostgreSQL。这个规模下，单独引入 Milvus 会增加部署、备份、权限同步和数据一致性成本，却不一定带来决定性的收益。 因此我们保留了 1024 维 Embedding 和 pgvector，重点补齐三件事： 1. 把旧的向量索引升级为 HNSW。 2. 增加 PostgreSQL 全文检索和 `pg_trgm` 模糊匹配。 3. 使用版本化索引支持影子构建、灰度和回滚。 HNSW 的初始配置如下： ```sql CREATE INDEX idx_chunk_vec_hnsw ON material_chunks USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 128); ``` 查询时把 `hnsw.ef_search` 设置为 100；在 pgvector 0.8 及以上版本启用 iterative scan，减少权限过滤之后候选数量不足的问题。 这个选择背后的思路很简单：**在规模没有证明现有数据库撑不住之前，不要提前支付分布式系统的复杂度。** ## 三、文档入库不是一个函数，而是一条可恢复流水线 我们把 Parser 拆成七个可追踪阶段： ```text extract → clean → enrich → assets/OCR → chunk → embed → persist ``` 每次处理都会记录资料 ID、解析代次、索引版本、当前阶段、耗时和错误。这样即使中途失败，也能知道失败发生在哪一步，而不是只留下一个模糊的“解析失败”。 ### 1. 上传时就阻断脏输入 Backend 对文件做三层校验：扩展名、MIME 和文件签名。目前支持 TXT、Markdown、DOCX 和 PDF，单文件上限为 50 MiB。 例如，文件名是 `.pdf`，但内容没有 `%PDF-` 文件头，会被直接拒绝；DOCX 除了 ZIP 签名，还要确认包内存在 `word/document.xml` 和 `[Content_Types].xml`。 更关键的是，团队写权限必须在读取完整文件、写入 MinIO 之前完成。否则一个没有权限的用户，也能不断制造大文件上传和孤儿对象。 ### 2. 原文件和规范版同时保留 原文件写入 MinIO 的 source bucket，解析后再生成规范 Markdown 写入 derived bucket。 原文件用于审计和下载，规范 Markdown 用于检索和在线阅读。两者不能互相替代：只保留原件不利于统一处理，只保留清洗结果又会丢失可追溯性。 DOCX 解析时按文档节点顺序保留段落和表格；PDF 保留页码、文本和表格。低文本密度页面会被识别为扫描页，渲染成图片进入 OCR 流程。图片使用 SHA-256 去重，避免同一张 Logo 或截图被反复存储。 ### 3. 清洗规则必须版本化 页面 ID、时间戳、编辑历史、浏览器兼容提示、论坛回复标记和纯数字噪声，都会干扰检索。 这些规则没有写死在解析函数里，而是放在版本化配置中。每次处理除了保存清洗后的正文，还会记录每条规则删除了多少内容以及少量抽样结果。这样后续发现误删时，可以定位到具体规则和版本。 ### 4. 云调用前脱敏，图片默认 fail-closed 发送给云模型的文本会遮蔽 Bearer Token、API Key、AWS Key、密码、邮箱和手机号；本地原文不被修改，仍然由业务权限控制。 图片更麻烦，因为想识别图片中的秘密，通常需要先做 OCR，而 OCR 本身可能就是云服务。我们的默认策略是禁止把原始图片发送到远端视觉模型。只有资料已确认不敏感，或者视觉端点位于受控内网时，才显式开启原图处理。 这会牺牲一部分“开箱即用”的图片理解能力，但安全策略应该默认失败关闭，而不是默认把未知内容上传出去。 ## 四、摘要不是正文前缀，而是一种独立检索信号 每份资料会生成三类语义元数据： - 一句话摘要； - 5～8 个技术关键词； - 3～5 个“这份资料能回答的问题”。 我们没有把摘要重复拼到每一个正文块前面。这样虽然能让每块看起来都有“全文背景”，却会让摘要的泛化语义长期占据 Top-K，真正包含参数、命令或表格的正文反而被挤出去。 更合理的做法是，把不同内容作为不同的检索信号保存： ```text body 正文块 summary 全文摘要 question 候选问题 image 图片 OCR 与说明 ``` 检索阶段可以命中任意信号，但在构造最终上下文时，再回到对应父资料的正文。这样既利用了摘要和候选问题的召回能力，又不会让它们替代真正的证据。 ## 五、分块策略：短文档保持完整，长文档结构化切分 统一固定长度切块实现简单，但并不适合所有资料。 当前策略是： - 不超过 5000 字且不超过 3500 Token 的短文档，整篇入库。 - 长文档按标题、段落和表格递归组合，每块最多 3000 Token。 - 相邻块保留 300 Token 重叠。 - 每块保存标题路径、页码和 Token 数。 短文档整篇入库的价值在于保留完整语义；长文档则需要控制上下文成本，并为“同章节扩展”和“前后块扩展”留下结构信息。 分块参数也不是永恒常量。索引版本表会记录模型、维度、Parser 版本和分块配置，任何策略变化都构建新索引，而不是悄悄覆盖线上数据。 ## 六、检索链路：混合召回比单纯向量 Top-K 更稳 一次问答的检索过程如下： ### 1. 只改写真正依赖上下文的问题 Backend 先验证会话属于当前用户，再读取最近 20 条消息。 Agent 只对“它怎么配置”“前面那个参数是什么”这类指代性追问做 Query Rewrite。一个本来就完整的问题，不需要为了使用模型而强行改写。 改写后的问题只用于检索，生成端仍回答用户的原始问题。前端会展示“已理解为……”，让用户知道系统如何解释了这次追问。 ### 2. 向量和词法各取 Top-30 向量召回解决语义相近但字面不同的问题；全文检索和 Trigram 则擅长型号、命令、配置项和专有名词。 两路结果使用 RRF（Reciprocal Rank Fusion）融合： ```text RRF(d) = Σ 1 / (60 + rank_i(d)) ``` RRF 不要求向量分数和词法分数处于同一量纲，只关心文档在各自结果中的排名，非常适合融合异构检索器。两路各取 30 条，融合后保留 20 条候选。 如果 Embedding 调用失败，系统仍然继续执行词法召回。这里还有一个容易忽略的细节：中文关键词不能简单拼成一个 `plainto_tsquery`，否则多个词会变成过严的 AND 条件。实现中把改写问题和技术关键词作为独立 term，以 OR 语义参与全文、Trigram 和 `ILIKE` 匹配。 ### 3. Rerank 只处理 20 条候选 融合后的候选交给 `qwen3-rerank`，最终保留 Top-8。 Rerank 的超时预算是 1.2 秒。超时、密钥缺失或响应异常时，不让整条问答失败，而是回退到 RRF 顺序。缓存键包含模型、查询、Top-N 和候选内容哈希，既避免陈旧结果，也不缓存任何权限集合。 ### 4. 命中子块后，重新扩展父资料 真正送给生成模型的不是孤立的 Top-8 信号，而是经过父资料扩展后的正文： - 短资料召回完整正文； - 长资料取命中块、同章节块和前后相邻块； - 最多 3 份资料、8 个正文块、12k Token。 如果命中的是摘要、候选问题或图片说明，就把它当成“父资料命中”，再回到正文寻找证据。 这一步解决的是 RAG 中很常见的矛盾：检索需要小而精确的信号，生成却需要连续、完整的上下文。 ## 七、权限校验必须出现不止一次 很多系统只在第一次召回时做权限过滤，然后默认后续处理都可信。这还不够。 我们的链路会在三个位置重新验证： 1. 向量和词法候选必须来自 `VisibleMaterialsScope`。 2. 父资料扩展再次应用同一个可见性范围，不能只相信第一阶段返回的 material ID。 3. 返回引用之前，Backend 校验 material、chunk 和 asset ID，并且只允许引用实际送入生成上下文的块。 这意味着即使 Agent 返回了一个伪造或过期的 chunk ID，前端也拿不到越权引用。 同样，Redis 不缓存“这个用户能看到哪些资料”，对象存储也不返回永久公开 URL。Backend 在鉴权后生成短时效签名地址，并区分容器内部连接端点和浏览器可访问端点，避免把 `minio:9000` 这种内部主机名发给用户浏览器。 ## 八、生产链路必须允许局部失败 生产 RAG 不应该是一个“任何一步失败，整个请求报错”的串行脚本。 这套链路定义了固定降级顺序： ```text Query Rewrite 失败 → 使用原问题 Embedding 失败 → 仅词法召回 Rerank 失败 → 保留 RRF 顺序 OCR 失败 → 只展示图片 没有可靠候选 → 明确回答“当前知识库未找到依据” ``` 阶段预算大致为 Rewrite 800ms、Embedding 700ms、数据库召回 300ms、Rerank 1200ms，总检索目标 P95 不超过 2.5 秒。 Redis 的连接和读写也设置了很短的 socket timeout。缓存不可用只会降低性能，不能拖死问答请求。 这里的核心思想是：**降级不是异常处理里的临时补丁，而是 RAG 产品行为的一部分。** ## 九、评测、反馈和可观测性要在上线前接好 如果没有评测集，调整 Top-K、Rerank 数量和分块参数，本质上都只能靠感觉。 我们先要求至少 100 条人工标注问题，生产前扩展到 300 条。每条问题标注正确答案应该来自哪些资料，离线输出： - Recall@5、Recall@20； - MRR； - NDCG@5； - Rerank 后 Recall@5； - 检索 P95 延迟。 当前上线门槛设置为 Recall@20 ≥ 95%、Rerank 后 Recall@5 ≥ 90%、检索 P95 ≤ 2.5 秒。评测过程中如果 Rerank 实际发生降级，任务会直接失败，不能把 RRF 回退结果伪装成模型重排成绩。 线上则记录每次 RAG 运行的原始问题、改写问题、索引版本、阶段耗时、降级阶段和候选分数。点赞、点踩和原因单独入库，并关联到具体回答。 Prometheus 重点关注各阶段 P95/P99、空召回率、降级次数、点踩率和解析失败率。日志只记录 trace、模型和版本，不记录原始正文。 这些数据的价值甚至高于某一次模型升级，因为它们会不断产生真实 Bad Case。 ## 十、不要在原索引上原地重建 RAG 的数据结构和检索参数变化很多，如果每次升级都直接覆盖线上索引，回滚会非常痛苦。 因此我们为每个 chunk 增加 `index_version`，旧索引标记为 `legacy-v1`，新索引写入 `rag-v2`。唯一约束也包含版本： ```sql CREATE UNIQUE INDEX uq_material_chunks_version_kind_idx ON material_chunks(material_id, index_version, kind, chunk_idx); ``` 新版本先作为影子索引在后台完整构建，线上继续读取旧版本。通过同一套人工评测后，再按 material ID 的稳定哈希 cohort 执行 10% → 50% → 100% 灰度。 每个比例都可以重复执行，也可以从 50% 缩回 10%。异常时，存在 legacy 数据的资料立即切回；新上传、只有 v2 数据的资料仍然保持可用。旧索引保留 14 天，确认稳定后再清理。 这套做法的好处是，RAG 升级终于从“跑一段脚本然后祈祷”，变成了一个可观察、可回退的发布过程。 ## 十一、这次改造带来的几个结论 回头看，最值得保留的不是某一个模型或参数，而是下面这些工程判断： 第一，**数据处理决定了 RAG 效果的上限。** 如果解析顺序错了、噪声没清掉、摘要污染正文块，再好的生成模型也只能在错误证据上发挥。 第二，**检索和生成需要不同粒度的上下文。** 小块、摘要、候选问题适合召回；连续正文和父资料适合生成。不要强迫一个数据结构同时把两件事做到最好。 第三，**权限是检索条件，不是生成提示词。** “请不要泄露无权限资料”不能替代数据库中的强制过滤。 第四，**所有外部依赖都要有超时和降级。** Embedding、Rerank、OCR、Redis、MinIO 任何一个都会失败，生产链路必须提前定义失败后的产品行为。 第五，**RAG 本质上是一个持续运营的数据系统。** 没有评测集、运行明细和用户反馈，就没有可靠的迭代依据。 一个 RAG Demo，可能几百行代码就能跑起来；一个能上线的 RAG，需要处理数据版本、权限、降级、追踪、评测和回滚。 真正拉开差距的，通常不是“用了哪个框架”，而是有没有把这些看起来不够性感、却决定系统可靠性的细节做完整。
199 元找人定制 Codex 主题？未曾设想的赚钱道路。。我免费教你怎么做
大家好，我是程序员鱼皮。 今天在 AI 交流群刷到一件挺有意思的事，居然有人在咸鱼卖 Codex 的主题皮肤？ 价格甚至可以达到 199 元？？ 而且还真有不少人买？？？  这让我想起来，搜狗当年靠输入法皮肤就赚了好几个亿。没想到现在 AI 编程工具 Codex 一火，同样的生意逻辑很快就被人跑通了。 不过其实给 Codex 定制主题皮肤并不难，根本不需要花钱！ 因为已经有大神把 Codex 换肤做成了开源项目，名字叫 **Codex Dream Skin**，刚刚上线 GitHub，才短短 1 天，就已经收获了几千 Star！ > 开源指路：https://github.com/Fei-Away/Codex-Dream-Skin  这个项目的作用就是让你的 Codex 从默认的白底黑字变成任何你想要的样子，不仅仅能自定义背景图，像配色方案、装饰元素、侧栏、输入框、建议卡这些都能改。 开源作者分享了一些定制的主题效果，花样还挺多的。 首当其冲的是美女主题，这谁看了不迷糊？  然后是财神爷主题，换成这个皮肤干活都有劲儿了吧？  还有初音未来主题，你很难想象这竟然是一个 AI 工具？  还有我个人最最最喜欢的 kun 哥，和偶像一起 Vibe Coding，美滋滋~  注意，所有原生控件（侧栏、输入框、项目选择器）都还能正常点击操作，不是简单贴一张假截图上去糊弄人的。 不过由于这个项目是刚开源，对零编程基础的朋友来说还是有使用门槛的，项目的 README 介绍文档中有一堆脚本文件和技术名词，估计很多人看完还是不知道怎么动手。 所以下面我站在巨人的肩膀上，直接教大家「傻子可懂」的 Codex 定制主题方法。 核心步骤其实就 3 步，全程让 AI 帮你搞定。 ## Codex 定制主题教程 我自己试着用 Codex + GPT 5.6 做了一套火影忍者宇智波佐助的主题，整个过程分享给大家。 首先打开 Codex，直接跟 AI 说： ```markdown 使用这个开源项目，帮我更换 Codex 的主题 https://github.com/Fei-Away/Codex-Dream-Skin ``` AI 会自动把仓库克隆下来，检查你的运行环境（Node.js 版本、系统平台等），然后执行安装脚本。  安装完成后，AI 会先帮你用项目自带的默认主题跑一遍，确保环境没问题。 然后你会看到 Codex 的界面已经发生了变化，说明换肤引擎生效了。 接下来，你可以直接让 AI 帮你生成完全个性化的素材。 比如我跟 AI 说： ```markdown 帮我生成火影忍者宇智波佐助的背景图，以及脚本支持的一些额外的定制元素图片，我要进行全方位的替换。 ``` GPT 5.6 可以直接生图（就是比较慢），它帮我生成了一套完整的佐助主题素材，包括佐助与须佐能乎的宽屏背景、宇智波透明纹章、侧栏暗纹、千鸟雷电角饰，还有最重要的万花筒写轮眼。  生成完毕后 AI 会自动把素材应用到 Codex 上。 不过由于主题可定制的元素太多了，第一遍生成的效果大概率有些地方看着不太舒服。 比如我这里发现有些文字的配色在深色背景下不太好辨认，直接跟 AI 说哪里不对就行： ```markdown 好像还有些文字显示的配色是有问题的 ```  整个过程下来，从零到一套完整的自定义主题，操作上几乎没什么门槛，就是跟 AI 对话而已。可惜有点慢，大部分时间是在等 AI 生图和调色。 ## 它是怎么实现的？ 可能有同学好奇，Codex 又没有官方的主题接口，这个项目是怎么做到换肤的？ 其实原理并不复杂，Codex 桌面端本质上是一个 Electron 应用，界面是用 Web 技术渲染的。这个项目利用了 CDP（Chrome DevTools Protocol 浏览器调试协议）在本机回环地址 127.0.0.1 注入自定义的 CSS 和 JavaScript，相当于给 Codex 的界面叠了一层装饰。 整个注入过程只走你自己电脑的本机地址，不涉及任何外部网络通信，也不会修改 Codex 官方的 `.app` 安装包和代码签名，只是在界面层面加了一层视觉效果。想恢复的时候让 AI 帮忙跑一下项目自带的 Restore 脚本就行，一条命令回到原样，不影响后续正常更新。  ## 最后哔哔 除了主题换肤，Codex 的桌面宠物也支持自定义，我之前写过一篇 [完整教程](https://mp.weixin.qq.com/s/i9iLg_AG7rODCFa34vCVfA)，感兴趣的同学也可以看看。自己动手，丰衣足食~  OK 就分享到这里，本文会收录到我免费开源的 [《Vibe Coding 零基础入门教程》](https://ai.codefather.cn/vibe)，上千张图、几十万字，带你从 0 开始快速学会 AI 编程，做出自己的产品、跑通变现全流程，一次拿捏。 > 开源指路：https://github.com/liyupi/ai-guide  我是鱼皮，持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注，也欢迎在评论区晒出你的 Codex 主题，看看谁的最有个性~
Claude Code 动态工作流速通指南，多 Agent 干活效率起飞！
大家好，我是程序员鱼皮。 Anthropic 在 5 月底发布 Claude Opus 4.8 的时候，同步推出了 Claude Code 的 **动态工作流** 功能。 有人用它 11 天完成了 75 万行代码的语言迁移，有人拿它做全代码库的安全审计。还有人说这玩意儿一跑起来，烧掉的 Token 比自己一个月用的还多…… 最近有小伙伴面试的时候，就被问到「动态工作流」相关的问题了，但和很多同学一样，对这玩意的理解是模糊的。 它到底是模型自己学会的能力，还是工具层面搭出来的？跟之前的多 Agent 编排有什么区别？ 如果面试官问你「动态工作流的本质是什么」，你能答清楚吗？ 本文我就来把动态工作流讲清楚，带你搞明白动态工作流的运作原理、技术架构，以及它在 AI 应用开发中的定位。 ## 动态工作流是什么？ 动态工作流是让 AI 自己编写编排脚本，把一个大任务拆成若干子任务，分发给数十到数百个并行子 Agent 执行，最后汇总验证结果的能力。  注意，这里的关键词是 **让 AI 自己编写**。 以往我们做多 Agent 协作，不管是用 LangGraph 这种框架、还是自己写编排代码，任务怎么拆分、子 Agent 之间怎么协调、结果怎么合并，这些逻辑都是开发者手动定义的。你得提前想好有几个 Agent、每个 Agent 负责什么、上下游怎么串联。 而动态工作流不一样。你只需要告诉 AI 自己想做什么，比如「帮我把这个项目从 Python 2 迁移到 Python 3」，它会自己分析代码库的结构，决定需要几个子 Agent、每个子 Agent 负责迁移哪些文件、怎么并行执行、怎么验证迁移后的代码是否正确。 整个编排方案是 AI 根据你的具体任务实时生成的，不是预定义好的模板。 打个比方，传统的多 Agent 编排就像你当项目经理，需要自己画甘特图、分配任务、开站会跟进度。 动态工作流更像是你把需求丢给一个靠谱的技术总监，他自己去摇人、分活、盯进度、验收，最后给你交付结果。  ## Agent 系统的分类 要理解动态工作流的技术定位，得先看看 Anthropic 官方是怎么给 Agent 系统分类的。 早在 2024 年 12 月，Anthropic 就发布了一篇非常经典的工程博客，叫 Building Effective Agents。  这篇文章把所有的 Agentic 系统分成了两大类。 第一类是 Workflow 工作流，特点是 LLM 和工具的协作路径是通过预定义的代码来编排的。你写好了流程，AI 按照流程走。 第二类是 Agent 智能体，特点是 LLM 自己动态决定接下来干什么、用什么工具、怎么推进任务。控制权在模型手里。 在 Workflow 这个大类下面，Anthropic 又细分了 5 种具体的模式。 1、Prompt Chaining 提示链 任务被拆成一连串固定步骤，前一步的输出是后一步的输入。比如先生成文案、再翻译成英文，两步是固定顺序。 2、Routing 路由 根据输入的类型把请求分发到不同的处理流程。比如客服系统里，退款问题走退款流程，技术问题走技术支持流程。 3、Parallelization 并行化 同一个任务拆成多个独立子任务并行执行，最后把结果汇总。比如让多个 Agent 分别从不同角度审查一段代码。 4、Orchestrator-Workers 编排者-工人 一个中心 LLM 作为编排者，动态地把任务分解，分配给多个工人 LLM 执行，然后综合它们的结果。这里的重点是「动态」，编排者不是按预定义的规则分配任务，而是根据具体输入来判断需要几个工人、每个工人干什么。 5、Evaluator-Optimizer 评估者-优化器 一个 LLM 生成结果，另一个 LLM 负责评估和提供反馈，循环迭代直到质量达标。  你发现了吗？动态工作流本质上就是第 4 种模式 Orchestrator-Workers 的产品化实现。 注意，这不是一种新模式，而是同一个模式的不同实现方式。区别在于 **谁来搭建这个编排系统**。 传统做法是你自己用代码实现 Orchestrator-Workers。比如你要做一次全代码库的安全审计，你得用 LangGraph 或者自己写 Python 来搭这套编排逻辑： ```python # 这是开发者自己写的编排器 files = scan_all_files(project_path) risk_groups = classify_by_risk(files) agents = [] for group in risk_groups.high: agents.append(Agent(task="deep_audit", targets=group)) for group in risk_groups.low: agents.append(Agent(task="quick_scan", targets=group)) results = run_parallel(agents) report = merge_results(results) ``` 这段代码运行起来确实是「动态」的，能根据实际文件情况做分配。但问题是，这个编排器本身是你写的。怎么扫描文件、怎么分级风险、起几个 Agent、每个 Agent 用什么策略，所有这些决策规则都得你自己设计。 而 Dynamic Workflows 的特点是 Claude Code 把这件事全包了。你只需要说一句「帮我审计这个项目的安全漏洞」，Claude 自己就会生成类似上面那段编排逻辑并执行。扫描文件、评估风险、分配任务、汇总结果，全部由模型在运行时自主完成。 一句话总结，**传统方式你是 Orchestrator-Workers 模式的开发者，Dynamic Workflows 里你是这个模式的使用者。** ## 动态工作流的运作机制 动态工作流的执行过程大致分为几个阶段。 1）首先是接收任务、制定计划。 Claude 会分析你的输入，理解任务的规模和复杂度，然后动态生成一份编排方案，决定需要启动多少个子 Agent、每个子 Agent 的职责是什么。这一步就像接到一个大项目后，技术负责人先评估工作量，再写一份招人计划和分工表。 2）计划确定后就进入分发执行阶段。 子 Agent 并行启动，各自处理分配到的子任务。目前系统最多支持同时运行 16 个并发子 Agent，总计上限 1000 个！ 3）然后是交叉验证，这是动态工作流的一个亮点。 它不只是把子任务的结果简单拼起来，还会安排独立的验证 Agent 去检查其他 Agent 的输出。对于高风险任务，甚至会启动「对抗性 Agent」，专门尝试找茬、攻破前面 Agent 产出的结果。 如果验证不通过，相关的子 Agent 会被要求修正。**这个循环会持续进行，直到所有结果达到一致性标准。** 是不是很眼熟？ 没错，又是 Loop Engineering 的思想。 之前我分享过 Claude Code 官方的循环工程设计理念，核心就是让 AI 反复跑、反复改、直到完成目标为止。动态工作流把这个思路用到了极致，不仅仅是让一个 Agent 自己循环，而是一群 Agent 互相验证、互相纠错地循环。 4）最终把验证通过的结果汇总成一份完整的交付物，返回给用户。 整个过程中的进度是持续保存的，如果任务中途被打断，恢复后可以从断点继续，不需要从头开始。  此外还有一个关键设计，这个 **编排的执行发生在对话上下文之外**。 你可以这么理解，主对话窗口是你和技术总监沟通的会议室，而那些子 Agent 各自在独立的工位上干活。不管外面有多少人在并行工作，都不会挤占你会议室的空间。所以不管任务多大、涉及多少个子 Agent，都不会撑爆 Claude 的上下文窗口。这是它能处理跨越数百个文件的大规模任务的关键。  ## 动态工作流实战案例 动态工作流最震撼的案例来自 JavaScript 运行时 Bun 的开发者 Jarred Sumner。 他用动态工作流把 Bun 从 Zig 语言移植到了 Rust，整个过程 11 天完成，产出了大约 75 万行 Rust 代码，原有测试套件的通过率达到 99.8%。 这个迁移是怎么用动态工作流完成的呢？ Anthropic 官方博客透露了大致的过程。 首先，一个工作流负责遍历整个 Zig 代码库，为每一个结构体的每个字段映射出对应的 Rust 生命周期标注。这一步需要分析大量的类型关系和所有权语义。 然后，另一个工作流把数百个 .zig 文件分配给并行的 Agent，每个 Agent 把分配到的 .zig 文件翻译成行为等价的 .rs 文件。而且每个文件会安排两个审查 Agent 来检查翻译结果。 接下来是修复循环。一个工作流反复运行构建和测试，把编译错误和测试失败分发给对应的 Agent 去修复，直到整个项目能够正常编译并通过测试套件。 最后，一个通宵运行的工作流负责消除不必要的数据拷贝，并为每处优化单独创建一个 Pull Request 供人工审查。 整个过程中，人类开发者做的事情就是定义目标、确认方案、最后审查 PR。中间的具体实施全部由动态工作流自主完成。  ## 动态工作流是模型能力还是工具能力？ 这是一道很尖锐的面试题：动态工作流是模型自身具备的能力，还是平台工具提供的？ 答案是 **两者缺一不可，但职责不同**。 **模型层面提供的是「智能」。** 比如： - 任务规划能力，能把一个模糊的大目标拆解成具体的、可执行的子任务 - 上下文理解能力，能分析代码库结构、理解各文件之间的依赖关系 - 工具调用能力，能正确生成和执行编排脚本 - 还有自我纠错能力，能判断子任务的输出是否正确，以及如何修复 这就是为什么动态工作流是跟 Opus 4.8 一起发布的。Opus 4.8 在任务规划和判断力上有明显提升，它对自己代码中的缺陷的检出率是前代模型的 4 倍。这种自我检验的能力是动态工作流能做到「交叉验证」和「对抗性检查」的基础。 **平台层面提供的是「基础设施」。** 比如： - 子 Agent 的生命周期管理，负责创建、调度、销毁 - 并发控制，限制最多 16 个同时运行 - 进度持久化，中断后可以恢复 - 上下文隔离，让编排逻辑不占用主对话的上下文窗口 - 以及最终的结果聚合和交付 用一个类比来理解，模型能力就像一个优秀的技术总监的大脑，他知道怎么拆任务、怎么分配人、怎么验收。 平台能力就像公司的项目管理系统和基础设施，提供了会议室、协作工具、版本控制、持续集成等等。 光有聪明的大脑但没有执行体系不行，光有系统但没人会规划也不行。 所以如果面试官问你这个问题，最准确的回答是，动态工作流是一种 **建立在强模型能力基础上的平台产品特性**。模型提供规划和决策的智能，平台提供并行执行和生命周期管理的基础设施，两者结合才构成完整的动态工作流。  ## 和多 Agent 框架的区别 理解了上面的架构分层之后，再来看看动态工作流跟 LangGraph、CrewAI 这些多 Agent 框架的区别就很清晰了。 传统多 Agent 框架的思路是，开发者自己定义 Agent 的角色和能力，自己编写编排逻辑决定谁先执行、谁后执行、结果怎么传递，异常情况也要自己处理。框架给你提供了一堆现成的模块和连接方式，但具体怎么组装是你的事。 动态工作流的思路完全相反，开发者只需要描述最终目标，模型自动完成角色定义、任务拆解、编排逻辑生成、异常处理和结果验证。你连编排代码都不用写，因为 Claude 自己会写。 **这两种方式没有绝对的好坏之分，适用场景不同。** 如果你的任务是高度标准化的、流程固定的，比如每天定时跑一轮数据分析报告，用传统框架把流程写死会更稳定、更可控、成本更低。 如果你的任务是一次性的、规模大的、子任务不可预测的，比如代码库迁移、安全审计、大规模重构，动态工作流的优势就很明显了，因为你根本没法提前定义好所有的子任务和执行路径。 ## 怎么用起来？ 动态工作流目前在 Claude Code 的 CLI、桌面端和 VS Code 扩展中都可以使用，也可以通过 API 调用。 其他 AI 编程工具也在探索类似的多 Agent 并行模式，比如 Cursor 推出了 Cloud Agents 和后台 Agent 并行能力。不过目前「由模型自己编写编排脚本」这种玩法，Claude Code 的动态工作流是做得最完整、产品化程度最高的。 启动动态工作流的方法非常简单，有 2 种方法。 第一种是直接告诉 Claude 创建一个工作流，比如： ```markdown 创建一个工作流，帮我审计整个代码库的安全漏洞 ``` 第二种是在 Claude Code 的 effort 菜单里开启 `ultracode` 设置。这个设置会把推理力度调到最高，同时让 Claude 自动判断当前任务是否适合用工作流来处理。如果适合，它会自动切换到工作流模式。 第一次触发工作流时，Claude Code 会显示即将执行的计划并要求你确认，不会直接就跑起来。 有一点需要注意，动态工作流的 Token 消耗量远超普通的 Claude Code 会话。道理很简单，你同时雇了几十上百号人帮你干活，工资当然比只请一个人贵得多。 所以建议按需使用，先从一个小范围的任务开始试，感受一下消耗量级，再逐步扩大规模，别上来就对着整个代码库一把梭。 ## 最后哔哔 看完这篇文章，你会发现 AI 应用开发正在从「开发者编排 Agent」向「Agent 编排 Agent」演进。开发者的角色在往上移，从写编排代码的执行者，变成定义目标和审查结果的管理者。 这个趋势意味着，以后面试 AI 应用开发岗位，光会用框架写 Agent 可能不够了，面试官更想知道你对整个 Agent 架构体系的理解有多深。Anthropic 那篇 Building Effective Agents 提出的 5 种模式，基本就是这个领域的面试必考知识点，建议反复读。我的 [面试刷题神器《面试鸭》](https://www.mianshiya.com) 上也整理了不少 AI 应用开发面试题，覆盖了 LangChain、RAG、多智能体协作这些方向，尤其建议找工作的朋友刷一刷。 我是鱼皮，持续分享 AI 编程和 AI 应用开发的干货。觉得有用的话记得点赞收藏和关注~ 也欢迎在评论区聊聊，你有没有用过动态工作流？跑一次花多少钱的 Token？