暑假

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

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

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

跟哥哥此前约定好的是平时达成了小目标，每次可以选择一本自己想读的书，只要不是特别离谱的都可以，漫画小说都行。但是考虑到这些课外书实在太吸引人了，便放到假期统一购买和阅读，昨天哥哥获得的三本自由读物已经到货了，今天出门前已经读了第一本的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的工具人😁

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

原文链接：微信公众号

前一阵子，中午在工位上吃饭，手机上刷着短视频，刷到了扯馆儿乌梢蛇的视频号，视频中说他出演的一部文艺片上映了，还是文艺片有点长，可以去看看。

说实在的好久没有看电影了，打开爱奇艺发现会员都过期了，转头到中国移动那儿领了一个会员，搜索了片名《金鸡一朵云》，点开看了一会儿。片子的进度确实很慢，反正我也不着急马上看完，分着好几天，断断续续直到今天才看完，片子没有特别想要表达的内容和观点，核心就是一个平铺直叙，纯小镇日常视角，没有任何跌宕，剧中为数不多的不那么日常的，就是那位在道观中寄宿的来自成都的某IT公司的高管在道观后山自杀了。剧中还有人去世，一是片头男主角秦朗的父亲秦方民去世后，秦朗带着父亲的骨灰回到老家金鸡镇安葬（其父生前嘱咐过百年后要葬到镇上水库中央的一座庙的后方），再就是片尾因病化疗无效去世的黄淑芬（秦方民的中学同学，秦朗母亲在电话中再三嘱咐要他本次回乡要去寻的人，但未告知其为何要寻她），本片英文名《A separation》，不知是否有些关联。

本片角色名字多为单名，男一号：秦朗，女一号：沈念，男二号：曹凯，女二号：孙丽（曹凯妻子）。

秦朗：父亲去世，回乡办丧，妻子祝静刚与其离婚，在重庆做导演工作（自称只是一种职业，并未以大导演自居）。

沈念：金鸡一朵云的老板，片名便是沈念自己在金鸡镇上开的理发店的名字。刚从职校毕业的她，因父母车祸离世，早早回乡照顾弟弟，尔后便留在了镇上，未在盐亭继续工作。

曹凯：秦朗的同学兼好友兄弟，在金鸡镇上做两份工，昝殿村的鱼塘管理和盐亭乘风驾校教练员。早年间去广东闯荡，虽未闯出什么名堂，但是成功地把广东媳妇孙丽带回了镇上，育有一子曹小宝。长期被男性性功能障碍困扰。

孙丽：与秦朗早年间在广东打工时认识，后随其回老家金鸡镇结婚生子。平日不上班，主要在家照顾孩子，爱打王者荣耀。

全片从秦朗回乡开始，到秦朗安葬好父亲的骨灰进入尾声，黄淑芬的悬念有了着落后，秦朗便再次回到了重庆，把这段时间里他与沈念之间的故事便遗落在了那个转弯处，全片以秦朗春节前回到金鸡镇上坟，发现金鸡一朵云已经在重新装修，沈念已经搬走，去了成都结束。片尾，秦朗在车站窗口买票时，先是询问了去重庆的车票，转而又问了一嘴去成都的车票，得到窗口工作人员的回答「去成都的票多得很」后，全片就结束了。

片中没有什么起起伏伏的剧情设计，也没有什么悬疑刺激的桥段，有的只是平平淡淡的生活，所有的对白都那么日常。偶有一些跳出日常的内容，便是沈念对于诗歌的偏好，片中的秦朗在沈念父母出车祸的隧道处解析了诗人席慕蓉对于泡桐树的感怀，沈念在道观亭子里朗读了席慕蓉的《一棵开花的树》节选片段：

陽光下慎重地開滿了花

朵朵都是我前世的盼望

當你走近 請你細聽

那顫抖的葉是我等待的熱情

而當你終於無視走過

片中的风水白事先生赵老师，盐亭县城的中药房大夫，与曹教练搞外遇的驾校女学员房薇薇，秦朗在金鸡镇住的旅馆的老板娘，都那么面目模糊又恰如其分的日常。

