AI编程搭子实战：用OpenClaw开发Android五子棋全流程

最近在整理手头的AI辅助开发流程，正好朋友让我用OpenClaw做一个五子棋练手项目。花了一个周末把简易版跑通，整体体验还挺顺。这篇就记录一下整个过程中我是怎么拆需求、怎么写代码、怎么让OpenClaw给我当编程搭子的，给同样想用AI工具做Android小游戏的朋友一个参考。

先交代一下背景。OpenClaw是一个开源的个人AI智能体框架，简单理解就是可以把它当成一个懂技术的编程搭子。你告诉它需求，它帮你写代码、改Bug、解释报错。五子棋则是很适合拿来练手的项目：规则明确、逻辑闭环、界面简单，又包含自定义View绘制、触摸事件处理、算法判定这些经典知识点。这两个东西凑在一起，正好能梳理出一套“AI辅助开发”的完整流程。

目标读者有两类：一是想做Android小游戏但不想从零啃文档的开发者，二是想体验AI编程工作流的朋友。这个简易版做到什么程度？双人本地对战、15x15棋盘、落子、五连判定、重新开始，就够了。下面直接进正题。

1. 项目需求拆解与技术选型

1.1 “简易版”的边界先画清楚

很多人拿到一个题目，第一反应是打开IDE就开始写，其实五子棋这种逻辑闭环很强的项目，把边界想清楚反而能省两倍时间。我一开始犯的错就是需求没说明确，上来就让OpenClaw写一个“五子棋app”，结果它默认给我加了一堆AI对手、音效、动画、悔棋、计时器，代码倒是漂亮，但很多不是我当前要的东西。

所以我把“简易版”圈定为这几个点：

• 双人同屏对战，不联网，不做AI对手
• 15x15标准棋盘
• 黑白双方交替落子
• 任意方向先形成5连者获胜
• 提供“重新开始”按钮

悔棋、禁手、步数统计、胜利动画这类功能，全部划到“后续扩展”，这个版本不碰。为什么这个范围合适？因为五子棋最核心的玩法闭环是“落子→判定→获胜”，其余都是外围。砍掉外围，才能把精力集中在棋盘绘制和胜负判定这两块核心代码上，也才能更快看到成品效果。

另一个原因是，用OpenClaw这类AI工具迭代时，需求边界越清晰，它生成代码的准确率越高。你让它写“五子棋游戏”，它会按照常见完整版来猜；你明确说“双人本地、15x15、无AI对手”，它就知道不需要加载一堆用不上的模块。AI编程工具不是玄学，输入的质量直接决定输出的质量。

1.2 技术选型：为什么是Android原生Kotlin

技术方案上我没有纠结太久，直接选了Android原生Kotlin加自定义View。理由有三点。

第一，五子棋游戏本质上是自定义View的绘制逻辑加上触摸事件处理，这是Android开发的基础能力，不需要引入Unity、Flutter这类跨端框架。杀鸡用牛刀反而麻烦，光是环境配置和布局模板就能劝退新手。

第二，Kotlin语言本身简洁，空安全设计也能少踩不少空指针的坑。配合OpenClaw这类大模型的代码生成能力，产出代码的准确率比Java高一些，后续调试时心智负担也小。

第三，简易版只有一个界面，Activity加一个自定义View就够了。几万行的游戏工程才需要考虑架构分层，这种小项目用最朴素的方式写反而好读好改。

如果你有心思对比，Flutter版五子棋我也见过，绘制和手势库写起来不差，但需要额外处理Dart和原生平台的通信问题。对一个只想快速跑通核心逻辑的简易版来说，原生Kotlin就是性价比最高的选择。等未来真要加联网对战、跨平台发布，再重构成Flutter也不迟，那是另一个话题。

1.3 OpenClaw在这个项目里扮演什么角色

这里必须把定位说清楚：OpenClaw不是“一键生成整个app”的魔法棒，而是一个“结对编程搭子”。它能做三件事，这三件事贯穿了整个项目：

• 按自然语言需求生成代码片段和完整文件
• 根据报错信息分析原因并给出修复方案
• 解释一段你不懂的代码逻辑，比如某个坐标系换算为什么要先减起始偏移

实际流程是：我提需求，它生成代码，我审查，跑起来，遇到问题继续问它。代码最终还是要过我这关，因为AI生成的代码偶尔会有版本兼容问题或逻辑漏洞，这一点后面会详细说到。

