2025-05-05 02:38:31
这是猫鱼周刊的第 64 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在
博客：阿猫的博客-猫鱼周刊
RSS：猫鱼周刊
邮件订阅：猫鱼周刊
微信公众号：猫兄的和谐号列车
互联网上有一群人，可以通过随意拍的一张街景照片，通过里面的蛛丝马迹（例如指示牌、建筑风格等等）迅速找到图片拍摄的地点，甚至能达到公里级别的误差。下面是一个例子：
有人尝试用 o3 去完成这个挑战，结果是 o3 的总分超过了人类的顶尖玩家，在精度上甚至达到了恐怖的水平。
我的第一想法是情报部门有福了，以往需要大量人力物力去从某张模糊的图片中找到蛛丝马迹定位图片的位置，现在只需要一个大模型就能做到同样的事。不过对于这类严肃的应用，找到更多证据佐证，形成闭环的证据链，才是实际工作上的难点。
另一个想法是，在看 Linus Tech Tips 的视频时，会发现他们会对拍到员工住宅外街景的地方都细心地打上模糊，当时他就解释过，是为了防止别有用心的人猜出他们的地址。如今不需要 Geoguessr 这类人就能做到这样的事，所以我们在互联网上最好还是不要发布可能会泄漏自己家庭地址等的照片为妙。
很有意思的语言学文章！在学英语的时候就隐约觉得这个星期几应该是跟行星有点关系，但是在读书阶段去考究这些问题，只会被批「你研究这些没用，背就是了」。说实话，如果当时学星期几的时候，英语老师讲一下这个引子，将会是很有趣的一节课。
在 LLM 之前，其实有过计算语言学和自然语言处理两个学科，是计算机科学和语言的交叉学科，他俩的重叠有点大，所以经常也被混为一谈。之前普遍认为做 NLP 的人，如果也懂点语言，对研究是会有帮助的，所以当时我也学过一些小语种，我本身对语言也有一定的兴趣。
原本我以为作者应该是文科生，博客内容都是思考、评论向的，还有语言学这类文章，没想到居然也是软件工程的（via /about），有点出乎意料。
作者利用识别手写的医学笔记的模型，改造成识别手写国际象棋棋谱，并加上了自动纠正等功能。可以在 chess-notation.com免费使用。
本来这个应该放去工具/网站栏目，但是这个作者的故事真的值得说道，所以放在这里讲。这个项目的动机是：
我的儿子经常参加象棋比赛，积攒了很多纸质棋谱，有的已经模糊或不完整。手动录入非常耗时。这个工具让我们几秒钟内就能保存和分享整盘对局。
作者主要是做 AI 在医学上的应用的，他之前做的免费的乳腺癌检测也很出名（链接），还有史上首个免费使用的器官和肿瘤分割云服务（链接）。之前作者的作品都很硬核，专业性质很强，这个项目倒是展示了「杀鸡用牛刀」的威力，解决一些 everyday life 的问题。
有收到读者的邮件，以为我的名字叫「猫鱼」，才想起来从来没有提到过周刊名字的来源，趁机会稍微写写。
首先呢我叫「阿猫」，我比较喜欢猫，也有点希望自己是一只猫，这个就不细说。鱼呢，则是因为当时我很向往「摸鱼」这种 vibe，有点像「看闲书」的感觉，我读书的时候就很喜欢上课看闲书，我觉得这是扩充思维多样性的关键。如果你是比较久的读者，会发现周刊的内容一开始很多技术方向的，后来逐渐有更多花样的内容。另外呢，「猫鱼」也是猫的零食吧，我是轻轻松松地写，满足我的表达欲，也希望读者轻轻松松地读，不需要刻意追求获得什么。
说到「刻意追求」，其实刚开始写的时候，我会很关注阅读量，时不时刷新一下，看到有增长会比较激动，后来渐渐对这个数字没什么感觉了，可能一两周才去看一次。在写的过程中，有一些平台收录了我的 RSS 链接，也给我带来了不少增长，微信公众号的也偶尔会踩中推荐逻辑带来一些流量，另外最近也发现 Folo 上居然也有不少阅读，读者互动也多了一些。由于周刊在我自己的博客、Quaily还有微信公众号三个地方发布，还有一些通过 RSS 阅读的朋友，所以其实我从来没有核算过每期实际的阅读量，感觉上来说，一般每期在一千内，好一点的可以去到两三千的样子，如果你在这里面，而且读完有种读书的时候上课藏在抽屉里看了一期杂志的那种感觉，那恭喜你体验到了「猫鱼周刊」的核心价值。
本来在我自己的备忘录里有个 CancerLog 的主题，专门记录治疗过程的，这个后续也许会整理一下再发出来，煮饭这个事情算是近期比较核心的内容，所以先抽出来讲。
由于要做碘 131，一段时间内要无碘饮食，所以这段时间都是自己煮饭。一般流程就是决定吃什么、买菜、备菜烹饪、洗碗这么几个步骤。整套流程下来，其实很费时间精力，但是熟练之后进步会很大，一开始我要花两个小时左右备菜和炒菜，到现在一个小时就能开饭。这里我分享几个 tips：
煮饭比外卖是要多花点时间精力，但是真的很省钱，而且健康很多。由于需要无碘，我基本吃的都是新鲜的肉和蔬菜，不能吃精加工食物。新鲜肉的口感和味道都是外卖吃的冷冻肉、合成肉、预制菜无法比拟的。
有时候想吃什么很麻烦，翻小红书又很费时间，我会用这段时间我在开发的「食咩」App 来帮忙，它有一个转盘可以帮我决定吃什么，也可以直接输入菜名来获得对应的食谱。如果你对它感兴趣，可以在 App Store 搜索「食咩」或者通过下面的链接下载使用，目前完全免费。
一个可以查看模型 metadata 和估计内存使用量的工具。之前一直没搞懂模型的内存需求怎么计算，一般都是靠参数量粗估，实际能不能跑还是靠试，这个工具提供了比较精准的估计。
一直在用的输入法自动切换/指示工具，最近开源了，支持一下。
感觉很多这类工具，只有几个出路：
很欣喜看到它走向开源，如果作者实在没有精力维护或者产品确实没法变成付费，开源的方式能让它走得更远。
本周刊已在 GitHub 开源，欢迎 star。同时，如果你有好的内容，也欢迎投稿。如果你觉得周刊的内容不错，可以分享给你的朋友，让更多人了解到好的内容，对我也是一种认可和鼓励。（或许你也可以请我喝杯咖啡）
另外，我建了一个交流群，欢迎入群讨论或反馈，可以通过文章头部的联系邮箱私信我获得入群方式。
2025-04-28 23:57:52
| ID | 胶卷 | 拍摄时间 | 张数 | 相机 | 扫描仪 |
|---|---|---|---|---|---|
| 01 | Kodak UltraMax 400 | 2025.02 - 2025.04 | 36 | Canon Sure Shot 105 zoom | Fuji Frontier SP3000 |
这是我拍摄的第一卷胶卷，后续拍摄的胶卷应该也会通过类似的方式分享出来。
自从在家里翻出来一台傻瓜机，并且从里面冲洗出了十几年前的影像，便对这种记录方式产生了一点兴趣。这一卷胶卷是在长沙旅游时，在星辰胶片馆买的。我带着这个傻瓜机去了长沙、广州、香港，也是拍出了不少照片。
比起下一卷用「半自动」相机拍的，这台「全自动」傻瓜机的拍摄体验更加简单，不需要考虑任何参数，不需要考虑对焦和曝光，只需要对准想要记录的东西按下快门。但这相应也是一个缺点，你没法控制曝光，甚至没办法得知当前拍摄参数（连快门速度都听不出来），更有一种开盲盒的感觉。
这卷其实还蛮出片，除了下面展示的，还有不少合照，很有氛围感。
2025-04-20 18:48:11
这是猫鱼周刊的第 63 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在
博客：阿猫的博客-猫鱼周刊
RSS：猫鱼周刊
邮件订阅：猫鱼周刊
微信公众号：猫兄的和谐号列车
这几周因为养病，刷的视频比较多，所以周刊的内容里混进比较多的视频，整体的结构也杂乱了一些。不确定这样会不会更有趣一些，所以希望得到大家的反馈。
评测媒体的客观性一直是一个很大的问题，从当年罗永浩跟王自如的「辩论」就可见一番。我觉得评测媒体和厂商的关系跟女装一样，只有零次和无数次。除非你是永远都不收钱的评测媒体（例如 testv），否则你必然跟厂商有或多或少的利益相关，这点影视飓风的视频里也有提及，有些格局小的厂商甚至因此把他们拉黑。
提起罗永浩和王自如，顺便说到一个观点：评测媒体想要作弊，那可再容易不过了。当年王自如的伎俩就非常拙劣，以至于罗永浩给他锤爆了。放到现在，在评测数据上想要做点手脚，可能复杂一点（因为大家都在标榜客观公正），但绝对是能做到的。
影视飓风的视频倒是提出了一个比较新颖的观点：「全是能肉眼判断相机动态范围少了一档的人，这个对厂商来说是多么恐怖的一群用户」。简单来说，厂商如果在专业领域花钱做投放，ROI 并不如在大众渠道做投放来得好。这个话其实也有点片面，影视飓风这个频道目前基本上是 KOL 的水平了，除了专业领域内，应该也有很多圈外的人在看，真要论带货，影视飓风还是很强力的，之前胶片那期视频，很多机器应声起价。
回到观众的视角，你看评测视频是为了什么？我的话一般是了解产品最终的体验，又或者是好奇一些新发布的产品。对电子消费产品，参数和体验是离不开的两个重点。参数你可以从厂商公布的数据获取，但是很多时候参数不代表最终的体验，作为普通消费者也不可能逐样买回来尝试，因此评测视频填补了这个空白。但还有一个坑是，你的使用场景跟评测的人可能不一样，因此最终的体验也不是准确的。
讲了这么多，核心就是一个：评测视频必然不是完全客观的。你要对视频本身有这么个预期，也不应该对媒体有太多的怨言。另外作为观众，你也可以用手/脚投票，不喜欢的媒体你不看就是了，不好看的视频不要点赞就是了。
用联网版的 DeepSeek-R1 做旅游攻略，他们的 prompt 写得挺不错。
DeepSeek 给他们规划的行程总体其实没什么大问题，但是瑕疵比较多，主要集中于时间安排上。也许是联网搜索到的信息里面没有提及景点的营业时间，有不少行程其实是扑了空，或者需要等景点开门的。另一个问题是有些景点太过于小众，没什么东西看，也没什么玩，都没有其他的游客，感觉有点白跑，但是 up 主的性格不错，居然没有丧气。
用 AI 做旅游攻略这个思路非常妙，我用 Cherry Studio + 高德地图的 MCP 复刻了一下，选择了我比较熟悉的广州。
总体来说，路线比较合理，去的都是一些很地道老广的地方。引入高德的 MCP 之后，它实际上搜索了酒店周边的几样广州特色美食来进行推荐（虽然里面只有银记肠粉这家我觉得真的是必吃的）。
之前提到，MCP 可能是通用人工智能的最后一公里，如果携程和大众点评也推出 MCP，甚至可以实现 AI 帮忙订房、订位，这样 AI 规划行程的体验就完美了。
说起 AI 旅游攻略，有个叫「圆周旅记」的 App，里面就有类似的功能。我自己使用过几次，不过里面的 AI 功能调教暂时比较鸡肋，容易把行程打乱，新鲜感有但是实用性一般，感兴趣可以体验一下。
一个 Text-to-SQL 生成器，利用了 RAG 来提升生成 SQL 的准确性。
我觉得核心是会通过收集人类纠正过的 SQL 来提升后续生成的效果。有人吐槽训练的过程非常要命，往里加权限隔离也非常麻烦。
美能达单反系统的数据库，截图是美能达镜头目录。最近正好入手了美能达 X-700，作为我入门胶卷摄影的第一台专业相机。
各地的医保政策查询，要是再早几周看到，我可能会仔细研究一下。
不过就我的情况来说，我是深圳职工一档医保，在广州三甲医院门诊/住院，省内可以不备案，唯一麻烦的点在于不能在小程序上直接支付，要去收费窗说明是深圳的医保才可以，报销比例也是正常的。
本周刊已在 GitHub 开源，欢迎 star。同时，如果你有好的内容，也欢迎投稿。如果你觉得周刊的内容不错，可以分享给你的朋友，让更多人了解到好的内容，对我也是一种认可和鼓励。（或许你也可以请我喝杯咖啡）
另外，我建了一个交流群，欢迎入群讨论或反馈，可以通过文章头部的联系邮箱私信我获得入群方式。
2025-04-13 19:58:04
这是猫鱼周刊的第 62 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在
博客：阿猫的博客-猫鱼周刊
RSS：猫鱼周刊
邮件订阅：猫鱼周刊
微信公众号：猫兄的和谐号列车
周刊又咕了几期，简而言之，这几周我经历了一次全麻手术、住院、数不清的检查和吊针等等，好消息是暂时是在慢慢恢复了，预后应该也不错。具体我在想法栏目细写。
「打工人小组件」的开发团队的复盘，算是非常实诚的分享。恰好这个 App 初期我真的下载体验过，属于是有趣，但实际作用甚微，因此我也没有给它付费。分享里提到两个独立开发着常犯的认知错误：
其实这恰好是独立开发中最难的两步：推广和变现，App 的创意、技术实现相比起来其实都简单很多。
Shopfiy 的 CEO 最近在内部备忘录中的分享，说的是 Shopify 鼓励全员使用 AI，将会把 AI 的使用加入绩效评估等。有一点很有争议，也很有意思：
一个团队在要求更多的人力和资源时，需要说明为什么不能通过 AI 完成。
有评论说，那以后雇 AI 得了，不用再雇真人了。实际上，一些简单的事，AI 干得更好，比一般人都干得好，而且成本更加低，从公司的角度推广 AI 使用是必然的。我觉得对个人的启发就是，AI 目前不能做的事才是人的核心竞争力，因此没必要顾忌 AI 的发展和推广，与其内耗不如多发展自己。
我在 25 岁生日的当天确诊了癌症。（真像小说的名字啊。）
目前来说大致的过程是这样的，去年（2024 年 3 月）体检的时候，发现甲状腺有一个结节，比较大。当时在深圳的三甲医院重新做了 B 超，分类为 TI-RADS 3 级，当时医生说不太可能是恶性，建议半年到一年复查。今年 3 月体检的时候，发现它有变大，于是挂了广州医院的号再看。重新 B 超后，分类为 TI-RADS 4b 级，这时候恶性可能就比较大了，于是第二天就做了穿刺。当周穿刺结果就出了，确认是甲状腺乳头状癌。
接下来就进入治疗阶段了。初步跟医生谈了一下之后确定住院的时间，办入院，定在清明之前手术。住院的第一天主要是做一些检查，所以那天我还溜出去吃饭、逛街、回家，第二天也没什么事做，主要是下午跟医生对一下手术方案，签一大堆东西，略过不表。第三天是手术日，由于我年纪最小，所以排在最后面手术，一直等到了下午两三点才把我送上楼。手术过程没我什么事，麻醉一推就睡着，再醒来已经是晚上，推回病房之后就是接下来几天漫长的恢复和煎熬。
我在第七天出院了，同一天做手术的病友因为手术规模小一点，都比我早出院了，所以拔完引流管之后跟医生护士简单道了下别就换衣服出院了。由于有医保，住院大概 2/3 的费用都由医保出了，只有部分自费的要自己付。
这个病的预后也算挺好，除了终身需要服药，恢复之后就可以正常生活。很难说这不是老天给我的警醒和第二次机会，之前的几年我经常熬夜，饮食也不注意，之后作息和饮食我都会多加留意。
收集了国内常见服务的 MCP Server，目前已知高德地图、腾讯地图、百度地图以及 Apifox 和彩云天气都已经官方支持了 MCP。
Netflix 开源的一种视频质量评估方法，反映观众对视频流质量的感知。可以直观对比不同编解码器对画质的影响。
值得一提的是，我是通过 Mac 视频画面碎裂？一年测试 一份大活 这个视频了解到这个算法的，视频做得很用心，感兴趣可以看一下。
ClawCloud 出的类似 Zeabur 等的容器服务，每月有 5 刀免费额度，算是羊毛。不过这个界面和设计思路，简直跟 sealos 神似。
本周刊已在 GitHub 开源，欢迎 star。同时，如果你有好的内容，也欢迎投稿。如果你觉得周刊的内容不错，可以分享给你的朋友，让更多人了解到好的内容，对我也是一种认可和鼓励。（或许你也可以请我喝杯咖啡）
另外，我建了一个交流群，欢迎入群讨论或反馈，可以通过文章头部的联系邮箱私信我获得入群方式。
2025-03-24 23:48:28
这是猫鱼周刊的第 61 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在
博客：阿猫的博客-猫鱼周刊
RSS：猫鱼周刊
邮件订阅：猫鱼周刊
微信公众号：猫兄的和谐号列车
午后的香港街头，阳光打在彩色的维他饮料框上，呈现出很好看的色彩。香港算是非常适合扫街的地方，有老旧又很干净整洁的街巷，也有很摩登繁华的闹市，市区里藏了很多街角公园，也有海边和港口，很多风景都很新鲜。
因为上周末去香港玩了，所以周刊暂停了一期。然后这周因为更多的一些事情，延迟到周一发布。
上期我们介绍过 MCP(Model Context Protocol)，本来想写一篇文章稍微介绍一下相关的资源，结果找到了这篇已经非常完善的文章，就不狗尾续貂了。
比较有意思的是，MCP 相比 Function Calling，它是一个更加底层的协议，定义的是 Client 和 MCP Server 的交互，而且不需要模型本身支持，可以通过 Client 端去实现。
MCP 很像是 LLM 的触手，LLM 通过 MCP 去感知世界（获取上下文）和与世界交互（操作工具）。可以预见的是，MCP 会是 LLM 实用化很重要的一步，或者说它可能是通用人工智能的最后一公里。
Linux 基金会一次访谈（应该是 2024 年初）中 Linus 和主持人谈到关于 AI 编程的话题，两个人其实体现出两种截然不同的态度。
Linus 对 AI 编程是比较乐观的：
而另一个 host 则比较悲观，或者说持有一点质疑：
关于这方面其实我还有一些想法，会在下面「想法」栏目展开一下。
也是一篇谈 AI 编程的文章，认为 AI 会让开发者变笨。
文章提到 Copilot Lag 的现象，就是习惯于用代码自动补全之后，在写代码的时候会习惯等待 AI 的补全，甚至被 AI 牵着鼻子走；久而久之，会削弱开发者独立思考和解决问题的能力，甚至遗忘基础语法和编程概念，对技术一知半解。
我算是非常早开始使用 AI 辅助编程的人，从 Copilot 的内测开始，我就一直使用 Copilot 和类似的工具完成我的编程工作。去年的时候，我写过一篇使用 Copilot 辅助我完成一个前端网站的文章，还得到了阮一峰老师的推荐；另外，我也在公司内部做过一些 AI 进行 Code Review 的实践，最近结合 Cursor 也折腾了一个新的 AI CR 方式。我是 AI 编程的坚定支持者。
Linus 的访谈中，看到两种平时也很常见的态度：乐观和质疑，不得不说，我在工作中听到质疑的声音会比较多。这类声音的核心主要是担心 AI 写 bug，又或者担心 AI 对其职业产生威胁等等。
我觉得 Linus 的回答也很耐人寻味：
Well, I see the bugs that happen without them every day. So that may be why I’m not so worried.
在没有 AI 的时候我也每天能见到 bug，所以这可能是为什么我并不太担心（AI 会写 bug）。
他说得算比较委婉，以我的经历，很多人写得甚至不如 AI，尤其是一些常见的算法或者逻辑。因此，担忧 AI 写 bug，只是自己抗拒接受新事物的一种借口。
我觉得随着 AI 编程逐渐铺开，以后编程会逐渐变成一个新的范式：将来的程序员会通过描述需求和技术设计，而最终的大部分代码都由 AI 生成，程序员的工作会从编写代码逐渐变成设计方案。这其实也是我近几个月使用 Cursor 的感受，自从有了 Agent 模式，在实现业务需求的时候会更多去想设计、逻辑方面的东西，而不是代码具体怎么写。
想法的另一部分是对「AI 会让开发者变笨」的回应。确实在有 Copilot 之后我很少写 go 的循环之类的语法，以至于如果突然要我手写一下，我可能会想不起来怎么写，这就是他说到的 「Copilot Lag」。我平常会把代码分成两种，一种是千篇一律反反复复的代码，例如 CRUD，这类我很倾向于交托给 AI，写得快，写得干净整洁，往往不需要太多改动就可以跑起来；另一种是新奇的代码，一般是我没接触过的新领域，就算让 AI 写了我也没法 review 是否符合我的想法，这些代码我会自己去写。简而言之，我会让 AI 帮我干繁杂的活，剩下有趣的部分自己操刀。
另外你会发现，一些很新奇的东西，AI 很可能不会写，就例如下面的 mcp server，至少在目前版本的 Claude 3.7 它还没有相关的知识，这就是我们人的学习能力大放异彩的时候。所以说：
AI 决定生成代码的下限，人决定上限。
我写的一个 Memos 的 mcp server，算是一个 mcp 的模板。
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("memos")
@mcp.tool()
def search_memos(query: str) -> List[Dict[str, Any]]:
pass
@mcp.tool()
def create_memo(content: str, tags: List[str] = []) -> Dict[str, Any]:
pass
def main():
mcp.run(transport="stdio")
if __name__ == "__main__":
main()
这里省略了具体的 API 交互逻辑，但实现一个 mcp server 最简单的方式就是这样。
Go 的 MCP 框架。目前来说，比较主流的是 Python 和 JS，他们都有官方的 SDK 支持。但其实 Go 是更加适合的，它跨平台分发原生二进制的特性我觉得非常适合这种场景。
社区复刻的 Manus，从演示视频来看完成度颇高。甚至我觉得比原版的 Manus 更加 promising，毕竟 「Talk is cheap, show me the code.」，而这个开源项目是真的有全部可运行的代码的。
Dify 工组流集合分享，收集了挺多示例，有些还是比较复杂的。
说起 Dify，这个项目我很早就在用，它比较大的特点就是可视化工作流编排，后续很多厂商的交互都或多或少致敬了它；而它在编排、低代码上确实挺好用，适合快速做一些 demo，比用 gradio 之类的工具写起来还要快一些。比较坑的是，在实际用起来发现，私有化部署一个 Dify 的吞吐量非常低，能抗的 QPS 很低，定制一些业务逻辑也很麻烦，因此正式使用还是得自己写代码。
一个有点简单的开源提示词优化器。最早接触到这个是在 Claude 的控制台，后来字节火山引擎也更新类似的功能，叫提示词优解，当时找了好久都没有找到开源的这种。
不过我觉得比较完善的形态，应该是像 Langfuse 那种工具里面，包含有收集 trace、prompt 版本管理的功能，再加一个 prompt 自动调整，可以设定一些 good case 和 bad case（类似火山引擎的交互）。期待开源工具的完善！
@giroudg投稿。免费字帖下载，用古诗词作为练字内容，帮助孩子又练字又温习诗词，双倍收获。
如果能切换几种字体，以及字帖方向（左右/上下）那就更好了。
MCP Server 收集网站。对应还有个开源项目 GitHub - punkpeye/awesome-mcp-servers: A collection of MCP servers.。
本周刊已在 GitHub 开源，欢迎 star。同时，如果你有好的内容，也欢迎投稿。如果你觉得周刊的内容不错，可以分享给你的朋友，让更多人了解到好的内容，对我也是一种认可和鼓励。（或许你也可以请我喝杯咖啡）
另外，我建了一个交流群，欢迎入群讨论或反馈，可以通过文章头部的联系邮箱私信我获得入群方式。
2025-03-10 23:21:45
周刊介绍了未来已来？-- 基于 cursor 的 ai code review这篇文章，马上仿照文章的方式给项目配了一个 mdc（之前的 .cursorrule），效果还不错，快马加鞭分享一下。
首先是按 Cmd + Shift + P 呼出命令面板，输入 rule ，选择 File: New Cursor Rule，然后输入这次新加规则的名称 code-review，按回车。这时候就会生成一个新的文件。
生成之后应该是下面的样子，有两个空需要填。
复制粘贴一下内容，注意 description 和 globs 要填在空上。globs 根据项目需要改成对应的正则。
---
description: Review code changes.
globs: *.go
---
You are a experience software developer, and your job is to review my code changes and try to find bugs or other possible improvements.
You can run a git command to get the changes in the stage.
You should start by summarizing the changes and give some preliminary overviews. Then followed by the issues or improvements you find in the code changes. If everything is fine, you can leave the second part empty.
Note that:
- Do NOT comment on product or business decisions. Focus ONLY on technical issues.
- Do NOT comment on documentation and testing.
- Do NOT comment on issues that should be caught by static linters and compiler as they are already handled in CI.
Your output should look like:
<example>
# Overview
The changes include:
- xxx
- xxx
# Issues
## xxxx
```
// some code snippets
```
some comments
</example>
可以根据实际情况调整一下里面的内容，不过这个效果已经不错了。
按 Cmd + L 呼出侧面板，切换到 COMPOSER 页签，模型选择 claude-3.7-sonnet-thinking（或者其他思考模型，例如 deepseek-r1），框中输入 Review changes. 然后回车即可。
中间可能会要求运行几个 git 命令，这是因为我希望它只去考虑最近变更的代码，需要手动点击运行。稍等片刻即可看到结果，看起来还不错，都是些很有意义的建议。
模型方面，可以试试不同的模型看看哪些更好，我只测试了 claude-3.7-sonnet 和 claude-3.7-sonnet-thinking ，其中 thinking 模型输出了更加有用的建议，而不是 nit（可改可不改的问题）。需要中文结果的话，可以把 Prompt 翻译成中文或者要求它用中文输出。
目前的流程还需要手动允许 git 命令执行，基于 mcp 的方法可以让代码逻辑直接生成 diff，省去中间的操作。后续有时间再详细探索。
