最近用 Codex 写项目，发现了一个问题，就是上下文的管理。

但我最近发现了一个很好用的项目，叫 ok-skills，它是一套专门为 Claude Code、Codex、Cursor 这类 AI 编程工具整理的可复用 skill 集合，有 40 多个。

可以告诉 AI 在特定场景下应该怎么工作，做什么，不做什么。

1
先说我用得最多的一个：planning-with-files。
它解决的问题很具体：AI 在复杂任务里没有持久记忆。

这个 skill 的思路来自 Manus 的工作方式——把"上下文"从对话窗口移到文件系统。
它让 AI 在开始任务之前先创建三个文件：task_plan.md 记录阶段目标和决策，findings.md 存放调研发现，progress.md 做每次操作的流水记录。

整个任务过程中，AI 每隔两个操作就写一次文件，保证关键信息落到磁盘上，而不是飘在对话上下文里。

我实际用起来的感受是，任务被强制结构化了。
AI 不能一上来就开始写代码，必须先建计划，先搞清楚做什么、分几步、每步验证什么。遇到报错也要记下来，下次不许重复同样的失败方式。
正是因为有这些约束，长任务才不容易跑偏。

2
另一个让我觉得挺有意思的是 grill-me。
它做的事情是，在你真正动手之前，逼着你把方案想清楚。

具体方式是一问一答的审讯式对话。
AI 会对你的方案提问，一次只问一个问题，问完你的回答再继续问下一个，直到设计上的每一个决策都有明确答案为止，不允许你含糊过去。

我第一次用它的时候觉得有点烦，因为它揪住了几个我自以为想清楚了但其实根本没想清楚的地方。
但事后复盘，那几个被追问出来的问题，确实是后来真正出问题的地方。

与它配套的还有一个 grill-with-docs，专门对照文档、架构决策记录（ADR）来质疑你的方案，边问边帮你把结论更新到文档里，对需要维护长期项目文档的场景很有用。

3
还有几个平时用得到但容易被忽略的：
find-docs 是查文档的。AI 写代码经常会用到一些过时的 API，因为它的训练数据有截止日期。
这个 skill 接入了 Context7，能在写代码之前先拉取当前版本的库文档，减少写出来能跑但已经是旧写法的情况。

gh-fix-ci 是修 CI 的。
GitHub Actions 挂了，日志拉下来，让 AI 读、归因、出方案，一套流程走完。不用自己一行行去看那些 ANSI 颜色乱码的日志。

frontend-design 和一整套叫 impeccable 的设计 skill 包是做界面的。
这套东西有个专门的概念叫"AI slop test"——如果你把这个界面给人看，对方一眼就觉得是 AI 生成的，那就是问题。

skill 里整理了一份很详细的"AI 生成界面的典型指纹"：蓝紫色渐变、毛玻璃卡片、每个 heading 旁边放图标……
skill 的作用是给 AI 立规矩：什么不能用，往哪个方向走。

4
使用方式不复杂。
把仓库 clone 到 ~/.agents/skills/ok-skills，然后在你的 AGENTS.md 或者 CLAUDE.md 里加几行触发规则，告诉 AI 什么时候用哪个 skill。

比如任务超过 5 个工具调用就启用 planning-with-files，需要查文档就用 find-docs，要做界面就读 frontend-design。
之后直接自然语言说"用 planning-with-files 来规划这个重构"就可以了。

仓库里的 skill 来源很杂，有 Anthropic 自己出的，有 OpenAI、Vercel、Upstash、各路开发者贡献的，ok-skills 这个仓库做的事情是把它们收集整理到一起，让你不用到处找。

这个ok-skills 是目前我见过整理得比较完整的一套。

我最近刷到，MiniMax解决了一个“马嘉祺”bug😂

MiniMax团队最近发了一篇技术博客，讲他们怎么排查一个时代少年团粉丝反馈的问题。
有粉丝发现，问模型“马嘉祺”是谁，它虽然能完整回答，出道经历、所在团体、代表作。

但只要你追问他叫什么名字，模型就会已读乱回，就是喊不出马嘉祺的名字。

我看到这个问题的时候，第一个猜测是：是不是训练数据里这个名字出现太少了，模型压根没学到。
但实际答案比这有趣得多。

1
是不是模型根本不认识这个名字呢？
这在逻辑上说不通，因为模型能介绍这个人，说明它知道这个人。问题不是知识缺失，是别的地方出了问题。

