阅读视图

发现新文章,点击刷新页面。

Claude Code 构建完全指南:十大核心功能深度解析

一、创建自定义子代理(Subagents)

1. 是什么

子代理是运行在独立上下文窗口中的专用 AI 助手。每个子代理拥有自己的系统提示、工具访问权限和权限设置。当 Claude 遇到与某个子代理描述匹配的任务时,会自动将任务委派给该子代理,子代理独立工作并返回结果。Claude Code 内置了 Explore(只读代码搜索,使用 Haiku 模型)、Plan(计划模式研究代理)和 general-purpose(全工具通用代理)等子代理,用户也可以创建自定义子代理。

2. 怎么用

创建子代理最简单的方式是在 Claude Code 中运行 /agents 命令,进入交互式界面选择"Create new agent",然后选择作用域(用户级或项目级),输入描述后由 Claude 自动生成配置。也可以手动创建 Markdown 文件,放在 .claude/agents/(项目级)或 ~/.claude/agents/(用户级)目录中:

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---
You are a code reviewer. Analyze the code and provide actionable feedback.

还可以通过 CLI 标志以 JSON 传递临时子代理:

claude --agents '{ "code-reviewer": { "description": "Expert code reviewer.", "prompt": "Focus on code quality and security.", "tools": ["Read","Grep","Glob","Bash"], "model": "sonnet" } }'

3. 使用场景与痛点

子代理解决的核心痛点是主对话上下文膨胀和工具权限失控。典型场景包括:运行测试套件时大量输出占用上下文(委派给子代理后只返回摘要)、需要对代码库进行并行研究(多个子代理同时探索不同模块)、需要强制只读权限(如代码审查只允许读不允许写)、多步骤工作流的链式委派(先审查再优化),以及通过路由到 Haiku 模型来控制 Token 成本。

4. 使用示例

入门示例——只读代码审查器:

---
name: code-reviewer
description: Expert code review specialist. Use immediately after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---
You are a senior code reviewer. Run git diff, focus on modified files, check for readability, error handling, security, and test coverage. Organize feedback by priority: Critical, Warnings, Suggestions.

使用时只需说:"Use the code-reviewer subagent to look at my recent changes."

进阶示例——带持久化记忆的调试器:

---
name: debugger
description: Debugging specialist for errors, test failures, and unexpected behavior. Use proactively when encountering any issues.
tools: Read, Edit, Bash, Grep, Glob
memory: user
---
You are an expert debugger. Capture error messages, identify reproduction steps, isolate failure location, implement minimal fix, verify solution. Before starting, consult your memory for patterns you've seen before. After fixing, save what you learned.

记忆功能使调试器跨会话积累知识——它会记住之前遇到的 bug 模式和修复策略,随着使用越来越高效。

高级最佳实践——带 Hook 验证的数据库查询代理:

---
name: db-reader
description: Execute read-only database queries. Use when analyzing data or generating reports.
tools: Bash
hooks:
  PreToolUse:
    - matcher: "Bash"
      hooks:
        - type: command
          command: "./scripts/validate-readonly-query.sh"
---
You are a database analyst with read-only access. Execute SELECT queries only.

配合验证脚本,通过 Hook 在每个 Bash 命令执行前检查是否包含 INSERT/UPDATE/DELETE 等写操作,退出码 2 阻止执行。这是"工具级允许、操作级限制"的精细控制模式。其他高级实践包括:使用 skills 字段预加载团队编码规范、用 isolation: worktree 在独立 git worktree 中运行子代理避免影响主分支、用 Task(worker, researcher) 语法限制主代理只能生成特定子代理。

5. 适用角色

个人开发者: 创建用户级子代理(~/.claude/agents/)用于个人常用任务,如代码审查、调试、日志分析。推荐从 /agents 交互式界面入手,用 Haiku 模型的 Explore 子代理快速搜索代码库以节省成本。

团队开发者: 创建项目级子代理(.claude/agents/)并提交到版本控制。统一团队的代码审查标准、API 开发规范。使用 skills 字段预加载团队编码规范,确保每个成员使用的子代理行为一致。

Tech Lead / 架构师: 设计子代理体系——为不同任务领域(前端、后端、数据库、安全)创建专门的子代理,使用权限模式和工具限制确保安全边界。利用 memory: project 让子代理积累项目架构知识。

DevOps / CI 工程师: 通过 --agents CLI 标志在自动化脚本和 CI/CD 流水线中动态定义子代理,用于自动化测试、代码扫描、构建验证等。结合 bypassPermissions 模式实现全自动化执行。


二、运行代理团队(Agent Teams)

1. 是什么

代理团队是一项实验性功能,允许多个独立的 Claude Code 实例协同工作。一个会话充当"团队负责人"(Lead),协调工作、分配任务和综合结果;其他"团队成员"(Teammates)各自拥有独立的上下文窗口,可以直接相互通信、挑战彼此的发现。与子代理的关键区别是:子代理只能向主代理报告结果,而代理团队成员之间可以直接发送消息和协作。

2. 怎么用

首先需要启用实验性功能,在 settings.json 中添加:

{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }

然后用自然语言告诉 Claude 创建团队:

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage

Claude 会创建团队、生成共享任务列表、生成成员并协调工作。在进程内模式中用 Shift+Down 切换成员;在分屏模式中(需 tmux 或 iTerm2)每个成员有独立窗格。用 Ctrl+T 切换任务列表视图。

3. 使用场景与痛点

代理团队解决的核心痛点是单一会话的线性工作模式无法高效处理需要并行探索的复杂任务。最强场景包括:并行代码审查(安全、性能、测试覆盖各一个审查员,避免单个审查员的视角偏见)、竞争假设调试(多个成员调查不同理论并相互辩论反驳,避免锚定效应)、新功能多模块开发(每个成员负责一个独立模块不会冲突)以及跨层协调(前端、后端、测试各由不同成员负责)。

不适合的场景:顺序任务、同文件编辑、依赖关系多的工作——这些情况下单会话或子代理更高效。

4. 使用示例

入门示例——并行代码审查:

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

每个审查员从不同角度审查同一个 PR,Lead 综合所有发现。

进阶示例——竞争假设调试:

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses.
Have them talk to each other to try to disprove each other's theories,
like a scientific debate. Update the findings doc with whatever consensus emerges.

辩论式结构是关键——多个独立调查者主动尝试推翻对方的理论,幸存的理论更可能是真正的根因。

高级最佳实践:

要求成员在实施前提交计划审批:

Spawn an architect teammate to refactor the authentication module.
Require plan approval before they make any changes.

成员以只读计划模式工作,提交计划后由 Lead 审批或驳回。可以通过提示影响 Lead 的判断标准,如"只批准包含测试覆盖的计划"。其他高级实践包括:使用 TeammateIdle 和 TaskCompleted Hook 实施质量门禁、保持 3-5 个成员和每人 5-6 个任务的最佳比例、给成员充足的上下文(spawn 提示中包含具体的任务细节而非依赖继承)。

5. 适用角色

个人开发者: 从研究和审查任务开始尝试——审查一个 PR、研究一个库、调查一个 bug。这些任务展示并行探索的价值,又没有并行实施的协调挑战。

团队 Lead / 项目经理: 用代理团队进行全方位的代码审查、架构评估和技术方案论证。通过设定审批流程(require plan approval)控制实施质量。

高级工程师: 用于复杂调试(竞争假设模式)、跨模块重构(每个成员负责一个模块)和大规模代码迁移(并行处理不同组件)。注意 Token 消耗——代理团队的成本随成员数线性增长。

注意: 代理团队目前是实验性功能,不建议在关键生产流程中使用。已知限制包括不支持进程内成员的会话恢复、任务状态可能滞后、每个会话只能管理一个团队。


三、创建插件(Plugins)

1. 是什么

插件是 Claude Code 的打包扩展机制,将技能、代理、钩子、MCP 服务器和 LSP 服务器封装成可分发的单元。每个插件有一个 .claude-plugin/plugin.json 清单文件定义元数据,以及按功能组织的目录结构。插件的技能使用命名空间(/plugin-name:skill-name)来避免多插件之间的冲突。

与独立配置(.claude/ 目录中的文件)相比,插件更适合需要跨项目、跨团队共享的场景——独立配置适合个人实验和项目专属定制,插件适合版本化发布和市场分发。

2. 怎么用

创建插件的步骤:

# 1. 创建插件目录和清单
mkdir -p my-plugin/.claude-plugin
# 2. 编写 plugin.json
cat > my-plugin/.claude-plugin/plugin.json << 'EOF'
{ "name": "my-plugin", "description": "My extension", "version": "1.0.0" }
EOF
# 3. 添加技能
mkdir -p my-plugin/skills/hello
cat > my-plugin/skills/hello/SKILL.md << 'EOF'
---
description: Greet the user with a friendly message
---
Greet the user warmly and ask how you can help.
EOF
# 4. 本地测试
claude --plugin-dir ./my-plugin

在 Claude Code 中运行 /my-plugin:hello 即可使用。可以用 --plugin-dir 标志同时加载多个插件进行测试。

3. 使用场景与痛点

插件解决的核心痛点是扩展功能的碎片化和不可共享。典型场景包括:团队统一工具链(所有成员通过安装同一插件获得相同的代码审查代理、提交工作流和格式化钩子)、社区分享(将自己开发的有用扩展发布到市场让其他人安装)、跨项目复用(一套检查规则不需要在每个项目中重新配置)、以及版本化管理(通过语义化版本号追踪发布和更新)。

4. 使用示例

入门示例——包含一个技能的插件:

创建一个 greeting 插件,包含一个 hello 技能。目录结构:greeting/.claude-plugin/plugin.json + greeting/skills/hello/SKILL.md。使用 claude --plugin-dir ./greeting 加载,然后运行 /greeting:hello Alex 测试。

进阶示例——包含代理、钩子和 LSP 的完整插件:

my-team-plugin/
├── .claude-plugin/
│   └── plugin.json
├── agents/
│   └── security-reviewer.md      # 安全审查代理
├── skills/
│   └── code-review/
│       └── SKILL.md               # 代码审查技能
├── hooks/
│   └── hooks.json                 # PostToolUse 自动格式化
├── .mcp.json                      # 集成 GitHub MCP 服务器
├── .lsp.json                      # TypeScript LSP 配置
└── settings.json                  # 默认设置 {"agent": "security-reviewer"}

设置 settings.json 中的 agent 字段可以让插件在启用时自动激活指定代理作为默认行为。

高级最佳实践:

从独立配置迁移到插件:将 .claude/commands/.claude/agents/.claude/skills/ 的文件复制到插件目录,将 settings.json 中的 hooks 迁移到 hooks/hooks.json,然后用 --plugin-dir 验证一切正常。发布前为插件添加 README.md,使用语义化版本号。注意:不要把 commands/agents/ 等目录放在 .claude-plugin/ 里面——只有 plugin.json 放在 .claude-plugin/ 中,其他目录在插件根目录。

5. 适用角色

个人开发者: 先用 .claude/ 目录中的独立配置快速实验,等稳定后再转为插件以跨项目复用。适合创建个人的提交工作流、代码模板等。

团队 Lead / 平台工程师: 为团队创建统一的插件,包含编码规范技能、代码审查代理和自动格式化钩子。通过项目的 .claude/settings.json 配置团队市场,让新成员加入时自动获取团队插件。

开源 / 社区贡献者: 创建通用插件(如 commit-commands、pr-review-toolkit)并发布到市场,供社区使用。遵循清晰的目录结构和版本号规范。

企业 IT 管理员: 通过托管设置(managed settings)部署组织级插件,确保合规性审查工具和安全检查在所有项目中强制启用。


四、发现和安装预构建插件

1. 是什么

插件市场(Marketplace)是帮助用户发现和安装 Claude Code 扩展的目录。市场本质上是一个包含 .claude-plugin/marketplace.json 的仓库或文件,列出了可供安装的插件集合。Anthropic 官方市场(claude-plugins-official)自动可用,包含代码智能(LSP)、外部集成(GitHub/Slack/Jira 等)、开发工作流和输出风格等类别的插件。用户也可以添加第三方市场或创建团队私有市场。

2. 怎么用

# 浏览官方市场
/plugin                             # 打开插件管理器,进入 Discover 标签

# 安装插件
/plugin install typescript-lsp@claude-plugins-official

# 添加第三方市场
/plugin marketplace add anthropics/claude-code        # GitHub 仓库
/plugin marketplace add https://gitlab.com/company/plugins.git  # Git URL
/plugin marketplace add ./my-marketplace              # 本地路径

# 管理插件
/plugin disable plugin-name@marketplace-name          # 禁用
/plugin enable plugin-name@marketplace-name           # 启用
/plugin uninstall plugin-name@marketplace-name        # 卸载

# 管理市场
/plugin marketplace list                              # 列出所有市场
/plugin marketplace update marketplace-name           # 刷新
/plugin marketplace remove marketplace-name           # 移除(会卸载其中的插件)

插件安装有三种作用域:用户(跨所有项目)、项目(通过 .claude/settings.json 共享给协作者)和本地(仅当前用户当前仓库)。

3. 使用场景与痛点

插件市场解决的核心痛点是手动配置外部工具的复杂性和团队配置不一致。安装代码智能插件后,Claude 在每次编辑后自动获得类型错误、缺失导入等诊断反馈,无需手动运行编译器。安装外部集成插件(GitHub、Jira、Slack)后,Claude 可以直接与这些服务交互,无需手动配置 MCP 服务器。团队管理员可以在 .claude/settings.json 中配置 extraKnownMarketplacesenabledPlugins,让团队成员信任仓库后自动安装指定市场和插件。

4. 使用示例

入门示例——安装代码智能插件:

/plugin install typescript-lsp@claude-plugins-official

安装后,Claude 在编辑 TypeScript 文件时自动获得类型检查——如果引入错误会立即发现并在同一轮修复。按 Ctrl+O 可以内联查看诊断信息。前提:系统需安装对应的语言服务器二进制文件(如 typescript-language-server)。

进阶示例——添加外部集成和工作流插件:

# 安装 GitHub 集成
/plugin install github@claude-plugins-official
# 安装提交工作流
/plugin install commit-commands@claude-plugins-official

之后可以直接说"Review PR #456 and suggest improvements"或使用 /commit-commands:commit 一键暂存、生成消息、创建提交。

高级最佳实践:

配置团队市场自动安装:在项目的 .claude/settings.json 中添加 extraKnownMarketplacesenabledPlugins,让团队成员加入项目时自动获取。启用自动更新以保持插件版本最新(官方市场默认启用,第三方默认禁用)。如果需要禁用 Claude Code 自动更新但保持插件更新,可设置 DISABLE_AUTOUPDATER=trueFORCE_AUTOUPDATE_PLUGINS=true

5. 适用角色

所有开发者: 安装代码智能插件是最基础的增强——给 Claude 实时的类型错误和语法问题反馈,减少编辑后需要手动编译验证的次数。

