背景
最近因为其他原因，借助 Trae 完成了这款“扫雷”小游戏。本来打算是参与掘金产品体验活动的，无奈这台五年前的 MacBook 内存实在支撑不住，把存档和截图都删了。那就就着这个项目，聊聊 AI 对前端开发的影响吧。
一点思考
模型发展至今，虽然 Claude-3.5-Sonnet 发布很长时间了，但与当初的 4096 Token 长度限制，不管是文本长度和多模态，都已经领先了非常多了。这类模型之上的工具，使得研发在拿到需求，设计业务流程、项目结构，沟通接口、字段等之后，不用展开更多任务派发和业务指导即可着手开发，直接颠覆了传统研发需要（大概）的一高二中四初级的人员配备。
也就是说，资深开发参与到一线研发会更高效，减少沟通的同时产出也更有保障。对于入门、初级研发，会是巨大的挑战，但好处是门槛更低，成长更快了。
在技术侧，文档的准备、强类型的定义变得更为重要，语义越明确代码的产出质量越高。先开发再补文档，可能效率还真没有这么快。
过程
回到“扫雷”这个项目，就是边写文档边写代码。
优先：文档 or 代码
雷区生成函数，因为考虑到第一次点击的问题，优先设计了文档，再给出代码逻辑，这块直接给出代码后，就没再修改。
UI 部分直接给的图片与简单描述，拆分的模块和状态管理就没有这么完美了，按道理 游戏（业务）的状态和较基础的状态有关联，应由一处组合管理，基础组件的单一性会更清晰；并且从UI的角度，雷区布局组合成了仅透传状态的组件，多个层级虽然可以更好的聚合操作，但这里其实还没有这个必要。在后续调整的时候浪费了不少时间。
强类型 和 语义
这个项目虽然在类型使用上没有出现问题，就定义 type key 的时候会根据当前代码定义了。在语义上建议使用 tailwind.css 和 tsx 这类包含信息更多更标准，逻辑表述更强的方式。
最后
在初步完成之后，还引导和手动的处理了遍历翻开死循环，道具功能添加和 UI 调整等内容。具体想了解的可以查看 Github，代码量挺少的，就是遍历算法加了 UI。
最后，与其说 AI 在取代开发者，不如说它在重新定义开发者的角色，它的上限，取决于我们。