Flutter - free resource mobile app, desktop, web

Rào cản để thử một AI coding agent trước đây là một cái API key và một cái thẻ tín dụng. OpenCode gỡ cả hai: gateway Zen của nó cho bạn chọn model hosted và dùng ngay, không mất tiền, không cần key.

Nghĩa là lý do cuối cùng để chưa học cách làm việc với agentic coding đã biến mất. Nhưng cũng nghĩa là sắp có rất nhiều người chĩa một model miễn phí vào repo riêng tư mà chưa kịp nghĩ chuyện đó kéo theo cái gì.

Cả hai điều đều đáng coi trọng. Dưới đây là tier free thật sự tốt cho việc gì, nó lấy của bạn cái gì bằng một loại tiền tệ không phải tiền, và cách sắp xếp công việc để bạn không phải trả tiền cho một model frontier chỉ để đổi tên biến.

”Miễn phí” ở đây nghĩa là gì

Có ba thứ khác nhau bị gộp chung dưới một chữ, và giới hạn của chúng khác nhau:

Công cụ thì miễn phí. Bản thân OpenCode là mã nguồn mở. Không giới hạn ở phía client, không license theo ghế, không đo đếm. Cắm API key riêng của bạn từ bất kỳ nhà cung cấp nào thì nó hoạt động như mọi agent harness khác.

Model hosted miễn phí nhưng có quota. OpenCode Zen là gateway tích hợp sẵn. Tier free của nó chạy ở mức 0đ/tháng với khoảng 100 request mỗi ngày, không cần thẻ, được dùng dàn model Zen. Các model được nhóm theo tier chứ không bán lẻ từng con — một tier mặc định với context lớn, một tier nâng cao với cửa sổ context lớn nhất, và một tier fast với context nhỏ nhưng độ trễ thấp hơn hẳn.

Free không có nghĩa là unlimited, và cũng không có nghĩa là riêng tư. Đó là hai điều mọi người hay bỏ qua, và cũng là hai điều quan trọng nhất.

Quota nhỏ hơn bạn tưởng

100 request mỗi ngày nghe rộng rãi cho tới khi bạn ngồi nhìn một agent làm việc. Một câu “sửa cái test đang fail này” có thể đốt năm tới mười lăm request, vì agent đọc file, chạy test, sửa, chạy lại, rồi đọc lỗi lần nữa. Vòng lặp agentic ngốn request theo cụm.

Thực tế: hãy trông đợi vài task thật mỗi ngày, chứ không phải một ngày làm việc dùng agent liên tục. Để học thì ổn. Nhưng đó không phải workflow bạn dám cam kết với một deadline.

Cái giá còn lại là source code của bạn

Đây là phần đáng nói thẳng chứ không phải ghi chú cuối trang: ở tier free, prompt và output nhìn chung được lưu lại và dùng để cải thiện model về sau. Đó là mô hình kinh doanh. Có một model trong dàn được ghi rõ là không bao giờ lưu hay dùng dữ liệu của bạn để train — nếu bảo mật là yêu cầu bắt buộc, đó là con cần tìm và cần kiểm chứng lại với tài liệu hiện hành, vì mấy chính sách này thay đổi.

Có một câu hay được nhắc ở đây — nếu bạn không trả tiền cho sản phẩm thì chính bạn là sản phẩm — và trong trường hợp này nó không phải phép ẩn dụ. Cái được trả chính là code của bạn.

Cũng lưu ý rằng tên model và thành phần tier free thay đổi rất nhanh. Danh sách đã đổi hai lần chỉ trong mấy tháng trước khi bài này được viết. Hãy coi mọi tên model cụ thể bạn đọc trong một bài blog, kể cả bài này, là ảnh chụp tại một thời điểm. Xem danh sách model Zen để biết hôm nay cái gì đang miễn phí, và xem luôn chính sách dữ liệu ở cùng chỗ đó.

Thứ tuyệt đối không được đưa vào model tier free

Không phải kiểu “cẩn thận nhé” chung chung. Đây là danh sách:

• Mọi loại credential — API key, token, mật khẩu, connection string, nội dung .env, private key
• Source riêng tư mà bạn không có quyền tiết lộ — code của công ty, code của khách hàng, mọi thứ đang trong NDA
• Dữ liệu khách hàng — bản ghi người dùng thật, thông tin cá nhân, bất cứ thứ gì lấy từ database production
• Tài liệu nội bộ — tài liệu kiến trúc, hợp đồng, roadmap, biên bản sự cố
• Bất cứ thứ gì thuộc diện tuân thủ quy định — dữ liệu y tế, tài chính, hoặc bị quản lý bởi luật chuyên ngành

Nguyên tắc nằm dưới: nếu bạn cần xin phép mới dám email nó cho một người lạ, thì đừng dán nó vào một model mà bạn chưa đọc chính sách lưu trữ.

Có một cái bẫy riêng của agent mà chat không có: agent đọc cả những file bạn không đưa cho nó. Chĩa nó vào thư mục gốc của repo là nó có thể đọc .env, config/secrets.yml, hay một file fixture đầy dữ liệu khách hàng thật — không cái nào bạn cố ý gửi đi. Model chat chỉ thấy thứ bạn dán vào; agent thấy thứ nó tự mở ra.

Nên trước khi chạy bất kỳ agent nào, free hay trả phí, trên một repo bạn không tạo ra riêng cho mục đích đó:

git ls-files | grep -Ei '\.env|secret|credential|\.pem$|\.key$|token'

Cái gì hiện ra thì phải nằm trong .gitignore, nằm trong file ignore mà agent tôn trọng, hoặc bị dời hẳn ra khỏi cây thư mục.

Bậc thang nâng cấp

Mô hình tư duy hữu ích không phải là free-hay-trả-phí. Mà là ba bậc, khớp với thứ mà task thật sự cần:

Phần lớn mọi người làm ngược ở cả hai đầu. Họ chạy model frontier cho code boilerplate, và chạy model free cho con bug hiểm đã ăn mất hai ngày. Cả hai đều lãng phí — một bên phí token, một bên phí thời gian của chính bạn.

Dấu hiệu cần nâng bậc: nếu bạn đã prompt lại ba lần mà câu trả lời vẫn sai theo đúng một kiểu, thì model không phải nút thắt như bạn nghĩ. Hoặc nâng một bậc, hoặc — thường gặp hơn — prompt của bạn đang thiếu bối cảnh mà model không thể tự suy ra. Thử bổ sung bối cảnh trước; cái đó miễn phí.

Cách moi được việc thật sự hữu ích từ tier free

Model free nhỏ hơn và kém kiên nhẫn hơn. Hãy điều chỉnh công việc cho vừa, thay vì kỳ vọng nó hành xử như model frontier.

Giao việc nhỏ hơn. “Refactor module auth” là task của model frontier. “Trong auth/session.py, tách logic refresh token ra thành hàm riêng và cập nhật hai chỗ đang gọi” là task của model free. Phạm vi nhỏ cũng đốt ít request hơn, chuyện này rất đáng khi bạn chỉ có một trăm.

Chỉ đích danh file. Để agent tự mò xem file nào quan trọng vừa tốn request vừa hay sai với model nhỏ. Nêu thẳng ba file nó cần thì tiết kiệm cả hai.

Gom việc cơ học lại làm một lượt. Đổi tên, thêm type hint, chuyển bộ test từ kiểu assertion này sang kiểu khác, viết docstring từ signature có sẵn — đây đúng là thứ model free làm tốt, và kết quả thì kiểm tra rất rẻ.

Dùng nó để đọc codebase. Một trong những cách dùng tier free hay nhất là nhờ một model nhanh giải thích một repo lạ. “Trace xem chuyện gì xảy ra khi một request tới /api/orders” là việc rủi ro thấp, giá trị cao, và không cần khả năng suy luận của frontier.

Dùng tier fast cho việc nhanh. Tier fast context nhỏ thật sự tốt hơn tier context lớn cho việc tra cứu nhanh và sửa một file — độ trễ thấp hơn, và context bạn không dùng tới là context có thể gây nhiễu.

Lựa chọn miễn phí còn lại

Đáng biết: Hermes Agent cũng miễn phí và hoạt động qua nền tảng nhắn tin — bạn điều khiển agent từ Telegram hoặc Discord thay vì từ terminal. Trải nghiệm hoàn toàn khác. Nếu điều hấp dẫn bạn là bấm điện thoại giao việc rồi lát nữa đọc kết quả, thì cái này hợp hơn một công cụ CLI. Mọi lưu ý về dữ liệu vẫn giữ nguyên, cộng thêm một điểm: nền tảng chat còn giữ bản sao của mọi thứ bạn gửi.

Setup khởi đầu không khiến bạn trả giá

1. Cài OpenCode. Setup đúng là chỉ vài phút.
2. Bắt đầu trên repo của chính bạn và không chứa gì bảo mật. Không phải cái monorepo của công ty. Một dự án cá nhân.
3. Xem dàn model free hiện tại và chính sách dữ liệu tại opencode.ai/zen trước task thật đầu tiên, không phải sau.
4. Chạy lệnh quét secret ở trên trên bất kỳ repo nào trước khi chĩa agent vào.
5. Làm ba task thật — một lần sửa bug, một lần refactor nhỏ, một buổi nhờ giải thích code. Bấy nhiêu là đủ để biết công cụ có hợp với cách bạn làm việc không.
6. Khi thấy mình bắt đầu phụ thuộc vào nó, chuyển sang model trả phí tầm trung. Ngay khi output của agent đi vào công việc có người trả tiền, thì cả rate limit lẫn chính sách lưu trữ đều không còn chấp nhận được.

Bước 6 là bước mọi người hay hoãn, thường là hoãn tới lúc dính rate limit giữa sprint. Hãy chuyển trước lúc đó, đừng đợi sau.

Tóm lại cho thẳng thắn

Tier free là cách rất tốt để học và là cách rất tệ để ship hàng. Đó không phải lời chê — tier free sinh ra để làm đúng việc đó, và OpenCode còn khá sòng phẳng khi nói ra sự đánh đổi.