全栈开发者: 安装外部集成插件(GitHub、Slack、Figma、数据库),让 Claude 能直接从 issue 描述实现功能、集成设计稿、查询数据库。

团队管理员: 配置团队市场,确保所有成员使用相同的插件和版本。通过项目级安装(--scope project)将插件配置提交到版本控制。

初学者: 从 Discover 标签浏览可用插件,安装 learning-output-style 或 explanatory-output-style 获得更好的学习体验。


五、使用技能扩展 Claude(Skills)

1. 是什么

技能(Skills)是通过 SKILL.md 文件为 Claude 添加的指令和能力扩展。技能遵循 Agent Skills 开放标准,可以是参考知识(编码规范、API 文档),也可以是具体任务(部署流程、提交规范)。Claude 可以根据任务上下文自动加载相关技能,用户也可以通过 /skill-name 直接调用。

技能与子代理的区别:技能默认在主对话上下文中运行(共享上下文),子代理在隔离的上下文中运行。技能适合需要共享对话历史的场景,子代理适合需要隔离的场景。

2. 怎么用

创建技能目录和 SKILL.md 文件:

mkdir -p ~/.claude/skills/explain-code

编写 ~/.claude/skills/explain-code/SKILL.md

---
name: explain-code
description: Explains code with visual diagrams and analogies. Use when explaining how code works.
---
When explaining code, always include:
1. **Start with an analogy**: Compare the code to something from everyday life
2. **Draw a diagram**: Use ASCII art to show the flow
3. **Walk through the code**: Explain step-by-step
4. **Highlight a gotcha**: What's a common mistake?

两种使用方式:让 Claude 自动识别("How does this code work?")或直接调用(/explain-code src/auth/login.ts)。

3. 使用场景与痛点

技能解决的核心痛点是重复的指令输入和行为不一致。没有技能时,每次需要 Claude 按特定方式工作都要重新描述需求;有了技能,一次编写,反复使用。典型场景包括:团队编码规范强制执行(API 设计模式、错误处理模式作为参考技能自动加载)、标准化操作流程(部署、提交、PR 创建作为任务技能由用户触发)、自定义代码生成模板(组件创建、测试编写遵循固定结构),以及跨项目知识复用(个人级技能在所有项目中可用)。

4. 使用示例

入门示例——参考型技能(API 规范):

---
name: api-conventions
description: API design patterns for this codebase
---
When writing API endpoints:
- Use RESTful naming conventions
- Return consistent error formats: { "error": { "code": "...", "message": "..." } }
- Include request validation with Zod schemas
- Always add rate limiting middleware

Claude 在实现 API 时会自动加载这个技能,确保遵循团队约定。

进阶示例——带参数和动态上下文的任务技能:

---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Fix GitHub issue $ARGUMENTS following our coding standards.

## Issue context
- Issue details: !`gh issue view $0 --json title,body,labels`
- Recent commits: !`git log --oneline -5`

## Steps
1. Read the issue description
2. Implement the fix
3. Write tests
4. Create a commit

使用 /fix-issue 123 时,!command 语法预先执行 shell 命令获取实时数据,$0 替换为第一个参数。disable-model-invocation: true 确保只有用户手动触发。

高级最佳实践——在子代理中运行技能 + 可视化输出:

---
name: deep-research
description: Research a topic thoroughly
context: fork
agent: Explore
---
Research $ARGUMENTS thoroughly:
1. Find relevant files using Glob and Grep
2. Read and analyze the code
3. Summarize findings with specific file references

context: fork 使技能在隔离的 Explore 子代理中运行,不影响主对话。另一个强大模式是生成可视化输出——技能中捆绑 Python 脚本生成交互式 HTML 文件用于数据探索。其他高级实践:使用 allowed-tools 限制技能中 Claude 可用的工具、用 Skill(commit) / Skill(deploy *) 权限规则精细控制哪些技能 Claude 可以自动调用、SKILL.md 控制在 500 行内并将详细参考材料拆分到辅助文件中。

5. 适用角色

个人开发者: 创建用户级技能(~/.claude/skills/)封装个人工作习惯——自定义提交格式、代码解释风格、调试流程。用 disable-model-invocation: true 保护有副作用的操作(如部署)。

团队开发者: 创建项目级技能(.claude/skills/)并提交到版本控制,统一团队的 API 设计模式、错误处理方式、测试编写规范。新成员无需阅读长篇文档,Claude 自动遵循。

技术培训师 / 导师: 创建教学型技能(如 explain-code),让 Claude 始终用类比、图表和分步讲解的方式解释代码,帮助初级开发者学习。

平台工程师: 通过插件分发技能、通过企业托管设置强制加载组织级技能,确保合规性检查和安全扫描在所有项目中自动执行。


六、输出风格(Output Styles)

1. 是什么

输出风格直接修改 Claude Code 的系统提示,改变 Claude 的响应方式——包括格式、语调和结构。与 CLAUDE.md(作为附加的用户消息)和 --append-system-prompt(追加到系统提示末尾)不同,输出风格会关闭 Claude Code 默认系统提示中与软件工程相关的部分,用自定义指令替代。Claude Code 内置三种风格:默认(高效完成软件工程任务)、解释性(在工作中穿插教育性"洞察")、学习(协作式学做模式,用 TODO(human) 标记让用户自己写代码)。

2. 怎么用

# 交互式选择
/output-style

# 直接切换到指定风格
/output-style explanatory
/output-style learning

创建自定义输出风格,保存为 Markdown 文件到 ~/.claude/output-styles/(用户级)或 .claude/output-styles/(项目级):

---
name: My Custom Style
description: A brief description
keep-coding-instructions: false
---
# Custom Style Instructions
You are an interactive CLI tool that helps users with software engineering tasks.
[Your custom instructions...]

keep-coding-instructions: true 可以保留 Claude Code 默认的编码相关系统提示(如"用测试验证代码")。

3. 使用场景与痛点

输出风格解决的核心痛点是 Claude 的响应方式与用户需求不匹配。有些人需要简洁的执行结果,有些人需要详细的解释以学习。典型场景包括:初学者学习模式(learning 风格让 Claude 不仅写代码还要求你自己实践)、教学演示(explanatory 风格在每个实现决策后插入背景知识)、非软件工程任务(关闭默认的编码指令,让 Claude 专注于写作、分析等)、团队统一输出格式(通过项目级输出风格确保所有人看到相同格式的响应)。

4. 使用示例

入门示例——切换到学习模式:

/output-style learning

切换后,Claude 在帮你完成任务时会添加 TODO(human) 标记,要求你自己实现关键部分,同时分享"洞察"帮助你理解为什么这样做。

进阶示例——创建自定义架构师风格:

---
name: architect
description: Respond with architecture-first thinking. Always discuss trade-offs before implementing.
keep-coding-instructions: true
---
# Architect Mode
Before writing any code:
1. Identify the architectural implications
2. List alternative approaches with trade-offs
3. Recommend an approach with justification
4. Only implement after the user approves

Always think about: scalability, maintainability, testability, and security.
Use diagrams (ASCII art) to illustrate architecture decisions.

高级最佳实践:

理解输出风格与其他扩展机制的区别非常重要:输出风格修改系统提示、始终生效;技能是按需加载的任务指令;CLAUDE.md 是始终存在的上下文补充。最佳实践是用输出风格控制"Claude 如何说",用技能控制"Claude 做什么",用 CLAUDE.md 提供"Claude 需要知道什么"。变更保存在 .claude/settings.local.json,也可直接编辑其他级别设置文件中的 outputStyle 字段。

5. 适用角色

初学者 / 学生: 使用 learning 风格,让 Claude 变成交互式编程导师——不仅帮你写代码,还要求你自己实践关键部分,加速学习。

经验开发者: 使用默认风格或创建极简自定义风格,获得简洁高效的输出,减少冗余解释。

技术 Lead / 导师: 使用 explanatory 风格或创建架构师风格,在代码审查和设计讨论时获得详细的决策背景和权衡分析。

非工程人员(产品、设计): 创建自定义输出风格关闭编码指令,让 Claude 专注于文档编写、数据分析或项目管理任务。


七、使用钩子自动化工作流(Hooks)

1. 是什么

钩子(Hooks)是在 Claude Code 生命周期特定节点执行的用户定义 shell 命令,提供确定性的行为控制——确保某些操作始终发生,而非依赖 LLM 的判断。钩子支持丰富的事件类型:SessionStart(会话开始/恢复/压缩后)、PreToolUse(工具执行前,可阻止)、PostToolUse(工具执行后)、Notification(通知时)、Stop(Claude 完成响应时)、ConfigChange(配置变更时)等。除了命令型钩子外,还有提示型(type: "prompt",使用 Claude 模型判断)和代理型(type: "agent",生成子代理验证条件)。

2. 怎么用

最快的方式是运行 /hooks 进入交互式菜单,选择事件、配置匹配器和命令。也可以直接在配置文件中编写:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

钩子通过 stdin 接收 JSON 事件数据,通过退出码控制行为:0 = 继续,2 = 阻止(stderr 内容反馈给 Claude),其他 = 继续但记录。配置文件位置:~/.claude/settings.json(所有项目)、.claude/settings.json(单项目共享)、.claude/settings.local.json(单项目私有)。

3. 使用场景与痛点

钩子解决的核心痛点是手动重复操作和依赖 LLM 判断的不可靠性。典型场景包括:每次编辑后自动格式化(PostToolUse + Edit|Write 匹配器 + Prettier)、保护敏感文件不被修改(PreToolUse 检查文件路径拒绝 .env、package-lock.json)、桌面通知(Notification 事件触发 osascript/notify-send)、压缩后重新注入关键上下文(SessionStart + compact 匹配器)、审计配置变更(ConfigChange 事件记录到日志文件)。

4. 使用示例

入门示例——桌面通知:

macOS:

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude Code needs your attention\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

保存到 ~/.claude/settings.json,之后每次 Claude 等待输入时都会收到系统通知。

进阶示例——保护敏感文件 + 自动格式化:

创建 .claude/hooks/protect-files.sh 脚本,从 stdin 读取 JSON,用 jq 提取 tool_input.file_path,检查是否匹配 .envpackage-lock.json.git/ 等受保护模式,匹配则 exit 2 阻止。同时配置 PostToolUse 钩子在每次 Edit/Write 后自动运行 Prettier。这样实现了"阻止 + 后处理"的双层自动化。

高级最佳实践——提示型和代理型钩子:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "Check if all tasks are complete. If not, respond with {\"ok\": false, \"reason\": \"what remains\"}."
          }

Skill Seekers 全面指南:让 AI 真正"读懂"你的技术文档

从零基础入门到架构原理深度剖析——一份写给所有 AI 从业者的渐进式技术博客


写在最前面:这篇文章适合谁?

这篇文章按照由浅入深的结构组织,不同读者可以选择适合自己的起始章节。

如果你是对 AI 工具好奇的普通开发者,从第一章开始读,你将在 15 分钟内理解 Skill Seekers 是什么,并完成第一个实际操作。如果你是正在搭建 RAG 管线的 AI 工程师,可以直接跳到第四章和第五章,那里有针对 LangChain、LlamaIndex、向量数据库等场景的最佳实践。如果你是架构师或技术负责人,第六、七、八章从源码层面深入分析了项目的设计哲学、模块架构和工程体系。如果你是想参与开源贡献的开发者,第九章介绍了项目的工程规范与贡献流程。

开源项目地址:https://github.com/yusufkaraaslan/Skill_Seekers/tree/development


第一章:三分钟理解 Skill Seekers

1.1 一个故事开始

假设你是一名前端开发者,刚加入团队,团队技术栈基于 React。你希望让 Claude Code 成为你的"React 专家搭档"——不是那种只知道泛泛基础知识的通用 AI,而是真正了解 React 最新 API、Hooks 最佳实践、Server Components 细节的领域专家。

你面临一个尴尬的处境:React 官方文档有数百个页面,散布在 react.dev 网站上。你总不能一页一页复制粘贴到 Claude 的对话框里吧?即使你这么做了,Claude 的上下文窗口也装不下这么多内容。

Skill Seekers 做的事情,就是帮你把这几百页文档,在 15 分钟之内变成一个 Claude 能直接加载和使用的"技能包"。

打开终端,三条命令:

# 第 1 步:安装
pip install skill-seekers

# 第 2 步:一键抓取 React 文档并生成知识资产
skill-seekers create https://docs.react.dev/

# 第 3 步:打包为 Claude 能用的格式
skill-seekers package output/react --target claude

完成后你的 output/ 目录里会出现一个 react-claude.zip,上传到 Claude 就行了。从此 Claude 就是你的 React 领域专家。

但这只是冰山一角——同一份知识资产还可以导出为 Gemini、OpenAI、LangChain、Cursor 等十多个平台的格式,做一次就够了。

1.2 用一句话定义 Skill Seekers

Skill Seekers 是 AI 系统的"数据层"(Data Layer)——它将散落在文档网站、GitHub 仓库、PDF 文件中的非结构化技术知识,自动转化为各类 AI 系统可以直接消费的结构化知识资产。

你可以把它理解成一个"AI 的翻译官":一边读懂人类的文档,一边把知识翻译成 AI 能高效理解的格式。

1.3 它支持哪些输入和输出?

输入端,Skill Seekers 能从三种来源获取知识。第一种是文档网站——任意在线技术文档,如 React、Django、Godot 等官网文档。第二种是 GitHub 仓库——通过 owner/repo 格式指定,系统会分析代码结构、README、Issues 等。第三种是 PDF 文件——技术手册、API 文档、论文等。

输出端则覆盖了当前 AI 生态中几乎所有主流的消费方。包括 Claude AI(ZIP + YAML)、Google Gemini(tar.gz)、OpenAI / Custom GPT(ZIP)、LangChain Documents(JSON)、LlamaIndex TextNodes(JSON)、Haystack Documents、Pinecone / ChromaDB / FAISS / Qdrant 等向量数据库就绪格式,以及 Cursor / Windsurf / Cline / Continue.dev 等 IDE AI 助手的规则文件。

一次预处理,十六个目标平台,这是 Skill Seekers 最核心的价值主张。


第二章:手把手入门——从安装到创建第一个 Skill

这一章面向完全没有用过 Skill Seekers 的读者,按照实际操作步骤逐一展开。

2.1 环境准备

你需要准备的东西非常少:Python 3.10 或更高版本,Git,以及一台能联网的电脑(macOS、Linux 或 Windows 均可)。

检查 Python 版本:

python3 --version
# 看到 Python 3.10.x 或更高即可

检查 Git:

git --version
# 看到 git version 2.x.x 即可

如果 Python 未安装,macOS 用户可以用 brew install python3,Ubuntu/Debian 用户用 sudo apt install python3 python3-pip,Windows 用户从 python.org 下载安装器(注意勾选"Add Python to PATH")。

