一个插件标准，七个工具共用

图：Open Plugins 标准——装一个就能在七个工具里用

最近 AI 编程工具越来越多：Cursor、Claude Code、Codex、Grok Build……每个一套插件格式。然后冒出了个 Open Plugins。

它是 Vercel Labs 维护的一个开放标准。装一个插件，就能在七个工具里跑。

用过 Claude Code 做复杂任务的，八成遇到过这种事——

让 AI 把 fetch 全换成 axios，泡了杯咖啡回来，发现它改了三四个文件就停下来等你点头。反复七八次，一杯咖啡都凉了

或者睡前跑了 /loop 盯 PR，早上发现它凌晨两点卡在 git merge 冲突上，窗口占了一整夜

或者开了三个 sub-agent 各查各的——完事三个结论互相矛盾，因为它们都没看到对方在做什么

根不在 AI 不够聪明。Claude Code 是回合制的——每轮只能做一件事，做完等你决定下一步。想让它持续运行、自动决策、并行工作，就得靠产品层面的编排机制来弥补

Claude Code 给了五个：/goal、/loop、sub-agent、Agent Teams、Workflows

选错了不仅浪费 token，还会把事情搞得更复杂

这篇文章帮你搞懂四件事：① Codex 是什么、能干什么 → ② 五分钟上手做个能玩的小游戏 → ③ 基本用法和核心功能 → ④ 接低成本的国产开源模型，把做好的应用发布上线，让别人能访问。

赶时间？ Codex 现在能接 DeepSeek、GLM 这些便宜模型了。想省钱 + 一键部署的，跳到第四步复制一段配置就行。想从头搞懂的，往下读。

前阵子在一台 TencentOS 服务器上配 GitHub CLI——AI Agent 跑在上面，需要通过手机 IM 跟它对话。遇到了一个经典场景：

• 没有浏览器（远程服务器，没图形界面）
• 没有 sudo 权限（只能装到自己 ~/bin）
• 需要 gh 能正常认证、创建 PR
• 关键：不能把 Token 直接发给 Agent——不管走什么通道，Token 一旦进了 Agent 的上下文就会被记录、可能被写入日志、甚至出现在训练数据里

传统 OAuth 流程要在浏览器里跳转。这里行不通。

第一个直觉是手动生成 Personal Access Token，gh auth login --with-token 灌进去。能用，但很麻烦——你要打开 GitHub 设置页、找到 Token 生成页面、选权限、复制、回到终端粘贴。隔几个月 Token 过期了，再来一遍。

我翻了翻 GitHub CLI 文档，发现它默认走的是一条不同的路：Device Flow（设备授权流）。执行 gh auth login --web，终端打印一串验证码，你去另外一台设备上打开 github.com/login/device 输入它，这边自动完成认证。

整个流程不到两分钟。当时觉得——这东西挺聪明的，值得拆开看看里面怎么跑的。

最近折腾 Agent Skills 有一阵子了。实战下来最折磨人的不是 AI 不会写代码，而是它写的代码**"只能活在本地"，以及它总是不听规矩**。

这篇文章主要分享两件事：

1. 让 AI 生成的代码能真正上线 — AI 写的代码 Demo 感十足，一上线就全是安全隐患。问题是 AI 不感知真实的后端底座。
2. 解决"AI 有 Skill 却不爱用"的毛病 — 明明配好了 Skills，AI 却视而不见，非要凭直觉盲干。技能激活率从 20% 硬拉到 84% 的方法。

一开始用 AI 生图的时候，我自己没有太在意风格。Midjourney 默认输出什么样，我就用什么样：光影浓郁、细节饱满、色彩鲜艳。结果配到文章里怎么看怎么不对——不是画得不好，是太像 AI 画的了。

后来我花了不少时间在 prompt 里调参数做减法，试了好几套风格方案，慢慢摸索出一些规律。回头想想，去掉 AI 味的核心其实很简单：做减法、加纹理、扁平化、低饱和度。

下面这三套方案是实战下来最稳的，直接贴 prompt 后缀就能用。

你是否遇到过这样的困扰：用 AI 生成应用时，代码出错了却不知道问什么问题？AI 给了 N 个解决方案，但不知道哪个是对的？

很多非技术人员在用 AI 编程时都会遇到这样的痛点：

• Debug 困难：页面显示异常，但不知道问题出在哪一层（前端？后端？还是部署？）
• 提问不准确：不知道如何描述问题，让 AI 能理解并给出准确答案
• 学习路径模糊：知道需要学一些基础，但不知道从哪开始，学什么才够用

今天，我将为你分享一套系统的方法，从基础概念到调试技巧，再到后端方案，让你从"能生成应用"到"能做出真正可用的应用"。

最近帮朋友看了几个用 AI 做的项目，发现一个有意思的现象：

代码能跑，功能也有，但就是...不能用。

不是技术问题，是别的问题。

最近我的《Kiro Spec 工作流复刻全攻略》爆了，很多朋友私信问我："为什么 Spec 模式这么有效？背后有什么理论支撑吗？"

说实话，这个问题我也思考了很久。直到我看到了 Gojko Adzic 的《实例化需求：团队如何交付正确的软件》这本书，才恍然大悟。

原来，Kiro 的 Spec 工作流背后，是 SBE（Specification by Example）方法论的完美实践。今天就来揭秘这套方法论，解决你的 AI 编程返工问题。

最近研究 Kiro 的推文又爆了，很多朋友私信问细节，所以再来整理一篇文章，系统分享下具体内容和实操方法。