比如，我们有时候也会出现，想说某个人的名字，但就在嘴边，说不出来。
大模型也会有类似的问题。
模型内部有两个关键模块：
一个叫embedding，负责把文字转成模型能计算的向量，可以理解为理解层；
另一个叫lm_head，负责把向量转回文字输出，是生成层。
这两套参数是独立的，各管各的。
MiniMax团队检查了预训练之后嘉祺这个词的理解层状态，向量正常，最近邻全是相关人名，亚轩、千玺、肖战……理解层完全没问题。

但问题出在生成层。
模型知道嘉祺是谁，但生成层找不到它了。

2
那么，生成层出了什么问题呢？
知道是生成层的问题之后，我以为还是数据太少。后训练数据里嘉祺这个词出现频率太低，所以生成层没学好。
这个猜测只对了一半。
MiniMax统计了一下，后训练数据里包含嘉祺的样本不足5条。

频率低确实是起点，但真正造成问题的机制是这样的：一个词几乎不出现在训练目标里，它的生成层参数就几乎收不到正向的梯度更新。
但与此同时，有一种叫weight decay的正则化机制还在持续施压，让不活跃的参数慢慢往零的方向漂。
这个漂移过程是无声的。不报错，不影响模型整体表现，标准评测也发现不了。
漂移到什么程度？
检查生成层之后，嘉祺这个词的近邻已经变成了file_content、edit_file这类工具调用标记。
一个人名，跑到了代码工具的语义空间里。

3
知道根因之后，MiniMax顺手扫了整个词表，看看还有哪些词退化了，然后发现了一件更让我意外的事。
退化最严重的不是某个明星的名字，而是日文口语token，占退化最大类别的40%以上。

这些词在预训练时学过，但后训练数据里几乎没有它们的位置。
但漂移带来的后果不只是说不出日语词。日文向量飘走之后，跑到了其他语言的向量旁边。

生成时错误激活，就出现了跨语言干扰。
这就和另一个被诟病已久的问题对上了——日语对话偶尔会混入俄文，一直没找到根因。
数据非常直接：修复前，日语对话里俄文字符的出现率是47%，29.7%的日语token跌破了向量相似度的健康阈值。
两个看起来完全无关的问题，同一个根因，一条线索解了两道题。
而这种问题在常规评测里几乎发现不了，只有在真实使用里才会以各种奇怪的方式冒出来。

4
那如何修复呢？
MiniMax的实际方案是：把全词表20万个token随机分组，每组大约8000个，打乱顺序构造成一条对话，query是这堆词加一句请重复以上内容，answer就是原样复制。
总共500条数据，确保每个token至少作为生成目标出现20次。
结果出乎意料地好。日语对话俄文混入率从47%降到1%，马嘉祺正常输出，全词表向量相似度维持在0.97以上。
500条数据修好了20万词表。
当然，这只是目前跑通的一条路，MiniMax在博客里也提到，他们还在探索其他方向。
一个思路是在后训练数据里按比例混入预训练语料。预训练数据的词表覆盖天然比后训练数据宽得多，混进来相当于给那些冷门token补了一条保险。
另一个思路是专门统计哪些token在后训练数据里覆盖不足，然后针对性地造包含这些token的高质量对话样本。相比全词表覆盖的方案，这种方式数据量更小，语义质量也更高，代价是需要维护一套持续监控token覆盖度的机制，不是一次性的工程。
还有一条路更激进，直接从词表层面下刀——把那些在目标场景下几乎永远不会用到的token裁掉，比如预训练特有的格式标记、传奇私服这类SEO垃圾词，然后对裁剪后的词表做继续预训练，重新对齐整个向量空间。

5
说回这篇博客本身，我觉得最值得单独讲的不是技术方案，而是他们选择把这件事写出来这个动作。
大多数公司发现bug之后，会悄悄修掉。
但MiniMax这次，是直接把整个排查过程都写了出来，包括最开始错误的猜测，包括哪些问题还没完全解决，日语退化的完整数据。
这种问题如果不说出来，行业里每家做后训练的团队都有可能踩到，各自私下修，各自损失。把过程写出来，意味着让别人看到你走过的弯路，也意味着让整个行业少走一遍弯路。
时代少年团的粉丝大概没想到，测试爱豆这个动作，最后推动了一次行业层面的工程研究。

经常要画架构图，但不知道怎么用AI生成的朋友们，推荐你去装一下这个Skill，叫 fireworks-tech-graph。

