Profile
Quỳnh Ruby
Author
Quỳnh Ruby quynhfruby.com
“
”
Author
Quỳnh Ruby quynhfruby.com
Author
Quỳnh Ruby quynhfruby.com

Bắt đầu dự án MealTrack

TL;DR

Từ một file Google Sheet kết hợp với Claude để theo dõi calo và dinh dưỡng, mình bắt đầu tự xây dựng một ứng dụng mang tên MealTrack.

Đây là bài viết đầu tiên trong chuỗi ghi chép về quá trình phát triển dự án này.

Bắt đầu từ một nhu cầu cá nhân

Vì muốn giảm cân nên mình cần kiểm soát lượng calo nạp vào và calo tiêu hao mỗi ngày. Từ đó tính được mức thâm hụt calo phù hợp, đồng thời vẫn đảm bảo cơ thể được cung cấp đủ các chất dinh dưỡng cần thiết.

Giải pháp đầu tiên mình thử là tận dụng Claude kết hợp với Google Sheet.

Mình tạo một file Google Sheet tên CaloriesTrack để lưu nhật ký ăn uống và quản lý thông tin dinh dưỡng.

Cách hoạt động cũng khá đơn giản:

  • Thực phẩm: Claude tìm kiếm thông tin dinh dưỡng của một số thực phẩm phổ biến. Với thực phẩm đóng gói, mình có thể chụp bảng thành phần dinh dưỡng trên bao bì rồi nhờ Claude cập nhật vào Google Sheet.
  • Nhật ký ăn uống: Mỗi lần ăn gì, mình chỉ cần nhập cho Claude. Claude sẽ cập nhật vào sheet, tính lượng calo và các thành phần dinh dưỡng đã nạp, đồng thời thông báo mình còn có thể ăn thêm bao nhiêu trong ngày.
  • Thực đơn: Nhờ Claude lên thực đơn theo tuần dựa trên danh sách thực phẩm mình có thể mua được. Việc này giúp tính toán trước nguyên liệu cần đi chợ và cân đối các bữa ăn.
  • Báo cáo: Cuối tuần, mình nhờ Claude tổng hợp dữ liệu, phân tích tình hình và đề xuất một số điều chỉnh. Khi cần, có thể nhờ Claude tạo thêm báo cáo để xem cho tiện.
Luồng ghi calo: nhắn món cho Claude, Claude tính calo, ghi vào Google Sheet, báo còn ăn được bao nhiêu
Luồng ghi calo bằng Claude và Google Sheet

Nhìn chung, cách làm này đáp ứng khá tốt nhu cầu ban đầu.

Tuy nhiên, mỗi lần tương tác, Claude lại phải gọi công cụ kết nối Google Sheet, đọc dữ liệu, xử lý rồi mới trả kết quả. Vì vậy, thao tác hơi chậm và cũng tiêu tốn kha khá token.

Sau hơn một tuần sử dụng, mình bắt đầu nghĩ đến việc tự build một ứng dụng để phục vụ nhu cầu này.

Thực ra, nếu nói rằng mình build app chỉ vì muốn tối ưu tốc độ và tiết kiệm token thì cũng hơi khiên cưỡng. Vì thật ra tự phát triển một ứng dụng cũng tốn không ít thời gian và token :D.

Nói chung, nghiện thì không cần lý do. 😅

Ý tưởng: MealTrack

Mình đặt tên cho ứng dụng là MealTrack.

Trước khi bắt đầu, mình xác định một số công việc chính mà app cần giải quyết:

Thực đơn của app

4 việc chính của MealTrack

✦
  1. 1

    Lưu nhật ký ăn uống và tính thành phần dinh dưỡng

    Không chỉ theo dõi calo, mình còn muốn kiểm soát một số thành phần dinh dưỡng khác mà cơ thể cần. Mục tiêu là tạo ra mức thâm hụt calo phù hợp nhưng vẫn hạn chế tình trạng thiếu chất trong quá trình giảm cân.

  2. 2

    Lên thực đơn theo tuần

    Mình muốn có thể lên thực đơn trước cho cả tuần, từ đó tính toán lượng thực phẩm cần mua và chuẩn bị các bữa ăn.

    Điều này khá phù hợp với thói quen sinh hoạt hiện tại của mình: thường đi chợ và nấu sẵn các món ăn vào cuối tuần để dùng dần trong tuần.

  3. 3

    Thư viện công thức món ăn

    Có những món mình thường xuyên nấu với công thức và định lượng gần như cố định.

    Thay vì mỗi lần ăn lại phải nhập từng nguyên liệu và khối lượng, mình muốn lưu sẵn công thức vào thư viện. Khi cần, chỉ việc chọn món ăn, các thông tin về nguyên liệu, định lượng và thành phần dinh dưỡng sẽ được tự động tính toán.

  4. 4

    Danh sách thực phẩm

    App cần có sẵn danh sách thực phẩm cùng thông tin dinh dưỡng tương ứng, đồng thời cho phép người dùng thêm mới hoặc chỉnh sửa.

    Mình dự định tải trước dữ liệu của một số thực phẩm phổ biến, tham khảo từ các tài liệu dinh dưỡng có nguồn rõ ràng. Dữ liệu ban đầu có thể chưa hoàn toàn chính xác, vì vậy cần có khả năng cập nhật khi tìm được nguồn đáng tin cậy hơn hoặc tự nhập các thành phần dinh dưỡng còn thiếu.

