Tuần trước, trong quá trình chuẩn bị cho một chiến dịch marketing với mã giảm giá trên landing page, team mình đã tạo một mã test giảm 100% để kiểm thử quy trình thanh toán. Khi chính thức mở landing page để đăng ký, mình đã dựng một Dashboard dạng Leaderboard để theo dõi hiệu quả sử dụng của các mã giảm giá.

Và bất ngờ, một mã giảm 100% nội bộ xuất hiện trên Leaderboard… tá hoả luôn! Cũng may là có dashboard đó, nếu chỉ dựa vào danh sách đơn hàng, khả năng cao là mình đã lướt qua mà không để ý.

Leaderboard mình dựng nhanh để dễ dàng theo dõi số mã được sử dụng.

Điều mình học được từ vụ này

• Khi nhìn vào danh sách đơn hàng, mã test 100% rất dễ bị lẫn giữa hàng trăm đơn hàng khác. Mình đã từng lướt qua mà không nhận ra có đơn dùng mã đó.
• Xem bảng xếp hạng mã ref giúp mình nhận diện dễ hơn, vì khi nhìn vào danh sách trên bảng xếp hạng, tự dưng “mã lạ” lại nhô lên. Trường hợp này, mã test nội bộ rõ ràng trên bảng, nên mình phát hiện nhanh.
• Việc trực quan hóa dữ liệu giúp mình nhanh chóng nhận ra các điểm bất thường hơn. Một bảng xếp hạng đơn giản đã giúp mình nhìn thấy những mã không hợp lệ mà rất khó có thể nhận ra từ dữ liệu thô.

Sau khi phát hiện ra mã bất thường, team mình đã phải xử lý và chuẩn bị một checklist nghiêm ngặt hơn để kiểm soát mã test trước khi chạy thực tế.

Bài học nhớ đời luôn!

Dạo này mình cũng hay phải đụng mấy workflow automation và hệ thống quản lý cho doanh nghiệp, nhưng nhìn lại một chặng đường, thì thứ khiến mình bắt đầu không phải là từ khoá “Automation” hay “No-code/Low-code” mà là “ Productivity “.

Cuối 2023, mình trăn trở nhiều về chuyện làm sao để tối ưu được hiệu suất làm việc của bản thân. Lúc đó, mình xác định “Productivity” sẽ là từ khoá mình theo đuổi trong năm 2024, và trên hành trình tìm kiếm giải pháp để tối ưu từng thứ nho nhỏ trong công việc lẫn cuộc sống, thì Automation chỉ là 1 trong những giải pháp mình lựa chọn.

Quay ngược về quá khứ, workflow đầu tiên mà mình setup là luồng đồng bộ Task từ Todoist lên Notion. Lý do mình có luồng này là vì mình xem được 1 video khá hay của một anh đẹp giai chia sẻ về “Productivity System” đơn giản của ảnh:

Bước 1 – Capture (Thu thập ý tưởng)

Bước 2 – Organize (Tổ chức & xử lý)

Xem xong tự dưng mình tỉnh lại liền.. Ồ, đúng là nhiều ý tưởng bộc phát lúc không ngồi máy, mà mình thường không ghi chép lại, xong quên luôn:))).

Mọi thứ đều ổn, cho tới khi nó bất ổn!

Ngày nào cũng phải copy dữ liệu từ Todoist lên Notion, cũng mệt. Và nó đi ngược lại với mục tiêu “ Productivity ” mà mình đang hướng tới.

Thế là mình đi tìm cách tự động đồng bộ task từ Todoist lên Notion:

• Mình thử Zapier trước, chạy cũng mượt nhưng có tính phí. Mà trả phí chỉ để chạy workflow đơn giản này thì mình thấy hổng đáng (thiệt ra là hổng có tiền á chớ..).
• Rồi nhớ mang máng công ty có cấp tài khoản n8n, hồi đầu hổng thích xài lắm nhưng có sẵn, không tốn tiền, nên ráng mò thử… rồi ghiền luôn.

Giờ nhìn lại cái workflow hồi đầu setup, thấy cũng hơi “phèn”, nhưng nhờ nó mình cũng tiết kiệm được khối thời gian.

Cứ có giải pháp để giải quyết được 80% vấn đề trong thời gian chờ đợi giải pháp hoàn hảo thì vẫn ổn hơn là không có vấn đề nào được giải quyết đúng hông!

Trong hình là phần 1 của series “Tối ưu hiệu suất” mình chia sẻ trong mấy buổi Friday Sharing ở EGANY + 2 version của workflow đồng bộ task từ Todoist lên Notion.

