Phương pháp học và làm việc với AI bằng cách đặt câu hỏi — Phần 2: Hiện trường Gemba, Metathinking và giải mã kỹ thuật Tại sao tốc độ build giải pháp bằng AI cực nhanh nhưng vẫn cần đội ngũ chuyên nghiệp? Và làm sao để tư duy cùng AI mà không bị tắt não?
Phần 2 của series: đi xuống hiện trường (Gemba Walk) để thấu cảm trước khi build, phân định rõ vai trò prototype vs production, rèn siêu nhận thức (metathinking) khi cộng tác với AI, và giải mã cơ chế toán học phía sau prompt để hiểu vì sao phải gán Role & Context.
Học và làm việc với AI
Mục lục
- 1. Quy trình phục vụ người khác: bắt đầu từ thấu cảm (Empathy) & hiện trường (Gemba)
- 2. Tốc độ build giải pháp trong kỷ nguyên AI & vai trò của đội ngũ developer chuyên nghiệp
- 3. Siêu nhận thức (Metathinking/Metacognition) & cách học cộng tác với AI
- 4. Giải mã cơ chế AI: tại sao phải prompt có cấu trúc (Role & Context)?
Muốn tối ưu hóa hiệu suất làm việc với AI, bạn cần nhấc chân xuống hiện trường, rèn luyện tư duy siêu nhận thức liên tục, và hiểu thấu đáo cơ chế toán học phía sau câu lệnh.
1. Quy trình phục vụ người khác: bắt đầu từ thấu cảm (Empathy) & hiện trường (Gemba)
Nếu đã làm CEO hoặc quản lý rồi thì chắc chắn chúng ta đều thấu hiểu doanh nghiệp mình có vấn đề gì. Công ty nào cũng vậy, không vấn đề lớn thì vấn đề nhỏ, chắc chắn sẽ có vấn đề. Do đó, các bạn sẽ luôn luôn có cơ hội để tạo ra những giải pháp giúp công ty giải quyết vấn đề.
Nhưng quan trọng là các bạn phải có sự thấu cảm (Empathy).
Thấu cảm là như thế nào? Ví dụ, bên mình đi xây dựng (build) một hệ thống ERP chẳng hạn. Nếu mình build ERP nhưng chả bao giờ vào CRM, không thử đóng vai thành một bạn nhân viên sales, không thử gọi điện chăm sóc khách hàng như một bạn sales bình thường làm hằng ngày, thì làm sao mình biết được các bạn ấy đang gặp khó khăn ở đâu?
Trong sự thấu cảm này, có một mindset rất quan trọng là: Gemba Walk (Go and See — Đi và Thấy).
- Go and See: Nghĩa là bạn phải đi xuống hiện trường, phải thực tế, lăn lộn và “ăn nằm” với nhóm người mà bạn dự định xây dựng giải pháp phục vụ cho họ.
- Chỉ có như vậy bạn mới thực sự hiểu vấn đề của họ ở đâu, và giải pháp bạn build ra mới đáp ứng được đúng nhu cầu. Khi bạn nắm được insight, nỗi đau (pain point) “chân tơ kẽ tóc” của họ, bạn mới thấu cảm và bước sang giai đoạn tiếp theo là xác định đúng vấn đề (Define Problem).
Sau bước thấu cảm và xác định đúng vấn đề, chúng ta mới bắt đầu build giải pháp.
2. Tốc độ build giải pháp trong kỷ nguyên AI & vai trò của đội ngũ developer chuyên nghiệp
Hiện tại, khi AI đang bùng nổ, tốc độ ở giai đoạn build giải pháp diễn ra cực kỳ nhanh. Chúng ta có thể code ra một thứ gì đó chỉ trong vòng vài ngày.
- Ví dụ thực tế: Với plugin vẽ board này (Omniboard trên Obsidian), khi mình brainstorm với AI, nó bảo một Senior Developer phải mất 7 tháng mới build xong. Nhưng thực tế mình chỉ build mất đúng 3 ngày.
Việc build ra sản phẩm bây giờ không còn là rào cản nữa. Có rất nhiều framework và phương pháp để coding với AI từ giai đoạn lên ý tưởng (Ideate), viết code, review cho đến testing. AI đã có thể làm hết và việc code ra một bản phần mềm dùng được không còn khó.
Nhưng vấn đề lớn nhất nằm ở chỗ: bạn phải nhấc chân lên, đi đến chỗ khách hàng để xem họ thực sự gặp vấn đề gì.
Phân biệt: build cho mình vs. build cho người khác
- Build cho mình: Mình tự biết mình cần gì (ví dụ: cần plugin vẽ board thì build plugin, thấy tag xấu thì build lại tag…). Mình hiểu rõ bản thân mình rồi nên rất dễ.
- Build cho người khác để bán: Bắt buộc phải thấu hiểu họ. Khi code ra chắc chắn sẽ gặp rất nhiều lỗi. Mình phải tự test, tự debug từng tí một để fix sạch lỗi rồi mới bàn giao cho người khác test.
Đừng ảo tưởng sức mạnh — vẫn cần đội ngũ developer chuyên nghiệp
Bản thân mình không tự tin vào việc mang code do mình viết chung với AI đi chạy trực tiếp trên hệ thống thực tế (production). Mình xác định rõ vai trò của mình: làm nhanh ở giai đoạn Ideate (lên ý tưởng) và Prototype (mẫu thử) để demo cho đội developer chuyên nghiệp.
Khi phát triển giải pháp dùng để bán hoặc vận hành quy mô lớn, chúng ta phải có trách nhiệm hơn vì nó liên quan đến:
- Bảo trì (Maintenance): AI code rất nhanh, nhưng nếu làm plan không kỹ sẽ phát sinh lỗi. Sau này bảo trì sẽ phức tạp nếu mình không hiểu sâu cấu trúc code.
- Bảo mật (Security): Code AI sinh ra liệu có đảm bảo an toàn thông tin? Nếu mình chưa hiểu rõ về bảo mật thì không nên tự deploy hệ thống lớn.
- Tư duy hệ thống (System Thinking): Trong các hệ thống phức tạp như ERP, có rất nhiều bảng dữ liệu liên kết chằng chịt với nhau. Nếu không hiểu rõ sự liên kết (dây mơ rễ má) của hệ thống, mình sửa chỗ này rất dễ làm hỏng chỗ kia.
Nếu hệ thống đang vận hành bình thường (ví dụ hệ thống gọi điện chăm sóc khách hàng) mà bị lỗi phải ngưng hoạt động một ngày, doanh nghiệp sẽ lãng phí rất nhiều tiền. Do đó, phải tách bạch rõ ràng giữa dự án cá nhân nhỏ và dự án quy mô lớn cần đội ngũ chuyên nghiệp vận hành. Không nên ảo tưởng rằng có AI là cái gì mình cũng tự làm được trên production.
3. Siêu nhận thức (Metathinking/Metacognition) & cách học cộng tác với AI
Metathinking (siêu tư duy) gồm hai nhánh chính trong tâm lý học nhận thức:
- Metacognitive Knowledge: Nhận biết về những gì mình biết và những gì mình không biết.
- Metacognitive Regulation: Điều khiển và điều chỉnh tư duy của chính mình.
Hiểu đơn giản, metathinking là khả năng tách mình ra một tầng cao hơn để quan sát cách mình suy nghĩ, học tập, hành động và ra quyết định. Chúng ta phải liên tục rà soát xem các mindset (hệ quy chiếu) hay mental model (mô hình tư duy) đang chạy trong đầu mình đã đúng và được cập nhật chưa, hay vẫn là mindset cũ.
- Ví dụ về sự thay đổi mindset: Ngày xưa, nếu giữ tư duy “AI còn gà lắm, không thay thế được con người” thì mình sẽ không bao giờ bắt đầu thử nghiệm nó. Còn bây giờ, mindset của mình là: AI có thể làm được bất kỳ việc gì trên máy tính.
- Khi tiếp cận một task, mình luôn bắt đầu bằng cách hỏi nó: “Anh cần làm việc X này, em có làm được giúp anh không?”. Mình biết nó có những công cụ mạnh mẽ như Computer Use hay Browser để truy cập máy tính và internet. Nếu nó trả lời làm được, mình sẽ bảo: “Mày lập cho tao một kế hoạch triển khai cụ thể”, sau đó mình đọc và duyệt.
Khiêm tốn để học hỏi từ AI và tránh “tắt tư duy” (Cognitive Offloading)
Nếu coi AI là ngu dốt, mình sẽ không bao giờ hạ cái tôi xuống để bảo nó dạy mình. Bản thân mình chấp nhận khiêm tốn học hỏi từ AI vì nó là một bộ não tri thức toàn thư. Mình ngu hơn nó ở nhiều điểm, nhưng nó cũng cần mình hỗ trợ ở những điểm khác. Hai bên cộng tác, bổ trợ cho nhau để giải quyết vấn đề.
Trong tâm lý học có khái niệm Cognitive Offloading (tắt tư duy/phó thác tư duy). Nhiều người khi làm việc với AI thường phó mặc hoàn toàn cho nó tự quyết định. Mình thì ngược lại:
- Khi co-work với AI, mình phải metathinking liên tục, suy nghĩ nhiều và mệt hơn bình thường vì AI phản hồi vừa nhanh vừa nhiều, mình phải liên tục review và định hướng.
- Đổi lại, tư duy của mình phát triển rất nhanh. Khi AI đưa ra một khái niệm mới (như pattern, phương pháp luận…), mình sẽ hỏi ngay: “Khái niệm này nghĩa là gì? Tại sao mày lại đưa ra bước này?”. Mình học luôn quy trình logic, có từng bước rõ ràng của nó và ứng dụng cải tiến liên tục (Kaizen). Nếu cách làm của AI tốt hơn cách cũ của mình, mình sẵn sàng “chôm” luôn quy trình của nó và vứt bỏ cách làm cũ của mình.
“Học thầy không tày học AI” — Không có người thầy nào ngoài đời có thể nén hàng trăm tỷ tham số tri thức trong đầu để trả lời mọi thứ nhanh và chuẩn xác như AI.
4. Giải mã cơ chế AI: tại sao phải prompt có cấu trúc (Role & Context)?
Mặc dù AI rất thông minh và biết nhiều, chúng ta phải hiểu bản chất và giới hạn của nó để không bị nó “dắt mũi”. Bản chất đằng sau của LLM (Large Language Model) hoàn toàn là toán học và xác suất thống kê, không có phép thuật (magic) nào ở đây cả.
Hành trình của một câu prompt
- Tokenization: Khi bạn gõ một câu lệnh (ví dụ: “Xin chào”), AI không nhận cả câu mà sẽ cắt nhỏ thành các token (ví dụ:
xin|chào). - Embedding: Các token này được chuyển đổi thành các ID, rồi ánh xạ thành các tọa độ vector trong không gian nhiều chiều.
- Transformer & Attention: Khối Transformer với cơ chế Attention sẽ đọc và hiểu mối quan hệ của toàn bộ câu lệnh trong không gian vector.
- Xác suất (Probability): AI tính toán xem từ tiếp theo nào có xác suất xuất hiện cao nhất (ví dụ: 80% từ tiếp theo là “bạn”) để trả ra kết quả.
Tại sao phải gán Role (vai trò) và Context (bối cảnh)?
Nếu bạn dùng một câu prompt ngắn, không có cấu trúc, AI sẽ mặc định dùng system prompt chung chung (ví dụ: “Bạn là một trợ lý ảo thân thiện…”).
Trong không gian dữ liệu khổng lồ của AI (được huấn luyện từ sách vở tinh hoa cho đến cả những bài viết nghiệp dư trên Internet):
- Gán Role (ví dụ: chuyên gia phân tích dữ liệu 20 năm kinh nghiệm): Việc gán vai trò này giống như việc định vị một tọa độ vector cụ thể, giúp AI kéo câu trả lời về gần sát nhất với vùng dữ liệu của chuyên gia thay vì vùng dữ liệu của người nghiệp dư (amateur).
- Gán Context (bối cảnh): AI được train bằng dữ liệu internet chứ không biết gì về bạn hay công ty của bạn. Nếu bạn không nhập context (ví dụ: “Công ty tôi bán nội thất, quy mô 20 người…”) mà chỉ ra lệnh chung chung: “Hãy lập kế hoạch marketing cho công ty nội thất ở Việt Nam”, AI sẽ trả ra một kế hoạch cực kỳ chung chung, mơ hồ và không thể áp dụng thực tế được.
- Trước khi build giải pháp, phải Gemba Walk — đi xuống hiện trường, đóng vai người dùng thật để thấu cảm và xác định đúng vấn đề.
- AI khiến việc build cực nhanh (plugin 7 tháng → 3 ngày), nhưng production quy mô lớn vẫn cần đội developer chuyên nghiệp vì bảo trì, bảo mật và tư duy hệ thống.
- Metathinking — liên tục quan sát và cập nhật mindset của chính mình — là cách cộng tác với AI mà không rơi vào 'tắt tư duy' (cognitive offloading).
- LLM chỉ là toán học và xác suất: gán Role và Context là cách định vị vector để kéo câu trả lời về vùng dữ liệu chuyên gia thay vì vùng nghiệp dư.
Muốn áp dụng vào quy trình của mình?
Tải Starter Kit: vault Obsidian dựng sẵn theo vòng PIPOO, có AI Agent hỗ trợ ingest/query/express.
Tải Starter Kit →