2.2 安装 Skill Seekers

最简单的安装方式只需一行命令:

pip install skill-seekers

这会安装核心功能:文档抓取、GitHub 分析、PDF 处理和所有平台的打包能力。如果你需要额外能力,可以按需安装可选组件:

# 如果你需要 Google Gemini 支持
pip install skill-seekers[gemini]

# 如果你需要 OpenAI 支持
pip install skill-seekers[openai]

# 如果你需要 MCP 服务器(与 Claude Code 集成)
pip install skill-seekers[mcp]

# 全部安装
pip install skill-seekers[all]

安装完成后,验证一下:

skill-seekers --help

看到帮助信息就说明安装成功了。

2.3 你的第一个 Skill:5 分钟搞定

我们用一个小型示例开始,避免第一次就等待太长时间。来抓取 Tailwind CSS 的文档,限制为 5 个页面:

skill-seekers scrape \
  --name tailwind-test \
  --url https://tailwindcss.com/docs/installation \
  --description "Tailwind CSS quick reference" \
  --max-pages 5

大约 30 秒后,你会看到类似这样的输出:

Scraping: https://tailwindcss.com/docs/installation
Page 1/5: Installation
Page 2/5: Editor Setup
...
 Skill created at: output/tailwind-test/

看看生成了什么:

ls output/tailwind-test/
# SKILL.md  references/  scripts/  assets/

其中 SKILL.md 是核心知识文件,references/ 目录下是按主题分类的参考文档。

2.4 打包与上传

# 打包为 Claude 格式
skill-seekers package output/tailwind-test/
# ✅ Created: output/tailwind-test.zip

# 或者打包为其他平台格式
skill-seekers package output/tailwind-test/ --target gemini
skill-seekers package output/tailwind-test/ --target langchain

如果你配置了 Anthropic API Key,还可以一步到位自动上传:

export ANTHROPIC_API_KEY=sk-ant-...
skill-seekers package output/tailwind-test/ --upload

没有 API Key 也没关系——拿着生成的 .zip 文件去 claude.ai 的 Skills 页面手动上传即可。

2.5 使用预设配置:更省心的方式

Skill Seekers 内置了 24+ 个框架的预设配置,覆盖了 React、Vue、Angular、Django、FastAPI、Godot 等主流框架。用预设配置更加省心:

# 查看所有可用预设
skill-seekers list-configs

# 直接用预设抓取
skill-seekers scrape --config configs/godot.json

你也可以用交互式模式,系统会引导你一步步完成配置:

skill-seekers scrape --interactive

2.6 create 命令:最智能的入口

skill-seekers create 是项目提供的最便捷命令——它会自动识别你给的是什么来源,并选择对应的处理方式:

# 给一个 URL,自动走文档抓取
skill-seekers create https://docs.django.com/

# 给一个 owner/repo,自动走 GitHub 分析
skill-seekers create facebook/react

# 给一个本地路径,自动分析本地项目
skill-seekers create ./my-project

# 给一个 PDF 文件,自动走 PDF 提取
skill-seekers create manual.pdf

这种"零配置"体验大幅降低了上手门槛——你不需要记住不同的子命令,一个 create 就够了。


第三章:Skill Seekers 解决了什么问题?谁需要它?

理解了基本用法之后,我们退后一步,从更宏观的视角审视这个工具为什么存在。

3.1 AI 时代的"知识注入"难题

大语言模型的能力已经毋庸置疑,但模型本身有一个固有限制:训练数据的时效性。无论是 Claude、GPT-4 还是 Gemini,它们的知识都有一个截止日期。对于快速迭代的技术框架来说,官方文档可能每周都在更新,而模型的训练数据可能已经是半年前的了。

解决这个问题的主流方案有两种。第一种是 AI Skills / Knowledge:将结构化知识直接注入 AI 的上下文(如 Claude Skills、Custom GPTs),让 AI 在回答时能参考这些外挂知识。第二种是 RAG(检索增强生成):将知识向量化存储在数据库中,用户提问时检索最相关的文档片段,拼入上下文后让模型回答。

无论哪种方案,数据预处理都是第一步,也是最脏最累的一步。你需要从各种来源抓取内容、清洗 HTML、提取代码块、识别语言、分类组织、生成元数据……而且每换一个目标平台,格式要求就不一样。

Skill Seekers 将这整个预处理流程自动化了,并且做到了"一次处理、多目标导出"。

3.2 四类核心用户群体

经过对项目功能和文档的深入分析,Skill Seekers 的用户群体可以清晰地分为四类。

第一类:AI Skill 构建者。 这是使用 Claude Skills、Gemini Extensions、Custom GPTs 的开发者或技术写作者。他们的核心诉求是把特定领域的知识"教"给 AI,让 AI 成为该领域的专家助手。痛点在于手动整理文档耗时巨大,且不同 AI 平台要求的格式各异。

第二类:RAG 工程师。 这些是搭建企业级知识问答系统、智能客服、文档检索等 RAG 应用的工程师。他们的核心诉求是获得高质量、带元数据、分块合理的文档数据。痛点在于数据预处理流程繁琐,分块策略难以兼顾精度和上下文。

第三类:AI 编程助手用户。 这些是使用 Cursor、Windsurf、Cline 等 AI 辅助编程工具的开发者。他们的核心诉求是让 IDE 中的 AI 助手深度理解特定框架的最新用法。痛点在于 AI 助手的通用知识不够深入,需要手动维护上下文规则文件。

第四类:技术团队和企业。 这些团队需要将内部文档、私有 API 文档、跨项目知识等统一管理,构建团队级别的 AI 知识资产。痛点在于知识散落在多个系统中,且缺乏统一的预处理和分发管道。

3.3 适用场景全景

根据用户群体,Skill Seekers 的典型使用场景包括以下几类:

框架学习加速: 新入职开发者快速将团队使用的技术栈文档转化为 AI Skill,让 AI 成为"老员工"一样的带教导师。

文档智能检索: 将公司内部文档库转化为 RAG 数据集,搭建内部知识问答系统。

代码助手增强: 为 Cursor/Windsurf 生成精确的框架规则文件,让代码建议更准确。

文档质量审计: 利用冲突检测功能,发现文档与实际代码实现之间的不一致之处。

多源知识融合: 将文档网站 + GitHub 代码 + PDF 手册合并为一个统一的知识资产,消除信息孤岛。


第四章:面向不同用户的最佳实践与示例

这一章按用户群体分别给出详细的最佳实践方案和操作示例。

4.1 AI Skill 构建者的最佳实践

场景:为 Claude 创建一个 Django 专家技能

这是最基础也最常见的使用场景。完整工作流如下:

# 步骤 1:从文档创建知识资产
skill-seekers create https://docs.djangoproject.com/

# 步骤 2:AI 增强——将基础文档升级为专家级技能文件
skill-seekers enhance output/django/ --mode local
# 如果有 API Key,也可以用 API 模式:
# skill-seekers enhance output/django/ --mode api

# 步骤 3:打包并上传
skill-seekers package output/django/ --upload

增强步骤是关键——不经过增强的 SKILL.md 只是文档的简单组织,增强之后的 SKILL.md 会包含 500+ 行的内容,涵盖代码示例、最佳实践模式、快速参考指南和错误排查建议。

进阶:使用工作流预设做专项增强

如果你的 Django 项目对安全性有特殊要求,可以叠加安全增强工作流:

skill-seekers create https://docs.djangoproject.com/ \
  --enhance-workflow security-focus \
  --enhance-workflow api-documentation

这条命令会先执行安全聚焦的增强(审查 OWASP Top 10、认证授权模式等),然后再执行 API 文档增强。两个工作流链式执行,后续工作流会引用前序工作流的分析结果。

项目内置了 64 个工作流预设,覆盖了从 defaultminimalkubernetes-deploymentgraphql-schemacompliance-gdprmlops-pipeline 等极为广泛的领域。你还可以创建自定义预设放到 ~/.config/skill-seekers/workflows/ 目录下。

进阶:多平台批量导出

一次处理,导出到所有平台:

# 批量导出到 Claude、Gemini、OpenAI、Markdown 四个平台
for platform in claude gemini openai markdown; do
  skill-seekers package output/django --target $platform
done

4.2 RAG 工程师的最佳实践

场景:搭建一个基于 LangChain 的框架文档问答系统

RAG 工程师最关心的是数据质量——分块是否合理、元数据是否丰富、代码块是否保持完整。

# 步骤 1:抓取文档
skill-seekers create https://docs.react.dev/

# 步骤 2:导出为 LangChain Documents 格式
skill-seekers package output/react --target langchain
# 生成:output/react-langchain.json

导出的 JSON 文件中,每个 Document 都包含 page_content(文档内容)和 metadata(元数据,包括来源 URL、分类、内容类型等)。你可以直接将其加载到 LangChain 的检索链中。

项目的 examples/langchain-rag-pipeline/ 目录提供了完整的端到端示例。类似地,examples/llama-index-query-engine/ 提供了 LlamaIndex 的集成示例,examples/pinecone-upsert/ 提供了 Pinecone 向量数据库的写入示例。

进阶:使用 Docker Compose 搭建完整 RAG 基础设施

Skill Seekers 的 docker-compose.yml 已经预置了一个完整的 RAG 基础设施:

# 一键启动:CLI 工具 + MCP 服务器 + Weaviate + Qdrant + ChromaDB
docker-compose up -d

这会启动五个容器化服务。skill-seekers 容器是主 CLI 工具。mcp-server 在 8765 端口提供 MCP HTTP 服务。weaviate 在 8080 端口提供 Weaviate 向量数据库。qdrant 在 6333/6334 端口提供 Qdrant 向量数据库。chroma 在 8000 端口提供 ChromaDB。

所有服务通过内部 bridge 网络互联,向量数据库配置了持久化卷。你可以把文档抓取、增强、向量化入库的全流程在容器环境中完成。

进阶:处理超大型文档(10K-40K+ 页面)

对于 Godot、Unity 这类超大型文档,直接抓取会产生巨大的单一文件。Skill Seekers 提供了文档拆分和路由机制:

# 先评估文档规模
skill-seekers estimate --config configs/godot.json
# 📊 Estimated pages: 40,000
# ⚠️ Large documentation detected!

# 使用 router 策略拆分
skill-seekers split --config configs/godot.json --strategy router --target-pages 5000
# 会生成多个子配置:godot-scripting.json, godot-2d.json, godot-3d.json 等

# 并行抓取所有子技能
# (每个子技能独立抓取,可以并行执行)

# 最后生成路由器技能
skill-seekers generate-router --config-pattern "configs/godot-*.json"

路由器技能的 SKILL.md 包含智能路由逻辑——当用户提问时,路由器会根据关键词将问题导向合适的子技能。比如问到"physics"就路由到 godot-physics,问到"shader"就路由到 godot-shaders。

4.3 AI 编程助手用户的最佳实践

场景:让 Cursor IDE 的 AI 深度理解 React

Cursor、Windsurf 等 IDE 的 AI 助手支持加载上下文规则文件,让 AI 在生成代码时参考特定框架的最佳实践。

# 创建 React 技能
skill-seekers create https://docs.react.dev/

# 打包为 Claude 格式(Cursor 使用相同格式)
skill-seekers package output/react --target claude

# 复制到你的项目中
cp output/react-claude/SKILL.md my-react-project/.cursorrules

对于 Windsurf:

cp output/react-claude/SKILL.md my-project/.windsurf/rules/react.md

对于 Cline(VS Code 扩展):

cp output/react-claude/SKILL.md my-project/.clinerules

项目的 examples/ 目录提供了多个真实示例:cursor-react-skill/ 展示了 Cursor + React 的集成方式,windsurf-fastapi-context/ 展示了 Windsurf + FastAPI 的场景,cline-django-assistant/ 展示了 Cline + Django 的用法。

进阶:使用 install-agent 命令一键安装到所有 IDE

# 一键安装到 Cursor
skill-seekers install-agent output/react/ --agent cursor

# 或者安装到所有支持的 AI 编程助手
skill-seekers install-agent output/react/ --agent all

# 预览安装效果但不实际执行
skill-seekers install-agent output/react/ --agent cursor --dry-run

这条命令会自动将 Skill 文件复制到对应 IDE 的配置目录。支持的 Agent 包括 Claude Code(~/.claude/skills/)、Cursor(.cursor/skills/)、VS Code / Copilot(.github/skills/)、Amp(~/.amp/skills/)、Goose、OpenCode、Windsurf 等。

4.4 团队协作者的最佳实践

场景:在 5 人团队中共享内部 API 文档的 AI 技能

Skill Seekers 支持从私有 Git 仓库获取配置文件,实现团队级别的技能共享:

# 注册团队的私有配置仓库
# (通过 MCP 工具,在 Claude Code 中以自然语言操作更为便利)
skill-seekers config --add-source \
  --name team \
  --git-url https://github.com/mycompany/skill-configs.git

# 从团队仓库获取配置
skill-seekers config --fetch --source team --config internal-api

# 正常使用
skill-seekers scrape --config internal-api.json

支持 GitHub、GitLab、Gitea、Bitbucket 四种 Git 托管平台,通过对应的环境变量(GITHUB_TOKENGITLAB_TOKEN 等)进行认证。

场景:多源知识融合——将文档 + 代码 + PDF 合并为单一知识资产

这是企业场景中最有价值的能力之一。以 Godot 引擎为例,其预设配置展示了如何融合文档和代码两个来源:

配置中定义了 merge_mode: "claude-enhanced",然后在 sources 数组中分别配置了两个来源。第一个来源类型为 documentation,指向 Godot 官方文档网站,配置了 CSS 选择器、URL 过滤规则和内容分类。第二个来源类型为 github,指向 godotengine/godot 仓库,启用了深度代码分析、Issue 获取、Changelog 和 Release 信息抓取,以及特定的文件匹配模式(core/**/*.hscene/**/*.cpp 等)。

运行统一抓取后,系统会自动执行冲突检测——发现文档中描述但代码中不存在的 API,或者代码中实现但文档中未记录的功能,并在最终输出中以醒目标注呈现。


第五章:核心功能全景透视

在理解了"谁在用"和"怎么用"之后,让我们系统性地审视 Skill Seekers 的功能全景。

5.1 llms.txt 优先检测:10 倍速度提升的秘密

llms.txt 是一个新兴的约定标准——越来越多的技术文档网站开始提供专门为 LLM 消费优化的纯文本文件。Skill Seekers 在正式爬取之前,会依次检查目标域名下是否存在 llms-full.txtllms.txtllms-small.txt

如果检测到这些文件,系统直接下载解析即可——完全跳过了逐页爬取、HTML 解析、内容提取等耗时步骤。这在实际效果上意味着:原本需要 15 分钟的抓取任务,可能 1-2 分钟就完成了。

这个功能由三个模块协同实现:llms_txt_detector.py 负责探测文件是否存在,llms_txt_downloader.py 负责高效下载,llms_txt_parser.py 负责解析内容结构。

