Bài viết
Giới hạn khi dùng AI chính là tham vọng của bạn: bốn chiều tốc độ, độ cao, độ sâu và độ rộng
Felix Rieseberg, engineering lead của Anthropic, chia việc "tham vọng hơn khi dùng AI" thành bốn chiều: tốc độ, độ cao, độ sâu và độ rộng. Bài viết này tổng hợp cách làm và ví dụ của ông, kèm ghi chú thực hành của riêng tôi: ra lệnh hướng theo mục tiêu, điều phối đội chuyên gia Multi-AI Agents để review chéo từ nhiều góc nhìn, nhằm nâng chất lượng công việc.
· 7 phút đọc
Trong bài "How to be more ambitious: A tutorial for humans with models", Felix Rieseberg, engineering lead của Anthropic, kể rằng mỗi khi thấy người khác dùng AI tạo ra kết quả đáng kinh ngạc, ông và những người xung quanh đều có chung một phản ứng: "Chúng ta chưa đủ tham vọng."
Cách tôi hiểu là: giới hạn khi con người dùng AI thường bị kẹt ở chính tham vọng và trí tưởng tượng của mình, chứ không phải ở mô hình.
Ông chia "tham vọng" thành bốn chiều:
- Tốc độ (Speed): cùng một việc, làm xong trong thời gian ngắn hơn.
- Độ cao (Altitude): nâng mức trừu tượng lên, nhìn vào kết quả cuối cùng thay vì một tác vụ đơn lẻ.
- Độ sâu (Depth): làm theo tiêu chuẩn, công cụ và phương pháp của các chuyên gia hàng đầu trong lĩnh vực.
- Độ rộng (Range): bước ra khỏi một lĩnh vực duy nhất, tìm lời giải liên ngành.
Kết luận trước: ra lệnh hướng mục tiêu thật chính xác, điều phối đội chuyên gia Multi-AI Agents cộng tác và review chéo từ nhiều góc nhìn, thì chất lượng công việc mới được nâng lên toàn diện.
Một: Tốc độ, cơ bản nhất và cũng ít vướng mắc nhất#
Cùng một việc, làm xong trong thời gian ngắn hơn. Felix cho rằng ai cũng đã quen với điều này nên bỏ qua luôn trong bài.
Quan điểm của tôi: tốc độ là giá trị dễ thấy nhất của AI, nhưng nếu chỉ chạy theo tốc độ thì cách cộng tác không thay đổi nhiều. Ba chiều phía sau mới thật sự tạo ra khoảng cách.
Hai: Độ cao, hỏi về "mục tiêu đằng sau mục tiêu"#
Câu hỏi cốt lõi: Kết quả tiếp theo mình thực sự muốn là gì? Mục tiêu đằng sau mục tiêu này là gì?
Các ví dụ của Felix:
- Từ sửa một Crash đến làm cho App không còn Crash. Trước đây ông nhờ Claude sửa đúng một Crash, sau đó đổi yêu cầu thành giữ App ở mức zero Crash. Để việc này chạy liên tục và tự động, trước hết ông phải đổi quy trình của mình: làm cho báo cáo Crash dễ lấy, ánh xạ phiên bản App với Git Commit, và để Claude dùng các máy Windows, macOS, Linux để tái hiện và xác minh bản sửa.
- Nâng cấp báo cáo kinh doanh hằng quý (QBR) qua ba bước:
- Dùng dữ liệu thô càng nhiều càng tốt để giải thích quý này đã thay đổi gì, vì sao và nên làm gì tiếp.
- Tìm ra 3 quyết định cấp bách nhất, viết luận điểm ủng hộ và phản đối cho từng quyết định.
- Thiết kế một cơ chế thay thế phát hiện vấn đề sớm hơn bản trình bày hằng quý, thử nghiệm bằng dữ liệu lịch sử, rồi chạy song song với quy trình hiện tại trong một quý.
Ông cũng nhắc về ranh giới: năm 2026, những mục tiêu mơ hồ kiểu "Claude, đi kiếm tiền cho tôi" vẫn chưa dùng được, nhưng ông kỳ vọng mức trừu tượng mà mô hình xử lý được sẽ ngày càng cao.
Ba: Độ sâu, theo yêu cầu của các chuyên gia hàng đầu trong lĩnh vực#
Cách làm của Felix:
- Dùng những công cụ mà ngành đó thực sự dùng. Mô hình thường chỉ đổi cách dùng từ chứ không đổi phương pháp, rồi đưa ra một bảng Markdown cho xong chuyện. Hãy kiên quyết yêu cầu dùng công cụ phân tích thật như cơ sở dữ liệu và mô hình thống kê.
- Đặt mục tiêu nghe có vẻ vô lý, và nói với mô hình rằng nó giải được. Ví dụ của ông: sau khi rút thời gian tải website từ 10 giây xuống 5 giây, tiếp tục yêu cầu 200 mili giây. Khi mô hình lùi bước, hãy khẳng định mục tiêu này đạt được.
- Thách thức những giả định bạn đang tin. Đưa dữ liệu thô cho mô hình và kiểm tra từ góc nhìn phản biện. Ví dụ: "Chúng ta cho rằng nguyên nhân người dùng rời bỏ là do onboarding, hãy thử tái hiện kết luận này từ dữ liệu thô."
- Tạo ra tri thức mới. Dựng mô phỏng từ Logs, tìm tín hiệu rời bỏ sớm nhất mà bạn chưa biết, rồi kiểm chứng bằng dữ liệu chưa từng thấy.
- Tìm giám khảo bên ngoài (Outside Judge). Đừng để mô hình tự chấm bài của chính nó. Tốt nhất là gắn một công cụ mà mô hình có thể tự chạy và nhận phản hồi ngay.
Nguyên tắc viết Prompt của ông: thứ cần xin là "phiên bản sâu hơn", không phải "phiên bản lớn hơn". Hãy để mô hình nói rõ chuyên gia hàng đầu sẽ làm thêm điều gì, dữ liệu gốc nhất nằm ở đâu, sẽ dùng phương pháp và công cụ nào, và ngoài mô hình hay phán đoán của bạn thì còn gì chứng minh được kết quả là đúng.
Bốn: Độ rộng, dùng động từ thay danh từ và lập đội chuyên gia#
- Động từ thay danh từ. Khái niệm này Felix trích từ The Art of Innovation. QBR không phải "một bộ slide", mà là "trong 30 phút, giúp những người bận rộn hiểu nhân quả và ra quyết định giữa sự bất định". Khi định nghĩa mục tiêu bằng động từ, bạn sẽ thấy cần năng lực của những lĩnh vực nào.
- Lập đội. Muốn làm bộ slide tốt, tìm nhà phân tích, nhà báo và biên tập viên; muốn trình bày trên sân khấu, thêm nhà thiết kế chuyển động và âm thanh. Muốn review đối kháng, tìm nhà nghiên cứu của quỹ bán khống và kế toán pháp y.
- Đừng nhập vai vô nghĩa. Không phải bảo mô hình "viết bằng giọng của quỹ bán khống", mà là bảo nó thực sự thực hiện phương pháp nghiên cứu của quỹ bán khống ở một phần của công việc. Chỉ đổi giọng văn thì kết quả không tốt hơn.
Điều kiện là: mô hình phải có một máy tính cài được phần mềm, và truy cập được dữ liệu liên quan, chẳng hạn qua các trình kết nối MCP.
Năm: Ghi chú thực hành của tôi, từ "truyền dữ liệu" đến "đạt ý định"#
Phần dưới đây là phần mở rộng của riêng tôi, kết hợp kiến trúc phần mềm với thực tiễn kỹ thuật, không phải nội dung của bài gốc.
1. Jobs to be Done và Intent-Based#
- Đừng hỏi "làm gì", hãy hỏi "đạt được gì". Thiết kế không nên dừng ở pipeline truyền dữ liệu thụ động như
generate_deck_pdf(), mà nên nâng lên thành ý định chuyển trạng thái như resolve_leadership_uncertainty_and_commit_budget().
- Định nghĩa loss function thực sự. Chỉ đòi sản phẩm thì mô hình sẽ sinh ra những lời rỗng tuếch trông hoàn hảo; đòi giải quyết sự bất định của quyết định thì mô hình và Sub-agent mới chủ động vá các lỗ hổng logic và ranh giới rủi ro.
2. Khám phá thì phát tán, nghiệm thu thì hội tụ#
- Khi khám phá, phát tán trước để tìm khả năng, rồi mới hội tụ.
- Khi nghiệm thu, đừng phát tán nữa. Tránh những câu hỏi không có ranh giới như "việc này còn làm được cách nào khác?", chỉ nhận về những câu trả lời chung chung.
- Viết rõ phạm vi mục tiêu, ràng buộc và công cụ xác minh khách quan (script test cụ thể, ngưỡng chỉ số kinh doanh), để đội Multi-Agent chạy stress test trong một khung tập trung và giao kết quả chất lượng cao.
Tóm tắt ghi chú#
- Hướng mục tiêu: động từ thay danh từ. Giao kết quả giải quyết được vấn đề, chứ không phải sản phẩm chỉ để nộp cho xong.
- Khám phá và hội tụ: khi khám phá thì phát tán để tìm khả năng, khi nghiệm thu thì hội tụ nghiêm ngặt để kiểm tra ranh giới.
- Tập trung vào trừu tượng: xuất phát từ câu hỏi cốt lõi, tái cấu trúc toàn bộ quy trình công việc.
- Chiều sâu chuyên gia: không chỉ bắt chước giọng điệu chuyên gia, mà buộc mô hình giải quyết vấn đề bằng công cụ và phương pháp của chuyên gia hàng đầu.
Bài gốc: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)