你说一句话，它就可以给你画一张生产级别的技术架构图，SVG 加高清 PNG，直接能用。

而且一行命令搞定安装，五分钟以内全部就位。

现在已经6k多star了！我装上去用了一周，说一下真实感受。

1

第一个场景，是给一篇内部文档配架构图。

比如，写一个关于 Mem0 记忆机制的技术说明，需要解释数据怎么流进来、经过 Memory Manager 之后怎么分别写进 Vector Store、Graph DB 和 KV Store，检索的时候又怎么从三个地方读取合并、最后返回给上层应用。

这套逻辑如果自己画，光是想清楚节点布局就要花不少时间，更别说还要对齐、调样式、选字体。

可以直接跟它说：画一个 Mem0 记忆架构图，蓝图风格，包含这几个节点。

它对 AI 和 Agent 领域的图表有真正的语义理解，知道什么节点用什么形状、什么关系用什么箭头，这些领域知识你不需要每次在 prompt 里重新解释。

2

还有另一个场景，是给技术分享做幻灯片配图。

内容是一个工具调用流程：LLM 收到请求，调用 Tool Selector，执行工具，Parser 处理结果，再返回给 LLM，整个是一个循环。

Style 2，深色终端风，黑底加霓虹色，等宽字体。告诉它流程节点，让它画。

3

当然，如果你本身对图形工具很熟练，用draw.io 做架构图完全不觉得费劲，这个工具能给你增加的价值就有限。

它更像是把画图这件事的门槛往下压了一截，让那些"因为太麻烦所以算了"的图，变得真的会去画。

很多技术文档写得不好，不是因为作者不懂，是因为配图太费事，最后文档里全是文字，读起来很累。

如果画图的成本降到跟写一句话差不多，配图这件事就会从"要不要做"变成"当然要做"。

有一类人可能最合适：独立开发者，或者在小团队里什么都要干的人。

既要写代码，又要写文档，还要做演示。这种情况下，能在需要的时候快速出一张像样的架构图，省的不只是时间。

当然，够不够用，还是推进你自己装一下试试。

做产品经理的朋友们，推荐你们都去装一下这个skill，名字叫 lenny-skills。

这个skill，涵盖了86 个资深PM技能，都是从 Lenny's Podcast 的访谈里蒸馏出来。

Lenny's Podcast 如果你没听过，可以去搜一下，它是英文产品圈里最有影响力的播客之一。

这个项目，把 100 多期播客里的内容，整理成 86 个 Skill 文件，每个文件对应一个产品工作场景，然后放进 Claude Code 的 .claude/skills/ 目录里。

我装上去试了一周，说一下我的真实感受。

1
我第一个用的是 writing-prds 这个技能。

我们团队在做一个新功能，大概方向清楚了。

装了 writing-prds 这个技能之后，我重新跟 Claude 对话，说我在做什么、目标用户是谁、想解决什么问题。

Claude 问我的第一个问题是：你现在写这份 PRD，最主要的读者是谁，他们读完之后需要做出什么决定？

我的 PRD 是写给工程师看的、还是给 stakeholder 看的、还是给自己理清思路用的，这三件事对应的写法其实完全不一样。

之后 Claude 给我的建议开始变得不一样了。

它不是在帮我填框架，而是在帮我想清楚一些更根本的东西：这个问题值得现在解决吗、我们真的理解用户痛点还是在假设、成功的标准是什么以及我们有没有能力衡量它。

2
还有competitive-analysis 这个技能。

当时我在研究一个竞品，想搞清楚我们跟它的差距在哪、对方的定位是什么、我们有没有机会。

用 competitive-analysis 技能之后，Claude 先问了我几个问题，有一个是：你现在做这个竞品分析，是要做出什么决定，还是要说服谁？

我当时随口说，是给团队做方向判断用的。

Claude 接下来说的一句话我印象很深：竞品分析最常见的错误，是把描述当成了分析。知道对方有什么功能是描述，但知道他们为什么这么做、这么做意味着什么、我们应该如何回应，才是分析。

然后它引导我沿着这个方向去想：竞品的用户是谁、他们选择竞品的真实原因是什么、对方在哪些地方有结构性优势而不只是暂时领先、我们能差异化的空间在哪里。

3
说实话，如果你是一个经验很丰富的 PM，在某些场景下你可能觉得这东西给出来的框架你早就知道。

