Sinh màn hình Flutter bằng Claude Code

Trả lời nhanh: Agent dựng màn hình Flutter rất nhanh, nhưng kết quả chỉ dùng được khi bạn mô tả theo trạng thái chứ không theo giao diện: màn hình này có những trạng thái nào, dữ liệu tới từ đâu, lỗi thì hiện gì. Bốn chỗ luôn phải tự kiểm: quản lý trạng thái có đúng cách dự án đang dùng không, trạng thái đang tải và trạng thái lỗi có được xử lý không, màn hình nhỏ có bị tràn không, và chuỗi hiển thị có tách ra để dịch được không.

Dựng màn hình là phần lặp lại nhiều nhất khi làm ứng dụng di động, nên cũng là chỗ agent giúp được nhiều nhất. Nhưng code sinh ra thường trông đúng mà thiếu những phần chỉ lộ ra khi chạy trên máy thật. Bài này chỉ cách mô tả cho đúng và những chỗ phải soi.

Mô tả theo trạng thái, không theo hình dáng

Cách mô tả kém hiệu quả: làm màn hình danh sách sản phẩm có ảnh và giá. Agent sẽ dựng một danh sách trông ổn nhưng thiếu mọi thứ khiến nó dùng được thật.

Cách mô tả tốt hơn:

Màn hình danh sách sản phẩm. Trạng thái:- Đang tải lần đầu: hiện khung xương- Có dữ liệu: danh sách cuộn, tải thêm khi gần cuối- Danh sách rỗng: hiện thông báo và nút thử lại- Lỗi mạng: giữ dữ liệu cũ nếu có, hiện thanh báo lỗi Dữ liệu tới từ ProductRepository.fetch(page, size), trả về Result.Quản lý trạng thái theo cách dự án đang dùng, xem lib/features/orders làm mẫu.Chuỗi hiển thị lấy từ file dịch, không viết thẳng trong widget.

Dòng cuối cùng và dòng nhắc tới màn hình mẫu là hai câu tiết kiệm nhiều thời gian nhất: chúng buộc code sinh ra khớp với dự án thay vì theo mẫu chung trên mạng.

Đặt quy ước vào file luật

Thay vì nhắc lại mỗi lần, ghi vào file quy ước dự án theo bài CLAUDE.md:

# Quy ước Flutter cho dự án này - Quản lý trạng thái dùng đúng thư viện đang có, không thêm thư viện mới- Mỗi màn hình tách hai phần: widget hiển thị và lớp lấy dữ liệu- Mọi chuỗi hiển thị lấy từ file dịch- Widget dài quá 150 dòng thì tách thành widget con- Không gọi mạng trực tiếp trong widget ## Không được làm- Không thêm gói mới khi chưa hỏi- Không sửa file trong lib/core

Hai dòng cấm cuối quan trọng: agent rất hay thêm một gói mới vì đó là cách nhanh nhất để giải quyết vấn đề trước mắt, trong khi dự án của bạn có thể đã có công cụ tương đương.

Bốn chỗ luôn phải kiểm

Quản lý trạng thái. Nếu dự án dùng một cách và code mới dùng cách khác, bạn có hai kiểu trong cùng ứng dụng. Đây là thứ tích tụ thành nợ kỹ thuật nhanh nhất.

Trạng thái đang tải và trạng thái lỗi. Code sinh ra thường xử lý đường đi thuận lợi rất tốt và bỏ qua hai trạng thái này, hoặc xử lý qua loa bằng một vòng xoay.

Tràn màn hình. Bố cục trông ổn trên máy mô phỏng màn hình lớn nhưng tràn trên máy nhỏ, hoặc khi bàn phím hiện lên. Đây là lỗi phổ biến nhất và chỉ lộ ra khi chạy thử.

Chuỗi hiển thị viết thẳng trong widget. Rất hay xảy ra dù bạn đã nhắc. Tìm nhanh bằng cách quét các chuỗi ký tự trong file vừa sinh.

Chạy thử là bắt buộc

Code biên dịch được không có nghĩa là màn hình dùng được. Ba mức kiểm tra, nên làm cả ba:

1. Chạy trên máy giả lập với vài kích thước màn hình khác nhau, theo bài về emulator.
2. Thử các trạng thái biên: danh sách rỗng, mất mạng giữa chừng, dữ liệu có tên rất dài.
3. Chạy trên máy thật trước khi phát hành, vì hiệu năng cuộn và cảm giác chạm chỉ đánh giá được ở đó.

Trạng thái tên rất dài đáng nhắc riêng: với tiếng Việt có dấu, chuỗi thường dài hơn tiếng Anh và hay làm vỡ bố cục được thiết kế theo mẫu tiếng Anh. Đây là lỗi rất hay gặp với code sinh từ các mẫu quốc tế.

Việc nào giao được, việc nào không

Giao được và tiết kiệm nhiều: dựng khung màn hình theo mẫu đã có; chuyển đổi bố cục sang màn hình nhỏ; viết lớp gọi dữ liệu theo mẫu chung; sinh dữ liệu mẫu để thử; viết kiểm thử cho phần logic.

Nên tự làm hoặc kiểm rất kỹ: phần chuyển động và hiệu ứng, vì chúng đòi cảm nhận chứ không đòi cú pháp; phần liên quan tới hiệu năng cuộn với danh sách lớn; và mọi thứ chạm tới thanh toán.

Với việc lớn hơn một màn hình, hãy bắt agent trình kế hoạch trước theo bài về plan mode. Kiểm tra danh sách file nó định sửa sẽ lộ ra ngay nếu nó định đụng vào phần lõi mà bạn không muốn.

Phần build và phát hành sau đó nằm ở bài build APK và AAB.

Bảng bốn chỗ công cụ hay làm thiếu

Hai dòng đầu là hai thứ quyết định trải nghiệm thật với mạng di động ở Việt Nam: người dùng thường xuyên gặp mạng chậm, và màn hình không có trạng thái đang tải trông như ứng dụng bị treo.

Mô tả kém và mô tả đủ trạng thái, đặt cạnh nhau

# Mo ta KEM: "lam man hinh danh sach san pham co anh va gia"#   -> ra mot man hinh chi co truong hop binh thuong # Mo ta TOT: neu du bon trang thai#   "Man hinh danh sach san pham. Bon trang thai:#    1. Dang tai: hien khung xam thay cho tung the#    2. Co du lieu: the gom anh, ten, gia dinh dang so nguyen dong#    3. Danh sach rong: hien thong bao va nut thu lai#    4. Loi mang: hien thong bao ngan va nut thu lai#    Chu tieng Viet co dau, khong cat chu, xuong dong neu dai."

Đặt quy ước vào tệp luật dự án

• Bảng màu và cỡ chữ: chỉ dùng giá trị đã khai, không tự thêm giá trị mới.
• Khoảng cách: chỉ dùng các bước đã định, không dùng số tùy ý.
• Kiểm thư mục thành phần trước khi tạo mới, để không sinh ra bảy phiên bản của cùng một cái nút.
• Mọi màn hình phải có đủ bốn trạng thái ở bảng trên.

Ranh giới giữa việc giao được và việc tự làm

• Giao được: dựng bố cục từ mô tả, tạo thành phần lặp lại, chuyển thiết kế thành mã, viết phần hiển thị danh sách.
• Không nên giao trọn: luồng thanh toán, luồng đăng nhập, và bất cứ chỗ nào xử lý tiền. Những chỗ này phải đọc kỹ từng dòng.
• Chạy thử là bắt buộc, không chỉ đọc mã. Giao diện chỉ lộ vấn đề khi chạy trên máy thật với dữ liệu thật.