Claude Code cho lặp giao diện Flutter: một quy trình làm việc thực tế

Vấn đề: lặp UI nhanh mà không biến thành mớ hỗn độn

Công việc UI Flutter nhanh thường bắt đầu ổn. Bạn tinh chỉnh layout, thêm một nút, di chuyển một trường, và màn hình cải thiện nhanh. Vấn đề xuất hiện sau vài vòng, khi tốc độ biến thành một đống thay đổi chẳng ai muốn review.

Các nhóm thường gặp cùng những thất bại giống nhau:

• Cây widget phát triển không theo kế hoạch, nên một thay đổi “nhỏ” bắt buộc phải sửa nhiều file.
• State bị dán chặt vào mã UI, khiến rebuild khó đoán và bug khó lần ra.
• Logic điều hướng bị tản mát (một push ở đây, một pop ở kia) cho đến khi flow không còn khớp với cách người dùng thực sự di chuyển trong app.
• Đặt tên trôi dạt, component bị nhân đôi, và chẳng ai chắc widget nào là “thật”.
• Diffs trở nên khổng lồ, reviewers lướt qua, vấn đề lọt qua, và regression xuất hiện sau đó.

Một nguyên nhân lớn là cách "một prompt lớn": mô tả toàn bộ tính năng, yêu cầu toàn bộ tập màn hình, và chấp nhận đầu ra lớn. Trợ lý cố gắng giúp, nhưng nó chạm vào quá nhiều phần của mã cùng lúc. Điều đó khiến thay đổi lộn xộn, khó review và rủi ro khi merge.

Một vòng lặp có thể lặp lại được sẽ khắc phục bằng cách buộc sự rõ ràng và giới hạn phạm vi ảnh hưởng. Thay vì "xây tính năng", làm lặp lại: chọn một user story, tạo lát cắt UI nhỏ nhất chứng minh nó, chỉ thêm state cần cho lát đó, rồi nối điều hướng cho một đường đi. Mỗi lần giữ đủ nhỏ để review, và lỗi dễ rollback.

Mục tiêu ở đây là một quy trình thực tế để biến user stories thành màn hình cụ thể, xử lý state và luồng điều hướng mà không mất kiểm soát. Làm tốt, bạn sẽ có các mảnh UI mô-đun, diffs nhỏ hơn và ít bất ngờ khi yêu cầu thay đổi.

Biến user stories thành spec UI rõ ràng để xây dựng

User stories viết cho con người, không phải cho cây widget. Trước khi sinh mã gì, chuyển story thành một spec UI nhỏ mô tả hành vi hiển thị. "Hoàn thành" phải có thể kiểm tra: những gì người dùng thấy, chạm và xác nhận, chứ không phải thiết kế "trông hiện đại".

Một cách đơn giản để giữ scope cụ thể là chia story thành bốn phần:

• Screens: thay đổi gì, giữ nguyên gì.
• Components: các mảnh UI mới xuất hiện, và chúng nằm chỗ nào.
• States: loading, success, error, empty, và mỗi trạng thái hiển thị gì.
• Events: tap, swipe, pull-to-refresh, back, retry.

Nếu story vẫn mơ hồ, trả lời các câu hỏi sau bằng ngôn ngữ đơn giản:

• Màn hình nào thay đổi, màn hình nào giữ nguyên?
• Component mới nào xuất hiện và chúng thuộc đâu?
• State nào tồn tại, mỗi state hiển thị gì?
• Sự kiện nào thay đổi state?
• Kiểm tra chấp nhận có thể làm trong 30 giây sau khi chạy app là gì?

Thêm các ràng buộc sớm vì chúng hướng mọi quyết định layout: cơ bản theme (màu, khoảng cách, typography), phản hồi kích thước (ưu tiên điện thoại chế độ dọc, sau đó là tablet), và tối thiểu truy cập (kích thước chạm, text scale dễ đọc, nhãn ý nghĩa cho icon).

