qa（dApp预发布审计）Skill 是什么？如何下载安装使用？

dApp预发布审计Skill：把「AI 写出来的 dApp」交给另一个 AI 按清单复审，上线前拦住那些必踩的坑

它是什么：一个专门针对基于 Scaffold-ETH 2 构建的以太坊 dApp 的预发布审计检查清单技能，只负责审核，不负责写代码。
核心思路：在 dApp 构建完成后，把这份清单交给一个全新的审核代理（或全新上下文），避免「自己写、自己夸」的盲区。
它盯的是什么：不是花哨的架构问题，而是 AI 代理实际反复发布出去的错误——例如用一段文字提示「请连接钱包」而不是渲染连接按钮、批准按钮和操作按钮同时出现、忘记移除 SE2 脚手架品牌、代币金额没有美元换算、移动端点击交易没有跳转钱包。
输出形式：逐项报告 PASS / FAIL，明确区分「阻止发布」与「应修复」两档，只报告不修复，把修改决定权留给开发者。
适合谁用：用 AI 辅助（vibe coding）快速产出 dApp 的独立开发者、黑客松团队、准备交付客户项目的合约/前端小团队。

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

技能中文名：dApp预发布审计Skill 技能英文名：qa 技能ID：13690

它解决的问题非常具体：现在的 AI 代理已经能借助 Scaffold-ETH 2 之类的脚手架，在很短时间内把一个以太坊 dApp 的前端、合约调用和钱包连接流程「糊」出来——但能跑通和能发布是两件事。AI 代理常见的通病是：把连接钱包写成一句提示文字、把批准和操作按钮一起渲染、保留脚手架自带的页脚与标题品牌、忘记显示合约地址、所有金额都不带美元估值、移动端用户点「质押」之后钱包 App 根本没有被唤起。这些不是安全漏洞，却足以让真实用户在第一分钟就放弃你的产品。该技能就是把这些「AI 反复踩的坑」固化成一份可逐项勾选的审计清单。

一键安装的思路与步骤：

确认安装前提：你手上已经有一个构建完成的 Scaffold-ETH 2 项目，包含 packages/nextjs/app/、packages/nextjs/components/、packages/nextjs/contracts/ 等目录；项目能在浏览器中打开并完成基本交互；你使用的 AI 开发工具支持加载外部技能（Skill）。
找到技能入口：在技能库或技能市场中，通过技能ID 13690 或英文名 qa 检索该技能并添加。具体入口地址、账号要求与安装命令请以官方说明为准。
加载到代理：按工具约定的方式把技能挂载到当前会话或独立的审核代理上（常见做法是将技能内容作为系统提示/上下文注入）。不同平台的加载方式与命令以官方说明为准。
验证是否生效：加载后直接问审核代理「请按清单审计这个项目，输出每项的 PASS 或 FAIL」。如果它返回的是一份分成「阻止发布」「应修复」两档的勾选清单，并且明确说明「只报告、不修复」，说明技能已正确生效；如果它只是给出一段泛泛的「你的代码看起来不错」，说明技能没有被加载进去。

一个实用建议：审核一定要开新会话。原会话里那个「刚把项目写完、正在沾沾自喜」的代理，很难客观评价自己的产物；而新上下文中的审核代理只会看到代码和清单，判断会更干净。

该技能的主要功能和特点

