这个周末应该是今年时间最闲适的一个了，娃儿们没啥课，难得周末的下午能坐在沙发上跟娃儿们聊聊天说说话。那这周我们也就轻松一下，分享一些近期我觉得让生活更美好的一些东西吧😊

好物

「五月花魔术扫把刮水地板刮浴室卫生间扫水神器40CM共3个硅胶刮条」这是京东商品名称，略微有点长，实际上就是一个硅胶刮水器，带一个长长的柄，每次冲完澡后可以用来快速把洒得到处都是的水刮到下水口处，快速让浴室回到一个地面干爽的状态，这是近期家里添置的一个让生活幸福感显著提升的小玩意儿。灵感来自好友家搬家购入了一个这个小玩意儿，见贤思齐抄了一份作业🌚。

好剧

近期看了两部不错的韩剧，其中一部让我重新开通了Netflix会员，在奈飞小铺里头拼车的账号还被封了，然后为了继续追剧，自己开了一个香港地区的会员。

《金特务：本色回归》

剧中的金特务是一名前北韩特种部队成员，代号66（其实这是他好友的代号，他自己的代号是73），与其被俘后加入南韩情报部门后的两名南韩特工一起为了寻找和营救自己失踪的女儿，一路开挂，神挡杀神佛挡杀佛地暴揍所有反派人物。中年大叔不好惹，特别讨我这种中年大叔的喜欢，本剧目前更新到第8集，最后两集要到下周末才能更新完。没想到Netflix这浓眉大眼的居然现在也开始搞周更这种事情了😮‍💨。

《铁拳教育》

这是一部偏小拼盘式的剧，我基本上是在微信视频号上看剪辑片段，凑着看完的。在Netflix上也就是补了一些此前在视频号上没凑齐的关键剧集的内容。这剧也是基本上从头爽到尾，男主长得又帅又能打，对于各种稀奇古怪的校园怪象，韩国人先用影视作品的方式给出了他们的一些看法和想象的解决方案，爽完之后，还略微让人产生一些反思。

好书

《白露春分》

知道这本书是因为其是去年宝珀理想国文学奖获奖作品，跟着读宝珀理想国文学奖获奖作品也有些年了，大概是从《南货店》《王能好》开始吧，因为梁文道了解理想国，因为理想国，了解宝珀理想国文学奖，再到这些优秀的年轻作者们的作品。

辽京这位作者此前未曾了解过，《白露春分》这本书是去年冬天周日跑步途中听宝珀理想国文学奖颁奖直播时下单购买的，今年搬家前后开始读的，上周才读完。书中从佳月和佳圆两个堂姐妹与其奶奶秀梅之间的故事展开，讲诉了一位家中女性长者的老去和家庭成员之间的参与和缺位（更多的是缺位），直到秀梅去世，长子立远永远一副万事包在我身上的姿态，但从未兑现过任何口头承诺，次子立生只顾自己跟再婚妻子小赵的小家庭，罔顾女儿佳月和母亲秀梅，小儿立民妻离子散一无所有，每日以酒度日，活像一个行尸走肉，大姑立春嫁在外地，但对家里不闻不问，一心只想培养自己的儿子考入清华北大，小姑立秋远走上海闯事业，鞭长莫及有心无力，对于秀梅的晚年也只能做到出钱出不了力。佳月这个小孙女补齐了所有的缺位，但终将无法圆满。书中对于家中不同成员的描写都非常的写实，简直就是照着村里的街坊邻居们写的。

好菜

「白菜炒肉」

这是近期我们家常吃的一道菜，老婆和孩子们都蛮爱吃的，照片是昨天晚上我炒的。👇下面是菜谱：

1. 取白菜若干，洗净，切成细块备用；

2. 剥几头蒜，切蒜片，干辣椒几颗切段备用；

3. 五花肉（肥瘦相间有肥油）切片备用，

4. 锅中放油，五花肉下锅煸炒（肉片放入锅中不要马上翻动，让它先煸个1分钟，然后再翻炒，防止粘锅），待其微卷后持续翻炒，直至煸炒金黄，看着肉片的肥油煸出来，猪皮微焦，放入蒜片和干辣椒，翻炒30秒左右，放入白菜块一起翻炒，炒至白菜微微发软，放入盐和鸡精调味，出锅前淋入少许生抽，再翻炒一会儿，出锅装盘即可。记住不要放水哦，白菜洗净后还带着一些水分，白菜在翻炒过程中还会析出一些水分，所以这道菜不需要额外加一滴水。

上桌后，猪肉干香有嚼劲，白菜吸足了猪油，混合蒜片和辣椒的香味，配着米饭吃，那是嘎嘎香😍。

原文链接：微信公众号

去年冬天里，娃儿去小区同学家玩，回来的时候跟我说同学爸爸要送他几条小鱼放在家里养着，刚好颂老师说他家里有个闲置的小米智能鱼缸，趁着一次来顺义钓鱼顺路帮我把鱼缸从家里给拉了过来。

缸到位后，娃儿还真去同学家里捞回来了三五条孔雀鱼，还带了一些无根草（我们老家这么叫的，不知道学名叫啥😂），这几条小鱼在缸里很快就适应了，之前我们试着在小的陶瓷圆缸里养过几条青鳉鱼，但是都没能存活下来。这次邻居家给的这几条小鱼倒是在新缸里头生龙活虎，没多久母鱼就下了好几次崽，缸里鱼苗和虾苗也越来越多了。无根草也是越来越茂盛了😊。

搬家的时候，把缸里的水放得差不多了，搬完后往鱼缸里续上水后，一直没能看到此前下了好几次崽的那条母鱼，全家里围着缸找了好几天一直没能找到它，大家都为它的消失感到遗憾😔。过了一个多月的一次偶然的机会，发现这条母鱼是被鱼缸里的石头卡住了，这一个多月它被卡在鱼缸里的一个角落里，也不知道它是怎么熬过来的，身子是瘦了不少，刚刚被找出来的那几天还不会游，身子在水中非常笨拙地扭动，鱼鳍和鱼尾都无法协调，就那么一卡一顿地，在水中缓慢移动，让人看着都心疼。适应了快两周后，身子慢慢也恢复了一些，但是因为繁殖周期短频次高，没过多久的某一天，当我们发现的时候，这条母鱼就只剩下一点点壳子了，它的肚子已经被缸中其他的孔雀鱼分食干净了😭。

有了这条母鱼的前车之鉴，便想着找时间得把其他还没长大的二代三代母鱼从缸里隔离出来，避免它们过早地繁殖，导致其寿命太短（孔雀鱼母鱼繁殖频率太高会导致其寿命大大缩短）。就找了此前的小瓷缸把几条小母鱼给捞了出来，单独喂养了。