但即便是这样，我觉得它的价值可能在另一个地方：帮你快速组织思路，帮你在对话里逼出一些你知道但没有认真想过的东西。

对于刚进入产品岗位不久的人，或者像我这样产品经验不是特别深、但经常需要做产品决策的人，它的价值会更直接。它不会让你跳过学习的过程，但它会在你需要的那个具体时刻，帮你用上一些你原本不知道的思考方式。

有一类人可能最适合：就是那些在小团队里、一个人当多个角色用的创业者或独立开发者。

既要做产品、又要写文案、又要想增长，什么都得懂一点但什么都不够深。这种情况下，能在需要的时候快速调用一个经过验证的框架，是很实用的事情。

最近看到Karpathy发了一条动态，说他现在大量的算力，已经不再是用来写代码，而是用来管理知识。
同时，他也在这条动态里，完整开源了他的知识管理方法。

我花了点时间认真研究了一下他的整套流程，并且在我自己电脑上也完整复刻了一下。

1
在开始之前，请先思考一个问题：你平时一般都是怎么处理信息的🤔

看到一篇好文章，直接收藏；朋友分享过来一个链接，转发给文件传输助手？
然后，这些东西就消失了......

你收进来的是信息，但信息本身不会自动变成知识。
中间差的那一步，是加工。

Karpathy的知识管理法，就是把这个加工过程，完整地设计出来。

2
他的做法其实不复杂。
你所有原始素材，文章、论文、代码仓库、图片，统统扔进一个叫 raw/ 的文件夹。
可以把这个文件夹理解为一个原材料仓库，什么都不用整理，直接堆进去。

然后他用大模型做了一件事：把这堆东西「编译」成一个wiki，也就是一个结构化的知识库。
在编译过程中，AI会提取核心概念，为每个概念单独写一篇文章，再把这些文章互相链接起来，形成一张网。

最后，他会用Obsidian作为可视化工具，查看这一切。
他几乎不会手动编辑知识库里的任何内容，所有的写作和维护，都是AI在做。

AI可以保持高度的一致性，同时处理大量文档，并且主动去找连接点。

3
知识库积累到一定规模之后，有趣的事情就开始发生了。

比如Karpathy某个研究方向的知识库，大概有100篇文章、40万词左右。
到了这个量级，他可以直接对着知识库问各种复杂问题，AI会去翻阅相关文档，综合不同来源的内容，给出完整的回答。

他原本以为需要搭一套复杂的RAG系统才能做到这件事，但实际上根本不需要。
AI在这个规模下，自己会维护索引和摘要，检索起来已经足够准确。

接下来，他不让AI的答案只存在于对话框里。
每次提问得到的输出，都会被重新归档回知识库。你的每一次探索，都沉淀成了永久的内容。

这个知识库是在生长的，而且它的生长方向，完全由你的好奇心决定。
你越用，它越有价值。

这跟我们日常用AI的方式有一个本质的区别：我们平时问完就忘了，下次遇到类似的问题，重新问。
但用这种方法，你的每一次问答都在给系统加砖。

4
Karpathy还会定期让AI对知识库做「健康检查」，找出哪些地方信息前后矛盾，哪些概念描述不完整，哪些潜在的连接还没有被发现。
这些问题找出来之后，补充、修正、新增文章，知识库的质量就在这个循环里持续提升。

我们自己的知识体系，有没有人在帮我们做这种检查？
大多数时候是没有的，我们脑子里有一堆知识，但哪些是准确的，哪些是模糊的，哪些其实是互相矛盾的，我们并不清楚，因为没有一套机制去把这些东西显化出来。

Karpathy这套流程，在某种程度上解决了这个问题。
至少在他的研究领域里，他对自己知识的掌握程度，是可以被系统性验证的。

5
不过说句实在的，他这套东西要完整复现，门槛确实有点高，需要对工具有一定的熟悉度，也需要持续投入时间去维护。

但这里面有一个思路，我觉得任何人都可以马上开始用。

你不需要搭一套完整的知识库系统，可以从一个最小的动作开始：下次读完一篇让你觉得有收获的文章，不要只是收藏，花三分钟让AI帮你提炼核心观点，然后问它一个问题：这个东西，和我之前知道的哪些东西有关联？

这一步的意义在于，它把"被动接收信息"变成了"主动建立连接"。

时间长了，你会发现自己对知识的感知方式开始变化，不再是"我收藏了很多东西"，而是"这些东西在我的理解框架里处于什么位置"。

