Cloudflare 全面开放自主管理 OAuth：为 AI 智能体与自动化工具解锁 API 访问

前沿哨所

• 即梦AI实战教程：利用DeepSeek与多模态大模型从零创作AI短片

  近日，Linux.do社区发布了一套名为“Ai短片创作-从零基础到实战落地”的综合性视频教程资源，该资源汇集了50余个教学视频，系统地展示了当前国产AI工具在视频生成与创作领域的全流程应用。该教程不仅涵盖了基础的“即梦AI”界面操作与提示词工程，还深入解析了智能画布、图生图等高阶功能。课程内容极具实操性，包含《山海经》异兽变身、萌宠做饭、特工营救等具体案例的制作过程，特别强调了在创作中植入DeepSeek大模型以及Agent模式的应用，展示了从剧本、绘图、配音到最终剪辑的完整商业短剧制作闭环。此外，教程还涉及了即梦AI 3.0至4.0版本的更新迭代对比，详细讲解了多模态大模型在视频生成中的角色一致性保持及对口型技术。这套资源为开发者及创作者提供了利用国产工具链进行低成本、高质量AI影视制作的详细路径。

  事件分析

  这套教程的发布标志着AI视频生成领域正在从单一的模型调用向系统化的工作流协作转变。从技术层面看，教程中涉及的DeepSeek植入与Agent模式解析，反映了业界正在尝试利用强大的推理模型来弥补纯视觉模型在叙事逻辑上的不足，即通过LLM（大语言模型）与CV（计算机视觉）模型的协同，实现更精准的画面控制和复杂的剧情编排。从产业视角来看，通过即梦AI等国产工具，配合AI音乐生成、智能画布等插件化能力，已经能够实现商业级TVC广告、古风短剧及绘本视频的批量生产。这意味着影视制作的门槛正在被技术极大地降低，未来的竞争核心将不再是软件操作，而是提示词编排能力与对多模态模型组合的深刻理解。国产多模态模型在视频领域的快速迭代，正在加速AIGC技术从娱乐化向专业生产力工具的进化。

  💡 核心观点：AI视频制作已进入“Agent+多模态”协同的新阶段，国产工具链的成熟正推动影视内容生产向标准化、流程化及低成本方向快速演进。

  原文链接：Linux.do

  5小时前

• 国产大模型套餐横评：MiniMax、DeepSeek、Kimi 与 GLM 的性价比深度对比

  本文针对国内主流大模型厂商的付费套餐进行了详细对比分析，旨在为开发者和个人用户提供购买建议。评测涵盖了 MiniMax、GLM（智谱）、DeepSeek、Kimi（月之暗面）及 MIMO 五家厂商。在性价比方面，MiniMax 被认为是首选，其 Plus 套餐周额度高达 4 亿 token，Max 套餐更是提供了约 12 亿 token 的海量额度，且搜索功能仅消耗 token 不额外计费，支持多模态生成，非常适合长时间 coding 和多模态开发。GLM 模型编程能力强，但 Lite 套餐额度偏低，且高峰期消耗三倍额度，视觉功能依赖 MCP 转述存在精度损失。DeepSeek 在 API 价格上优势明显，但在套餐模式下，若缓存命中率不高，实际成本并不便宜，且暂不支持视觉。Kimi 被指出额度体验较差，计费规则不透明，不适合作为主力 coding 工具。MIMO 则存在积分换算陷阱，实际可用额度需仔细折算。综合建议是：追求稳定大量使用选 MiniMax，特定强编码场景考虑 GLM，API 调用首选 DeepSeek。

  事件分析

  此次评测反映了国产大模型在商业化落地过程中从“API 价格战”向“订阅服务体系”的转型。厂商们正试图通过打包 token、多模态能力（图像、语音）及搜索功能来构建差异化竞争壁垒。技术层面上，各家在长文本处理和代码生成能力上已趋同，但在多模态交互的稳定性（如 GLM 的视觉转述精度）和高峰期服务调度（如 GLM 的三倍消耗）上仍存在明显差异。DeepSeek 的缓存机制和 MiniMax 的全功能整合策略表明，未来的竞争将不仅是模型能力的比拼，更是资源调度效率和生态整合能力的较量。对于开发者而言，混合使用不同模型以应对不同场景（如代码、多模态、搜索）将成为提升效率的最优解。

  💡 核心观点：大模型订阅制的核心竞争力已从单纯的低价转向高并发下的稳定性与多模态调用的灵活性，单一模型已难以覆盖全场景需求。

  原文链接：Linux.do

  5小时前

• AI Agent接管运维：开源项目Server Security Init实现服务器安全自动化

  针对新手用户在拿到服务器后不知如何进行安全配置的痛点，一项名为“Server Security Init Skill”的开源项目近日在社区发布。该项目旨在利用AI Agent的能力，自动完成Ubuntu/Debian服务器的全流程安全加固与初始化。该项目不仅是一个脚本工具，更被设计为一个AI Agent技能，可以直接将GitHub链接提供给具备Agent能力的AI（如Claude或OpenAI系列），由AI自主读取代码并执行安装。其功能涵盖了服务器安全初始化的完整闭环：首先是身份认证的安全加固，能够自动生成本地SSH密钥对，引导用户完成公钥上传，并验证登录可用性；随后创建具备免密sudo权限的非root用户，并修改SSH端口，彻底禁止不安全的root登录和密码登录方式。在网络防御层面，该Skill会自动配置UFW（Uncomplicated Firewall）防火墙策略，仅保留必要端口的放行规则，并部署Fail2ban防暴力破解工具，同时支持将管理员IP加入白名单以防误封。最后，它还能智能更新本地的SSH config配置文件，实现通过服务器别名直接连接。该项目已在GitHub完全开源，标志着AI技术在DevOps和基础设施自动化领域的实际落地，为开发者提供了一种无需手动编写脚本即可完成复杂系统配置的全新范式。

  事件分析

  该项目的核心价值在于验证了AI Agent从“信息处理”向“系统操作”转型的可行性。与传统的Shell脚本或Ansible Playbook不同，Agent Skill模式将操作逻辑封装为AI可理解、可调用的能力单元。这意味着大模型不再仅仅局限于生成代码片段，而是可以直接作为执行者，介入并控制底层Linux系统的关键配置。从技术角度看，这种模式体现了“意图驱动计算”的趋势：用户只需表达“初始化并加固服务器”的高层意图，Agent便能拆解任务并精准执行chmod、ufw、iptables等底层指令。这降低了服务器安全运维的门槛，同时也引发了对AI操作权限与系统风险的思考。随着此类垂直领域开源技能的积累，Agent生态正在从单纯的对话模型演变为具备复杂工程能力的自动化操作系统，未来有望重构开发与运维的工作流。

  💡 核心观点：AI Agent正从对话助手进化为系统级执行代理，标准化开源技能的涌现标志着运维自动化迈入意图驱动的新阶段。

  原文链接：Linux.do

  5小时前