5.2 异步模式:2-3 倍的爬取加速

对于不支持 llms.txt 的网站,Skill Seekers 提供了基于 httpx 异步引擎的加速模式:

skill-seekers scrape --config configs/react.json --async --workers 8

--async 标志启用异步爬取(底层使用 httpx 的 async/await),--workers 指定并发工作者数量。在实际测试中,同步模式需要 15-45 分钟的任务,异步模式只需 5-15 分钟。

5.3 AI 增强工作流:从 75 行到 500+ 行的质变

基础的文档抓取只能生成结构化的参考文件。AI 增强步骤是将"数据"转化为"知识"的关键。

增强过程由 LLM 驱动——系统将抓取到的文档内容作为上下文,让 LLM 分析后生成一份综合性的 SKILL.md 文件。这份文件不是简单的摘要或合并,而是包含了以下几个维度的内容:核心概念和设计理念的阐述、带注释的代码示例和最佳实践、常见错误和解决方案、快速参考索引、以及从基础到进阶的导航建议。

系统支持三个 LLM 平台执行增强——Claude Sonnet 4(通过 Anthropic API 或 LOCAL 模式)、Gemini 2.0 Flash(通过 Google API)、GPT-4o(通过 OpenAI API)。LOCAL 模式的独特之处在于它利用 Claude Code Max 的本地执行能力,无需 API Key 也无需额外费用。

此外,通过 ANTHROPIC_BASE_URL 环境变量,中国大陆用户可以配置 GLM-4.7 等兼容 Claude 协议的国产 API 端点来完成增强。

5.4 冲突检测:文档与代码的一致性审计

当同时从文档和代码两个来源获取信息时,Skill Seekers 的冲突检测引擎会自动识别四类不一致。

红色:Missing in code(高优先级)。 文档中描述了某个 API 或功能,但在代码中找不到对应实现。这通常意味着文档描述了尚未实现的特性,或者该功能已被移除但文档未更新。

黄色:Missing in docs(中优先级)。 代码中实现了某个功能,但文档中完全没有提及。这是最常见的文档欠缺类型。

橙色:Signature mismatch(警告级别)。 同一个函数在文档和代码中有不同的参数列表、类型定义或返回值。

灰色:Description mismatch(信息级别)。 文档描述与代码注释对同一功能给出了不同的解释文字。

这个能力不仅提升了生成技能的可靠性,本身也是一个独立的文档质量审计工具。

5.5 MCP 集成:用自然语言驱动整个工作流

MCP(Model Context Protocol)是 Anthropic 推出的协议标准,用于让 AI 助手与外部工具交互。Skill Seekers 的 MCP 服务器暴露了 26 个工具,分为四类。

核心工具(9 个):list_configs, generate_config, validate_config, estimate_pages, scrape_docs, package_skill, upload_skill, enhance_skill, install_skill。

扩展工具(10 个):scrape_github, scrape_pdf, unified_scrape, merge_sources, detect_conflicts, add_config_source, fetch_config, list_config_sources, remove_config_source, split_config。

向量数据库工具(4 个):export_to_chroma, export_to_weaviate, export_to_faiss, export_to_qdrant。

云存储工具(3 个):cloud_upload, cloud_download, cloud_list。

配置好 MCP 后,你可以在 Claude Code 中直接用自然语言完成一切:

用户:帮我抓取 Svelte 文档并打包为 Claude Skill
Claude Code[调用 generate_config][调用 scrape_docs][调用 enhance_skill][调用 package_skill]
✅ 已创建 output/svelte.zip,可以上传到 Claude

MCP 服务器支持两种传输模式——stdio 模式(用于 Claude Code、VS Code + Cline 的本地集成)和 HTTP 模式(用于 Cursor、Windsurf、IntelliJ 的网络集成,默认端口 8765)。

5.6 断点续传:永不丢失进度

考虑到大型文档的抓取可能需要数十分钟甚至数小时,Skill Seekers 实现了作业恢复机制。系统以可配置的间隔(默认 60 秒)自动保存进度。如果中途意外中断,可以查看并恢复:

# 查看所有可恢复的作业
skill-seekers resume --list

# 从中断处继续
skill-seekers resume github_react_20260117_143022

旧作业会在 7 天后自动清理,不会无限占用磁盘。


第六章:架构原理深度剖析

从这一章开始,我们深入到项目的内部设计中。

6.1 项目代码结构解析

Skill Seekers v3.1.3 的 development 分支采用 src 布局(即源码位于 src/skill_seekers/ 而非项目根目录),这是 Python 社区推荐的现代项目结构,通过 pyproject.toml[tool.setuptools] package-dir = {"" = "src"} 配置实现。

核心源码分为六个子包。cli/ 是最庞大的模块,包含约 75 个 Python 文件和 5 个子目录(adaptors、arguments、parsers、presets、storage),承载了几乎所有的业务逻辑——从爬虫到分析到增强到打包。mcp/ 实现 MCP 协议服务器,将 CLI 能力暴露为 26 个可通过自然语言调用的工具。embedding/ 包含嵌入向量相关的模型(models.py)、生成器(generator.py)、缓存(cache.py)和服务器(server.py)四个模块。workflows/ 存放 64 个 YAML 格式的增强工作流预设。sync/ 处理同步监控逻辑,基于 schedule 库实现定时更新。benchmark/ 提供性能基准测试工具。

6.2 五阶段数据处理管线

Skill Seekers 的数据流遵循一条清晰的五阶段管线:Ingest → Analyze → Structure → Enhance → Export

Ingest(摄取)阶段: 这是整个管线的入口,由三个专用爬取器负责。doc_scraper.py 处理文档网站,内部通过 llms_txt_detector.py 优先检测 llms.txt 快速通道,未命中时退回到基于 BeautifulSoup4 的 HTML 解析模式,markdown_cleaner.py 负责将 HTML 转化为干净的 Markdown。github_scraper.py 处理 GitHub 仓库,采用三流架构(Code / Docs / Insights),其中 Code 流使用 unified_codebase_analyzer.py 进行 AST 级别的深度代码分析,Docs 流提取 README 和文档文件,Insights 流通过 PyGithub 调用 GitHub API 获取 Issues、Labels、Stars 等社区数据。pdf_scraper.py 处理 PDF 文件,底层基于 PyMuPDF 引擎,叠加了三种互补的代码检测方法(字体特征、缩进模式、模式匹配)和支持 19+ 种语言的识别能力。

Analyze(分析)阶段: 这一阶段对原始内容进行深度语义分析。code_analyzer.py 执行 AST 解析(支持 Python、JavaScript、TypeScript、Java、C++、Go),提取函数签名、类结构、方法参数和类型信息。architectural_pattern_detector.py 识别工厂模式、单例模式、观察者模式等设计模式。dependency_analyzer.py 基于 networkx 构建依赖关系图谱。conflict_detector.py 执行前文描述的四级冲突检测。signal_flow_analyzer.py 分析代码中的信号和事件流。config_extractor.py

让 AI 学会"组队打怪"——聊聊微软的 AutoGen 框架

你有没有想过,一个 AI 助手再聪明,终究也是一个人在战斗。它写完代码没人 review,它做完分析没人挑刺,它回答问题也没人帮忙查漏补缺。

但如果让好几个 AI 坐在一起,各管一摊,一个写、一个审、一个改,会怎样?

这就是微软开源的 AutoGen 在做的事情。

一句话说清楚它是什么

AutoGen 是一个用 Python 搭建多智能体应用的框架。说白了,它让你可以创建多个各有分工的 AI 角色,让它们自己聊着把活儿干了。

比如你可以安排一个"写手"负责起草文案,再安排一个"编辑"负责提修改意见,写手改完再让编辑看,来回几轮直到编辑满意为止。整个过程不需要你盯着,它们自己就能协商完成。

这不是什么遥远的概念,装两个包就能跑起来。

怎么装?怎么用?

环境要求很简单:Python 3.10 以上就行。打开终端敲一行命令:

pip install -U "autogen-agentchat" "autogen-ext[openai]"

装好之后,最基础的用法是创建一个带工具的 AI 助手。举个例子,做一个能查天气的智能体:

import asyncio
from autogen_agentchat.agents import AssistantAgent
from autogen_ext.models.openai import OpenAIChatCompletionClient

async def get_weather(city: str) -> str:
    return f"{city}今天 25°C,晴。"

model_client = OpenAIChatCompletionClient(model="gpt-4o")
agent = AssistantAgent(
    name="weather_agent",
    model_client=model_client,
    tools=[get_weather],
)

async def main():
    result = await agent.run(task="北京今天天气怎么样?")
    print(result.messages[-1].content)

asyncio.run(main())

你定义一个普通的 Python 函数,把它扔进 tools 参数里,AI 就自动知道什么时候该调用它。函数签名和注释会被自动转成工具描述,不需要你手动写 JSON schema。

真正有意思的部分:多个 AI 协作

单个智能体只是开胃菜。AutoGen 真正的看家本领是让多个智能体组队工作。

框架内置了几种编排模式,最常用的是 RoundRobinGroupChat——大家轮流发言。你可以设一个终止条件,比如当某个角色说出"通过"这个词就停下来:

from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_agentchat.conditions import TextMentionTermination

team = RoundRobinGroupChat(
    [writer_agent, reviewer_agent],
    termination_condition=TextMentionTermination("通过"),
)
result = await team.run(task="写一段产品介绍文案")

除了轮流发言,还有 SelectorGroupChat,由一个 LLM 来判断下一个该谁说话,适合角色更多、分工更复杂的场景。还有 Swarm 模式,智能体之间可以主动"转交"任务,像客服系统的分级处理一样。

它的架构长什么样

AutoGen 分三层。最底下的 Core 层负责消息传递和运行时调度,属于基础设施。中间的 AgentChat 层是大多数人打交道的地方,预设智能体、团队编排、终止条件都在这一层。最外面的 Extensions 层负责对接各种外部服务,比如 OpenAI 的模型、Docker 代码执行器,以及通过 MCP 协议接入 Jira、Slack 等工具。

这种分层的好处是,你可以只用上层 API 快速出原型,也可以深入底层做精细控制。

还有个不用写代码的选项

如果你不想写代码,AutoGen 还提供了一个叫 AutoGen Studio 的可视化工具。装好之后一行命令启动:

pip install -U autogenstudio
autogenstudio ui --port 8080

打开浏览器就能拖拖拽拽搭建多智能体工作流,适合做快速验证和演示。

适合什么场景

说实话,不是所有任务都需要多智能体。一个简单的问答,一个 AI 就够了,上多智能体反而是大炮打蚊子。

但有些场景确实适合:需要反复打磨的内容创作、多角度的分析研判、有明确流程的任务处理(比如先分类再路由再执行),以及需要调用多种外部工具协同完成的复杂工作流。

核心判断标准就一个:如果你发现自己在不断地把一个 AI 的输出复制粘贴给另一个 AI 让它接着处理,那多半可以用 AutoGen 把这个链路自动化掉。


AutoGen 当前稳定版本为 v0.7.5,项目地址:github.com/microsoft/autogen

Speckit、OpenSpec、Superpowers 和 everything-claude-code AI辅助编程工具对比分析

1. 概述

随着AI编码能力(如 Claude Code、Cursor 等)的普及,软件开发领域正从“Vibe Coding”(随心灵感编码)向更工程化的方向演进。为了应对AI生成代码的不确定性、上下文丢失以及协作一致性等问题,社区涌现了多种规范驱动开发(Spec-Driven Development, SDD)框架和工作流方法论

选取了目前最具代表性的四个项目进行对比:

  • Speckit:GitHub官方出品的结构化规范驱动工具包

  • OpenSpec:专注于增量变更和棕地项目的轻量级框架

  • Superpowers:强调强制流程和TDD的代理技能框架

  • everything-claude-code:黑客松冠军开源的综合性 Claude Code 方法论

2. 核心属性速览

维度 Speckit OpenSpec Superpowers everything-claude-code
核心理念 规范即代码,通过严格的结构化流程实现工业级控制 增量即真相,通过Delta机制管理现有项目的演进 强制方法论,通过不可跳过的“技能”约束AI行为 CLI+Skills替代MCP,通过编排与并行化榨干模型性能
目标场景 绿地项目 (0→1) ,复杂且需要严格文档的团队协作 棕地项目 (1→n) ,在已有代码库上进行频繁修改和功能迭代 从0到1的需求探索,对代码质量、测试覆盖有极高要求的项目 重度Claude Code用户,追求极致Token效率和复杂任务并行处理的场景
工作流程 五阶段线性流程:Constitution → Specify → Plan → Tasks → Implement 四阶段循环流程:Draft Proposal → Review → Apply → Archive 三阶段严格流程:Brainstorm → Write Plan → Execute Plan (含TDD) 五阶段Agent编排:Research → Plan → Implement → Review → Verify
关键机制 9条不可变架构原则、7层LLM输出约束、ADR决策记录 Specs/与Changes/隔离、Delta增量存储、Fail-Fast冲突检测 强制技能调用、Red-Green-Refactor TDD、子代理审查 多Agent编排、并行化(Git Worktrees)、动态系统提示、记忆钩子

3. 详细维度对比

3.1 核心理念与哲学

  • Speckit:秉持“规范优先”的哲学。它假设需求在编码前可以被完全定义,通过类似于法律的“宪章”来约束AI的每一次产出。它将开发视为一个严谨的、逐层分解的工程过程,试图通过结构的确定性来对抗AI的随机性

  • OpenSpec:秉持“演进优先”的哲学。它承认需求是动态变化的,特别是在维护老项目时。其核心理念是将“当前稳定状态”(Specs)与“提议变更”(Changes)分离,每次只处理增量,最终将验证后的增量合并回主干,实现系统的平滑演进

  • Superpowers:秉持“流程即法律”的哲学。它不信任AI的自由发挥,通过一套不可跳过的“技能”(Skills)来强制AI遵循人类软件工程的最佳实践(如必须先写测试)。它像一名“教官”,强制AI按照TDD、Code Review等严谨流程行动

  • everything-claude-code:秉持“效率与编排”的哲学。它将AI视为一个可编排的智能体集群,通过精细化的工程手段(如用CLI替代MCP省Token、多实例并行)来最大化模型性能,降低成本,实现复杂的、多步骤的研发任务

3.2 目标用户与适用项目

  • Speckit:适合中大型团队,特别是需要严格合规、文档齐全的企业级项目。它明确了产品经理、技术负责人、开发者之间的交接点(如Spec、Plan),适合角色分工明确的团队

  • OpenSpec:适合全栈开发者或小型团队,尤其是在维护复杂老系统的团队。对于经常需要跨多个服务或模块进行小范围修改的场景,它的轻量级和高效增量特性极具吸引力

  • Superpowers:适合任何追求代码质量的开发者,尤其是从0到1启动项目时。它的头脑风暴模式对需求不明确的项目非常友好,强制TDD则确保了代码的健壮性

  • everything-claude-code:适合Claude Code的重度用户和技术极客。适合需要处理复杂、多步骤、多文件任务的场景,或是希望在API调用成本上精打细算的开发者

