Quá trình tạo một web game được tự động phát triển và triển khai mỗi ngày từ việc tổng hợp ý kiến người dùng

Tôi đã thử làm một web game với ý tưởng là tập hợp các mục phản hồi của người dùng rồi triển khai vào ngày hôm sau.
Đây là dự án tôi làm để làm quen hơn với các công cụ AI, và vì GitHub cũng được công khai nên cứ thoải mái xem qua nhé.
game: https://spiralwave.frogred8.dev
github: https://github.com/frogred8/SpiralWave

• Tổng quan và lên kế hoạch dự án
  • Động lực và mục tiêu: thử nghiệm vibe coding với các công cụ AI đã phát triển mạnh hơn (Gemini, v.v.) và thử phát triển web game bằng những công nghệ chưa từng dùng.
  • Hướng phát triển: quyết định làm một mini web game kiểu 'thu thập tài nguyên có giới hạn thời gian' trong đó ý kiến người dùng được tự động phản ánh mỗi ngày.
• Tạo nguyên mẫu ban đầu
  • Khái niệm cốt lõi: game thu thập tài nguyên và xây dựng cây kỹ năng, không có cạnh tranh hay mất mát.
  • Ứng dụng AI: chuyển bản phác thảo giấy thành prompt và dựng cấu trúc game cơ bản dựa trên TypeScript, Vite, Phaser chỉ trong 30 phút.
• Giới hạn của việc hiện thực logic phức tạp và cách tự giải quyết
  • Phát triển cây kỹ năng: logic kỹ năng tiên quyết cơ bản được hiện thực bằng AI, nhưng với logic phức tạp là khi hủy nút trung gian thì các nút con bị hủy dây chuyền, AI không giải được nên tôi tự làm.
  • Bỏ qua mã kiểm thử: do thiết kế thay đổi thường xuyên và tốc độ phát triển nhanh, tôi cố ý không viết mã test.
• Refactor quy mô lớn và đặc tính của việc debug bằng AI
  • Tách UI: do một file đơn trở nên quá cồng kềnh nên tôi tách mã UI ra, nhưng độ thống nhất và mức độ hài lòng về cấu trúc đều thấp; qua đó xác nhận rằng với các tác vụ lớn, cách tăng cường prompt rồi làm lại là hiệu quả.
  • Bug về thứ tự thực thi: với lỗi runtime phát sinh sau refactor (thứ tự cập nhật trạng thái và hiển thị UI bị đảo ngược), AI chỉ lạm dụng guard code, nên cuối cùng lập trình viên con người phải tự nắm luồng và sửa trực tiếp hai dòng mã để giải quyết đơn giản.
  • Sai sót của AI khá giống con người nên mang lại một cảm giác khá lạ.
• Áp dụng auto commit Git và hướng dẫn
  • Xây dựng hướng dẫn prompt: để giảm sự phiền toái của việc lặp lại chỉ thị, tôi đưa vào file chỉ dẫn (GEMINI.md) tổng hợp tech stack và cách hệ thống vận hành.
  • Workflow tự động hóa: sau khi hoàn tất công việc với mã, tôi thiết lập để tự động tạo commit message chứa thời gian chạy agent, prompt chỉ thị và tóm tắt công việc, nhờ đó giảm công sức review đơn giản.
• Thiết kế và tối ưu kiến trúc cập nhật tự động
  • Chuyển đổi cách triển khai: phương án triển khai tự động thời gian thực mỗi 2 giờ như dự tính ban đầu bị loại bỏ vì tỷ lệ phát sinh bug runtime cao (khoảng 25%) làm độ ổn định build kém; thay vào đó quyết định tạo/triển khai một bản build kiểm thử hằng ngày riêng biệt.
  • Workflow Cron: sử dụng node:cron để xây dựng quy trình tự động hóa kiểu nguyên khối nối tiếp 'thu thập phản hồi → tinh chỉnh → sinh mã → build và tạo bản phát hành → triển khai'.
  • Cập nhật release note: chia sẻ file danh sách server giữa các instance Docker bằng common volume và áp dụng cache hết hạn sau 5 phút để kiểm soát tải; đồng thời hiện thực việc tinh chỉnh các yêu cầu đa ngôn ngữ của người dùng sang tiếng Anh rồi dịch lại để hiển thị release note.
• Những tính năng bị loại bỏ trong quá trình phát triển
  • Tính năng đề xuất/Like cho ý kiến trên leaderboard (thiếu định danh và gánh nặng chi phí gọi API).
  • Công cụ quản lý dữ liệu kỹ năng tinh vi (giới hạn về sức tưởng tượng và việc sửa trực tiếp JSON hiệu quả hơn).
  • Môi trường phân tán Docker theo từng dịch vụ (gộp thành 1 image để tối thiểu hóa độ phức tạp vận hành và quản lý).
  • Tính năng thông báo email khi ý kiến người dùng được phản ánh (rủi ro về tính hiệu lực của việc thu thập mail không cần đăng ký và nguy cơ bị giả mạo).
  • Thêm quảng cáo bên hông (mệt mỏi với quy trình phê duyệt của nền tảng và hiệu quả thấp so với đơn giá thấp).
• Cảm nhận sau khi phát triển dựa trên AI
  • Trade-off giữa năng suất và kiểm thử: tốc độ hiện thực khi phát triển tăng khoảng 10 lần, nhưng đồng thời gặp giới hạn khi thời gian và mức độ mệt mỏi cho việc kiểm chứng (QA) cũng tăng tương ứng.
  • Đặc điểm của chất lượng mã: độ hoàn thiện ở cấp độ hàm cao nhưng khả năng đọc thấp nên khó nắm được toàn bộ luồng, đồng thời có xu hướng đưa vào các mẫu khái quát hóa không cần thiết một cách cồng kềnh ngay cả trong những tình huống mà hard coding cục bộ lại có lợi hơn.

[recast7838]

Thú vị đấy.