学期中，大娃提出来想养乌龟，在咨询了好友后，结合娃儿自己的搜索和研究，最终决定养两只中华草龟，娃儿的说法是「中华草龟性情活泼好动，比较好养活，不容易养死🤦‍♂️」，好友的建议是「草龟喜人还聚财」，从好友分享的链接中下单购买了两只草龟，到货后一只草龟在运输途中已经没了生命迹象，娃儿们把这只带到离家不远的北小河给放归自然了。留下来一只，先由二娃认领并给它起了一个名字叫「莽哥」（这是一本他读的书《出逃的莽哥》中的主角大娃名字，在那本书中的莽哥也是一只小朋友养的乌龟）。商家随后补发了一只，隔几天也到了，这只就由大娃认领了，大娃给它取名「小龟龟」，没几天便发现它非常好狠斗勇，总是欺负先来的莽哥，哥哥便给它改名为「坏龟龟」了。

眼瞅着「莽哥」天天被「坏龟龟」追着咬，却无处可逃，便想着给它俩换个大点的龟缸，想起好友家用中转箱改造的龟缸，便请教了一番。好友发来好几个视频链接，点开逐一学习后，打开淘宝，依次购入中转箱、火山石、溪流石、隔板、水竹、春羽还有一些养水培植物用的架子和框，当然少不了高锰酸钾。

等着淘宝购物车里头的一个个链接变成家门口的快递，周末找时间，给中转箱消毒，把火山石和溪流石清洗干净消毒，绿植清洗根系和泥土再消毒，把火山石铺在中转箱底部，用隔板隔开底部的火山石，再铺上溪流石，用架子把绿植放上去，加上水，就可以把小龟缸中的莽哥和坏龟龟给搬进新家了。端午假期大娃提出要去趟五台山，在五台山的显圣广场前面的溪流中，我们捡了四块扁平的石头，放在车子的后备箱带回了北京，如今便是莽哥和坏龟龟的晒龟石了，每天它们都会爬到石头上面晒太阳，时而伸出小脑袋，时而完全缩进龟壳里，全由它们自己的心情。

这么一来，小龟缸就空出来了，刚好可以把在小圆瓷缸中隔离的孔雀鱼母鱼给搬进大不少的小龟缸了，说干就干，先把小龟缸清洗消毒，加水后便把小圆瓷缸里的小鱼们放入小龟缸里了。再下单买了些不同尺寸大小的溪流石，到货后清洗消毒入缸，再从大鱼缸里捞出一些小虾放入其中，无根草也茂盛了不少。

如此一来，家中阳台一角，一个落地中转箱是莽哥和坏龟龟的豪华大别墅🤩，旁边是从顺义搬家过来时带过来的发财树、豆瓣绿、虎皮兰和茉莉花，靠里一些便是高地摆放的大小鱼缸。这是一家人每天搬着小板凳时常驻足停留的小区域，有时偶尔喂喂食，更多的时候就是坐在板凳上盯着缸里的小鱼小虾们游来游去发呆，看看莽哥和坏龟龟是躲在了植物根系下面，还是趴在石头上打盹儿。

台风「巴威」就要登录了，连北京这些天都多了很多雨水，湿度也是高到离谱，昨天的湿度到了91%，今天略微好一点也有71%。早上跟娃儿一起出门跑步被淋在了公园驿站等了得有二十分钟才能继续冒着小雨跑完5公里回家。大娃今天主动提出要吃火锅，说是想吃酸汤火锅了（同事给了好几包贵州酸汤料，上次吃完觉得好吃，这回又给拿了好几袋），果断安排上，晚饭后到北小河溜达了一圈，这个周末就到这里了。

希望大家都能平平安安的🙏，我们下个周末见。

原文链接：微信公众号

暑假

娃儿们这周中已经完成了这个学期的学习了，期末考试结束后就开始居家了，下周再返校一次，就正式进入暑假了。

每个学期的考试，跟娃儿们都有一个小约定，只有兄弟二人任何一人达成约定，便可任选一款游戏机作为奖励，截止目前得到的消息，暂时还未解锁该福利☺️，坦白说其实我也很想玩，但是还是希望能蹭一下儿子们的福利，看看下周会不会有好消息吧🤗。

暑假开始，目前跟娃儿们约定好了暑期晨跑的计划，只要条件允许，需要持续不间断地完成每日晨跑的小任务，每天自己记录跑步公里数，达成目标后，可以选择在一定范围内的奖励（在范围内可以自行选择）。

跟哥哥此前约定好的是平时达成了小目标，每次可以选择一本自己想读的书，只要不是特别离谱的都可以，漫画小说都行。但是考虑到这些课外书实在太吸引人了，便放到假期统一购买和阅读，昨天哥哥获得的三本自由读物已经到货了，今天出门前已经读了第一本的1/4了。弟弟昨天从搬家好友家搬了好些适合他读的书回来，暑期阅读任务应该是已经完全够用了。

下周暑假就开始了，娃儿们的暑期安排也是要准备起来了。作业、户外、运动、阅读，还有他们各自的兴趣，希望娃儿们能自己合理安排好自己的时间，坚持把这些日常的小事都做到实处💪。

AI新闻

这周看到不少新闻和评论，我在朋友圈里也分享了一些自己看到且认为不错的文章。其中有一篇我很是喜欢的博主评论尸的《为什么说Anthropic是邪恶的？》，跟网上诸多谈论和分析上一周Anthropic疯狂封号的事件略有不同的是，这篇文章除了也比较好地还原了Anthropic本次是如何实现账号识别和执行封号动作之外，重点从这个识别或者说打标记的行为上展开了更深层次的讨论，蛮有意思的，如果觉得感兴趣可以找来读读看，搜索微信公众号：虹线，应该就能找到这篇文章。

对于Anthropic封号的事情我没啥好评论的，如果能把封号的钱退了，我觉得会好受一些，除此以外也没啥好说的。毕竟他们家天天贴着脸告诉全世界，他们不喜欢我们中国人，也不给我们中国人提供服务，我们用了一些手段绕开他们的限制后，被识别出来了，确实很不舒服，但是从某种角度上来说，可能也算一种咎由自取？

这周更为重要的两个类型的新闻是部分头部大厂开始限制公司内部员工使用AI Token的用量了，其中不乏阿里、腾讯这样的国内大厂，更早的还有Meta和微软这样的海外巨头。另外一个便是曾经嚷嚷着要跟OpenAI还有Anthropic这些LLM巨头们争天下的Meta要开始建数据中心对外提供算力服务了，SpaceX在把xAI合并后也要对外出租他们那些海量的GPU了。

