VibeCoding 开发经验总结分享

以下内容从《VibeCoding开发经验总结分享》PDF 文档中提取并重新编排，包含 18 条实战经验技巧。这些经验来自真实的 Vibe Coding 项目实践过程，每条都配有原文截图或操作演示。

经验 1：让 Claude 启动浏览器验证

1 让 Claude 自己启动浏览器验证

像真正机器⼈一样⼲活，避免多次出错，不断需要⼿⼯输⼊修正。

与其反复粘贴错误日志让 AI 猜测问题，不如直接让 AI 启动浏览器、打开页面、看到实际效果后自行判断和修复。这种方式模拟了人类调试的真实流程，效率显著提升。

经验 2-3：遇到顽固 Bug 的策略

2 不要让 AI 反复修改同一个 Bug

如果 AI ⼀直修改不好当前 bug，就不要再让 AI 重复多次修改。⽽是让它对⽐ git diff 差异或 worktree，分析新产⽣这个 bug 的真正原因，避免修改⽅案偏离太远。

依然有这个错误，为什么 PpssppActivity.java ⼯程没有这个问题，game_loader 有这个问题？请再仔细对⽐两个⼯程加载逻辑差异，确保⼀致。

3 让 AI 直接编译运⾏并根据⽇志继续分析

可让 AI 直接编译运⾏ Android APK，根据终端⽇志继续分析问题，直到解决。不⽤重复多次粘贴⽇志 —— 这样解决问题效率更⾼。

安装有密码提⽰时还需要每次⼿⼯点下安装，但整体效率仍然高于人工逐行排查。

经验 4：双 AI 并行开发

4 同步使⽤两个 AI 做同⼀个功能

AI 编码很快，可以同步让两个 AI 同时做⼀个功能，互相弥补出现的问题。对比看哪个做得更好，后续还可以互相 review。

这种方法类似于代码审查中的双程序员制（Pair Programming），能大幅减少遗漏和错误。

经验 5：TDD 测试驱动开发

5 使⽤ TDD（测试驱动开发）模式

先写测试⽤例要求，然后循环根据测试⽤例去解决问题；类似 hardness 开发模式，给 AI 加上约束条件，让它针对约束去解决问题。

TDD 测试要点

测试⽤例需要全⾯：端到端测试，各个界⾯按钮事件需触发
进⼊游戏，模拟 fold、call、raise 等操作，根据前端/后台/浏览器⽇志确定是否有误
玩家连接后测试：模拟点击操作，截图看游戏状态和⽇志
UI / 逻辑 / 合约调⽤，端对端集成测试流程⾛⼀遍
不要启动新的 Chrome 浏览器，连接现有已启动的调试浏览器
参考 docs/GAME_BOT_TEST_FLOW.md ⽂档内的测试流程进⾏测试，间断性截图看状态分析
运⾏游戏⾃测流程，启动机器⼈，CDP 控制浏览器 UI 真实操作

经验 6：浏览器自动化操作

6 ⽤浏览器模拟点击操作

可以解决浏览器插件安全问题和⽹站防抓取问题。通过 pynput 或 CDP 协议直接控制浏览器进行真实操作。

自动签名脚本 — 完整 Deposit + 签名流程（已验证稳定）

# 1. 点击 Deposit 按钮 (normX=0.475, normY=0.803 -> 逻辑坐标 718,788)
cliclick m:718,788 && sleep 0.5 && cliclick c:718,788

# 2. 等待 TronLink 签名弹窗出现（约4-5秒）
sleep 5

# 3. 点击签名按钮 (1406,638) — 两次点击：第⼀次聚焦，第⼆次确认
cliclick m:1406,638 && sleep 2 && cliclick c:1406,638 && sleep 2 &&
cliclick c:1406,638

注意：签名需要两次点击 — 第⼀次聚焦钱包窗⼝，第⼆次触发签名。直接单次点击可能⽆效。

等待并签名