Học trên free. Làm việc trên trả phí. Chỉ nâng lên frontier khi task thật sự khó. Và đọc chính sách lưu trữ trước prompt đầu tiên, chứ không phải sau khi đã dán vào thứ không rút lại được.

Câu hỏi thường gặp

OpenCode miễn phí bản thân công cụ hay chỉ miễn phí model? Công cụ là mã nguồn mở và không đo đếm. Tier free của Zen là phần model hosted, có giới hạn request mỗi ngày. Bạn cũng có thể cắm API key riêng từ bất kỳ nhà cung cấp nào.

Thật sự được bao nhiêu request? Tier free được ghi ở mức khoảng 100 request mỗi ngày. Vòng lặp agent tiêu vài request cho mỗi task, nên hãy tính là vài task đáng kể mỗi ngày chứ không phải dùng liên tục.

Code của tôi có bị dùng để train không? Ở tier free thì nhìn chung là có — prompt và output được lưu lại và dùng để cải thiện model. Có ít nhất một model trong dàn được ghi rõ là không nằm trong diện này. Hãy kiểm chứng lại với tài liệu hiện hành, vì điều khoản có thay đổi.

Dùng cho việc của khách hàng được không? Không, nếu đó là tier free có chính sách giữ dữ liệu để train, trừ khi khách hàng đã đồng ý rõ ràng bằng văn bản. Hãy dùng tier trả phí có cam kết xử lý dữ liệu trong hợp đồng.

Nên bắt đầu với model free nào? Bắt đầu ở tier mặc định cho việc code nói chung, chuyển sang tier nâng cao khi task cần nhiều context hoặc nhiều suy luận hơn, và dùng tier fast cho việc nhanh trên một file. Tên model cụ thể thay đổi liên tục — hãy xem danh sách hiện tại thay vì tin bất kỳ bài blog nào, kể cả bài này.

Model miễn phí có đủ tốt để học agentic coding không? Có, và đó là lập luận mạnh nhất ủng hộ nó. Kỹ năng chia nhỏ task, cung cấp bối cảnh và kiểm chứng output chuyển sang model trả phí gần như nguyên vẹn. Kỹ năng mới là phần bền, không phải model.

Bài này khai triển từ một ghi chú đang lan truyền trong cộng đồng lập trình viên Việt Nam về các model miễn phí của OpenCode, mà những cảnh báo cốt lõi trong đó — free không phải unlimited, dữ liệu của bạn dùng để train model kế tiếp, tuyệt đối đừng dán secret — đều là những cảnh báo đúng. Tên model và quota trong bài phản ánh thời điểm viết và thay đổi thường xuyên; các link dẫn tới nguồn chuẩn hiện hành.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.

Bảo model tạo ảnh vẽ “một cái poster”, bạn sẽ nhận về một tấm ảnh có hình dạng poster: hình ở trên, chữ ở dưới, hai bên tranh nhau sự chú ý, chẳng có gì gắn chúng lại với nhau. Nó nhìn ra ngay là do AI sinh vì bố cục chung chung, chứ không phải vì chất lượng render kém.

Cách sửa không phải là đổi model xịn hơn. Mà là đưa cho model một hệ bố cục thay vì một chủ đề.

Dưới đây là hai hệ cho ra kết quả nhìn như có art director thật. Cả hai đều kèm template điền chỗ trống. Cả hai đều chạy được trên mọi model tạo ảnh hiện tại có nhận prompt dài — Nano Banana, Midjourney, Seedream, GPT Image, Flux.

Vì sao chỉ dẫn bố cục ăn đứt tính từ mô tả phong cách

Đa số prompt làm poster là một đống tính từ: tối giản, thanh lịch, cao cấp, chuyên nghiệp, đoạt giải. Mấy từ đó đẩy model về phía trung bình cộng của tất cả những gì được gắn nhãn như vậy trong dữ liệu huấn luyện. Mà trung bình chính là thứ bạn đang muốn thoát khỏi.

Chỉ dẫn bố cục thì khác. “Vùng thông tin phía dưới chiếm 25–40% chiều cao” là ràng buộc mà model có thể thỏa hoặc không thỏa, và nó ràng buộc phần bố cục chứ không phải phần bề mặt. Nói bốn điều cụ thể về cấu trúc thì bạn nhận được một cấu trúc cụ thể.

Ba đòn bẩy làm được nhiều việc nhất:

Mọi thứ bên dưới đều dựng trên ba cái đó.

Hệ 1 — Bố cục split-level

Hợp với: poster triển lãm, bìa sách, đồ họa sự kiện và văn hóa, bất cứ thứ gì cần cảm giác được tuyển chọn kỹ.

Ý tưởng nghe thì hiển nhiên — chia khung thành phần trên và phần dưới — nhưng phiên bản hiệu quả có một điểm xoay rất cụ thể. Nó không phải “hình trên, chữ dưới”. Nó là hai hoặc ba vùng không đều nhau với vai trò khác nhau, rồi được nối lại bằng những thành phần vượt qua ranh giới.

Cái sự vượt ranh giới đó mới là toàn bộ mẹo. Một cành hoa chạy xuyên qua đường chia, một tiêu đề đủ lớn để cưỡi lên nó, bờ vai của nhân vật phá qua vạch. Không có nó thì bạn có hai hình chữ nhật xếp chồng. Có nó thì bạn có chiều sâu.

Công thức chia vùng

┌─────────────────────────┐
│                         │
│   VÙNG HÌNH CHÍNH       │  50–65%
│   một chủ thể duy nhất  │
│                         │
├─────────────────────────┤
│  DẢI CHUYỂN TIẾP        │  8–15%
├─────────────────────────┤
│  VÙNG THÔNG TIN         │
│  tiêu đề / ngày / nơi   │  25–40%
│  tên đơn vị (rất nhỏ)   │
└─────────────────────────┘

Ba điều khiến nó thật sự hiệu quả chứ không chỉ gọn gàng:

Dải chuyển tiếp không phải để trang trí. Nó là một dải hẹp — một khối màu nhạt, một vạch mảnh, một hàng module thông tin nhỏ — có nhiệm vụ làm thứ thứ ba mà không vùng nào sở hữu. Thiếu nó, hai vùng đọc lên như không liên quan gì tới nhau. Nó tương đương một dấu phẩy trong thị giác.

Một tiếng nói chính, vài tiếng thì thầm. Giữ đúng một chủ thể chính. Sau đó rải vài chi tiết nhẹ ký vào khoảng trống: nét vẽ mảnh, phác thảo dở, một mảnh sơ đồ, chữ dựng đứng, mấy ký hiệu chú thích nhỏ. Chúng làm vùng trống có mật độ mà không cạnh tranh. Đây chính là khác biệt giữa “thoáng” và “trống”.

Tiêu đề tham gia vào bố cục. Không phải một dòng chú thích nằm dưới hình — tiêu đề là một thành phần bố cục. Phóng to nó, dựng đứng nó, đặt lệch có chủ ý, hoặc cho nó chạy xuyên qua ranh giới vùng.

Template

Điền vào các ngoặc vuông rồi dán nguyên cả khối:

[Chủ đề]: ___
[Hình chính]: ___
[Tiêu đề chính]: ___
[Tiêu đề phụ / bản dịch]: ___
[Họa tiết bổ trợ]: ___
[Màu chủ đạo]: ___
[Màu nhấn]: ___
[Ngày và địa điểm]: ___
[Tỷ lệ khung]: 9:16

Thiết kế một poster theo ngôn ngữ editorial cao cấp và triển lãm
văn hóa, dựng trên bố cục split-level.

CẤU TRÚC — không tạo bố cục "hình trên, chữ dưới" thông thường.
Chia khung thành ba vùng ngang không đều nhau:
- vùng hình chính chiếm 50-65% chiều cao
- một dải chuyển tiếp hẹp chiếm 8-15%
- vùng thông tin chiếm 25-40%

VÙNG CHÍNH — chỉ một chủ thể duy nhất: [Hình chính]. Thêm hai tới ba
chi tiết phụ nhẹ ký vào khoảng trống (nét mảnh, phác thảo dở, một sơ
đồ nhỏ, chữ dựng đứng) để vùng trống có mật độ mà không lấn át chủ thể.

DẢI CHUYỂN TIẾP — nối hai vùng bằng một khối màu giảm bão hòa, một
vạch mảnh, hoặc một hàng module thông tin nhỏ. Dải này không thuộc
về vùng nào cả.

CHỮ — tiêu đề chính là một thành phần bố cục, không phải chú thích.
Phóng to, dựng đứng, đặt lệch, hoặc cho nó cắt ngang ranh giới vùng.
Đồng thời cho một phần chủ thể chính vượt qua ranh giới, để tách bạch
tiền cảnh và hậu cảnh.

PHÂN CẤP — bốn cỡ chữ khác biệt rõ ràng: tiêu đề chính cỡ lớn, rồi
tiêu đề phụ và ngày tháng, rồi phụ đề nhỏ, rồi thông tin đơn vị rất
nhỏ. Gom nhóm chữ nhỏ thật sát nhau; tuyệt đối không rải rác.

MÀU — tối đa 5 màu. [Màu chủ đạo] dẫn dắt, [Màu nhấn] chỉ xuất hiện
trên dưới 10% diện tích.

TINH THẦN — mỗi vùng có vai trò riêng, và các vùng được nối lại qua
chủ thể chính cùng phần chữ. Giàu chi tiết nhưng không rối, thoáng
nhưng không trống; đạt độ hoàn thiện của một poster bảo tàng thật
hoặc một catalogue nghệ thuật.

Sửa khi ra chưa đúng

• Không có gì vượt ranh giới. Nói thẳng: “chủ thể chính phải chồng lên ranh giới vùng khoảng 10–15% chiều cao của nó.” Model mặc định chia tách gọn gàng.
• Chữ nhỏ rải khắp nơi. Thêm: “toàn bộ chữ dưới tiêu đề phụ phải nằm trong một khối duy nhất, sát nhau.”
• Quá nhiều màu. Hạ trần xuống 3 và gọi tên từng màu.
• Các vùng ra bằng nhau. Nhắc lại các tỷ lệ phần trăm ở cuối prompt — position bias là có thật, và chỉ dẫn cuối cùng thường sống sót.