Cuối cùng, quyết định cái gì là ổn định và cái gì linh hoạt để không churn codebase. Những thứ ổn định là những gì các tính năng khác phụ thuộc vào, như tên route, data model và API hiện có. Những thứ linh hoạt an toàn để lặp là cấu trúc layout, microcopy và cấu thành widget chính xác.

Ví dụ: "As a user, I can save an item to Favorites from the detail screen." Một spec UI có thể xây được như sau:

• Màn hình detail hiển thị biểu tượng bookmark.
• Chạm để chuyển trạng thái saved.
• Trong khi lưu, hiển thị một progress nhỏ.
• Khi thất bại, hiển thị lỗi nội tuyến với hành động Retry.
• Điều hướng giữ nguyên (không thêm route mới).

Đó là đủ để xây, review và lặp mà không phải đoán mò.

Thiết lập vòng lặp lặp để diffs nhỏ

Diffs nhỏ không có nghĩa là làm chậm. Chúng giúp mỗi thay đổi dễ review, dễ undo và khó làm hỏng. Quy tắc đơn giản: một màn hình hoặc một tương tác mỗi lần lặp.

Chọn một lát cắt chặt trước khi bắt đầu. "Thêm empty state cho màn hình Orders" là một lát cắt tốt. "Tái cấu trúc toàn bộ Orders flow" thì không. Hướng tới một diff mà đồng đội có thể hiểu trong một phút.

Cấu trúc thư mục ổn định cũng giúp giữ thay đổi có giới hạn. Một layout tính năng-đầu tiên đơn giản ngăn bạn rải widgets và routes khắp app:

lib/
  features/
    orders/
      screens/
      widgets/
      state/
      routes.dart

Giữ widget nhỏ và có thành phần. Khi một widget có inputs và outputs rõ ràng, bạn có thể thay layout mà không chạm tới logic state, và thay state mà không viết lại UI. Ưu tiên widget nhận giá trị thuần và callback, không phải state global.

Một vòng lặp dễ review:

• Viết spec UI 3–6 dòng cho lát cắt (xuất hiện gì, tap làm gì, loading/error trông thế nào).
• Sinh hoặc sửa chỉ những file tối thiểu cần (thường là một màn hình và một hoặc hai widget).
• Chạy màn hình, rồi làm một lượt cleanup (đổi tên, khoảng cách, loại props không dùng).
• Commit với message trùng với lát cắt.

Đặt quy tắc cứng: mỗi thay đổi phải dễ revert hoặc cô lập. Tránh refactor rải rác trong khi lặp trên một màn hình. Nếu bạn thấy vấn đề không liên quan, ghi lại và sửa trong commit riêng.

Nếu công cụ của bạn hỗ trợ snapshot và rollback, dùng mỗi lát cắt như một điểm snapshot. Một số nền tảng vibe-coding như Koder.ai có snapshot và rollback, giúp thử nghiệm an toàn hơn khi bạn muốn thay đổi UI mạnh.

Một thói quen nữa giúp các vòng lặp sớm bớt ồn: ưu tiên thêm widget mới thay vì sửa widget chia sẻ. Component chung là nơi một thay đổi nhỏ biến thành diffs lớn.

Từng bước: tạo cây widget từ user story

Công việc UI nhanh an toàn khi bạn tách việc suy nghĩ ra khỏi gõ phím. Bắt đầu bằng một kế hoạch cây widget rõ ràng trước khi sinh mã.

1. Yêu cầu chỉ outline cây widget. Bạn muốn tên widget, thứ bậc, và mỗi phần hiển thị gì. Chưa code. Đây là lúc bạn phát hiện thiếu trạng thái, màn hình rỗng, và lựa chọn layout lạ khi mọi thứ còn rẻ để thay đổi.

2. Yêu cầu breakdown component với trách nhiệm. Giữ mỗi widget tập trung: một widget render header, một widget render list, một widget xử lý empty/error UI. Nếu cần state sau này, ghi chú nhưng chưa triển khai.

