重修一个烂尾小工具后,我对AI编程清醒了一点

我最近又想打扑克，才想起十个月前自己用 GitHub Copilot 糊过一个筹码计数器。

它不是完全不能用。它能跑，有页面，也确实能记录筹码。但每次真要拿出来给朋友用，我又会犹豫：all in 和边池算不清，联网同步偶尔抽风，页面越用越长，代码更是堆成一团。

这类项目尴尬的地方在于，它勉强超过了“玩具 demo”，但还没到“真的能用”。于是它就被放在那里，像一个小小的技术债。

这次我把它重新丢给 Codex，目标很简单：不是再做一个新 demo，而是把这个旧东西修到我真的敢拿去玩牌。

先让我们读懂项目

这个项目是我早期 AI 编程的产物。当时我基本没有前端基础，JavaScript 也看不太明白，如今也够呛，而且连之前到底有哪些 bug 都忘了。

所以我没有一上来就让 Codex 改代码，而是先问了一句：

请给我讲讲这个项目

它先把文件结构、运行方式、主要逻辑、亮点和问题都讲了一遍。等我确认它大致理解了项目，再让它检查代码逻辑、安全性和健壮性，并给出修改建议。

这一步其实挺重要。

很多时候，我们对 AI 编程的期待太像“我说一句，它变一个结果”。但在一个已经存在、并且有历史包袱的项目里，第一步更应该是让它和你站到同一张地图上。

后面我把智能等级和权限都拉高，让它集中处理这些问题，还顺手把“手动输入赢家”改成了按钮选择。

代价也很真实：它啃了十几分钟，改了上千行代码，又用 Playwright 做了大量测试，五小时更新的额度一下子用掉了 80%。

要我说，这才算是工程。工程就会消耗时间、上下文和额度。

难以走通的其实是德扑规则

之前很困扰我的问题，是 all in 和边池。

如果一个玩家筹码不足全下，其他玩家继续下注，就会形成边池。全下玩家即使赢，也只能拿走和他筹码对应的那部分；后面的边池则由剩下的玩家争夺。

这套规则我自己都没完全想清楚过，更不知道怎么高效测试。所以去年不管怎么改，总觉得差一点。

这次反而因为“把赢家输入改成按钮选择”，把整个底池系统顺出来了。

赢家不再靠手动输入名字，而是点按钮进入待选状态，再确认结算。这样既能避免误触，也能支持多人平分。边池会一层层排下来，不该参与某个池子的玩家自动不可选。

我为了改进使用体验而冒出来的想法，被做成了解决关键卡点的直观设计。

它把一段很绕的规则，变成了用户看得懂、点得动的界面。这也是我这次最满意的地方：Codex 不只是在补 bug，它把一个模糊需求扩成了可操作的交互。

早期的 LLM + IDE 只是一个会补全代码的助手，而现在的 coding agent 在足够清晰的任务里，已经能反复检查自己的方案，把一些原本没说透的细节补出来。

当然，前提是任务足够清晰，权限足够开放。

小修小补

修完大问题以后，小问题开始冒头。

比如某个状态变量串了，导致弃牌也会被当成开边池的条件。比如牌局记录一直往下堆，页面越来越长。再比如我让它提交到远程后，打开 GitHub Pages 一看，页面居然像修改前和修改后的混合体。

这件事最后查出来，更像是分支、远程主分支、Pages 构建和缓存混在一起造成的错觉。Codex 的处理方式倒是很稳：先确认当前分支，再比较本地和远端文件树，最后在主分支上做一次直接提交，触发 Pages 重新部署。

如果你不熟 Git，这一段就很像玄学。

我当时的感受大概是：果然是不学数理化，处处是魔法。只不过这次有个 agent 可以陪我把魔法拆回命令和状态。

这类体验让我意识到，AI 编程有用的地方，不一定是写出多炫的功能，还可以是在你不知道该从哪里排查时，替你把混乱局面摊开。