Tự dưng ngồi xem lại series này, cái cảm xúc dạt dào ghê. Sắp tới mình sẽ bóc tách từng thứ nho nhỏ trong series này ra để chia sẻ, cũng gọi là có kỷ niệm :D.

Mình có gần 400 trang nội dung trên Notion cần viết lại, ngồi làm tay chắc hết 1-2 ngày, nên tranh thủ setup luôn workflow trên n8n cho nó tự chạy.

Trong workflow:

• Mình dùng model gpt-4o-mini, gọi API bên thứ 3 để tiết kiệm ~70% chi phí so với gọi thẳng OpenAI API.
• Dự kiến chạy xong gần 400 trang chắc mất tầm 1-2 tiếng.

Flow này cũng có thể dùng để:

• Tổng hợp ghi chú từ Second Brain / PKM
• Viết lại thành nội dung cho Blog, Fanpage, tài liệu sản phẩm, v.v.

Dạo này mình đang có hứng đọc lại mấy bài trên Lenny’s Newsletter — một trang quá nổi tiếng trong giới làm sản phẩm rồi ha. Ai làm product chắc cũng từng nghe hoặc lướt qua ít nhất một lần.

Vấn đề là… bài viết quá trời, mà mình thì không đủ thời gian đọc hết. Thế là mình nảy ra ý tưởng: xây một workflow tự động lưu bài viết về Notion — để đọc dần, tiện ghi chú, lại dễ phân loại. (Chi tiết về workflow này chắc để dịp khác mình kể kỹ hơn)

Bắt đầu từ đâu?

Bước đầu tiên dĩ nhiên là cần có danh sách link của tất cả bài viết. May sao, bác Lenny đã tổng hợp sẵn theo năm ở trang sitemap: https://www.lennysnewsletter.com/sitemap

Nhưng khi copy toàn bộ link này vào Notion, nó sẽ dán nội dung dạng hyperlink (tiêu đề có gắn URL), việc tiếp theo mình cần làm là phải bóc tách được URL từ hyperlink đó.

Đọc tới đây, trong đầu mình tự động “nhảy số”: sao không dùng AI để trích xuất toàn bộ link luôn?
Thế là mình gõ prompt, nhờ AI đọc nội dung trang sitemap, xử lý và xuất ra bảng dữ liệu đúng format mình cần.

Kết quả: hoạt động trơn tru, nhìn mượt cực kỳ. Dán vào Notion là xong bước 1 của workflow.
Tới đây thì cảm giác… “mình ngầu lòi”.

Nhưng mà… có chắc ăn không?

Dừng lại một chút. Có thật mọi thứ đã ổn chưa?

Vấn đề bắt đầu xuất hiện khi mình nghĩ kỹ lại:

Liệu dữ liệu AI trả về có đúng hoàn toàn với nội dung thật trên trang không?

Câu trả lời là: không chắc. Vì bản thân AI rất dễ bị “hallucination” — chế thêm dữ liệu hoặc nhầm lẫn thông tin.

Vậy là:

• Nếu mình tin tưởng tuyệt đối, lỡ sai thì… ôm một đống link rác.
• Nếu muốn kiểm tra lại từng link, thì… quay về làm thủ công như cũ.
• Nếu muốn “làm cho chuẩn”, lại phải thiết kế thêm workflow phức tạp để kiểm lỗi.

Tự dưng, cái giải pháp “ngầu” lúc đầu, giờ trở thành một gánh nặng.

Quỳnh..quay xe!

Tối đó nằm nghĩ nghĩ… sao mình không nghĩ tới thứ đơn giản hơn?

Ơ.. Google Sheet làm phát một mà!!

Chỉ cần viết một function Google Apps Script hoặc dùng add-on đơn giản là có thể từ dữ liệu đầu vào đó, lấy toàn bộ URL mà không cần AI, không prompt, không tốn token, không lo sai lệch dữ liệu.

Một giải pháp đơn giản, hiệu quả… và lẽ ra mình nên làm từ đầu.

Bên dưới là demo tính năng bóc tách URL từ dữ liệu đầu vào, sử dụng Google App Script để xử lý.

Mình rút ra gì từ chuyện này?

Câu chuyện nhỏ này nhắc mình một điều:

Đôi khi vấn đề nó đơn giản lắm, cách giải quyết cũng đơn giản. Chỉ là mình tự nghĩ phức tạp lên — hoặc bị cuốn theo công nghệ mà thôi.