这是什么信号呢？不是很清楚，反正上周美股的存储概念股们基本上集体大跳水就是了，现如今AI看上去炙手可热，整个产业链条上的玩家们互相投资相互锁单，我投资你100亿美金，你买我家100亿算力，我占你5%的股份，你卖我80亿的芯片，玩得实在太高级了，左脚踩右脚如此循环往复就上天了，我们时常调侃的武侠小说里的梯云纵就这么实现了。当然这未必就一定是坏事，如果AI产业在这波左右脚紧密和娴熟的配合下，真实地创造了新的生产力，那就是商学院新的经典案例，如果最终跌下来了，泡沫破灭了，也还是商学院的经典案例😂。

结合最近一段时间自己的思考，还有此前我分享的文章的内容来看，我自己总结下来基本上是这样的。

AI在其自身的行业里，目前确实还在飞速发展的阶段，一些资本和基建的疯狂加热，对于整个行业来说未必是坏事，如果想要抓住机会的话，假设自己短时间无法加入相关行业，在公开二级市场上寻找相关的投资机会也是不错的，只是现在这个时间点看上去已经在一个不低的点了，但是倘若未来AI确实能够创造更高层次的生产力，也许当前这个状态也就是个基准值吧。

目前非常积极和拥抱AI的组织和个人，遇到了一个非常现实的问题，那就是AI的加持，对于当前使用它们的组织和个人来说，究竟意味着什么？投入必定带来回报吗，ROI算得过来吗？这是一个非常有意思的问题，我可以分享一些我自己的观察和思考。

先说观察。我们团队中使用AI工具最频繁，用量最大的分两类同学，设计师和程序员，设计师在内容创作上现在基本上超过60%（很有可能更高）的工作是由AI工具来辅助完成的，程序员在代码编写上基本上超过80%都是由AI工具来完成的。当某一天OpenAI的账号风控升级和用量计算策略调整后，从我们公司内部群里大家讨论的内容便能明确地感受到，AI Token已经要接近网络带宽和电池这样的基础设施了，大家在工作中对它的依赖性在不到一年的时间里，已经完成了AI适配化改造了。

再说我身边不怎么用AI工具的家人朋友们，他们的日常生活和工作确实没有太多要用AI的场景和需求，也没有什么特别直接的外部刺激让他们主动去学习和探索AI能如何帮助他们更好的完成自己的工作，或者改善生活。豆包这样的产品在某种程度上实际上已经把AI工具普及化做得不错了。只是大家使用AI的方式更多地还是停留在跟具体的某一个产品进行互动，如果哪天淘宝、京东、美团、携程这样的App给出了更接近AI的交互方式和产品形态，估计大家才会意识到其实可能自己当下的工作和生活方式原来可以被改造，那个时候可能各行各业都会有更多的变化吧，截止到现在，很多的行业中的人们应该还是站在外面看AI（其实我们也差不多，在我们业务最核心的环节，AI介入的部分实际上并不多）。

再说感受和思考。我们时不时也能看到一些关于OPC的分享，还有一些AI对于成熟产业的改造之类的新闻，每每当我们看到这种成功案例时，总是非常欣喜并且为之心动，想着啥时候我们也能走上那条路。从这一年多重度AI学习和应用的目前进展来看，目前我们远没有达到我们想要达到的那个阶段，不过整个组织对于AI能帮我们做什么，已经有了一个相对还不错的认识，大家也都养成了很好的与AI协作的习惯，只是目前从商业的结果上来看，还没有取得肉眼可见的成果。

回到Meta、阿里等等这些头部厂商们对AI Token消耗态度的180°大转弯，起码可以比较确定的是，这些厂商基于当前的状态给出的判断就是继续加大AI Token消耗在组织内部的投入，对于他们整个组织当下的商业结果不会带来明显的正向提振，哪怕他们自己实际上是AI行业蓬勃发展的受益者，甚至他们还要不断地在市场上去说服更多的AI Token消费者相信AI必然带来巨大的变革，做AI时代的卖铲人。

那么这是为什么呢？我的观点是这样的，LLM的能力确实有比较稳定的在持续进步，AI的能力边界也确实在部分先锋人群的探索下不断地在拓宽边界和扩大其可渗透的场景，但是我们绝大部分公司和组织本身还是比较固化的，在这些相对固化的组织和结构中的我们，虽然掌握了一些跟AI相关的能力，但是我们还是在固化的组织、结构和流程中做具体的执行，这些已经固化的流程和工作，恰恰是这些组织或者说公司当前的核心业务的核心组成部分。我们做个比较简单的假设，假设一个公司的核心业务有5个环节，由5个不同部门的人协同完成，最终可以取得单位为1的收益。目前AI组织进化的结果是让这5个环节中的两个环节取得了效率和产出的提升，假设提升为50%，也就是说现在有两个环节的产出变成了1.5，如果简单来计算是不是怎么着也有1.5*1.5=2.25的效益提升，看上去能取得125%的增长，对吗？

不对，现在很多的公司或者说组织，还是工业化的产物，哪怕现在已经是互联网时代、移动互联网时代、AI时代，其实绝大部分公司的生产流程跟在流水线上生产一台冰箱和洗衣机并没有明显的差异。只是我们这些天天坐在办公室工位上打工的人们，不一定要那么按时到岗，下班的时间也没有跟流水线停止工作直接关联而已，但实际上我们的协作方式还是一个流水线的形式。而当一个公司或者组织已经习得了一套完整和成熟的体系在当前的商业社会上取得商业结果后，这套流水线就会自行跑起来，之前很多讲创业的书或者课程都会谈到的一个增长飞轮，又或者当前在AI工程化领域里头非常流行的Loop Engineering概念，跟这个其实蛮类似的。Meta也好，阿里也罢，甚至我们自己所在的公司，每天、每个月、每个季度、甚至每一年，其实都在这个Loop里头。而一个循环能否有可能取得更大的成果，未必跟这个循环中的某一个环节执行得更快了存在着完全正相关的关系。更多的时候，可能是这个Loop的新输入、迭代的新方向甚至是评估本次Loop产出结果的评价体系，才是影响最终Loop是否可以持续找到更大结果的关键。在我们上面举的那个例子中，两个环节的效率提升，大有可能会变成其他环节的压力，甚至会带来组织协同上的摩擦，最终在协同的摩擦中，这些增长在3个未明显增长的环节中出现逐级效应递减，最终给组织成功带来的影响微乎其微。

