返回首页

对比阅读

对比阅读:一个开发者用 AI 帮自己管 AI 工具 — 这 件小事暴露了 Agent 生态的真实现状 与 一个开发者用 AI 帮自己管 AI 工具 — 这 件小事暴露了 Agent 生态的真实现状

AEN
Claude CodeCursormulti-model collaboration·

一个开发者用 AI 帮自己管 AI 工具 — 这 件小事暴露了 Agent 生态的真实现状

What This Is

A developer log published on Juejin this week describes a painfully specific problem: the author had installed so many "Skills" (capability extension plugins for AI coding assistants — think of them as apps for your AI) that their description text was consuming so much of the AI's context window that the model's actual performance degraded. More plugins, d umber AI.

His fix: he designed a custom file management structure and built a command-line tool called hk-skill that handles the full plugin lifecycle — fet ching, security review, adaptation, registration, and per-project activation. The whole thing is open-sourced. What makes it worth noting is that the tool itself was built using multiple AI models working in concert. He documented in detail how he divided responsibilities across GPT, Kimi, and GLM — planning, execution, and review — and what he learned from each.

The Industry View

This story hits on a genuine structural problem in the AI tooling world: plugins and tools are proliferating rapidly, but the infrastructure for managing those tools is essentially nonexistent. The plugin ecosystems of leading AI coding assistants — Cursor, Claude Code, and others — are still in a "wild growth" phase: no unified version control, no security review standards, no cross-project activation management. The pain point this developer ran into is one that any team using AI coding tools heavily will eventually hit.

That said, we should be clear about the article 's limitations. This is a personal project dev log. The tool's stability and maintainability are unproven, and the author himself admits he " started treating it as just a small utility," a mindset that led to a sharp spike in AI token consumption later on due to missing structured documentation. More fundamentally, his solution — a local file structure with symbolic links — is a developer-native, hands-on approach that offers virtually no usability for anyone without a technical background. History shows that "developer self -rescue tools" like this fail to become general-purpose products far more often than they succeed.

There 's a second observation in the article worth pulling out separately: his account of multi-model collaboration. Using GPT for planning and review, and Kimi for execution, outperformed using any single model alone. This remains a personal perception without quantitative backing, but it aligns with a trend we 've been tracking — experienced users are increasingly exploiting the task -specific performance differences between models deliberately and systematically.

Impact on Regular People

For enterprise IT teams: If your team is already using AI coding tools at any meaningful scale, "plugin and prompt version management" needs to go on your technical debt list now. This is not a minor housekeeping issue — it directly affects the stability and reproducibility of AI-assisted development workflows .

For individual professionals: The most practically useful part of this article isn't the tool itself — it's the author's hard -won lesson: "Design documents must come paired with a technical plan. Skipping that upfront costs far more later." This holds equally in any AI-assisted workflow. The more you cut corners on upfront structure , the higher the rework cost down the line.

For the broader market: The chaos in AI plugin management will inevitably attract commercial products to fill the gap. Whoever ships a credible "app store plus package manager for AI tools " first has a real shot at owning a foundational layer of the next-generation developer stack — and right now, that position has no clear frontrunner.

来源: juejin.cn
BZH
Claude CodeCursor多模型协作·

一个开发者用 AI 帮自己管 AI 工具 — 这 件小事暴露了 Agent 生态的真实现状

这是 什么

掘金平台本周有一 篇开发者日志,作者遇到的问题很具 体:他在使用 AI 编程助手时,给它装了太 多「Skills」(技能插件,可以理解为给 AI 助 手扩展能力的功能模块,类似手机 装 App),结果这些插件的说 明文字挤占了 AI 的「工作记 忆」,反而让 AI 变笨了。

他的解 法是:自己设计了一套文件管理结 构,并写了一个命令行工具 hk-skill,可以完成 插件的拉取、安全审查、适配、注册、按项目启用等一 整套流程。整个工具已开源。值 得注意的是,这套工具本身也是用多个 AI 模型协 作写出来的——他在文中详 细记录了用 GPT、Kimi、GLM 等不同模型承担不 同角色(规划、执行、审查)的分工经验。

行 业怎么看

这件事触碰到了 AI 工具 圈一个真实的结构性困境:插件和工具越 来越多,但「管理这些工具」的基础设施几 乎是空白的。目前主流 AI 编程助手( Cursor、Claude Code 等)的插件生态还处于「野生生 长」阶段——没有统一的版本管理、没有安全审查标准、没有 跨项目的启用控制。这位开发者踩到的坑,任何重 度使用 AI 编程工具的团队都会遇到。

不过,我 们也需要指出这篇文章的局限性。这是一个个 人项目的开发日志,工具的稳定性、可维护性 尚未经过验证,作者自己也坦承「 刚开始只是当作小工具在开发」,因为缺少规范文档导致后期 AI 的调用成本(token 消耗)急 剧上涨。更重要的是,他提出的解法(本 地文件结构 + 符号链接)是一种偏向开发者的手工 方案,对非技术背景的使用者几乎没有可 操作性。这类「开发者自救 工具」能否真正演化成通用产品, 历史上失败的案例远多于成功的。

文中另 一个值得单独拎出来的观察是他对多 模型协作的描述:用 GPT 做规划和审查、用 Kimi 做 执行,效果优于单一模型。这个经验目前还是个 人感知,缺乏量化依据,但与 我们此前观察到的行业趋势吻合——不 同模型在不同任务类型上的优劣差异正在被有 经验的用户主动利用。

对普通人 的影响

对企业 IT:如 果你们团队已经在规模化使用 AI 编程工 具,「插件/提示词的版本管理」应该进 入你的技术债务清单。这不是小 问题,它会直接影响 AI 辅助开 发的稳定性和可复现性。

对个人职场:这篇文章最实 用的部分不是工具本身,而是作者总结的教训—— 「设计文档一定要配套技术方案,省了后面更亏」 。这个道理在 AI 辅助工作流中同样成立:越想 省略前期规范,后期的 返工成本越高。

对消费市场:AI 插件管 理混乱的问题,终将催生商业产品来 填补。谁先做出「AI 工 具的应用商店 + 包管理器」, 就有机会成为新一代开发者基础设施的入 口——这个位置目前还没有明确的竞争者 。

来源: juejin.cn