Ngoài ra, app cũng cần một số chức năng phụ như xem báo cáo, nhập món ăn thủ công, quản lý tài khoản và dữ liệu người dùng.

Đây là phạm vi ban đầu mình xác định cho MealTrack. Những gì sẽ được giữ lại, thay đổi hay bổ sung có thể sẽ rõ hơn trong quá trình phát triển.

Cách mình tiếp cận dự án

Dự án này mình Vibe Coding với Claude Code, chủ yếu sử dụng Opus 5.5 cho khâu lập kế hoạch, Sonnet 5.5 cho thực thi và kết hợp với bộ AgentKit.

Quy trình mình đang áp dụng:

  1. Idea
  2. Brainstorm
  3. Draft Spec
  4. Lặp lạiPrototypeDùng thử/Feedback
  5. Finalize Spec
  6. Plan
  7. Build
  8. Ship

Vì sao mình lại dựng Prototype trước?

Ở một vài dự án Vibe Coding trước đây, thấy AI viết code khá tốt nên mình thường cho AI nhảy thẳng vào làm, đợi code xong hết mới quay lại xem giao diện.

Vấn đề bắt đầu xuất hiện khi làm những app có nhiều tính năng và luồng người dùng phức tạp.

Lúc viết Spec và lập Plan, có nhiều chỗ mình chưa hình dung được hết các thao tác và trải nghiệm thực tế. Đến khi code xong, mình mới phát hiện những điểm chưa hợp lý và phải thay đổi, điều chỉnh khá nhiều.

Mình có cảm giác khi logic hệ thống đã được triển khai, việc điều chỉnh UX/UI thường không còn đơn giản. AI có xu hướng bám theo cấu trúc đã xây dựng, hoặc nếu thay đổi lớn thì có thể phải refactor khá nhiều.

Tính ra cũng không tiết kiệm thời gian là mấy, mà thành quả cuối cùng lại không được như kỳ vọng.

Vì vậy với MealTrack, mình quyết định dựng Prototype trước, tự trải nghiệm và điều chỉnh các luồng sử dụng. Khi đã tương đối rõ về cách app cần hoạt động, mình mới chốt Spec và lên Plan để triển khai đầy đủ.

Trước đây

  1. Viết Spec, lập PlanChưa hình dung hết thao tác và trải nghiệm thực tế
  2. AI code xong hết
  3. Mới xem giao diệnCode xong mới thấy điểm chưa hợp lý
  4. Sửa nhiều, có thể phải refactorAI bám theo cấu trúc đã xây dựng

Không tiết kiệm thời gian là mấy, kết quả không như kỳ vọng

Với MealTrack

  1. Draft Spec
  2. Lặp lạiPrototypeDùng thửTự trải nghiệm, điều chỉnh luồng sử dụng
  3. Finalize Spec, Plan
  4. Build

Rõ cách app cần hoạt động rồi mới chốt Spec và triển khai đầy đủ

Trong lúc dùng thử Prototype, mình nhận ra có một điểm cần thay đổi ở luồng đăng nhập.

Ban đầu, mình thiết kế luồng yêu cầu người dùng đăng nhập trước khi có thể sử dụng app.

Sau khi tự trải nghiệm, mình nhận ra không nhất thiết phải yêu cầu đăng nhập ngay từ đầu. Thay vào đó, mình cho phép người dùng truy cập và trải nghiệm trước một số tính năng cũng như các màn hình chính.

App chỉ yêu cầu đăng nhập khi người dùng thực hiện một hành động cần lưu dữ liệu, chẳng hạn như thêm món ăn hoặc tạo công thức.

Lúc yêu cầu đăng nhập, app sẽ giải thích thêm để người dùng biết dữ liệu của mình sẽ được lưu lại và có thể sử dụng trên nhiều thiết bị.

Lúc đầu mở app là phải đăng nhập; sau khi thử Prototype, app chỉ hỏi đăng nhập khi thêm món hay tạo công thức
Khi nào app hỏi đăng nhập

Mình nghĩ cách này hợp lý hơn vì người dùng đã có cơ hội hiểu app làm được gì và trải nghiệm một phần trước khi phải đăng ký tài khoản.

Tiến độ hiện tại

MealTrack đang ở giai đoạn Prototype. Mình vẫn đang tiếp tục kiểm tra, điều chỉnh các luồng sử dụng và hoàn thiện những chức năng cốt lõi trước khi chuyển sang giai đoạn triển khai.

Bấm thử

Prototype MealTrack

Mở toàn màn hình ↗

Bạn có thể bấm thử ngay trong khung bên dưới: thêm món, lên thực đơn, xem tổng quan. Dữ liệu chỉ là dữ liệu mẫu, tải lại trang sẽ trở về như ban đầu.

Mở toàn màn hình để xem user flow: toàn bộ các màn hình của app, cách chúng nối với nhau và vài nhiệm vụ gợi ý để thử.

Đây mới là những ghi chép đầu tiên của dự án. Mình sẽ tiếp tục cập nhật những thay đổi, vấn đề gặp phải và cách mình giải quyết trong các bài viết tiếp theo.

Hẹn gặp lại ở những cập nhật tiếp theo của MealTrack!

Chia sẻ bài viết này:
import "../components/workflow-connectors.ts";