回到刚刚我们说的Meta或者阿里，这些动辄上万人的大企业中的天子骄子们，在公司巨大的飞轮上都扮演着自己所在位置的那个齿轮，当大家都开始用AI工具来武装自己的时候，也更多地还是在那个位置上扮演着那个齿轮，而齿轮转动得更快了，是否就能带动整个公司的飞轮呢？大家代码写得更快了，需求文档产出更多了，设计方案做得更漂亮了，运营活动做得更密了，数据分析做得更深入了，是否带来必然的业务增长呢？在当下全球经济低迷，全靠AI拉一波的情况下，好像各家都没有那么明显的效果。哪怕是OpenAI和Anthropic这两家公司，在自家的大模型能力日益渐长的情况下，其推出新的大模型的速度也并没有线性或者指数地增长，反倒是推出C端类型产品的速度和更新迭代特性的速度确实有着越来越快的节奏，看上去AI模型核心厂商取得的进展也是偏外围的一些改进，一旦触及到最为核心的部分，这些创造了AI繁荣的火种们，貌似也并未取得什么质的飞跃。

那么为什么我们总能听到一些AI Hero式的都市传说呢？某某OPC已经取得了年收入额千万的成绩等等。这是为啥呢？我们不能否认这个市场上肯定存在着这样的公司，先不论其他行业，单纯就AI大模型这个行业，当下的市值有多高，大家也非常清楚，在这个行业的一些成功的OPC取得这样的成绩未必是不可能的。还有一些非AI大模型行业的其他行业应用成功案例，肯定也会有，而这些成功案例的背后，更多是这些案例做到了“借助AI把不可能变为了可能”，也就是他们不是在老事情上做加法或者乘法，而是直接做了从0到1甚至到100的全新的事情。

不论是这些创造AI行业的当红炸子鸡们，还是围绕这些当红炸子鸡做服务的人（上下游产业，甚至MCN等等），他们显然都是全新的业务形态。还有那些AI Hero式的OPC们，在没有AI助力的年代，他们的想法是完全无法靠自己一个人或者少数的几个人去执行和落地推进的，现在很好地应用了AI，把他们的想法变成了现实，他们在做的也是新的事情，是一种新的业态。

而Meta、阿里等等众多大厂们，他们当下的组织和当下的核心业务已经太稳定太结实了，AI的介入并未给他们带来什么新的场景，最多也就是原有场景的提效，而提效是有天花板的。兴许他们在当前未找到新的场景时，认为自己已经快摸到原有组织和流程提效的天花板了，便做出了相应的一些决策。

一些胡思乱想，聊做记录吧。回到自己，学习AI和应用AI显然已经是行业共识无需多言。如何更好的应用和结合AI去探索更多未知的领域，找到新的业态，而非试图在已有成熟的业态中寄希望于AI提效能带来质的变化，兴许是一个需要认真思考的问题🤔。

原文链接：微信公众号

上周的文章中分享了我自己在长时间使用AI后，发现的几点变与不变的东西，然后这周就一头扎进去继续学习如何更好地应用AI来帮助自己在工作中做一些具体事情，上周了解到两个很不错的项目 Matt Pocock Skills 和 GSD-Core。

Matt Pocock Skills – https://github.com/mattpocock/skills

My agent skills that I use every day to do real engineering – not vibe coding.

Developing real applications is hard. Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve.

These skills are designed to be small, easy to adapt, and composable. They work with any model. They’re based on decades of engineering experience. Hack around with them. Make them your own. Enjoy.

https://github.com/mattpocock/skills/

以上是 Matt Pocock Skills 的官方GitHub页面的介绍，这周我在实际的开发中刻意地尝试着用了三天，在我们项目的H5工程中通过这个技能组来帮忙修改和补充部分H5页面的规则说明页。整体使用的体感上确实比较适合程序员持续推进，我这几天里用得最多的就三个技能：

ask-matt ：直接把自己的需求指令输入进去，技能最终会自己路由应该用哪个技能执行，有的时候会跟你继续沟通，有的时候就自己直接调用其他技能开干了，在项目中执行完 setup-matt-pocock-skills之后就可以万事先用ask-matt了，正所谓凡事先问matt桑。在熟悉了一阵后，其实我们也大概能知道这些技能应该怎么用了，在我自己的实际使用体验中，grill-me是我在执行修改之前用得最多的，通常我会用它来帮我对称设计稿Figma链接中的内容，以及我的需求，然后它会跟我确认好几轮需求，然后每次也会给出合理的建议（实测建议被接受率超过70%），我只需要接受建议并偶尔给出补充和确认即可。

grill-me：这是除implement之外我使用频率最高的指令了，正如上文所描述的，它能帮助我们从更多角度来确认需求的细节点，毕竟我们很多人在跟AI Agent沟通的时候，想的和说的其实是不一样的，很多时候我们认为我们表达清楚了，但实际上我们的表达中带有太多的预设，而这些预设实际上Agent是完全无从获取的，这些预设只是存在我们的脑子里，并非它的已有认知，尤其在Agent并未拥有长期记忆的情况下，那么grill-me实际上是一个帮助Agent在执行任务前强行跟我们对称认知和确认需求细节的一个重要环节，如前面所说每次通过grill-me沟通确认后的需求执行，基本上都可以做到90%以上的完成度，然后再紧跟一个implement指令把精修的需求指令给到Agent就OK了。

implement：这是一个在Matt自己日常工作中并不常使用的命令，我们可以看看这个SKILL的内容如下：

name	implement
description	Implement a piece of work based on a PRD or set of issues.
disable-model-invocation	true

Implement the work described by the user in the PRD or issues.

Use /tdd where possible, at pre-agreed seams.

Run typechecking regularly, single test files regularly, and the full test suite once at the end.

Once done, use /review to review the work.

Commit your work to the current branch.

它看上去更多是一个触发Agent去执行PRD和Issue清单中的任务，约束Agent基于tdd指令进行编码，编码完成后用review再进行代码审查，通过后提交代码的流程。但是更多的时候，在我们的项目协作和迭代推进中，并非每一个迭代和修改都是有PRD和issue的状态，很多的时候我们就是发现页面上的一个标题的样式或者按钮的位置没有按照设计稿中来实现，又或者文案的内容不符合需求，那么这个时候我们以往的做法通常就是直接一句话，例如：“帮我把规则说明页中左上角的返回键按钮样式，改成跟内容页面中右上角关闭按钮样式一致，点击后的行为都是关闭当前页面”。往常我们这样的自然语言指令给到Codex/Claude Code也是能跑的，而且我相信大部分的研发同学也是这么做的，那么这两者之间的核心差异是什么呢？直接使用自然语言跟Codex/Claude Code互动不就是最自然的方式和最正确的方式吗？说得也没错，而且最终实现的效果基本上差异不会特别大，也并不会因为我们用了一些约束AI Agent的技能就一定会有很大的改变，但是我想说的是，恰恰就是这一些约束可以让我们从反复的细节修改和错误修复中解脱出来，implement中约束的tdd迭代模式和事后review流程能在一次修改迭代中帮我们充分调用大模型的能力先完成内部的一个小闭环，整体编码实现的质量有了很大的提升，大大减少了频繁返工修改细节的时间（我们都知道现在Vibe Coding中最耗时间的就是等Agent完成它的工作，减少互动轮次就是大大节省时间提升效率）。