只审核、不构建的明确定位：技能在开头就划定边界——审核员的任务是阅读源码、打开应用点击每条流程、逐项判定 PASS/FAIL，不进入修复环节。这避免了「边审边改、改完又破坏别的地方」的混乱。
钱包连接必须是按钮，不是文字：这是技能点名的「AI 代理最常见错误」——渲染 <RainbowKitCustomConnectButton /> 而不是写一句「请连接你的钱包来玩」。判定标准很硬：未连接钱包时，页面上必须有一个大的、明显的连接钱包按钮作为主要 UI 元素。
四状态单按钮流程校验：应用在任一时刻只能显示一个主按钮，并按「未连接 → 连接钱包 / 错误网络 → 切换链 / 需要批准 → 批准 / 就绪 → 操作」的顺序推进。技能明确列出失败样例：批准和操作按钮同时可见、完全没有网络检查导致在错误链上静默失败、用户批准后又重复点击批准。
从代码层面验证按钮状态绑定：它不仅看界面，还要求检查按钮的 disabled 属性是否绑定到 useScaffoldWriteContract 的 isPending，并给出检索命令 grep -rn "useWriteContract" packages/nextjs/——在 scaffold-eth 内部之外出现 useWriteContract 即为错误，因为原始 wagmi 写法在钱包签名时就返回，而不会等待区块确认。
Scaffold-ETH 2 品牌残留清理：逐项检查页脚（BuidlGuidl 链接、“Built with 🏗️ SE2”、“Fork me”、支持链接）、标签标题（必须是应用名，不能是 “Scaffold-ETH 2” 或 “App Name | Scaffold-ETH 2”）、README（必须描述本项目而非 SE2 模板）、网站图标。
合约地址可见性：AI 代理常常显示已连接的钱包地址，却忘了显示用户正在交互的合约地址；技能要求用 <Address/> 组件展示（含 blockie、ENS、复制、区块浏览器链接）。
金额必须带美元估值：任何代币或 ETH 金额（包括输入框）都应显示成 “0.5 ETH (~$1,250)” 这类带 USD 换算的形式——「代理从不主动添加 USD 值」。
OG 图像必须是绝对 URL：images: ["/thumbnail.jpg"] 这类相对路径会导致分享卡片在各种平台上全部失效，技能要求改为绝对生产 URL，并给出 grep -n "og:image\|images:" packages/nextjs/app/layout.tsx 的快速检查方式。
RPC 与轮询的真实性校验：pollingInterval 必须从默认的 30000 改为 3000（否则界面像坏了一样，30 秒才更新一次）；不能使用脚手架自带的默认 Alchemy 密钥；更重要的是——不仅要检查代码里写了 process.env.NEXT_PUBLIC_*，还要确认这些变量在托管平台上真的设置了，否则会回退到公共 RPC 而被限流。技能特别点出 AI 代理的典型错觉：「看到模式匹配就判 PASS，却从没在 Vercel 上设置过变量」。
Phantom 钱包支持：Phantom 不在 SE2 默认钱包列表中，大量用户装了 Phantom，缺失就意味着他们根本连不上，必须在 wagmiConnectors.tsx 中加入 phantomWallet。
移动端深度链接（最硬核的一块）：RainbowKit v2 / WalletConnect v2 不会自动深度链接到钱包 App，必须自行实现。技能给出了完整的 writeAndOpen 辅助函数模式、为什么延迟是 2000ms（需要估算 gas、编码 calldata、通过 WalletConnect 服务器中继）、如何通过连接器 ID + wagmi.recentConnectorId + wc@2:client 会话数据来识别用户究竟用的是哪个钱包，以及五条关键规则：先触发交易、后深度链接；window.ethereum 存在时跳过；必须查 WalletConnect 会话数据；使用简单 scheme（如 rainbow://）而不是 rainbow://dapp/...；包装每一个写入调用而不只是主操作。
基线测试背书：技能说明其覆盖范围是「AI 代理实际发布的错误」，并通过与标准 LLM 的基线测试验证得出——也就是说，清单上的每一条都是被反复验证过的真实高频失败点，而不是拍脑袋的通用建议。

如何使用该技能？

第 1 步：在构建完成后切换到新代理 不要在原会话里继续追问「我的项目有没有问题」。开启一个新的代理会话（或新的上下文窗口），把技能挂载进去。这一步是技能本身的要求：「在构建完成后，将此交给单独的审核代理（或新上下文）」。

第 2 步：提供项目上下文与清单 把你的仓库路径、正在运行的本地或预览地址、目标链信息一并给审核代理。可以这样输入：

这是我用 Scaffold-ETH 2 构建的项目，预览地址是 xxx，目标链是 Base。请按预发布审计清单逐项检查，输出 PASS/FAIL，只报告不修复。

第 3 步：让审核代理阅读源码 技能规定审核员应阅读 app/、components/、contracts/。实际使用中，你可以直接让它执行技能内给出的检索命令，例如：

grep -rn "useWriteContract" packages/nextjs/
grep -n "og:image\|images:" packages/nextjs/app/layout.tsx

以及查看 packages/nextjs/scaffold.config.ts 中的 pollingInterval 与 rpcOverrides 配置。

第 4 步：在浏览器中真实点击每条流程 这是该技能区别于「纯代码审查工具」的关键：审核员需要打开应用，在未连接钱包的状态下看主界面是什么样，然后依次走连接、切网络、批准、操作四条路径，并在手机上通过 WalletConnect 连接后点击操作按钮，观察钱包 App 是否被唤起、是否准备签名。

第 5 步：逐项判定并分类输出 技能要求报告每个项目为 PASS 或 FAIL，并在结尾的「审计总结」中分成两档。

输出示例（节选，示意格式）：