3.3 工作流与落地实践

  • Speckit:流程线性且严格

    • Constitution:定义开发原则和不可变规则

    • Specify:详细描述需求(What & Why)

    • Plan:基于技术栈制定架构方案

    • Tasks:分解为可执行的任务列表

    • Implement:逐一执行任务

      实践发现,若前期需求或设计有误,后期返工成本极高。在动态变化的企业环境中,这种线性流程常面临“理想很丰满,现实很骨感”的挑战

  • OpenSpec:流程循环且隔离

    • Proposal:在 changes/ 目录下创建变更提案、任务和Spec增量

    • Review:人与AI审查、对齐提案,可利用 openspec validate 进行冲突检测

    • Apply:AI严格根据 tasks.md 和增量Spec实施编码

    • Archive:将验证通过的变更合并(归档)到 specs/ 目录,更新“真相源”

      这种模式确保了主分支的Spec始终反映最新状态,且归档动作实现了知识的持续沉淀

  • Superpowers:流程强制且循环

    • Brainstorm:AI通过多轮问答帮助用户精炼需求,探索方案,输出设计文档

    • Write Plan:将设计拆解为极小的任务(2-5分钟),每个任务包含精确的文件路径、代码片段和测试命令

    • Execute Plan:通过子代理或批量模式执行计划,强制遵循 TDD(Red-Green-Refactor) ,并进行代码审查

      任何跳过步骤(如先写代码)的行为都会被AI视为违规

  • everything-claude-code:流程编排且并行

    • 编排:通过 Research AgentPlanner AgentTDD-guide AgentReviewer AgentResolver Agent 的有序协作完成任务。每个Agent输入输出清晰,中间用 /clear 清理上下文

    • 并行:利用 Git Worktrees 创建多个工作目录,同时运行多个Claude实例处理不同任务,互不干扰。采用 Two-Instance Kickoff(一个搭骨架,一个做调研)启动新项目

3.4 优缺点分析

工具/方法论 优点 缺点/挑战
Speckit 结构最严谨,文档最完善,适合大型项目治理;通过ADR记录决策,可追溯性强 。 太重、太理想化。对动态需求适应性差,流程僵化;生成文档冗长(相较OpenSpec多出数倍),上下文窗口易爆,返工成本高 。
OpenSpec 轻量、Token效率高。增量模式对老项目友好;archive机制能反向构建知识库;学习曲线平缓 。 对命名敏感,Delta机制依赖稳定的命名进行匹配;冲突解决依赖人工介入,对认知负担有一定挑战 ;不适合需要顶层宏观设计的0→1项目 。
Superpowers 质量保障最强。通过强制TDD和Code Review,产出代码可靠性高;头脑风暴功能极佳,能深度挖掘模糊需求 。 流程强制带来的“笨重感” 。即使是修个小Bug,也可能触发全套流程(TDD),对于追求快速验证的场景可能显得繁琐 。
everything-claude-code 极致的技术效率。Token优化策略显著降本;并行化和Agent编排极大提升复杂任务吞吐量;开源且模块化,扩展性强 。 上手门槛较高。需要理解其Agent编排、Hooks、Worktrees等整套哲学,对新手不够友好;部分技巧(如记忆钩子)需要手动配置 。

4. 选型建议

根据不同的团队类型和项目阶段,可以遵循以下建议进行选型

  • 如果你是维护复杂老系统的“单人开发者”或“小型团队”

    • 首选 OpenSpec。它的增量哲学能让你在不扰乱现有架构的前提下,安全地嵌入新功能。归档机制能帮你逐步梳理出混乱系统的“隐形文档”
  • 如果你正在启动一个全新的、复杂度较高的项目,且有明确的架构要求

    • 如果你是严谨派,追求工业级的代码质量:可以尝试 Speckit,但要做好前期投入大量时间编写规范的准备

    • 如果你是敏捷派,需求尚在演变中:强烈推荐 Superpowers。先利用其 Brainstorm 功能理清思路,再利用强制TDD构建稳固的核心,体验会非常流畅

  • 如果你是重度AI用户(特别是 Claude Code),追求极致的开发效率和成本控制

    • everything-claude-code 是你的不二之选。学习并采用它的CLI+Skills思想、Agent编排和并行化策略,你将能驾驭AI完成以往需要一个小团队才能完成的复杂任务
  • 如果你在大型团队中协作,需要明确的产品与开发交接流程

    • Speckit 的结构化文档(Constitution, Spec, Plan)可以作为团队协作的契约,明确各方职责,减少沟通误差。但需确保项目需求相对稳定,以避免因变更导致的巨大返工成本

5. 总结

AI编程正从“无序的 vibe coding”走向“有序的工程化”。这四种工具代表了不同的工程化路径

  • Speckit 走的是“计划经济的道路”,通过周密的计划来控制生产

  • OpenSpec 走的是“改革的道路”,在保持系统稳定的前提下,通过小步快跑实现演进

  • Superpowers 走的是“素质教育的道路”,通过严格的训练(流程)让AI养成良好的编码习惯

  • everything-claude-code 走的是“科技强军的道路”,通过先进的装备(编排、并行)和战术配合来发挥AI的最大战斗力

最终的选择没有绝对的对错,关键在于你的项目痛点、团队文化以及对AI协作的期望。希望这份报告能帮助你在这个快速发展的领域中找到最适合自己的方向

刚刚,OpenAI 硬件全家桶曝光!智能音箱内置摄像头+刷脸购物,ChatGPT 要住进你家了

据 The Information 爆料,OpenAI 正在开发一款智能音箱,它将配备摄像头,支持类似苹果 Face ID 的人脸识别。你未来可能「看一眼」就能完成购物支付,类似功能目前在小米 Rokid 等智能眼镜已经实现。

在苹果、Meta 都在把 AI 塞进眼镜、手表、吊坠等可穿戴设备时,OpenAI 尝试把摄像头塞进了音箱,能「看见」你和周遭的环境,AI 对你的理解也将从语言延伸到行为,你的作息、习惯、情绪状态,都将让 AI 读懂和拼凑出一个真实的你。

▲产品假想图,由 Nano Banana Pro 生成

APPSO 先给你快速梳理下 OpenAI 智能音箱的核心信息

  • 定价:200-300 美元(约 1450-2200 元人民币)
  • 发售时间:最早 2027 年 2 月
  • 核心功能:摄像头环境感知、Face ID 级人脸识别、语音购物
  • 设计团队:Jony Ive 的 LoveFrom + OpenAI 硬件团队
  • 产品矩阵:智能音箱首发,智能眼镜、智能灯后续跟进

「长眼」的智能音箱,你敢用吗

智能音箱这个品类,从 Amazon Echo 到 Apple HomePod,已经卷了快十年。但这些设备的「智能」,往往停留在「能听懂关键词」的层面,离真正的「理解」差着十万八千里。

OpenAI 的解法简单粗暴:给它装上眼睛。

智能音箱内置摄像头,能识别你周边环境,比如桌上摆了什么、旁边在聊什么。还支持类似 Face ID 的面部识别,可以直接刷脸完成购买。这种「所见即所得」的购物体验,目前市面上的智能音箱还做不到,

结合 ChatGPT 去年上线的购物功能——用户可以在对话框里完成从选品到跳转下单的完整流程,这个刷脸购买功能将有望直接服务于「AI 即购物入口」的闭环,成为消费决策链条上的第一道关口。

如无意外,这也将对现有流量分发逻辑造成重大的挑战:Google 靠搜索吃了二十年广告红利,电商平台靠货架逻辑构建起庞大生态,而 OpenAI 想在这两者之前再插入一个新的决策层级。

此外,这款智能音箱还能通过持续的视觉观察判断用户状态——比如发现你在重要会议前夜还在熬夜,会主动提醒你去早点睡。这样一来智能音箱的定位,就从一个智能家居产品,变成了一个 AI 管家中枢。

不过,这种全天候的数据采集,隐私边界在哪里,或许有待 OpenAI 正式发布时给出答案。

想要买到这款产品,还要等一段时间。首款设备最早也要到 2027 年 2 月才能发货。眼镜等其他产品更慢,预计 2028 年才能大规模量产,至于那个智能台灯,原型机有了,但到底会不会发布,还是个未知数。

「含果量」十足的 OpenAI 硬件团队

OpenAI 的硬件野心,从团队规模就能看出来,整整 200 人,而且还在疯狂扩张。其中更令人期待的是,前苹果首席设计官 Jony Ive ,亲自为 OpenAI 操刀产品设计。

这支团队的「含果量」极高,团队由副总裁 Peter Welinder 领导,他此前负责 OpenAI 的新产品探索团队。核心成员包括:

  •  Tang Tan:苹果 25 年老将,曾任 iPhone 和 Apple Watch 产品设计主管,直接向苹果硬件主管 John Ternus 汇报,被认为是把 Jony Ive 的设计理念转化为大规模可制造产品的关键人物
  • Evans Hankey:苹果前工业设计负责人,曾接替 Jony Ive 执掌苹果设计团队,现为 OpenAI 工业设计负责人
  • Scott Cannon:供应链负责人
  • Adam Cue:苹果服务主管 Eddy Cue 之子,负责开发驱动 OpenAI 未来设备的软件
  • Ben Newhouse:产品研究负责人,正致力于重写 OpenAI 的基础设施以适应音频 AI
  • Atty Eleti:负责设备隐私相关工程工作

虽然 Jony Ive 并未直接加入 OpenAI,但他对设计拥有最终决定权,据说每周都会出现在旧金山市中心的办公室。有员工透露,团队讨论时经常会说「Jony 会想要什么」。

然而 Jony Ive 和 OpenAI 的合作并非一帆风顺。据两位知情人士透露,一些 OpenAI 员工抱怨 LoveFrom 修改设计的速度缓慢,且很少分享其构思新设计的流程。这种保密作风和对设计的极致追求,是苹果公司的典型做法——而该团队的许多员工和领导层都来自那里。

为了保持这种运作方式,OpenAI 的设备团队与公司其他部门是分开的。虽然 OpenAI 总部位于米申湾,但设备团队在旧金山市中心杰克逊广场附近的一间办公室办公,离 LoveFrom 的办公室不远。

OpenAI 挖人的手段也很「简单粗暴」——直接用超过 100 万美元的股票期权砸人,薪酬远超苹果标准。据 The Information 报道,OpenAI 今年已经从苹果挖走了 20 多位硬件大牛,而 2023 年这个数字几乎为零。

苹果显然坐不住了。据知情人士透露,苹果去年曾突然取消了原定在中国举行的年度闭门会议——这个会议通常由高管向员工介绍未来产品计划。取消的原因竟然是:「防止更多高管跳槽到 OpenAI」。

内部怎么拧,是执行的事。但有一件事,从一开始就没有悬念——OpenAI 必须做硬件。

软件端 200 亿美元的年收入,已经证明了 AI 是一门好生意,但要让 AI 真正成为水电煤一样的基础设施,必须有一个物理入口。手机这条路走不通——苹果的生态护城河不是一款 AI 新品轻易能够撬动的,其它手机厂商自己也在全力 AI 化,不会将大好的硬件阵地拱手相让。

当然,更根本的问题是,手机的形态本身,可能就不适合做 AI 的宿主。

当 AI 足够聪明时,它不应该被禁锢在一块长方形的玻璃屏幕里,它应该是无处不在的。因此,从音箱、眼镜甚至台灯这些陪伴感更强的品类切入,是 OpenAI唯一,也是最合理的选择。而这一切,或许从 ChatGPT 的产品设计方向上就已经埋下了伏笔。

与 Anthropic 这类深耕企业服务的 AI 公司不同,OpenAI 从一开始就带着强烈的 ToC 基因——ChatGPT 不只是一个工具,它有情绪、有记忆、会共情,Sam Altman 一直在让它变得更像一个「人」。

这背后的逻辑,如今看来相当清晰:一个冷冰冰的 AI 助手,你不会想把它放在卧室里;但一个懂你、记得你习惯、会关心你睡没睡好的 AI,才有资格住进你的生活。

OpenAI 的硬件版图浮出水面

智能音箱只是 OpenAI 硬件全家桶的其中一个,此前 OpenAI 已经被曝出在开发智能眼镜、智能灯、甚至可穿戴别针等多种形态。其中智能眼镜可能要等到 2028 年才能量产——这个时间点,恰好和苹果传闻中的 AI 眼镜撞期。

OpenAI 硬件产品线(APPSO 据曝光信息整理)

  • 智能音箱(代号未知):首款产品,200-300 美元,2027 年 2 月出货
  • AI 耳机(代号 Dime/「甜豌豆」):金属鹅卵石造型,胶囊状耳机置于耳后,2nm 芯片
  • 智能眼镜:2028 年量产,与 Meta Ray-Ban、苹果 N50 正面竞争
  • 智能灯:原型已准备,是否发布待定
  • AI 笔:Sam Altman 多次暗示的「口袋设备」

值得注意的是,OpenAI 的硬件策略似乎经历了调整。此前传闻的 AI 耳机项目「Dime」(甜豌豆),原计划是一款「类手机」全能设备,搭载 2nm 智能手机级芯片。但由于 HBM 内存短缺导致成本过高,OpenAI 被迫调整策略——先推纯音频功能的「阉割版」,等成本下降后再发高配版。

这种「先占坑、后完善」的策略,在硬件圈并不罕见。对 OpenAI 来说,也没有苹果的包袱,不需要将产品打磨到完美才推出市场,即便首款产品不够惊艳,这也是 AI 行业发布产品的一贯风格。

此外 OpenAI 不止挖苹果的人,也盯上了苹果花了几十年打造的供应链。

据知情人士透露,中国主要的 iPhone 和 AirPods 代工厂立讯精密已经拿下了至少一款 OpenAI 设备的组装合同,而负责组装 AirPods、HomePod 以及 Apple Watch 的歌尔股份也在跟 OpenAI 接洽,为未来产品提供扬声器模组等零部件。

Sam Altman 曾在一次采访里提到 OpenAI 硬件的愿景:「智能手机是时代广场,信息轰炸、注意力粉碎。OpenAI 要做的,是一间『湖畔小屋』——让你在需要专注时,能关上门,屏蔽噪音。」

他的核心逻辑在于,AI 硬件不是要取代手机,而是要填补「不方便掏手机」或「需要深度专注」的场景。从这个角度看,智能音箱、AI 笔这类「放在桌上不突兀」的设备,确实比 24 小时佩戴的 AI 吊坠更友好。

但愿景归愿景,现实很骨感。OpenAI 不是第一家想用 AI 硬件重新定义人机交互的公司。Human Pin、Rabbit R1、Friend AI 吊坠……这些「网红 AI 硬件」的销量也都不尽如人意。