writing-great-skills：这个技能可以用来帮我们写SKILL，也可以用来帮我们评估目前已有的SKILL是否需要重构，并同时给出优化的方案，然后配合implement就可以帮我们把SKILL做一些优化。我自己用它对我日常用得最多的两个SKILL做了一些优化，确实效果不错。暂时还无法从SKILL实际工作的效果上去评估 ，但是可以从SKILL文件的结构和内容上明显对比出来前后的差异。

综上，Matt Pocock Skills已经替代了Superpowers技能组成为了我日常开发中使用最为频繁的技能组了，诚如 Matt 在其项目的GitHub主页上所说，这是一个do real engineering – not vibe coding的技能，非常适合有经验的程序员使用。它不像Superpowers和GSD-Core这样的开发套件般的AI Coding Framework这么重，也没有它们那么强的流程规范要求，同时也不要求完全的控制主导权，把更多的决策和主导权交给了与Agent互动的开发者，符合我们在中大型项目中的协作需求。

👇下面我们来聊聊GSD-Core，这是上周我在一篇微信公众号中了解到的一个开发套件，那篇文章的链接在这里大型项目还得是GSD，比OpenSpec和Superpowers好在哪里，文中对GSD-Core、Superpowers和OpenSpec做了比较全面的对比，有兴趣的可以找来读读看。今天我想跟大家分享的是我在使用GSD-Core做了一个全新的小系统的感受，还是先看看GSD-Core的项目官方介绍。

GSD-Core – https://github.com/open-gsd/gsd-core

What is GSD Core

GSD Core is a context-engineering and spec-driven development framework that drives AI coding agents (Claude Code, Codex, Gemini CLI, Kimi CLI, Copilot, Cursor, and more) through a disciplined phase loop. It solves context rot — the quality degradation that accumulates as an AI fills its context window — by running all heavy research, planning, and execution work in fresh-context subagents while keeping your main session lean.

---

How it works

Each milestone repeats the same five-step loop, one phase at a time:

1. Discuss — capture implementation decisions before anything is planned

2. Plan — research, decompose, and verify the plan fits a fresh context window

3. Execute — run plans in parallel waves; each executor starts with a clean 200k-token context

4. Verify — walk through what was built; diagnose and fix before declaring done

5. Ship — create the PR, archive the phase, repeat for the next one

从GSD-Core的官方介绍中我们能明显看出来，这个框架设计的目的就是为OPC而生，一个框架从需求讨论开始，拆解计划，然后开始编码实现，自己测试验收，最终发布上线，一个小的项目或者一个项目的某个需求的完整生命周期它都覆盖了。

刚好最近我有一个小的需求，那就是监控我们项目在公司数据平台上可视化平台的成本支出情况，为后续优化成本做一些基础数据的准备。因为此前我已经有了一个可以访问公司数据平台相关数据能力的技能，所以我只需要给这个技能追加一个获取可视化平台各个看板中的报表的成本数据和访问情况数据的能力后，就可以开始制作这个全新的系统了。

先说结论，从我创建项目起，到我最终完成这个项目的迭代发布到内网服务器上投入日常使用，整整花了差不多两天的时间，👇下面是我在整个项目完成部署后，我让Codex帮我分析统计了一下这个项目迭代的一些数据。

时间跨度：2026-06-22 11:21 → 2026-06-24 10:37，约 47 小时。

交付规模：6 个 phase、25 个 plan、46 个 task、44/44 requirements。

源码规模：受控源码约 13,690 LOC；产品/脚本/运维/测试相关约 16,033 LOC。

GSD 过程资产：.planning 约 125 个文件、28,928 行；核心 phase 文档约 18,633 行。

active execution 记录约 3.5-4 小时，但这不包含讨论、等待确认、真实部署、人工验收、上下文切换和重跑验证。

Token：仓库没有记录精确 token 用量，复盘里也明确是 Model mix: not measured。只能判断是百万级以上，很可能是数百万 tokens 量级。

在这个项目的迭代过程中，我跟Codex主动沟通并且输入大段文字都是发生在本机调试验收的阶段，因为在这个阶段中会发现很多实现最终不符合我的预期，后面我也会分享为何会出现这样的问题，以及后续如果继续使用GSD-Core这样的AI Coding Framework的时候，我们应该重点关注哪些内容以避免出现这样的问题。整个项目的开始，就是👇下面这一段话开始的：

我想基于$inke-data-toolkit这个工具获取数据平台可视化平台成本的能力，对于对缘这个项目的数据平台的整体可视化报表的每日成本、周成本、月成本做一个监控，为我们持续优化报表成本提供数据参考。 这个系统最终会部署在公司内网的一台服务器上，服务器的IP：192.168.xx.xx，本机可以直接使用root账号登录访问该主机。我希望这个系统是一个web看板系统，可以一目了然地查看分模块、分看板、分报表的成本支出，尤其对于那些长期没有访问记录（七天内、15天内、30天内访问人数为0、＜3人，＜xx次）的报表更是要做出警告标注，优先优化成本的就应该指向这些低访问频率高成本的报表。

尔后我跟Codex的大量交互，基本上就是，简单的回复1,1这样的选择题答复，或者类似于gsd-discuss-phase 1、gsd-plan-phase 1、gsd-ui-phase 1、gsd-execute-phase 2、gsd-ui-review 1这样的指令，基本上不需要太多的输入。但是这也正是这个流程我认为比较黑盒的部分，因为GSD-Core的设计思路是所有的需求在开始的时候已经跟你对称清楚了，计划一旦制定好就会严格按照计划中的文档约束一步步往前迭代，在最后开始测试验收的时候，我最为频繁使用的是gsd-quick和gsd-fast这两个轻量级的指令，这也是考虑到在GSD-Core主导的项目中，我们人类需要参与进去快速修复某些小问题和细节的时候设计的，你看就这个还分两个等级，一个gsd-quick（相对临时的一个符合GSD规范的完整的迭代任务，可以跟主线不直接产生关联），一个gsd-fast（不遵守GSD规范的非常小的改动，也不会创建计划文档、上下文文档、状态文档跟踪的任务模式），说明实际上需要我们接手参与的东西还是不少的。

