macOS App Skills：AI Coding Agent 开发原生 macOS 应用的技能包

为什么用 Claude Code 写 macOS 应用,2 万行代码里只有不到 1 千行是手写的?Indragie 在 2025 年的实战文章里给出答案:Agent 写原生 Mac 应用容易踩进 5 个坑——Swift Concurrency 困惑、混用新旧框架、调用废弃 API、搞错窗口管理、发布流水线漏步骤。说白了,Agent 不懂 macOS 的原生模式,会把 Mac 当网页写。

macos-app-skills 就是给 AI Agent 的技能包,专门解决这些问题。它把分散在 WWDC 视频、文档不全、容易写错的 macOS 模式固化成 7 个模块——构建、原生模式参考、设置窗口、自动更新、刘海 UI、发布流水线、安装接入。每个模块都有明确的子契约表(是什么、解决什么、典型用法、命令、流程、限制、FAQ),让 Agent 第一次就做对,不用反复试错。下面按模块拆开看,再和 fireworks-macapp-creator、claude-swift-skills 做一次选型对比。

安装接入：让 Agent 加载技能包

安装命令很简单:

npx skills add fayazara/macos-app-skills -g -y

-g 表示全局安装,-y 跳过交互确认。装完重启 Agent,它会自动加载 skills 目录里的内容。我之前就试过在 OpenCode 里装这个包,重启后 skills 列表里多出了 macos-app-skills 的几个模块——build、macos-patterns、settings-ui、auto-update、notch-ui、release。

前提条件得提前备好:macOS 14+、Xcode 15+、Swift 5.9+。想用 Liquid Glass 这些 macOS 26 特性,得装 Xcode 26 beta;低版本会优雅降级,不影响基本功能。

Agent 加载验证有个坑:有些 Agent(比如 Claude Code)需要手动配置 skills 目录路径。OpenCode 会自动识别 ~/.config/opencode/skills/,Cursor 得在项目根目录放 .agents/skills/。验证方法是让 Agent 列出已加载 skills,或者直接问”你知道 macos-app-skills 的 build 模块吗”,看它能不能引用内容。

常见失败主要有两类:网络问题和权限问题。国内网络访问 GitHub assets 可能慢,用代理或多试几次;权限问题多半是 npx 缓存目录写不了,改成 sudo npx 或手动把 skills 目录拷到 Agent 配置路径。还有一种情况:版本不兼容。项目创建于 2026-05,skill 数量和命名可能变动,装之前看一眼 GitHub README 的最新列表。

子模块拆分

子模块	是什么	解决什么	典型用法	命令	流程	限制	FAQ
安装命令	npx 全局安装技能包	让 Agent 能调用 macOS 开发技能	一行命令完成安装	npx skills add fayazara/macos-app-skills -g -y	执行命令 → 重启 Agent → 验证加载	依赖 npx 和网络	网络慢怎么办?用代理或多试几次
前提检查	macOS/Xcode/Swift 版本要求	确保环境能运行 skill 里的代码	检查系统版本、Xcode 版本、Swift 版本	sw_vers、xcodebuild -version、swift --version	查版本 → 对比 README 要求 → 不满足就升级	macOS 14+、Xcode 15+、Swift 5.9+	低版本能用吗?部分功能会降级
Agent 加载验证	确认 Agent 已加载 skills	验证安装是否生效	让 Agent 列出 skills 或测试引用	无标准命令,依赖 Agent 实现	重启 Agent → 询问加载状态 → 测试引用	不同 Agent 配置路径不同	Agent 没加载怎么办?检查配置路径
常见失败	网络、权限、版本三类问题	排障清单帮助快速定位	代理、sudo、版本核对	无特定命令,按排查清单处理	检查网络 → 检查权限 → 检查版本	国内网络可能慢	sudo 安全吗?尽量不用,改手动拷目录

build 模块：从命令行构建 macOS 工程

build 模块用 xcodebuild 从命令行构建任意 macOS Xcode 工程。说白了,就是让 Agent 不用点 Xcode GUI,直接用命令搞定编译。

它解决几个具体问题:工程发现(找 .xcodeproj 或 .xcworkspace)、scheme 检测(弄清楚有哪些 target)、beta 工具链处理(Xcode beta 的路径问题)、常见构建失败(比如 scheme 未找到、签名错误)。很多 AI 写 macOS 应用 错误 都发生在这一步——Agent 不知道该传哪些参数,或者把 iOS scheme 当 macOS scheme 调。

