别让AI再造轮子，烧的全是Token。两个Skill，搜GitHub翻arXiv，Token省下一大截

lincats

526人浏览 · 2026-08-13 06:34:14

lincats · 2026-08-13 06:34:14 发布

别让AI再造轮子，烧的全是Token。两个Skill，搜GitHub翻arXiv，Token省下一大截

几个月前，用 AI 开发了一款小工具，耗费了不少 Token 和时间，完成后随手一搜 GitHub，同类项目不下二十个。那种感觉像辛苦做完了作业，翻开答案本发现早有标准解法。直到最近看到 AI Labs 的两个 Skill，Advise Project Approach 和 NeuroArchive，才意识到这个问题早有系统性的解法。

一、Agent 从不抬头看路

打开 Claude Code 或 Codex，开启 Plan Mode，描述需求。Agent 思考片刻，输出构建方案。

这个过程流畅、专业，却有一个巨大的盲区。

Agent 从不检查需求是否已有现成的方案。 无论是付费工具还是开源项目，它不会主动搜索。新建项目如此，给已有产品添加功能时同样如此。Agent 直接开始探索解决路径，从不查看互联网上是否已有答案，从不参考同类产品如何解决相同问题。

后果直接且昂贵。大量时间与 Token 消耗在已被解决的问题上。

视频原作者 AI Labs 直言，Agent 的问题在于

"Your agent never checks if the thing that you want already exists or not. It never looks how other competitors have solved that problem."

（你的 Agent 从不检查你想要的东西是否已经存在，也从不查看其他竞争者如何解决了同样的问题。）

Agent 的默认行为是"从零开始构建"，这个默认值每一天都在浪费开发者的计算资源。

二、Skill 1，Advise Project Approach，先搜索再动手

AI Labs 构建了一个 Skill 来精确填补这个盲区，名为 Advise Project Approach。

使用指南

安装仅需一行命令，将 GitHub 仓库链接粘贴到 Agent 中即可。

 npx skills add https://github.com/AaravKashyap12/advise-project-approach

Skill 会被安装到 .claude/skills/ 目录，Claude Code 自动发现并加载。

触发方式。 Skill 安装后，在 Claude Code 对话中描述构建需求即可自动介入。无需特殊指令，只需把想做的事情说清楚。

 我想在 Next.js 项目里加一套用户认证系统，支持邮箱登录和 OAuth。帮我评估一下有哪些现成的方案。

Skill 收到需求后不会立刻动手写代码，而是按以下顺序执行。

追问澄清。
受众是谁？预算多少？必须免费还是可以付费？
全网搜索。
自动检索 GitHub 和官方文档，列出匹配的付费工具与开源方案。
标注筛选。
对每个方案做出判断。哪些直接可用，哪些需要改造，还有一些只是因为大团队规模才那么复杂，并不适合当前项目。
成本估算。
按开发期、上线日、增长期三个阶段给出成本预估。

整个过程不需要使用者告诉 Skill "去搜索"或"去对比"。这些步骤已经内置在工作流里。使用者只需要回答它提出的问题，其余由 Skill 自行完成。

适用场景。 Skill 在两种情况下效果最显著。

第一种是从零启动新项目。拿到需求后不要直接进入 Plan Mode，先把需求丢给 Skill，让它做一轮全网搜索。往往能发现已有工具可以直接用，免去数天的开发工作。

第二种是给已有项目添加新功能。假设项目里需要加一个消息推送模块，自己从头写大约两天。但 Skill 搜索后可能发现 Firebase Cloud Messaging 或 OneSignal 已经能覆盖需求，接入只需两小时。

两种场景的核心逻辑一致，在写任何代码之前，先确认轮子是否已经存在。

如何回答 Skill 的提问。 Skill 追问时，回答越具体，搜索结果越精准。

问题	模糊回答	精准回答
受众是谁？	"普通用户"	"内部 20 人团队，后续可能扩展到 500 人"
预算范围？	"不太贵就行"	"零预算，只能用免费方案" 或 "每月 200 元以内"
必须免费？	"都行"	"核心功能必须开源，周边服务可付费"