那么回到为何使用GSD-Core这样完整的AI Coding Framework后，会出现最终交付的结果与我们的预期偏差太大，最终需要反复通过其他的方式来修改的这个问题上。从我自己的实践中，我总结出来的原因如下：

1. 提出的需求过于宽泛，没有明确提出目标是什么，需要使用什么样的技术框架来实现，对于最终产品呈现的设计和视觉效果没有任何约束，导致在后续需求讨论对称，以及AI Agent在接到任务后做的需求调研也是似是而非，逐渐偏离了我想象中的样子。最关键的是：事实上，我并没有准确地把我想象中的系统应该是什么样子，通过文字或者图片的方式给到Agent。

2. 在Agent通过调用GSD-Core中的指令跟我讨论确认需求后，我并未仔细核验它产出的文档（因为它默认产出的文档是全英文的，这里应该可以给它约束），确认它对于需求的理解和调研是否准确并且符合需求，就直接让它开始干活了，最终导致了Agent是严格按照GSD-Core约束的流程规范在迭代和验收并且分阶段推进项目，但是从一开始它就存在着明显的问题：给出需求的我，没有很好地把需求目标拆解并同步给到Agent。

回到文章之初我提到的，关于长时间使用AI后，我最近在思考的问题，就是当我和我的团队们开始长期使用AI之后的一些变与不变的东西。我还是坚信不论在互联网时代也好、移动互联网时代也好、AI时代也好，我们需要掌握的能力，有一个没有变：把问题想清楚，把问题说清楚，且让别人能听懂的能力。

当我们捡到一盏神灯，它赋予了我们无限的想象，此时我们的想象边界和我们向神灯描绘我们的想象的能力，就决定了神灯能带我们去到的地方有多远有多高了。

一些翻车事件

Agent开着SKILL就往河里去了

这周项目需要追加一个多语言的适配，要是换成往常的工作流，这可是个大工程，首先多语言适配的地方非常多，在一个设计良好的移动端App项目中，大概可能会涉及到以下板块的内容需要做适配：

1. App内的所有原生页面上的固定文案：UI界面和各种规则说明页；

2. H5页面的所有固定文案：UI界面和各种规则说明页；

3. 后端服务接口返回的内容中的所有文案：固定配置和动态文案；

App内的多语言适配，此前已经有了独立的SubAgent可以完成自动化适配，只给它一个多语言适配的指令，Agent便会把所有多语言适配的配置文件中的key逐个都翻译好，客户端研发同学不到1个小时就基本上完成了整个App内现有的多语言适配工作。

H5页面的多语言适配跟App内原生的多语言适配基本上类似，给Agent一个指令，便能自动把所有多语言适配的配置文件找出来，然后把对应的key都翻译好，基本上也就是几分钟的事儿（我们的H5页面相对较少一些）。

后端服务接口返回的大量文案都是在运营后台配置的，有一些是纯多语言文案字段，有一些是配置项中的字段需要做多语言适配，例如我们大量的礼物和虚拟资源配置，都需要给礼物和资源的名称和介绍做多语言适配，这个就需要借助运营后台的管理SKILL来帮我们批量实现了。

而恰恰就是在使用我日常天天用的运营后台管理的SKILL来帮我批量给已经配置好的礼物配置、虚拟资源配置等复杂配置项做多语言适配的时候，Agent自己出现了不在预期的行为。我们的礼物配置和虚拟资源配置除了有基础的名称还有更为复杂的礼物动画、虚拟资源动画和自定义配置项，Agent在执行翻译适配的时候，先调用SKILL读取配置项的能力，拿到了全量的配置项字段后，它并非只补充了新增多语言适配的字段的值，然后把全量字段再调用SKILL的能力回写到运营后台的配置中，它自己不知道是为了图这个接口调用时候传入的字段小的啊，还是哪根筋搭错了，它只把几个非常基础的字段往回写了，我们配置过程中最费劲最复杂的内容，也就是需要上传资源文件，拿到资源文件在CDN上的URL和其他用于描述这些资源文件的字段，例如：资源文件MD5值、动画时长、动画类型等等字段，它一概丢了，而我们运营后台的写入接口并非一个增量更新的逻辑，是每次调用传入什么字段就写入什么字段的逻辑，这就导致它少传了这些关键字段，最终运营后台里头所有的礼物配置都丢失了最关键的配置——礼物动画配置，整个测试环境的礼物都无法正常播放动画了，虚拟资源只能显示个预览图标了。

问题出现的时候，我一开始都没有怀疑到我自己头上，还跑去问我们后端同学是不是对礼物配置服务做了什么调整，后来一想不对啊，这问题就是前一天晚上我做完多语言适配才出现的。马上让Codex自己排除，虽然Codex无法找到非常确凿的证据来证明是它自己把配置给配置坏了（稍后我们会讲到这也是个坑），但是它结合整个历史会话和执行的一些临时记录和日志最终分析得出的结论就是它调用接口的时候少传了字段值导致的。

是，基本可以确定是昨天那次礼物多语言批量更新导致的。⚠️

证据链是：

• 昨天更新前，礼物列表里 animation 是有值的。例如 ID 62 更新前有：bundle=golden_overlord.pag、url=https://res.xxxx.com/...zip、md5=24eff...、size=5344570、duration=10。

• 昨天实际生成的礼物 update payload 只有：id、name、story_title、story没有带回 price/icon/gift_type/animation/extra。

• 实际写接口是临时脚本直接调用：/v1/xxx/gift/update不是通过 gift_api.py update 的安全合并路径。

• 刚刚重新查当前测试环境：28 个礼物的 animation.bundle/url/md5 都为空，size/duration 都是 0。

• 当天所有会话里只发现这一次批量 /v1/xxx/gift/update 来源，没有第二个礼物批量 update。

所以准确说：昨天礼物这一批没有成功把已有配置项的完整业务字段原样回填；由于 gift update 接口不是安全的局部 patch，漏传的 animation 被后端默认空值覆盖了。

当前看 price/icon/gift_type/extra 还在，主要丢的是 animation 里的资源字段。恢复需要从 DB 备份、后台操作日志、生产/预发同源配置、或历史发布/COS 记录里找原始 animation 信息，再用完整 payload 回写。我也建议马上把 meetar-res-admin 的 runbook/脚本加硬校验：凡是礼物更新 payload 不包含 animation、price、icon、gift_type、extra 时直接拒绝批量写。

