1. 从零到上架为什么我选择用 Codex 做一款中国象棋国庆七天假期我没有出门看人山人海而是把自己关在书房里用 Codex 从零开始搓了一款中国象棋并且最终成功上架了 App Store。这件事听起来有点疯狂但如果你也经历过那种“脑子里有个想法却迟迟不敢动手”的煎熬你大概能理解我为什么非要把它做出来。中国象棋这个题材看起来简单实际上暗坑极多——规则逻辑、走法校验、将军判定、将帅照面、困毙与绝杀每一项都能让新手开发者卡上大半天。而 Codex 这类 AI 编程助手恰好能在这种“规则密集但结构清晰”的项目里发挥出惊人的效率。这篇文章不是要吹嘘 AI 有多神而是想把我这七天里踩过的坑、绕过的弯、以及最终让 App 顺利过审的完整过程原原本本地分享出来。如果你是一个有点编程基础、想独立做一款小应用上架的开发者或者你正在犹豫要不要用 AI 辅助写代码那这篇内容应该能给你不少参考。我会从技术选型、核心算法、UI 适配、上架审核这几个维度把整个项目的骨架和血肉都拆开来讲。尤其是那些“看起来能跑但一上真机就崩”的细节我会重点标注因为那才是一个项目从玩具变成产品的关键分水岭。先说说为什么选中国象棋。市面上的象棋 App 已经多如牛毛但大多数要么广告满天飞要么操作反人类要么在 iPad 上拉伸得惨不忍睹。我的目标很简单做一个干净、流畅、支持人机对战和本地双人对战的小工具没有花里胡哨的社交功能也没有强制登录。这个定位决定了我的技术栈不能太重开发周期不能太长而 Codex 的代码生成能力正好能帮我压缩掉大量重复劳动。比如棋盘绘制、棋子移动动画、走法生成这些模块我只需要把规则描述清楚Codex 就能给出可用的 Swift 代码片段我再根据实际运行效果微调。这种“描述—生成—验证—修正”的循环比我以前一行行手敲快了至少三倍。不过AI 生成的代码有一个通病它往往只关注“功能实现”而忽略了“边界条件”。中国象棋的边界条件恰恰是最要命的地方。比如“将帅不能照面”这条规则AI 第一次给我的代码只判断了同一列上是否有棋子阻挡却忘了考虑将帅本身的位置关系。结果测试的时候两个老将隔着空棋盘大眼瞪小眼游戏居然不判负。这种 bug 在 AI 生成的代码里非常常见因为它的训练数据里可能包含了大量不完整的开源实现。所以我的经验是AI 可以帮你写 70% 的代码但剩下 30% 的规则校验和异常处理必须你自己逐条推敲。这 30% 才是决定你的 App 能不能上架、会不会被用户骂的关键。还有一个现实问题App Store 的审核。很多人以为代码写完就万事大吉其实审核环节才是真正的“大考”。尤其是游戏类应用苹果对版权、隐私、内容合规的要求非常严格。中国象棋虽然是个传统游戏但如果你用了某些特定的棋子图片、音效或者字体都有可能被判定为侵权。我在上架前特意把所有素材都换成了自己用代码绘制的矢量图形音效也是用系统自带的音频工具合成的这才顺利过审。这些细节我会在后面的章节里详细展开。2. 技术选型与 Codex 协作模式为什么是 SwiftUI 原生引擎2.1 跨平台框架的诱惑与陷阱一开始我考虑过用 Flutter 或者 React Native 来做毕竟一套代码能跑 iOS 和 Android听起来很划算。但仔细一想中国象棋的棋盘渲染和棋子动画对性能要求其实不低尤其是人机对战时AI 思考的递归搜索会占用大量 CPU 时间如果再用跨平台框架的桥接层很容易出现卡顿。而且我的目标平台就是 iOS短期内没有安卓计划所以直接上 SwiftUI 是最稳妥的选择。SwiftUI 的声明式语法和 Codex 的代码生成风格非常契合——你只需要描述“棋盘是一个 9x10 的网格每个交叉点可以放置棋子”Codex 就能给出一个基于LazyVGrid或者Canvas的布局方案。但 SwiftUI 也有它的坑。比如棋盘上的棋子拖动如果直接用DragGesture在 iOS 16 上会出现手势冲突导致棋子拖到一半就卡住。这个问题我排查了很久最后发现是ZStack的层级顺序和手势优先级没处理好。Codex 第一次生成的代码把拖动手势加在了棋子上但棋子的父视图也有一个点击手势两者冲突了。解决办法是把拖动逻辑统一放到棋盘容器层通过坐标转换来判断用户点中了哪个棋子。这个思路其实不难但如果没有实际跑过真机你根本想不到问题出在手势竞争上。2.2 Codex 在规则引擎开发中的实际表现中国象棋的规则引擎是整个项目的核心。我把它拆成了三个模块走法生成、合法性校验、胜负判定。走法生成相对简单每种棋子车、马、炮、兵、士、象、将的移动规则都是固定的Codex 能根据我的描述快速生成对应的函数。比如“马走日但蹩马腿时不能走”Codex 给出的代码逻辑基本正确但它没有处理“马腿”被己方棋子挡住的情况——它只判断了目标位置是否有敌方棋子却忘了检查蹩马腿的位置是否为空。这个 bug 在测试时非常隐蔽因为大多数情况下马腿都是空的只有特定残局才会触发。合法性校验就更复杂了。你需要判断一步棋走完之后己方的将是否被将军。如果被将军这步棋就是非法的。这个逻辑需要模拟走棋、重新计算所有敌方棋子的攻击范围、再判断将的位置是否在攻击范围内。Codex 生成的代码在这里犯了一个典型错误它只检查了敌方棋子的直接攻击却忘了“将帅照面”也是一种攻击。也就是说如果走完一步棋后己方将和敌方将在同一列上且中间没有棋子这步棋也是非法的。这个规则在代码里需要单独处理不能简单地归入“被将军”的逻辑。胜负判定则涉及到“困毙”和“绝杀”的区别。困毙是指一方无子可走但并未被将军绝杀是指一方被将军且无法解将。这两种情况都判负但触发条件不同。Codex 第一次生成的代码把两者混为一谈导致某些局面下游戏提前结束。我后来手动重写了这部分逻辑把“无合法走法”作为统一的判负条件才解决了问题。2.3 人机对战 AI 的轻量化实现人机对战是象棋 App 的标配但我不可能去训练一个深度学习模型那太重了。我的方案是用 Minimax 算法加上 Alpha-Beta 剪枝搜索深度设为 4 层。这个深度在 iPhone 上大约需要 0.5 到 1 秒的思考时间对于休闲玩家来说完全可以接受。Codex 帮我生成了 Minimax 的框架代码但评估函数需要我自己设计。评估函数的核心是给每个棋子赋一个基础分值再根据位置加成。比如兵过河后价值翻倍马在中心区域比在边角更有威胁。这些经验参数我是参考了一些公开的象棋引擎资料然后手动调整的。这里有一个性能优化的细节不要每次搜索都重新生成所有走法。我在代码里维护了一个走法缓存当棋盘状态没有变化时直接复用上一次的走法列表。这个优化让 AI 的思考时间缩短了大约 30%。Codex 一开始生成的代码是每次递归都重新计算效率很低。我后来在搜索函数里加了一个transposition table用来存储已经评估过的局面避免重复计算。这个表用字典实现键是棋盘的哈希值值是该局面的评估分数和搜索深度。加上这个之后AI 的响应速度明显提升尤其是在中局阶段效果非常明显。3. 棋盘渲染与交互细节那些 AI 不会告诉你的坑3.1 棋盘坐标系的建立与转换中国象棋的棋盘是 9 列 10 行但棋子是放在交叉点上的不是格子里。这个区别在绘制时非常关键。如果你用Grid布局每个格子代表一个交叉点那么棋盘的宽高比应该是 9:10而不是 8:9。Codex 第一次生成的代码用了Grid的默认间距结果棋盘被拉伸得像个正方形棋子位置全乱了。我后来改用Canvas手动绘制通过计算每个交叉点的坐标来定位棋子才解决了这个问题。坐标转换是另一个容易出错的地方。用户的触摸事件返回的是屏幕坐标你需要把它转换成棋盘上的行列索引。这个转换涉及到棋盘的偏移量、缩放比例、以及每个交叉点的间距。我写了一个convertToBoardPosition函数先把触摸点减去棋盘的原点偏移再除以交叉点间距最后四舍五入得到最近的交叉点。这个函数看起来简单但如果你忘了考虑棋盘的缩放比如在 iPad 上棋盘会放大坐标就会偏得很离谱。我的建议是把所有与坐标相关的计算都封装在一个独立的工具类里并且写单元测试验证边界情况。比如触摸点在棋盘边缘时应该返回最近的合法交叉点而不是返回 nil 或者越界的索引。3.2 棋子拖动的流畅度优化棋子拖动是用户体验的核心。我一开始用DragGesture实现发现棋子跟手性很差拖到一半会突然跳回原位。排查后发现是两个问题一是手势的minimumDistance设得太小导致轻微移动就触发拖动二是棋子的位置更新没有用State绑定导致视图不刷新。Codex 生成的代码用了GestureState但GestureState在拖动结束后会自动重置不适合用来保存棋子的最终位置。我后来改成了State加onChanged和onEnded回调才实现了流畅的拖动效果。还有一个细节当用户拖动棋子时应该把棋子稍微放大一点并且加一个阴影让用户感觉棋子被“拿起来”了。这个效果用scaleEffect和shadow就能实现但要注意动画的时长。我试过 0.1 秒和 0.2 秒最后发现 0.15 秒最自然。太快了感觉不到太慢了又显得拖沓。这些微交互的细节AI 通常不会主动帮你加但它们是决定 App 品质感的关键。3.3 走法提示与非法走法反馈对于新手玩家来说走法提示非常重要。我的做法是当用户选中一个棋子时用半透明的圆点标记出所有合法的落子位置。这个功能需要调用走法生成引擎把当前棋子的所有合法走法计算出来然后转换成棋盘上的坐标。Codex 生成的代码在这里有一个性能问题它每次选中棋子都重新计算所有走法包括那些明显不可能的走法比如车被挡住的方向。我后来加了一个简单的剪枝对于直线移动的棋子车、炮、兵只沿着四个方向逐格检查遇到棋子就停止。这样计算量小了很多选中棋子时的响应几乎是瞬时的。非法走法的反馈也很重要。如果用户试图把棋子拖到一个非法位置棋子应该自动弹回原位并且给一个轻微的震动反馈。这个震动用UIImpactFeedbackGenerator就能实现但要注意震动的强度。我试过.light和.medium最后选了.light因为.medium在安静的环境下会显得很突兀。这些体验上的细节你只有自己反复测试才能找到最合适的值。4. 上架 App Store 的完整流程与审核避坑4.1 开发者账号与证书配置上架的第一步是注册开发者账号。个人账号一年 99 美元企业账号更贵但支持多人协作。如果你只是做个人项目个人账号完全够用。注册过程中需要填写税务信息和银行账户这些信息必须真实有效否则后续收款会出问题。证书配置是另一个容易卡住新手的环节。你需要创建开发证书和发布证书还要配置 App ID 和描述文件。Xcode 的自动管理签名功能可以省去很多麻烦但如果你用了某些特殊的权限比如推送通知就需要手动配置。我的建议是尽量用自动签名除非你有明确的理由需要手动配置。自动签名能避免 90% 的证书问题。4.2 App 元数据的准备与优化App Store 的元数据包括应用名称、副标题、描述、关键词、截图和预览视频。这些内容直接影响你的应用能不能被用户搜到。中国象棋这个关键词竞争很激烈所以我在副标题里加了“单机对战”和“无广告”这两个卖点。描述里我重点强调了“支持人机对战和本地双人”“无需联网”“完全免费”。截图我做了 6 张分别展示了棋盘界面、人机对战、双人对战、走法提示、胜利动画和设置页面。预览视频我录了一段 30 秒的实机操作展示了拖拽棋子和 AI 思考的过程。这些素材的准备花了我整整一天但非常值得因为它们是用户决定要不要下载的第一印象。4.3 审核被拒的常见原因与应对我的第一次提交被拒了原因是“元数据不完整”。具体来说苹果要求提供隐私政策链接而我当时没有。中国象棋本身不收集任何用户数据但苹果规定所有应用都必须有隐私政策哪怕你只是本地存储。我后来用了一个简单的静态页面生成工具写了一份隐私政策声明不收集任何数据才通过了审核。第二次提交又遇到了“设计问题”苹果说我的应用在 iPad 上显示不正常。我检查后发现是棋盘在 iPad 上被拉伸了因为我没有适配不同屏幕尺寸。解决办法是用GeometryReader动态计算棋盘的尺寸确保它在任何设备上都保持 9:10 的宽高比。第三次提交终于通过了整个过程花了大约五天。这里有一个经验提交前一定要在尽可能多的设备上测试。我用模拟器测了 iPhone SE、iPhone 15 Pro 和 iPad Pro但模拟器上的表现和真机还是有差异。比如 iPhone SE 的屏幕很小棋盘的触摸区域容易误触iPad Pro 的屏幕很大棋子显得太小。这些问题只有真机测试才能发现。如果你没有那么多设备至少要在 iPhone SE 和一款大屏 iPad 上测试这两个极端情况覆盖了大多数适配问题。5. 七天开发节奏复盘每天到底在做什么5.1 第一天到第二天规则引擎与棋盘骨架第一天我主要在做规则引擎。上午用 Codex 生成了走法生成和合法性校验的代码下午手动修正了将帅照面和蹩马腿的 bug。第二天开始搭棋盘 UI用 Canvas 绘制了棋盘线和九宫格用 SwiftUI 的ForEach渲染棋子。这两天的工作量最大因为规则引擎是基础如果这里有问题后面的所有功能都会受影响。我的建议是规则引擎一定要写单元测试。我写了大约 30 个测试用例覆盖了每种棋子的走法、将军判定、困毙判定。这些测试在后续开发中帮我省了很多调试时间。5.2 第三天到第四天人机对战与交互优化第三天我实现了 Minimax 算法和评估函数。一开始 AI 的棋力很弱因为它只会贪吃棋子不懂得保护老将。我调整了评估函数的权重把将的安全值调高AI 才开始有模有样地防守。第四天我重点优化了交互包括棋子拖动、走法提示、非法走法反馈。这两天的工作比较琐碎但用户体验的提升非常明显。我找了一个朋友来试玩他提出的几个问题比如棋子太小、拖动不跟手都是我没想到的。所以尽早找真实用户测试他们的反馈比你自己闭门造车有价值得多。5.3 第五天到第七天上架准备与审核冲刺第五天我开始准备上架素材包括截图、预览视频、隐私政策。第六天提交了第一次审核被拒后连夜修改。第七天重新提交第二天早上收到了通过的通知。这三天的心情就像坐过山车尤其是被拒的时候一度怀疑自己是不是哪里没做好。但回过头来看被拒其实是好事它逼着我把那些忽略的细节补上了。如果你也在准备上架我的建议是预留至少两天的时间给审核和修改不要等到最后一天才提交。6. 给想用 AI 辅助开发的独立开发者的几条实在建议6.1 AI 是加速器不是自动驾驶Codex 这类工具能帮你快速生成代码但它不会替你思考。尤其是涉及到业务规则、边界条件、用户体验的地方你必须自己把关。我的经验是把 AI 当成一个打字很快但经验不足的初级工程师。你可以让它写框架、写样板代码、写重复的逻辑但核心算法和关键决策必须自己来。比如象棋的评估函数AI 可以给你一个基础版本但具体的权重参数需要你根据实际对局效果来调整。这些参数没有标准答案只能靠反复测试。6.2 测试驱动开发在 AI 协作中更重要因为 AI 生成的代码质量参差不齐你更需要用测试来保证正确性。我在开发规则引擎时先写测试用例再让 Codex 生成代码然后跑测试看是否通过。如果不通过就把失败信息贴给 Codex让它修正。这种“测试—生成—验证”的循环比“生成—手动调试”效率高得多。而且测试用例本身就是最好的文档后续如果你想修改规则跑一遍测试就知道有没有破坏原有功能。6.3 上架只是开始维护才是长跑App 上架之后你还会收到用户的反馈、系统的更新、以及各种兼容性问题。比如 iOS 每次大版本更新SwiftUI 的 API 都可能有变化你需要及时适配。我的建议是保持代码的模块化把规则引擎、UI 渲染、AI 搜索分开这样当某个部分需要修改时不会影响到其他部分。另外定期备份代码和素材避免因为意外丢失进度。独立开发是一场马拉松不是短跑能坚持下来的人往往是那些把基础打扎实的人。6.4 关于中国象棋这个题材的额外提醒如果你也想做象棋类应用有几个版权问题需要注意。棋子的样式、棋盘的纹理、音效最好都自己原创或者使用开源可商用的素材。我见过一些开发者直接用了某款商业象棋的棋子图片结果被投诉下架。另外象棋的规则本身没有版权但如果你用了特定的开局库或者残局库那些数据可能有版权。我的做法是只用自己实现的搜索算法不依赖任何外部棋谱数据这样最安全。最后App 的名称不要包含“官方”“正版”这类词汇否则容易被判定为误导用户。老老实实叫“中国象棋”或者“象棋对弈”反而更容易过审。