来源

这篇解决什么问题

这篇笔记解决的是：在准备开发一个 Mac 微信 AI 群回复机器人时，如何选择和组合几类 AI 编码工作流工具。

这个项目不是单纯写一个脚本。它同时涉及需求澄清、安全边界、macOS UI 自动化、误发风险、AI Provider 抽象、测试和知识库沉淀。因此，单靠“让 Agent 直接写代码”容易跑偏，需要先判断哪些工具负责定规格，哪些工具负责推进交付，哪些工具只适合作为配置和组织方式参考。

更深一层看，这四类工具并不是同一个抽象层的竞争品。它们分别解决的是 AI 编程里不同阶段的控制问题：

如果把它们混在一起比较，很容易得出“哪个更强”的误判。更准确的问题应该是：当前项目最缺的是推进力、规格纪律、能力组织，还是执行节奏。

一句话定位

对比表

技术层面的关键差异

1. 状态管理方式不同

GSD 更像项目推进器，关心的是当前任务从需求到交付的状态流转。它会推动拆任务、分配 agent、落地代码、跑测试、整理结论。

OpenSpec 更像变更账本，关心的是“为什么改、改什么、怎么验收”。它适合维护需求、接口和行为约束的长期一致性。

Everything Claude Code 更像工作台模板，关心的是把可复用能力装进项目：有哪些 agent、有哪些 slash commands、有哪些 hooks、哪些上下文文件会被自动读入。

Superpowers 更像执行纪律，关心的是每一步有没有先澄清、有没有规格、有没有测试、有没有检查点。它不是替你决定做什么，而是约束你怎么做。

2. 产物形态不同

这意味着它们可以组合，但不应该互相替代。比如 OpenSpec 可以定义“机器人什么时候回复”，GSD 可以安排多个 agent 并行实现，Everything Claude Code 可以提供 agent 和 command 模板，Superpowers 可以要求每一步先有验收标准。

3. 风险控制方式不同

对微信 AI 群回复机器人这种项目，最大的风险不是功能做不出来，而是误发消息、权限过大、UI 自动化不稳定、未来维护困难。

每个工具的实用案例

GSD 案例：把微信机器人从想法推到可运行 MVP

场景：用户只有一句需求，“群里有人 @机器人或者提到名字时，机器人自动回复”。这个需求听起来简单，但真正落地至少包含 UI 读取、触发判断、AI 回复、发送保护、配置、测试、文档。

用 GSD 的方式处理，不是先写代码，而是把目标拆成交付链：

实际产物可以是：

doc-writer: 写 Obsidian 工具对比文档
ui-agent: 实现 WeChatUIAdapter
bot-core-agent: 实现 config/trigger/bot
provider-agent: 实现 Echo/OpenAI/Ollama + CLI
review-agent: 审查误发风险和安全边界

这个案例里，GSD 的价值是把“想做一个机器人”变成“多个可并行交付的工程切片”。它最适合解决执行推进问题，尤其是当任务容易在需求、实现、测试、文档之间来回跳的时候。

OpenSpec 案例：给“什么时候回复”建立可演进规范

场景：第一版机器人只在 @小助手 或提到“小助手”时回复。过几天用户可能会要求：

如果没有规范，代码会很快变成一堆布尔开关。OpenSpec 的做法是把行为写成变更规格，而不是直接在代码里堆逻辑。

一个简化 spec 可以长这样：

## Capability: Mention-triggered replies

### Requirement: Reply only when addressed
The bot MUST generate a reply only when a message contains one of:
-`@<bot_name>`
-`＠<bot_name>`
- a configured plain-text alias

### Requirement: Ignore self messages
The bot MUST NOT reply to messages where sender is in `bot.self_names`.

### Requirement: Prevent repeat replies
The bot MUST keep a bounded processed-message set keyed by group, sender, and text.

### Requirement: Dry-run by default
The bot MUST NOT send to WeChat unless the operator explicitly passes `--send`.