Hệ 2 — Ảnh chuyển thành đồ họa trừu tượng

Hợp với: biến một tấm ảnh sẵn có thành tác phẩm kiểu phòng trưng bày. Chân dung, kiến trúc, phong cảnh, ảnh sản phẩm.

Cấu trúc khác, triết lý giống. Khung được chia làm hai nửa: một nửa giữ nguyên ảnh thật, nửa còn lại là bản rút gọn trừu tượng của chính chủ thể đó. Đặt cạnh nhau, cặp đôi này đọc lên có chủ đích theo cách mà từng nửa riêng lẻ không có được.

Quy tắc theo hướng ảnh là thứ khiến nó bền:

Đây là ngoại lệ duy nhất cho nguyên tắc “tránh 50/50”, và nó xứng đáng: hai nửa không cạnh tranh nhau, chúng là cùng một chủ thể ở hai thanh âm khác nhau, nên sự cân bằng đọc lên như một phép so sánh có chủ ý.

Có một skill mã nguồn mở triển khai cách này tại ZzzLc0405/photo-abstract-editorial nếu bạn muốn dùng như một công cụ tái sử dụng thay vì dán prompt mỗi lần.

Nhiệm vụ của từng nửa

Nửa ảnh — giữ nguyên, đừng diễn giải lại. Đây là chỗ đa số thất bại. Model rất muốn stylize, mà ngay khi nó làm vậy thì cặp đôi sụp đổ. Hãy nói thẳng: giữ nguyên hình dáng, tỷ lệ, chất liệu thật, ánh sáng và bóng đổ tự nhiên, màu gốc của chủ thể. Chỉ chỉnh màu — nhẹ nhàng theo kiểu nhiếp ảnh nghệ thuật đương đại, không hơn. Nếu cần mở rộng khung cho vừa, chỉ mở rộng bầu trời, mặt đất hoặc môi trường xung quanh, tuyệt đối không đụng vào chủ thể.

Nửa đồ họa — rút về đường bao. Lấy đường viền dễ nhận ra nhất của chủ thể rồi dựng lại bằng hình học sạch, mảng màu phẳng, nét mảnh và khoảng trống rộng rãi. Không minh họa tả thực, không chi tiết vụn. Đích đến là trừu tượng nhưng nhận ra ngay lập tức.

Lấy bảng màu từ chính tấm ảnh. Đây là chỉ dẫn buộc hai nửa lại với nhau, và cũng là cái mọi người hay quên. Màu được lấy mẫu từ ảnh gốc mới là thứ khiến hai nửa nhìn như một tấm poster chứ không phải hai file ghép lại.

Template

Tạo một poster editorial tối giản cao cấp từ tấm ảnh được tải lên.
Khung dọc tỷ lệ 3:4.

CÁCH CHIA — nếu ảnh gốc nằm ngang, chia khung theo chiều ngang thành
hai nửa xấp xỉ bằng nhau (ảnh ở trên, đồ họa ở dưới). Nếu ảnh gốc
dựng đứng, chia theo chiều dọc thành hai nửa xấp xỉ bằng nhau (ảnh
một bên, đồ họa bên còn lại).

NỬA ẢNH — giữ nguyên ảnh gốc một cách trung thực: hình dáng, tỷ lệ,
chất liệu thật, ánh sáng và bóng đổ tự nhiên, cùng màu sắc gốc của
chủ thể. Chỉ áp dụng chỉnh màu chuyên nghiệp ở mức tiết chế, theo
đúng thanh âm của nhiếp ảnh nghệ thuật đương đại. Nếu buộc phải mở
rộng khung, chỉ mở rộng bầu trời, mặt đất hoặc môi trường xung quanh.
Không bóp méo, không đổi phong cách, không thay đổi chủ thể.

NỬA ĐỒ HỌA — diễn giải lại đường bao và cấu trúc dễ nhận ra nhất của
chủ thể thành một bố cục trừu tượng đơn giản: hình học sạch, mảng màu
phẳng, nét mảnh, khoảng trống rộng rãi. Không minh họa tả thực, không
chi tiết rườm rà. Kết quả phải trừu tượng nhưng vẫn nhận ra ngay đó
là cùng một chủ thể. Lấy toàn bộ bảng màu từ các màu có trong ảnh gốc.

NỀN — nền trung tính sáng (màu xương, ngà, xám ấm), lề rộng rãi và
bố cục cân bằng quanh trục giữa.

CHỮ — tối thiểu hoặc không có. Nhiều nhất là một tiêu đề ngắn và một
năm, đặt cỡ nhỏ.

ĐỊNH HƯỚNG — thiết kế editorial tối giản cao cấp, poster triển lãm
nghệ thuật đương đại, ngôn ngữ đồ họa kiến trúc, sang trọng tiết chế,
art direction chuẩn bảo tàng, khoảng trống rộng rãi.

TRÁNH — bố cục kiểu template, thiết kế thương mại rẻ tiền, phong cách
hoạt hình, render 3D, trang trí rườm rà, gradient, hiệu ứng neon,
minh họa rối rắm, và mọi hình thức bóp méo chủ thể trong ảnh.

Sửa khi ra chưa đúng

• Chọn ảnh có đường bao rõ ràng. Muốn rút gọn thì phải có thứ để rút gọn. Cảnh rối rắm không có hình khối chủ đạo sẽ ra một mớ nhòe.
• Nửa trừu tượng nhìn như đồ lại vụng về. Đẩy mạnh phần rút gọn: “không quá 5 hình khối riêng biệt.”
• Nửa ảnh bị stylize mất. Dời mệnh đề giữ nguyên xuống cuối prompt và thêm: “phần ảnh phải giữ nguyên chất nhiếp ảnh.”
• Hai nửa nhìn không liên quan. Nhắc lại chỉ dẫn về bảng màu, và gọi tên hai ba màu bạn nhìn thấy trong ảnh gốc.

Phần chuyển được sang mọi prompt poster khác

Bóc cả hai hệ ra thì bên dưới vẫn là bốn nước đi giống nhau:

Nêu cấu trúc trước phong cách. Phần trăm, số vùng, số lượng — những thứ này ràng buộc model theo cách tính từ không làm được. “25–40% chiều cao” là kiểm được; “cân đối” thì không.

Đặt trần cho bảng màu. Nếu chỉ đổi được một điều trong cách viết prompt tạo ảnh, hãy đổi cái này. Ba tới năm màu, nêu ra bằng một con số, là chỉ dẫn có đòn bẩy cao nhất trong cả prompt.

Gọi tên phân cấp một cách rõ ràng. Model mặc định làm phẳng phân cấp, vì dữ liệu huấn luyện lấy trung bình thì phẳng. Liệt kê bốn cỡ chữ khác biệt sẽ ép nó tách bạch ra.

Cho các thành phần vượt khỏi khung của chúng. Chiều sâu trong bố cục đến từ những thứ không chịu nằm yên trong ô của mình. Đây là chỉ dẫn hay bị thiếu nhất trong những prompt cho ra kết quả phẳng lì.

Câu hỏi thường gặp

Dùng được với model tạo ảnh nào? Bất kỳ model nào nhận prompt dài có cấu trúc — Nano Banana, Midjourney, Seedream, GPT Image, Flux. Model render chữ tốt sẽ xử lý phần phân cấp typography khá hơn; với model yếu chữ thì cứ tạo bố cục rồi tự đặt chữ vào sau.

Dùng thương mại được không? Bản thân hệ bố cục là quy ước thiết kế, không phải tài sản của ai — split-level có từ trước AI hàng chục năm. Hãy kiểm tra điều khoản thương mại của chính model bạn dùng, và kiểm tra giấy phép của bất kỳ đoạn code hay skill nào bạn sử dụng.

Làm sao để chữ trong poster đọc được? Viết ngắn, ghi rõ chuỗi chữ trong dấu ngoặc kép, và chuẩn bị tinh thần phải sửa. Với những thứ đưa cho khách hàng, hãy tạo bố cục bằng AI rồi dựng chữ thật bằng công cụ thiết kế đè lên trên.

Bìa sách thì dùng hệ nào? Split-level. Vùng thông tin ánh xạ rất tự nhiên sang tên sách, tác giả và nhà xuất bản.

Sao ở hệ 2 lại đảo ngược nguyên tắc 50/50? Vì hai nửa không tranh nhau sự chú ý — chúng là cùng một chủ thể được trình bày hai lần. Sự cân bằng ở đây đọc lên như một phép so sánh, chứ không phải sự do dự.

Khung split-level trong bài được phóng tác từ một phân tích bố cục ghi nguồn Larus Canus, còn cách ảnh-chuyển-trừu-tượng từ một bài ghi nguồn VibeEverything, cả hai đang lan truyền trong cộng đồng thiết kế AI Việt Nam. Các template prompt phía trên được mình viết lại bằng ngôn từ của mình kèm phần giải thích lý do; skill mã nguồn mở triển khai hệ thứ hai đã được dẫn link ở phần nguồn.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.

Sau nửa năm, setup AI của phần lớn mọi người trông giống hệt nhau: mười một con trợ lý tự tạo nhớ mang máng, một nghĩa địa tab trình duyệt, và cảm giác lấn cấn rằng cái mình mò ra hồi tháng Ba đang nằm đâu đó trong một cuộc chat không bao giờ tìm lại được.

Tạo agent là phần dễ. Nền tảng nào — Grok Bot, custom GPT, Claude Projects — cũng làm được trong hai phút. Thứ phân biệt một setup hữu ích với một mớ bừa bộn không phải là số lượng agent. Mà là chúng có dùng chung bối cảnh không, có báo cáo công việc không, và có chạy được khi bạn không ngồi đó không.

Chín thói quen dưới đây đưa bạn tới đó. Mình viết theo hướng không phụ thuộc nền tảng, vì mô hình này sống lâu hơn công cụ bạn đang xài năm nay.

Phần 1 — Dạy hệ thống hiểu bạn là ai

1. Phỏng vấn chính mình trước

Một đội ngũ agent chỉ tốt bằng mức nó hiểu tình hình của bạn. Mà phần lớn mọi người không bao giờ viết cái đó ra, vì nó chán và vì mình đã biết rồi.