今天刷小红书，看到我很喜欢的博主张咋啦分享她做的这个 follow-builders skill，立刻让我的龙虾去装了一下。

这个skill的核心理念源于zara之前说的：关注做产品的builder，而不是kol。

安装过程很简单，直接把这个skill复制给你的龙虾，然后让它安装。

安装好以后，会有一个简单的onboarding流程，你可以根据你的个人偏好回答一下。

我用上这个skill以后，都不需要自己去刷各种信息源站了！

现在 AI 圈子里信息太多了，很多都是故意制造焦虑的信息。真正有价值的，其实是那些在一线做产品的人的原创思考。比如 Karpathy 对模型训练的见解，Kevin Weil 对产品设计的思考，Amanda Askell 对 AI 安全的观点，这些才是真正值得花时间消化的内容。

而 follow-builders 这个skill做的事情，就是帮你把这些人的最新动态和播客内容，自动整理成一份精炼的摘要，每天或每周定时推送给你。

它追踪的内容源是精心筛选过的。包括 Latent Space、No Priors 这些顶级 AI 播客，还有 25 位真正在做事的建设者的 Twitter 账号。

这个名单是集中维护的，会自动更新，你完全不用操心。

我之前也试过用 RSS 订阅或者 Twitter 列表来管理信息，但问题是信息量还是太大了。

一个两小时的播客，你可能没时间完整听完。一个建设者一天发十几条推文，你也不知道哪条最重要。

而 follow-builders 会帮你把播客总结成关键要点，把推文筛选出最有价值的部分，配上原文链接。

你可以快速扫一遍摘要，对感兴趣的内容再去看原文。这样一来，半小时就能掌握这些顶级建设者一周的思考精华。

我现在的习惯是，每天早上直接看一遍我的虾给我整理的摘要，标记几个想深入了解的话题，晚上再去看原文或者听完整的播客。

信息焦虑没有了，反而对行业动态的把握更清晰了。

而且如果你想调整摘要的风格，也可以随时跟 agent 说。比如让摘要更简洁一点，或者更关注技术细节，或者换成更轻松的语气。它会自动帮你调整，下次推送就生效。

对于做产品的人来说，这个 skill 还有一个隐藏价值：它帮你建立了一个高质量的信息参照系。

就像 Ovitz 说的那样，当你见过的人越多、读过的东西越多，你对新事物的判断就越准确。

持续追踪这些顶级建设者的思考，你会慢慢形成自己对行业的判断框架。

什么是真正的创新，什么是炒作，什么方向值得投入，什么坑不要踩，这些感觉会越来越清晰。

而这种判断力，才是做产品最核心的能力。

所以如果你也有信息焦虑，如果你也想更高效地追踪 AI 行业的动态，如果你也想关注那些真正在做事的人而不是网红，真的可以试试这个 skill。

装上它，你会发现，原来信息管理可以这么轻松。

我最近又发现了一个项目，叫Claude Superpowers，目前它在 GitHub 上已经有 83,000 个星标了，几乎每天都挂在热门榜上。

用它的几乎全是开发者，市场营销的朋友们好像完全不知道这个东西的存在。

你可能会问，Superpowers是什么？

这是一个让 AI 变得更聪明的技能框架，它会强制 AI 在开始干活之前，先退一步问你：你到底想要什么？

然后把你的需求整理成一份清晰的方案，分段展示给你看。

等你确认没问题了，它才会开始执行。

而且执行的时候也不是乱来的，它会把整个任务拆成一个个小步骤，每个步骤只需要 2 到 5 分钟，然后一步步推进，每完成一步都会检查一遍，确保没跑偏。

1

我知道你在想什么：这听起来像是给程序员用的东西啊？

但你仔细想想，做市场营销的时候，你是不是经常遇到这些情况：

你想策划一个活动，跟 AI 聊了半天，它给你输出了一大堆内容，看起来挺像那么回事。

但仔细一看，要么是跟你的品牌调性不搭，要么是根本没抓住你的目标用户。

你想写一篇深度的产品文章，AI 给你写了 3000 字，但通篇都是那种很空的话，没有具体的案例，没有真正能打动人的细节。

你想做一套完整的内容矩阵，AI 给你列了 20 个选题，但你不知道该从哪个开始，也不知道这些选题之间有什么逻辑关系。

这些问题的本质都是一样的：AI 太着急给你答案了，它没有真正理解你要什么。