回答得越具体，Skill 越能筛掉不匹配的方案。模糊的回答会让它列出一长串选项却无法收敛。

阅读 Skill 的输出。 Skill 完成搜索后会输出一份结构化的方案文档，包含三部分信息。第一部分是匹配方案的列表，每个方案附有适用性判断和理由。第二部分是它所做的假设清单。如果某个假设不对，直接纠正，Skill 会基于修正后的假设重新筛选。第三部分是三阶段成本估算表，标出开发期、上线日、增长期各自的费用变化。

拿到这份输出后，使用者的决策路径很清晰。有直接可用的方案就优先用，部分匹配的先评估改造代价，完全没有的再自行构建。

它的工作流程分为四个步骤。

第一步，判断场景。 全新项目与在已有代码上添加功能，是两个完全不同的问题。Skill 首先确定当前处境。新想法则规划整体架构，已有项目则分析现有代码，明确指出保留什么、修改什么。

第二步，澄清需求。 Skill 不会在需求模糊时直接搜索。它会先行追问。目标受众是谁？需要解决什么？预算约束如何？能接受付费方案还是必须坚持免费？

对于已经明确的信息，Skill 直接跳过。对于未提供的信息，它不会悄悄猜测，而是显式写出所做的假设，供使用者审视和纠正。

第三步，搜索已有方案。 需求明确后，Skill 同时搜索付费工具与开源项目。若官方文档和 GitHub 的搜索结果不够充分，它会询问是否需要扩展到更多社区平台获取信息。实测中，多数场景不需要额外来源即可定位到可用的方案。

第四步，也是最关键的一步。区分什么对当前项目确实有用。

GitHub Stars 陷阱

Agent 天然倾向选择最流行的方案。在 GitHub 上，"流行"意味着 Stars 最多。

但 Stars 只是一个只增不减的书签计数器。它说明"曾经有许多人觉得这个项目不错"，仅此而已。

Stars 无法回答的问题只有一个。这个方案是否匹配当前的场景与规模。

更隐蔽的陷阱在架构层面。一个领域内最大的开源项目之所以庞大，通常因为它背后有一支完整的团队和大量的用户。它的架构为那个规模设计，对那个团队而言是正确的选择。如果 Agent 直接照搬，使用者得到的是全部复杂的设置，却没有获得任何适配自身场景的理由。

Advise Project Approach 强制要求，对找到的每个项目，写清楚两件事。什么对当前场景有实际价值，什么只是因为对方体量庞大才存在。这就是"为自身情况构建的方案"和"为别人的公司构建的方案"之间的分野。

被忽略的成本维度

假设要在应用中加入即时通讯功能。完全不需要从零构建，Stream 和 Sendbird 已将整套方案产品化，接入即可使用。

但先看成本。

Sendbird 免费计划覆盖约 100 用户
Stream 起步约 500 美元/月，支持 10,000 用户
两者在超出额度后，每增加一个聊天用户均需额外付费

Agent 通常完全忽略这个成本视角。Advise Project Approach 在三个时间点强制检查成本。开发期（零用户）、上线日（真实用户涌入）、增长期（规模化后）。将六个月后才会显现的成本问题，提前到决策阶段看清楚。

三、Skill 2，NeuroArchive，当前沿没有现成方案时

Advise Project Approach 覆盖了绝大多数场景。它回答的核心问题是"什么东西已经存在"。

但遇到实验性需求，尚未有人发布过成品，Skill 1 就停住了。

这不代表没有人研究过。概念可能早已存在，只是尚未产品化。

当现成方案不存在

AI Labs 在构建 Skill 分发工具时遇到了这样的场景。他们需要一个 CLI 工具，能将 Skill 更新自动推送到用户的笔记本电脑上。Advise Project Approach 标记出这个环节存在安全隐患，随后停住了。没有现成的参考方案可以索引。

这时第二个 Skill 登场，名为 NeuroArchive。

搜索学术前沿

NeuroArchive 搜索的平台是 arXiv。

这个平台上的内容来自大学和实验室的研究者。他们的全部工作就是花费数月甚至数年钻研一个特定问题，随后精确记录下发现了什么、什么路径走不通。其他研究者阅读、拆解、引用，全部免费公开。