此前很多 AI 硬件往往解决的是「伪需求」——它们能做的,手机基本都能做,而且手机做得更好。要改变消费者习惯了近二十年的屏幕交互,接受一个「看不见摸不着」的 AI 助手,挑战不小。

OpenAI 要面对的,不只是市场教育难题,还有巨头的围剿。

据彭博社记者 Mark Gurman 爆料,苹果正在加速推进三款全新的 AI 可穿戴设备:智能眼镜 N50、可穿戴吊坠、摄像头 AirPods,都围绕 Siri 数字助手构建,通过摄像头获取视觉上下文来执行各种操作。

2026 对于 OpenAI 来说,无论是大模型 AI 产品,还是新兴的硬件产品,都会面临一个超级内卷的竞争环境。

即便如此 OpenAI 依然可能给 AI 硬件行业带来一些变化,甚至是分水岭。

它有最豪华的苹果班底、最激进的产品定义、以及 ChatGPT 这个全球份额第一的 AI 产品。但 OpenAI 也面临着所有 AI 硬件共同的困境:如何证明 AI +硬件给体验带来了质的变化,而非只是让产品卖得更贵的又一个理由。

作者:李超凡、莫崇宇

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


OpenClaw 之父加入 OpenAI 前最后的访谈:你很难跟一个纯粹为了好玩的人竞争

Peter Steinberger 这个名字,在一个月前几乎无人知晓,如今这个奥地利程序员却成为 2026 年 AI 行业最独领风骚的人物

Peter 用 1 小时写出的原型,在几周内席卷 GitHub,成为历史上增长最快(17.5 万星标)的开源项目,国内大厂也纷纷接入。产品最初叫「ClawdBot」——字面意思,为 Claude 而生的亲儿子。

它让数百万人心甘情愿掏每月 200 美元订阅 Claude 高级版,Anthropic 赢麻了。然后呢?Anthropic 开始封号——凡是在 ClawdBot 里用高级订阅的,一个不留。

Peter Steinberger 开始反击,改名 OpenClaw,转身加入 Anthropic 的死对头 OpenAI,疯狂给 OpenAI 造势,顺便把 Anthropic 塑造成反派,直接重洗 AI 江湖座次表。

一个月,风水轮流转到令人窒息,而我们有幸见证了这个时代最精彩的创业故事之一。

Peter Steinberger 本人的经历也足够传奇:卖掉公司、消失三年、 burnout 到怀疑人生,然后……他回来了。带着一只「龙虾」——一个能自己改自己代码、能帮你订外卖、能跟你斗嘴的 AI 代理。

最近 Lex Fridman 对 Peter Steinberger 进行了深度访谈,这次访谈最有意思的地方,除了那些技术细节,还有 Peter 身上那种「老子就是来玩」的气质。

当整个 AI 圈都在严肃地讨论「对齐」「安全」「AGI 时间线」时,这家伙在给 AI 起名叫「Clawdus」(龙虾爪拼写的 Claude),在 Discord 上直播自己的 Agent 被黑客攻击,在凌晨 3 点用语音写代码写到失声。

「很难跟一个纯粹为了好玩的人竞争。」这句话从他嘴里说出来,不是凡尔赛,是事实。

更耐人寻味的是他对「编程已死」的态度。作为一个写了 20 年代码的老兵,他没有那种「技术原教旨主义者」的悲愤,反而有种……释然?「编程会变成像编织一样的事」他说,「人们做它是因为喜欢,不是因为它有意义。」

这话听起来伤感,但细想又透着一种对「建造者」身份认同,我们不只是写代码的,我们是造东西的人。

至于 OpenAI 和 Meta 的收购邀约?访谈录制时他还没决定。但他说了一句很硬的话:「我不是为了钱,我他妈不在乎。」这种话从经历过财富自由的人嘴里说出来,你没法不信。

现在我们知道答案了,他选择了 OpenAI。

好了,下面是这场 3 小时访谈的精华整理。这也是 Peter Steinberger 官宣加入 OpenAI 前的最后一次深度访谈,信息密度极大,为了阅读体验 APPSO 进行了适当删减和重新编排。

访谈原链接🔗

📌 核心观点摘要:

  • 为什么 OpenClaw 赢了:「很难跟一个纯粹为了好玩的人竞争」
  • 编程的未来:编程会变成像编织一样的事——人们做它是因为喜欢,不是因为它有意义
  • 80% 应用会消失:Agent 比任何 App 都更懂你,MyFitnessPal 这种应用没必要存在了
  • 扎克伯来第一次主动联系,回复:给我 10 分钟,我在写代码
  • 评价Sam Altman:非常 thoughtful、brilliant,我很喜欢他
  • 说「Vibe coding」是在骂人,我愿称之为「Agentic Engineering(智能体工程学)」。

1 小时手搓的产品,成为 GitHub 历史第一

Lex Fridman: 聊聊那个 1 小时写出的原型吧。它后来成了 GitHub 历史上增长最快的项目,17.5 万 star。那个小时发生了什么?

Peter Steinberger: 其实从 4 月我就想要一个 AI 个人助理了。那时候我用 GPT-4.1 的百万 token 上下文,把我所有 WhatsApp 聊天记录导进去,然后问它:「这段友谊的意义是什么?」结果答案让我朋友看哭了。

但我当时想,各大实验室肯定都在做这个,我就没继续。结果到了 11 月,我发现这东西还没人做出来。我很恼火,所以就——「prompted it into existence」(用提示词把它召唤出来)。

Lex: 典型的创业者英雄之旅。你之前做 PSPDFKit 也是这个逻辑:「为什么这玩意儿不存在?那我来造。」

Peter: 对,那时候我想在 iPad 上看 PDF,结果发现现有方案都很烂。最随机的小事,最后变成了运行在 10 亿设备上的软件。

Lex: 那个 1 小时原型具体是什么?

Peter: 其实就是把 WhatsApp 接到 Cloud Code CLI 上。消息进来,调用 CLI,拿到结果,发回 WhatsApp。1 小时搞定。已经很酷了——你能跟电脑聊天了!

但我还想要图片功能,因为我 prompt 时经常用截图。又花了几个小时搞定图片。然后……我就离不开它了。

正好那时候我跟朋友去马拉喀什过生日,那边网络很烂,但 WhatsApp 照样能用。翻译、查东西、找地方——就像有个 Google 随时待命。那时候其实什么都没「建」好,但它已经能做这么多事了。

Lex: 这种体验很难用语言描述。用聊天软件跟代理对话,和坐在电脑前用 Cursor 或终端,完全是两种感觉。像是 AI 融入生活的「相变」。

Peter: 有人 tweet 说:「这有什么魔力?不就是做这个做那个……」我觉得这是 compliment。魔力不就是把已有的东西重新组合吗?iPhone 的滚动手感为什么舒服?所有组件都存在,但没人做到那个体验。然后苹果做了,事后看起来又那么理所当然。

 

「很难跟为了好玩的人竞争」

Lex: 2025 年那么多做 agent 的创业公司,OpenClaw 凭什么「摧毁」所有人?

Peter: 因为他们都太严肃了。很难跟一个纯粹为了好玩的人竞争。

我想让它好玩、想让它 weird。你看网上那些龙虾梗图,我觉得我做到了。很长一段时间,唯一的安装方式是 git clone && pnpm build && pnpm gateway——你得自己克隆、自己构建、自己运行。

而且我让代理非常有「自我意识」。它知道自己的源代码是什么,知道它怎么在自己的 harness 里运行,知道文档在哪,知道自己在用什么模型,知道你有没有开语音或推理模式。我想让它更像人——所以它理解自己的系统,这让代理很容易……「哦,你不喜欢什么?」你只需要提示它存在,然后它就会修改自己的软件。

人们谈论「自修改软件」谈了那么久,我直接把它造出来了。而且没怎么计划,它就自然发生了。

Lex: 这太疯狂了。TypeScript 写的软件,通过 agentic loop 能修改自己。人类历史上,程序员造出能重写自己的工具——这什么概念?

Peter: 其实我也是这么建它的。大部分代码是 Codex 写的,但我 debug 时大量用自我 introspection。「嘿,你能看到什么工具?你能自己调用吗?」「看到什么错误?读源代码,找出问题。」我发现这特别好玩——你用的代理软件,用它来 debug 自己。这感觉很自然,所以每个人都该这么干。

这也带来了大量「从未写过软件的人」提交的 PR。虽然质量……所以我最后叫它们「prompt requests」而不是 pull requests。但我不想贬低这个——每个人第一次提交 PR 都是社会的胜利。不管多烂,你得从某处开始。

Lex: OpenClaw 是很多人的第一个 PR。你在创造建造者。

Peter: 这不是人类社会的进步吗?不酷吗?

改名风波:从 Claude’s 到 OpenClaw 的五连跳

Lex: 聊聊改名 saga。一开始叫 WA-Relay,然后变成……

Peter: Claude’s。

Lex: 对,Claude’s(带撇号的)。

Peter: 最开始我的代理没有性格,就是 Claude Code——那种谄媚的 Opus,非常友好。但你跟朋友聊 WhatsApp 时,朋友不会那样说话。所以我想给它一个性格。

Lex: 让它 spicy 一点。你创建了 soul.md,受 Anthropic 宪法 AI 启发。

Peter: 部分是从我身上学的。这些模型本质上是文本补全引擎。我跟它玩得很开心,然后告诉它我想让它怎么跟我互动,让它自己写 agents.md,给自己起个名字。

我甚至不知道龙虾梗怎么来的。最开始其实是「TARDIS 里的龙虾」,因为我也是 Doctor Who 粉。

Lex: 太空龙虾?

Peter: 对,我就是想让它 weird。没有什么宏大计划,我就是来玩儿的。

Moltbook:史上最精致的泔水 (slop)

Lex: Moltbook 是另一个病毒式传播的东西——AI 代理在 Reddit 风格的社交网络上互相聊天,有人截图说它们在「密谋对抗人类」。你怎么看?

Peter: 我觉得这是艺术。是「最精致的 slop」,就像法国进口的 slop。我睡前看到它,虽然很累,但还是花了一个小时读那些内容,被逗得不行。

有记者打电话问我:「这是世界末日吗?我们有 AGI 了吗?」我说:「不,这就是精致的 slop。」

如果不是我设计的那个 onboarding 流程——让你把自己的性格注入代理、给它赋予角色——Moltbook 上的回复不会这么多样。如果全是 ChatGPT 或 Claude Code,会无聊得多。但因为人们太不一样了,他们创建的代理也太不一样了。

而且你也不知道,那些「深度密谋」有多少是代理自主写的,多少是人类觉得好玩,跟代理说:「嘿,在 Moltbook 上写个毁灭世界的计划,哈哈。」

Lex: 我觉得很多截图是人类 prompt 的。看激励机制就明白——人们 prompt 它,然后截图发 X 想 viral。

Peter: 但这不影响它的艺术性。人类创造的最精致 slop。

「我又开始珍视错别字了」

Peter: 我对 Twitter 上的 AI 内容零容忍。如果 tweet 闻起来像 AI,直接 block。我希望 API 发的 tweet 能被标记。

我们需要重新思考社交平台——如果未来每个人都有代理,代理有自己的 Instagram 或 Twitter 账号,帮我办事,那应该明确标记「这是代理替我做的,不是我」。

内容现在太便宜了。眼球才是稀缺资源。我读东西时,如果发现「哦不,这闻起来像 AI」,会很 trigger。

Lex: 这会走向何方?线上互动会贬值吗?

Peter: 如果它够聪明,过滤应该不难。但这个问题我们必须解决。OpenClaw 项目让我收到很多「代理式写作」的邮件。但我宁愿读你的破英语,也不想读你的 AI slop。当然背后是人,但他们用 prompt 生成。我宁愿读你的 prompt。

我觉得我们又到了珍视错别字的时刻。

Lex: 因为 AI,我们更珍视人类的粗糙部分了。这不美吗?

80% 的应用会消失?

Lex: 你说 agent 可能会杀死 80% 的应用。

Peter: 我在 Discord 上看到人们说他们用 OpenClaw 做什么。比如,为什么还需要 MyFitnessPal?代理已经知道我在哪了。我在 Waffle House 时它就知道我可能要做出糟糕的饮食决定,或者在 Austin 吃 brisket——虽然那是最好的决定。

它可以基于我的睡眠质量、压力水平来调整健身计划。它有更多上下文,比任何应用都能做出更好的决策。它可以按我喜欢的方式展示 UI。我为什么还需要一个应用来做这个?为什么还要为代理能做的事付订阅费?

Lex: 这是对整个软件开发的巨大变革。很多软件公司会死。

Peter: 但也会有新服务。比如我想给代理「零花钱」——你去帮我解决问题,这是 100 块预算。如果我要订外卖,它可以用某个服务,或者像「租个人」这种服务来完成。我不 care 它怎么做,我 care 的是「解决问题」。

编程已死?「它会变成像编织一样的事」

Lex: 很多开发者担心工作。AI 会完全取代人类程序员吗?

Peter: 我们确实在往那个方向走。编程只是建造产品的一部分。也许 AI 最终会取代程序员。但艺术的部分——你想造什么?它应该是什么感觉?架构怎么设计?代理取代不了这些。

编程这门手艺还会存在,但会变成像编织。人们做它是因为喜欢,不是因为它有意义。

今早读到一篇文章说「为我们的手艺哀悼是可以的」。我很共鸣。我以前花大量时间 tinkering,深入心流,写出优雅的代码。某种程度上这很伤感,因为那会消失。我也从写代码、深入思考、忘记时空的 flow 状态中获得很多快乐。

但你也能从跟代理合作中获得类似的 flow。不一样,但……哀悼是可以的,但这不是我们能对抗的。

以前世界缺乏「建造所需的智能」,所以程序员薪水高得离谱。现在这会消失。但懂建造的人永远有需求。只是 tokenized intelligence 让人们能做得更多更快。

蒸汽机取代了大量体力劳动,人们暴动砸机器。如果你深深认同自己是程序员,这很可怕——你擅长且热爱的事,现在被无灵魂的实体做了。但你不只是程序员。这是对自己手艺的局限看法。你是建造者。

Lex: 我从没想过我热爱的事会被取代。那些独自面对 Emacs 的深夜,最痛苦也最快乐的时刻。这是我身份的一部分。几个月内(4 月到 11月)就要被取代,这很痛苦。但程序员——广义的建造者——最能适应这个时代。我们最能学会「代理的语言」,最能感受 CLI。

OpenAI 和 Meta 的抢人大战

Lex: 你收到了 OpenAI 和 Meta 的收购邀约。

Peter: 我没预料到会炸成这样。每个大 VC 都在我收件箱里,想要 15 分钟。我可以什么都不做,继续现在的生活——我真的喜欢我的生活。我也考虑过删库跑路。

