IT之家 5 月 17 日消息，YouTube 博主 Game Maker's Toolkit 本周（5 月 11 日）发布视频，深入分析 R 星当年如何将《GTA3》装进仅有 32MB 内存的 PS2 游戏机。 作为参考，《GTA3》发售于 2001 年，是《GTA》系列 3D 世界观的开山之作，凭借革命性的自由玩法， 为现代开放世界游戏树立标杆 。 而 PS2 游戏机的硬件规格并不算豪华，它虽然拥有容量至少 4.7GB 的 DVD 光驱，但光驱读取速度仅有 5MB/s，完全无法即时加载资源。内存的状况也不算宽裕， 尽管总线带宽最高可达 3.2GB/s ， 但容量只有可怜的 32MB 。 IT之家援引博主观点，R 星在这极其有限的硬件中成功塞入了宽约 4 公里的开放世界，其中的自由市拥有波特兰、斯唐顿岛、海岸之谷三个可探索区域，还带有大量 NPC 行人。 博主首先表示，传统游戏一般会进入某个区域时，将所有模型、纹理、动画、音效等传输到内存，当玩家走到下一个区域时触发加载动画，并将先前的区域从内存擦除并加载新区域。 但这种策略并不适用于《GTA3》，因为该游戏并没有独立的区域，也没有墙壁或门分隔各个区块，玩家可以自由地任意探索自由市，整个波特兰的文件就达到 40-50MB，完全超出 32MB。 随后博主开始研究《GTA3》的源代码，改写部分程序并重新编译出了一个新的游戏执行文件，成功揭示了 R 星的优化秘诀。 具体来说，R 星并没有把整个自由市都塞进内存，而是将自由市化作一个棋盘切成数千个网格，玩家走到哪里，游戏就只显示视觉范围内的模型、人物、资产。系统会悄悄在你前方构建世界，同时悄悄删除身后走过的世界。 不过，如果《GTA3》只有这种流式传输机制远远不够，因为这种系统只能保证内存不会溢出，而画面远处的建筑物则会不断闪来闪去。 为此，R 星建立了一套扇区检查系统，游戏会自动检查玩家当前区块视野内的模型： 离玩家近的区域会被详细渲染 ， 而远处的地方只会渲染高楼、桥梁、起重机等看起来明显的物体 。而且游戏内部含有多个精度的模型，玩家靠近时可以使用高精度版本，远离时则使用低精度版本，节省内存开销。 总的来说，R 星当年用了多种手段，让《GTA3》能够呈现在 PS2。
折腾半天发现一个， 神级小白技巧 ：Windows 当发现 Claude code 不好用 或者发现调用工具失败 先回退到指定版本 npm install -g @anthropic-ai /[email protected] 2 个帖子 - 2 位参与者 阅读完整话题
大道至简的胜利, 一个神级skill推荐, 忘掉brainstorming吧 - 开发调优 - LINUX DO 之前在这个帖子末尾留了个坑，现在来填上 先叠甲, 这篇文章我主要指的是 superpowers 和 GSD 这两个框架, 我知道站里的佬友们也做了一些很优秀的框架, 我对此非常的respect. 本文的核心不是为了批判, 主要是为了分享一些观点, 希望和大家一起探讨。 1. 现有框架的一个巨大的bug 这些十几万star的编程框架竟然没有一个有做过benchmark上的实际对比, 注意这可是以提升编程效率和质量为目标的框架, 却没有任何证据能证明这些框架比简单的提示词有更好的效果, 我之前在网上翻了半天, 真的没找到有人做个严谨的实验对比, 来证明框架的效果. 有佬们如果有看过具体的评测文章, 可以贴出来我们一起学习一下 正面例子如 PI 这个coding agent 在 他的博客 末尾所述, 一个最简单的coding agent也能在benchmark上取得不错的效果. 想要证明一个东西的效果, 我感觉我们还是需要一些严谨的对照实验吧。很多框架带来的只是虚假的热闹, 具体落到实际项目上能否产生正向的影响，还需要更多的证据。 2. 为什么这些框架大多是过度设计的 核心出发点： AI的上下文非常宝贵 , 所以： 不应该让太多和代码无关的东西占据上下文. 之前深度使用了GSD, 刚上手时觉得很厉害, 流程一大堆，文档一大堆，调研一大堆, 随便问个小问题, context都被用掉了一半. 一个下午用掉了平常10天的token量, 最后产出东西会发现不一定能完全符合你的需求, 因为他在对需求这最重要的一步做的不够深入. 另外这些框架的skill很多一看就是AI生成的，长篇大论，一大堆废话，看着就头大，这些skill有没有经过人工的review都很难说，仔细看都有很多可以精简的地方。 比方说如果你想让模型按照TDD来开发, 你并不需要搞个上千字的skill给模型讲一遍什么是TDD, 什么红绿灯, 你只需要告诉模型"按照TDD来开发", 这就足够了, TDD是一个很经典的概念, 在他的知识库里，他是知道什么是TDD的, 不需要再浪费prompt去解释它。 之前在 grill-me 的帖子中，我就实际验证了, 简单的prompt反而能实现更好的效果。 3. 模型需要复杂的约束吗? 好的模型不需要过多的约束, 这就像如果你是老板，你底下有一个非常非常牛逼的程序员, 那你就不需要给他太多的指导, 不然就变成内行指导外行了 差的模型也不需要过多的约束, 因为模型本来就笨, 注意力本来就不集中, 再给他脑子里塞一大堆上下文, 只会让他的小脑瓜转不过来，丢三落四, 对于差的模型，更需要精简而清晰的指令. 就像你让一个小孩帮你做事, 肯定是一次只给他一个清晰的指令, 让他做一件小事, 效果是最好的 4. 复杂的框架并不一定适合你 AI发展到现在, 一切软件都趋向于定制化, 学习框架的成本可能高过让AI给你定制一套简单解决方案的成本. 看看GSD，没个半天时间都看不明白怎么用 5. 复杂的框架，长期来看大概率会成为绊脚石 随着模型更新，模型的长程执行能力也在持续增强，不用任何框架，一句话让模型跑几个小时早已不稀奇（可以参考GLM5.1上线时的报告） 从长期发展来看，随着AI能力变强，我们给他约束应该是越来越少的，这是AI软件发展的大势所趋，越来越多的能力会内化进模型，上层只需要薄薄的封装即可。回到编程上，也许我们提供最少的原则性的约束(如TDD)和适应项目的规范，可能就足够了 总结 “simple but work” 是一个非常值得追求的事情。 8 个帖子 - 8 位参与者 阅读完整话题
在 Claude Code 里可以用 Codex 啦，我刚才用了下，生成的文档很耐打！有用过的朋友吗，欢迎评论区留言交流👏
在 Claude Code 里可以用 Codex 啦，我刚才用了下，生成的文档很耐打！有用过的朋友吗，欢迎评论区留言交流👏
最近发现一个神奇skill. mattpocock 的 /grill-me github.com/mattpocock/skills grill-me/SKILL.md main --- name: grill-me description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me". --- Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask the questions one at a time. If a question can be answered by exploring the codebase, explore the codebase instead. 内容非常精简，只有几句话，但效果出奇的好. 它的作用就是在你提出需求的时候，不断的质问你，和你理清需求. AI编程的第一原则就是 清晰准确的描述需求 . CC自带的 plan 中的提问功能, Superpowers里面的 brainstorming , 其实都是在做这个事情, 和你理清楚需求再做计划. 需求越清晰, 执行效果才会越好. `griil-me` 也是在做这个事情, 通过对你刨根问底的深入追问来理清需求. 对需求和做计划时慢一点，实现时才能快一点, AI编程时请记住 慢就是快! 实测 /grill-me > /brainstorming > /plan , grill-me的提问是最多的, 远多于另外两个工具. 实测对比 为了对比grill-me和brainstorming, 我对这两个skill问了一个非常复杂的项目级重构, 大概需要处理几十个文件的移动和重构, 非常多需要确认的细节(某个文件要挪到哪里/跨模块如何处理依赖/如何处理循环依赖/测试要不要跟着重构/某些函数要合并/哪些模块要解耦) grill-me问得非常详细, 问了我差不多20个问题, 花了半个小时, 后者只问了七八个问题. 最终用grill-me的计划, 执行起来一遍过, 100+测试全通过 brainstorming跑起来比较唬人，又是调研又是subagent，但最终产出的计划文档并没有grill-me好 具体表现在前者会生成更加详细的操作步骤, 并且看起来就非常的清晰, 而后者生成的计划文档步骤更少, 更糙一点 grill-me 这个skill的prompt非常的精简，所以能把尽可能多上下文空间留给后面的逻辑, 这一点本身就是巨大的优势 当然也有缺点, 逻辑比较简单，只做了提问，甚至问完都不会自己把文档写下来. 所以请大家问完问题之后，务必让他 写入到计划文档md . 然后清空上下文之后再执行这个计划, 这样才能保持最干净的上下文 建议grill-me生成之后再让他review一遍, 或者让brainstorming Review一遍 交叉验证, 我交叉验证的时候发现grill-me的计划中漏处理一个文件, 不过问题不大 关于AI编程框架, 晚点我会再开新贴分享一个最近思考的暴论 5 个帖子 - 4 位参与者 阅读完整话题
一直很喜欢mcp的交互方式，简明高效了。求佬们一人给小弟推荐一些神级高频使用的mcp吧。 13 个帖子 - 12 位参与者 阅读完整话题