这个案例里，OpenSpec 的价值是让需求变更有地方落。以后如果要加“知识库检索”，不是直接改 Provider，而是先新增 capability：

## Capability: Retrieval-augmented reply

The bot SHOULD retrieve local notes before generating a reply when retrieval is enabled.
The bot MUST disclose low-confidence answers instead of inventing facts.

这样开发者、Agent、测试都能围绕同一份规格工作。OpenSpec 最适合那些会持续演进、而且不能靠口头约定维护边界的项目。

Everything Claude Code 案例：为项目建立可复用 Agent 工作台

场景：微信机器人项目不是一次性脚本。后续可能要继续加功能，比如多群轮询、知识库检索、消息摘要、错误日志、UI 适配不同微信版本。

Everything Claude Code 的价值不在于“直接拿来全量安装”，而在于它展示了一种能力组织方式：把 agent、commands、skills、hooks、上下文文件变成项目资产。

对当前项目，可以借鉴出一个轻量结构：

.claude/
  agents/
    ui-agent.md
    bot-core-agent.md
    provider-agent.md
    review-agent.md
  commands/
    test.md
    dry-run.md
    safety-check.md
  skills/
    macos-accessibility.md
    provider-integration.md
  hooks/
    before-send-check.md

这些文件不一定马上创建，但职责可以先设计清楚：

一个实用命令也可以这样定义：

/safety-check
Run tests and search source for forbidden APIs:
task_for_pid, mach_vm_read, mach_vm_write, codesign, sqlite3, db_storage

这个案例里，Everything Claude Code 的价值是把“怎么和 Agent 协作”变成项目内的配置，而不是每次靠临时口头分工。它适合团队或长期项目，尤其适合把高频流程沉淀成命令和技能。

Superpowers 案例：把高风险功能拆成可验收小技能

场景：真实发送微信消息是高风险动作。如果让 Agent 一步到位实现“读消息并发送”，很容易出现误发：焦点不在微信、群切错、剪贴板被覆盖、旧消息重复触发。

Superpowers 的思路是先把能力拆成可独立验证的小技能，并设置检查点：

Skill 1: 读取当前群最近消息
验收：只打印消息，不发送，不写剪贴板。

Skill 2: 判断是否触发
验收：@名字、全角@、别名能触发；普通消息不触发；自己消息不触发。

Skill 3: dry-run 回复
验收：命中后只打印将要回复的文本。

Skill 4: 真实发送
验收：必须显式 --send；发送前确认当前 app、当前群、输入框状态。

对应到代码，Superpowers 会要求先实现这样的测试，而不是先写 UI 自动化：

deftest_runner_defaults_to_dry_run():
    runner = BotRunner(config, adapter, provider)
    runner.run_once()
assert adapter.sent ==[("reply",True)]

deftest_ignores_self_messages():
assertnot should_respond(Message("我","@bot"), names=("bot",), self_names=("我",))

这个案例里，Superpowers 的价值是降低执行失控风险。它不只是“多问问题”，而是把每个危险动作变成有前置条件、有验收、有回滚余地的小步骤。对涉及本机 UI、外部账号、消息发送、文件删除、付费 API 的项目尤其有用。

怎么用于微信机器人项目

推荐组合是：OpenSpec/Superpowers 定规格，GSD 推进交付，Everything Claude Code 借鉴配置和 agent 组织方式。

具体到当前项目：

对当前项目的取舍

不建议全量照搬任何一个体系。

这个微信机器人项目的高风险点不是代码量，而是误触发、误发送、权限过大和维护脆弱性。因此，流程应该服务于几个明确目标：

结论

当前项目最适合采用轻量组合：

这样既能利用 AI 编码工作流的优点，又不会为了流程本身拖慢开发。对微信 AI 群回复机器人来说，正确顺序是：先明确安全边界和触发规则，再做 dry-run，再做真实发送。

可复用到后续项目的判断