典型用法是让 Agent 执行构建时先加载这个 skill。它会告诉 Agent 怎么找工程文件、怎么选 scheme、怎么处理错误。命令示例:

xcodebuild -project MyApp.xcodeproj -scheme MyApp -configuration Release

或者带 workspace:

xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -configuration Release clean build

流程大概是:工程发现 → scheme 检测 → 执行构建 → 检查错误 → 迭代修复。Agent 会先找 .xcodeproj 或 .xcworkspace,然后列出可用的 scheme,选一个合适的,执行构建,如果有错就根据 skill 里的排障清单处理。

限制很明显:只支持 Xcode 工程,不支持 SwiftPM。如果你的项目是纯 SwiftPM,得先转成 Xcode 工程,或者用其他 skill。beta 工具链也有坑——Xcode beta 版本号和路径不标准,skill 里有专门的处理逻辑。

FAQ 里最常见的问题是:scheme 未找到怎么办?多半是 project 里没定义 scheme,或者 scheme 名称和 target 名称不一致。skill 会教 Agent 用 xcodebuild -list 先查可用 scheme,避免瞎猜。另一个问题:beta 工具链如何处理?skill 会指定 Xcode beta 的路径(通常在 /Applications/Xcode-beta.app),并传递 -destination 参数指定平台。

子模块拆分

子模块	是什么	解决什么	典型用法	命令	流程	限制	FAQ
是什么	用 xcodebuild 构建 macOS 工程	从命令行编译,不用点 GUI	Agent 执行构建时先加载此 skill	见下方代码块	工程发现 → scheme 检测 → 构建 → 错误处理	仅支持 Xcode 工程	SwiftPM 项目怎么办?转 Xcode 工程
解决什么	工程/scheme/工具链/失败处理	Agent 不知道该传哪些参数	先找工程文件,再选 scheme	xcodebuild -list 先查 scheme	执行 → 检查错误 → 迭代修复	beta 工具链路径不标准	beta 工具链如何处理?指定路径和 destination
典型用法	让 Agent 执行构建时加载 skill	避免 Agent 瞎传参数	构建前先加载 build skill	无特定命令,Agent 会调用 skill	加载 skill → 执行构建 → 处理错误	skill 只是知识,不是魔法	Agent 不加载怎么办?手动加载或检查配置
命令	xcodebuild 标准命令	给 Agent 可执行的命令示例	直接传给 xcodebuild	xcodebuild -project MyApp.xcodeproj -scheme MyApp	按参数执行 → 等待结果 → 解析错误	参数格式必须正确	scheme 名称怎么查?用 -list
流程	构建 → 检错 → 修复	标准构建流程	按步骤执行	无特定命令,流程是逻辑	发现 → 检测 → 构建 → 检错 → 修复	流程不可跳步	构建失败怎么办?看 skill 里的排障清单
限制	Xcode 工程支持范围	说明适用条件	只用于 Xcode 工程	无	无	不支持 SwiftPM,需先转换	为什么不支持 SwiftPM?skill 基于 xcodebuild
FAQ	scheme 未找到、beta 工具链	常见问题解答	查可用 scheme,指定 beta 路径	xcodebuild -list	检查 → 查询 → 指定	beta 工具链需额外配置	怎么知道是 beta?版本号和路径判断

macos-patterns 模块：防止 Agent 把 Mac 当网页写

macos-patterns 模块是整个技能包里最核心的。它把 macOS 原生模式固化成可查阅的参考,防止 Agent 用 Web 思路写 Mac 应用。很多 SwiftUI Agent skill 都有类似问题——Agent 会写网页式的 UI,不懂菜单栏、窗口层级、屏幕几何这些 macOS 特有概念。

它解决的具体痛点包括:

1. 菜单栏应用三种方式：MenuBarExtra(SwiftUI 原生)、NSStatusItem(AppKit 古老)、NSPopover(弹出窗口)。Agent 容易混淆,选错方式会导致 UI 不符合 macOS 规范。
2. 激活策略：Dock 图标开关、LSUIElement 配置、NSApplication.setActivationPolicy()。Agent 不懂的话,会把后台应用写得像前台应用。
3. NSPanel vs NSWindow：浮动窗口(NPanel,比如 Inspector)和普通窗口(NSWindow)的区别。Agent 容易用错,导致窗口行为不符合预期。
4. 窗口层级和 collection behaviors：CGShieldingWindowLevel(遮挡层)、NSWindow.Level(层级)、collectionBehavior(多屏、全屏行为)。Agent 不懂会写出窗口乱跳的代码。
5. 屏幕几何：frame vs visibleFrame(有无 Dock/菜单栏)、Y 轴翻转(macOS 坐标系从左下角开始)、多屏处理。这些细节 WWDC 视频里有,但 Agent 不一定知道。
6. 键盘快捷键三档：SwiftUI .keyboardShortcut()(简单)、NSEvent monitor(全局)、Carbon hotkey(系统级)。Agent 容易选错档位。
7. 其他模式：文件选择器(NSOpenPanel)、剪贴板(NSPasteboard)、拖放(NSDragging)、NavigationSplitView + inspector、登录启动(LaunchAgent)、Quick Look(QLPreviewPanel)、NSWorkspace(系统交互)、ScreenCaptureKit(录屏)、UserDefaults/@AppStorage(持久化)。

典型用法：主动加载此 skill,让 Agent 在写 macOS UI 时先查阅模式清单。比如你想写菜单栏应用,先问 Agent”macos-patterns 里推荐用哪种菜单栏方式”,它会告诉你 MenuBarExtra 是 SwiftUI 原生推荐,NSStatusItem 是 AppKit 老方案。

模式清单太长,skill 里会把每个模式都拆成”推荐/替代/适用场景/代码示例/限制”五列。这里挑几个高频的讲:

菜单栏应用对比

方式	推荐/替代	适用场景	代码示例	限制
MenuBarExtra	推荐	SwiftUI 原生,简单场景	MenuBarExtra("App", systemImage: "app") { ContentView() }	macOS 13+
NSStatusItem	替代	需要复杂定制或 AppKit interop	NSStatusBar.system.statusItem(withLength: NSStatusItem.squareLength)	需手动管理生命周期
NSPopover	补充	弹出式窗口,点击后展开	NSPopover() + NSStatusItem	需配合 NSStatusItem 使用

激活策略对比

策略	推荐场景	配置方式	代码	限制
NSApplication.ActivationPolicy.regular	前台应用,有 Dock 图标	Info.plist 不设置 LSUIElement	默认行为	最常见
NSApplication.ActivationPolicy.accessory	后台应用,无 Dock 图标但有菜单栏	Info.plist 设置 LSUIElement=true	NSApplication.shared.setActivationPolicy(.accessory)	菜单栏仍可见
NSApplication.ActivationPolicy.prohibited	完全后台,无 UI	LaunchAgent 配置	NSApplication.shared.setActivationPolicy(.prohibited)	无 Dock、无菜单栏

窗口层级对比

类型	层级数值	适用场景	代码	限制
NSWindow.Level.normal	0	普通窗口	默认	最常见
NSWindow.Level.floating	3	浮动窗口,比如 Inspector	window.level = .floating	不会遮挡其他应用
CGShieldingWindowLevel	最高	遮挡层,比如 Notch UI	window.level = CGShieldingWindowLevel()	会遮挡一切,慎用

限制：仅适用于 macOS,不覆盖 iOS。如果你需要跨平台模式,得用其他 skill(比如 claude-swift-skills 的 cross-platform 模块)。

FAQ 里常见问题：如何切换 Dock 图标?用 NSApplication.setActivationPolicy() 动态切换。如何处理多屏?用 NSScreen.screens 列出所有屏幕,visibleFrame 会返回排除 Dock/菜单栏后的可用区域。Y 轴翻转怎么处理?macOS 坐标系从左下角开始(0 在左下),Agent 容易用 Web 的左上角坐标系,需手动转换。

settings-ui 模块：设置窗口与 Liquid Glass

settings-ui 模块解决两个问题：macOS 设置窗口的正确实现方式、Liquid Glass(macOS 26 的新材质)配置。说白了,就是让 Agent 写出符合 macOS 规范的设置窗口,而不是用 SwiftUI 的 Window 场景瞎写。