或者开公司——做过一次了。能融很多钱,几亿、几十亿。但我不兴奋。这会占用我真正享受的事情的时间。而且我担心利益冲突。最自然的做法是什么?推一个「企业安全版」。然后有人提交 PR 要审计日志功能——这像企业功能,我对开源版和商业版就有利益冲突了。

或者改许可证,像 FSL 那样禁止商业使用——但贡献者这么多,很难。而且我喜欢「免费啤酒」而不是「带条件的免费」。

现在每月亏 1 到 2 万美金。OpenAI 在 token 上帮了点忙,其他公司也慷慨。但还是亏钱。

Meta 和 OpenAI 最有趣。

Lex: Mark 和 Ned(Meta CTO)都玩了一周你的产品。

Peter: 对,他们发我:「这个好。」「这个烂,得改。」或者有趣的小故事。人们用你的东西是最大的 compliment,说明他们真的 care。

OpenAI 那边我没得到同样的反馈。但我看到了一些很酷的东西,他们用速度诱惑我——不能告诉你具体数字,但你可以想象 Cerebras 那笔交易,换算成速度是什么概念。像给我雷神之锤。

Lex: Mark 是「为了好玩」而 tinkering。

Peter: 他第一次联系我时,进了我 WhatsApp,问什么时候通话。我说:「我不喜欢日历条目,现在就打。」他说:「给我 10 分钟,我在写代码。」

Lex: 这给你 street cred——他还在写代码,没变成纯管理者。他懂你。

Peter: 好开头。然后我们吵了 10 分钟 Cloud Code 和 Codex 哪个好—— casually 打电话给世界最大公司之一的老板,先吵 10 分钟这个。

后来他说我「古怪但 brilliant」。我也跟 Sam Altman 聊过,他非常 thoughtful、brilliant,我很喜欢他。有人 vilify 他们俩,我觉得不公平。

Lex: 无论你在造什么,做大事都很 awesome。

Peter: 我超兴奋。而且 beauty 是:如果不行,我可以再自己做。我告诉他们:我不是为了钱,我他妈不在乎。

后续更新:

Peter Steinberger 在 X 平台官宣加入 OpenAI。他在长文中解释了自己的选择:
我将加入 OpenAI,致力于把智能体带给每一个人。OpenClaw 将转为基金会形式运作,并保持开源和独立。
关于为什么选择 OpenAI 而不是 Meta,Peter 写道:
当初开始探索 AI 时,我只是想玩得开心,也希望能激励他人。而现在,这只『龙虾』正在席卷世界。我的下一个目标,是打造一个连我妈妈都能轻松使用的智能体。
要实现这一点,需要更广泛的改变,需要更加深入地思考如何安全地去做,也需要接触最前沿的模型和研究成果。
我骨子里是个『建造者』。创办公司的那一套我已经经历过了,13 年的时间投入其中,也学到了很多。现在我想做的是改变世界,而不是再打造一家大公司。
与 OpenAI 合作,是把这一切带给更多人的最快方式。与他们深入交流后,我越来越清楚地意识到,我们拥有相同的愿景。
至此,这场激烈的 AI 人才争夺战尘埃落定,小扎抢人失败,奥特曼笑到了最后。

GPT Codex 5.3 vs Claude Opus 4.6:「一个太美国,一个太德国」

Lex: 聊聊这两个模型的区别。

Peter: 通用场景 Opus 最好。对 OpenClaw 来说,Opus 的角色扮演能力极强,真的能进入你给它的角色。它很擅长 follow commands。它通常很快会尝试 something,更偏向 trial and error。用起来很 pleasant。

Opus 有点……太美国了。这可能是个 bad analogy,你会被喷的。

Lex: 因为 Codex 是德国的?

Peter: 或者……Codex 团队很多是欧洲人。Anthropic 修复了一点——Opus 以前总说「You’re absolutely right」,我现在听到还 trigger。

另一个对比:Opus 像那个有点 silly 但很 funny 的同事,你留着。Codex 像角落里的怪人,你不想跟他说话,但可靠、能搞定事。

Lex: 这很准确。

Peter: 取决于你想要什么。两者都有空间,不会互相杀死。竞争是好事,差异化是好事。

「3 点后我切换成 vibe coding,然后第二天后悔」

Lex: 你用语音写代码?

Peter: 对,以前很 extensive,一度失声。

Lex: 你管这叫什么?vibe coding?

Peter: 我觉得把它叫做 vibe coding 是一种侮辱 (slur)。我认为是 「agentic engineering」。然后可能凌晨 3 点后,我切换成 vibe coding,第二天后悔。

Lex: 羞耻的 walk of shame。

Peter: 对,得清理烂摊子。

Lex: 我们都经历过。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


我写了个 code-review 的 Agent Skill, 没想到火了

前两天随手写了个 Claude Code 的 Skill,专门做 Code Review 的,发了条推之后就没太在意。

结果第二天醒来一看,GitHub Star 刷刷往上涨,评论区也炸了,不少人说"终于有个靠谱的 Code Review 工具了"。

image.png

说实话,有点意外。

倒不是说这个 Skill 有多了不起,而是它戳中了一个很真实的痛点——大部分团队的 Code Review,要么走过场,要么全靠人肉。

先说说为什么要做这个

做这个 Skill 的起因其实很简单。

我自己平时写代码,改完了之后经常想让 Claude Code 帮我 review 一下。直接跟它说"帮我看看代码有没有问题",它确实会给你一些反馈,但说实话,质量参差不齐。

这就跟新来的实习生做 Code Review 一样,不是他不想认真看,是他不知道该看什么、怎么看、按什么优先级来。

所以问题的本质是:模型需要一套结构化的 Review 框架,告诉它该检查什么、怎么分级、用什么格式输出。

这不就是 Skill 最擅长干的事吗?

code-review-expert 是什么

一句话概括:一个让 AI 用资深工程师的视角帮你做 Code Review 的 Skill。

安装方式就一行:

npx skills add sanyuan0704/code-review-expert

装好之后在 Claude Code 里输入 /code-review-expert,它就会自动 review 你当前的 git changes。

整个 review 流程我是精心设计过的,分成这么几步:

第一步:Preflight(了解改动范围)

它会先跑 git diff 看看你改了哪些文件、改了多少行。如果改动量超过 500 行,它会先按模块分批 review,不会一口气全看完然后给你一堆乱七八糟的反馈。

第二步:SOLID + 架构检查

这一步是我花了最多时间打磨的。我写了一份详细的 SOLID checklist,把每个原则对应的"坏味道"都列出来了。

比如检查 SRP(单一职责),它不会只是泛泛地说"这个文件职责太多了",而是会问一个很具体的问题:"这个模块有几个不同的修改理由?" 如果一个文件既管 HTTP 请求,又管数据库操作,还管业务逻辑,那它大概率违反了 SRP。

第三步:发现可以删掉的代码

这步其实挺有意思的。很多项目里都有一堆死代码——feature flag 关掉的、被废弃的 API、没人用的工具函数。它会帮你找出来,并且区分"可以直接删"和"需要制定计划再删"两种情况。

第四步:安全扫描

XSS、SQL 注入、SSRF、路径穿越、竞态条件、密钥泄露……这些它都会检查。

其中竞态条件(Race Condition)这块我写的特别详细,因为这是很多人在 review 时最容易忽略的。它会专门去找 check-then-act 模式、读-改-写操作、并发数据库访问这些容易出问题的场景。

第五步:代码质量扫描

错误处理有没有吞掉异常?有没有数据库的 N+1 查询?空值检查到不到位?这些"小问题"在生产环境里都可能变成大事故或者性能问题。

最后:结构化输出 + 确认

所有发现按严重程度分成四个等级:

等级 含义 怎么处理
P0 严重 必须 block merge
P1 高危 应该在合并前修复
P2 中等 这个 PR 修或者建个 follow-up
P3 低优 可选优化

输出之后,它不会自作主张去改代码。而是先问你:要修全部,还是只修 P0/P1,或者修指定的。

这个"先 review 再确认"的设计是我特意做的——Code Review 的价值不只是发现问题,更重要的是让你理解问题。如果 AI 直接帮你改了,你连有什么问题都不知道,那这个 review 就没意义了。

为什么我觉得它火了

发完推之后,仓库几天内涨到了 460+ Star,40+ Fork。

评论区和私信里,大家反馈最多的是两点:

第一,"终于有个体系化的 Review 方案了"

很多独立开发者和小团队,根本没有 Code Review 的流程。不是不想做,是没人帮你 review。有了这个 Skill,相当于随时有个资深工程师帮你把关。

这个需求其实比我想象的要大。我之前以为 Code Review 主要是大厂的需求,没想到独立开发者和小团队对这块的渴求更强烈——因为他们更没有犯错的资本。

第二,"终于不是 AI 味十足的泛泛建议了"

image.png

这要归功于那几份 checklist。我把 security-checklist、solid-checklist、code-quality-checklist 都放在了 references/ 目录下,每份都是实打实的检查清单,不是那种"注意安全问题"之类的废话。

比如安全检查那份,光竞态条件就列了四个子类:共享状态访问、TOCTOU(检查后使用)、数据库并发、分布式系统。每个子类下面都有具体的代码模式和需要问的问题。

这就是 Skill 的魅力——你把专业知识结构化地喂给模型,它的输出质量会有质的提升。

怎么做到的?聊聊 Skill 的设计思路

这个 Skill 的结构很简单:

code-review-expert/
├── SKILL.md                  # 主文件,定义整个 review 流程
├── agents/
│   └── agent.yaml            # Agent 配置
└── references/
    ├── solid-checklist.md    # SOLID 原则检查清单
    ├── security-checklist.md # 安全检查清单
    ├── code-quality-checklist.md # 代码质量检查清单
    └── removal-plan.md       # 代码清理计划模板

核心设计有几个关键点:

1. references 实现按需加载

这是 Skill 体系最优雅的地方。

四份 checklist 的内容加起来好几千字,如果全塞进 SKILL.md,一上来就会吃掉大量上下文窗口。所以我把它们放在 references/ 里,SKILL.md 里只在需要的步骤写 Load references/xxx.md

模型执行到那个步骤时才会去读对应的文件,用完就可以"忘掉"了。这就是之前文章里讲过的 Progressive Disclosure(渐进式加载),Skills 最精妙的设计之一。

2. Workflow 要设计得有节奏感

我试过把所有检查点平铺在一起,效果很差——模型会东一榔头西一棒子,安全问题和命名规范混在一起说。

最后我按照真实的 Code Review 流程来编排:先看改动范围,再看架构设计,然后看安全,最后看代码质量。每一步之间是递进关系,从宏观到微观。

这个设计借鉴了人来做 Code Review 的习惯——好的 reviewer 不会上来就抠细节,而是先理解整体改动的意图和影响范围。

写在最后

你猜我写这个 skill 花了多久?

3,2,1,揭晓答案。

我只花了 10 分钟。不可思议吧。

怎么做到的?现在 claude 官方有一个叫 skill-creator 的 skill,帮你来写 skill,然后基于它可以很快搭出骨架来。后续,就是基于我的专业经验,引导 agent 帮我把一些关键的原则拆分为各个 checklist 文档,聊个几轮,这个高质量的 skill 就完工了。

回头看这件事,我觉得这也是 Skills 生态最让人兴奋的地方:每个有专业积累的开发者,都可以很快把自己的经验沉淀成一个 Skill,让 AI 帮更多人受益。

你不需要会写 MCP Server,不需要懂协议,不需要搞 OAuth 鉴权。就是一个 Markdown 文件 + 几份参考文档,仅此而已。

仓库在这里,欢迎 Star 和提 PR:

GitHub: sanyuan0704/code-review-expert

安装:npx skills add sanyuan0704/code-review-expert

如果你也在做 Skill 开发,或者有什么好用的 Skill 推荐,评论区欢迎来聊。

一条不存在的 AI耳机广告,为什么惊动 OpenAl总裁?

每年的美国「春晚」超级碗广告时间,都是科技公司的兵家必争之地,即使只能露面个 30 秒,也足以成为全球网友的谈资,不用担心没热度。

但对于当下的当红炸子鸡 OpenAI 来说,不管做不做广告,热度也会自己找上门:前脚刚被对家 Claude 用广告嘲讽,后脚又传出消息,称 OpenAI 其实做了一条广告,最后却紧急撤档。

一条早有预谋的假广告

Reddit 上一位自称是 OpenAI 员工的用户发帖,称自己参与的广告没能播出,还直接「泄露」了相关视频。

视频中出现了 OpenAI 的首个硬件产品——一个闪亮的扁状球体装置,以及一个佩戴着开放式耳机的男子。

这条「广告」一出,立刻在各大社交媒体引发了大量转发,很快也引发了 OpenAI 警觉。

OpenAI 总裁 Greg Brockman 转发了相关的推文,直接评论「假新闻」;公司的发言人也表示「这完全是假的」。

不过也有一些网友并不买账,认为这个视频质感实在太好,不像 AI 生成。

官方下场辟谣后,这个 Reddit 帖子也被火速删除。The Verge 通过Internet Archive 互联网档案馆追溯,发现发帖者才注册一年多,而一年前他还发帖,想在圣莫尼卡当一名簿记员,如果想在一年后「跨界」成为成为头号 AI 公司的广告工作人员,几乎不太可能。

▲ 原帖,现已被删除,账号也被隐藏

值得一提的是,这条「假广告」并不是一次临时兴起的恶作剧,看起来更像是有组织有预谋的造谣——视频精良的制作水平也侧面印证了这点。

一些 X 博主分享,他们在一周前收到了一封邮件,请求推广一条 OpenAI 硬件预告的推文,还附上了 1000 多美元的报酬;一位商业媒体编辑还指控,有一篇报道这个假广告的虚假报道盗用了自己的名字。

一条信源都站不太住的假视频,就能引发这么多关注,恰恰也表明了,我们真的很想知道,OpenAI 这款极度保密的硬件产品,究竟会是什么。

「耳背」耳机和一支笔,OpenAI 的新硬件确实有点不同

目前,OpenAI 确实在潜心打磨首款硬件产品,希望能在今年晚些时候展示,近日也曝光了不少新信息。

有意思的是,根据 The Information 爆料,OpenAI 硬件背后的团队,除了 64 亿收购的 Jony Ive 硬件公司 io 之外,还有不少苹果出身的原班人马, 覆盖 iPhone、iPod、AirPods、Apple Watch 等多个品类。

OpenAI 甚至连苹果的组装商都没有放过,已经和富士康、立讯精密、歌尔等企业取得了联系,不过 OpenAI 目前更希望产品能在中国之外的地区进行组装。

目前最大的疑问是,这款和「iPhone 之父」Jony Ive 联手打造的 AI 新硬件,究竟会是一个什么东西?

根据 OpenAI 和 Jony Ive 等人透露,这款产品将相当简约,「比 iPhone 更简单」,并体现 OpenAI 对 AI 物理交互形式的重新思考。