Tiếp nối bài viết trước, trong bài viết này mình sẽ chia sẻ chi tiết hơn về những suy nghĩ và trải nghiệm của mình với Lovable – công cụ mình dùng để build SnapVocab.

Mình dùng Lovable – gói Free chỉ được 5 messages/ngày. Điều này với nhiều người có thể sẽ khá hạn chế và bức bối. Mình cũng vậy, nhưng vì sao mình vẫn quyết tâm không nâng cấp lên gói cao hơn để build nhanh hơn, prompt thoải mái hơn?

Kinh nghiệm từ việc nâng cấp tài khoản

Thật ra mình từng nâng cấp gói Starter (100 messages/tháng) để build cho 1 sản phẩm khác, và đây là những thứ mình nhận ra sau dự án đó:

• Làm nhanh nhưng prompt tuỳ tiện: Hạn mức message cao khiến mình dễ viết prompt ẩu, không quan tâm đến kết quả đầu ra vì đầu tư suy nghĩ kỹ càng còn khó khăn và tốn công hơn việc gửi yêu cầu sơ sài rồi chỉnh sửa.
• Hăng máu nhưng ngắt quãng: Hăng máu là tốt nếu nó được duy trì suốt một thời gian dài. Tuy nhiên mình thì không phải kiểu người có thể duy trì sự hăng máu đó liên tục được. Vì số lượng message nhiều, nên mình cứ thế làm hăng trong 1 ngày, tiêu gần hết số message để rồi sản phẩm bỏ ngỏ đó suốt 1 thời gian mới quay lại. Tới lúc quay lại thì tư duy không còn liền mạch nữa.
• Không có thời gian để reflect: Việc làm nhiều thứ 1 lúc khiến mọi thứ nhanh phình to ra, để đến khi mình muốn thay đổi hay điều chỉnh thì… quá rối rắm để có thể điều chỉnh theo ý mình.

Làm gì với 5 messages mỗi ngày?

Đó là lý do vì sao mình thay đổi trong dự án mới này, với 5 messages mỗi ngày buộc mình phải:

1. Cân nhắc rất kỹ mỗi prompt

Ví dụ thay vì prompt: “Bổ sung nút cho tính năng Pronunciation”

Mình sẽ đầu tư thời gian để viết prompt chi tiết hơn: “Hãy bổ sung tính năng Pronunciation: Nếu thông tin trả về có audio, hiển thị nút play audio nằm phía bên phải của phần phiên âm. Nếu không có audio thì ẩn nút play này. Khi click vào nút Play audio, không cộng Encountered cho từ.”

2. Tận dụng hết khả năng để tự xử lý mà không cần phải prompting

• Mình nhờ Claude đưa câu lệnh để tạo database trực tiếp trên Supabase thay vì prompt cho Lovable xử lý.
• Mình đọc log báo lỗi, nhờ Claude giải thích, nếu là lỗi từ Supabase thì nhờ nó hướng dẫn mình cách tự fix mà không cần phải nhờ Lovable xử lý.
• Đối với chỉnh style của UI: Mình có thể dùng tính năng Edit UI của Lovable để điều chỉnh, không nhất thiết phải prompt nếu chỉ chỉnh mấy cái nho nhỏ.
• Và mình nhận ra, mình hoàn toàn có thể tự pull source từ Github được kết nối với Lovable để tự điều chỉnh source code, xong xuôi chỉ cần push lại source là Lovable cũng sẽ build lại source cho mình.

3. Reflect liên tục

• Vì chỉ được 5 message mỗi ngày nên ngày nào mình cũng phải tranh thủ tận dụng để làm tiếp, và cố gắng mỗi ngày đều có được 1 cái gì đó hoàn chỉnh.
• Sau mỗi phiên làm việc, mình đều phải ngồi tính toán lại xem ngày mai nên làm gì tiếp theo để chỉ gói gọn trong 5 prompt có thể release được 1 cái gì đó. Những thứ hôm nay mình làm liệu có đủ tốt chưa,.. Nó giúp mình luôn phải thấu hiểu sản phẩm mình đang làm và tính toán rất nhiều thứ không chỉ là tính năng, là trải nghiệm người dùng, mà còn phải cân đo đong đếm xem cái gì nên làm trước – làm sau để mọi thứ khi ghép nối vào với nhau có thể tạo ra được bức tranh hoàn thiện.

4. Duy trì đều đặn