具体痛点：SwiftUI 的 Window 场景不支持 fullSizeContentView,导致设置窗口没有透明背景扩展。Liquid Glass 配置错误会导致材质显示不正确。Agent 不懂的话,会写出和系统设置窗口风格不一致的 UI。

典型用法：用 NSWindowController + .fullSizeContentView + NavigationSplitView。skill 里提供了完整的 Swift 文件,可以直接拷到项目里用。流程：

1. 创建 NSWindowController
2. 配置 fullSizeContentView
3. 添加 NavigationSplitView(sidebar + detail)
4. 设置透明背景
5. 集成 Liquid Glass(macOS 26+)

代码示例(skill 里会提供完整文件)：

// SettingsWindowController.swift
class SettingsWindowController: NSWindowController {
    convenience init() {
        let window = NSWindow(
            contentRect: NSRect(x: 0, y: 0, width: 600, height: 400),
            styleMask: [.titled, .closable, .resizable],
            backing: .buffered,
            defer: false
        )
        window.title = "Settings"
        window.fullSizeContentView = true // 关键配置
        self.init(window: window)
    }
}

限制：macOS 26+ 才有 Liquid Glass,低版本会优雅降级成普通材质。如果你不需要 Liquid Glass,可以忽略这部分,用标准的 SwiftUI WindowGroup。

FAQ：低版本如何降级?skill 里会提供 fallback 代码,检查系统版本后选择不同材质。如何添加 sidebar?用 NavigationSplitView,skill 里会有完整示例。

auto-update 模块：Sparkle 自动更新集成

auto-update 模块解决 Sparkle 自动更新集成的时机问题。SPUStandardUpdaterController 必须在 applicationDidFinishLaunching 返回前创建,否则更新检查会失败。这个细节 WWDC 和 Sparkle 文档里都有,但 Agent 容易忽略,导致用户看不到自动更新提示。

典型用法：UpdaterManager 单例 + Info.plist 配置 + EdDSA 密钥生成。skill 里提供了 UpdaterManager.swift,可以直接拷到项目里用。

流程：

1. 添加 SPM 依赖(Sparkle)
2. 创建 UpdaterManager 单例
3. 配置 Info.plist(SUFeedURL、SUPublicEDKey)
4. 生成 EdDSA 密钥(Sparkle sign_update)
5. 添加 UI(settings toggle + menu bar button)

代码示例(skill 里会提供完整文件)：

// UpdaterManager.swift
class UpdaterManager {
    static let shared = UpdaterManager()
    private var updaterController: SPUStandardUpdaterController!

    init() {
        // 必须在 applicationDidFinishLaunching 返回前创建
        updaterController = SPUStandardUpdaterController(
            startingUpdater: true,
            updaterDelegate: nil,
            userDriverDelegate: nil
        )
    }
}

限制：仅适用于 Mac App Store 外分发。如果你要上架 App Store,不能用 Sparkle,得用 App Store 的内置更新机制。

FAQ：如何生成 EdDSA 密钥?用 Sparkle 的 sign_update 工具,skill 里会有详细步骤。如何测试更新?本地搭建 feed 服务器,或者在 release 后手动触发更新检查。

notch-ui 模块：刘海区 Dynamic Island UI

notch-ui 模块解决 MacBook 刘海区的 Dynamic Island 风格悬浮 UI。说白了,就是让 Agent 写出类似 iPhone 14 Pro 的刘海 UI,而不是瞎写一个普通窗口。

具体痛点：特定 NSPanel 配置(borderless、CGShieldingWindowLevel)、屏幕几何数学(刘海位置计算)、自定义形状(凹贝塞尔”耳”曲线)。Agent 不懂的话,会写出位置错误、形状不匹配的刘海 UI。很多 Notch UI macOS SwiftUI 项目都踩过这些坑。

典型用法：borderless NSPanel + CGShieldingWindowLevel + NotchShape。skill 里提供了 NotchWindow.swift + NotchShape.swift,可以直接拷到项目里用。

流程：

1. 创建 borderless NSPanel
2. 设置 CGShieldingWindowLevel
3. 实现 NotchShape(凹贝塞尔”耳”曲线)
4. 添加弹簧动画
5. 提供 fallback pill 模式(无 notch 的 Mac)

代码示例(skill 里会提供完整文件)：