沈念店里风扇的咔咔声（全片处在一种南方小镇里闷闷的湿热中，全片所有人脸上总有一层薄薄的汗），频繁出现在秦朗旅馆房间的蚂蚱（尔后在沈念的店里，秦朗烧给父亲的纸房子上均有再次出现），沈念的乐扣盒子里切成块儿的西瓜，秦朗身上常开的黑色衬衣肩上的双肩包（明明热得冒细汗，但是还是穿两件背背包），这些细碎而反复出现的意象构成了一个超出纯粹日常的场，让观者能感受到这是我们作为他者在窥探的被设计出来的意象。

秦朗遇见沈念，正处于丧父和妻散的双重emo中，遇到了一个形似前妻祝静的沈念，心中起了涟漪，也曾试着努力鼓起勇气去靠近对方，但是在沈念试图再次确认他在车外对其喊话时的内容时，却谎称自己只是喊沈念下车透透气。全片最大的遗憾便由此产生。

沈念遇着秦朗，此前职校毕业的她早早回乡承担起养家的责任，曾经因为爱读诗被短暂出现在小镇上的一位林老师伤了心。这回遇到从重庆回来的导演秦朗，本以为这次遇着了对的人，未曾想最后哪怕是自己努力想要表达自己的心意，而对方竟未再做出任何回应，还是在完成其父亲安葬事宜后便回了重庆。至此，金鸡一朵云，便要去寻她自己的诗了。

曹凯，在小镇上打两份工养活一家老小，却与自己单位女学员不清不楚，身有恶疾心里不痛快。妻子孙丽怒其不争，夫妻生活不和谐，情感淡漠，最终因孙丽出轨爆发冲突。片尾曹凯回到了广东番禺继续打拼，妻子孙丽带着曹小宝住进了他们在盐亭买的学区房里。

再次回到金鸡镇的秦朗，站在水库边父亲的坟头，看着天空中飞舞的雪花，跟电话那一头的曹凯说着「曹凯，金鸡镇居然下雪了。」发给沈念的消息，显示「你已不是对方好友，发送朋友验证……」。

金鸡一朵云，要飘到哪儿去呢？

原文链接：微信公众号

北京今天又下雨了，上午趁着雨停，沿着北小河跑到公司，原本准备拿上电脑就下楼骑车回家，坐在工位上打开电脑忙活了一会儿，收拾好电脑背上书包再下楼时，外面雨已经大了。幸好书包中带有雨伞，那就不骑车了，打车回家。老婆和娃儿们上午出门去了一趟附近的社区医院，做了一下转学后的疫苗接种情况登记，回来的时候顺道在盒马买了午饭回来，等我到家时便直接吃上了。

午饭后休息一会儿，外头雨势未见小，打着伞陪大娃去学校上管乐团的课，娃儿进了校门，我领了一个谱台回来。二娃跟他妈妈正在屋里午休呢，我烧了点水，泡上一杯茶，坐在餐桌前，拿起手机，准备把这周写字的作业完成了。

上周日下午，大娃跟着他妈妈还有小姨去地坛公园了，我们俩从少年宫回来就去超市买菜了，大娃说他晚上要回家吃饭。跟二娃一起在附近的果蔬好超市买了五花肉，油豆泡，排骨，小白菜，奥尔良鸡翅，葡萄，在收银台排队等结账的时候，二娃盯着墙上大大的充值返现的广告看了一会儿，然后有了下面的对话。

B：老爸，这个充2000送1%，充3000送2%，充10000送4%，充20000送5%，是什么意思啊？

D：就是我们今天往这个会员账号里头充值2000块钱，实际到账是2000加上他们超市再送的1%，也就是2000块钱可以当做2020来花，意思是我们只需要花2000块钱可以买到2020块钱的东西。

B：那充20000块钱送得不是更多吗？

D：是的，充20000送5%，送多少钱啊？

B：我算一下啊。

