技能使用指南

orchestration（以太坊dApp开发）Skill 是什么？如何安装使用？

以太坊dApp开发Skill把Scaffold-ETH 2开发拆成合约、前端、生产三阶段，内置密钥泄露自查、三按钮交互流程与UX规范，还能落地ERC-8004加x402代理支付范式。本文讲清安装验证步骤、核心功能、竞品对比与真实场景体验，帮你少走弯路，快速上手AI驱动的链上应用交付。

以太坊dApp开发Skillorchestration
8 个章节 约 18 分钟阅读 AI 智能生成

以太坊dApp开发Skill：用三阶段流水线把合约、前端与生产部署一次走通

  • 它是什么：这是一个面向 AI 代理的「dApp 编排」技能，把 Scaffold-ETH 2（简称 SE2）的完整开发流程拆成合约 → 前端 → 生产三个阶段，每个阶段都有明确的验证门，避免 AI 一上来就乱写代码。
  • 它解决什么：通用 AI 写 dApp 时最常犯的错，是编辑 SE2 自动生成的 deployedContracts.ts、绕开 Scaffold 钩子直接用原始 wagmi、跳过阶段直接上线、把私钥和 API Key 提交到 Git。
  • 它的特色：内置密钥泄露自查命令、三按钮交互流程（切网络 → 授权 → 执行）、UX 规范（人类可读金额、加载态、禁用无限授权），以及 ERC-8004 + x402 的「AI 代理商业」端到端范式。
  • 适合谁：独立开发者、黑客松团队、Web3 前端工程师，以及想让 AI 代理自动完成链上应用交付的团队。
  • 一句话结论：它更像一位「严格要求你的链上项目技术负责人」，你按它的阶段走，出问题的概率会明显下降。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

基本信息

项目 内容
技能中文名 以太坊dApp开发Skill
技能英文名 orchestration
技能ID 13691
技能定位 AI 代理规划、构建、部署完整以太坊去中心化应用的三阶段编排系统
依托框架 Scaffold-ETH 2（合约 + Next.js 前端 + IPFS/Vercel 部署）

它到底解决什么问题？

在真实开发中，「让 AI 帮我写个 dApp」经常得到这样的结果：合约能编译，前端能跑，但一接钱包就报错；或者代码能上线，但仓库里躺着明文私钥。原因不是模型不会写 Solidity，而是 SE2 有自己的一套强约定，通用建议在这里基本失效：deployedContracts.ts 由工具自动生成不能手改，读写要用 useScaffoldReadContract、useScaffoldWriteContract 这套钩子而非原始 wagmi，外部合约必须提前登记到 externalContracts.ts。这个技能把这些约定固化成「必须遵守的规则」，让 AI 代理按规矩干活。

一键安装的思路与步骤

AI 技能的本质是一份结构化的「操作手册 + 约束条件」，安装后由 AI 编程助手在合适的场景自动加载。通用流程如下（具体命令、入口与权限以官方说明为准）：

  1. 确认前提：你已经使用支持「技能（Skill）」机制的 AI 编程助手或代理运行时，并且本地具备 Node.js 与包管理器环境；若要部署真实合约，还需要一个可用的钱包与少量真实 ETH。
  2. 获取技能：在技能市场或团队内部技能库中，按技能ID 13691 或英文名 orchestration 检索，选择安装/添加（入口与操作按钮以官方说明为准）。
  3. 绑定项目：在对话中说明你要做的是 Scaffold-ETH 2 项目，或直接让它「按三阶段流程构建一个 dApp」，让技能被正确触发。
  4. 验证是否生效：提一个试探性问题，例如「SE2 里 deployedContracts.ts 能手动改吗？」或「外部合约应该放在哪个文件？」。如果回答能明确说出「不能编辑、自动生成」和「externalContracts.ts」，说明技能已被加载。
  5. 再验一层：让它复述三个阶段与阶段回退规则（阶段3出错回阶段2、阶段2合约出错回阶段1）。能答对，就可以正式开工了。

需要提醒的是：安装技能不等于装好工具链。技能负责「怎么想、怎么写、怎么不走错路」，而 npx create-eth@latest、yarn chain、yarn deploy 这些命令仍然在你的本地终端里真实执行。