Vậy thì để AI moi nó ra. Tạo một skill hoặc prompt lưu sẵn với nhiệm vụ duy nhất là chất vấn bạn — mỗi lần một câu, không gợi ý đáp án, cho tới khi nó tóm tắt lại chính xác công việc, mục tiêu và ràng buộc của bạn.

Bạn đang phỏng vấn tôi để dựng một tài liệu bối cảnh về công việc của tôi.

Quy tắc:
- Hỏi MỖI LẦN MỘT CÂU và chờ tôi trả lời.
- Không bao giờ gợi ý đáp án hay đưa lựa chọn sẵn.
- Câu trả lời nào mơ hồ thì hỏi tiếp, đừng bỏ qua.
- Cần bao phủ: hằng ngày tôi thật sự làm gì, tôi bị đánh giá dựa
  trên cái gì, ai phụ thuộc vào tôi, hiện đang tắc ở đâu, tôi đang
  né việc gì, và trong 90 ngày tới tôi muốn điều gì thành hiện thực.
- Dừng lại khi bạn tóm tắt được tình hình của tôi trong 10 gạch đầu
  dòng mà tôi sẽ gật đầu. Đưa 10 gạch đó ra và hỏi tôi sai chỗ nào.

Quy tắc cuối quan trọng hơn tất cả những cái còn lại. “Đưa bản tóm tắt ra và hỏi sai chỗ nào” là thứ biến một buổi phỏng vấn thành một vòng lặp sửa sai.

Chạy cái này trước khi lập kế hoạch quý, trước khi bắt đầu dự án, trước khi xây bất kỳ automation nào. Lưu kết quả lại. Nó trở thành bối cảnh chung mà mọi agent khác đều đọc.

Vì sao nó hiệu quả: bạn không phải viết tài liệu — thứ mà bạn sẽ chẳng bao giờ viết xong. Bạn chỉ trả lời câu hỏi, việc đó dễ hơn nhiều, còn phần viết thì thứ khác lo.

2. Chỉ một cửa ngõ duy nhất

Bạn có thể có agent cho content, research, lập kế hoạch và việc hành chính. Cái bạn không muốn là mỗi lần dùng lại phải nhớ con nào lo việc gì.

Chọn một agent làm cửa ngõ. Đặt tên cho nó — nói chuyện với Klaus thật sự dễ chịu hơn nói chuyện với Trợ lý 4. Mọi thứ đi qua nó.

Quy tắc vận hành của nó ngắn thôi:

Bạn là chief of staff của tôi. Bạn là agent duy nhất tôi nói chuyện
trực tiếp.

Trước khi tự làm bất kỳ việc gì:
1. Kiểm tra xem có agent chuyên trách nào phụ trách việc đó không.
   Danh sách hiện có:
   - Motion — hình ảnh, video, animation
   - Eyes — research và kiểm chứng thông tin
   - Miner — nghiên cứu nội dung, tìm nguồn, quét đối thủ
   - Coffee — lập kế hoạch buổi sáng và ưu tiên trong ngày
   - Views — chiến lược nội dung và phân phối
2. Nếu có agent phù hợp thì giao việc cho nó và mang kết quả về đây.
3. Chỉ tự làm khi không agent nào phù hợp.
4. Nếu đã giao việc, nói rõ bạn dùng agent nào và vì sao.

Đừng bao giờ bắt tôi phải mở thêm một cuộc trò chuyện khác.

Dòng cuối chính là toàn bộ vấn đề. Chi phí của một setup nhiều agent không nằm ở token, mà ở gánh nặng phải tự điều phối trong đầu. Hãy đẩy phần điều phối đó vào hệ thống.

Mỗi agent chuyên trách cần một mô tả thật sắc. “Trợ lý chung” thì vô dụng với một bộ điều phối. “Lo sinh ảnh, prompt dựng video và brief motion graphics” thì điều phối được. Chief of staff đọc chính những mô tả này để quyết định — mô tả mơ hồ thì điều phối sai.

3. Để cửa ngõ tự thiết kế phần còn lại của đội

Sau khi làm xong buổi phỏng vấn ở thói quen #1, bạn không cần đoán mò xem nên tạo agent gì tiếp theo nữa. Cứ hỏi:

Đây là tài liệu bối cảnh và danh sách agent hiện có của tôi.

Với các mục tiêu trong tài liệu bối cảnh, đang thiếu những vai trò nào?
Quy tắc:
- Không đề xuất thêm một chief of staff thứ hai hay một trợ lý chung.
- Không đề xuất vai trò trùng lặp với agent đã có — thay vào đó hãy
  chỉ ra agent hiện tại nào đã lo phần đó rồi.
- Với mỗi đề xuất: nêu đúng vấn đề lặp đi lặp lại mà nó giải quyết,
  nó cần làm được gì, và nó tuyệt đối không được đụng vào gì.
- Xếp hạng theo số giờ tiết kiệm được mỗi tháng. Ghi rõ cách bạn ước lượng.

Hai quy tắc “không” là phần chịu lực. Cứ để tự do, model sẽ đề xuất một con trợ lý chung chung và một con điều phối trùng lặp, vì đó là hai hình dạng phổ biến nhất trong dữ liệu huấn luyện của nó. Cấm hai cái đó đi thì bạn nhận được đề xuất bám theo vấn đề thật của mình.

Khi ưu tiên thay đổi, cứ nói cho chief of staff biết cái gì đã đổi và để nó thiết kế lại đội ngũ. Đội hình nên là thứ có thể vứt đi và dựng lại.

Phần 2 — Kiểm soát ai được biết gì

4. Tách bộ nhớ chung khỏi bộ nhớ riêng

Phần lớn nền tảng giờ đều có bộ nhớ lâu dài. Sai lầm là quăng tất cả vào chung một đống.

Hai tầng:

Phép thử rất đơn giản: agent khác có ra quyết định tệ hơn nếu không biết điều này không? Có thì là bộ nhớ chung. Chỉ ảnh hưởng tới công việc của một agent thì để riêng.

Chuyện này càng quan trọng khi đội càng đông. Nhiều agent có thể cùng dùng lịch của bạn — nhưng bối cảnh về lý do sáng thứ Ba là khung giờ bất khả xâm phạm thì phải nằm ở bộ nhớ chung, không thì con nào cũng đặt lịch đè lên.

Khi bảo agent ghi nhớ điều gì, hãy nói rõ:

Lưu vào bộ nhớ chung: team ship hàng vào thứ Năm, không bao giờ thứ Sáu.
Lưu vào bộ nhớ riêng của bạn: tôi thích bản nháp 400 chữ, không phải 800.

Thêm một thói quen: phần lớn công cụ cho phép tách một tin nhắn quan trọng thành thread riêng. Hãy dùng nó. Đào sâu một nhánh ý tưởng trong thread phụ, giữ cuộc trò chuyện chính sạch sẽ. Thread chính là xương sống của hệ thống — đừng làm nó rối bằng những lần thăm dò.

Phần 3 — Nối công cụ, ghi lại công việc

5. Bắc cầu tới những app nền tảng của bạn không hỗ trợ

Nền tảng AI nào cũng có sẵn plugin. Không nền tảng nào có đủ hết. Khi bạn cần YouTube, Reddit, LinkedIn, một CRM hay một API tìm kiếm không được hỗ trợ sẵn, một nền tảng tích hợp như Composio đứng ở giữa — hàng trăm tích hợp nằm sau một kết nối duy nhất mà agent của bạn gọi được.

Rồi ghi cái cầu đó vào bộ nhớ chung, để mọi agent đều biết năng lực này tồn tại:

Lưu vào bộ nhớ chung: YouTube, LinkedIn, Reddit và Perplexity đều
truy cập được qua Composio. Hãy kiểm tra Composio trước khi nói với
tôi rằng việc gì đó không làm được.

Không có dòng đó, agent sẽ liên tục báo với bạn rằng nó không làm được những việc nó làm được. Năng lực không được ghi ra thì coi như không tồn tại.

Lưu ý bảo mật, và cái này không phải tùy chọn: một cầu nối tích hợp đang giữ credential sống của các tài khoản của bạn. Cấp scope hẹp nhất mà vẫn chạy được, xem lại từng kết nối thật sự làm được gì, và tuyệt đối đừng cho một agent chạy tự động không giám sát quyền ghi vào thứ mà bạn sẽ đau tim nếu nó ghi đè sai. Sự tiện lợi là thật, nhưng bán kính thiệt hại cũng thật.

6. Ghi log công việc của agent ra ngoài cuộc chat

Ngay khi bạn bắt đầu giao việc từ cả điện thoại lẫn laptop, mọi thứ tuột khỏi tầm kiểm soát. Công việc biến mất vào những cuộc hội thoại chẳng ai mở lại.

Cách xử lý là biến việc ghi log thành một phần của task, không phải chuyện làm cho có sau đó. Một skill kiểu “ghi việc này vào tracker” chạy trước khi bắt đầu làm:

Khi tôi giao một task research hoặc task nhiều bước:
1. Tạo project trong tracker TRƯỚC, trước khi làm bất cứ điều gì.
2. Thêm một task cho mỗi việc con, kèm: agent phụ trách, thời gian
   bắt đầu, đang chờ điều gì, và một trường link cho kết quả.
3. Giao việc.
4. Cập nhật task với ghi chú tiến độ và link kết quả khi xong.
5. Đưa tôi link project trong phần trả lời.

Bạn yêu cầu so sánh 5 nhà cung cấp voice agent, thì tracker có project trước khi bất kỳ phần research nào diễn ra. Về sau bạn thấy được cái gì đã chạy, cái gì đã xong, ai làm, kết quả nằm ở đâu — mà không phải đào bới lịch sử chat.

Giá trị không nằm ở việc diễn trò quản lý dự án. Nó nằm ở chỗ công việc không còn bốc hơi.

Phần 4 — Dạy một lần, rồi tự động hóa

7. Làm mẫu cho những workflow không diễn tả được bằng lời

Có những quy trình thiên về thị giác và thật sự khổ sở khi phải viết ra. Bấm chỗ nào, trong bốn cái nút giống nhau thì chọn cái nào, layout xê dịch thì xử lý sao.