3. Sinh scaffold màn hình và các stateless widget. Bắt đầu với một file màn hình duy nhất có nội dung placeholder và TODO rõ ràng. Giữ inputs rõ ràng (constructor params) để bạn có thể cắm state thật sau này mà không viết lại cây.

4. Làm một pass riêng cho style và chi tiết layout: spacing, typography, theming và hành vi responsive. Xử lý style như một diff riêng để review dễ dàng.

Một mẫu prompt hiệu quả

Đặt ràng buộc ngay từ đầu để trợ lý không phát minh UI bạn không thể ship:

• Thiết bị mục tiêu (chỉ phone, tablet nữa, orientation)
• Hạn chế thiết kế (Material 3, màu theme hiện có, quy tắc khoảng cách)
• Kỳ vọng điều hướng (hành vi back, deep links nếu có)
• Tiêu chí chấp nhận (phải hiển thị và có thể chạm gì)
• Ranh giới mã hiện có (file/widget nào phải giữ, quy ước đặt tên)

Ví dụ cụ thể: user story là "As a user, I can review my saved items and remove one." Yêu cầu một widget tree gồm app bar, list với item rows, và empty state. Sau đó yêu cầu breakdown như SavedItemsScreen, SavedItemTile, EmptySavedItems. Chỉ sau đó, sinh scaffold với stateless widgets và fake data, rồi thêm style (divider, padding, nút remove rõ ràng) trong một pass riêng.

Thêm xử lý state mà không làm phình mã UI

Việc lặp UI sụp đổ khi mỗi widget bắt đầu đưa ra quyết định. Giữ cây widget “ngu”: nó đọc state và render, không chứa business rules.

Bắt đầu bằng cách đặt tên các state bằng ngôn ngữ đơn giản. Hầu hết tính năng cần hơn "loading" và "done":

• Loading (lần tải đầu hoặc refresh)
• Empty (chưa có dữ liệu)
• Error (request thất bại, bị từ chối quyền)
• Success (dữ liệu sẵn sàng)
• Partial input (form bắt đầu nhưng chưa hợp lệ)

Rồi liệt kê các event có thể đổi state: tap, submit form, pull-to-refresh, back, retry, và "user edited a field." Làm điều này trước tránh đoán mò sau.

Giữ state tách khỏi widget

Chọn một cách quản lý state cho feature và giữ nó. Mục tiêu không phải "pattern tốt nhất" mà là diffs nhất quán.

Với màn hình nhỏ, một controller đơn giản (ChangeNotifier hoặc ValueNotifier) thường đủ. Đặt logic ở một chỗ:

• Inputs: event từ UI (submit, refresh, edit)
• Output: một đối tượng state duy nhất UI render
• Side effects: gọi API và yêu cầu điều hướng

Trước khi thêm mã, viết các chuyển trạng thái bằng câu tiếng Anh đơn giản. Ví dụ cho màn hình login:

"Khi user tap Sign in: đặt Loading. Nếu email không hợp lệ: ở lại Partial input và hiển thị thông báo nội tuyến. Nếu password sai: đặt Error với thông báo và bật Retry. Nếu thành công: đặt Success và điều hướng tới Home."

Rồi sinh mã Dart tối thiểu khớp với những câu đó. Reviews đơn giản vì bạn có thể so sánh diff với các quy tắc.

Thêm quy tắc testable cho input không hợp lệ

Làm validation rõ ràng. Quyết định điều gì xảy ra khi input không hợp lệ:

• Bạn chặn submit hay cho submit và hiện lỗi?
• Trường nào hiện lỗi, và khi nào?
• Back có hủy input một phần hay giữ lại?

Khi trả lời những câu này, UI sạch và mã state nhỏ.

Thiết kế luồng điều hướng khớp hành vi thực tế của người dùng

Điều hướng tốt bắt đầu như một bản đồ nhỏ, không phải một đống route. Với mỗi user story, viết ra bốn khoảnh khắc: nơi người dùng vào, bước tiếp theo có khả năng nhất, cách họ hủy, và "back" có nghĩa gì (trở về màn hình trước hay trở về trạng thái an toàn).