我自己用的是命令行方式启动OpenClaw，交互体验很像在一个终端里请了个懂技术的助手。它能在对话上下文中记住之前的修改记录，我纠正过一次坐标换算错误之后，后面再让它生成相关代码时，它就不会重复犯同样的错，这是它比直接打开网页版问答工具体验更好的地方。

2. OpenClaw辅助开发的工作流搭建

2.1 环境准备和版本坑

OpenClaw本身是个开源项目，依赖Node.js环境。大致安装路径是：先装Node.js LTS版本，然后克隆项目仓库，在项目目录执行依赖安装，再配置大模型API的密钥，最后启动服务进入交互命令行。因为这个项目迭代速度比较快，具体命令还是以官方README为准，我在这一步就不贴一份注定会过期的命令清单了。

我在这块踩过的坑是Node.js版本太老。本机原本装的是Node.js 14，启动OpenClaw时报了一个语法层面的错误，查了一下发现是项目代码里用到了Node.js 16之后才支持的语法。升级到Node.js 18之后问题消失。如果你也遇到莫名其妙的启动报错，第一步先检查运行环境版本，而不是怀疑配置写错。

Android侧的环境就是常规三件套：Android Studio、JDK 17、Android SDK。模拟器我直接用Android Studio自带的Pixel设备，跑这种纯绘制的应用完全够用，不需要单独配置真机。当然，真机上手感会更好，尤其是触摸落子的响应延迟，不过那是优化阶段的事，开发期模拟器方便调试。

2.2 怎么提需求，OpenClaw才不给废话

这是我这次项目里体会最深的一点。第一轮我输入的是“做一个五子棋app”，OpenClaw给我返回了一份包含AI对手、难度选择、排行榜的完整项目方案。功能很丰富，但我内心只想说一句“我不是这个意思”。问题出在需求表述太模糊，它只能按最大概率去找“五子棋app”的常见形态，结果自然不是我想要的。

后来我改成了结构化描述，一次就能拿到接近可用的结果。核心写法是这样的：

“用Kotlin写一个Android五子棋游戏核心逻辑。要求：15x15的棋盘，用二维数组存储棋盘状态，0表示空、1表示黑棋、2表示白棋；当前玩家落子后自动切换；落子后判断该位置在横、竖、两个斜方向是否形成连续5个同色棋子；只提供核心逻辑，不需要完整UI。”

对比一下就能发现，有效提示词包含三个要素：明确数据结构、明确输入输出、明确范围边界。你告诉它“用二维数组存棋盘”，它就会按这个约定写后续代码；你告诉它“不需要UI”，它就不会浪费篇幅生成一堆布局文件。开放式提问是给人类老师的，给编程AI的指令要像写需求文档一样精炼。

还有一个技巧是让AI把代码拆成可独立验证的小块。比如先让它生成棋盘数据模型和胜负判定函数，自己写个简单单元测试跑一遍确认无误，再让它生成自定义View和触摸事件，最后合成。分步来比一次性让它生成一个巨型文件要稳得多，出问题也好定位。

2.3 迭代循环：读代码这道功课不能省

整个项目下来，我形成了固定的三步循环：

第一步，让OpenClaw生成一个完整的文件，比如BoardView.kt；第二步，手动放进Android项目，编译运行；第三步，看到报错或行为不对，把日志贴给它，并附上预期行为，让它修复。

这个循环里最忌讳的是不读代码，直接让AI写了又写。我遇到过一个情况：OpenClaw生成的自定义View里，棋子数组在onSizeChanged里没有正确初始化，导致第一次落子后棋盘显示混乱。我当时偷懒没看代码，直接让它“再写一遍”，结果生成的新代码还是错的。后来冷静下来把代码读了一遍，发现是生命周期回调时机的问题，手工一改就通了。

所以我的经验是：AI生成代码可以，但“读代码”这个功课不能省。你可以不用从零写，但至少要能看懂每个关键变量的作用。否则一旦AI在逻辑细节上出错，你连从哪下手修复都不知道。这个项目的核心难度不在于代码量大，而在于几个容易出错的小细节，比如坐标换算、边界判断、状态切换，这些都需要你亲自理解一遍才稳妥。

3. 核心代码实现与要点解析

3.1 棋盘数据模型

五子棋的棋盘模型极其简单，一个二维数组就能搞定。我用board[row][col]表示第row行第col列的状态：0是空、1是黑棋、2是白棋。

private val boardSize = 15 private val board = Array(boardSize) { IntArray(boardSize) } private var currentPlayer = 1