至此，虽是破案了，还得想办法补救和预防后续继续发生这样的事故，本次只是在测试环境，如果这是对线上环境的操作呢？想想都后怕。所以我马上启动了以下步骤：

• 第一，先给当前SKILL加上约束，确保其在调用运营后台更新字段接口时，一定要传入全量字段，每次传入的全量字段必须是从查询接口中获取的初始配置的全量字段基础上做修改和补充后的新字段值，而不能只传入本次修改和更新的字段，以免出现其他字段被覆写为空值或默认值；

• 第二，给SKILL加上Harness，给所有执行运营后台接口调用加入日志，涵盖查询、新增、更新、删除所有操作，逐一按照模块+时间分类落盘记录到本地，确保后续所有的操作都有迹可循，万一出现错误可以快速从执行日志中恢复；

• 第三，想办法基于已经优化完的SKILL再次恢复和抢救所有受影响的配置项，先让Codex把昨天我们执行的指令历史会话找出来，把所有调用接口修改过的数据项列出来，然后一个个再通过指令给到Codex，让其调用修复和优化后的SKILL补全此前被覆盖为空值和默认值的配置项（这是最痛苦也最费时间的）。

在基本上做完（暂时还不能完全确定是否还有其他被影响的配置）所有的配置项恢复后，在群里跟团队小伙伴们聊到这个话题，小伙伴也分享了一个他自己的经历，那就是我们做了一个H5项目发布的SKILL，平日里用起来非常方便，但是他自己在使用的过程中遇到过他只是想要把服务发布到测试环境的时候，Agent最终把服务发布到线上环境去了的情况（当然具体细节我不是非常清楚，也许可能是我们的小伙伴只是随手写了一句“发布”，而没有使用像“发布到测试环境”这样的约束）。聊到这里，我俩纷纷表示，这两个CASE给我们提了一个醒，SKILL + Agent确实能力超强，但是需要我们给它们装上Harness，类似这样的CASE，我们实际上就不应该让这两个SKILL有直接访问线上环境配置和服务的能力，否则一旦真的Agent做了什么不可预知的事情，承担责任的还得是我们碳基人类，损失的是业务的收益和真实碳基用户的体验。

⚠️生产环境接入Agent要慎重，Harness是AI成为真正生产力不可绕过的一环，这个Harness Engineering不一定是纯AI或者纯代码实现，也有可能就是需要人的参与，不论是我们作为扶缰人也好，还是作为执鞭人也罢，马车开进沟里或者掉下悬崖，责任总归是我们的，马是万万无法担此重担啊。

Anthropic总想着教我们怎么做人

周三晚上，在学习和使用了GSD-Core帮我做完那个小的成本监控系统后，想着接下来用Claude Code来交叉验证一下，是否不同的模型跟这些AI Coding Framework之间的配合在出活效率上有所不同（因为此前用GPT-5.5 & Extra High Thinking Reasoning结合GSD-Core干活，我觉得有点磨叽）。

因为此前我自己已经被Claude Code封号封麻了，历史上我起码有5个Pro账号被封了，目前仅存的一个Pro账号存活了超过半年，只是最近半年不怎么用Claude Code，而且中间有两个月订阅了ZenMux Builder的Max计划，所以就没有续费了。这次重新找出来想要继续用一下这个账号，登录免费账号使用都是OK的，没啥问题。晚上下班前想着，那就升级一下吧，这次想着不止升级个Pro账号了，先升级到Pro账号，后面再升级到Max账号吧。之前我都是在Google Play上直接订阅Pro和Max，那会儿我没意识到实际上在Google Play和App Store中订阅Claude Max Plan是需要支付额外的Google税和Apple税的。

👇下面是 Claude Plan 在 不同渠道购买的价格，一旦你想升级到Pro网上的档位，多出来的差额都够再订一个或者两个Pro Plan了，所以我这次没有直接在Google Play上购买。

Claude Plan	Web / Claude 官网美区	Google Play 美区	App Store 美区
Pro 月付	$20.00 / 月	$20.00 / 月	$20.00 / 月
Max 5x 月付	$100.00 / 月	$125.00 / 月	$124.99 / 月
Max 20x 月付	$200.00 / 月	$250.00 / 月	$249.99 / 月

Anthropic和OpenAI家的支付风控都拉得很高，限制了中国大陆和香港地区的所有信用卡和借记卡，所以只能曲线救国了，想起手上刚好有两张虚拟币的卡可以用。前一阵子有同事需要使用OpenAI的语音转录API，还用SafePal的虚拟卡充值了一些OpenAI API的Credits，那么是不是可以试试SafePal这张卡能不能订阅Claude Plan呢？说干就干，买U充值到SafePal卡中，接受那每一步的手续费和磨损，$250美金到账SafePal中，就剩了$237，一试发现竟然还被拒付了😅。只能换卡了，换到DogPay，又是一通折腾，再次接受买U的磨损，充值到卡后，再次尝试，这回成功了😄，先下班回家。

隔天早上到了公司，试着用了一会儿Claude Code和Matt Pocock Skills结合干活，想着让它帮我改一下H5页面，没想到一个活还没干完了，已经收到了这个邮件了。

Hello,

An internal investigation of suspicious signals associated with your account indicates a violation of our Usage Policy. As a result, we have revoked your access to Claude.

To appeal our decision, please fill out this form or learn more about the appeals process here.

Regards

Anthropic’s Safeguards Team

相信不少人也收到过好多份这个邮件了，真的是一点脾气都没有。前一天，好友在朋友圈下评论「你要是 claude 做到半个月不封号，告诉我经验」，我回复道「好」，谁知好友说出这句话是有原因的，他们公司最近很多号都集体扑街了。只是收到评论的那会儿，我还是非常的naive，想着我这个账号一年多前都已经是Max了，只是这些时间停了订阅而已，而且这个账号中间也曾经停过订阅又重新恢复过订阅，看上去是一个非常安全的高价值账号才对啊。

也许就是长时间用OpenAI家的服务后，对于出口IP的主动控制习惯就没有那么好了，这次订阅Pro Plan后，没有切换到此前我固定给Claude家的出口IP，而是用了一个dmit家VPS的出口IP，但是被封的那会儿还没有意识到可能是这个问题。不信邪的我，马上就在我的Android手机上试着再次注册新账号，谁知注册账号时便被告知无法注册新账号了，此时我依然没有想到可能是IP的问题，因为Android设备的出口IP也是用的dmit家的IP。