Bắt đầu bằng một route map, rồi khoá những gì được truyền giữa màn hình

Một route map đơn giản nên trả lời những câu thường gây phải làm lại:

• Entry: màn hình mở đầu, từ đâu (tab, notification, deep link)
• Next: đường chính tiếp theo sau hành động chính
• Cancel: nơi người dùng đến nếu họ bỏ flow
• Back: back có được phép không, và nó giữ gì
• Fallback: đi đâu nếu thiếu dữ liệu cần thiết

Rồi định nghĩa tham số truyền giữa màn hình. Rõ ràng: IDs (productId, orderId), filters (khoảng ngày, trạng thái), và draft data (form chưa hoàn chỉnh). Nếu bỏ qua, bạn sẽ nhồi state vào singletons global hoặc rebuild màn hình để "tìm" context.

Lên kế hoạch cho deep links và pattern "trả kết quả"

Deep link quan trọng ngay cả khi bạn không gửi đi ngày đầu tiên. Quyết định khi user vào giữa flow: bạn có thể load dữ liệu thiếu không, hay redirect về màn hình vào an toàn?

Cũng quyết định màn hình nào trả kết quả. Ví dụ: màn hình "Select Address" trả addressId, và màn checkout cập nhật mà không cần full refresh. Giữ dạng trả về nhỏ và typed để thay đổi dễ review.

Trước khi code, nêu ra các edge case: thay đổi chưa lưu (hiện confirm dialog), cần auth (tạm dừng và tiếp tục sau login), và dữ liệu bị thiếu hoặc bị xoá (hiện lỗi và cách thoát rõ ràng).

Làm thay đổi UI dễ review và mô-đun

Khi bạn lặp nhanh, rủi ro thực sự không phải "UI sai" mà là UI không thể review. Nếu đồng đội không biết gì đã thay đổi, tại sao, và gì là ổn định, mỗi vòng sau càng chậm.

Một quy tắc giúp: khoá giao diện công khai trước, rồi cho phép nội bộ di chuyển. Ổn định props public của widget (inputs), các UI model nhỏ, và arguments route. Khi tên và kiểu rõ, bạn có thể thay đổi cây widget mà không phá phần còn lại của app.

Ưu tiên các mối nối nhỏ, ổn định

Yêu cầu một kế hoạch diff-friendly trước khi sinh mã. Bạn muốn một kế hoạch nói rõ file nào sẽ thay đổi và file nào phải giữ im. Điều đó giữ review tập trung và ngăn refactor vô tình thay đổi hành vi.

Các pattern giữ diffs nhỏ:

• Giữ public widget mỏng: nhận đúng dữ liệu và callback cần, tránh truy cập singletons.
• Đưa business rules ra khỏi widget sớm: đặt quyết định vào controller hoặc view model, UI render state.
• Khi một mảnh UI không thay đổi mỗi giờ nữa, trích ra thành widget tái sử dụng với API rõ ràng, typed.
• Giữ route arguments rõ ràng (một object argument thường sạch hơn nhiều field optional).
• Thêm changelog ngắn vào mô tả PR: gì thay đổi, tại sao, và test gì.

Ví dụ cụ thể mà reviewers thích

Giả sử user story: "As a shopper, I can edit my shipping address from checkout." Khoá args route trước: CheckoutArgs(cartId, shippingAddressId) giữ ổn định. Rồi lặp bên trong màn hình. Khi layout ổn, tách thành AddressForm, AddressSummary, và SaveBar.

Nếu xử lý state thay đổi (ví dụ validation chuyển từ widget sang CheckoutController), review vẫn đọc được: các file UI chủ yếu thay đổi phần render, trong khi controller cho thấy logic thay đổi ở một chỗ.

Sai lầm phổ biến khi lặp với trợ lý AI