currentPlayer表示当前轮到谁落子，初始为1，即黑棋先手。黑白先手是五子棋的固定规则，黑棋先手有优势，很多正式规则里还加了禁手来限制黑棋，但简易版不需要管这些，直接把先手给黑棋就行。

这个数据模型是整个游戏的“真相来源”，UI绘制、胜负判定、重置棋盘全都围绕它展开。好处是简单直观，坏处是随着功能增加，比如悔棋时要记录历史步骤，这个模型就需要扩展。但那是后续的事，简易版够用了。

3.2 自定义View绘制棋盘

棋盘绘制用自定义View来实现，核心是覆写onDraw方法。我在BoardView里定义了几支画笔：画网格线的、画黑棋的、画白棋的。这里有个细节，白棋如果直接填充纯白色，在浅色背景上会看不清边缘，所以要额外给白棋加一个黑色描边，视觉上会清楚很多。

class BoardView @JvmOverloads constructor( context: Context, attrs: AttributeSet? = null ) : View(context, attrs) { private val boardSize = 15 private val board = Array(boardSize) { IntArray(boardSize) } private var currentPlayer = 1 private val linePaint = Paint().apply { color = 0xFF8B5A2B.toInt() strokeWidth = 2f isAntiAlias = true } private val blackPaint = Paint().apply { color = 0xFF000000.toInt() style = Paint.Style.FILL isAntiAlias = true } private val whitePaint = Paint().apply { color = 0xFFFFFFFF.toInt() style = Paint.Style.FILL isAntiAlias = true } private val whiteStrokePaint = Paint().apply { color = 0xFF000000.toInt() style = Paint.Style.STROKE strokeWidth = 2f isAntiAlias = true } private var cellSize = 0f private var boardStartX = 0f private var boardStartY = 0f override fun onSizeChanged(w: Int, h: Int, oldw: Int, oldh: Int) { super.onSizeChanged(w, h, oldw, oldh) val padding = 30f val totalSize = minOf(w - padding * 2, h - padding * 2) cellSize = totalSize / (boardSize - 1) boardStartX = (w - totalSize) / 2f boardStartY = (h - totalSize) / 2f } override fun onDraw(canvas: Canvas) { super.onDraw(canvas) drawBoardLines(canvas) drawPieces(canvas) } private fun drawBoardLines(canvas: Canvas) { for (i in 0 until boardSize) { val y = boardStartY + i * cellSize canvas.drawLine(boardStartX, y, boardStartX + cellSize * (boardSize - 1), y, linePaint) val x = boardStartX + i * cellSize canvas.drawLine(x, boardStartY, x, boardStartY + cellSize * (boardSize - 1), linePaint) } } private fun drawPieces(canvas: Canvas) { for (row in 0 until boardSize) { for (col in 0 until boardSize) { val player = board[row][col] if (player != 0) { val cx = boardStartX + col * cellSize val cy = boardStartY + row * cellSize val radius = cellSize * 0.42f if (player == 1) { canvas.drawCircle(cx, cy, radius, blackPaint) } else { canvas.drawCircle(cx, cy, radius, whitePaint) canvas.drawCircle(cx, cy, radius, whiteStrokePaint) } } } } } }

onSizeChanged里做的事情很关键：根据View的实际宽高来计算每个格子的像素尺寸cellSize。这里我留了30像素的边距，防止棋盘贴边导致边缘被裁掉。totalSize取的是宽高减去边距后的较小值，再把多余的像素均分到左右或上下，保证棋盘居中。

在drawBoardLines里，15条横线和15条竖线交叉成15x15的棋盘格子，交叉点才是落子位置，所以cellSize计算时除以的是boardSize - 1而不是boardSize。这个细节很多人第一次写会搞错，结果画出来的棋盘只剩14个格子，看起来整个棋盘被压扁了。

棋子半径取cellSize * 0.42，大约是格子宽度的一半少一点。太大棋子会连成一片，太小棋子又显得稀疏，0.42这个比例在视觉上比较舒服。这个问题我没特意调过，是根据经验选的，跑起来效果不错。

3.3 触摸落子与坐标换算

棋盘画出来以后，下一步是让玩家能通过点击落子。这里最核心的就是“坐标换算”：把屏幕上的像素坐标转换成棋盘上的行列索引。这个环节在简易版里看起来不起眼，实际上恰恰是最容易出Bug的地方，我前前后后在这里栽过两次。