而 Superpowers 的工作方式，恰好能解决这个问题。

2

那具体怎么用呢？

举个例子，假设你要策划一个新品发布的传播方案。

如果你直接问 AI，它可能会给你输出一个看起来很完整的方案，但你总觉得哪里不对劲。

但如果你用了 Superpowers，流程会变成这样：

首先，它会问你一堆问题。

你的新品是什么？目标用户是谁？预算多少？时间线是怎样的？你希望达到什么效果？你有哪些渠道资源？

然后，它会根据你的回答，整理出一份方案大纲，分成几个部分展示给你：传播策略、内容规划、渠道选择、时间安排、预算分配。每个部分都足够短，你可以快速看完并给反馈。

等你确认了大方向，它才会开始细化。

它会把整个执行过程拆成具体的任务：第一步做什么，第二步做什么，每一步需要产出什么内容，怎么验证效果。

而且在执行的过程中，它会不断检查：这个文案是不是符合我们定的调性？这个渠道选择是不是跟目标用户匹配？这个时间节点是不是合理？

这种工作方式，其实就是一个靠谱的市场总监会做的事情。

3

它帮你省下最直接的，是时间。

以前你可能需要跟 AI 来来回回沟通好几轮，才能得到一个勉强能用的结果。

现在有了 Superpowers，它会在一开始就把事情问清楚，大大减少返工的次数。

其次是质量。

因为它会强制 AI 在每个环节都做检查，所以输出的内容会更符合你的要求，更有逻辑性，更容易落地。

最重要的是，它能帮你建立一套可复用的工作流程。

你第一次用它策划活动的时候，可能还需要花点时间适应。

但当你用过几次之后，你会发现你已经形成了一套自己的方法论。下次再做类似的事情，你就知道该问哪些问题，该怎么拆解任务，该在哪些环节重点检查。

这套方法论，不只是你自己能用，你还可以教给团队里的其他人。这样整个团队的工作效率和质量都会提升。

4

我不是说 Superpowers 能解决所有问题。

市场营销本质上还是一个需要创意、需要洞察、需要对人性有深刻理解的工作。

但它能做的，是帮你把那些重复性的、结构化的、需要严谨逻辑的工作做得更好。让你有更多时间和精力，去做那些真正需要人来做的事情。

这其实是一个机会，当所有人都在用同样的工具、同样的方法做市场营销的时候，你如果能用一套更高效、更系统的方式，你就有了竞争优势。

推荐所有做 AI 产品的朋友们一定要用一下Prompt Engineering Guide，这是我见过最全面的提示词工程学习指南。

内容很多，但全是干货，我身边很多人都把这个指南作为他们团队的必备参考资料。

不论你现在是刚开始接触大语言模型的新手，还是已经在用AI但总觉得效果不够好，亦或是正在开发 AI 产品需要更专业的提示词技巧，都可以从这个指南中学到一些干货。

1

Prompt Engineering Guide 是什么？

它汇集了从基础入门到高级技巧的所有提示词工程知识，零样本提示、少样本提示、思维链、检索增强生成……你能想到的前沿技术，几乎都有详细讲解。

而且这个项目在 GitHub 上已经获得了数百万学习者的认可，还登上过 Hacker News 第一名。

提示词工程不只是写几句话让 AI 听话，而是一种理解和驾驭大语言模型能力边界的思维方式。

2

简单讲一下这个指南的价值。

很多人刚开始用AI的时候，就是随便问几句话，得到的回答要么太泛泛，要么答非所问。

那怎么办？

这个指南做了一件很系统的事：它把提示词工程拆解成了可学习、可复制的技巧。

从最基础的提示词元素、LLM 参数设置，到高级的思维链提示、自洽性技术、思维树方法，每一个技巧都有详细的解释和实例。

你不需要有技术背景，只要跟着学，就能明显提升你和 AI 对话的质量。

而且指南里还专门讲了一个很重要的观点：提示词工程的本质是建立参照系。

当你见过的提示词案例越多、尝试过的技巧越多、理解的模型特性越深，你对新任务的提示词设计就越准确。

3

举个例子，同样是让 AI 做数学推理题，普通提示可能只有 30% 的准确率，但如果你用思维链提示，让模型一步步展示推理过程，准确率能提升到 80% 以上。

这种判断力不是天赋，而是你见过足够多的案例、参照系足够丰富。

指南就像一个知识库，在不断给你的大脑输入最佳实践。