这会儿我们结完账了，已经来到了超市外头的马路上，我右手提着买好的菜，左手牵着二娃的手，往家走的同时，继续着刚刚的对话。

B：老爸，500，对吗？

D：再算算呢，充20000送5%。

B：20000是100个多少啊，老爸？

D：100个100是多少？

B：10000。

D：那20000是100个多少？

B：200？

D：嗯，对啊。那20000的5%是多少？100个200中的5个200，是多少？

B：老爸，我算算啊，1000是吗？

D：对的。

B：1000块这么多？那我们为什么不充啊？

D：宝贝，你是不是觉得这个充20000送1000很划算？

B：对啊，不划算吗？老爸。

D：如果我们一年在这家店里稳定消费超过20000的话，那么看上去它的回报率还是不错的，现在外面的投资回报率能到5%的项目已经很少了，你们的压岁钱在银行买的定期理财的年化利率才不到3%，也就2.5%到3%之间波动。这么一比，这个确实看上去会更划算。

B：那老爸我们为什么不充啊？

D：我们来打个比方好不好。假设现在妈妈在家里持续批发冰棍，然后再卖给你和哥哥吃（他妈妈进入夏天后，为了让孩子们吃到质量更好的冰棍，已经改成先从盒马或者其他电商平台买冰棍放在冰箱，然后再按原价卖给他俩了，然后从零花钱里扣买冰棍的钱），然后妈妈推出一个充值送冰棍礼金的活动，比方说你有400块钱的零花钱，妈妈推出了一个充400送20的活动，你充了400块给妈妈，就可以吃总共420块钱的冰棍，你会选择充吗？

B：那我总共就只有400多的零花钱，全充给妈妈了，我就没钱了啊。

D：嗯，那你选择充还是不充呢？

B：那…，我不知道。

D：你这么想，如果你充了400块钱在妈妈那儿，妈妈那儿记账显示你有420块钱可以用来吃冰棍。如果妈妈一直批发你爱吃的冰棍的话，你会一直吃得蛮开心，对吧？

B：对啊，那不是挺好的。

D：但是，万一，我是说万一，妈妈后面批发的冰棍不是你爱吃的，都是我跟妈妈爱吃的冰棍，你选择吃还是不吃呢？

B：那我让妈妈买别的，我再吃。

D：如果有一天，你路过蜜雪冰城，你想喝奶茶或者吃冰淇淋的话，但是你的钱已经都充到了妈妈的冰棍账户里头了，你拿不出钱来买冰淇淋或者奶茶了，你就只能找哥哥借钱或者找爸爸妈妈要钱了。

这会儿我们已经进小区来到楼下了，进了电梯对话继续。

D：那宝贝，你还要充值吗？

B：老爸，那我还是留着吧，这样我想吃什么就吃什么。

D：嗯，行，你做出来一个自己的选择。其实我们看到超市的充值返现的活动也是一样的，我们需要放弃一定的流动性才能获得一定的收益，而每个人在看待流动性的时候的体感和需求是不一样的。超市通过提前锁定我们的消费，拿到了我们充值的钱，可以用于他们的日常经营甚至扩大规模，投资产业链上下游之类的，20000块钱对于他们来说不是只卖出了20000块钱的货物赚我们这20000块钱菜的利润，而是拿着这20000块钱去做了更多的事情，如果大家一年都花不完这20000块钱的话，那么他们的收益只会更高，而我们自己享受到的收益就更低了。

B：噢，老爸，我听不懂😵‍💫。

D：好了，咱们到家了，爸爸给你做饭去了，你来淘米煮饭吧，今天咱们放点五色糙米一起煮吧。

B：行。

这周的写字作业就到这里吧，二娃跟着他妈妈出发去顺义上课了，我也要准备去学校接大娃下课了。这周前几天娃儿们的小姨来北京给他们过六一儿童节，每天放学给他们做饭吃，这周我们动手做饭次数少多了。不过还是把拍了的照片记录一下吧😊。

原文链接：微信公众号