Luu Huong Tech

30/04/2026

Rãnh rỗi ở nhà muốn chia sẽ với anh em giải pháp giúp người dùng sau khi login vào app qua tài khoản google, thì mình có thể sử dụng chính tài khoản của họ để gọi gemini model sử dụng. VÀ NHƯ THẾ APP CỦA CHÚNG TA SẼ TIẾT KIỆM ĐƯỢC RẤT NHIỀU TIỀN. CŨNG NHƯ TĂNG TRẢI NGHIỆM NGƯỜI DÙNG.

So với cách truyền thống là sử dụng API key thì cách này sẽ làm tăng trải nghiệm người dùng rất nhiều. Vì giảm thiểu thời gian cho họ tạo API key cũng như giải quyết một vấn đề là NGƯỜI DÙNG PHỔ THÔNG HỌ CÓ TÂM LÝ RẤT NGẠI KHI ĐƯA CÁC THÔNG TIN BẢO MẬT CHO BÊN PHÁT TRIỂN.

repo để đây anh em rãnh thẩm nhé: https://github.com/chauvoluuhuong/use-gemini-with-oauth2-scope

20/02/2026

Nhanh, gọn, lẹ, trình bay các dạng dữ liệu khác nhau để "dạy, và làm AI hiểu bạn muốn gì" sẽ làm một application ngắn demo cụ thể cho anh em base theo a video này

Tim Berglund and the lightboard are back with an overview of Context Engineering in agentic AI. He breaks down the components that make up context (including...

04/02/2026

💬 [Thảo luận vui vẻ]
Anh em khi build agentic app (các app sử dụng AI agent) hay để ý điều gì?

Chia sẻ một chút góc nhìn cá nhân của mình 👇

---

🔹 1. AI không bao giờ đúng 100%
→ Luôn phải có bước involve con người để double check kết quả của AI.
→ Vì vậy UI/UX phải thật trực quan để giảm tối đa thời gian cho bước này.

---

🔹 2. Giảm thiểu việc sử dụng AI (nghe hơi nghịch lý nhưng đúng vậy)

Ai nói mình cổ lỗ thì mình chịu 😄
Quan điểm của mình là:

👉 Nếu bài toán giải quyết được bằng code thì:

* Code chính xác 100% (nếu bạn code đúng 😉)
* Chi phí rẻ hơn
* Chạy nhanh hơn
* Predictable hơn rất nhiều so với việc ném token vào AI rồi… cầu nguyện kết quả 😅

---

🔹 3. Phân chia agents & tools, đừng dồn hết vào một con agent

Nếu dồn hết vào một agent:

* Mỗi lần sửa system prompt là mệt
* Phải test lại đủ thứ effect dây chuyền

Cách mình hay làm:

* Tạo nhiều agent, mỗi con tập trung một nhiệm vụ
* Dùng model “xịn” cho xử lý phức tạp
* Dùng model “bình thường” cho việc đơn giản → tối ưu chi phí & thời gian

👉 Tools nếu thấy có khả năng reuse thì nên đưa về MCP (Model Context Protocol) server để:

* Nhiều agent dùng chung
* Dễ bảo trì hơn

---

🔹 4. Vector database hay context window?

Cả hai đều là cách “cho AI kiến thức”.
Context window của LLM giờ khá khủng, nên khi làm MVP nhiều người:

* Bỏ qua vector DB
* Nhét thẳng knowledge vào context window

Thực tế mình làm nhiều MVP thấy cách này cũng ổn (MVP thôi mà 🤗).
Nhưng nhớ một điều:

⚠️ Context window càng to → thông tin càng dễ bị nhiễu

Giống như nói chuyện với người:

* Nói quá nhiều → câu chuyện loãng
* Tiếp thu kém hơn

👉 Nên quan trọng nhất vẫn là:

* Xác định rõ goal của agent
* Nó thực sự cần bao nhiêu thông tin để làm việc hiệu quả

---

Anh em có thêm góc nhìn nào hay ho thì cùng chia sẻ nha 👀🍻

03/02/2026

Giới thiệu các bạn giải pháp để AI điều khiển trình duyệt web của bạn. Thay bạn click, kéo, thả, đọc, điền thông tin....

Nhờ vạy giúp tự động công việc bạn hơn. Giải pháp đến từ Google.

Bonus: Mình sẽ giới thiệu nhanh các bạn về MCP (model context protocol)

03/01/2026

Đừng chạy đua theo tính năng, phần mềm quản lý / ERP phải thích hợp với chính data của bạn, quy trình của bạn. Chúng tôi chỉ cần vài giờ để chứng minh điều đó VỚI CHÍNH DỮ LIỆU THẬT TỪ CÁC BẠN

Call now to connect with business.

31/12/2025

TẠI SAO DÂN NO DEV THƯỜNG CÓ XU HƯỚNG THỔI PHỒNG AI

Anh em thảo luận vui vẻ nhé, vì sao dân No Dev (xinh phép tạm gọi vạy cho dễ hiểu, cho các bạn vibe coding, sử dụng AI để viết tool...mà không phải là software engineer), hay có xu hướng thổi phồng AI, vibe coding, luôn kiểu AI CÓ THỂ LÀM MỌI THỨ, NHờ AI thì một dự án doanh nghiệp mất vài năm có thể hoàng thành trong vài ngày...bla bla.

Mình trước nhé, với mình dev (software developer) cơ bản là danh từ chỉ công việc phát triển phần mềm. Đã gọi là phát triển thì nó phải base trên một cái gì đó, như sử dụng library, framework. Rồi sau này thì theo trào lưu họ integrate với cloud services hay SAAS. Và hiện giờ họ cũng dùng AI nhiều vào việc phát triển phần mềm.

Vạy với mình cơ bản ai cũng có thể là dev, miễn chiu học hỏi, luôn nắm bắt xu hướng.

Nhưng tại sao so với dân No Dev họ không có xu hướng đề cao AI?

Trước hết không phải vì họ không dùng AI mà trái lại họ dùng AI nhiều hơn dân NO Dev rất nhiều, vì thực sự họ đang kiếm tiền từ việc đó :)