Cách nhanh nhất để làm chậm là yêu cầu trợ lý thay đổi mọi thứ cùng lúc. Nếu một commit chạm layout, state và điều hướng, reviewers không biết gì gây lỗi, và rollback khó khăn.

Thói quen an toàn là một intent mỗi lần: định hình cây widget, rồi wire state, rồi kết nối điều hướng.

Những lỗi khiến mã lộn xộn

Một vấn đề phổ biến là để mã sinh tự phát minh pattern mới mỗi màn hình. Trang này dùng Provider, trang kia dùng setState, trang thứ ba giới thiệu controller tuỳ chỉnh, app nhanh chóng mất sự nhất quán. Chọn một tập pattern nhỏ và tuân thủ.

Một lỗi khác là đặt công việc async trực tiếp trong build(). Khi demo nhanh có vẻ ổn, nhưng gây gọi lặp khi rebuild, flicker, và bug khó theo dõi. Di chuyển gọi vào initState(), view model hoặc controller, và giữ build() chỉ phụ trách render.

Đặt tên là cái bẫy im lặng. Mã biên dịch được nhưng đọc như Widget1, data2, hoặc temp khiến refactor tương lai đau. Tên rõ cũng giúp trợ lý sinh thay đổi follow-up tốt hơn vì ý định rõ ràng.

Các hàng rào ngăn chặn hậu quả tệ nhất:

• Chỉ thay đổi một trong: layout, state, hoặc navigation mỗi lần lặp
• Dùng cùng pattern state cho toàn feature
• Không gọi mạng hoặc DB trong build()
• Đổi tên placeholder trước khi thêm chức năng
• Ưu tiên trích widget hơn thêm nesting

Bẫy nesting

Một sửa lỗi hiển thị kinh điển là thêm một Container, Padding, Align, SizedBox cho vừa mắt. Sau vài lần, cây trở nên khó đọc.

Nếu một nút lệch, thử loại wrapper, dùng một parent layout đơn, hoặc trích một widget nhỏ với constraint riêng.

Ví dụ: màn checkout nơi tổng giá nhảy khi loading. Một trợ lý có thể bọc hàng giá bằng nhiều widget hơn để "ổn định" nó. Cách sạch hơn là dành sẵn chỗ bằng placeholder loading đơn giản trong khi giữ cấu trúc hàng.

Checklist nhanh trước khi commit lần lặp UI tiếp theo

Trước khi commit, làm một lượt hai phút kiểm tra giá trị người dùng và bảo vệ khỏi regression bất ngờ. Mục tiêu không phải hoàn hảo mà là đảm bảo lần lặp này dễ review, dễ test và dễ undo.

Checklist sẵn sàng commit

Đọc user story một lần, rồi kiểm tra các mục sau trên app đang chạy (hoặc ít nhất widget test đơn giản):

• Widget tree khớp story: Các phần chính từ acceptance criteria tồn tại và hiển thị. Text, nút và khoảng trắng có chủ ý.
• Tất cả trạng thái có thể đạt: Loading, error và empty không chỉ được phác thảo. Bạn có thể kích hoạt từng trạng thái (dù bằng flag debug tạm) và nó trông chấp nhận được.
• Điều hướng và hành vi back hợp lý: Back về màn hình mong đợi, dialog đóng đúng, và deep link (nếu dùng) dẫn tới nơi hợp lý.
• Diffs nhỏ và có sở hữu: Thay đổi giới hạn trong vài file có trách nhiệm rõ. Không refactor rải rác.
• Rollback sạch: Nếu revert commit này, các màn hình khác vẫn build và chạy. Loại bỏ flag tạm hoặc asset placeholder có thể phá sau này.

Một kiểm tra thực tế: nếu bạn thêm màn Order details mới, bạn nên có thể (1) mở từ list, (2) thấy spinner loading, (3) giả lập lỗi, (4) thấy order empty, và (5) bấm back về list mà không nhảy kỳ quặc.

Nếu workflow của bạn hỗ trợ snapshot và rollback, chụp snapshot trước thay đổi layout lớn. Một số nền tảng như Koder.ai hỗ trợ điều này và giúp lặp nhanh hơn mà không mạo hiểm nhánh chính.

