寫東西只為了抒發,一切隨緣不為流量
有事找 @finalfantasty
👻 個人博客 Blog: https://blog.pdzeng.com
👻 個人微博客 Blog:
https://daily.pdzeng.com/
有事找 @finalfantasty
👻 個人博客 Blog: https://blog.pdzeng.com
👻 個人微博客 Blog:
https://daily.pdzeng.com/
Telegram 已修復並成功回覆。總結修了兩個地方:
1. server.ts 第 35 行:=== undefined → !process.env[m[1]],讓空字串也被 .env 覆蓋(根因修復)
2. .zshrc 第 148 行:加了 || unset TELEGRAM_BOT_TOKEN,Keychain 取不到時不留空字串(防禦性修復)
注意:plugin 更新時 server.ts 的修改會被覆蓋。如果之後更新 plugin 又壞了,有 .zshrc 的修復兜底。
1. server.ts 第 35 行:=== undefined → !process.env[m[1]],讓空字串也被 .env 覆蓋(根因修復)
2. .zshrc 第 148 行:加了 || unset TELEGRAM_BOT_TOKEN,Keychain 取不到時不留空字串(防禦性修復)
注意:plugin 更新時 server.ts 的修改會被覆蓋。如果之後更新 plugin 又壞了,有 .zshrc 的修復兜底。
truongduy2611/app-store-preflight-skills
🔗 https://github.com/truongduy2611/app-store-preflight-skills
#github
🔗 https://github.com/truongduy2611/app-store-preflight-skills
#github
▶️ Claude Code 从 0 到 1 全攻略 —— MCP / SubAgent / Agent Skill / Hook / 图片 / 上下文处理/ 后台任务 / 权限 ...... #youtube
https://www.youtube.com/watch?v=AT4b9kLtQCQ
https://www.youtube.com/watch?v=AT4b9kLtQCQ
每當你看到一個很有聲量甚至於很有傳播度的文章或是專案,你得去問問,這對我有用嗎?他為什麼這麼出圈?
探索本質的過程中,你會學習到一些東西,例如
gstack skills 相當於透過 gary tan 的哲學來協助你做出決策跟判斷,單純的使用會得到 gary tan 十幾年的工作經驗,相當於找他當顧問
那要怎麼活用這些技能在你的工作上,每個東西你都需要嗎?
不,但是這些你得自己探索
探索本質的過程中,你會學習到一些東西,例如
gstack skills 相當於透過 gary tan 的哲學來協助你做出決策跟判斷,單純的使用會得到 gary tan 十幾年的工作經驗,相當於找他當顧問
那要怎麼活用這些技能在你的工作上,每個東西你都需要嗎?
不,但是這些你得自己探索
OpenAI 宣布将收购 uv、Ruff 等工具的开发商 Astral,整合 Python 开发工具至 Codex 生态OpenAI 宣布将收购开源 Python 工具开发商 Astral,后者开发的 uv、Ruff 和 ty 等工具支撑着数百万开发者的现代 Python 工作流。交易完成后,Astral 团队将加入 OpenAI 的 Codex 团队,其开源工具链将被整合进 Codex 生态系统,使 AI 代理能够直接调用开发者日常依赖的工具,覆盖从代码规划、修改到验证和维护的完整软件生命周期。
目前 Codex 自年初以来已实现用户量 3 倍增长和使用量 5 倍增长,每周活跃用户超过 200 万。此次收购尚需获得监管批准,完成前 OpenAI 与 Astral 将保持独立运营。
OpenAI
🚀 在花频道|社区讨论|投稿通道
技术圈的风向变得比天气还快。几个月前,模型上下文协议(MCP)还是人人都想上的船,转眼间,风评急转直下,鼓吹“MCP已死,CLI万岁”成了新的政治正确。
很多人被表象迷惑了。他们说,MCP臃肿、消耗大量上下文,远不如简单直接的命令行(CLI)来得高效。经验丰富的老炮们甚至不屑一顾:“这玩意儿看起来就像垃圾,那它就是垃圾。”
这种论调听起来很酷,但可能完全搞错了重点。
是的,如果AI智能体要用的工具是`git`或`curl`这种早已刻在模型“肌肉记忆”里的命令,那用CLI当然省事。但如果你用的是一个自定义工具呢?智能体照样需要一份说明书(`--help`或者`SKILL.md`)来学习,所谓的Token优势瞬间荡然无存。整个OpenAPI schema塞进上下文的场景,并不少见。
这场争论的真正分野,不在于技术,而在于开发的组织形态。它区分了两种开发者:单打独斗的“感觉编程”(vibe-coding)信徒,和面向组织的“智能体工程”(agentic engineering)实践者。
对于前者,MCP确实显得多余。但对于一个10人以上的团队,问题就变了:如何保证不同技术栈的工程师用不同智能体得到一致的结果?如何管理密钥、做权限控制?如何追踪哪个工具有效、哪个在拖后腿?
这才是MCP真正发力的地方——不是本地`stdio`模式的小打小闹,而是作为中心化服务器通过HTTP提供的服务。它把认证(Auth)、安全(Security)、遥测(Telemetry)这些麻烦事一揽子解决了。工程师离职?吊销他的OAuth令牌即可,他从未接触过核心密钥。这对于任何依赖GitHub Actions这类临时运行环境的团队来说,更是刚需。
更有趣的是,连Anthropic和Cloudflare都发现,让LLM直接调用MCP,不如让LLM“写代码去调用MCP”来得更稳、更省。Anthropic的“程序化工具调用”甚至能节省高达98.7%的Token。这说明,MCP的价值在于提供了一个稳定的、可被机器理解的“契约”,而不是一个手感舒适的“玩具”。
所以,当人们在激烈争论MCP和CLI的优劣时,他们实际上在无意中暴露了自己的立场:他们究竟是在构建一个随时可丢弃的个人项目,还是在为一个需要长期维护、多人协作的系统打地基?这根本是两条路线的斗争。
这已经不是技术选型问题,而是工程成熟度问题。当你的智能体应用开始考虑“人”的因素——团队协作、权限、审计、迭代——你会发现,你需要的不是一个更“聪明”的工具,而是一个更“笨”、更稳固、有明确边界的协议。那些嘲笑MCP的人,可能还没遇到需要为AI代码擦屁股的烦心事。