Vạy vì sao họ không có xu hướng thổi phồng AI ?

Ở mặc tốt thì dân No Dev thường có view end-user (góc nhìn khách hàng) tốt hơn, tức xuất phát điểm của họ thường là các pain-point đang tồn tại. Họ có thể đang làm nghề marketing, customer service.. với mong muốn làm cái gì đó tự động hơn trong công việc của mình như tự post bài, tự kiếm data khách hàng, tự gửi email...

Căn bản là họ làm tool không đơn giản vì lương mà vì họ muốn giải quyết bài toán thực của họ, hoặc những người xung quanh họ -> đây là một good point rất lớn, một người làm vì đam mê, có mục tiêu rõ ràng thì kết quả sẽ rất tốt -> thực ra có rất nhiều tool viết bằng cách vibe coding đã gặt hái rất nhiều thành công.

nhưng còn mặc xấu? vì họ chưa thấy hết tính phức tạp của phần mềm.
Bạn có thể nhìn vào một ngôi nhà và luôn trầm trồ về tính hào nhoáng của nó, nhưng hãy tin tôi, khi bạn thực sự nhìn vào cấu trúc ngôi nhà với độ phức tạp từ đo đạt, tính toán, làm nền móng, dựng cột....Thì bạn sẽ thấy AI chưa đủ thông minh để thay thế được ông kiến trúc sư đâu.

Tất nhiên sẽ có một thời điểm nào đó AI đủ sức thay ông kiến trúc sư, nhưng đó là ở tương lai. Còn hiện giờ bạn vẫn cần vị trí ông kiến trúc sư ấy.

Cá nhân mình thấy để dùng AI hiệu quả bạn phải thực sự hiểu cái bạn muốn làm, tách nhỏ bài toán ra đơn vị nhỏ nhất để AI nó đủ hiểu mà thực hiện. Và tất nhiên luôn phải review code AI để biết nó đang sai ở đâu mà chỉnh nó.