该技能的主要功能和特点

  • 三阶段构建系统（核心骨架）：阶段1在本地分叉上快速迭代合约与 UI；阶段2把合约部署到主网或 L2、用真实状态验证并优化 UI；阶段3把前端发布到 IPFS/Vercel 做最终质量保证。三阶段之间有硬性验证门，禁止跳过或合并。
  • SE2 约定守护：明确区分「自动生成的文件」与「你应该编辑的文件」，把 deployedContracts.ts（勿动）、externalContracts.ts（动它）、hooks/scaffold-eth/（用它们）、scaffold.config.ts（主配置）的职责讲清楚。
  • 强制使用 Scaffold 钩子：提供读、写、事件三类钩子的标准写法，包括 watch: true 实时监听、onBlockConfirmation 确认回调，避免 AI 退回原始 wagmi 写法导致状态不同步。
  • 三按钮交互规范：任何代币交互只显示一个按钮——链错了先切网络，授权不足先批准，条件满足后才执行动作；严禁同时摆出「批准」和「执行」两个按钮。
  • UX 硬性规则：显示用 formatEther() / formatUnits()、传参用 parseEther() / parseUnits()；所有异步操作必须有加载态；待处理交易期间禁用按钮（区块确认通常 5–12 秒）；禁止无限授权，只批准确切金额或 3–5 倍。
  • 密钥安全护栏：覆盖钱包私钥、Alchemy/Infura/Etherscan/WalletConnect 密钥、内嵌密钥的 RPC URL、OAuth 令牌等全部凭证，并点名 SE2 最典型的坑——scaffold.config.ts 里的 rpcOverrides 会被提交到 Git。技能给出 git diff --cached + grep 的一整套提交前自查命令，以及必须写入 .gitignore 的条目清单。
  • 阶段过渡规则：生产环境发现 bug 不是就地手改，而是退回上一个阶段修、补回归测试、再重新部署，避免「在生产环境打补丁」这种最危险的操作。
  • 前沿范式内置：给出 ERC-8004（代理身份与信誉）+ x402（HTTP 原生支付）的完整六步循环——发现、信任、调用、支付、接收、评分，并附 TypeScript 代理实现骨架，覆盖「代理之间自主付费调用」的 agent 经济场景。

和普通「让 AI 直接生成 dApp 代码」相比，它强在约束与顺序：不是给你更多代码，而是告诉你哪些代码不该写、哪一步不该跳、哪个文件不该动。

如何使用该技能？

以下为典型调用流程，命令来自技能提供的 SE2 标准工作流。

第 1 步：触发技能并锁定场景

在对话里明确说明：我要用 Scaffold-ETH 2 构建一个以太坊 dApp，请按三阶段流程推进。技能被触发后，AI 会先确认网络目标（主网还是某个 L2）与功能范围，而不是直接开始写合约。

第 2 步：阶段1——脚手架与合约

npx create-eth@latest my-dapp
cd my-dapp && yarn install
yarn chain          # 终端1：本地节点
yarn deploy         # 终端2：部署合约

按技能的「关键步骤」清单推进：在 packages/foundry/contracts/（或 Hardhat 对应目录）编写合约 → 写部署脚本 → 在动前端之前把所有外部合约登记进 packages/nextjs/contracts/externalContracts.ts → 补齐测试（目标覆盖率 ≥90%）→ 做安全审计。验证标准是：yarn deploy 成功、deployedContracts.ts 自动生成、测试全绿。

第 3 步：阶段1——前端

yarn chain           # 终端1
yarn deploy --watch  # 终端2：合约变更自动重新部署
yarn start           # 终端3：Next.js 跑在 localhost:3000

读写统一走 Scaffold 钩子，例如读取余额：

const { data } = useScaffoldReadContract({
  contractName: "YourContract",
  functionName: "balanceOf",
  args: [address],
  watch: true,
});

写入代币操作时，让 AI 按「切网络 → 授权 → 执行」三按钮流程实现，并用 isMining 控制按钮禁用状态。验证标准是：完整用户旅程在本地用真实钱包跑通，边缘情况（余额不足、用户拒绝、交易回滚）都有可读的错误提示。

第 4 步：提交前跑密钥自查

