提交到nongnu 有个好处就是它是emacs 的默认插件库，用的人可以直接安装。
nongnu的规定我好像不太符合，因为我会下载另外一个 repos 的 release
可以先试一下，那边维护者很积极，比melpa 都积极，应该会给个建意，然后再权衡吧
1 个赞
\老婆好厉害/
我盲猜是因为ai的代码生成能力太强，维护者看不过来，维护者不愿意用ai进行审阅，有种被ai夺权的感觉。编程的逻辑改变了，就像高级语言取代汇编一样，自然语言也会取代高级语言，编程者也能在自然语言中玩味逻辑的。ai和emacs的共同点都是追求高度定制，不同点在于emacs有一个“付出感”的体验过程更加真实，ai是直接的结果，没有了体验过程的结果就像是看电视，有画面，没有在场感。
1 个赞
mcp有外部控制能力，但是skill纯靠模型自觉，且在安全风险日益被重视的情况下，类mcp方案（AI的外围控制系统）的工程化思维在skills热之后，一定会蓬勃发展，归根结底，我觉得还是因为AI不是一切问题的根本解，还是得配套完善的落地工程方案，这也是AI发展过程中必须经历的虚与实吧。
就像虽然emacs很老了，但是可扩展，与时俱进的理念永远不老一样。
1 个赞
是好事也是坏事。门槛降低，个性化软件越来越多，也可能是垃圾越来越多……
1 个赞
很不错,能开个B站视频教程吗?
1 个赞
mcp 比 skill+cli 的优点：有一个完整的 tool call schema ，并且带参数类型的。而 CLI 就是纯自然语言描述。 mcp 的缺点：浪费 token。很多时候完整的 tool schema 其实是杀鸡焉用牛刀。用 cli + 自然语言描述下文档，足够 AI 用了，而且 AI 用 bash 用的非常好，它用 bash pipe 很多时候比调用封好的死板的 tool schema 更灵活。
还有就是也和工程实践上有关系。skills+cli 可以非常自然的渐进式按需加载。因为无非就是一堆 prompt 然后让 AI 照着文档调用 bash。MCP 目前的主流 agenet 的实现都还是在一开始就完整的全部装载到上下文里面，动态加载没有 skill 做起来那么简单。另外也和当前的 LLM 在实现 tool call 的方式有关，大部分（基本所有？） LLM 都把 tool schema 都全部放在最前面的 system prompt 里面，导致一旦 tools schema 发生动态改变，缓存就会失效，这样 token 的价格会高很多。
最后我说下我的观点，我个人认为 MCP 确实越少越好。Skills + Cli 的方式其实对于 AI 来说确实是更 natural 的方式。MCP 只在需要严格的 tool schema 精确控制不能犯错的时候才有必要。
2 个赞
是个好主意，我列到计划里
最近太忙了，又要换工作，又要做手术，还要学新技术栈。AI出来了，非但没觉得轻松，反而更忙了啊 
我当时想的就是这个。另一个就是大家说mcp的优点时最常谈起的就是安全，可是Lisp哪里有安全可言呢（
自由与安全不可同时拥有，这个我也有体会了，我的 以web的形式使用org-mode 的项目感觉始终达不到可以公开发表的程度，就是因为安全性基本为0。
一开始就没有考虑过任何安全相关的问题，如果不开源仅自用可以不需要安全，到最后需要考虑安全问题的时候就傻眼了
1 个赞