如今使用的几乎所有底层技术都起源于 arXiv。让 ChatGPT 成为可能的 Transformer 论文，在产品出现数年前就已发布在 arXiv 上。

当构建实验性功能时，答案就躺在 arXiv 上。

每篇论文一个子 Agent

NeuroArchive 的运行方式有其独特之处。它接收问题后，匹配合适的研究领域，拉取相关论文。

阅读方式才是关键。

它不会一次性读完所有论文。每篇论文分配一个独立的子 Agent，一个携带全新上下文窗口的独立 Agent，主 Agent 自动向其传递 Prompt。一篇论文对应一个阅读者，彼此看不到对方在读什么。全部读完后，汇总为一个结论。

在 AI Labs 的案例中，针对"自动推送文件到用户设备的安全问题"，NeuroArchive 拉取了 12 篇论文。反复筛选后锁定一篇关于包管理系统的论文，按照论文描述的技术方案实现、测试，最终确认有效。

四、Skill 3，Head Start，智能路由层

两个 Skill 各自独立运行有一个现实的问题。NeuroArchive 运行成本高，而大多数构建场景并不需要它。

于是使用者的行为模式变成了，平时不运行 NeuroArchive，等到实际需要的那一次，恰好也没有运行。

AI Labs 构建了第三个 Skill，Head Start，将两者合并。它对所有任务运行 Advise Project Approach，仅在遇到确实全新的问题时自动引入 NeuroArchive。

Head Start 目前仅在 AI Labs Pro 社区内提供，没有公开的 GitHub 仓库。但它的逻辑并不复杂。它就是一个路由层，先运行 Skill 1，分析结果，仅在"无现成方案"时调用 Skill 2。

自行构建 Head Start

在 .claude/skills/ 目录下创建 head-start/SKILL.md，内容如下。

 # Head Start — 智能构建顾问

 先搜索已有方案，找不到时自动深入学术论文。

 ## 工作流

 收到构建需求后，按以下顺序执行。

 ### Phase 1，已有方案搜索

 调用 Advise Project Approach 的完整流程。
 1. 判断场景（新项目 / 添加功能）
 2. 澄清模糊需求（受众、功能边界、预算约束）
 3. 搜索付费工具与 GitHub 开源项目
 4. 区分"对当前规模有用"与"大团队才需要"
 5. 三阶段成本检查

 ### Phase 2，判断是否需要深入

 Phase 1 结束后自检。
 - 是否找到了至少一个直接可用的方案（付费或开源）？
 - 若有，直接输出建议，Phase 2 跳过
 - 若全部不适用，或核心模块无现成方案，进入 Phase 3

 ### Phase 3，学术前沿搜索

 调用 NeuroArchive 流程。
 1. 将未解决的核心问题提炼为研究问题
 2. 确定匹配的研究领域
 3. 搜索 arXiv，拉取相关论文
 4. 每篇论文分配子 Agent 独立阅读
 5. 汇总结论，给出技术路线建议

 ### 输出格式

 无论走到哪个 Phase 结束，均输出以下内容。
 - 已有方案清单（适用/不适用的原因）
 - 如进入 Phase 3，论文列表、推荐方案、实现思路
 - 三阶段成本估算

创建后 Claude Code 会自动发现该 Skill，无需额外配置。

调参建议。 Head Start 仅有一个可调参数，"什么算找不到"。默认规则如下。

条件	判断
找到 ≥1 个直接匹配的开源项目	停在 Phase 1
仅找到"部分匹配"或需大量改造	进入 Phase 3
GitHub 无匹配，但有商业 SaaS 可选	列出选项与成本，停在 Phase 1
完全找不到任何方案	进入 Phase 3

可按团队偏好调整阈值。保守型（有半个方案就不进 Phase 3），激进型（非 100% 匹配就进 Phase 3）。

五、实战全流程，构建一个 Skill 分发工具

AI Labs 在视频中完整演示了用这套 Skill 体系从零构建一个真实工具的过程。需求很明确。做一个 CLI 工具，将团队的 Skill 发布出去，使用者自动获取更新。

安装与启动