git diff --cached --name-only | grep -iE '\.env|key|secret|private'
grep -rn "0x[a-fA-F0-9]\{64\}" packages/ --include="*.ts" --include="*.js" --include="*.sol"
grep -rn "g.alchemy.com/v2/[A-Za-z0-9]" packages/ --include="*.ts" --include="*.js"
grep -rn "infura.io/v3/[A-Za-z0-9]" packages/ --include="*.ts" --include="*.js"

有任何命中就停下来，把密钥搬进 .env、把 .env 写进 .gitignore。同时确保 RPC 走环境变量：

rpcOverrides: {
  [chains.base.id]: process.env.NEXT_PUBLIC_BASE_RPC || "https://mainnet.base.org",
},

第 5 步：阶段2——真实合约 + 本地 UI

更新 scaffold.config.ts 的 targetNetworks → yarn generate 生成部署者钱包 → yarn account 查看地址 → 打入小额真实 ETH → yarn deploy --network mainnet → yarn verify --network mainnet → 用真实钱包以 1–10 美元额度小额试跑 → 优化 UI（去掉 SE2 默认品牌、自定义样式）。

第 6 步：阶段3——生产部署与质检

部署前确认 onlyLocalBurnerWallet: true（防止生产环境暴露燃烧器钱包）、更新标题/描述/OG 图（1200×630）、测试值恢复为生产值。然后二选一：

yarn ipfs                    # 去中心化部署到 IPFS
cd packages/nextjs && vercel # 快速部署到 Vercel

最后按清单质检：公共 URL 可访问、钱包连接与切网正常、读写合约可用、无控制台错误、无燃烧器钱包入口、链接预览 OG 图正常、移动端响应式、在 MetaMask / Rainbow / WalletConnect 上分别验证。

同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
以太坊dApp开发Skill（orchestration） AI 代理的 SE2 三阶段开发编排规范 阶段化流程 + 验证门、Scaffold 钩子规范、密钥安全护栏、ERC-8004/x402 范式 需在支持技能的 AI 助手中安装，本地需 Node 与钱包环境 AI 参与或主导的 dApp 全流程构建、黑客松、代理经济应用 优势：约束明确、防坑能力强、自带安全自查；不足：强绑定 SE2，非 SE2 项目收益有限
通用大模型直接生成代码 通用编码助手 按提示生成合约、前端、脚本 无需安装技能，开箱即用 快速出原型、单文件小脚本 优势：零门槛；不足：不了解 SE2 约定，容易手改自动生成文件、用错钩子、泄露密钥
Scaffold-ETH 2 官方文档自学 权威一手资料 完整 API、组件库、示例与教程 免费，需自行阅读与实践 系统学习、查证细节 优势：最准确、覆盖最全；不足：需要人自己组织顺序，AI 不会自动遵守其中的纪律
低代码/托管式 Web3 平台 可视化搭建 dApp 前端与合约模板 拖拽组件、预置合约模板、托管部署 门槛最低，多为账号注册即用 展示型页面、快速验证商业想法 优势：上手快；不足：定制深度有限，复杂合约逻辑与自托管部署受限

选择建议：如果你的项目就用 SE2，且希望 AI 真正参与交付而不是「写完一堆跑不起来的代码」，这个技能的价值最直接；如果只是做个一次性演示页，低代码平台更省事。

该技能的典型应用场景与实际体验情况

场景一：黑客松团队（48 小时交付）

角色是 2–3 人的小团队，痛点是时间紧、前端同学不熟链上交互、容易在最后两小时发现合约地址没同步。使用方式是让 AI 按阶段1先跑通本地闭环，再一次性推进到阶段2、阶段3。实际体验：上手难度低，yarn deploy --watch 配合 Scaffold 钩子让前后端联调几乎无摩擦；需注意的是黑客松里最容易忽略的是密钥检查那一关，务必在第一次 git commit 前就跑一遍自查命令。

场景二：独立开发者的正式产品上线

角色是独立开发者，痛点是「本地能跑、上线就炸」，尤其是隐私和授权逻辑。使用方式是严格执行阶段2的小额真金测试（1–10 美元）和阶段3的部署前清单。实际体验：效果最明显的是三按钮流程和禁止无限授权这两条，用户误操作导致的失败交易显著减少；注意事项是 onlyLocalBurnerWallet: true 这一项千万别漏，否则生产环境可能把燃烧器钱包暴露给访客。

