吾尝试"技为义路"之术于Claude Code之属。取四千五百五十六技之众，随机采六百八十六技，索引之入织网之忆，以单句之器熔铸之，复以八务之问循之。其要数如下：严选首一之确率六十二分之五。前五集群准确率八十七点五，毫秒级查询延迟，每项任务载入约五百令 之用，较之系统提示中载列四千五百五十六技之名称与描述，需约二十二万八千符。此乃 Anthropic 之渐进披露所持之常态。得适技入代理之首选五者，十有七八焉。是故，此法较之旧术，约省四百五十六倍之语境窗口。

此篇所述，乃吾为何而试，其设如何，其果何呈，及何处破格之实。运行者与查询之全源，可复现也.

大势之下，渐进披露不足矣

Anthropic之Claude技能（及Cursor之对应技能，及其他所有代理框架之技能）皆以Markdown文件形式存于文件夹中。每项技能皆有其名，并有简短描述于其frontmatter之中。默认加载策略乃Anthropic所言之"渐进披露"：代理于启动时将每项技能之名+描述读入其系统提示中，仅在其决定调用某项技能时方加载其全文。

渐进式披露可解形体之困——汝无需为未用之技能形体付费。然其不能解索引之困。纵仅技能之名与描述，亦于每项技能、每场会话之初载入，而未及有所求。五十技能，汝需耗约二千五百令牌于目录。二百技能，目录将耗Claude Sonnet 200K上下文窗口之五分之壹，而汝犹未发一言。其数理愈演愈繁，速至难观。

纵使目录之形相符，然同类繁多，久视则辨识渐疏。逾千条目，手眼难辨之际，代理亦常误判。且无垃圾清理之制：旧技无人弃，重复无人识，目录徒增而已。

义路之式，使目录与提示相离。每技之名与说，一存于嵌入之索，有标指于磁盘之SKILL.md文。及于事时，使者行一义索之呼于事说，得五优之选，择其一，独读其全文。每转之费，恒定不论目录之广。

此乃其理。然所询者，实境中搜索果能得相关之技乎？

测试之布置

语料库。 反重力之绝技一公共之集，汇群芳之技。四千五百五十六份SKILL.md之文，依目录去重。每文皆有YAML之题（名、述、签），及markdown之体。

範例. 千技，random.shuffle(seed=42) 所選於序列之檔。其間，約二百技，默然棄於紐合吞納之端（蓋為內容驗證之濾），二十五技，單波傳遞而敗，八十六技，嵌入後終困於「待定」之態——此乃已知紐合記憶之工作者停滯也。終成索引之文庫： 六百八十六技。

路由文书. 每一技艺，其内嵌之文，悉为name + "\n\n" + description。其SKILL.md全文，恒存于盘；而mesh仅存路由之讯，并附一skill_path之标，标其盘之路径。此之故，索引中，每技艺约含五十至二百之符文.

嵌入之模。 intfloat/multilingual-e5-base，运行于本地，借由sentence-transformers，生成768维向量，存于Postgres + pgvector。十并行嵌入工作者，单CPU容器吞吐率约38文档/分钟。

查询。八种多样任务描述，于阅览语料之前所撰，旨在涵盖常见开发工作：

1. "部署docker至生产环境"
2. "分析股市数据"
3. "撰营销之函"
4. "优化迟缓之SQL查询"
5. "审安全于网应用"
6. "立CI CD之流于Python"
7. "察内存漏于C++"
8. "构React TypeScript之件"

"于每询，吾请mesh示其最似五技，察其名并余弦相似之率。"

"度。"

• 严选一：首得之技，人评者不疑而择之.
• 宽选一：首得之技，虽属同类，非至配也（如Azure部署技，应于Docker部署询）。
• 五选聚类：前五之结果至少有一为强匹配，使该代理可合理识之而用之。

其结果

：凡六八六技皆已索引，就查询而论：

严选一者：五之八焉，得六十二分之五.
五者聚群：七之八焉，得八十七分之五.
严选一者之余弦相似度：自八十三至八十八.
查询迟滞：凡试皆不逾一息.

会聚之曲

文渊之建，百艺为波，一波既成，尽套复询。此可见枢机之质，随文渊之深而增减耳。

*一问超时于行

二观落地甚坚

前五聚簇早陷饱和至五百索引之技（约全文之十一），聚簇之度已至八五，后增百八十六亦几无变动。于多问，相关技族已入索引；后变者，非技族之属，乃聚簇之魁耳

严一魁位，日攀不已。 自五百至六八六，索引之技增，首一率自五十增为六二五。其进，由于一技特立（xvary-stock-research），终得入抽样之域。每新波，皆为八问中一技全合之机。

路由诚然失职时

SQL之询，未尝产真首一。首一者food-database-query（虚应"查询"之词），而群中含spark-optimization与cqrs-implementation，然无真SQL调优之能。察语料未索引之部，sql-optimization-patterns犹存——惟落混洗之波十至四十五，出吾千例之窗。

此乃此律之真容。路由之精准，系于语料之深，非在检索之术。嵌入之法，功成矣：凡询，皆得相契之群，似度在0.83至0.88间。当所求之技在索引中，路由得之。不在，纵检索精良，亦难补偿。

其实之效：此法随技艺之增而胜。技艺未满三十，无计也——亟载之，去之。过百则算数始关，逾千则唯此可久矣.

票数之算

每事之转：

• 常载之法（四千五百五十六技艺之名与说）：系统提示符中含约228,000个符号，不能容纳于200K的上下文窗口。若为1M上下文窗口，则此内容独占预算之23%。渐进披露可存体，难存索。
• Router：一索请（微不足道之符号），返五优（约500符号），择技读全SKILL.md（约500-1,500符号，视其大小而定）。每轮总计：不足2K符号。

此率或减百倍至四百五十倍，视所启之技而定。其要：路由之费恒定，无论目录存百技抑或十万技。

诚言待解之题

嵌顿之漏. 七百七十二文入网数据库，八十六文（十一·一%）滞于“待定”之态，终未得嵌。网存工码有MAX_CONSECUTIVE_ERRORS = 10者，阻工于不善之文，默然去其余列。当为上游之题；其间，于新器重启工人，可涤积压之滞。

默然之大量摄入，则落空矣。 千百之文，其二百者，竟未尝现于库也——虽众PUT报成功，然网织所存之行列，少于所陈者。盖有内容校验之滤，施于空或近空之文。其事当察，然未损搜检之质。

十工之增。 顺常NUM_WORKERS = 3 壅塞于单核之容器。升为十倍，通量倍增（~9变~38文/分），未睹其损。此变当可于次网发布中参数化之。

查询超时。 波五运行中一查询超时于默认三十秒；重试则成。盖冷缓存预热之故，非搜索之失。

自复现之。

此试所用皆开源之物。运行者约七十行Python之码。

• 文渊：反重力之绝技
• 記憶之庫：网络内存(MIT許可，隨附MCP伺服器以運行Claude Code與Cursor)
• 行者与诘问及原果：并载于是文之侧

将语料投诸网格，稍作查询，察其反馈。若其式合于汝之流程，则布线甚易：但以一MCP之呼于汝。claude.md凡从事任事，必先于mesh中搜技能之属，合于事状者，乃取其首得而用之。

相关

若未读之，则伴文也如何整理汝之Claude技艺而不陷于文件之海论及此模式之版本管理——将技艺存为附日期标签之记忆文书，则最新版本仅一问可达，旧版永无删除之需。二文相合，既述技艺之存取之道，复明其理。

---

初载于klymentiev.com