安装仅需一行命令。

 npx skills add https://github.com/AaravKashyap12/advise-project-approach

NeuroArchive 同理。

 npx skills add https://github.com/UditAkhourii/neuroarxiv

安装完成后，在对话中直接描述需求即可触发 Skill。AI Labs 当时提交的 prompt 如下。

 /advise-project-approach 我们想做一个工具，把团队的 Skill 发布出去。下载了这些 Skill 的人，应该能自动获取更新，不需要手动检查版本是不是最新的。帮我评估一下有哪些现成的方案，以及最适合的技术路线。

Skill 加载后启动研究流程，随后回过头提出了四个关键问题。

受众是谁？
提供多个选项，建议先为内部团队构建（因为团队本身也使用内部 Skill），再扩展到社区
支持哪些 Agent？
若仅支持 Claude Code，方案已经存在。Claude Code 的 Plugin 系统会自动更新。但因团队同时使用 Codex，需要自建方案覆盖更多 Agent
需要编辑 Skill 还是仅存储与分发？
确认只需要存储和推送更新，无需编辑功能
更新机制？
确认发布端手动推送，接收端自动拉取

Skill 1 的产出

Advise Project Approach 输出了项目方案文档，关键发现如下。

不需要构建 Web 应用。
Skill 可直接存储在 GitHub 上，通过 CLI 工具分发
存储问题分期解决。
内部团队阶段使用 GitHub 存储；社区发布时再评估专用存储方案
技术路线大幅简化。
比最初设想的 Web 应用方案简洁得多

NeuroArchive 接手边缘问题

方案中有一个 Skill 1 无法处理的点。将文件自动推送到他人设备的安全问题。没有现成产品可以参考。

NeuroArchive 介入。拉取 12 篇相关论文，子 Agent 分别阅读。最终选定一篇关于包管理系统的论文，按论文方案实现安全机制，测试通过。

最终成品

一个 CLI 工具。发布端两条命令，指向已有 Skill，发布。接收端的 Agent 每次重启时后台自动拉取更新，自动挂载到 Claude Code 和 Codex。

核心价值一目了然。Agent 不再从零造轮子。 约 90% 的需求有现成方案，Skill 1 负责找到并适配；约 10% 的前沿问题，Skill 2 去学术界寻找答案。Skill 3 自动判断该走哪条路径。

六、这套方案适合中文开发者吗？

原版 Advise Project Approach 的搜索范围是西方主导的。它的默认搜索路径是 GitHub、npm、PyPI、官方文档以及海外社区与社交平台。

对中文开发者而言存在明显的缺失。

缺失项	说明
Gitee / 开源中国	不在默认搜索范围
阿里云 / 腾讯云 / 华为云的托管服务	成本分析仅覆盖海外 SaaS
掘金 / 知乎 / SegmentFault	中文技术社区的方案讨论完全漏掉
微信生态 / 小程序 / 企业微信	不在"已有方案"的搜索路径里

底层的思考框架是通用的。 判断场景、澄清需求、寻找可比方案、区分"对自身有用"与"规模使然"、三阶段成本检查。这套逻辑不依赖任何特定平台。

改造方案也很简单。 在 Advise Project Approach 的 SKILL.md 中添加中文生态搜索源即可。

 ## 中文生态搜索源（附加）

 在原有搜索源基础上，额外搜索以下平台。

 ### 开源替代
 - Gitee（gitee.com），国内开源替代方案
 - 开源中国（oschina.net），中文技术方案与评测

 ### 云服务与成本
 - 阿里云 / 腾讯云 / 华为云相关托管服务
 - Serverless、云函数、短信/推送等国内 API 服务

 ### 技术方案
 - 掘金（juejin.cn），前端/全栈方案与踩坑记录
 - 知乎，架构选型讨论
 - SegmentFault，具体技术问答

这样改造后，搜索即时通讯方案时，Agent 会同时发现 Stream/Sendbird 和环信/融云；搜索支付方案时，会同时发现 Stripe 和支付宝/微信支付。

Head Start 的路由逻辑同样适用于中文生态。仅需将搜索源替换或扩充即可，路由判断本身不需要改动。