# 等待签名弹窗出现后⾃动签名（配合截图检测）
sign_tronlink() {
  echo "⏳ 等待 TronLink 签名弹窗..."
  sleep 3
  cliclick c:1395,631
  echo "✅ 已点击签名按钮"
}
sign_tronlink

完整充值 + 自动签名流程

# 1. 触发充值操作（通过 CDP 或⻚⾯按钮）
# 2. 等待 TronLink 签名弹窗出现
sleep 3
# 3. ⾃动签名
cliclick c:1395,631
echo "✅ 签名完成"
# 4. 等待交易确认
sleep 5
# 5. 截图确认结果
screencapture -x /tmp/tronlink-sign-result.png

OCR 截图检测签名弹窗

Bash(screencapture -x /tmp/sign_popup.png && /tmp/ocr3 /tmp/sign_popup.png
2>/dev/null | awk 'NR<=')
⎿ 'Chrome' x=0.053 y=0.017
'ТЛАН' x=0.270 y=0.018
'Poker Achievement NFT (PAN X Account TU8rhtpFQUsgpbe9:' x=0.211 y=0.056

OCR 没有捕获到 TronLink 弹窗内容，弹窗可能是独⽴窗⼝层。重新编写 OCR 脚本⽀持传⼊⽂件参数：

Bash(cat > /tmp/ocr_file.swift << 'EOF'
import Vision...
⎿ compiled

TronLink 弹窗是独⽴的 Chrome 扩展窗⼝，screencapture -x 可能没截到它。⽤不带 -x 的⽅式截全屏包含所有窗⼝：

Bash(screencapture /tmp/sign_all.png && /tmp/ocr_file /tmp/sign_all.png 2>/dev/null |
awk 'NR<=50')
⎿ 'Chrome' x=0.054 y=0.017
'< > c' x=0.039 y=0.100
'HE THAN' x=0.257 y=0.018
⎿ 'Q' x=0.836 y=0.018
'TronLink' x=0.820 y=0.051
'4H6B #- 21:53:34' x=0.944 y=0.018

看到 TronLink 弹窗在右侧，有 0.9937 TRX 和地址信息。扫描右侧更多内容定位签名按钮：

Bash(/tmp/ocr_file /tmp/sign_all.png 2>/dev/null | awk -F'x=' '{if(NF>1 && $2+0 > 0.8)
print}' | awk 'NR<=30')

TronLink 弹窗在右侧，签名按钮可能是绿⾊图形按钮 OCR 识别不到。根据弹窗位置 x≈0.92，换算坐标并尝试点击签名按钮：

# 弹窗右侧 x≈0.93, 签名按钮在底部 y≈0.55-0.65
# 逻辑分辨率 1512x982
y=0.55 -> (1406,540)
y=0.60 -> (1406,589)
y=0.65 -> (1406,638)

# 先移动⿏标到 y=0.65 位置确认，再执⾏签名：
Bash(cliclick m:1406,638)

已验证: 2026-04-06，通过 pynput 监听⽤⼾实际点击录制

经验 7：开启调试模式深入分析

7 问题⽆法解决时，打开调试⽅式

配置好调试环境，使用断点分析 AI ⽣成的代码是否合理。

后台 Node.js 调试 + 前端 Chrome 浏览器调试，双管齐下定位问题根因。

后台 Node.js 调试

使用 Node.js 内置调试器或 VS Code 断点调试，逐步执行 AI 生成的代码，观察变量状态和调用栈。

前端 Chrome 浏览器调试

使用 Chrome DevTools 分析前端行为，检查网络请求、控制台日志、DOM 结构等。

经验 8-10：工具与模型策略

8 模型切换策略

Sonnet 模型⽆法解决时，可以更换 Opus 更好的模型；Codebuddy ⾥也可以切换模型。GLM 5.0 搞不定时可试试 Kimi。现在各 AI ⼯具使⽤费较⾼，国内 GLM + Kimi 结合使⽤也是好选择。问题反复搞不定时使⽤ ClaudeCode、Gemini，将海外模型调⽤的⽅法搬移到国内模型使⽤。