// NotchWindow.swift
class NotchWindow: NSPanel {
    init() {
        super.init(
            contentRect: calculateNotchFrame(),
            styleMask: [.borderless],
            backing: .buffered,
            defer: false
        )
        level = CGShieldingWindowLevel() // 关键配置
        backgroundColor = .clear
    }
}

限制：仅适用于 MacBook notch,其他 Mac(比如 iMac、Mac mini)用 fallback pill 模式。如果你不需要刘海 UI,可以忽略这个模块。

FAQ：无 notch 的 Mac 如何处理?skill 里会提供 fallback pill 模式,显示在顶部中间。如何调整位置?根据屏幕尺寸和刘海位置计算,skill 里会有数学公式。

release 模块：完整发布流水线

release 模块解决 macOS 发布流水线的复杂性。8+ 手动步骤容易遗漏或出错——版本 bump、Archive、Notarize、Export、DMG creation、EdDSA signing、appcast.xml 更新、GitHub release。Agent 不懂的话,会把其中几步漏掉,导致发布失败或更新无法推送。

典型用法：添加 release.json + 运行 Go CLI。skill 里提供了 Go CLI 工具,可以直接用。

流程(8 步)：

1. 版本 bump：更新 Info.plist 和项目文件里的版本号
2. Archive：用 xcodebuild archive 打包
3. Notarize：用 notarytool 提交公证
4. Export：用 xcodebuild -exportArchive 导出 .app
5. DMG creation：用 create-dmg 制作安装包
6. EdDSA signing：用 Sparkle sign_update 筹名
7. appcast.xml 更新：用 Sparkle generate_appcast 更新 feed
8. GitHub release：用 gh release create 发布到 GitHub

命令示例：

# Go CLI
go run github.com/fayazara/macos-app-skills/release/cli@latest

或者手动执行每一步(skill 里会有完整命令清单)：

# Archive
xcodebuild -project MyApp.xcodeproj -scheme MyApp archive

# Notarize
notarytool submit MyApp.zip --apple-id YOUR_ID --password YOUR_PASSWORD --team-id YOUR_TEAM

# Export
xcodebuild -exportArchive -archivePath MyApp.xcarchive -exportOptionsPlist ExportOptions.plist -exportPath .

# DMG
create-dmg --volname "MyApp" --volicon "icon.icns" MyApp.app MyApp.dmg

# EdDSA signing
sign_update MyApp.dmg

# appcast.xml
generate_appcast MyApp.app

# GitHub release
gh release create v1.0.0 MyApp.dmg --title "v1.0.0" --notes "Release notes"

限制：需要 GitHub CLI + Sparkle EdDSA 密钥。如果你没有配置 gh,会卡在最后一步;没有 EdDSA 密钥,会卡在签名步骤。

FAQ：如何配置 release.json?skill 里会提供模板,指定版本号、公证凭据、DMG 配置等。如何处理公证失败?查看 notarytool 的错误日志,skill 里会有排障清单。

子模块拆分

子模块	是什么	解决什么	典型用法	命令	流程	限制	FAQ
是什么	完整发布流水线 + Go CLI	macOS 发布 8 步流程自动化	release.json + Go CLI	go run github.com/fayazara/macos-app-skills/release/cli@latest	版本 bump → Archive → Notarize → Export → DMG → EdDSA → appcast → GitHub	需要 GitHub CLI + Sparkle 密钥	没有 GitHub CLI 怎么办?手动发布到 GitHub
解决什么	8+ 手动步骤易错漏	Agent 遗漏步骤导致发布失败	加载 skill,按流程执行	无特定命令,按步骤清单	执行每一步 → 检查错误 → 迭代处理	流程不可跳步	某一步失败了怎么办?看 skill 里的排障清单
典型用法	release.json + Go CLI	标准发布实现	添加 release.json,运行 CLI	见上方代码块	配置 → 运行 → 检查结果	release.json 需手动配置	release.json 怎么写?skill 里有模板
CLI	Go CLI 工具	自动化发布流程	一行命令完成发布	go run github.com/.../cli@latest	执行 CLI → 等待完成 → 检查结果	Go 环境	没有 Go 怎么办?手动执行每一步
流程	8 步发布流程	清晰的步骤清单	按步骤执行或用 CLI	无特定命令,流程是逻辑	bump → Archive → Notarize → Export → DMG → EdDSA → appcast → GitHub	步骤顺序不可改	步骤顺序能改吗?不建议,按 skill 流程
限制	GitHub CLI + Sparkle 密钥	说明前提条件	检查 gh 和密钥配置	gh --version、sign_update --help	检查 → 配置 → 执行	缺少工具会卡住	如何配置 Sparkle 密钥?用 sign_update 工具
FAQ	release.json 配置、公证失败	常见问题解答	用 skill 里的模板和排障清单	无特定命令	查模板 → 配置 → 处理错误	公证可能失败多次	公证失败怎么办?查看 notarytool 日志