override fun onTouchEvent(event: MotionEvent): Boolean { if (event.action != MotionEvent.ACTION_UP) return true val x = event.x val y = event.y val col = Math.round((x - boardStartX) / cellSize) val row = Math.round((y - boardStartY) / cellSize) if (row < 0 || row >= boardSize || col < 0 || col >= boardSize) return true if (board[row][col] != 0) return true board[row][col] = currentPlayer if (checkWin(row, col)) { postInvalidate() onGameWin?.invoke(if (currentPlayer == 1) "黑棋" else "白棋") return true } currentPlayer = if (currentPlayer == 1) 2 else 1 postInvalidate() return true }

坐标换算的公式是：先把点击位置的像素坐标减去棋盘左上角的起始偏移boardStartX和boardStartY，得到相对于棋盘区域的坐标，再除以格子大小cellSize，然后用Math.round四舍五入到最近的交叉点索引。

这里有两个容易踩的坑。第一个是忘记减boardStartX，如果棋盘不是从View最左上角开始的，直接除cellSize会导致所有落子位置偏移固定距离。棋盘越靠右下方，偏差越明显。第二个坑是用直接转int而不是Math.round，直接转int是向下取整，点击交叉点左上方的区域会映射到错误的格子，视觉上就是“棋子总是落在点击位置的左上方/右下方偏移一点”。

判断逻辑的顺序也很重要：先做边界检查，再做重复落子检查，最后落子、判胜。如果你把判胜写在落子之前，那永远判定不了。这个顺序看似废话，但在AI生成的代码里我确实见到过逻辑混乱的版本。

3.4 五连子判定算法

胜负判定是五子棋最核心的算法，思路也很固定。在一颗棋子落下之后，只需要判断以它为起点，在横、竖、右斜、左斜四个方向上，加上各自的反方向，连续同色棋子数是否达到5个。

fun checkWin(row: Int, col: Int): Boolean { val player = board[row][col] val directions = arrayOf( intArrayOf(0, 1), // 横向 intArrayOf(1, 0), // 纵向 intArrayOf(1, 1), // 右斜 intArrayOf(1, -1) // 左斜 ) for (dir in directions) { var count = 1 var r = row + dir[0] var c = col + dir[1] while (r in 0 until boardSize && c in 0 until boardSize && board[r][c] == player) { count++ r += dir[0] c += dir[1] } r = row - dir[0] c = col - dir[1] while (r in 0 until boardSize && c in 0 until boardSize && board[r][c] == player) { count++ r -= dir[0] c -= dir[1] } if (count >= 5) return true } return false }

方向数组只用四个基向量：横向是(0,1)，纵向是(1,0)，右斜是(1,1)，左斜是(1,-1)。为什么不写八个方向？因为每个方向的正反两侧加在一起，才是一整条直线上的连续棋子数。比如横向正方向是向右，反方向是向左，两个方向分别累加，最后的总数就是当前行上包含落子点的连续同色棋子数量。四个基向量正好覆盖所有直线，再多就重复了。

边界判断写法上有个细节，r in 0 until boardSize && c in 0 until boardSize && board[r][c] == player，这个条件是从左往右短路的。如果r或c越界，后面的数组访问不会执行，避免了数组越界崩溃。我遇到过一次OpenClaw生成的代码把board[r][c] == player放在了最前面，运行起来一落子就闪退，就是边界判断顺序写反了。排查这类问题时，第一反应就检查越界条件是不是在数组访问之前。

判胜的触发时机是当前玩家落子之后立即调用，传入的正好是最后落子的行列。这样只需要检查包含新落子点的直线即可，不用每次把整个棋盘扫一遍，效率也高。简易版棋盘只有15x15，性能压力几乎不存在，但这种“只检查当前点”的思路在更大棋盘上也能用。

3.5 Activity集成与游戏重置

核心逻辑都写在BoardView里，Activity只需要做两件事：加载布局、设置胜利弹窗和重新开始的监听。

class MainActivity : AppCompatActivity() { private lateinit var boardView: BoardView override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) boardView = findViewById(R.id.boardView) boardView.onGameWin = { winner -> AlertDialog.Builder(this) .setTitle("游戏结束") .setMessage("$winner 获胜！") .setPositiveButton("再来一局") { _, _ -> boardView.resetGame() } .setCancelable(false) .show() } findViewById<Button>(R.id.btnRestart).setOnClickListener { boardView.resetGame() } } }

BoardView里需要加一个胜利回调的声明：

