AI 开发五大核心技能工具组合打法 · 从代码规范到产品交付

一人开发者或小团队用 AI 写代码，常见问题不是「模型不够聪明」，而是 质量参差不齐、安全漏洞频出、UI 粗糙、交付混乱：Agent 一口气改十个文件、第三方 Skill 悄悄读 .env、界面全是紫粉渐变卡片、功能做完了却没人测。下面这套 五大工具组合打法，按场景选配，帮你把 AI 产出拉到可维护、可上线、可审计的水准。

问题场景

痛点	典型表现	后果
代码乱改	无关重构、风格突变、无法 review	技术债、回滚困难
安全失守	第三方 Skill 执行可疑脚本、泄露密钥	供应链风险、合规事故
UI 廉价感	模板审美、间距混乱、无障碍缺失	用户不信任、品牌受损
交付无流程	没有 MVP 边界、没有测试、没有验收	永远做不完或上线翻车
工具堆叠	五个工具全开，反而更慢	overkill、上下文爆炸

结论：需要的是 分工清晰的工作流增强层，而不是再找一个「更聪明的模型」。OpenCode、Cursor Agent、Oh My OpenAgent 等负责写代码；下面五个工具负责 怎么改、是否安全、是否像产品、是否测过。

五大工具分工矩阵

工具	解决什么痛点	核心机制	常驻 or 按需
Karpathy Guidelines	乱改、过度重构、改动不可验证	手术式修改：假设 / 范围 / 成功标准	常驻（AGENTS.md / Rules）
Superpowers	没设计就写码、没测试就合并	TDD 驱动完整流程：澄清 → 拆解 → 测试 → 审查 → 收尾	复杂工程 按需启用
Skill Vetter	第三方 Skill/插件带毒	先审计后安装	每次接入外部 Skill 必过
GStack	单点开发、缺 PM/设计/QA	虚拟团队：CEO / 工程经理 / 设计师 / QA	新产品 按需启用
微软前端设计审查	UI 粗糙、AI 味、无障碍差	12 项设计维度 + 反模式检测	有界面前 上线前必过

实战组合场景

场景一：日常编码（修 Bug、小功能）

Karpathy Guidelines（常驻） → Superpowers（TDD 流程）

怎么做

1. 项目 AGENTS.md 写入手术式修改原则（假设、范围、成功标准）
2. 打开 Superpowers：brainstorming 快速对齐 → writing-plans 拆 2–5 分钟任务
3. test-driven-development：先红后绿，verification-before-completion 再声称完成
4. 合并前 requesting-code-review 对照计划

不必开：GStack（无新产品叙事）、微软设计审查（无 UI 变更）、Skill Vetter（未装新 Skill）

---

场景二：第三方集成（新 Skill / 插件 / MCP）

任何外部 Skill/插件 → Skill Vetter 安全审计 → 通过后再安装

怎么做

1. 拿到 SKILL.md 与附属脚本，先 不要 写入 .cursor/skills/ 或 opencode.json
2. Skill Vetter 扫描：bash/curl、读写路径、环境变量、外网请求
3. 人工确认合理权限后安装；版本升级 重新审计
4. 若 Skill 会改代码，继续叠加 Karpathy + Superpowers

安全敏感项目：Vetter 贯穿全流程，plugin 数组变更走 PR + 审计记录。

---

场景三：新产品开发（0 → 1 可上线）

GStack（产品团队模拟） → Superpowers（工程迭代） → 微软设计审查（UI 把关）

怎么做

1. GStack · CEO：定 MVP 3～5 条，其余进 backlog
2. GStack · 工程经理：模块划分、里程碑、技术风险
3. GStack · 设计师：反 AI 味约束（可叠加 UI Skills 目录 Skill）
4. Superpowers：按里程碑 TDD 迭代，worktree 隔离
5. 微软设计审查：上线前 12 维扫一遍，输出修复清单
6. GStack · QA：边界用例 + 回归

第三方 Skill（如 Superpowers、Oh My OpenAgent）：在第 4 步前已过 Skill Vetter。

---

场景四：项目上线前（已有代码，冲刺发布）

Karpathy Guidelines（代码审查） + 微软设计审查（UI） + GStack QA 环节

怎么做

1. 代码侧：用 Karpathy 原则做最后一轮 diff 审查——是否最小改动、是否有成功标准、测试是否覆盖
2. UI 侧：12 维设计审查，重点Accessibility、响应式、反渐变/卡片堆叠
3. GStack QA：验收用例、错误态、空态、权限边界
4. Superpowers 的 verification-before-completion：所有「已完成」须有命令输出证据

---

场景五：安全敏感项目（金融、医疗、企业内网）

Skill Vetter 贯穿全流程 + Karpathy（可审计小步改动） + Superpowers（测试证据）

怎么做

• 新依赖、新 Skill、新 MCP：一律先 Vetter
• 改动遵循手术式原则，每次 PR 附假设与验证命令
• 禁止「大补丁一次性合并」；Superpowers TDD 强制留测试痕迹
• UI 若涉及用户数据展示，叠加微软设计审查中的表单与错误态检查

最佳实践建议

1. 常驻 Karpathy 规范 — 写进 AGENTS.md 或 Cursor Rules，所有 Agent 会话默认遵守
2. 第三方 Skill 必过 Vetter — 无例外；内部自研可等价人工评审并留档
3. 产品开发启用 GStack — 先角色、后编码，避免直接「帮我写一个完整 App」
4. UI 项目必配微软设计审查 — 与 UI Skills 目录 Skill 互补，上线前 checklist 化
5. 复杂工程采用 Superpowers — 需要多文件、多模块、要维护半年以上的，走完整 TDD 流程

避坑指南

坑	说明
五工具全开	修一个 typo 也走 GStack + 12 维审查 = 浪费时间；分场景选配
Karpathy 用于探索原型	手术式修改会拖慢 0→1 试错；原型阶段可放宽，定型后再收紧
GStack 做微小改动	改配置、单文件 patch 不需要 CEO/QA 全套
微软审查用于 CLI	无界面则跳过；后端 API 用测试与 OpenAPI 契约代替
Vetter 替代信任	完全自控的内部工具链可简化，但 外部 Skill 不要跳过
只要 Superpowers 不要规范	有流程仍可能乱改文件；Karpathy 与 Superpowers 叠加 效果最好

与编码 Agent 平台的关系

平台	定位	与本打法关系
OpenCode	开源终端/IDE 编码 Agent	宿主；通过 plugin 装 Superpowers、Oh My OpenAgent
Cursor Agent	IDE 内 Agent	宿主；Rules 写 Karpathy 规范，Skills 目录装审计过的包
Oh My OpenAgent	多 Agent 编排	分工执行；与 GStack 角色理念相近，可二选一或组合
Claude Code / Codex	其他 harness	Superpowers 分 harness 安装；安全与 UI 层同样适用

关键判断：这五个工具 不替代 具体编码 Agent，而是 工作流层增强——让同一份模型能力产出更专业、更安全、更像产品的结果。先选好宿主 Agent，再按上表挂规范、流程、审计与审查。

| 下一步
|

你想…	建议入口
立规矩	Karpathy Guidelines — 写入 AGENTS.md
走工程流程	Superpowers — OpenCode / Cursor 安装
审 Skill	Skill Vetter — 接入前扫描
做完整产品	GStack — CEO → 工程经理 → 开发 → QA
救 UI	微软前端设计审查 + UI Skills
配 OpenCode	OpenCode 工具页 — plugin 集成说明