但光有技巧还不够，这个指南还讲了另一个非常重要的观点：所有 AI 应用的底层逻辑都是相通的。

当然，具体场景不同，但核心原则是一样的。

无论是做内容生成、代码编写、数据分析还是客户服务，你都需要清晰的指令、合适的上下文、对输出格式的控制，以及对模型局限性的理解。

4

指南里有个应用案例特别有意思。有人用提示词工程做职位分类任务，一开始准确率只有 60%，后来他们用了少样本学习，给模型提供了几个标准示例，准确率立刻提升到 90% 以上。

而且同样的思路可以迁移到其他分类任务：情感分析、内容审核、意图识别……底层逻辑完全一样，只是换了个应用场景。

这套思路和做产品时的思路一模一样：找到可复用的模式、建立标准化流程、不断优化迭代。

5

真正有价值的学习资源，不是把知识藏起来卖高价，而是通过开放共享让整个社区受益，然后在更高层次提供专业服务。

如果你现在正在用 AI 工具但总觉得效果不够好，也许问题并不是工具本身，而是你还没有掌握正确的使用方法。

给做一人公司的朋友们推荐一下The Agency这个项目，让你可以拥有自己的AI专家团队！
这个项目非常🔥，现在已经15.2k star了！

这个项目把一个完整公司拆解成了 61 个专业角色：前端开发、后端架构、UI 设计、增长黑客、社交媒体运营、项目管理、质量测试。
你能想到的专业分工，几乎都有对应的Agent。

而且，每个Agent都有明确的个性、工作流程、交付标准和成功指标，你会感觉就像真的在和一个有脾气、有风格的专业人士合作。

1
这套系统的由来也很有意思。

它最初是从 Reddit 上的一个讨论帖子演化出来的，作者花了好几个月时间不断迭代，发布后的 12 小时内就收到了 50 多个请求。

这套系统做对了一件很多人没做的事：它不是简单地告诉 AI“你现在是个开发者”，而是给每个Agent建立了完整的身份系统。

比如有一个叫 Reality Checker 的测试Agent，它的口头禅是：我不只是测试你的代码，我默认会找出 3 到 5 个问题，而且所有问题都要有截图证据。

再比如 Reddit Community Builder 这个营销Agent，它会提醒你：你不是在 Reddit 上做营销，而是要成为一个恰好代表某个品牌的、有价值的社区成员。

还有 Whimsy Injector 这个设计Agent，它的原则是：每个有趣的元素都必须服务于功能或情感目的。设计的愉悦感应该是增强体验，而不是分散注意力。

这些Agent不只是工具，更像是有专业判断力的协作伙伴。

作者把这叫做建立参照系，当一个Agent见过的案例越多、处理过的场景越多、积累的模式越丰富，它对新问题的判断就越准确。

2
举个实际应用的例子。
有个团队用这套系统做了一个叫 Nexus Spatial Discovery 的项目，同时启动了 8 个Agent：产品趋势研究员、后端架构师、品牌守护者、增长黑客、支持响应员、用户体验研究员、项目协调员和 XR 界面架构师。

这 8 个Agent在一次会话中，就产出了一份覆盖市场验证、技术架构、品牌策略、上市计划、支持系统、用户体验研究、项目执行和空间界面设计的完整产品蓝图。

这种协作效率，是单个通用 AI 很难做到的。

但光有专业分工还不够，这套系统还做对了另一个非常重要的事情：它把所有Agent都设计成了可以跨工具使用的格式。

现在它支持 Claude Code、Cursor、Aider、Windsurf、Antigravity、Gemini CLI 和 OpenCode 这些主流的 AI 编程工具。
你不需要被绑定在某个特定平台上，可以在自己习惯的环境里使用这些Agent。

3
下面这部分，是我觉得这套系统最有价值的地方。

很多人问：AI 工具这么多，为什么还要专门搞一套Agent系统？直接用通用 AI 不就行了吗？
作者的回答很直接：因为专业化才是效率的来源。

通用 AI 就像一个什么都懂一点的通才，但当你需要解决具体问题时，你需要的是在某个领域深耕多年的专家。
这些专家不仅知道怎么做，还知道什么时候该做、什么时候不该做、遇到什么情况该调整策略。

而这种专业判断力，恰恰是通过大量的领域知识、工作流程和成功案例积累出来的。

The Agency 的每个Agent都内置了这些经验，它们不是从零开始学习，而是站在已经被验证过的最佳实践基础上工作。