🚨 钱包流程
FAIL — 未连接时页面渲染的是 <p>请连接你的钱包以继续</p>，未使用 RainbowKitCustomConnectButton

🚨 四状态按钮
FAIL — 批准按钮与操作按钮同时渲染；操作按钮 disabled 绑定的是 isLoading 而非 useScaffoldWriteContract 的 isPending

🚨 SE2 品牌
PASS — 页脚已替换为项目仓库链接
FAIL — 标签标题仍为 "App Name | Scaffold-ETH 2"

重要：USD 值
FAIL — 质押输入框与余额均只显示 "1,000 TOKEN"，无美元换算

=== 审计总结 ===
阻止发布：3 项未通过
应修复：5 项未通过

第 6 步：按「阻止发布」优先修复，再复审一轮 第一档「阻止发布」包含：钱包连接按钮、错误网络切换按钮、单按钮流程、批准按钮在区块确认期间禁用并显示旋转器、SE2 页脚/标题/README 清理。第二档「应修复」包含：合约地址、USD 值、OG 图像、pollingInterval、RPC 覆盖与环境变量、网站图标、Phantom、移动端深度链接三项。修复完成后，建议再开一次新会话重跑清单，因为修复本身很容易引入新的按钮状态问题。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
dApp预发布审计Skill（qa）	面向 AI 生成 dApp 的预发布体验与流程审计清单	钱包按钮化、四状态单按钮流程、按钮 `disabled` 与 `useScaffoldWriteContract` 绑定、SE2 品牌残留、合约地址展示、USD 估值、OG 绝对 URL、轮询与 RPC 环境变量、Phantom 支持、移动端深度链接	低。加载技能 + 一个新代理会话即可；无需额外账号或部署	AI 辅助快速开发的 Scaffold-ETH 2 dApp 上线前自检；黑客松交付前把关	优势：条目极具体、可直接 grep 验证、覆盖移动端深链接这类少有人讲的实操细节；不足：只针对 Scaffold-ETH 2 技术栈，不覆盖合约安全漏洞，且不负责修复
通用大模型直接评审	让 ChatGPT / Claude 等直接看代码并给建议	泛化的代码理解与建议输出	极低，粘贴代码即可	快速获取改进灵感	优势：零门槛；不足：输出不稳定、容易「夸项目」，几乎不会主动提出「按钮而非文字」「先交易后深链接」这类具体失败模式
智能合约静态分析工具（如 Slither 类工具）	合约层安全扫描	重入、权限、整数等漏洞模式检测	中等，需本地安装与配置	合约上线前的安全兜底	优势：安全维度专业；不足：完全不覆盖前端钱包流程、UI 状态机、品牌残留、移动端跳转，与本品互补而非替代
人工第三方审计服务 / 通用代码审查工具	专业审计或 PR 级代码评审	深度人工分析与报告	高，需要排期、沟通与费用（具体以服务方报价为准）	涉及真实资金的大额项目	优势：深度与权威性最强；不足：成本与周期高，通常不细究「连接钱包是按钮还是文字」这类体验层问题

一句话结论：合约安全工具管「钱会不会被偷」，人工审计管「架构与风险」，而这个技能管「用户第一分钟会不会走」——三者不冲突。

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

场景一：独立开发者用 AI 从零做出一个 dApp，准备发到社交平台 痛点：项目在自己浏览器里「能跑」，但分享出去后，朋友打开只看到一句「请连接你的钱包」，找不到按钮；分享卡片也没有缩略图。使用方式：构建完成后开新会话，加载技能，让审核代理走一遍完整清单。实际体验：这类「文字代替按钮」的问题在第一次审计中几乎必现，且修复成本极低（换成一个连接按钮组件），但如果不审，很可能带着它上线。

场景二：黑客松或 bounty 提交前的最后把关 痛点：时间紧，前端钱包流程粗糙，评审打开后点两下就卡住。使用方式：把「阻止发布」七项当作提交前的硬门禁逐条过。实际体验：单按钮状态机是最容易被抓出来的问题——批准和操作按钮经常同时渲染，或者在区块确认期间批准按钮仍可点击，导致用户重复签名。技能要求的「禁用 + 旋转器直到链上确认」是一条能立刻提升专业观感的改动。

场景三：移动端用户反馈「点了没反应」的排查 痛点：桌面端一切正常，手机用户通过 WalletConnect 连接后点「质押」，页面毫无变化，用户不知道要去钱包 App 里签名。使用方式：按技能给出的 writeAndOpen 模式实现深度链接，并检查是否遵守「先触发交易、后延迟 2000ms 跳转」的规则。实际体验：这是全篇最需要动手的一块。技能提醒的几个反例非常真实——在 writeContractAsync() 之前就设置 window.location.href，页面直接跳走，交易根本没发出去；只靠 connector.id 判断钱包，结果永远是 walletConnect，导致跳转到错误钱包；以及在钱包内置浏览器里还去做深度链接。