Ví dụ thực tế: từ user story đến màn hình trong ba lần lặp

User story: "As a shopper, I can browse items, open a details page, save an item to favorites, and later view my favorites." Mục tiêu là đi từ lời đến màn hình trong ba bước nhỏ, dễ review.

Iteration 1: chỉ tập trung danh sách browse. Tạo cây widget đủ để render nhưng chưa ràng buộc dữ liệu thật: một Scaffold với AppBar, một ListView các hàng placeholder, và UI rõ cho loading và empty. Giữ state đơn giản: loading (hiện CircularProgressIndicator), empty (hiện thông báo ngắn và nút Try again), và ready (hiện list).

Iteration 2: thêm màn details và điều hướng. Giữ rõ ràng: onTap push route và truyền một object param nhỏ (ví dụ: item id, title). Bắt đầu details page read-only với tiêu đề, mô tả placeholder và nút Favorite. Mục tiêu là khớp story: list -> details -> back, không thêm luồng phụ.

Iteration 3: giới thiệu cập nhật favorites và feedback UI. Thêm một nguồn duy nhất cho favorites (dù vẫn in-memory), và nối nó vào cả hai màn. Tap Favorite cập nhật icon ngay và hiển thị xác nhận nhỏ (ví dụ SnackBar). Rồi thêm màn Favorites đọc cùng state và xử lý empty.

Một diff reviewable thường trông như:

• browse_list_screen.dart: cây widget cộng loading/empty/ready UI
• item_details_screen.dart: layout UI và nhận param navigation
• favorites_store.dart: minimal state holder và phương thức cập nhật
• app_routes.dart: routes và helper navigation typed
• favorites_screen.dart: đọc state và hiển thị empty/list UI

Nếu một file trở thành "nơi mọi thứ xảy ra", tách nó trước khi tiếp tục. File nhỏ, tên rõ giữ lần lặp sau nhanh và an toàn.

Bước tiếp theo: làm cho vòng lặp lặp được trên nhiều feature

Nếu workflow chỉ hoạt động khi bạn "vào zone", nó sẽ vỡ khi bạn đổi màn hay đồng đội chạm vào feature. Biến vòng lặp thành thói quen bằng cách ghi lại và đặt hàng rào quanh kích thước thay đổi.

Tạo mẫu prompt có thể tái sử dụng

Dùng một template nhóm để mọi lần lặp bắt đầu với cùng input và tạo cùng kiểu output. Ngắn nhưng cụ thể:

• User story + acceptance criteria ("done" nghĩa là gì)
• Ràng buộc UI (design system, spacing, component phải reuse)
• Quy tắc state (state ở đâu, local vs shared)
• Quy tắc navigation (routes, deep links, back behavior)
• Quy tắc output (file chạm, test cần cập nhật, giải thích trong diff)

Điều này giảm khả năng trợ lý phát minh pattern mới giữa chặng.

Định nghĩa "nhỏ" để diffs dự đoán được

Chọn một định nghĩa nhỏ dễ thi hành trong code review. Ví dụ, giới hạn mỗi lần lặp số file thay đổi và tách refactor UI khỏi thay đổi hành vi.

Một bộ quy tắc đơn giản:

• Không quá 3–5 file thay đổi mỗi lần lặp
• Một widget mới hoặc một bước navigation mỗi lần
• Không đổi phương pháp quản lý state giữa chặng
• Mọi thay đổi phải build và chạy trước khi bước tiếp

Thêm các điểm kiểm soát để undo nhanh. Ít nhất, gắn tag commit hoặc giữ checkpoint local trước refactor lớn. Nếu workflow hỗ trợ snapshot/rollback, dùng mạnh tay.

Nếu bạn muốn workflow chat có thể sinh và tinh chỉnh Flutter end-to-end, Koder.ai có chế độ planning giúp review kế hoạch và file dự kiến trước khi áp dụng.