三大竞品对比：选哪个 skill 包？

除了 macos-app-skills,还有两个类似的 skill 包：fireworks-macapp-creator 和 claude-swift-skills。三个项目定位差异明显,适用场景不同。

定位差异

项目	定位	模块数	特点
macos-app-skills	功能模块化,专注 macOS 特定场景	7 个模块	build、macos-patterns、settings-ui、auto-update、notch-ui、release、安装接入
fireworks-macapp-creator	架构 + 样式系统 + 脚手架工具	8 种样式	Python 脚手架工具、SwiftUI-first + AppKit interop、样式驱动 UI
claude-swift-skills	Swift 全栈 + iOS/macOS + WWDC 2025	22 个技能	Swift 6.2、SwiftUI、SwiftData、Liquid Glass、Foundation Models、iOS/macOS 跨平台

适用场景对比

场景	macos-app-skills	fireworks-macapp-creator	claude-swift-skills
仅 macOS 应用	✅ 推荐	✅ 可用	⚠️ 过重,包含 iOS
macOS + iOS 跨平台	❌ 不支持 iOS	❌ 不支持 iOS	✅ 推荐
需要发布流水线	✅ 有 release 模块	⚠️ 有但不如 macos-app-skills 详细	⚠️ 有 macos-distribution
需要样式系统	❌ 无样式系统	✅ 8 种预置样式	❌ 无样式系统
需要 WWDC 2025 特性	⚠️ 有部分(Liquid Glass)	⚠️ 有部分	✅ 完整覆盖 WWDC 2025
需要脚手架工具	❌ 无脚手架	✅ Python 工具生成 SwiftPM 项目	❌ 无脚手架

推荐结论

说实话,选择主要看三个因素：平台范围、功能需求、WWDC 特性覆盖。

仅 macOS 应用：选 macos-app-skills 或 fireworks-macapp-creator。如果你需要发布流水线和刘海 UI,选 macos-app-skills;如果你需要完整脚手架和样式系统,选 fireworks。

macOS + iOS 跨平台：选 claude-swift-skills。它是唯一覆盖 iOS 的,包含 Foundation Models(本地 LLM)、技术栈验证器、PRD 架构工具等 22 个技能。

需要 WWDC 2025 特性：选 claude-swift-skills。它完整覆盖 WWDC 2025,包括 Liquid Glass、Swift 6.2、SwiftData 新特性等。

我之前试过这三个包,发现各有优缺点。macos-app-skills 最轻量,适合快速上手;fireworks-macapp-creator 最完整,适合新项目;claude-swift-skills 最全面,适合跨平台和 WWDC 特性。最终选择还是看你的具体需求。

结论

macos-app-skills 是 AI Agent 开发原生 macOS 应用的必备工具。它把 7 个模块(build、macos-patterns、settings-ui、auto-update、notch-ui、release、安装接入)固化成细粒度契约表,让 Agent 第一次就做对,不用反复试错。它把 7 个模块(build、macos-patterns、settings-ui、auto-update、notch-ui、release、安装接入)固化成细粒度契约表,让 Agent 第一次就少踩坑。真正要落地时,你仍然要看本机 Xcode、Swift、签名、公证、Sparkle 密钥和 Agent 自身能力,不要把 skills 当成自动发布保证。

选择建议：仅 macOS 应用选 macos-app-skills 或 fireworks,macOS + iOS 跨平台选 claude-swift-skills,需要发布流水线选 macos-app-skills,需要样式系统选 fireworks,需要 WWDC 2025 特性选 claude-swift-skills。

下一步行动：安装 macos-app-skills(npx skills add fayazara/macos-app-skills -g -y),根据需求选择竞品,参考 AGENTS.md 最佳实践。如果遇到问题,查 skill 里的 FAQ 和排障清单。