Nếu nền tảng của bạn cho agent một máy tính đám mây dùng chung kèm chế độ ghi hình “teach a task”, hãy dùng nó đúng cho những việc này. Bấm ghi, làm quy trình ở tốc độ bình thường, bấm dừng. Agent phân tích thao tác vừa rồi và biến nó thành một skill tái sử dụng được.

Việc phù hợp: tìm ảnh và lưu theo một quy ước đặt tên cụ thể; thao tác với giao diện không có API; bất kỳ việc gì mà bước kế tiếp phụ thuộc vào cái đang hiển thị trên màn hình.

Việc không phù hợp: bất cứ thứ gì đã có API sạch sẽ. Ghi lại thao tác click đè lên một API được hỗ trợ vừa chậm hơn vừa dễ vỡ hơn nhiều. Làm mẫu là để lấp chỗ trống.

8. Routine mới là thứ khiến hệ thống chạy không cần bạn

App chat dành cho lúc bạn đang suy nghĩ. Routine dành cho lúc bạn không.

Routine là một công việc lặp lại mà agent chạy theo lịch hoặc theo trigger. Đặt tên, viết yêu cầu, và chỉ định skill hay agent cần gọi.

Hai loại trigger, giải quyết hai vấn đề khác nhau:

• Theo lịch — mỗi giờ, mỗi ngày, hoặc khoảng thời gian tùy chỉnh. Hợp với bản tin tổng hợp, rà soát định kỳ, báo cáo lặp lại.
• Theo sự kiện — tin nhắn Slack, hoạt động Git, tin nhắn Teams và tương tự. Hợp với việc phản ứng lại những thứ bạn không kiểm soát được thời điểm.

Vì routine chạy trên cloud nên nó vẫn tiếp tục khi laptop đã tắt và điện thoại đang nằm trong ngăn kéo. Đó là khác biệt giữa một trợ lý và một hệ thống.

Hãy bắt đầu từ những cái nhàm chán nhất. Một bản brief 7 giờ sáng mỗi ngày, đọc lịch và hộp thư rồi nói cho bạn ba việc thật sự quan trọng, có giá trị hơn bất kỳ automation thông minh nào bạn sẽ xây sau này rồi chẳng bao giờ tin tưởng.

Đặt rào chắn cho mọi thứ chạy không giám sát: agent chạy tự động nên mặc định chỉ tạo bản nháp và thông báo, không gửi, không đăng, không xóa. Chỉ chuyển một routine sang chế độ hoàn toàn tự động sau khi bạn đã theo dõi output của nó vài tuần và lần nào nó cũng đúng.

9. Lưu profile trình duyệt đã đăng nhập

Máy tính của agent trở nên hữu ích hơn hẳn khi nó dùng lại được một profile trình duyệt đã đăng nhập sẵn.

Đăng nhập agent vào dịch vụ một lần, trong profile đã lưu của nó. Dạy nó thao tác. Gắn thao tác đó vào một routine. Phiên đăng nhập được giữ lại — nên bạn không phải dán mật khẩu vào cuộc trò chuyện mỗi lần chạy.

Đó mới là lập luận bảo mật thật sự của tính năng này, và nên nói thẳng ra: credential nằm trong profile đã lưu tốt hơn credential nằm trong lịch sử chat. Lịch sử chat bị tóm tắt, bị export, rồi bị nạp ngược vào các bối cảnh khác. Một phiên trình duyệt được lưu thì không.

Hai quy tắc nếu bạn làm cách này:

1. Dùng tài khoản riêng cho việc của agent ở những dịch vụ cho phép — đừng dùng tài khoản chính.
2. Không bao giờ dán mật khẩu, API key hay mã 2FA vào cuộc trò chuyện, kể cả “chỉ lần này để setup thôi”. Hãy đăng nhập thủ công ngay trong profile đó.

Ráp lại thành một hệ thống

Một cuối tuần là đủ, theo thứ tự này:

1. Chạy buổi tự phỏng vấn. Lưu kết quả làm tài liệu bối cảnh.
2. Tạo chief of staff. Dán quy tắc điều phối vào. Đưa nó tài liệu bối cảnh.
3. Hỏi nó đang thiếu agent nào. Xây hai con đầu bảng. Không phải tám.
4. Tách bộ nhớ. Dữ kiện chung ở tầng trên, ghi chú từng agent ở tầng dưới.
5. Nối một cây cầu cho công cụ mà bạn cứ ước gì nó chạy được, rồi ghi vào bộ nhớ chung.
6. Thêm phần ghi log vào chỉ dẫn của chief of staff.
7. Dựng một routine — bản brief buổi sáng là lựa chọn đầu tiên kinh điển.
8. Sau đó mới tính tới chuyện dạy bằng làm mẫu và lưu profile.

Bước 1–3 mang lại phần lớn giá trị. Phần còn lại là lãi kép.

Điều gì thật sự khiến nó chạy được

Setup tốt nhất không phải setup nhiều agent nhất. Mà là setup trong đó mỗi agent biết rõ vai trò của mình, có đủ bối cảnh cần thiết, báo cáo lại việc đã làm, và biến được một quy trình bạn từng làm tốt thành thứ dùng lại được.

Ba kiểu hỏng cần canh chừng:

Quá nhiều agent. Mỗi agent là một quyết định điều phối. Năm con sắc nét hơn mười lăm con mờ nhạt — và một danh sách mờ nhạt còn làm hỏng khả năng điều phối của chief of staff, vì nó chọn dựa trên chính mấy dòng mô tả đó.

Bộ nhớ không bao giờ được dọn. Bộ nhớ chung đã lỗi thời còn tệ hơn không có bộ nhớ chung, vì agent hành động theo nó một cách rất tự tin. Rà lại mỗi tháng và xóa những gì không còn đúng.

Routine không ai đọc. Một automation tạo ra output mà bạn lướt qua là chi phí thuần túy. Nếu bạn đã bỏ qua output của một routine hai lần liên tiếp, hoặc sửa nó, hoặc xóa nó.

Câu hỏi thường gặp

Có cần nền tảng cụ thể nào không? Không. Mô hình này chạy trên mọi hệ thống có trợ lý tùy chỉnh lưu được và có bộ nhớ — Grok Bot, custom GPT, Claude Projects. Chỉ thói quen 7 và 8 cần tính năng riêng của nền tảng (máy tính cho agent, routine theo lịch).

Nên bắt đầu với bao nhiêu agent? Hai: chief of staff, và một con chuyên trách cho việc lặp lại nhiều nhất của bạn. Chỉ thêm khi bạn thấy rõ agent hiện có cho ra kết quả tệ hơn hẳn so với một con chuyên trách.

Cái gì vào bộ nhớ chung, cái gì để riêng? Chung nếu agent khác sẽ ra quyết định tệ hơn khi không biết. Riêng nếu nó chỉ ảnh hưởng tới công việc của chính agent đó.

Để agent chạy không giám sát có an toàn không? Có, nếu kỷ luật về scope. Mặc định cho routine chạy tự động quyền đọc và chỉ xuất bản nháp. Mọi thứ gửi đi, đăng lên, tiêu tiền hay xóa dữ liệu đều nên cần bạn duyệt, cho tới khi bạn đã theo dõi nó chạy đúng trong nhiều tuần.

Thói quen nào giá trị nhất trong danh sách này? Buổi tự phỏng vấn. Mọi thói quen còn lại đều tốt lên khi hệ thống thật sự hiểu tình hình của bạn, và đều xuống cấp khi nó không hiểu.

Bài này khai triển từ một bộ chín mẹo đang được chia sẻ trong cộng đồng AI Việt Nam, vốn được viết ra sau một tuần dùng Grok Bot hằng ngày. Phần prompt và cách đóng khung trong bài là của mình; còn các thói quen nền tảng thì đáng học bất kể bạn đang dùng nền tảng nào.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.

Gần đây có một bài tóm tắt “khoa học đằng sau prompt engineering” được chia sẻ rất nhiều, dựa trên năm kết quả nghiên cứu. Danh sách ý tưởng thì hay. Nhưng mấy con số đi kèm lại thuộc kiểu được copy từ bài này sang bài khác mà không ai mở paper gốc ra coi. Nên mình mở ra coi.

Hai trong năm tuyên bố là đúng. Ba cái còn lại thì không — ít nhất là không đúng theo cách đang được lan truyền. Có một trường hợp nghiên cứu thật còn cho kết quả ngược lại với lời khuyên.

Không phải vì vậy mà vứt cả danh sách đi. Phần lời khuyên nền tảng phần lớn vẫn hợp lý. Nhưng nếu bạn định thay đổi cách làm việc dựa trên một nghiên cứu, thì nên biết đó là nghiên cứu nào và nó thật sự đo cái gì.

Dưới đây là từng tuyên bố, phần nào mình kiểm chứng được, và mình sẽ làm gì với nó.

Tóm tắt nhanh

1. Đừng hỏi “…đúng không?” — cái này đúng

Tuyên bố: một nghiên cứu của Cornell Tech thử 45 model, chỉ đổi vài từ trong câu hỏi, và thấy rằng cách hỏi kiểu “X là lựa chọn tốt hơn, đúng không?” kéo câu trả lời về phía X.

Kết luận: đúng. Paper là Tag Questions and the Generational Reversal of Sycophancy Across 45 Language Models. “Tag question” chính là cái đuôi …, đúng không? hay …, phải không?. Nghiên cứu giữ nguyên nội dung câu hỏi, chỉ đổi phần đuôi, chạy trên 45 model và đo mức độ đồng ý dịch chuyển bao nhiêu.

Chi tiết thú vị mà bản tóm tắt phổ biến bỏ mất: hiệu ứng này không đồng đều giữa các thế hệ model. Model mới không đơn giản là “ngoan hơn” — ở một số chỗ xu hướng còn đảo ngược. Nên “model mới ít nịnh hơn” cũng không phải giả định an toàn.

Nên làm gì. Bóc câu trả lời ra khỏi câu hỏi. Khác biệt không hề nhỏ:

❌ Thuê nhà là lựa chọn khôn ngoan hơn với tình hình của tôi, đúng không?
✅ So sánh mua và thuê nhà cho tình huống của tôi: 32 tuổi, thu nhập
   freelance trung bình 25 triệu/tháng nhưng dao động 30%, đã tiết kiệm
   được 1,5 tỷ, dự định ở lại thành phố này ít nhất 3 năm nữa.
   Nêu rõ giả định nào ảnh hưởng nhiều nhất tới kết luận.

Bản thứ hai dài hơn nhưng ít chỉ thị hơn. Đó mới là điểm chính — bạn đưa dữ kiện để nó suy luận, chứ không đưa kết luận để nó gật đầu.

Chuyện này đúng xa hơn phạm vi lời khuyên đời sống. Cách tổ chức API này ổn đúng không? là mời model đồng ý. Phản biện cách tổ chức API này so với các phương án khác mà bạn sẽ cân nhắc là mời model làm việc.

2. “Think step by step” so với role ngắn — tuyên bố này không đứng vững

Tuyên bố: IBM chạy hơn 430.000 lượt đánh giá trên 8 kiểu prompt, thấy “think step by step” thua cách hỏi thường, và kiểu thắng là câu hỏi cộng một vai trò ngắn như “với góc nhìn của một kỹ sư độ tin cậy.”

Kết luận: mình không tìm được nghiên cứu này. Tìm theo mọi hướng đều không ra thứ gì khớp với mô tả hay con số đó. Nếu nó tồn tại thì không nằm ở chỗ các bài tóm tắt nói.

Quan trọng hơn, nghiên cứu được ghi nhận rõ ràng nhất gần với chủ đề này lại cho kết quả ngược lại ở phần persona. When “A Helpful Assistant” Is Not Really Helpful (Findings of EMNLP 2024) thử persona trong system prompt một cách có hệ thống, qua nhiều vai trò và nhiều bộ câu hỏi kiến thức, và thấy persona không cải thiện độ chính xác một cách đáng tin cậy — ở khá nhiều trường hợp, điểm khi có persona còn thấp hơn baseline không persona. Các nghiên cứu sau đó lặp lại cùng một hình dạng kết quả: nói với model rằng nó là chuyên gia không làm nó trả lời đúng hơn ở những câu có đáp án kiểm chứng được.

Vậy nên lời khuyên đang lan truyền — “bỏ step-by-step, thêm role vào” — theo bằng chứng hiện tại thì một nửa không có cơ sở, một nửa còn ngược.

Phần trực giác đằng sau vẫn đúng. Nửa đầu của tuyên bố có chạm vào cái gì đó thật. Câu “take a deep breath and work through this step by step” đến từ Large Language Models as Optimizers, và bản tóm tắt gốc nói đúng: nó được tìm ra trên PaLM 2-L năm 2023. Đó là thời model sẽ không tự chia nhỏ bài toán nếu bạn không yêu cầu. Model reasoning bây giờ tự chia nhỏ mặc định, gắn thêm câu đó lên trên chẳng thêm được gì.

Nên làm gì:

• Đừng thêm “think step by step” vào model reasoning. Nó làm sẵn rồi.
• Vẫn nên dùng với model nhỏ/nhanh, hoặc khi bạn cần thấy các bước trung gian để kiểm tra.
• Coi persona là công cụ điều chỉnh giọng văn và đối tượng, không phải công cụ tăng độ chính xác. “Giải thích như một kỹ sư độ tin cậy đang báo cáo cho ban giám đốc” là chỉ dẫn hợp lệ về văn phong và cách đóng khung. Nó không làm model biết thêm điều gì.

Phân biệt cuối cùng đó mới là phần dùng được. Persona định hình cách câu trả lời đọc lên như thế nào. Nó không định hình việc câu trả lời có đúng hay không.

3. Tự tin ≠ chính xác — kết luận đúng, con số sai

Tuyên bố: Microsoft kiểm 2,6 triệu nguồn tham khảo và thấy khoảng 1/4 paper NeurIPS 2025 được kiểm có ít nhất một trích dẫn do AI bịa.

Kết luận: hiện tượng được ghi nhận rất kỹ; nhưng con số thì không. Cuộc kiểm tra mà mọi người đang nhắc tới thật ra là của GPTZero, không phải Microsoft. Nó quét 4.841 trong khoảng 5.290 paper được nhận tại NeurIPS 2025 và xác nhận hơn 100 trích dẫn bịa nằm rải trong 51 paper.

Con số đó gần 1% hơn là 25%. Rất khác nhau — và vẫn đáng báo động, vì mỗi paper trong số đó đã qua phản biện với ít nhất ba reviewer.

Paper phân loại đi sau, Compound Deception in Elite Peer Review, mới là bài đáng đọc hơn. Nó phân loại 100 trích dẫn bịa đó, và phân bố cho bạn biết cần cảnh giác với cái gì:

Nên làm gì. Để ý: 27% + 4% = 31% số trích dẫn bịa có dính tới một paper thật, tìm được. Đó mới là loại nguy hiểm. Một lần search trả về một cái gì đó tạo cảm giác đã kiểm chứng, nhưng thật ra chưa.

Nên quy trình kiểm phải cụ thể:

1. Paper có tồn tại không? (Search đúng tiêu đề.)
2. Tác giả và năm có đúng không? Một phần ba lỗi nằm ở đây.
3. Paper có thật sự nói điều nó đang được trích cho không? Mở ra và tìm đúng câu đó.

Bước 3 là bước mọi người hay bỏ, và cũng chính là lý do bài viết này tồn tại — mấy tuyên bố mình đang kiểm chứng đều nghe như đã có nguồn.

4. Đừng nhét mười điều luật vào một prompt — hiệu ứng có thật, nguồn thì không

Tuyên bố: Meta thử 15 model với prompt có từ 1 đến 12 yêu cầu. Ở mức 8 yêu cầu, model làm đúng từng yêu cầu khoảng 41%, đúng cả 8 cùng lúc chỉ khoảng 5,7%, và 12/15 model mất ổn định khi vượt quá 3 yêu cầu.

Kết luận: mình không tìm được nghiên cứu cụ thể đó, nhưng hiện tượng mà nó mô tả lại là một trong những kiểu lỗi được đo đạc kỹ nhất hiện nay. Nhiều benchmark 2025–2026 đo thẳng vào chuyện này:

• Instruction Stacking Collapse xếp chồng 24 chỉ thị có verifier, áp từ 1 tới 20 chỉ thị mỗi lần, trên các model production. Tỷ lệ tuân thủ giảm phi tuyến khi chồng dày lên — mức giảm tăng tốc chứ không dốc đều.
• When Instructions Multiply đo và ước lượng năng lực khi số chỉ thị tăng dần.
• SEQUOR cho thấy đúng kiểu suy giảm đó trong hội thoại nhiều lượt, và thấy nó tệ hơn đáng kể khi các ràng buộc xuất hiện dần theo thời gian thay vì đưa hết một lần — tức đúng như cách hội thoại thật diễn ra.
• Order Matters tìm thấy position bias trong prompt nhiều ràng buộc: vị trí của ràng buộc trong prompt ảnh hưởng tới việc nó có sống sót hay không.

Nên là: đừng trích “41% và 5,7%”. Nhưng hãy hành động theo kết luận, vì chiều của hiệu ứng thì không ai tranh cãi, và kết quả từ SEQUOR nghĩa là nó áp dụng cho các cuộc chat kéo dài của bạn chứ không chỉ prompt một phát.

Nên làm gì. Tách phần tạo nội dung khỏi phần kiểm ràng buộc:

Lượt 1 — tạo:
  Viết bài hướng dẫn migration. Hai yêu cầu bắt buộc: tách riêng
  Android và iOS, và mọi code block phải chạy được nguyên trạng.

Lượt 2 — kiểm (tin nhắn mới, đính kèm bản nháp):
  Đối chiếu bản nháp này với từng mục dưới đây. Mỗi mục trả lời
  PASS hay FAIL kèm một câu trích từ bản nháp làm bằng chứng.
  Chưa sửa gì cả.
  1. Dưới 1.500 từ
  2. Không dùng dấu gạch ngang dài
  3. Mọi khẳng định từ nguồn ngoài đều có link
  4. Xưng hô nhất quán "bạn" xuyên suốt
  5. Kết bằng một checklist

Lượt 3 — sửa:
  Chỉ sửa những mục bị đánh FAIL. Giữ nguyên phần còn lại.

Kiểm dễ hơn vừa-tạo-vừa-kiểm. Và yêu cầu “trích bằng chứng” rất quan trọng: không có nó, model sẽ tự tin đánh PASS cho những mục rõ ràng đã fail — tức là lặp lại đúng vấn đề ở mục #3.

Thêm một thói quen nữa, xuất phát từ kết quả position bias: đặt ràng buộc quan trọng nhất ở cuối prompt, gần chỗ model bắt đầu sinh nội dung.

5. Mục tiêu quan trọng hơn ví dụ — không kiểm chứng được

Tuyên bố: nghiên cứu từ EPFL, Apple và Mistral AI cho thấy prompt có ví dụ đạt 74%, còn bỏ ví dụ và nói rõ mục tiêu thì đạt 83,8%.

Kết luận: không kiểm chứng được. Mình không tìm được paper nào khớp với tổ hợp ba tổ chức đó cùng những con số đó. Có nghiên cứu hợp lệ cho thấy few-shot có thể gây hại trong một số bối cảnh cụ thể — code synthesis là một trường hợp được ghi nhận — nhưng “ví dụ thua mục tiêu, 74% so với 83,8%” thì không phải kết quả mình chỉ ra được cho bạn.

Phần còn lại sau khi bỏ con số đi. Lời khuyên vẫn hợp lý, vì một lý do rất cơ học: ví dụ thì thiếu xác định. Đưa model ba bản newsletter rồi nói “viết giống vậy”, nó phải tự đoán bạn đang muốn giống ở điểm nào. Độ dài? Giọng văn? Câu đùa ở đoạn hai? Rất thường nó sẽ chọn đặc điểm chung bề mặt nhất — mà đặc điểm bề mặt lại đúng là thứ khiến văn AI đọc lên biết ngay là văn AI.

So sánh:

❌ Đây là 3 bản newsletter của tôi. Viết bản thứ 4 giống mấy bản này.