Send a message to learn more

28/11/2025

ĐÚNG YÊU CẦU THÌ DỄ - ĐÚNG NHU CẦU MỚI KHÓ

Tất cả những điều khiến một dự án phần mềm quản lý thất bại không phải vì công nghệ quá phức tạp.
Mà bởi NGAY CẢ NGƯỜI MUỐN LÀM CŨNG KHÔNG RÕ MÌNH CẦN GÌ.

Điều này dẫn đến hàng loạt hệ quả:

Bên thiết kế phần mềm KHÔNG ƯỚC LƯỢNG ĐÚNG, chọn sai nền tảng → khó mở rộng.

Yêu cầu chỉnh sửa phát sinh liên tục → CHI PHÍ TĂNG VỌT.

Nói thì dễ, LÀM SAO VƯỢT QUA ĐƯỢC MỚI KHÓ.

Một cách phổ biến là xây dựng prototype / MVP (MINIMUM VIABLE PRODUCT) như một bước kiểm thử trước khi triển khai thực tế.
Nhưng cách này lại phát sinh thêm CHI PHÍ KIỂM THỬ.

Và quan trọng hơn:
GIÁ TRỊ CỦA PHẦN MỀM QUẢN LÝ NẰM Ở KHẢ NĂNG LUÔN CHẤP NHẬN SỰ THAY ĐỔI, thích ứng với quy trình mới.

VẬY LÀM SAO ĐỂ TRUNG HOÀ TẤT CẢ?

Chúng tôi cung cấp cho bạn NỀN TẢNG ĐƠN GIẢN – LINH HOẠT, nơi chính bạn có thể tự tay xây dựng và chỉnh sửa phần mềm quản lý của mình MÀ KHÔNG CẦN BIẾT CODE.

🚀 4 bước để có phần mềm quản lý chỉ trong vài giờ:

1. TẠO & TUỲ BIẾN ĐỐI TƯỢNG QUẢN LÝ (ENTITY)
Toàn quyền chỉnh sửa thuộc tính, logic cho các đối tượng như đơn hàng, khách hàng, nhân viên…

2. PHẦN MỀM TỰ SINH GIAO DIỆN
Đầy đủ chức năng: thêm – xoá – sửa – tìm kiếm, tương ứng với từng đối tượng.

3. TÍCH HỢP DỄ DÀNG VỚI N8N WORKFLOW
Kết nối dữ liệu để tự động hoá quy trình vận hành.

4. MỞ RỘNG GIAO DIỆN VỚI HTML + AI
Nhúng thêm giao diện theo ý bạn, có hỗ trợ AI để tạo nhanh.

Tài liệu & demo miễn phí: https://automatework.io/

26/11/2025

Nhằm đáp ứng chuyên sâu, phục vụ khách hàng. G-Portal (generic portal) chuẩn bị release feature mới cho phép người dùng tự tạo các view đặc biệt, chuyên sâu dành riêng cho mình dựa trên data và API từ G-Portal

25/11/2025

Một trong những vấn đề quan trọng nhất của phần mềm quản lý là nó phải luôn đáp ứng sự thay đổi của nghiệp vụ và quy trình.

Bạn không thể cứ mỗi lần thêm một thuộc tính hay thêm một logic nào đó lại phải lệ thuộc vào đội ngũ phát triển và tiếp tục tốn thêm chi phí.

Và quan trọng nhất, chính bạn – người sử dụng – mới là người hiểu rõ quy trình nhất. Sẽ thật tuyệt nếu bạn có thể tự sửa đổi, hoặc thậm chí tự xây dựng phần mềm cho chính mình.

Đó chính là lý do vì sao chúng tôi tạo ra nền tảng low/no-code GPortal (Generic Portal) —
nơi chúng tôi cung cấp giải pháp gọn nhẹ – đơn giản – dễ dàng tích hợp với AI để xây dựng phần mềm quản lý.

📄 Gửi bạn tài liệu phần mềm: https://automatework.io/