场景四：小团队把清单当作内部发布门禁 痛点：多人协作时，每个人对「可以上线了吗」的判断标准不一致。使用方式：把技能内容作为团队发布前的固定检查表，由非作者本人（或另一个代理）执行。实际体验：明确定位为「只报告不修复」这一点在协作中价值很大——审核者不会顺手改坏代码，修复责任回到作者身上，职责清晰。

上手难度与注意事项：整体很容易上手，技能本身就是一份可执行的清单，不需要额外工具链。需要注意三点：一是必须开新上下文，否则审核代理会顺着原会话的思路放水；二是清单中的 grep 命令需要审核代理具备仓库访问权限；三是技能不覆盖合约逻辑正确性与安全性，不要把「清单全 PASS」理解为「项目安全」。

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

把「隐性经验」变成「显性清单」。 这些坑原本要靠发几次真实项目、被用户吐槽几次才能总结出来，现在一次性前置到发布前。对于用 AI 快速产出的开发者来说，这相当于在发布前多了一道由「见过很多次翻车」的审核员执行的检查。

显著缩短发布前的排错时间。 清单里每一条都配了具体的判定标准和检索方式（grep 命令、配置文件路径、组件名），审核代理不用漫无目的地探索代码库，而是带着明确目标去验证。像 pollingInterval 从 30000 改到 3000 这种「一行改动、体感天差地别」的问题，靠人工很难想到去查，靠清单则是顺手一条。

降低专业门槛。 移动端深度链接是很多有经验的开发者都容易写错的部分，技能直接给出了可参考的辅助函数模式与五条关键规则，让不熟悉 WalletConnect v2 行为的人也能做出「点了就跳钱包、跳过去正好有东西可签」的体验。

减少真实用户的流失。 未连接时看不到按钮、金额没有美元概念、分享卡片没有图、手机点了没反应——每一条都直接对应一个用户放弃的瞬间。修复这些的成本远低于重新买一次流量。

长期价值在于可复用。 这份清单可以沉淀为团队的标准动作、写进发布流程文档、甚至作为 CI 之外的「人工/代理复核」环节固定下来。技术栈在变，但「一次只显示一个按钮」「先交易后跳转」「环境变量要真的设置」这些原则会长期有效。

常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？ 在支持外部技能的工具中，通过技能ID 13690 或英文名 qa 检索并加载即可，通常无需额外部署。具体的安装入口、命令以及是否涉及费用，请以官方说明为准。该技能本身的内容形态是一份审计清单，加载后即可让审核代理按清单工作。

Q2：它适合谁用？我不用 Scaffold-ETH 2 能用吗？ 最适合用 AI 辅助、基于 Scaffold-ETH 2 快速开发以太坊 dApp 的开发者与小队。如果你用的是其他技术栈，清单中「按钮而非文字」「一次一个按钮」「金额带美元估值」「OG 图像用绝对 URL」「先交易后深链接」等原则依然有参考价值，但涉及 useScaffoldWriteContract、scaffold.config.ts、wagmiConnectors.tsx 的具体判定项需要自行调整。

Q3：清单全 PASS 是不是就代表项目可以安全上线了？ 不是。 该技能明确只覆盖「AI 代理实际发布的错误」这类发布前体验与流程问题，不涉及合约逻辑漏洞、经济模型风险等安全层面。它应该与合约静态分析、必要的第三方审计一起使用，属于上线前多重检查中的一环。

Q4：为什么强调必须开一个新代理或新上下文？ 因为技能的设计前提是「构建完成后交给单独的审核代理」。在同一个会话里，模型倾向于维护自己之前的产出、倾向于给出「看起来不错」的评价；而新上下文的审核代理只面对代码和清单，更容易给出诚实的 FAIL。这是这个技能效果好坏的关键操作细节。

Q5：它和直接让大模型帮我看看代码有什么区别？ 区别在具体程度。通用提问通常得到的是「建议增加错误处理」「可以优化状态管理」这类泛化建议；而这个技能会要求审核员打开浏览器看未连接状态下有没有按钮、grep 检查是否混用了 useWriteContract、确认 pollingInterval 是不是 3000、验证环境变量是否真的在托管平台设置过、在手机上实测点击操作按钮会不会唤起钱包。前者给你感觉，后者给你结论。