[Blog Hài] Tôi xây dựng huấn luyện viên AI trên điện thoại để ngăn tôi lướt mạng (#1)

Tám. Tám tiếng trung bình mỗi ngày tôi dành làm zombie điện thoại.

Đó là một phần ba toàn bộ ngày của tôi biến mất mỗi ngày.

Tôi không tự hào về điều đó, tất nhiên... nhưng bây giờ tôi quản lý thời gian hàng ngày tốt hơn nhiều. (Android báo cáo tôi dùng điện thoại ít hơn 11 giờ so với tuần trước. Woo-hoo!) Từ kinh nghiệm đó, tôi thực sự không muốn quay lại con người trước kia nữa, nên tôi quyết định sử dụng những tài năng ít ỏi để tạo ra một thứ gì đó trên điện thoại của mình để nhắc nhở tôi dừng thói quen xấu này lại mỗi khi tôi lại sa vào nó

Đó là lúc dự án cá nhân này được sinh ra - một trợ lý, hay nói đúng hơn, một huấn luyện viên kỹ thuật số, để giúp tôi kiểm soát hành động khi tôi lạm dụng điện thoại. Nó sẽ quan sát những gì tôi làm trên điện thoại, theo dõi sử dụng của tôi, và can thiệp để nhắc nhở tôi về những thói quen tôi lại mắc phải. Ngoài ra, tôi là fan hâm mộ của F.R.I.D.A.Y., trợ lý mới của Tony trong Iron Man: Age of Ultron, nên nếu nó bảo tôi dừng binge-watching Netflix, tôi chắc sẽ nghe lời, haha.

Đây là một số preview từ ứng dụng của tôi:

Vậy đây là mục tiêu của tôi: xây dựng một trợ lý AI theo dõi điện thoại của tôi và bảo tôi đi "touch grass".

Lưu ý nhanh về quyền riêng tư: Đúng, một ứng dụng chụp ảnh màn hình điện thoại của bạn sẽ gây lo ngại. Đối với proof-of-concept này, tất cả các ảnh chụp màn hình được xử lý cục bộ, mã hóa khi truyền tải, và không bao giờ được lưu dưới dạng hình ảnh—chỉ lưu tóm tắt văn bản.

Dự án này sẽ được chia thành 3 dev logs, mỗi cái được đăng trên một blog riêng:

- Devlog #1: Xây dựng bằng chứng khái niệm (đây là phần này)

- Devlog #2: Dạy AI đọc và phản ứng với ngữ cảnh điện thoại phong phú

- Devlog #3: Xây dựng công cụ can thiệp và hoàn thiện tính cách "huấn luyện viên"

Devlog #1 – Xây dựng Proof of Concept

Phần 1: Lập Kế Hoạch (Phần Dễ)

"Screen Time AI Coach" cần làm gì?

1. Hiểu ngữ cảnh điện thoại – qua chụp ảnh màn hình + AI nhìn thấy

2. Giao tiếp với tôi – qua hộp thoại overlay (pop-up kiểu RPG)

3. Giống như FRIDAY – dắt dẫn, tinh sáng và thực sự hữu ích

Vậy nên yêu cầu khá súc tích! Hãy lập sơ đồ tech stack của tôi:

- GPT-4o-mini để tóm tắt ảnh chụp → văn bản

- GPT-4.1 cho tính cách FRIDAY và các phản hồi

- Android Foreground Service để hoạt động liên tục ở nền

- Media Projection API để chụp màn hình

Đây là luồng cơ bản:

Đơn giản phải không? Chụp ảnh màn hình cứ 18 giây, tóm tắt, gửi cho FRIDAY, nhận phản hồi.

Tôi nghĩ sẽ xong trong một tuần. Spoiler: Tôi đúng là bé ngây thơ.

Phần 2: Thử Thách Android Development

Thú nhận lúc này: Tôi là một full-stack web developer. Tôi chưa bao giờ chạm vào Android Studio trước dự án này.

Tôi nghĩ, "Có khác gì đâu? Cả hai đều là ứng dụng mà. Khó đến mức nào?"

Câu trả lời? Khó hơn tôi tưởng!

Tôi sẽ không đi sâu quá chi tiết vì tôi muốn blog này tập trung hơn vào hệ thống LLM, nhưng đây là những bất ngờ đáng chú ý tôi gặp phải dành cho những người am hiểu công nghệ:

Những Bất Ngờ Lớn Nhất

1. Chụp màn hình không đơn giản

- Bạn không thể đơn giản gọi code captureScreen()

- Phải đăng ký một dịch vụ MediaProjection ở cấp hệ thống

- Ngoài ra, nó yêu cầu quyền của người dùng mỗi lần ứng dụng khởi động

- Và chỉ có thể có MỘT media projection hoạt động (cái này cắn tôi sau khi cố ghi hình demo)

2. Vấn đề "Android vừa giết chết ứng dụng của tôi"

- Android tích cực giết các quá trình nền, nhưng tôi cần quá trình này tồn tại để xem người dùng đang làm gì

- Giải pháp: Foreground Service với thông báo liên tục

3. Quá nhiều quyền để bật

- Hệ thống hộp thoại overlay cũng yêu cầu quyền bổ sung từ người dùng

- (dĩ nhiên. Bạn nghĩ Android sẽ cho phép bạn hiển thị bất kỳ thứ gì lên màn hình người dùng tùy tiện?)

- Thông báo cần quyền, ghi vào bộ nhớ ngoài cần quyền, internet...

Nhưng qua tất cả những cơn đau đầu đó, đây là kiến trúc hiện tại:

(Một số thành phần bị mờ—đừng lo, chúng sẽ được tiết lộ ở Phần 3)

Sau một tuần Stack Overflow và cãi vã với hệ thống quyền của Android, cuối cùng tôi đã có ảnh chụp màn hình chảy vào OpenAI. Đến lúc dạy AI xử lý chúng.

Phần 3: Dạy FRIDAY Khi Nào Nói (và Cách Nhớ)

Trước khi đi vào chi tiết triển khai, hãy nói về cách OpenAI API hoạt động.

Hướng Dẫn API Nhanh: Không giống như website ChatGPT nơi cuộc trò chuyện tồn tại, Chat Completion API là stateless. Mỗi yêu cầu phải bao gồm *toàn bộ* lịch sử cuộc trò chuyện. Giống như nói chuyện với ai bị mất trí nhớ—bạn phải nhắc lại toàn bộ cuộc trò chuyện mỗi lần.

Bây giờ chúng ta hiểu điều đó, hãy xem các vấn đề nó tạo ra.

Vấn đề #1: Cuộc Khủng Hoảng Token $473/Ngày

Sau vài ngày lập trình, chúng ta có một prototype đang hoạt động! Đây:

Tuyệt phải không? Nhắn tin cho tôi nếu bạn tò mò về system prompt 😄.

Nhưng có một vấn đề…

Ảnh hiển thị số lượng token tăng nhanh trong nhật ký phản hồi

Ban đầu tôi có ~3.000 tokens và nó tăng ~300 tokens mỗi yêu cầu. Tần suất yêu cầu là một cứ 18 giây (200/giờ)

Thử tính toán nào:

3.000 + 3.300 + 3.600 + 3.900...

= 6.570.000 tokens/giờ

= 157.680.000 tokens/ngày

× $3 cho 1M tokens (giá GPT-4.1)

= $473/ngày

$473. Mỗi ngày. Đó là tiền THUÊ NHÀ HÀNG THÁNG của tôi. WTF— Trời... Mấy thứ này chẳng bao giờ dễ dàng cả...

Giải Pháp: Hệ Thống Bộ Nhớ Nội Bộ

Nhớ lại cách OpenAI API không có bộ nhớ chứ? Mỗi yêu cầu cần toàn bộ lịch sử cuộc trò chuyện. Khi lịch sử đó phát triển, token cũng vậy—theo cấp số nhân.

Tôi cần giới hạn lượng thông tin gửi đi mà không mất thông tin quan trọng.

Có khá nhiều cách:

1. Cắt bỏ dữ liệu không cần thiết trong lịch sử chat

2. Tóm tắt lịch sử chat quá khứ (ngữ cảnh tự nén dài hạn)

3. Chiến lược chụp ảnh tốt hơn (không chụp khi người dùng không ở nhà, ví dụ)

Tất cả đều là cách tiếp cận tốt để cuối cùng giảm kích thước yêu cầu gửi, nhưng tôi chỉ muốn tiếp tục prototyping, nên điều tôi có thể làm nhanh chóng là triển khai một bộ nhớ nội bộ.

Nói tóm lại, mỗi lần LLM phản hồi:

- Hãy để nó xem lại lịch sử trò chuyện, tìm một số thông tin đáng chú ý về người dùng, lưu vào bộ nhớ.

- Và cho mỗi yêu cầu, chỉ lấy 20 tin nhắn gần đây từ lịch sử chat.

Kết quả: Số lượng token ổn định ở **8.500-9.500 mỗi yêu cầu**

Nó đang không vướt quá 9000. Tuyệt

Điều này giảm chi phí hàng ngày dự kiến từ $473 xuống ~$25-30 (vẫn đắt cho một dự án cá nhân, nhưng có thể quản lý để test vì tôi không sử dụng nó quá nhiều, nên thực tế là $1-2 mỗi ngày).

Đây là kiến trúc được cập nhật với quản lý bộ nhớ:

Vấn đề #2: Vấn Đề Spam

Vấn đề Token Economy: ✅ Đã sửa

Vấn đề tiếp theo: FRIDAY không thể nín được.

Tưởng tượng dòng thời gian này:

- 10:00 AM – Người dùng mở YouTube

- 10:01 AM – Người dùng xem một Short về huấn luyện bồ câu

- 10:02 AM – Người dùng xem cảnh chết Iron Man (ôi, spoiler!)

- 10:03 AM – Người dùng xem một Short khác…

- 10:04 AM – Một Short khác…

- …

- 6:00 PM – Người dùng cuối cùng đóng YouTube

Liệu FRIDAY nên bình luận về mỗi Short? Đó là 480+ lần gián đoạn trong 8 giờ. Tưởng tượng FRIDAY cứ vài giây:

Khó chịu phải không? Lý tưởng nhất là lúc đầu, nó nên bình luận gì đó vui vẻ về một hoặc hai Short đầu tiên, nhưng sau đó, AI nên nhận ra thói quen binge Short của tôi, và sau một giờ, bắt đầu một cuộc trò chuyện để can thiệp.

Vậy, làm cách nào để AI nhận ra những mẫu lặp lại nhất định dựa trên bộ nhớ, dòng thời gian và lịch sử chat trong một khoảng thời gian dài?

Chà, đó là cho devlog #2 vì devlog này đã đủ dài. Nhưng tôi muốn ít nhất AI không bình luận lại những thứ lặp lại hoặc không quan trọng (như màn hình chính hoặc màn hình trống).

Giải Pháp: Dạy FRIDAY Bỏ Qua Những Thứ Nhàm Chán

Bản sửa lỗi thực sự đơn giản nhưng cần một chút thử sai để điều chỉnh đúng cách. Chỉ cần thêm những quy tắc này vào system prompt:

[RULES – RESPONSE BEHAVIOR]
* Tránh lặp lại.  
* KHÔNG bình luận về những sự kiện tầm thường hoặc tĩnh (ví dụ: màn hình chính, điện thoại nhàn rỗi, màn hình trống). 
* Nếu quan sát hiện tại về cơ bản giống với một quan sát gần đây, bỏ qua hoàn toàn.
* Bạn chỉ phản ứng khi tình huống đáng giá insight hoặc khi có điều gì đó mới xảy ra.

Kết quả: FRIDAY bây giờ im lặng trong những hoạt động lặp lại và chỉ nói lên khi có điều gì đó đáng nói.

FRIDAY không nói gì khi tôi idle trên màn hình chat trong 3+ phút

Hoàn hảo. Bây giờ AI hiểu khi nào để nói chuyện.

Phần 4: Proof-of-Concept Demo

Sau hai tuần phát triển, đây là những gì FRIDAY có thể làm:

Demo 1: Xem Tôi Xem Phim

FRIDAY bình luận khi tôi binge-watch CinemaWins:

Điểm tốt: Tính cách cảm thấy đúng – hóm hỉnh nhưng không khó chịu.

Cần cải thiện: Đôi khi bỏ lỡ ngữ cảnh từ chính nội dung video.

Demo 2: Gọi Ra Nghiện YouTube Shorts Của Tôi

FRIDAY can thiệp sau khi phát hiện một mẫu:

Điểm tốt: Thực sự khiến tôi dừng lại và suy nghĩ (đó là mục tiêu).

Cần cải thiện: Thời gian can thiệp vẫn còn tùy tiện – cần nhận diện thói quen thông minh hơn.

Tóm Tắt Lại:

Ở đây chúng ta có một prototype có thể:

- A: Hiểu ngữ cảnh điện thoại qua chụp ảnh màn hình, mặc dù các bản tóm tắt chắc chắn cần mạnh mẽ hơn trong tương lai nếu chúng ta muốn nắm bắt tất cả thông tin và sắc thái

- B: Giao tiếp với người dùng qua hệ thống hộp thoại overlay.

- C: Nói như FRIDAY, bình luận về nội dung màn hình điện thoại của tôi và cảnh báo tôi không xem bất kỳ nội dung short nào.

Trong Devlog #2, tôi sẽ giải quyết vấn đề khó: dạy FRIDAY thực sự hiểu thói quen của tôi trong nhiều giờ và ngày, không chỉ trong vài giây. Điều này có nghĩa:

- Trích xuất ngữ cảnh tốt hơn từ ảnh chụp màn hình

- Bộ nhớ dài hạn và khớp mẫu

- Thời gian can thiệp thông minh hơn (không chỉ "bạn đã ở trên YouTube một lúc")

Mục tiêu: Biến FRIDAY từ một nhà bình luận thích giễu từ một huấn luyện viên thay đổi hành vi thực sự.

Liệu xây dựng một AI để giải quyết chứng nghiện YouTube của tôi có quá mức ko? Haha, chắc vậy.

Qua dự án này tôi đã học được rất nhiều về Android dev, quản lý LLM context và prompt engineering, nên tôi không có ko có hối hận gì.

Cảm ơn vì đã đọc!

— Jackal