• Nếu bạn bỏ lỡ ngày hôm nay, thì bạn mất 5 messages. Lovable sẽ không bù cho bạn. Đó là lý do vì sao mỗi ngày dù trễ, dù mệt, dù bất cứ lý do gì mình vẫn phải mở máy và làm. Mình không muốn lãng phí 5 messages miễn phí mà mình có được.
• Nên nó giúp mình duy trì đều đặn mỗi ngày với sản phẩm mình đang có để nó được sự liền mạch trong quá trình phát triển.

Tiến độ hiện tại của dự án

Sau 1 tuần làm việc với 5 messages/ngày, đây là những gì mình đã hoàn thành:

• [x] Thiết kế và xây dựng database cho ứng dụng dịch và quản lý từ vựng
• [x] Đăng nhập/Đăng ký tài khoản
• [x] Quản lý từ vựng cơ bản
• [x] Đo lường mức độ ghi nhớ của mỗi từ vựng
• [ ] Flashcard
• [ ] Quản lý từ vựng nâng cao
• [ ] Tự động lên lịch ôn tập từ vựng theo phương pháp Spaced Repetition

Tiến độ có thể không nhanh như khi dùng gói trả phí, nhưng chất lượng code và sự tập trung mà mình đạt được lại vượt xa kỳ vọng.

Đến khi nào thì mình sẽ quyết định nâng cấp lên gói cao hơn?

Có thể là không, ít nhất là cho sản phẩm này*,* hiện tại mình thấy ổn với những gì đang có.
(Hoặc có thể là Có – ở thời điểm nào đó mình cần một sự tăng tốc để release sản phẩm).

Cơ bản là sản phẩm này mình build để giải quyết pain point của cá nhân mình, và mình tận dụng nó để học và hiểu thêm về cách build 1 sản phẩm nhỏ với AI sẽ thế nào mà thôi.

Bài học lớn nhất: Giới hạn tạo ra kỷ luật

Khi nhìn lại quá trình làm việc với 5 messages/ngày, mình nhận ra rằng giới hạn đôi khi lại là điều tuyệt vời nhất cho sự sáng tạo. Nó buộc chúng ta phải suy nghĩ kỹ hơn, lên kế hoạch chi tiết hơn, và thực sự đánh giá giá trị của từng tương tác với công cụ.

Còn bạn thì sao? Bạn có từng trải nghiệm việc làm việc trong điều kiện giới hạn lại mang đến kết quả tốt hơn không? Hãy chia sẻ kinh nghiệm của mình trong phần bình luận nhé!

Để bạn dễ dàng theo dõi hành trình xây dựng SnapVocab từ đầu, mình sẽ luôn cập nhật các bài viết liên quan tại đây:

• Bài mở đầu: SnapVocab #1 – Mở đầu
• SnapVocab #2: Đi sâu vào quy trình & phác thảo Prototype với AI
• Bài hiện tại: SnapVocab #3: Lý do mình chỉ sử dụng Lovable bản Free

(Danh sách này sẽ được cập nhật liên tục mỗi khi có bài viết mới.)

Tiếp nối bài viết trước, mình đã chia sẻ về ý tưởng ban đầu khi nhận ra mình “tụt mood” thế nào mỗi lần gặp hàng tá từ mới trong trải nghiệm đọc sách tiếng Anh. Lần này, chúng ta sẽ cùng nhau đi sâu hơn vào quy trình hiện thực hóa ý tưởng ấy thành một prototype có thể hoạt động được.

1. Phác thảo hành trình người dùng

Như mình từng đề cập, mục tiêu cốt lõi của SnapVocab là giảm tối đa sự gián đoạn khi đọc sách tiếng anh trên Kindle. Vậy nên, mình hệ thống hóa ý tưởng theo một userflow 5 bước:

**1. Capture (Chụp)**Người dùng chụp màn hình trang sách hoặc đoạn văn đang đọc (trên Kindle, web, PDF, v.v.).

2. Xử lý văn bản – Lúc này người dùng sẽ có hai lựa chọn:

• Dịch cả đoạn: Hệ thống sẽ dịch toàn bộ đoạn văn bản.
• Bóc tách từ riêng lẻ: Tách từ vựng trọng tâm có nghĩa.

3. Chọn từ cần tra cứuNgười dùng chọn những từ mới cần tra.

4. Tra cứu từHệ thống sẽ trả về ý nghĩa của các từ vựng đã chọn.

5. Lưu vào cơ sở dữ liệuCác từ vựng và thông tin liên quan (ngữ cảnh, ví dụ) được lưu trữ để dùng về sau.