这就像你不需要每次都从头教一个新人怎么做项目管理，而是直接和一个有十年经验的项目经理合作。

现在已经有社区维护的中文版本了，覆盖了 26 个翻译Agent，还增加了 4 个针对中国市场的专门Agent。

4
能用一辈子的工具，不是因为它功能最全，而是因为它能随着你的成长而进化。

The Agency 这套系统的核心价值，就是它提供了一个可以不断扩展的专业协作框架。
今天你可能只需要前端开发和 UI 设计两个Agent，明年你可能需要增长黑客和数据分析，后年你可能要加入 XR 界面设计。

这个框架会一直在那里，随时可以调用你需要的专业能力。

如果你现在正在用 AI 辅助工作，但总觉得效率还不够高，也许问题不是 AI 本身，而是你还没有找到合适的协作方式。

我非常推荐你们去了解一下 Nick Saraev 这套关于 Claude Skills 的实战教程！

虽然长达一个多小时，但全程都是可以直接落地的干货。
评论区很多人也说，这可能是目前关于 AI Skills 最实用的一期内容，有人已经看了好几遍了。

不论你是正在做自由职业想要提升效率，还是经营着小团队需要自动化流程，亦或是已经在运营成熟业务，都可以从这套方法论中获益。

1

Claude Skills 是什么？
它像是一个可以 24 小时不间断工作的数字员工，而且不需要你付工资。Nick 现在经营着一家年利润 400 万美元的公司，而他管理这家公司主要靠的就是 AI agents 和这些 skills。

他教的 2000 多个学生也在用同样的方法。

2

简单讲一下 Nick 展示的几个核心技能。

第一个是自动跟进潜在客户。

你只需要输入/follow-up nurture 这个命令，系统就会自动扫描你的 CRM 里所有处于不同阶段的客户，查看之前的邮件往来记录，然后给每个人发送个性化的跟进邮件。

这些邮件读起来就像是你亲手写的一样自然，不会让人觉得是机器人在发。

整个流程从以前需要花几个小时，现在变成几秒钟就搞定。

第二个是一键生成视频缩略图。

Nick 拿一张著名的约翰·哈姆的照片举例，只需要说 reproduce the John Ham thumbnail，系统就会自动提取你的面部特征，生成多张不同风格的缩略图供你选择。

整个过程也就几十秒，效果相当惊艳。

第三个是 LinkedIn 潜在客户抓取。

你可以直接说 scrape me 50 management consultants in Arizona，系统就会自动去 LinkedIn Sales Navigator 抓取目标客户的姓名、邮箱等信息，整理成 Excel 表格。这在以前可能需要外包给数据公司做，现在几分钟就完成。

第四个是冷邮件营销自动化。

输入客户信息后，系统会参考你之前表现最好的邮件模板，自动重写适合新客户的版本，还能生成多个变体用于 A/B 测试。

把原本需要三四个小时的工作压缩到几分钟。

第五个是快速网站生成器。

给系统一个简单指令，它就能生成一个高质量的网站并部署到 Netlify，你可以直接把链接发给潜在客户。这种价值赠送往往能让客户印象非常深刻。

3

除此之外，Nick 还展示了两个很有趣的个人生活技能。

一个是自动预订 WeWork 工位，另一个是 Amazon 购物助手。

前者让他不用再每天手动预订，后者帮他比较 Amazon 上的商品，自动选出性价比最高的选项。

这些 skills 最强大的地方在于，它们不只是执行预设指令的工具，而是会自我修复和进化的智能体。

如果运行过程中遇到 API 限制、服务中断或者逻辑漏洞，系统会自动识别问题并修复，甚至重写 skill 本身。

就像 Nick 说的，这相当于雇了一个既聪明又有上进心的员工，看到问题会主动解决，而不是等着你来指挥。

4

从底层逻辑来说，skills 其实就是传统 SOP 的进化版。

以前我们给员工写操作手册，现在我们给 AI agent 写 skills。

你把任何一个业务流程写成清单，喂给 Claude 或 Gemini，它就能帮你转成 skill 格式。整个过程比你想象中简单得多。

Nick 说了一句话让我印象很深：现在大多数人在用 AI 做花哨的 demo，但真正能创造价值的，是那些能解决具体业务问题的应用。

如果你现在做的事情让你感到繁琐重复，也许问题并不是事情本身，而是你还没有找到合适的自动化方案。

这就是技术改变工作的最好例子。