Đánh giá case Tencent WorkBuddy cho nghiên cứu A-share: so sánh 40+ mã, xuất HTML sang DOCX và workflow AI research thực tế hơn
Nếu bạn nhìn WorkBuddy và chỉ thấy một công cụ AI có thể viết nháp báo cáo nghiên cứu, thì có lẽ bạn đang nhìn vào lớp ít đáng chú ý nhất.
Tôi đã đọc lại bài công khai trên Tencent Cloud Developer Community về cách dùng WorkBuddy để dựng một pipeline nghiên cứu A-share. Điều đáng chú ý nhất không phải là nó "viết ra kết luận được", mà là case này nối nhiều bước nghiên cứu thành một chuỗi khá hoàn chỉnh:
- thu thập dữ liệu
- so sánh ngang nhiều mã
- tạo báo cáo nghiên cứu dài ở định dạng
HTML - chuyển
HTMLsangDOCX - tải lên knowledge base để tái sử dụng
Với người mua đang đánh giá sản phẩm, đây là tín hiệu đáng xem hơn nhiều so với một tuyên bố kiểu "AI có thể hỗ trợ analyst".
Có một ranh giới cần nói rõ ngay từ đầu:
Điều này không có nghĩa mọi đội ngũ research đều đang dùng cùng một front-end WorkBuddy, hay cùng một mô hình vận hành.
Cách diễn đạt chính xác hơn là:
Case công khai cho thấy năng lực AI và agent theo kiểu WorkBuddy của Tencent đã được đặt vào một workflow khá giống môi trường research production thật, chứ không chỉ là demo chat.
Kết luận trước
-
Tính đến ngày 29 tháng 6 năm 2026, tín hiệu công khai thuyết phục nhất của
WorkBuddycho nghiên cứu A-share không nằm ở một bước "viết báo cáo", mà nằm ở một workflow 4 phần:- Thu thập dữ liệu và nghiên cứu ban đầu
- Tạo báo cáo deep research dạng
HTML - Chuyển
HTMLsangDOCX - Tải lên knowledge base
-
Case công khai này trông gần production hơn vì có các chi tiết như:
- 3 tháng sử dụng thực tế
- 40+ mã cổ phiếu được so sánh ngang
- luồng tải knowledge base gồm 4 bước
- quản lý memory xuyên nhiều phiên
- các lỗi thực chiến như mã hóa tiếng Trung trong
DOCX, token hết hạn và connector bị ngắt
-
Nếu team của bạn đang làm:
- nghiên cứu A-share hoặc thị trường Trung Quốc
- hỗ trợ buy-side hoặc sell-side research
- theo dõi ngành
- chuẩn hóa đầu ra báo cáo
- xây knowledge base cho research
thì case này đáng tham khảo hơn một bài "AI viết research report" thông thường.
Một ranh giới nữa cũng rất quan trọng:
Các con số công khai ở đây là số liệu của chính case được công bố, không phải cam kết hiệu quả chung cho mọi team, mọi workflow hay mọi deployment của WorkBuddy.
Vì sao team research thường phản ứng mạnh với workflow AI hơn là chỉ "câu trả lời hay hơn"
Phần tốn thời gian nhất của research thường không phải là viết ra một câu kết luận sắc bén.
Nó thường là chuỗi việc như:
- gom dữ liệu nguồn
- đọc báo cáo tài chính và báo cáo cũ
- so sánh doanh nghiệp theo chiều ngang
- viết báo cáo theo cấu trúc cố định
- lưu trữ kết quả để vòng nghiên cứu sau không phải làm lại từ đầu
Nói cách khác, phần đau đầu thường không nằm ở quan điểm đầu tư tự thân. Nó nằm ở đây:
quá nhiều bước nghiên cứu rời rạc, quá nhiều định dạng, và quá ít thứ được tích lũy tự nhiên thành tri thức dùng lại cho cả team.
Vì vậy, câu hỏi tốt hơn không phải là "model này có nói hay hơn không?"
Mà là:
- workflow có chia thành bước lặp lại được không
- bước chuyển đổi định dạng có đủ ổn không
- research memory và knowledge base có thể lớn dần theo thời gian không
Bối cảnh 1: Trong research, mấu chốt không chỉ là chất lượng phân tích, mà là phân tích có nối được tới khâu giao hàng hay không
Điểm đầu tiên case công khai này làm khá đúng là nó không dừng ở câu hỏi "AI có đưa ra một góc nhìn được không?"
Thay vào đó, nó tách nhiệm vụ thành 4 giai đoạn:
- Thu thập dữ liệu và nghiên cứu ban đầu
- Tạo báo cáo nghiên cứu sâu dạng
HTML - Chuyển
HTMLsangDOCX - Tải lên knowledge base
Đó là cấu trúc rất giống thực tế.
Nhiều team research không bị chặn vì thiếu người có quan điểm. Họ bị chặn vì:
- phát hiện nằm rải rác ở nhiều phiên làm việc
- kinh nghiệm quy trình rất khó tái sử dụng
- thành phẩm cuối cùng khó trở thành tài sản chung của team
Nhìn ở mức cao, workflow công khai này đang cố giải bài toán đó.
Bối cảnh 2: So sánh 40+ mã cho thấy đây là research theo lô, không phải viết một bài đơn lẻ
Một chi tiết rất đáng xem trong case công khai là:
- so sánh ngang 40+ mã cổ phiếu
Vì sao nó quan trọng?
Vì nó cho thấy workflow này không chỉ dùng để viết note cho một công ty. Nó đang chạm vào:
- so sánh peer theo diện rộng
- nghiên cứu ngành có cấu trúc
- đầu ra theo template
Điều này đặc biệt quan trọng với A-share. Ở nhiều team thật, phần mệt nhất không phải là viết deep-dive cuối cùng. Mà là:
- sàng lọc một danh sách rộng trước
- rồi mới rút gọn xem mã nào đáng đào sâu hơn
Vậy nên tín hiệu giá trị ở đây không nhất thiết là "nó viết có giống chief analyst hay không".
Mà là:
nó có đỡ được phần groundwork lặp lại, nặng format và tốn thời gian trước khi analyst đưa ra judgment thật sự hay không.
Bối cảnh 3: Chuyển HTML sang DOCX nghe nhỏ, nhưng có thể là phần giống production nhất
Đây có thể là chi tiết bị đánh giá thấp nhất trong cả case:
- chuyển
HTMLsangDOCX
Nghe có vẻ nhỏ, nhưng đây chính là chỗ nhiều "workflow AI cho research" bị đứt.
Rất nhiều team có thể đi tới:
- một kết luận nằm trong cửa sổ chat
- một bản nháp markdown nằm ở panel bên cạnh
Nhưng tài liệu để luân chuyển chính thức thì vẫn thường phải là Word hoặc DOCX.
Nếu đoạn cuối cùng này vẫn cần người chỉnh tay, workflow chưa thật sự khép kín.
Đó là lý do việc case công khai nêu thẳng các vấn đề như sau lại khiến nó đáng tin hơn, chứ không phải kém tin hơn:
- chuyển
HTMLsangDOCX - lỗi mã hóa tiếng Trung
- token hết hạn
- connector bị ngắt
Đây đúng là kiểu vấn đề chỉ lộ ra khi workflow đã được đẩy gần hơn tới khâu giao tài liệu thật.
Theo nghĩa đó, WorkBuddy trong case này không chỉ sinh nội dung.
Nó đang đụng tới:
"last mile" nơi đầu ra research phải trở thành tài liệu có thể bàn giao.
Bối cảnh 4: Luồng tải knowledge base 4 bước quan trọng vì mục tiêu không phải một báo cáo, mà là tài sản research có thể tái sử dụng
Tín hiệu thứ hai tôi sẽ chú ý kỹ là:
- luồng tải knowledge base gồm 4 bước
Điều đó cho thấy workflow này không được thiết kế để dừng lại sau một báo cáo. Nó đang cố:
- đẩy phát hiện nghiên cứu vào knowledge base
- để công việc sau tái sử dụng phát hiện cũ
- nối memory xuyên phiên với một lớp tài sản bền hơn
Vì sao chuyện này quan trọng?
Vì nhiều team research không thật sự cần thêm "một báo cáo nữa". Họ cần:
một cách để không phải lặp lại cùng một phần groundwork mỗi khi coverage được mở lại.
Nếu đầu ra không đi vào knowledge base, AI vẫn chỉ gần với một công cụ viết dùng một lần. Nếu đầu ra có thể chảy ngược vào một kho tri thức tái sử dụng, nó bắt đầu giống:
một bàn làm việc research có khả năng tích lũy tri thức theo thời gian cho cả team.
Bối cảnh 5: Memory xuyên phiên là điều khiến research theo dõi liên tục trở nên khả thi
Case công khai cũng nhấn vào:
- quản lý memory xuyên nhiều phiên
Đây là chi tiết rất có giá trị vì nghiên cứu A-share hiếm khi là việc làm một lần rồi thôi.
Nhịp làm việc thực tế thường giống thế này:
- hôm nay xem bức tranh ngành
- ngày mai bổ sung filing
- tuần sau cập nhật valuation
- rồi về sau thêm thông báo mới, thay đổi chính sách hoặc guidance kết quả kinh doanh
Nếu hệ thống lần nào cũng bắt đầu từ số 0, phần lớn giá trị thực dụng sẽ biến mất.
Đó là lý do memory xuyên phiên quan trọng. Ở trạng thái tốt nhất, nó giúp workflow giữ được một mức liên tục nhất định quanh:
cùng watchlist, cùng tuyến ngành và cùng một tiến trình research còn dang dở.
Bối cảnh 6: Vì sao case này trông giống WorkBuddy hơn là một model chat thông thường
Từ case công khai này, lý do lớn nhất khiến nó giống WorkBuddy hơn là một khung chat model thông thường không nằm ở sức mạnh model thuần túy. Nó nằm ở hình dạng của workflow:
- nhận được file và tài liệu research
- xuất đầu ra qua nhiều định dạng
- đẩy kết quả vào knowledge base
- giữ được ngữ cảnh research qua hơn một phiên
Đó là mục tiêu rất khác với trải nghiệm chat AI thông thường.
Một model chat bình thường thường là:
- hỏi một câu
- nhận một câu trả lời
Còn case này gợi tới một thứ khác:
- khởi động một chuỗi research
- để hệ thống nối các bước research, viết nháp, chuyển đổi và tích lũy tri thức
Vì vậy, mô hình tư duy phù hợp hơn ở đây là:
một research workstation
chứ không phải:
một cửa sổ chat biết nói về cổ phiếu.
Team nào nên xem kỹ case này trước
Phù hợp để đánh giá ngay
- team làm theo dõi A-share, coverage ngành và đầu ra research chính thức
- analyst hoặc research associate phải làm nhiều peer comparison và báo cáo theo template
- team muốn biến đầu ra research thành knowledge base có thể tái sử dụng
- team thường xuyên phải chuyển nội dung research thành tài liệu bàn giao chính thức
Có thể quan sát thêm
- team chỉ làm Q&A nhẹ, một lần
- team không có cấu trúc báo cáo cố định và không có nhu cầu lưu giữ tri thức
- team không cần tính liên tục xuyên phiên
Nếu bạn muốn dựng workflow tương tự, nên xem gì trước
Nếu điều bạn thực sự quan tâm không phải "nên nhớ tên sản phẩm upstream nào", mà là làm sao ghép được workflow tương tự cho stack research của riêng mình, thì nên bắt đầu từ:
Góc nhìn thực dụng quan trọng hơn nhãn thương hiệu:
- năng lực model
- workflow research
- lớp chuyển đổi định dạng
- lớp tích lũy tri thức
Nên được xem cùng nhau, thay vì chỉ nhìn vào tên một sản phẩm.
Kết luận cuối cùng của tôi
Nếu phải gói gọn case WorkBuddy này trong một câu, đánh giá của tôi là:
Điểm đáng chú ý nhất không phải là "AI cũng viết được research report", mà là nó đã bắt đầu đi vào chuỗi công việc thật sự ngốn người của team research: nghiên cứu, sinh báo cáo, chuyển định dạng và đưa kết quả vào knowledge base.
Nếu chuỗi này chạy mượt, thứ WorkBuddy nhìn thấy không chỉ là tăng năng suất tạm thời. Nó là:
cách một đầu ra research dùng một lần có thể dần biến thành hệ thống tri thức có thể tái sử dụng cho cả team.