• Agent Skill 跨工具复用: 目录结构、版本管理与团队共享

  TL;DR: 多工具时代, skill 不该各管各的

  如果你同时在用 Claude Code、Codex、openclaw、hermes 这类 agent 工具, 大概率已经踩进同一个坑: 同一套”让 agent 怎么提交代码””怎么写 commit message””怎么发布到 WordPress”的知识, 被你在四个工具里各写了一遍。改一处, 另外三处忘了同步; 半年后想不起来哪个版本是最新的; 换台机器又得手动拷一遍。

  这不是工具的问题, 是你把 skill 当成了”每个工具的私有配置”, 而不是”独立于工具存在的工程资产”。

  一句话结论: agent skill 本质是纯文本 + 脚本目录, 天然适合用 git 管理、用软链或子模块在多工具间共享一份源、用语义化版本号追踪演进。 把这三件事做对, 你维护的就从”四份会漂移的副本”变成”一份可 diff、可回滚、可团队协作的真相源”。

  下面按这个顺序拆: 先讲清楚 skill 到底是什么、为什么能跨工具复用; 再给标准化目录结构; 然后是一份源多工具复用的几种接法; 接着是 git 版本管理与变更记录; 最后是跨工具迁移的差异点和团队协作流程。

  读之前如果你对 agent 工具本身还没选定, 可以先看 Claude Code vs Codex vs WorkBuddy vs Zcode: AI 编程 Agent 怎么选 和 Codex vs Cursor 额度对比: 价格、限制与选型建议, 把工具盘子定下来再谈复用更有意义。

  一、Agent Skill 的本质: 为什么它能跨工具

  1.1 Skill 不是插件, 是”可被加载的专业知识包”

  很多人第一次接触 skill, 会下意识把它类比成浏览器插件或者 IDE 扩展——一个绑死在某个宿主里、调一套私有 API 的二进制。这个类比会把你带偏。

  以 Claude Code 的 Skill 范式为例, 一个 skill 的核心就是一个文件夹, 里面放一份 SKILL.md。这份 markdown 顶部有 YAML frontmatter, 只需要两个字段就能跑起来:

  ---
  name: commit
  description: 用规范化的 conventional commit 信息创建提交。当用户要求提交代码、写 commit message、整理变更时触发。
  ---
  
  # Commit Skill
  
  ## 何时使用
  当工作区有未提交改动, 且用户要求"提交""commit""存一下"时。
  
  ## 步骤
  1. 运行 `git status` 和 `git diff` 看清改了什么
  2. 按 conventional commit 规范归类: feat / fix / docs / chore ...
  3. 生成简洁的标题 + 必要的正文
  4. 提交前用 `git diff --staged` 复核
  

  注意它的形态: 没有一行宿主专属代码, 全是自然语言 + shell 命令。 这正是它能跨工具的根本原因——它描述的是”做这件事的方法”, 而方法本身不依赖某个特定 agent 的运行时。

  1.2 渐进式加载: description 是检索入口, 不是装饰

  Claude Code 的 skill 有一个关键机制叫渐进式披露 (progressive disclosure): 系统启动时, 并不会把每个 skill 的全文塞进上下文, 而是只加载 name 和 description 两个字段。模型根据当前任务语义匹配到某个 description, 才会去读那份 SKILL.md 的正文; 正文里再引用 references/ 或 scripts/ 时, 又是按需加载。

  这套机制对”复用”有两个直接含义:

  • description 写得好不好, 决定了 skill 能不能被正确触发。 它不是文档摘要, 是检索关键词。要把”什么时候用我”写清楚, 把用户可能说的触发词都覆盖到。
  • 正文和资源按需加载, 意味着一个 skill 可以很厚而不污染上下文。 你可以把长 checklist、模板、参考表都塞进 references/, 平时不占 token, 用到才拉。

  这种”薄入口 + 厚实现”的思路, 和 agent 工程里反复出现的一个判断是同构的: 复杂度应该沉淀进可复用的资产, 而不是困在一次性对话里。关于 harness 和 skill 谁轻谁重的取舍, Agent Harness 不是要安装的软件包 和 Loop Engineering 是 Harness 的局部命名 讲得比较透, 值得对照着读。

  1.3 为什么”纯文本 + 脚本目录”是可迁移的最大公约数

  再看 Codex、openclaw、hermes。它们各自的扩展机制在字段名、加载方式上肯定有差异——Codex 有自己的指令文件与自定义提示约定; openclaw、hermes 这类工具有各自的组织方式。但把它们抽象一层就会发现, 几乎所有 agent 工具的”能力扩展”都落在同一个最大公约数上:

  一段告诉 agent 怎么做某件事的自然语言提示, 加上一组它可以调用的脚本/命令。

  以 hermes 这类偏调度型的 agent 为例, 它的 skill 通常也是走 prompt 描述 + 脚本目录的组织方式; openclaw 这类工具同理。字段叫什么、放在哪个目录、用什么格式声明触发条件, 这些是表层差异; 而”提示 + 脚本”这个内核是共享的。

  这就是跨工具复用在工程上成立的前提: 你维护的真相源应该是这个内核, 而把各工具的表层差异留给一层薄薄的适配。下面所有方法论都建立在这个判断上。

  二、标准化目录结构: 一份 skill 长什么样

  复用的第一步是约定结构。如果每个 skill 的内部布局都不一样, 后面的软链、迁移、版本管理都无从下手。下面是一套被验证可用的标准布局——它向 Claude Code 的 skill 约定看齐, 同时刻意保持”任何工具都能消费”的中立性:

  skills/
  ├── commit/
  │   ├── SKILL.md            # 入口: frontmatter(name/description) + 正文
  │   ├── references/         # 按需加载的厚资料: 规范表、模板、checklist
  │   │   └── conventional-commit-spec.md
  │   └── scripts/            # 可执行脚本, 被正文引用
  │       └── gen-message.sh
  ├── blog-publish/
  │   ├── SKILL.md
  │   ├── references/
  │   │   ├── seo-title-rules.md
  │   │   └── frontmatter-template.md
  │   ├── scripts/
  │   │   ├── build-images.py
  │   │   └── publish.sh
  │   └── assets/             # 静态资源: 模板图、样式片段
  │       └── poster-base.svg
  └── code-review/
      ├── SKILL.md
      └── references/
          └── review-checklist.md
  

  几条约定值得明确:

  1. 一个 skill 一个目录, 目录名即 skill 名, 和 frontmatter 里的 name 保持一致。这样工具扫描目录就能建立索引。
  2. SKILL.md 是唯一入口, 正文尽量短, 把”何时用 / 怎么用 / 边界”讲清楚即可。详细规则下沉到 references/。
  3. scripts/ 放确定性逻辑。 agent 擅长决策, 不擅长精确执行重复步骤。能用脚本固化的(改文件名、调 API、跑校验), 就别让模型每次现写。这点和”把 agent 当决策者、把确定性留给代码”的工程直觉一致, 构建 Agent 和写软件, 是两种工程 对这个边界有专门的讨论。
  4. references/ 是按需加载区。 越厚越好, 因为平时不占上下文。SEO 清单、品牌规范、API 字段表, 都该放这里。
  5. assets/ 放二进制或静态模板, 和会频繁 diff 的文本分开, 避免污染 git 历史。

  这套结构的好处是关注点分离: 决策(SKILL.md)、知识(references)、执行(scripts)、资源(assets)各居其位。换工具时, 你迁移的是整个目录, 而不是从一坨混在一起的配置里抠。

  三、一份 skill 源, 多工具复用

  结构定了, 接下来是核心问题: 同一个 skill, 怎么让 Claude Code、Codex、openclaw、hermes 都能用上, 而只维护一份源?

  核心原则只有一句: 真相源 (source of truth) 唯一, 各工具的目录是它的投影。 不要在每个工具的配置目录里各放一份会各自演化的副本。下面是三种接法, 从轻到重。

  3.1 方案 A: 软链接 (symlink)——最轻, 适合单人多工具

  把所有 skill 集中放在一个独立仓库, 比如 ~/agent-skills/。然后在每个工具期望的目录位置, 用软链指过去:

  # 真相源
  ~/agent-skills/skills/commit/
  ~/agent-skills/skills/blog-publish/
  
  # 各工具消费点, 全部软链到同一份源
  ln -s ~/agent-skills/skills  ~/.claude/skills
  ln -s ~/agent-skills/skills  ~/.codex/skills
  ln -s ~/agent-skills/skills  ~/.config/openclaw/skills
  

  改一处, 处处生效, 因为它们物理上就是同一份文件。优点是零同步成本、改完立即可见; 缺点是软链对某些工具的扫描器不一定友好(有的工具不跟随符号链接), 跨机器要重新建链, Windows 下软链权限也更麻烦。

  适用场景: 单人、同一台开发机、多个工具。这是收益最高、成本最低的起点。本站把自营分站统一管理时也用过类似”一份源 + 多处指向”的思路。

  3.2 方案 B: git submodule——适合多仓库、需要钉版本

  如果 skill 要被多个项目仓库引用, 而且你希望每个项目能钉在某个 skill 版本上(不被上游改动随时影响), 用 git submodule:

  # 在项目仓库里把 skill 仓库挂为子模块
  cd my-project
  git submodule add [email protected]:me/agent-skills.git .agent/skills
  
  # 各工具再软链到子模块目录, 或工具直接读这个路径
  ln -s ../.agent/skills .claude/skills
  
  # 升级时显式拉取并锁定到新 commit
  cd .agent/skills && git pull origin main && cd -
  git add .agent/skills && git commit -m "chore: bump skills to latest"
  

  submodule 的关键价值是版本锁定: 子模块在父仓库里记录的是一个确定的 commit hash。这意味着 A 项目可以用 skill 的 v1.2, B 项目还停在 v1.0, 互不干扰, 升级是一次显式的、可在 PR 里 review 的动作。代价是 submodule 的心智负担确实存在(忘记 --recurse-submodules、游离 HEAD 等老问题), 团队得统一约定。

  3.3 方案 C: 同步脚本——工具不认软链时的兜底

  有些工具就是不跟随软链, 或者要求 skill 必须是真实文件。这时用一个幂等的同步脚本, 把真相源拷贝到各工具目录:

  #!/usr/bin/env bash
  # sync-skills.sh —— 把真相源同步到各工具消费目录
  set -euo pipefail
  SRC="$HOME/agent-skills/skills"
  
  for dst in 
    "$HOME/.claude/skills" 
    "$HOME/.codex/skills" 
    "$HOME/.config/openclaw/skills"
  do
    mkdir -p "$dst"
    rsync -a --delete "$SRC/" "$dst/"   # --delete 保证目标和源一致, 不留孤儿
    echo "synced -> $dst"
  done
  

  rsync --delete 保证目标目录和源完全一致, 不会留下已删 skill 的残骸。把这个脚本挂到 git 的 post-merge hook 或一条手动命令上, 每次更新源后跑一次即可。它比软链笨, 但最通用——任何工具都吃真实文件。

  三种方案不互斥: 常用工具走软链, 个别挑食的工具用同步脚本补齐, 跨项目引用上 submodule。判断标准就一条——永远只有一份会被编辑的源, 其余都是它的只读投影。 这和”不要重复造轮子、把基础设施收敛成一份”的工程主张是一回事, 告别重复造轮子: 为什么 AI Agent 创业不应自研基础设施 把这个取舍讲到了创业层面。

  四、版本管理: 用 git 把 skill 当代码养

  skill 是纯文本, 这意味着它能享受软件工程几十年积累的全部版本管理红利。别浪费这个优势。

  4.1 skill 仓库本身就该是个 git 仓库

  最基本的一步: ~/agent-skills/ 初始化成 git 仓库, 推到远端。这样你立刻获得三件事——历史可追溯(谁在什么时候改了哪条规则)、可回滚(某次改动让 skill 触发变差, 一个 git revert 回去)、可 diff(改动一目了然, 因为全是文本)。

  这正是”纯文本 + git”组合的核心价值。对比一下: 如果你的 skill 是埋在某个工具 GUI 里的配置项, 上面这三件事一件都做不到。

  4.2 语义化版本: 给 skill 打 tag

  当 skill 开始被多个项目、多个人引用时, 引入语义化版本 (SemVer) 就有意义了。约定:

  • MAJOR (2.0.0): 破坏性变更。比如改了 skill 的触发语义、删了某个被脚本依赖的字段、调整了输出格式, 老的调用方需要适配。
  • MINOR (1.3.0): 向后兼容地加能力。新增一个 reference、扩展触发词、加一个可选脚本。
  • PATCH (1.2.1): 修字。typo、措辞优化、修一个脚本 bug, 不改行为契约。

  打 tag 的操作:

  git tag -a v1.3.0 -m "blog-publish: 新增 SEO 标题硬规则 reference"
  git push origin v1.3.0
  

  submodule 引用时, 就可以钉到 v1.3.0 这个 tag 而非游动的 main, 升级变成”从 v1.3.0 到 v1.4.0″这种可读、可评审的动作。

  4.3 CHANGELOG: 让”为什么这么改”留痕

  git 历史记录了”改了什么”, 但”为什么改、改了之后触发效果有没有变好”需要单独留痕。在 skill 仓库根放一份 CHANGELOG.md:

  # Changelog
  
  ## [1.3.0] - 2026-06-26
  ### Added
  - blog-publish: 接入 SEO 标题硬规则 reference, 标题生成前强制过清单
  ### Changed
  - commit: description 补充"存一下""归档"等触发词, 提升命中率
  
  ## [1.2.1] - 2026-06-20
  ### Fixed
  - code-review: 修正 checklist 里一处误导性表述
  

  这件事在 agent 语境下尤其重要。skill 的好坏不像普通代码那样有确定的单元测试, 它的”对不对”体现在触发是否准、产出是否稳。 你改一版 description, 触发率可能上去也可能下去, 这本质是个需要观测的反馈过程。把每次改动和它的意图记下来, 才能在效果回退时定位是哪一次改坏的。

  关于”agent 的效果如何度量”这件事本身就是门学问, LLM 评测的下一步是一张二维矩阵 和 Prompt Learning 的两个反馈圈 提供了两套可以直接借用的视角: 前者讲怎么把评测组织成可读的矩阵, 后者讲提示迭代的反馈闭环, 都能套到”skill 改完怎么验证”上。

  五、跨工具迁移: 差异点在哪里, 怎么处理

  把内核标准化之后, 真正的工作量在处理各工具的表层差异。这里列出迁移时最常踩的几类差异和应对。

  5.1 frontmatter / 元数据格式差异

  不同工具对”这个 skill 叫什么、什么时候触发”的声明方式不一定相同。Claude Code 用 SKILL.md 顶部的 YAML frontmatter(name + description); 其他工具可能用别的文件名、别的字段、甚至别的格式。

  应对: 真相源用一套最表达力强的格式(推荐 Claude Code 的 frontmatter 约定), 迁移时用一个小转换脚本生成各工具要的形态。 不要反过来——不要为了迁就某个工具的弱格式, 把真相源也阉割了。

  5.2 触发机制差异: 自动检索 vs 显式调用

  这是最容易出问题的一类差异。有的工具像 Claude Code 那样靠 description 语义自动匹配触发 skill; 有的工具需要用户显式调用(比如打一个斜杠命令)。

  这两种机制对 description 的要求完全不同:
  – 自动匹配的工具, description 要写得像”检索关键词”, 把所有可能的触发说法都覆盖。
  – 显式调用的工具, description 更像”帮助文档”, 用户已经知道要调它了。

  应对: 把 description 写成自动匹配友好的版本(信息量大的那种总是兼容显式调用), 在迁移到显式调用工具时不需要改。反过来则会丢信息。

  5.3 脚本运行环境差异

  scripts/ 里的脚本依赖的解释器、环境变量、工作目录, 在不同工具下不一定一致。一个在 Claude Code 下 cwd 在项目根的脚本, 换个工具可能 cwd 在别处。

  应对三原则:
  – 脚本内部一律用绝对路径或相对脚本自身定位, 不假设 cwd。
  – 依赖通过环境变量注入, 不硬编码。尤其涉及密钥时, 走 bootstrap 读取, 绝不写死在脚本里。
  – 跨工具差异用一层适配 wrapper 吸收, 别让核心脚本里长出 if 工具==X 的分支。三个以上分支就是设计出问题的信号。

  跨模型/跨 SDK 调用时还有一类隐蔽差异是错误格式不统一, 同一个失败在不同链路下报得五花八门, AI_ProviderSpecificError 报错定位与修复: AI SDK 排错 是一个具体的踩坑样本, 迁移脚本前扫一眼能省时间。

  5.4 能力边界差异

  不是每个工具都给 skill 同等的权限。有的能跑任意 shell, 有的沙箱限制严格; 有的能联网, 有的不行。一个重度依赖 shell 的 skill 迁到受限工具里可能直接哑火。

  应对: 在 SKILL.md 里显式声明这个 skill 的依赖前提(需要 shell、需要网络、需要某个 CLI 已安装)。迁移时先核对目标工具是否满足, 不满足就降级或标记为不可用, 而不是让它在运行时静默失败。

  六、团队共享: 从个人资产到协作流程

  单人复用解决”我自己别重复劳动”; 团队共享要解决”全队用同一套规范, 且改动可控”。

  6.1 集中仓库 + PR 流程

  把 skill 仓库放团队可访问的 git 远端, 任何人改 skill 都走 branch + PR + review。这件事的价值在于: skill 是会直接影响 agent 行为的”准代码”, 一个人随手改了 commit skill 的规范, 全队的提交风格就变了。让它走 review, 和 review 代码同等对待。

  git checkout -b feat/blog-skill-seo-rules
  # 改 skills/blog-publish/references/seo-title-rules.md
  git add . && git commit -m "feat(blog-publish): 加入 SEO 标题硬规则"
  git push origin feat/blog-skill-seo-rules
  # 开 PR, 团队 review 触发效果与措辞后合并
  

  6.2 安全审查: skill 也是攻击面

  这一点必须单独强调。skill 里有 scripts/, 有命令, 有时还有凭据读取逻辑。一个被污染的 skill, 等于让 agent 在你机器上跑了一段你没仔细看的脚本。 团队共享放大了这个风险——一个人引入恶意或粗心的 skill, 影响全队。

  所以 skill 仓库的安全要求不能靠”感觉没问题”:
  – 脚本不硬编码密钥, 走 bootstrap / 环境变量。
  – review 时重点看 scripts/ 里有没有外发数据、有没有读敏感文件、有没有往临时目录写可执行文件。
  – 来源不明的第三方 skill, 先在隔离环境跑过再进主仓。

  “安全要的是证明而不是感觉”这个判断对 skill 同样成立, 安全不是氛围, 是证明 讲的虽然是 prompt 安全, 但”不能靠语义过滤器兜底, 要靠可验证的约束”这个内核, 直接适用于 skill 脚本审查。

  6.3 文档即接口: README + 触发词索引

  团队规模上来后, 别人不知道你这有哪些 skill、什么时候该用哪个。在仓库根维护一份索引, 列出每个 skill 的 name、description 摘要、依赖前提、维护人。这本质是把”文档即接口”落到实处: 一份能驱动别人正确调用 skill 的索引, 才算把这套资产建模完整了。

  6.4 复用的边界: 不是所有东西都该做成共享 skill

  最后一条反向提醒: 不要把什么都做成团队级 skill。高度个人化的工作习惯、一次性的探索脚本, 留在个人层就好。团队仓库里只放真正需要全队一致的东西(提交规范、发布流程、安全 checklist)。skill 太多太杂, 反而增加 description 之间的语义干扰, 让自动触发的工具选错。关于”什么该沉淀、什么该丢”, 选型层面的 AI Agent 框架全景: LangChain/LangGraph/n8n/Dify 等选型指南 给了一个可类比的取舍框架: 先定决策维度, 再决定收口到哪一层。

  七、相关阅读

  把这套方法论放进更大的 agent 工程图景里, 下面几篇可以接着读:

  • Claude Code vs Codex vs WorkBuddy vs Zcode: AI 编程 Agent 怎么选 —— 先把工具盘子定下来。
  • Agent Harness 不是要安装的软件包 —— harness 与 skill 的边界划分。
  • 构建 Agent 和写软件, 是两种工程 —— 为什么 skill 要把决策和确定性执行分开。
  • 把 Agent 送上生产: RAG、工程、安全、评测 —— skill 只是生产化拼图的一块。
  • 开源 AI Agent 调试器 HALO: 利用 RLM 技术实现本地化闭环优化 —— skill 改完后怎么观测闭环效果。
  • AI 信源指南: 收录 Karpathy、Sam Altman 等百余位顶级专家的 X 平台关注清单 —— 跟进 agent 工具演进的信息源。

  如果你是从零搭 agent 开发能力, 技术社区热议: AI Agent 开发的学习路径与资源盘点 适合作为更靠前的入门索引。

  八、FAQ

  Q1: skill 用 markdown 写, 不会因为太”软”而不可靠吗?

  可靠性不来自格式的”硬”, 来自结构和验证。把确定性逻辑沉到 scripts/(那部分是真代码, 可测), 把决策留给 SKILL.md(那部分本来就该是自然语言)。再配上 git 历史和 CHANGELOG, 你对每次改动的效果有迹可循。这比埋在 GUI 里、改了无从追溯的”硬配置”可靠得多。

  Q2: 我只用一个工具, 还有必要搞这套吗?

  值得做的是其中两件: git 版本化和标准化目录。这两件即使单工具、单人也立刻回本——你获得了回滚能力和清晰结构。软链/子模块/同步脚本那部分是多工具才需要的, 单工具可以先不碰, 等你哪天加第二个工具时再补, 成本也不高。

  Q3: openclaw、hermes 这类工具的 skill 格式和 Claude Code 不一样, 怎么共享?

  共享的是内核(提示 + 脚本目录), 不是表层格式。真相源用表达力最强的格式(推荐 Claude Code 的 frontmatter 约定)写一份, 各工具的具体格式用一层转换/适配脚本生成。具体差异在哪、怎么吸收, 见第五节”跨工具迁移”。核心是: 永远不要为了迁就某个工具的弱格式去阉割真相源。

  Q4: 软链、子模块、同步脚本, 到底用哪个?

  按场景: 单人单机多工具用软链(最轻); 跨项目引用、要钉版本用子模块(可锁 commit); 工具不认软链时用同步脚本(最通用)。三者可以混用, 唯一的铁律是——只有一份会被编辑的源, 其余都是只读投影。

  Q5: 团队里怎么防止有人引入有问题的 skill?

  把 skill 仓库当代码仓库管: 改动走 PR + review, 重点审 scripts/ 里的命令(有没有外发数据、读敏感文件、写可执行文件到临时目录), 密钥一律走 bootstrap 不硬编码, 第三方来源先隔离环境跑过再进主仓。详见第六节 6.2。

  九、结语

  agent 工具会一直增加, 这是确定趋势。如果你的 skill 跟着工具走, 每多一个工具就多一份要手动同步的副本, 维护成本是线性甚至超线性增长的。

  换个建模方式: 把 skill 当成独立于工具存在的工程资产——纯文本、可 diff、git 版本化、一份源多处投影。这样每多一个工具, 增加的只是一条软链或一段适配, 边际成本趋近于零。

  落地就三步, 今天就能起: 第一, 把散在各工具里的 skill 收进一个 git 仓库, 按标准目录结构摆好; 第二, 选软链或同步脚本, 让各工具指向这一份源; 第三, 给重要 skill 打上 tag、补上 CHANGELOG。从”四份会漂移的副本”到”一份可维护、可审计、可共享的真相源”, 差的不是工具, 是把它当资产来养的这套习惯。

  6小时前