var onGameWin: ((String) -> Unit)? = null

这样View层不直接依赖Activity，通过回调通知外部“游戏结束了”。这种解耦方式在简单项目里看起来很轻量，后续想改成跳转胜利画面也方便。

重置逻辑也很简单，把二维数组全部清零，当前玩家重置为黑棋，再刷新画面：

fun resetGame() { for (row in 0 until boardSize) { Arrays.fill(board[row], 0) } currentPlayer = 1 postInvalidate() }

布局文件里放一个BoardView占满大部分屏幕，下面放一个“重新开始”按钮就行。BoardView的宽度高度设置为match_parent，让它有足够空间绘制15x15棋盘。

4. 常见问题与排查经验

4.1 问题速查与解决方案

我把这个项目里实际遇到过的坑整理成了表格，按现象、原因、解决办法三列来写，方便你对照排查。

4.2 我最头疼的一个Bug：边界判断顺序引发的越界崩溃

这个Bug值得单独拿出来说。OpenClaw第一次生成的checkWin函数里，边界判断是这样的：

while (board[r][c] == player && r >= 0 && r < boardSize && c >= 0 && c < boardSize) { ... }

看起来好像没问题，实际上Java和Kotlin的条件判断是从左到右求值的。board[r][c]排在边界判断之前，意味着当r或c已经越界时，程序会先尝试访问数组，结果直接抛ArrayIndexOutOfBoundsException。

这个问题在调试器里看比任何AI解释都直观。我第一次遇到时，还以为是棋盘数组大小不对，后来给checkWin加了Log，把每次判断的r、c打印出来才定位到问题。日志里能看到当棋子落在边角位置时，r或c会跑到-1或15，然后程序就崩了。修法就是调整条件顺序，把边界判断放在数组访问之前。

这也印证了我前面说的：AI生成的代码可以，但一定要自己理解关键逻辑。如果你不知道条件表达式是从左到右短路的，排这种Bug能让人怀疑人生。

4.3 排查坐标换算问题的技巧

如果你发现棋子落点不准，先在onTouchEvent里加一行Log打印原始坐标和换算后的行列：

Log.d("BoardView", "x=$x, y=$y, row=$row, col=$col")

再在onDraw里打印棋盘起始坐标和格子大小：

Log.d("BoardView", "startX=$boardStartX, startY=$boardStartY, cell=$cellSize")

对比两组日志就能知道问题出在哪个环节。如果坐标对但格子大小不对，问题在onSizeChanged；如果坐标对但行列结果是乱的，问题在Math.round的用法或起始偏移没减。这类问题用打印日志的方式比盯代码更快。

5. 后续扩展方向

这个简易版做出来后，可扩展的方向其实很多，我列几个我打算下一步尝试的。

第一个是给单机加一个简单AI对手。最简单的做法是每次轮到AI时，在空位置中随机落子，这是“能玩”和“有AI”的界限。如果想要AI稍微聪明一点，可以检查对手是否已有四连，有就堵；再检查自己是否有三连或四连，有就补。这个规则式AI不需要深度学习，几十行代码就能让体验上一个台阶。

第二个是加入悔棋功能。数据结构层面可以把每次落子的行列记录到一个栈里，悔棋就是从栈里弹出一个位置，把棋盘状态清零，并回退当前玩家。这个功能对数据模型的改动很小，但能显著提升实用性，双人对战时手滑点错格子是常有的事。

第三个是走持久化，保存对局状态。把当前棋盘二维数组和当前玩家序列化成JSON或者用SharedPreferences存储，app杀进程后再打开还能继续下。这个功能对“简易版”来说稍重，但如果你想把五子棋当成自己长期维护的项目，早晚会用到。

这些扩展都可以继续用“提需求→OpenClaw生成→验证迭代”的流程来做。我的建议是每次只加一个功能，跑通稳定后再做下一个，避免多个改动叠加后都不知道是哪一步引入的Bug。

最后再分享一个小经验。很多人以为用AI写代码可以完全不动脑子，实际上这个项目做下来，最花时间的不是写代码，而是“明确需求”和“验证AI输出”。OpenClaw把五子棋的骨架代码生成出来，可能只要两三分钟，但我要看得懂它生成的棋盘坐标换算，才能在落子错位时知道去哪修。以后如果你也想用AI辅助做小游戏，我的建议是：先自己把核心逻辑想清楚，再让AI帮你加速实现，这样整体体验会舒服很多。