/tags/ai-agent/ Recent content in ai-agent on Hugo -- gohugo.io en Wed, 06 May 2026 10:00:00 +0800 /posts/agent-skills-spec-and-evals/ Wed, 06 May 2026 10:00:00 +0800 /posts/agent-skills-spec-and-evals/ 至少从 2025 年下半年到我写这篇（2026-05-06）这段产品叙事看，“Agent Skills"是一个在 AI 工具圈快速升温的概念：Anthropic 在 Claude / Claude Code 里推它，Cursor、GitHub Copilot、Gemini CLI、OpenCode、Goose、Roo Code 等一批工具也陆续宣布支持，agentskills.io 则把它整理成了一个开放标准。至少在叙事层面，它确实有点像 AI 工具圈想长出来的一个"USB-C 接口”。 但热闹归热闹，更冷静的那一面是：skill 真的有用吗？什么时候有用？怎么知道它有用？ 这一篇我把三份资料串起来聊一下： agentskills.io 给出 skill 的开放定义和加载机制； SWE-Skills-Bench 用基准实测提醒我们：公开 skill 在真实仓库里未必会带来增益； Angular 社区开发者 Daniel Sogl 那篇 Skills Without Evals Are Just Markdown and Hope，把 skill 的两种隐性失败模式说得很透。 我现在更愿意把 skill 拆成两个层面来看：规范层面，它解决的是上下文如何按需分发；工程效果层面，它解决的是这份指令包能不能在你当前仓库里产生净增益。 前者解释它为什么会流行，后者决定它值不值得进你的工作流。 Agent Skills 是什么 按照 agentskills.io 的定义，一个 skill 本质上就是一个文件夹 + 一个 SKILL.md： my-skill/ ├── SKILL.md # 必需：metadata + 指令 ├── scripts/ # 可选：可执行脚本 ├── references/ # 可选：参考文档 ├── assets/ # 可选：模板、资源 └── . /posts/claude-code-harness-vibe-coding-2026/ Sun, 26 Apr 2026 02:00:00 +0800 /posts/claude-code-harness-vibe-coding-2026/ 📦 本文基于的完整项目源码：meirongdev/shop 开场：一次被拒绝的 git push 让 Claude Code 帮我把一批 commits 推到 origin/main，得到的不是成功，是一段克制但毫不含糊的拒绝： Permission for this action has been denied. Reason: Pushing directly to main bypasses PR review; commits should go to a feature branch. 奇怪的是，我的项目 .claude/settings.local.json 里有 142 条 Bash(...) allow 规则，却没有任何 deny；用户级 ~/.claude/settings.json 也只配了 permissions.defaultMode: "auto" 一行。这条拦截看起来是凭空冒出来的——但它的措辞具体到了"PR review"和"feature branch"，又像是某个真人写过的策略。 这篇文章想顺着这条具体的拒绝信息往下挖：到底是哪一层在拦？为什么 2026 年的 AI 编码 agent 普遍都在补这种"边界"设计？vibe coding 失控时的代价可能有多大？业界其他 agent 又选择了哪些不一样的取舍？ 文中尽量给出我能找到的引用，并优先保留我这次还能访问到的 URL。 一、拦截到底是哪一层做的？ Q：先验证一下，是不是有人写了 deny rule？ 我把 settings 翻了一遍，没有 deny。Claude Code 的官方权限文档写得很清楚：deny rules 是最高优先级，但没有内置的"危险命令"自动阻止列表——rm -rf /、git push origin main 之类都不在 hardcoded blacklist 里。换句话说，这个拦截不来自某个静态规则。 /posts/git-worktree-study/ Fri, 20 Mar 2026 22:15:00 +0800 /posts/git-worktree-study/ 最近在使用各种 AI Coding Agents（如 Claude Code, Gemini CLI）进行开发时，我发现它们在后台处理复杂任务时，经常会用到 “Worktree”。于是我顺手补了一轮 Git Worktree 的基础知识，也想弄清楚这些工具为什么偏爱它。 那么，到底什么是 Git Worktree？为什么这些工具和一些开发者会愿意用它？ 1. 什么是 Git Worktree？ 简单来说，git worktree 允许你在同一个仓库中同时拥有多个工作目录。 “平行宇宙”模型 通常情况下，一个 Git 仓库只有一个工作目录（Working Directory）。当你执行 git checkout branch-b 时，Git 会直接修改你当前目录下的所有文件。如果你当前的代码还没写完（比如正在进行一项复杂的重构），你就得先执行 git stash 或者临时提交一个不完整的 commit，才能切换分支去修 Bug。 而 git worktree 就像是为你创建了多个“平行宇宙”： 主工作目录 (Main Worktree)：你通过 git clone 或 git init 创建的那个原始目录。 链接工作目录 (Linked Worktree)：你通过 git worktree add 创建的其他目录。 这些目录共享同一个 .git 文件夹（包括对象库、提交历史等），但它们各自检出了不同的分支，且互不干扰。 2. Worktree vs. Clone vs. Checkout 为了更直观地理解，我们可以通过下表进行对比： 特性 git checkout git clone git worktree 存储方式 单一目录切换 独立副本 多目录共享 .