Chia quy trình thành hai phần lớn

Phần 1: Trích xuất văn bản từ hình ảnhMình đã xử lý phần này bằng Apple Shortcuts để tự động chuyển ảnh chụp thành dạng text. Phần này trước đây đã được mình thử nghiệm, nên tính khả thi cao và không cần tốn thêm thời gian “chứng minh” nữa.

Phần 2: Bóc tách & tra từĐây là linh hồn của SnapVocab. Sau khi có text, mình tiến hành phân tích, tách từ — rồi cuối cùng là tra cứu nghĩa và lưu lại thông tin.

2. Tư duy nền tảng khi tạo prototype với AI

Khá trùng hợp, đúng lúc này mình đang học khoá AI Prototyping của Sơn Võ, nơi Sơn chia sẻ cách tận dụng AI để build prototype hay thậm chí là MVP. Song song với việc xác định userflow, mình áp dụng những gì học được từ khóa học của Sơn, với các keyword then chốt:

PRD (Product Requirement Document) là trái timXây dựng 1 PRD tốt ngay từ đầu sẽ giúp mình định hướng và kiểm soát tốt quá trình build Prototype với AI.

Roadmap – kim chỉ namSau khi để AI “nạp” đủ thông tin, nó có thể bị “ngáo” nếu không được nhắc nhở liên tục. Việc có một roadmap cụ thể buộc AI phải bám sát mục tiêu ban đầu, tránh sinh ra những ý tưởng quá lan man.

ERD (Entity Relationship Diagram) – xương sống của backendViệc chốt ERD ngay từ đầu giúp hạn chế rủi ro phải refactor nặng về sau, đặc biệt là khi snapshot data của người dùng đã nhiều.

Chia để trịThay vì ôm đồm mọi thứ cùng lúc, hãy chọn cách chia toàn bộ dự án thành nhiều phiên bản (version), và trong mỗi phiên bản lại tiếp tục “chẻ” thành các bước (step) cụ thể. Điều này giúp kiểm soát tốt từng giai đoạn, hạn chế rủi ro khi thêm tính năng mới hoặc tăng độ phức tạp.

3. Bắt tay xây Prototype với Lovable

1. Xây dựng PRD

Mình bắt đầu bằng việc brainstorm với Claude, đưa cho nó userflow và ý tưởng ban đầu, kèm theo một template PRD mình mong muốn. Claude đã giúp mình chỉnh sửa và hoàn thiện PRD với các mục tiêu, tính năng, và userflow chi tiết.

Ghi chú: PRD không cần quá hoàn hảo, nhưng phải đủ rõ ràng để AI hiểu được mình muốn gì.

2. Thiết kế UI với Lovable

Sau khi có PRD, mình nhập nó vào Lovable và bùm! Bất ngờ với bản UI đầu tiên khá ổn áp. Lovable không chỉ tạo ra giao diện mà còn hiểu được flow của ứng dụng mình muốn xây dựng.

Một tip nhỏ: Sau khi có UI đầu tiên, mình đã nạp PRD vào phần Knowledge Base trên Lovable. Điều này giúp nó luôn nhớ và bám sát PRD, hạn chế việc “em đi xa quá em đi xa tôi quá”.

Version UI đầu tiên được tạo ra bởi Lovable.

3. Kiểm soát quá trình

Mình luôn bắt Lovable viết lại roadmap và liệt kê những thứ nó đã làm được sau mỗi phiên làm việc. Điều này giúp cả mình và AI không bị lạc khỏi mục tiêu ban đầu.

Sau vài lần prompt, mình đã có bản UI version 1 khá ưng ý. UI có đầy đủ các tính năng chính:

• 1 ô để nhập văn bản cần tra cứu
• Tính năng cho phép tách văn bản thành từng từ riêng biệt
• Người dùng có thể chọn các từ vựng cần tra cứu
• Hệ thống trả về nghĩa của từ, kèm các chỉ số đánh giá mức độ ghi nhớ của từ

4. Thiết kế database với Supabase

Để có cơ sở dữ liệu, mình nhờ Claude đề xuất mô hình ERD phù hợp với PRD đã có. Claude đã đưa ra một thiết kế với các bảng chính:

• users: Thông tin người dùng
• words: Danh sách từ vựng
• user_words: Mối quan hệ giữa người dùng và từ vựng

Có hai cách để tạo database trên Supabase:

• Để Lovable tự tạo theo ERD được cung cấp
• Tự tạo trên Supabase