场景三：AI 代理经济应用（付费 API 调用）

角色是想做「代理自动购买服务」的团队，痛点是传统 API 需要账号、密钥、订阅和发票，代理之间无法自主结算。使用方式是按技能给出的六步循环实现：查 ERC-8004 身份注册表发现服务 → 查信誉注册表按在线时长与质量过滤 → 请求端点收到 402 → 用 EIP-3009 授权签名支付（Base 上 gas 约 0.001 美元量级）→ 收到 200 与交易哈希 → 回写链上评分。实际体验：这是一套门槛偏高的范式，需要理解 402 支付流程与信誉读取接口；技能的价值在于把「发现—信任—支付—评分」的顺序和关键合约地址、调用方式一次讲清，避免在文档间反复横跳。

场景四：教学与训练营

角色是讲师或学员，痛点是学员拿到一堆命令却不知道先后顺序。使用方式是把三阶段当作课程大纲，每阶段结束用技能给的验证门做一次检查。实际体验：阶段过渡规则（阶段3出错回阶段2、阶段2合约出错回阶段1）特别适合纠正「哪里报错就在哪里硬改」的坏习惯。

该技能能为用户带来的价值

  • 效率提升：把「查文档—试错—回滚」的循环压缩成有顺序的清单，合约到前端再到上线的路径不再反复推倒重来；--watch 自动重部署与自动生成类型文件，让联调几乎零手工同步。
  • 门槛降低：不熟悉 SE2 的新人也能照着三阶段推进，钩子用法、外部合约登记、部署命令这些「隐性知识」被写成了显式规则。
  • 风险成本下降：密钥泄露的代价往往是资金被瞬间抽干，而技能把提交前自查做成了固定动作；禁止无限授权、待处理交易禁用按钮、人类可读金额等规则，直接减少用户资产风险与失败交易。
  • 质量下限抬高：≥90% 测试覆盖率、区块浏览器验证、多钱包兼容检查、移动端响应式，这些「容易被省略的收尾工作」被列成清单，交付质量不再依赖个人自觉。
  • 长期价值：三阶段与回退规则是一套可复用的工程方法论，迁移到其他链上项目同样成立；而 ERC-8004 + x402 部分则提前布局了代理经济这一新兴方向。

常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？

在支持技能机制的 AI 助手中，按技能ID 13691 或英文名 orchestration 检索并添加即可，具体入口、权限与是否收费以官方说明为准。技能本身只是「操作手册」，不包含链上服务；使用中产生的费用来自真实的 gas、RPC 服务等第三方开销。

Q2：它和直接让 AI 写 dApp 代码有什么区别？

区别在约束。通用 AI 会给你能编译的代码，但不保证符合 SE2 约定——比如去改自动生成的 deployedContracts.ts、用原始 wagmi 导致状态不同步、跳过阶段直接上线、把密钥写进配置文件。这个技能把这些错误提前列为禁令，并用阶段验证门把关。

Q3：不用 Scaffold-ETH 2 的项目能用吗？

价值会打折。技能的核心是 SE2 的三阶段流程、目录结构和 Scaffold 钩子；如果你用的是其他框架，其中「密钥安全自查」「三按钮交互流程」「UX 规则」「阶段回退思路」仍然通用，但具体命令与文件路径不适用。

Q4：密钥已经不小心提交了怎么办？

立即停止后续提交，把泄露的密钥视为已失效：作废并重新生成对应的 API Key、转移钱包资金到新地址，然后清理 Git 历史。技能中也有更完整的密钥安全指引与泄露后的处置建议，建议按其中的流程走，不要只在最新一次提交里删掉了事。

Q5：适合谁用？我该选它还是选低代码平台？

适合独立开发者、黑客松团队、需要 AI 深度参与交付的 Web3 团队，以及要做代理付费调用（x402）的探索者。如果你只想快速做一个展示页面、不涉及复杂合约逻辑与自托管部署，低代码平台更省事；只要涉及真实资产与正式上线，这个技能的阶段纪律与安全护栏更值得。