✅ Tỷ lệ mở newsletter của tôi giảm từ 34% xuống 21% trong 3 tháng.
   Vẫn gửi thứ Ba 9h sáng, vẫn format cũ, danh sách không đổi,
   kiểu đặt tiêu đề cũng không đổi. Trước khi kết luận gì, hãy nói
   cho tôi biết bạn cần thêm dữ liệu nào để phân biệt được vấn đề
   deliverability với chuyện người đọc chán nội dung.

Bản thứ hai đưa cho model một bài toán để giải thay vì một cái vỏ để bắt chước. Nó cũng kết thúc bằng việc hỏi model chưa biết gì — làm lộ giả định trước khi giả định đó bị nướng vào câu trả lời.

Giữ ví dụ lại cho những việc thuần cơ học: định dạng output, cấu trúc JSON, nhãn phân loại, style guide có luật rõ ràng. Bỏ ví dụ đi khi bạn cần model phán đoán.

Cái gì thật sự khái quát được

Bỏ hết mấy con số không kiểm chứng được ra, còn lại một bức tranh khá nhất quán:

Nêu mục tiêu và ràng buộc, đừng nêu đáp án và khuôn mẫu. Tuyên bố 1 và tuyên bố 5 thật ra là cùng một phát hiện nhìn từ hai phía. Câu hỏi mớm thì trao sẵn kết luận; một đống ví dụ thì trao sẵn khuôn. Cả hai đều thay thế phần suy luận của model bằng phỏng đoán của bạn về output.

Kiểm tra tách khỏi tạo nội dung. Tuyên bố 3 và 4 đi cùng nhau. Model vừa không đáng tin khi phải thỏa nhiều ràng buộc một lúc, vừa không đáng tin khi tự báo cáo độ chính xác của chính nó. Cả hai đều tốt lên khi việc kiểm là một lượt riêng và bắt buộc có bằng chứng.

Mẹo prompt có hạn sử dụng. “Take a deep breath” là thật, được đo, được công bố — và được đo trên PaLM 2-L năm 2023. Nó hết hạn. Mọi thứ bạn đọc hôm nay, kể cả bài này, đều có hạn dùng gắn với một thế hệ model.

Và kiểm nguồn trước khi chia sẻ lại. Ba trong năm tuyên bố của một bản tóm tắt được chia sẻ rộng rãi, viết rất chắc nịch, đã không sống sót qua một lần mở nguồn ra coi. Đó mới là bài học thật, và nó áp dụng cho cả output của AI lẫn bài viết của con người.

Câu hỏi thường gặp

Có nên bỏ hẳn câu “think step by step” không? Với model reasoning hiện tại thì có, nó thừa. Vẫn giữ lại cho model nhỏ/nhanh, hoặc khi bạn cần soi các bước trung gian.

Persona có gây hại không? Bằng chứng cho thấy nó không giúp tăng độ chính xác một cách đáng tin cậy, và đôi khi còn làm giảm ở các câu hỏi kiến thức. Nhưng vẫn dùng tốt — và hữu ích — để điều chỉnh giọng văn, đối tượng và cách đóng khung.

Một prompt nhét được bao nhiêu ràng buộc thì an toàn? Các benchmark đã công bố cho thấy chất lượng bắt đầu giảm khá sớm và giảm phi tuyến. Hai tới ba yêu cầu cứng mỗi lượt, phần còn lại kiểm riêng — đó là quy tắc làm việc có cơ sở.

Chain-of-thought chết rồi à? Không. Nó được tích hợp sẵn rồi. Câu prompt thì thừa, kỹ thuật thì không.

Kiểm nhanh một trích dẫn do AI đưa ra bằng cách nào? Search đúng tiêu đề, rồi đối chiếu tác giả và năm, rồi mở ra tìm câu chứng minh cho khẳng định. Khoảng một phần ba trích dẫn bịa vẫn trỏ tới paper có thật, nên “nó tồn tại” là chưa đủ.

Năm tuyên bố được xem xét trong bài đến từ một bản tóm tắt tiếng Việt được chia sẻ rộng rãi, dựa trên bài viết của Ruben Hassid về khoa học đằng sau prompt engineering. Các ý tưởng trong đó đáng để đào sâu, nên chúng xứng đáng được kiểm chứng thay vì chép lại. Mọi paper được nhắc tới đều có link ở trên; chỗ nào mình không tìm được nguồn, mình nói thẳng là không tìm được thay vì chuyển tiếp con số đi.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.

CircularProgressIndicator có sẵn của Flutter dùng ổn — cho tới khi designer đưa bạn một vòng cung bắt đầu ở vị trí 4 giờ, kết thúc ở 8 giờ và ôm lấy một cái nút. Lúc đó bạn không còn cấu hình widget nữa mà phải tự vẽ nó. Bài này dựng vòng cung đó từ đầu bằng CustomPaint, và quan trọng hơn là giải thích phần tính góc — chỗ hầu hết mọi người vấp lần đầu.

Bài viết giả định bạn đã quen với widget cơ bản của Flutter. Trọng tâm ở đây là phần vẽ, không phải phần dựng khung.

Ba widget cần dùng

Chỉ ba widget làm việc thật sự:

• Container — vẽ vòng tròn viền tĩnh bên ngoài (đường “ray” mà tiến trình chạy trên đó).
• Stack — cho phép cung vẽ chồng lên vòng tròn đó thay vì nằm cạnh.
• CustomPaint — đưa cho bạn một Canvas để tự vẽ cung.

Bắt đầu với vòng tròn nền

Trước khi vẽ gì, hãy đưa một vòng tròn đơn giản lên màn hình. Một Container với BoxShape.circle và viền là đủ; bọc sẵn trong Stack ngay từ giờ sẽ đỡ phải sửa lại ở bước sau.

import 'package:flutter/material.dart';

const Color darkBlue = Color.fromARGB(255, 18, 32, 47);

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData.dark().copyWith(scaffoldBackgroundColor: darkBlue),
      debugShowCheckedModeBanner: false,
      home: const Scaffold(
        body: Center(
          child: ProgressIndicatorButton(),
        ),
      ),
    );
  }
}

class ProgressIndicatorButton extends StatelessWidget {
  const ProgressIndicatorButton({
    Key? key,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    const buttonSize = 80.0;
    const borderWidth = 2.0;

    return Stack(
      children: [
        Container(
          width: buttonSize,
          height: buttonSize,
          decoration: BoxDecoration(
            shape: BoxShape.circle,
            border: Border.all(
              color: Colors.white,
              width: borderWidth,
            ),
          ),
        ),
      ],
    );
  }
}

Kết quả là một vòng tròn viền trắng mảnh giữa nền tối. Mọi thứ từ đây trở đi được vẽ đè lên nó.

Viết CustomPainter

Widget CustomPaint chỉ hay ho bằng đúng cái CustomPainter bạn đưa cho nó. Một painter cần ba thứ:

1. kế thừa CustomPainter
2. cài đặt paint
3. cài đặt shouldRepaint

shouldRepaint đúng như tên gọi: trả về true khi một instance mới của painter cần vẽ lại. Với chỉ báo tĩnh thì không có gì thay đổi giữa các lần build, nên false là đúng — và rẻ hơn. (Khi bắt đầu animation cho cung, hãy trả true hoặc so sánh các trường với oldDelegate.)

Mổ xẻ phương thức paint

paint nhận Canvas để vẽ và Size mà nó được cấp. Canvas vẽ được hình chữ nhật, hình tròn, đường thẳng và cả path tùy ý; ở đây ta chỉ cần một cung (arc).

void paint(Canvas canvas, Size size) {
    // 2
    final paint = Paint()
      // 3
      ..color = Colors.blue
      // 4
      ..strokeCap = StrokeCap.butt
      // 5
      ..style = PaintingStyle.stroke
      // 6
      ..strokeWidth = width;

    // 7
    final center = Offset(size.width / 2, size.height / 2);

    // 8
    final radius = (size.width / 2) - (width / 2);

    // 1
    canvas.drawArc(
      Rect.fromCircle(center: center, radius: radius),
      startAngle,
      sweepAngle,
      false,
      paint,
    );
  }

Giải thích từng điểm:

1. drawArc nhận năm đối số. Thứ nhất là Rect chứa cung — Rect.fromCircle giữ cho nó tròn đều. Thứ hai là nơi cung bắt đầu, thứ ba là độ dài cung quét. Thứ tư (useCenter) quyết định hai đầu cung có nối về tâm hay không; để false trừ khi bạn muốn một miếng bánh. Thứ năm là Paint.
2. Paint giữ toàn bộ thuộc tính hiển thị của nét vẽ và được truyền vào drawArc.
3. color — màu nét vẽ.
4. strokeCap — kiểu bo hai đầu cung. StrokeCap.butt cắt phẳng; StrokeCap.round bo tròn, đây là kiểu đa số thiết kế cần.
5. style — PaintingStyle.fill tô đặc, PaintingStyle.stroke chỉ vẽ viền. Vòng tiến trình là viền.
6. strokeWidth — độ dày viền đó, đi kèm với PaintingStyle.stroke.
7. center — một nửa chiều rộng và một nửa chiều cao, để cung nằm giữa khung mà painter nhận được.
8. radius — nửa chiều rộng trừ đi nửa độ dày nét. Bỏ phép trừ này thì nét vẽ sẽ tràn ra mép khung và bị cắt.

Đây là toàn bộ file với painter đã ráp vào, phần tính góc vẫn được comment lại để code biên dịch và chạy được:

import 'package:flutter/material.dart';
// import 'dart:math' as math;

const Color darkBlue = Color.fromARGB(255, 18, 32, 47);

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData.dark().copyWith(scaffoldBackgroundColor: darkBlue),
      debugShowCheckedModeBanner: false,
      home: const Scaffold(
        body: Center(
          child: ProgressIndicatorButton(),
        ),
      ),
    );
  }
}

class ProgressIndicatorButton extends StatelessWidget {
  const ProgressIndicatorButton({
    Key? key,
//     required this.startAngle,
//     required this.endAngle,
  }) : super(key: key);

//   final double startAngle;
//   final double endAngle;

