所筑何物
吾筑Scriptless.ai——一由人工智能驱动之测试工场，使汝自"吾有GitHub仓库"至"吾有运行之浏览器测试并具失效分析"不亲撰一字之测试码。
诚言其事：吾所睹之众团队，皆视测试为事，行于既疲于撰制功能之后。测试之覆失，渐积；质验之滞塞，叠起；旦夜二时，Debug CI之败，唯睹赤格，无境无由。Scriptless.ai，乃吾欲全易此局之尝试也。
其要在此：
- 联接尔之GitHub仓库 — OAuth入，择一仓库，毕.
- 以Gemma 4生测试之例。 — 此模读尔实源文件与文件林，乃生结构、路线特定之测试案（UI、认证、表单、API、边界案、整合），悉合尔确代码林。非泛泛Lorem Ipsum之测试——乃真知尔路线与文件之测试。
- 于真云浏览器中行。 — 每一测试皆化身为 Playwright 脚本，于 Browserbase 实时会话中运行。真浏览器，真网络，真 DOM.
- 视觉察之败. — 测试若败，Gemma 4 之视能分析败时页面之截图，告汝所见，所失之由，及当何以修正。不复盲掘日志之古.
- 声控万般 — 以 Speechmatics 之能，可令言「运行失败测试」或「仅显通过」，而界面应之。无需持器，即可验质。
此乃全栈之制：Next.js 为前端，Neon Postgres 配 Drizzle 以存，Clerk 为认证，Stripe 为计费之基，Vercel 以部署。用户之积分，随生成与执行而减，计费之构已备，可应订阅之约。
示例
🚀 实时应用： https://scriptless-ai.vercel.app/
以Clerk登录→授权GitHub→连接仓库→点击生成测试，观Gemma 4之作为.
初试何物：
- 连接汝所拥有之任何公共Next.js或React仓库
- 点击生成测试用例，察其模型如何构架针对尔文件树之测试
- 运行测试——Browserbase会唤起真Chrome实例
- 若其败，则卷至视觉分析之节，观Gemma 4之诊断
代码
📦 GitHub: https://github.com/Arjunhg/scriptless-ai
值得探究之要件：
| 文件 | 其功用 |
|---|---|
lib/featherless/client.ts |
无羽之客配置，模型别名指向gemma-4-31B-it
|
lib/featherless/generateTests.ts |
调用Gemma 4以工具调用生成结构化测试案例 |
lib/featherless/analyzeScreenshot.ts |
将失败截图发送至Gemma 4视觉诊断 |
lib/featherless/prompts/testGeneration.ts |
转化Gemma为质检工程师之系统提示 |
app/api/generate-test-cases/route.ts |
API 路径，读取 GitHub 文件 → 调用 Gema → 存入数据库 |
app/api/test-cases/run/route.ts |
执行流程：脚本生成 → Browserbase → 视觉备选 |
hooks/useVoiceCommands.ts |
Speechmatics 实时流程 + 语句最终逻辑 |
lib/speechmatics/commandParser.ts |
基于词元的 NLP 命令解析器（词干提取、停用词、同义词） |
吾如何使用 Gema 4
吾正在使用google/gemma-4-31B-it（三十一密指令调适之变体），经由Featherless AI OpenAI相容之API而得。Gemma 4于此应用中，助成二种迥异、实别之用场：
1. 🧠 测试案例之生成（文辞+工具呼召）
既而用户点击"生成测试用例"，则后端自GitHub取其仓库之文件树，并滤取源文件之属，悉送诸Gemma 4，附以结构化之系统提示，并工具调用定义，以应submit_test_cases之需。
// lib/featherless/client.ts
export const FEATHERLESS_TEXT_MODEL = "google/gemma-4-31B-it";
// lib/featherless/generateTests.ts
const response = await featherlessClient.chat.completions.create({
model: FEATHERLESS_TEXT_MODEL,
messages: [...messages],
tools: [TEST_CASE_TOOL_DEFINITION],
tool_choice: { type: "function", function: { name: "submit_test_cases" } },
});
此模返回一JSON载，含五至八测试案，每案具一title、description、type（ui/auth/form/api/integration/edge-case）、priority、targetRoute、targetFiles及expectedResult。其解汝之应用结构于境——不妄生无路之径或无文之件，盖因汝示其实文件林也。
吾择31B者，盖结构输出之信实为要。小模往往偏离工具调用之范式，或产不备之JSON，尤以大仓之复杂数树为甚。31B之模，纵千词输入，亦恒保结构之信。
2. 👁️ 失败视域之析（多模）
若试运行败，则Playwright脚本于败处摄一屏。此屏遂递于Gemma 4之视能：
// lib/featherless/analyzeScreenshot.ts
const response = await featherlessClient.chat.completions.create({
model, // google/gemma-4-31B-it
messages: [{
role: "user",
content: [
{ type: "text", text: `You are a QA engineer analyzing a browser test failure screenshot.\n\nTest case: ${testDescription}\n\nDescribe what is visible on the page, what likely went wrong, and suggest concrete next steps...` },
{ type: "image_url", image_url: { url: screenshotUrl } },
],
}],
max_tokens: 512,
});
其果乃三至五句之诊，直呈于试运行之卡。非“败——元素未觅”，而得若此："此页显四十四之误。其途/dashboard/analytics尚无。此试引一导航之行，恐近时一改已删之。当议更其目标之途，或增一引。"
此乃吾于开物时，实所惊异——Gemma 4之视析甚锐。非惟状此页，且思其故，及何由。 若以是页为靶，则试之必败。
何故选31B密？
- 工具调用之信： 小型模型常于重压下破结构化输出之范。31B则恒常。
- 长文推理之能： 试生之辞，可含三千至五千之符，并载文件之文。31B模型从容应之。
- 界面截图之视效：浏览器截图，其界面元素繁密。三十一亿参数之视效模型，能正确辨识组件、错误状态及布局之瑕疵，此中小型模型往往遗漏或描述过于泛泛。
- 一体两用：以同一模型家族处理文与视，使整合简明，行为于二事皆可预判。
独建于Gemma 4之赛。凡基设、提旨、声流、界面，皆所设计所运。