联网同步，才是从烂尾到实装的裂口

联网同步扯出来的这些问题，是我去年放弃这个项目的最主要原因。

我不需要一个复杂产品，只需要大家打开同一个房间号，就能同步当前牌局、玩家筹码和操作记录。

但现实里会遇到很多麻烦：网络延迟、多人同时操作、远端状态覆盖本地状态、写入失败之后界面不知道该相信谁。

这一次，Codex 帮我把 Firebase 配置和同步逻辑重新理了一遍。最终的策略也不花哨：同步过程中禁用关键操作；写入失败或被其他设备抢先更新时，从远端恢复；必要时通过刷新动作避免界面卡在中间态。

这些都不是惊天动地的功能。

但它们决定了这个工具能不能真的拿到桌上用。很多 AI demo 的问题就在这里：演示时看起来很顺，真正多人使用时，各种边界状态会一起出来。一个工具从“能跑”到“能用”，中间隔着的往往就是这些不漂亮的小逻辑。

拆文件，给以后留路

等我简单测试已经发现不了明显问题，再翻代码，发现已经一千多行。

于是我新开了一个对话，让 Codex 分析这份代码是不是应该拆。它的判断也很直接：如果以后还会继续扩展，现在就值得拆。

拆完之后，代码总量并没有神奇变少，甚至有些文件仍然很大。它只是被放进了 src 目录，Firebase 配置也被拆了出来。

但这件事对我很有意义。

以前我很容易把“代码能跑”当成结束。现在我更愿意多问一句：如果下个月再回来，我还能不能看懂？如果再加功能，会不会每一步都踩到旧逻辑？

这也是 coding agent 改变我的地方。它不只是在写代码，也在逼我用更像工程项目的方式管理自己的小作品。

改完界面，它终于像一个能拿上桌的东西

功能修完以后，我又看了看原来的页面。

那套绿色格子还是挺可爱的，毕竟是自己一点点试出来的。但如果真的要给别人用，我不太希望它会冲别人大喊“我刚学会前端”。

我开了个新对话，给 Codex 的关键词是“扑克味”和“高级感”。

结果虽然还能看出一点 AI 味，但已经非常接近我的预期：更像德扑桌垫和复古金边筹码，手机端用起来也舒服得多。顺手做了个图标之后，这个项目的完成度一下子上去了。

移动端界面

这大概是我目前最喜欢的 AI 编程时刻：并没有凭空造出一个巨大东西，但是把一个本来灰头土脸的小项目，慢慢修到自己喜欢。

局限性不是工具的，而是我的

这次以后，我对 Codex 的局限性也有了些感受。

一个一千多行的小项目，在高智能和高速模式下，很快就能吃掉大量额度。上下文窗口也不是无限的，长时间连续开发时，很容易需要重新同步项目状态。

所以我开始更认真地做几件事：

把主对话留给连续开发和架构理解；把相对独立的任务拆到新对话；定期更新项目文档，记录当前状态、顶层规则和修改历史；不要每次都让 agent 从零猜项目。

这听起来有点麻烦，但它其实是在承认一件事：

Agent 不是一个无所不能的大活人。它更像一台能力很强、但需要你给出工作现场和边界条件的工程机器。

用得好，它能把你从很多繁琐细节里解放出来。

用得糊涂，它也会把你的糊涂放大。

最后

这次重修德州扑克筹码计数器，不算什么大项目。

它没有复杂架构，也没有惊人的技术突破。它只是一个我真的会用的小工具：能算底池，能处理 all in，能联网同步，界面也终于像个样子。

但正因为它小，它才让我更清楚地看到 coding agent 的价值。

有意义的 AI 编程体验，不是每天造一个新 demo，而是终于把一个被你放了十个月的小东西，修到可以拿出来用。

这件事对我来说，比又多做一个半成品重要多了。