  @override
  Widget build(BuildContext context) {
    const buttonSize = 80.0;
    const borderWidth = 2.0;

    return Stack(
      children: [
        Container(
          width: buttonSize,
          height: buttonSize,
          decoration: BoxDecoration(
            shape: BoxShape.circle,
            border: Border.all(
              color: Colors.white,
              width: borderWidth,
            ),
          ),
        ),
        SizedBox(
          width: buttonSize,
          height: buttonSize,
          child: CustomPaint(
            painter: ProgressIndicatorPainter(
              width: borderWidth,
//               startAngle: startAngle,
//               sweepAngle: endAngle,
            ),
            child: Center(
              child: Container(
                width: buttonSize - 20.0,
                height: buttonSize - 20.0,
                decoration: const BoxDecoration(
                  color: Colors.blue,
                  shape: BoxShape.circle,
                ),
                child: const Center(
                  child: Icon(
                    Icons.done,
                    size: 30.0,
                  ),
                ),
              ),
            ),
          ),
        ),
      ],
    );
  }
}

class ProgressIndicatorPainter extends CustomPainter {
  const ProgressIndicatorPainter({
    required this.width,
//     required this.startAngle,
//     required this.sweepAngle,
  }) : super();

  final double width;
//   final double startAngle;
//   final double sweepAngle;

  @override
  void paint(Canvas canvas, Size size) {
    final paint = Paint()
      ..color = Colors.blue
      ..strokeCap = StrokeCap.butt
      ..style = PaintingStyle.stroke
      ..strokeWidth = width;

    final center = Offset(size.width / 2, size.height / 2);
    final radius = (size.width / 2) - (width / 2);

//     canvas.drawArc(
//       Rect.fromCircle(center: center, radius: radius),
//       startAngle,
//       sweepAngle,
//       false,
//       paint,
//     );
  }

  @override
  bool shouldRepaint(CustomPainter oldDelegate) => false;
}

Hãy giữ nguyên các dòng comment đúng vị trí — bỏ comment một nửa thì sẽ lỗi biên dịch.

startAngle và sweepAngle thực sự là gì

Đây là phần đáng đi chậm lại.

startAngle tính bằng radian và bắt đầu từ 0 — tức vị trí 3 giờ trên đường tròn đơn vị. Điểm gây bẫy là chiều: drawArc quét theo chiều kim đồng hồ, trong khi đường tròn đơn vị bạn học ở trường chạy ngược chiều kim đồng hồ. Thay vì suy luận lại từ đầu, mẹo là cứ đọc vị trí trên đường tròn đơn vị như bình thường rồi thêm dấu âm. Muốn cung bắt đầu ở π/2 (vị trí 12 giờ)? Truyền -π/2.

sweepAngle không phải vị trí kết thúc — nó là độ dài. Giá trị bạn truyền được cộng vào startAngle, và tổng đó mới là nơi cung dừng. Muốn vẽ từ π/2 về 0 thì cần startAngle: -π/2 và sweepAngle: π/2, vì −π/2 + π/2 = 0.

Tính sweep cho một cung bất kỳ

Lấy vòng cung ở đầu bài: nó bắt đầu quanh 2π/3 và kết thúc quanh 11π/6 trên đường tròn đơn vị. Không có phép trừ gọn gàng nào luôn cho ra sweep khi start là góc tùy ý, nên hãy đếm cung theo từng lát:

• góc phần tư I được phủ trọn → π/2
• góc phần tư II và IV mỗi bên góp một lát π/6 → π/6 + π/6

π/6 + π/6 + π/2 = 5π/6, đó chính là sweep. Code đầy đủ:

import 'package:flutter/material.dart';
import 'dart:math' as math;

const Color darkBlue = Color.fromARGB(255, 18, 32, 47);

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData.dark().copyWith(scaffoldBackgroundColor: darkBlue),
      debugShowCheckedModeBanner: false,
      home: const Scaffold(
        body: Center(
          child: ProgressIndicatorButton(
            startAngle: -2 * math.pi / 3,
            endAngle: 5 * math.pi / 6,
          ),
        ),
      ),
    );
  }
}

class ProgressIndicatorButton extends StatelessWidget {
  const ProgressIndicatorButton({
    Key? key,
    required this.startAngle,
    required this.endAngle,
  }) : super(key: key);

  final double startAngle;
  final double endAngle;

  @override
  Widget build(BuildContext context) {
    const buttonSize = 80.0;
    const borderWidth = 2.0;

    return Stack(
      children: [
        Container(
          width: buttonSize,
          height: buttonSize,
          decoration: BoxDecoration(
            shape: BoxShape.circle,
            border: Border.all(
              color: Colors.white,
              width: borderWidth,
            ),
          ),
        ),
        SizedBox(
          width: buttonSize,
          height: buttonSize,
          child: CustomPaint(
            painter: ProgressIndicatorPainter(
              width: borderWidth,
              startAngle: startAngle,
              sweepAngle: endAngle,
            ),
            child: Center(
              child: Container(
                width: buttonSize - 20.0,
                height: buttonSize - 20.0,
                decoration: const BoxDecoration(
                  color: Colors.blue,
                  shape: BoxShape.circle,
                ),
                child: const Center(
                  child: Icon(
                    Icons.done,
                    size: 30.0,
                  ),
                ),
              ),
            ),
          ),
        ),
      ],
    );
  }
}

class ProgressIndicatorPainter extends CustomPainter {
  const ProgressIndicatorPainter({
    required this.width,
    required this.startAngle,
    required this.sweepAngle,
  }) : super();

  final double width;
  final double startAngle;
  final double sweepAngle;

  @override
  void paint(Canvas canvas, Size size) {
    final paint = Paint()
      ..color = Colors.blue
      ..strokeCap = StrokeCap.butt
      ..style = PaintingStyle.stroke
      ..strokeWidth = width;

    final center = Offset(size.width / 2, size.height / 2);
    final radius = (size.width / 2) - (width / 2);

    canvas.drawArc(
      Rect.fromCircle(center: center, radius: radius),
      startAngle,
      sweepAngle,
      false,
      paint,
    );
  }

  @override
  bool shouldRepaint(CustomPainter oldDelegate) => false;
}

Thích dùng độ hơn? Đổi ở sát chỗ vẽ

Nếu radian làm code gọi khó đọc, hãy nhận giá trị theo độ vào painter rồi đổi sang radian ngay trước drawArc. Không có gì khác thay đổi — vẫn các khái niệm đó, chỉ là con số dễ chịu hơn.

import 'package:flutter/material.dart';
import 'dart:math' as math;

const Color darkBlue = Color.fromARGB(255, 18, 32, 47);

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData.dark().copyWith(scaffoldBackgroundColor: darkBlue),
      debugShowCheckedModeBanner: false,
      home: const Scaffold(
        body: Center(
          child: ProgressIndicatorButton(
            startAngle: -120,
            endAngle: 150,
          ),
        ),
      ),
    );
  }
}

class ProgressIndicatorButton extends StatelessWidget {
  const ProgressIndicatorButton({
    Key? key,
    required this.startAngle,
    required this.endAngle,
  }) : super(key: key);

  final int startAngle;
  final int endAngle;

  @override
  Widget build(BuildContext context) {
    const buttonSize = 80.0;
    const borderWidth = 2.0;

    return Stack(
      children: [
        Container(
          width: buttonSize,
          height: buttonSize,
          decoration: BoxDecoration(
            shape: BoxShape.circle,
            border: Border.all(
              color: Colors.white,
              width: borderWidth,
            ),
          ),
        ),
        SizedBox(
          width: buttonSize,
          height: buttonSize,
          child: CustomPaint(
            painter: ProgressIndicatorPainter(
              width: borderWidth,
              startAngle: startAngle,
              sweepAngle: endAngle,
            ),
            child: Center(
              child: Container(
                width: buttonSize - 20.0,
                height: buttonSize - 20.0,
                decoration: const BoxDecoration(
                  color: Colors.blue,
                  shape: BoxShape.circle,
                ),
                child: const Center(
                  child: Icon(
                    Icons.done,
                    size: 30.0,
                  ),
                ),
              ),
            ),
          ),
        ),
      ],
    );
  }
}

class ProgressIndicatorPainter extends CustomPainter {
  const ProgressIndicatorPainter({
    required this.width,
    required this.startAngle,
    required this.sweepAngle,
  }) : super();

  final double width;
  final int startAngle;
  final int sweepAngle;

  @override
  void paint(Canvas canvas, Size size) {
    final paint = Paint()
      ..color = Colors.blue
      ..strokeCap = StrokeCap.butt
      ..style = PaintingStyle.stroke
      ..strokeWidth = width;

    final startAngleRad = startAngle * (math.pi / 180.0);
    final sweepAngleRad = sweepAngle * (math.pi / 180.0);

    final center = Offset(size.width / 2, size.height / 2);
    final radius = (size.width / 2) - (width / 2);

    canvas.drawArc(
      Rect.fromCircle(center: center, radius: radius),
      startAngleRad,
      sweepAngleRad,
      false,
      paint,
    );
  }

  @override
  bool shouldRepaint(CustomPainter oldDelegate) => false;
}

Hai ví dụ để luyện tay

Cùng quy trình, chỉ khác con số:

• Bắt đầu ở vị trí 3 giờ. startAngle là 0 (viết 0.0 trong code cũng được). Sweep phủ trọn góc phần tư IV cộng một lát π/6 của góc phần tư III: π/6 + π/2 = 4π/6.
• Bắt đầu ở −5π/4. Ở góc phần tư II lấy trọn quadrant, rồi ở góc phần tư III lấy một lát π/6 và một lát π/12: π/2 + π/6 + π/12 = 3π/4.

Kết luận

Đếm từng lát theo góc phần tư không phải cách thanh lịch nhất để suy ra sweep angle, nhưng nó đáng tin và bạn có thể tính ngay trên giấy cạnh bản thiết kế. Khi vòng cung tĩnh đã đúng, việc thêm animation chỉ là một bước ngắn: điều khiển sweepAngle bằng AnimationController, và đổi shouldRepaint sang so sánh với oldDelegate để Flutter thực sự vẽ lại.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.