Vì giới hạn số lượt message trong 1 ngày của Lovable, mình quyết định nhờ Claude tạo sẵn câu lệnh SQL, rồi mình tự chạy trên Supabase. Sau đó chỉ việc kết nối Lovable với Supabase và bảo nó follow theo những thứ đã có sẵn. Chiến thuật này giúp tiết kiệm được kha khá lượt chat với Lovable!

5. Kết nối API từ điển

Sau khi đã có UI và database, mình cần một API từ điển để tra nghĩa. Lại một lần nữa, Claude giúp mình tìm API miễn phí phù hợp: https://api.dictionaryapi.dev

API này có nhiều ưu điểm:

• Miễn phí và không cần key
• Có file audio cho phát âm
• Cung cấp đầy đủ thông tin về loại từ, định nghĩa, ví dụ…

Ở bước này, mình yêu cầu Lovable thực hiện kết nối với API này, lấy nghĩa của từ và lưu vào database trên Supabase.

Kết quả và kế hoạch triển khai tiếp theo

Đây là demo những tính năng mình đã làm xong trong giai đoạn 1. Bước tiếp theo sẽ triển khai tính năng Đăng nhập/Đăng ký người dùng.

Để bạn dễ dàng theo dõi hành trình xây dựng SnapVocab từ đầu, mình sẽ luôn cập nhật các bài viết liên quan tại đây:

• Bài mở đầu: SnapVocab #1 – Mở đầu
• Bài hiện tại: SnapVocab #2: Đi sâu vào quy trình & phác thảo Prototype với AI

(Danh sách này sẽ được cập nhật liên tục mỗi khi có bài viết mới.)

Cùng đồng hành với mình nhé!

Mỗi ngày, khi SnapVocab có thêm một bước tiến mới, mình sẽ đều chia sẻ lại quá trình, những khó khăn gặp phải và cách mình giải quyết chúng.

Nếu bạn cũng đang gặp vấn đề tương tự khi đọc sách ngoại ngữ, hoặc đơn giản là tò mò về cách xây dựng một sản phẩm từ con số 0, hãy đồng hành cùng mình nhé!

Xuất phát điểm

Chuyện là mình quyết tâm đọc 1 quyển sách tiếng Anh trong năm nay, cơ mà với vốn từ vựng ít ỏi mình có thì đúng là trắc trở. Mình đọc sách trên Kindle – và Kindle đã có từ điển sẵn nhưng…

Hãy tưởng tượng bạn đang đọc một đoạn văn có 7-8 từ mới. Mỗi lần gặp từ lạ, bạn phải:

1. Dừng lại
2. Tap vào từ
3. Tra nghĩa (nhiều khi còn lòi ra thêm 1 đống từ vựng mới nữa..)
4. Cố gắng hiểu trong ngữ cảnh
5. Quay lại đoạn văn
6. … và lặp lại quy trình này nhiều lần

Chưa kể, Kindle không hỗ trợ tốt từ điển Anh-Việt =.=.

Sau khoảng gần chục lần như vậy, flow đọc của mình hoàn toàn bị đứt đoạn. Mình tự hỏi liệu có thể tối ưu hóa quá trình này không?

Từ những vấn đề đó, mình hình dung về một giải pháp lý tưởng: chỉ cần chụp màn hình, app sẽ tự động bóc tách từ vựng, tra nghĩa nhanh chóng, và lưu trữ thông minh để mình dễ dàng ôn tập sau này.

Ý tưởng giải pháp

Từ nhu cầu cụ thể, mình bắt đầu phác thảo một workflow đơn giản cho SnapVocab:

• Chụp màn hình trang đang đọc
• Tự động nhận diện & bóc tách text
• Highlight các từ mới
• Tra cứu và trả về ý nghĩa của các từ
• Lưu lại từ vựng + context để ôn tập về sau

Công cụ học tập có thể bổ sung ở Phase 2

• Flashcard
• Spaced repetition
• Track learning progress

Next focus:

Xây dựng Prototype để kiểm chứng tính khả năng của ý tưởng trên.

Để bạn dễ dàng theo dõi hành trình xây dựng SnapVocab từ đầu, mình sẽ luôn cập nhật các bài viết liên quan tại đây:

• Bài hiện tại: SnapVocab #1 – Mở đầu
• SnapVocab #2: Đi sâu vào quy trình & phác thảo Prototype với AI

(Danh sách này sẽ được cập nhật liên tục mỗi khi có bài viết mới.)