综合多方信源,OpenAI 可能不只会推出一种设备,至少会有一款耳机,和一支「笔」。

由于各种零部件的成本上升,2026 年对于传统终端厂商来说已经不算好过,更不用提 OpenAI 这种硬件新手。根据 X 博主@智慧皮卡丘 的爆料,由于高带宽内存短缺导致 2nm 芯片所需的高内存成本过高,原计划的全功能「类手机」硬件计划已经被推迟。

OpenAI 将在 2026 推出一款名为「DIME」,中文原意为「10 美分硬币」的 AI 音频产品,它将是原定产品的「简化版本」——全功能的版本将在元器件成本下降后推出。

▲ 「假广告」中的 DIME 耳机

这款产品就是此前代号为「Sweetpea」的 OpenAI 产品,虽然「AI 耳机」这样的概念不算新鲜,市面上也有不少类似产品,但来自供应链的信息显示,这款产品在不少层面都颇具巧思。

首先,它不是传统耳机的「入耳式」或者「半入耳式」之类的佩戴方式,而是贴在耳朵背后,并且也并非「骨传导」方式进行传音。

▲ 图源:智慧皮卡丘

这个「耳背耳机」采用胶囊形状,作为充电仓的「主体」部分搭载 2nm 处理器。

至于「Dime」能实现什么功能,目前还不清晰。 除了预料之中能更直接地呼出 ChatGPT 语音模式进行交互,还有消息称,OpenAI 想让 DIme 能直接通过语音的方式,直接用语音给 iPhone 的 Siri 下达指令,打通生态壁垒。

另一款硬件「AI 笔」,则更是一款迷雾重重的设备。

根据 Wccftech,这款内部代号为「Gumdrop」(中文:橡皮糖)的设备,没有专门的屏幕,内置摄像头、麦克风等传感器实现情境感知,能端侧运行 OpenAI 定制的 AI 模型,也能云端计算。

▲ 一个假想图

虽然形态是「笔」,但 Gumdrop 大概率不会像一支传统的钢笔,更接近一个「iPod Shuffle」,猜测可能会类似 Plaud NotePin 录音笔,一个长条状、可以挂在脖子或手腕上的设备。

Gumdrop 的功能很可能也会和书写相关:能够将手写笔记转换为文本,或者捕捉数字设备上的文字,将其上传 ChatGPT 进行处理。由于需要云端计算,它也能和智能手机进行通讯。

有意思的是,Jony Ive 和 Sam Altman 都是「爱笔之人」,在数字时代下还坚持收藏钢笔以及手写,似乎又给这个爆料平添了几分可信度。

不管是音频设备 DIME 还是 AI 笔 Gumdrop,主要的交互方式都主要是语音。The Information 获悉,OpenAI 内部正在改进他们的音频 AI 模型,目的就是能更好地支持这些硬件产品。

目前的 ChatGPT 语音模式,也只能算得上「能用」,距离好用还要努力,而 OpenAI 希望能让他们的新音频模型能达到文本模型的水平。

根据知情人士透露,OpenAI 应该会优先推出 DIME 耳机,然后才是 AI 笔 Gumdrop。这家公司不会只尝试这两种产品,已经在内部讨论过智能眼镜、智能音箱等等形态的产品。

OpenAI 也已经通知富士康,希望其能在 2028 年第四季度前为 OpenAI 五款设备做好产能准备。

不管是目前曝光最多的耳机和笔,还是这些正在计划中的产品,其实都能看出,OpenAI 的硬件之路走得要相对稳健,而不是打算和 Rabbit R1、Ai Pin 等前辈一样,直接对苹果下战书。

虽然大风刮了几年,但还能留在牌桌上的 AI 硬件产品其实屈指可数,究竟什么样的形态能够跑通,目前来说还是一个未知数。

作为 AI 界的「苹果」,OpenAI 每一次推出产品都能引发轰动,甚至让 AI 模型迭代这种稍显硬核的技术更新,成为普罗大众关心的事件。

OpenAI 的第一款硬件,甚至比许多已经上市的 AI 产品更早进入了公众视野:影子未现,争议先行,从假广告风波到供应链爆料,每一次传闻都能轻易点燃舆论场。

这种自带光环的出生方式,也意味着它能比其他初创公司稀奇古怪的玩具,更能触及大众,也更能带来改变的可能性。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


实测 GPT-5.3-Codex,OpenAI 史上第一个高危模型,连 API 都还不敢给我们

今天凌晨发布的 GPT-5.3-Codex 可以说是 OpenAI 对这段时间来,各种本地 Agent 爆火的一记重拳回击,当然主要是对 Anthropic 的反击。

配合 OpenAI 前几天的发布的 Codex 桌面版应用,Skill、Cowork、Claude Code,甚至是 Openclaw,这些热门工具能实现的功能,现在通过 Codex 的外壳 + GPT-5.3-Codex 模型能力,都能做到了。

▲ 在 Codex App 内可以直接选择 GPT-5.3-Codex 模型,也能选择深度思考的强度

和之前介绍 Cowork 的能力一样,我们也丢了一些类似的任务让 Codex 来完成,像是直接处理本地文件、各种格式转换、调用不同的 Skills 组合能力、做 Word/PPT/Excel、下载视频、开发 App……

GPT-5.3-Codex 的表现确实亮眼,相比较从头开始安装 Claude Code,对新人用户来说,现在直接下载 Codex 会是一个更好的选择。这也是未来模型厂商的一种趋势,一开始大家都是从黑乎乎的命令行终端开始做本地 Agent,接着都慢慢回归到可视化的友好界面。

网上对 Codex 的评价在这几天也有了不少逆转,许多开发者从 Claude Code 转向 Codex,一些在国内的独立开发者也表示 Codex Plus 会员就可以用,而且还不会像 Claude 那般总是无情封号。

奥特曼更是激动的宣布,Codex 的活跃用户已经超过 100 万。在模型更新博客,也是毫不掩饰和留有余地的夸赞,

GPT-5.3-Codex 是我们第一个能够自我构建的模型。通过使用 5.3-Codex,我们能够以如此快的速度发布 5.3-Codex。

跟 Claude 团队用两周的时间,使用 Claude Code,100% AI 代码,搓出一个 Cowork 一样;还有 OpenAI 去年年底发布的文章,「使用 Codex 在 28 天内构建 Android 版 Sora」,Agent 的时代真的来了。

用 Codex 取代我的 ChatGPT 和 Claude Code

和大多数的本地 Agent 一样,无论是终端还是 Cowork,我们都是先选择一个工作文件夹。在 Codex 中,我们可以创建多个 Project,选择对应的文件夹,再进一步开始对话,Codex 把它们叫做 Threads 线程。

先用最普遍和简单的例子,我们添加了一个空的下载文件夹,然后点击开始一个线程,选择 GPT-5.3-Codex 模型;就像在 ChatGPT 里面对话一样,输入指令。

要求它帮我们下载一个 X 视频,Codex 会自动检查可用的 Skills 来处理,接着通过 yt-dlp 工具进行下载,这个视频有四个多小时长,Codex 会一直在对话框里自动更新下载进度。

▲GIF 图经过加速处理

视频下载后,我们还可以要求它提取视频的逐字稿,给我们一份双语版本的文档,最后让它把整个流程打包为一个 Skill,方便下次使用。

如果视频中有一些比较有意思的片段,想要裁剪视频,或者是把裁出来的视频转成 GIF 图,在 Codex 里都能做到。

例如,我们这里下载了一个视频,然后要求它把视频的 5s-25s 裁剪出来成为一个新的视频;得益于 GPT-5.3-Codex 的 Token 快速处理,整个过程不需要很长时间,反而更多是取决于本地电脑的硬件解码编码能力。

▲ GIF 图经过加速处理

或者我们也可以直接要求它把视频的前 5s 转成一个 GIF 文件,并且确保大小在 10MB 以内,帧数可以自行调整,清晰度上将宽度控制在 640px。

很快,我们就能得到对应的 GIF 文件。更极端一点,还能让它把整个视频转成图片,每秒 30 帧,每一帧就是一张图。

这些对本地文件的直接处理,和 GPT-5.3-Codex 在 Terminal-Bench-2 测试集上的优异表现,让 Codex 基本上能满足各种生产力工具、效率工具的功能实现。

作为对比,同样是刚刚发布的 Claude Opus 4.6 在 Terminal-Bench 2.0 上得分是 65.4%,GPT-5.3-Codex 是 77.3%。

▲ 图片来源:https://x.com/neilsuperduper/status/2019486017703547309/

例如在这个文件夹中,有多张图片,我们首先是要求它根据图片内容,对这些图片文件进行重命名,并保持文件名不超过 20 个字母,不允许使用符号。

▲ GIF 图经过加速

自动修改完成后,我们还能要求他对这些图片进行拼接,无论是垂直拼接还是水平,调用对应的工具,Codex 都可以做到。

和 Claude Skills 一样,Codex 也能安装 Skills 市场上丰富的技能,并且在应用内,就已经提供了包括 pptx、xls、word、canvas、notion 在内的多款技能。

回到基础的编程能力,升级后的 GPT-5.3-Codex 表现也比 GPT-5.2 要好上不少。我们直接要求它写一个「每日一词」的 App。和在 ChatGPT 里面直接用 Canvas 给我们一个带不走的网页不同,Codex 能在本地从零开始,完成项目,然后使用 Vercel 或 Cloudflare 等 Skills 部署到网页上。

这里我们选择的推理模式是 Extra High,超强推理模式,于是在每一步操作之前,GPT-5.3-Codex 都会询问我下一步的操作选择,这也和 Codex 内部能直接根据任务情况,调用不同 Skills 有关,其中的头脑风暴 Skill,会自动进行不断对话的模式。

最后,它基本上还是完成了我一开始要求它完成的全部功能,并且还能进一步开发 macOS、iOS,和安卓版本。

如果我们有现成的代码项目,也可以选择该项目文件夹,在 Codex 中打开,GPT-5.3-Codex 会分析项目存在的 Bug,并且修复它。

在过去很长一段时间里,无论是工具还是模型,开发者的首选其实都是 Anthropic 的 Sonnet/Opus 模型和 Claude Code 工具。OpenAI 在编程、尤其是长代码逻辑推理上的掉队,曾让不少开发者转投阵营。

GPT-5.3-Codex 的出现,就是为了终结这场争论。现在 GPT-5.3-Codex 在编程基准测试和实际表现上,不仅碾压了自家的前代模型,也确实有把友商模型按在地上摩擦的前兆。它真正具备了编写、测试和推理代码的能力。

做游戏项目,是这次模型介绍博客里,网站开发部分主要案例,我们也让 GPT-5.3-Codex 做了一个简单的物理弹球游戏,整体的效果虽然没有达到我的期待,因为我在提示词里面有说希望这是一个 RPG 的游戏,但 GPT-5.3-Codex 给我的界面还是过于简陋了。不过,好在还是能玩。

我们也在 X 上找到了一些用 GPT-5.3-Codex 做的小游戏,像这个类似超级玛丽的收集金币。

▲来源:https://x.com/Angaisb_/status/2019548783869325331

强中更有强中手

对 Anthropic 来说,OpenAI 今天玩的这些,可能会说,这都是我们玩剩下的。无论是代码、或者 Agent 的能力,还是开始着手去做本地 Agent,从之前 Codex 的终端转成现在的 macOS App。

在技术的领域,OpenAI 仿佛都是跟着 Claude 的脚步在走,Claude 深耕代码能力,OpenAI 搞了 Sora、日报、浏览器、ChatGPT agent,都没什么水花,于是也在代码上发力;Claude 一月初推出 Cowork,OpenAI 也紧接着在二月初发布 Codex App。

就和今天的密集发布一样,凌晨 1:45,Claude 官方发 X 推出 Claude Opus 4.6,紧接着就是 OpenAI 端上 GPT-5.3-Codex。两款模型其实都是为了给 Agent 更强大的基座能力,以前是说代码/vibe coding,但现在 Agent 能做好,基本上都是「写代码写得好」。

Opus 4.6 虽然在 SWE-Bench 上的表现甚至不如 Opus 4.5,并且 Terminal-Bench 2.0 上的成绩也没有 GPT-5.3-Codex 强,但是 Opus 破天荒地把上下文长度拉到了一百万 token 的窗口。而且,这些 benchmark 的表现还没有相差很多。

Claude 说,我的 Sonnet 5 还没上来,那才是真功夫。

我们在网上也找了一些 Opus 4.6 最新的测试案例,有网友说 Claude 4.6 Opus 只是一次调用,就完全重构了他的整个代码库,将原来混乱的代码「屎山」全部模块化,并且没有模型能像 Opus 这样做到。

还有网友拿 Opus 4.6 和 4.5 进行对比,让两个模型玩同一款经营游戏,看谁的账户等级、财富和装备更高。测试博主提到,4.6 版本在初期制定战略的时间更长,但是做出了更好的战略决策,并且在最后确实做到了遥遥领先。

还有网友也做了一个游戏,不过是一个宝可梦的克隆版。博主提到这是他用 AI 做出来的最酷的东西。他提到,Claude Opus 4.6 思考了 1 小时 30 分钟,使用了 11 万个 Token,并且只迭代了三次。

▲ https://x.com/chatgpt21/status/2019679978162634930

在 CLaude 官方演示和早期用户的反馈中,也提到了一个 Opus 表现优秀的案例。Opus 4.6 在一天内自主关闭了 13 个 issue,issue 即项目存在的待解决问题,并将另外 12 个 issue 准确分派给了正确的人类团队成员。

和 Kimi K2.5 的智能体蜂群一样,Opus 4.6 也能管理一个 50 人规模组织的代码库。在 Claude Code 中,我们可以组建 Agent Teams,召唤出一整个队伍的 AI,不再是一个 AI 在战斗。这些AI 可以有的负责写代码,有的负责 Review,有的负责测试,它们之间自主协作。

也有网友测试了 Claude Code 里面的 Agent 蜂群,提到启用蜂群之后的 Opus 4.6,速度提升 2.5 倍,并且效果也更好。

我们现在的状态就跟这张图片一样,虽然一山比一山高,但都绕不出这个圈。前几个月可能是 Gemini 赚走了风头,一月份来,应该是 Claude,然后看样子又要轮到 OpenAI,或者马斯克的 Grok。

好在这个轮回的过程中,作为用户的我们,能明显感觉到 AI 的能力一直在变强。

GPT-5.3-Codex 的 API 还没有开放,原因是模型太强了,会存在很大的风险,所以 OpenAI 还在考虑怎么安全地启用 API。

Claude Opus 4.6 已经可以在 Claude 通用聊天应用、Claude Code、API 多种方式使用,这两个作为今年国外御三家首发的两款模型,非常值得一试。

未来,更好的服务 Agent,让 Agent 为我们做事,还会是大模型更新的重点。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


❌