• 大模型周刊 第 36 期：监管给前沿模型踩刹车，开源在 token 榜上接力

  作者：toy　|　覆盖周期：2026.06.20 – 2026.06.26

  这一周，OpenAI 有三件事砸在同一个窗口里：6 月 24 日和博通一起亮出第一颗自研芯片 Jalapeño，6 月 25 日被白宫要求把新模型 GPT-5.6 慢慢放、一个客户一个客户审批，6 月 26 日又传出可能把 IPO 推到 2027 年、只为守住万亿估值。一家公司一周里同时秀肌肉、被按头、和拖时间，挺少见。

  另一边，开源和中国队没闲着。DeepSeek 的 V4 Flash 把 OpenRouter 的 token 消耗榜冲到第一，Anthropic 则把”蒸馏”官司打到阿里巴巴头上。上周政府刚关停 Fable 5、智谱用 MIT 开源的 GLM-5.2 接住缺口，这周这条线继续往下走。

  我的判断是：前沿模型的瓶颈，正从”能不能做出来”转向”准不准放出来、放给谁”。监管第一次成了模型的产品参数，而这个参数，闭源大厂自己说了不算。

  一、OpenAI：芯片、刹车和延期，挤在同一周

  OpenAI 这周的三条新闻，方向完全相反，却指向同一件事。

  产品/动作清单：
  – 6 月 24 日，和博通联合发布首颗自研 AI 芯片 Jalapeño，专为推理优化，号称在自家模型帮助下 9 个月完成端到端设计，计划年底开始部署。
  – 6 月 25 日，白宫国家网络总监办公室和科技政策办公室出面，要求 GPT-5.6 只发给一小批伙伴，政府”逐个客户审批”放行。
  – 6 月 26 日，《纽约时报》报道 OpenAI 倾向把 IPO 推到 2027 年，CFO Sarah Friar 主推这个节奏，Altman 把”砍掉万亿估值换早上市”称作”想都别想”。

  先说芯片。自研一颗 AI 芯片通常要两三年，OpenAI 把周期压到 9 个月，靠的是让自家模型参与设计。听着很 OpenAI。但要泼盆冷水：Jalapeño 是推理芯片，不是训练芯片，短期内撼不动英伟达在训练侧的地盘。它解决的是”ChatGPT 跑起来太贵”，不是”我能不能训出下一代”。

  再说刹车。这是美国政府第一次在一个前沿模型公开发布之前就出手限制——以前管的是芯片和硬件，这次直接管模型本身。Altman 跟员工说这”不是我们想要的长期模式”。翻译过来：发布节奏第一次不归公司管了，政府点一个客户，你才能开通一个客户。

  市场/开发者反馈： 开发者圈对自研芯片乐见其成，少一层对英伟达的依赖就少一道卡脖子；但对”逐客户审批”普遍犯怵——一个产品发布要走政府审批流，等于把迭代速度交了出去。也有人翻旧账：Anthropic 上周刚被关停 Fable 5，这周轮到 OpenAI 被踩刹车，前沿玩家轮流挨管。

  我的判断： 三条新闻叠在一起看，OpenAI 正从”研究狂奔”切换成”基建玩家”——自己造芯片、守万亿估值、对政府服软。宁可等到 2027 也不肯把估值砍下来，说明它赌的是算力加企业的长线，而不是再靠一两个模型炸场。真正的变量是那只监管的手：当发布要审批、估值要看政策脸色，”快速迭代”这套叙事第一次不灵了。

  

  二、Anthropic：一边喊暂停，一边把蒸馏官司打到阿里

  Anthropic 这周没发新模型，但话题量不小。

  产品/动作清单：
  – 6 月 24 日，公开指控阿里巴巴”明目张胆、非法”地大规模套取 Claude 能力，把上半年那场”蒸馏”官司又往前推了一步。
  – 此前 2 月，它已点名 DeepSeek、Moonshot、MiniMax，称这三家用两万四千多个假账号、累计一千六百多万次对话来”蒸馏”Claude——其中 MiniMax 那轮最大，超过一千三百万次，集中在 agentic 编码上。
  – 月初（6 月 4 日）还通过 Anthropic Institute 发文，呼吁全球协调暂停前沿 AI，理由是模型快要能”自己造下一代”，递归自我改进会让人类失去控制。

  蒸馏是什么？简单说，就是拿强模型的输出当教材，喂给自己的弱模型，让它快速学会强模型的本事。行业里很常见，但几乎所有闭源厂商的条款都明令禁止——你买的是答案，不是拿去训练竞品的许可。Anthropic 给的数字够狠：两万四千个假账号不是”蹭用”，是工业化的批量套取。

  那”呼吁暂停”呢？这里有个不能忽略的时间点：这篇暂停倡议发出来，距离 Anthropic 自己秘密递交 IPO 没几天，公司估值已逼近万亿。一边说”大家慢点、危险”，一边自己冲刺上市——质疑者读出来的是”先把监管聚光灯打到前沿，自己接着跑”。

  市场/开发者反馈： 安全派给暂停倡议点赞，觉得递归自我改进的风险该认真谈；速度派则吐槽这是”用安全叙事做商业护城河”。Tom’s Hardware 干脆点破：呼吁暂停的潜台词，是”在失控之前得先囤够算力”。Anthropic 自己也承认，超过 80% 合入代码库的代码现在由 Claude 写，工程师季度产出是 2025 年前的约 8 倍——这既是它喊危险的证据，也是它自己在加速的证据。

  我的判断： “宪法 AI 加安全优先”在当下监管环境里确实更吃香，但这周这套组合拳暴露了一个矛盾：Anthropic 既是规则的呼吁者，又是规则的受益者。对全球开发者来说，更现实的影响是 Fable 5 还锁着，海外和中国用户用不上最强的 Claude——而每一道这样的墙，都是在给开源递刀子。

  

  三、Google：Gemini 3.5 进了默认位，但留不住人

  Google 这周的两条线，一条往上走，一条往下掉。

  产品/动作清单：
  – I/O 2026（5 月 19 日）之后，Gemini 3.5 Flash 已经是搜索 AI Mode 的全球默认模型，AI Mode 月活过了 10 亿，查询量每季度翻一倍多。
  – 3.5 Pro 在 I/O 上预览，进入内部测试，公开放出大约晚一个月。
  – 6 月 18 日，Gemini 联合负责人、Transformer 论文作者之一 Noam Shazeer 宣布离开 Google，加入 OpenAI。

  10 亿月活是什么概念？意味着 Google 已经把”搜索框”这个最赚钱的入口，整体换成了一个 agent 平台——能帮你订房间、临时搭个界面、在后台 24 小时跑信息代理。对做 SEO、靠搜索流量吃饭的人来说，这是地震：入口逻辑从”给你十条蓝链接”变成”我直接把答案做出来”。

  往下掉的是人。Shazeer 不是普通工程师，他是”Attention Is All You Need”的作者之一，2024 年 Google 花了约 27 亿美元、通过收购 Character.AI 把他请回来。不到两年，人又走了，去了 OpenAI。Altman 调侃说”想和他共事从 OpenAI 第一天就开始了，只是花了十年”。

  市场/开发者反馈： 开发者认可 Gemini 的 agent 工具链和多模态，但对搜索改默认这件事感情复杂——好用是好用，流量焦虑也是真的。Shazeer 走人则被普遍读成 Google DeepMind 的损失：27 亿请回来的核心架构师，说走就走。

  我的判断： Google 在”agent 操作系统”这层的布局其实最全——搜索、Workspace、Cloud 一条龙，10 亿月活是别人羡慕不来的分发优势。但执行偏保守，又留不住顶尖架构师。人才战打到现在，谁能留住写出范式的那几个人，谁就握住下一代的入场券——这一局，Google 输了一分。

  

  四、中国队：上周开源，这周接着抢地盘

  上周智谱用 MIT 开源的 GLM-5.2 接住了 Fable 5 留下的缺口，这周这条线没停。

  智谱（GLM-5.2 余波）： GLM-5.2 是 753B 参数的 MoE 模型，1M 上下文，6 月 13 日发布即 MIT 开源，还在华为昇腾上完成训练、Day 0 适配了一票国产算力。榜单上它在 Design Arena 的编码类目冲到全球第一（Elo 1360，险胜 Fable 5 的 1350），是第一个登顶这个人类盲测编码榜的开源模型；在 Code Arena 前端榜则是全球第二，仅次于 Fable 5。开源模型过去从没在编码人类盲测里压过闭源旗舰，这次破了。

  DeepSeek（本周真亮点）： V4 Flash 上周把 OpenRouter 的 token 消耗榜冲到第一，单周用量涨了 48%，DeepSeek 三款模型一周合计跑了将近 6 万亿 token。价格是它的核武器：V4 Flash 每百万 token 输入 0.09 美元、输出 0.18 美元，比 Claude、GPT 同档便宜一两个数量级。近 6 万亿 token 不是榜单刷分，是真实跑出来的用量——token 密集的场景（agent 长链、批处理、海量改写）现在几乎只剩它这一个理性选项。

  Moonshot： 6 月 8 日传出新一轮融资，寻求最高 20 亿美元、估值冲到 300 亿美元——这是它半年里第三轮，估值从去年底的 40 多亿美元翻了约 7 倍。Kimi K2.6 目前是 OpenRouter 上使用量第二的大模型。

  MiniMax： 1 月已在港股上市、首日翻倍（涨 109%），这周的消息是它在筹备国内（A 股）上市，给烧钱的模型研发再找一个钱袋子。

  市场/开发者反馈： 海外开发者用中国模型用得很活跃，理由朴素——又快又便宜还能自己部署。但”蒸馏”争议一直没断，Anthropic 这周又添了一把火。

  我的判断： 中国队这周是”开源、低价、融资”三件套同时发力，正好卡在海外限制的缝里。DeepSeek 的 token 榜首证明一件事：大规模落地拼的不是榜单第一名，是性价比——便宜两个数量级，用量自己就上来了。智谱拼的是”能自主可控地当主力用”，DeepSeek 拼的是”便宜到没有替代”，两条路都比”再炸一个 benchmark”更接地气。

  

  五、Agent 战场：Hermes 把 OpenClaw 拉下了第一

  模型之外，真正的战场在 agent 框架。

  产品/动作清单：
  – Hermes Agent（美国 Nous Research 出品）从 5 月 10 日起登上 OpenRouter 全球第一，目前每天跑 2240 亿 token，把 OpenClaw 的 1860 亿甩在身后，成了用量最大的开源 agent。
  – 两者路线分叉：Hermes 押”做—学—改”的自我改进环加三层记忆，OpenClaw 押更广的网关生态。OpenClaw 创始人 Peter Steinberger 2 月已加入 OpenAI，项目转给了独立开源基金会。

  这里要纠正一个常见误会：Hermes 不是中国队，Nous Research 是美国的开源团队；OpenClaw 也是社区项目，不是哪家国内大厂的壳。两者之争是”控制平面 vs 运行时”——谁来定义 agent 怎么被驱动、状态存在哪、出错怎么恢复。

  市场/开发者反馈： Hermes 的自学习环和多 agent 任务板受欢迎，社区夸它”能跨轮锁住目标、自己从幻觉里恢复”；OpenClaw 的生态更广、接入更多。争论集中在一个老问题：到底是控制平面值钱，还是运行时值钱。

  我的判断： agent 时代的核心从来不是单个模型，是编排（orchestration）。Hermes 和 OpenClaw 的分叉，是未来多 agent 体系的预演——记忆、技能、目标拼成的完整中枢，比”我接了哪个模型”重要得多。给企业的建议还是那句：按场景混用，别站队站死。模型可以随时换，编排层换起来才真疼。

  本周关键观察

  • 监管成了模型的产品参数。 GPT-5.6 被逐客户审批、Fable 5 还锁着——前沿模型第一次在”上线前”就被政府卡，发布节奏不再归公司管。
  • 闭源每立一道墙，开源就接一波量。 政府关停 Fable 5、限发 GPT-5.6 的同一时间窗里，GLM-5.2 登顶开源编码榜、DeepSeek V4 冲上 token 榜首。这不是巧合，是替代效应。
  • 性价比比榜单第一更能决定落地。 DeepSeek 不争 benchmark 头名，靠便宜两个数量级把一周近 6 万亿 token 的真实用量拿下。
  • 人才战决定下一代范式。 27 亿请回来的 Shazeer 两年后还是走了，核心架构师的流向比模型跑分更早预示风向。
  • 真正的护城河在编排层。 Hermes 超过 OpenClaw 说明：agent 时代谁定义运行时和记忆，谁就握住了换不掉的那一层。

  下周看点

  • GPT-5.6 的”逐客户审批”进展：会不会如 Altman 所说几周内扩大放开，还是继续卡着。
  • OpenAI IPO 时间表是否进一步明确（2027 还是提前），以及万亿估值能不能扛住政策变量。
  • Moonshot 那轮 300 亿美元估值的融资是否落地。
  • GLM-5.2 与各家 agent 生态（Hermes / OpenClaw 等）的实际接入案例。

  ---

  数据来源：CNBC、TechCrunch、Axios、CNN、《纽约时报》（经 Business Standard、Yahoo 转载）、Al Jazeera、Bloomberg、Fortune、Tom’s Hardware、VentureBeat、MarkTechPost、TechRadar、智谱 AI 开放文档、IT 之家，以及 OpenAI、Broadcom、Anthropic、Google 官方博客。

  6小时前

