上周的文章中分享了我自己在长时间使用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就无国界了😂。

原文链接：微信公众号