企业官网建设流程全解析

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 的名称不要包含“官方”“正版”这类词汇，否则容易被判定为误导用户。老老实实叫“中国象棋”或者“象棋对弈”，反而更容易过审。