• 技术岗位价值正在重构：实测表明AI已能接管内部工具开发，执行型工作面临淘汰

  一位拥有技术背景的跨境电商创业者在 V2EX 分享了使用 Claude 和 Codex 等大模型工具辅助开发内部工具的深刻观察。据其描述，包括后台页面搭建、数据导入导出、简易报表生成、移动端页面开发以及测试文案调整等大量“技术活”，现在已优先交由 AI 处理。虽然 AI 生成的代码在美观度上未必完美，但其核心价值在于“先能跑、能验证”，有效打破了以往因技术资源排期瓶颈而导致小想法无法落地的困境。该用户指出，从半技术管理者的视角来看，前端、测试、设计乃至部分后端的执行型岗位必将被压缩，尤其是那些“需求明确后照着做”的重复性工作。尽管受限于国内企业流程、权限管理及数据部署的复杂性，全面替代的缓冲期可能较长，但趋势难以逆转。文章强调，技术人员的核心价值正在向业务上游迁移，单纯的代码编写能力不再稀缺，取而代之的是对业务逻辑的理解、需求拆解能力、风险判断力以及设计验收标准和指挥 AI 产出的能力。未来开发者的竞争力将不再体现为“更会写代码”，而是体现为“更懂业务”并能利用 AI 快速交付结果的工程化素养。

  事件分析

  这一现象标志着软件开发行业正从“手工编码”向“AI 辅助编排”加速转型。随着 Claude Code 等工具的成熟，代码生成的边际成本大幅降低，技术执行的门槛被实质性打破。产业层面，这意味着初级开发岗位（如切图、简单CRUD、脚本编写）的生存空间将被挤压，企业对技术人才的需求将从“代码实现者”转向“系统设计者”和“业务解构者”。技术栈的价值链正在重组，能够熟练使用 AI 工具进行快速原型验证并兜底复杂风险的工程师将掌握主动权。这不仅是工具的升级，更是软件工程范式的根本性变革：未来的核心竞争壁垒在于对业务逻辑的精准抽象以及对 AI 产出的有效把控。

  💡 核心观点：编程门槛的急剧降低将开发重心从“代码实现”不可逆地转向“业务决策”，未来属于懂业务并能指挥 AI 的架构师。

  原文链接：V2EX 分享发现

  8小时前