上周的文章中分享了我自己在长时间使用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上购买。

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：行。

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

原文链接：微信公众号

最近听了一期《声东击西》的节目——#388 从铁路大亨到科技巨头：镀金时代的喧嚣与困境，正在重演吗？标题比较模糊，看上去不知道具体要讲啥内容，不过因为是《声东击西》的老听众了，把整期节目都听完了。实际上节目内容已经忘得差不多了，但是其中有一个片段中提到了，在美国出现跨州铁路之后，铁路网络给整个社会结构带来多大一些影响，这让我记忆深刻，当时就跑神了。

节目组主持人徐涛跟嘉宾马啸聊到美国各州当年在跨州火车出现之前，是没有统一的列车时刻表这样的东西的，是因为有了跨州列车之后，才慢慢出现了统一列车时刻表这样的东西，来供各州的乘客了解列车发车时间的。

我们生活在中国大陆，知道中国大陆只有一个时区，我们平时都称之为北京时间。我们去到新疆旅游，知道新疆夏天晚上10点天才黑，在巴音布鲁克草原上，9点多太阳才落山，但是我们只使用一个时区。去年夏天第一次出国，去到雅加达，飞机落地后，发现手表和手机的时间是同步的，没有时间差，刚开始也没感觉到什么异常。后面再跟家里发微信的时候才想起来，北京比雅加达早一个小时。

节目中徐涛和马啸聊到铁路交通网络的发展和完善，让美国的联邦政府的行政管辖权逐渐扩大，从铁路沿线土地的使用权和管辖权开始。包括前面提到的统一时刻表等等，从政治和文化上，对于我们现在常说的更晚近出现的「想象共同体」的形成有着深远影响。

书同文，车同轨，统一度量衡，从湖南湖北进入关中地区，人们不用换车轴，大家写信传递信息用的是一样的小篆，商人们买卖东西不用带两把称价格也好算了，半价就是八两，八两就是半斤。

全国统一使用普通话作为官方通用语言，教学中也普遍使用普通话授课，部分少数民族聚居地区采用双语授课的方式。如今我们去香港、澳门、新疆、内蒙等地，基本上完全没有语言障碍，当地的服务人员和居民不论是否为当地土生土长的居民，对于使用普通话交流都是完全顺畅的。

使用同一个时区，在大学期间，过年时候，跟好友刘琪打电话，虽然每次我们已经吃完饭准备要睡觉了，他接了电话总是正要准备吃饭，但是我们的沟通使用的是同一个时间，约好晚上9点多通话，那就是晚上九点多，我们不需要在心里换算一下对方口中说的时间跟我自己当下的时间是否是同一个时间。那么美国人呢？他们使用四个时区，我听邻居说荷兰到现在还会使用夏令时（也就是在一年中的某一个时间点，他们国家的时间会统一往前或者往后拨一个小时），他们公司是一家荷兰的畜牧业科技公司（是的荷兰是一个畜牧业大国和农业大国，农业出口世界第二，肉类出口欧盟第一，国土面积跟咱们重庆一般大）。

老家县城的孩子们（很多都是进城读书的娃），基本上已经不太会说永新话了，目前很多孩子还能听得懂永新话，再往下一代，可能就要听不懂了。以前我们老家，隔一个县，很多方言就不太相通了，隔一个镇子方言和口音都有所不同，现在大家说的都是普通话，去到隔壁县的任何一个镇子上，下车去超市或者小店里头买东西，人家直接说普通话就好了。

我们都知道甘南地区有着很多的藏族同胞在那儿居住和放牧，这个地区的宗教和文化认同更多是藏族，但是其行政规划属于甘肃。还有湘西地区和黔东南的苗族聚居区和文化圈，也属相似的情况。小时候听家里长辈们说起一些稍微靠近隔壁县的村里的人和事儿时，总能听到一些嫁到隔壁县和从隔壁县嫁过来的上一辈女性的故事，这些靠近两县交界处的村子之间，虽然行政上各属不同县，但是在文化和习俗上，乃至人情世故中，却是你中有我我中有你的交融之态。

整个欧洲大陆的天主教/基督教信仰，十字军的东征，某些恐怖组织奉行的极端主义意识形态和信仰，把一小部分人变成了共同体，而这些共同体之间的隔阂或者说排斥，随着共同体的愈发坚固而变得相互之间越来越水火不容，现如今的世界地缘冲突无不是源于此。

曾经的火车，如今的高铁，在现实中把更多的小圈层打破连接成大圈层，把众多小的共同体逐渐融合成更大的共同体。在众多网民的手机中安装的抖音、快手、小红书、Tiktok、Instagram、Facebook等等等等，在线上构建形形色色的共同体，这些「共同体」之间，互相点赞也好，时不时地互喷也罢，俨然把这些散落天涯各处的个体缀成了一个个巨型网络，网络与网路之间的勾连和撕扯，每天每时每刻，都在牵动着网上的你和我。

说不上好坏，道不明是非，似懂非懂，瞎想一通。把自己听完节目后的一些胡思乱想和平日里的一些想法记录一下。

就这样吧，北京已经进入了三十多度的高温天气了，刚刚拿出来的风扇嗡嗡地叫着，时间也不早了，睡吧。

原文链接：微信公众号