沉下心里冷静了一会儿，换到iOS设备上，把手机出口IP换成了此前给Claude服务专用的美国家宽IP，使用Apple账号登录注册了一个Claude账号，考虑到不知道具体是IP触发了风控还是支付通道触发了风控，所以这次订阅Pro Plan时，我再次苟且选择了通过App Store的订阅来开通Claude Pro Plan，这次给美区的Apple ID绑定了DogPay的信用卡（他们家的卡能过，SafePal家的就不行，无法绑定美区Apple账号），开通后又用了一会儿，期间出现了一次网络问题，Claude一直在那儿重试连接，脑子一热切换到了dmit家的出口，Claude中的请求倒是通了，结果还没有返回来呢，我就收到又一封主题为Your account has been suspended的邮件了。坐在工位的我，彻底没脾气了，只能骂了一句国骂。

不到24个小时内，我的两个Claude Pro账号又被扬了，期间我还手欠想做一个测试，用Google Play订阅给我那个被封的账号（现在被封的账号还能正常登录，只是不能使用Claude的服务，此前被封的账号是连登录都登录不了）尝试升级到Pro Plan，最终导致搭进去了$60，目前已经退回来的有Google Play这边的订阅费，通过DogPay支付的两笔Pro的费用，截止目前在DogPay的账单页面中显示还是「进行中」，既不是「已完成」（支付成功）也不是某个看上去像是「已退款」的状态，不知道虚拟卡在处理退款上到底会是个啥情况。

为了能继续访问Claude系列模型，充分地去体验不同的模型结合不同的工具可能的差异，我还得继续想办法养一个Claude的账号，在号养成之前，只能把眼光投向了AWS家的Kiro了，通过Kiro + Kiro Gateway来把Claude系列模型的访问能力反向代理给Claude Code用（毕竟不同的Agent在工具的适配和生态上还是有很大差别的，我们可以看到很多社区里头的优秀的工具和开发套件，真的都是优先适配Claude Code，甚至他们的开发和使用就都是Claude Code完成的，我们可以通过GSD-Core和Matt Pocock Skills的GitHub贡献者名单便可窥见一斑，基本上Claude的图标都在前5名）。正所谓要听劝，能用最优秀的模型和最优秀的工具，在成本可接受的情况下，咱们就不要在这种事情上绊住自己的手脚，该用用，想辙也得用。

不过Anthropic教我做人也不是一次两次了，曾经有一位前辈给我分享了他的方案，美国家宽IP（真正在美国友人家中车库的机房里的机器）+美国银行借记卡（真正的美国人的银行卡）才有可能做到不被风控识别，但是无奈成本略高，单我个人使用且是未获得大量实际收益的学习和折腾之用，目前每个月$200+的固定支出已经是我能承受的最高支出了。

接下来更需要实现的应该是如何把这每个月的固定支出转化为实际收益，不只是局限在个人学习和折腾上，也许哪天我就能饶有自信地找到那位前辈，把他的方案要过来，从此AI就无国界了😂。

原文链接：微信公众号

这是Apple Music中播放纵贯线乐队的《亡命之徒》歌曲最后高潮部分时的歌词效果。仔细看能发现这个歌词上下是在同步高亮显示正在演唱的歌词内容，其中上面的那部分是乐队中其他成员的Rap和声，下面的主要歌词部分是主音歌手的唱词。

几年前我们还一直在笑Apple都这么多年了，咋就不能把一个千千静听十年前就已经做得非常好的动态歌词显示的功能做上呢？是西方人不唱卡拉OK，所以他们不需要看歌词吗？

近期听歌比较频繁地使用Apple Music后，发现好几年前他们推出的这个播放器对于歌词的处理还是非常用心思的，例如不是所有歌词都是居中或者简单的左对齐，而是会很有排版地根据不同歌曲的歌词内容来进行排版，当然受限于歌词库（这个显然是第三方提供的）的内容质量，我们能看到有些歌词有动态效果（逐个字跟着歌曲演唱的节奏跳动着高亮，还带有微动画效果，非常细腻，比KTV的歌词字幕效果强太多了）。连一首歌里出现多人合唱，都能正确处理和声歌词的显示和动效，并且不干扰主歌的歌词显示效果，从歌词质量到产品交互和界面设计，已经文本字体选择和排版，都是费了好些心思的。包括粤语歌曲的歌词显示也做得很到位，对于我们这种喜欢粤语歌但是完全不会说粤语的人，想要准确地发音，确实是个很好的工具。

为了印证我的猜测，我打开了网易云音乐和QQ音乐，发现这两者对于《亡命之徒》这首歌的歌词处理都只是正确地显示了主歌部分的歌词，而对于后面那段rap和声是完全没有做任何处理，哪怕只是藏在歌词内容中都没有，更不要说做出合理地显示处理了。

最近我自己也一直在想一个问题，那就是我们已经如此广泛地在工作和生活中尽量和刻意地使用了AI一段时间，那么给我们带来了什么改变呢？我想了蛮久，截止到今天，我想我能给出来的有两个非常确定的改变，和两个非常确定的不变。

确定的改变：

1. 我们很多的伙伴已经不再打开代码编辑器写代码了，哪怕改都很少，编辑器打开代码文件更多也只是用来查看和阅读代码，可能做一下review。

2. 原来很多不敢做的事儿，现在敢做和能做了，原先我们很多的H5的功能和活动只能找前端同学搞定，现在是客户端和服务端的同学都能自己写了。

确定的不变：

1. 截止目前为止，绝大部分伙伴的产出应该并没有得到非常明显的提升（如果从商业结果上来看的话）。

2. 拥有了原本我们并不具备的创造系统的能力，并不一定能带来实际的产出（做出用户需要，解决用户问题的产品）。

周三中午，当我看到Apple Music中《亡命之徒》的歌词字幕效果时，更是让我深有触动，现如今凡事问AI已经成为了我们很多人的日常，那么这种细微的洞察，由谁来完成呢？AI吗？Apple这些年的这种细腻确实已经渗入了他们整个公司产品的毛细血管了，也许在他们看来，做成这样是理所应当的，而在我看来，这却是在这个时代里越来越宝贵的能力和品质。

虽然我非常厌恶苹果家在中国大陆的Siri的智障体验，近些年macOS和iOS的软件Bug也是层出不穷，但是放在整个行业里，他们家的产品依然还是有着非常深厚的人文关怀在里头。为此他们的产品溢价高，也是这么的理所应当。

愿我们在AI盛行的明天，都能保持自己的感知力、敏锐度和洞察力，不沦为AI的工具人😁

最后，今天夏至，也是父亲节。祝各位父亲们节日快乐，也请各位记得跟自己的父亲说一声节日快乐。我也要在做好父亲的路上继续努力了💪

原文链接：微信公众号