
Bắt đầu dùng Claude Code cho công việc BA
Đầu năm 2025, AI bắt đầu phổ biến rộng - không còn là chuyện của riêng một nhóm tech-savvy nào nữa. Thời điểm đó mình đang làm BA ở LHD. Công ty bắt đầu ứn...
May 2026
✍️ Hana · 🗓️ Tháng 5/2026 📚 Series: Bước đầu trở thành BA thời AI 🔢 Order: 8
Antigravity IDE mở file workload dashboard tổng hợp 156 task của 6 product
Thói quen của mình bây giờ không phải mở mail hay Slack trước. Mở Antigravity trước, đó là IDE mình dùng chính cả ngày. Trên đó mình có một file dashboard tổng hợp toàn bộ task của 6 product mình đang theo: VKS, vDB, AI_INNOVATION, Task_Operation, Task_Support, Agentbase. 156 task, 137 cái đã xong, còn 8 cái đang chạy và 11 cái chưa đụng tới. Nhìn một phát là biết hôm nay nên lo cái gì.
Cái hay không phải là con số. Cái hay là mình không phải tự gõ lại con số đó. AI đọc task log, tổng hợp, tính phần trăm từng product, rồi mình review. Việc của BA cả ngày là đọc tài liệu, viết requirement, trả lời dev, theo dõi tiến độ. Mình kéo gần hết mấy việc đó về một chỗ: cái editor đang mở sẵn trên màn hình.
Bài này mình kể cách mình dùng AI ngay trên IDE để xử lý workload hằng ngày, không phải mở 5 cái tab tool khác nhau.
Hồi đầu mình cũng dùng AI kiểu mở một tab chat riêng, copy đoạn tài liệu dán vào, hỏi, rồi copy kết quả dán ngược lại file. Mỗi lần như vậy là một vòng context-switch: tài liệu ở một chỗ, chat ở chỗ khác, file output ở chỗ thứ ba. Một ngày mình làm cái vòng đó vài chục lần.
Khi AI nằm thẳng trong IDE thì khác hẳn. Tài liệu, requirement, source code, file note meeting đều nằm trong cùng một workspace. AI đọc được hết, hiểu được context xung quanh, và mình không phải copy đi copy lại. Ba lý do mình thấy rõ nhất:
Thứ nhất, AI có context thật. Nó thấy cả folder dự án, không phải chỉ đoạn text mình dán vào. Khi mình hỏi "user story này có mâu thuẫn với spec cũ không", nó đọc được spec cũ luôn.
Thứ hai, output ra đúng chỗ. AI viết user story thì ghi thẳng vào file .md trong dự án, không phải để mình copy thủ công.
Thứ ba, mọi thứ versioned. File trong IDE thường đi kèm git. Mình thấy được hôm qua AI sửa gì, mình sửa gì, rollback được nếu cần.
Bốn công cụ BA dùng để gọi AI: VS Code, Antigravity, Claude Code và Cursor, trong đó Antigravity là cái dùng chính
Nói thẳng luôn: cái mình mở mỗi ngày là Antigravity. Nó là IDE thiên về agentic, tức là mình giao nguyên một việc nhiều bước cho AI tự chạy rồi báo lại, thay vì hỏi từng câu một. Hợp đúng kiểu việc BA: tổng hợp report, dọn lại cấu trúc folder tài liệu, cập nhật dashboard task. Mình để nó chạy, mình review.
Ba cái còn lại mình giới thiệu qua để bạn biết đường chọn, vì mỗi người một thói quen:
VS Code là editor phổ thông nhất, BA non-tech cũng cài được trong 5 phút. Cài thêm extension AI là có chat ngay trong sidebar. Đây là chỗ mình hay khuyên người mới bắt đầu vì nhẹ và quen thuộc.
Claude Code chạy trong terminal. Nghe có vẻ khó với BA, nhưng thực ra mình chỉ gõ tiếng Việt yêu cầu, nó làm. Mạnh cho việc viết tài liệu dài và chạy workflow. Mình từng kể kỹ trong bài bắt đầu với Claude Code.
Cursor là editor sinh ra cho AI ngay từ đầu, gõ lệnh tự nhiên rất mượt, đọc nhiều file một lúc tốt. Hợp khi cần AI rà qua nhiều file requirement cùng lúc để soi mâu thuẫn.
Điểm chung của cả bốn: AI nằm cạnh file, không nằm trong một tab riêng. Chọn cái nào không quan trọng bằng việc bắt đầu dùng một cái.
Đây là phần mình thấy đáng tiền nhất. Liệt kê đúng những việc mình làm hằng ngày.
Một spec 30 trang, hay một file note meeting 8 người nói lung tung, mình quăng cho AI và hỏi: "tóm tắt giúp mình 5 ý chính, và liệt kê những chỗ chưa rõ cần hỏi lại". Cái mình cần không phải bản tóm tắt đẹp, mà là danh sách câu hỏi mở còn treo. AI giỏi nhặt ra mấy chỗ đó.
Với meeting, mình paste transcript vào và hỏi:
Đọc transcript này. Liệt kê:
1. Các quyết định đã chốt
2. Các action item, kèm người chịu trách nhiệm
3. Những điểm còn tranh luận chưa ngã ngũ
Ba mục đó là đủ để mình viết minh meeting note mà không nghe lại bản ghi.
Mình mô tả tính năng bằng tiếng Việt, AI dựng khung user story theo format team mình đang dùng. Quan trọng là phải nói rõ format, nếu không nó viết kiểu chung chung.
Viết user story cho tính năng "user reset mật khẩu qua email".
Format: As a / I want / So that.
Kèm Acceptance Criteria viết theo Gherkin (Given/When/Then),
cover cả happy path, sai email, và token hết hạn.
AI lo phần khung và mấy case dễ quên (token hết hạn, gửi mail trùng). Mình lo phần context của team: business rule nào đã chốt, ràng buộc nào legal đã duyệt. Mình có viết kỹ hơn về cách phối hợp này trong bài cách mình viết PRD cùng AI.
Cái này mình thích nhất. Trước khi đưa spec cho dev, mình nhờ AI đóng vai dev khó tính đọc qua:
Đọc spec này như một dev sắp implement.
Liệt kê những chỗ mơ hồ, thiếu thông tin, hoặc có thể hiểu nhiều cách.
Hỏi lại mình những câu mà một dev sẽ hỏi.
Nó nhặt ra những chỗ mình viết "nhanh" mà không nói nhanh là bao nhiêu ms, hay những flow mình quên mất nhánh lỗi. Tìm được mấy lỗ hổng đó trước khi vào sprint planning đỡ hơn nhiều so với để dev phát hiện giữa sprint.
Từ Acceptance Criteria, mình nhờ AI sinh bộ testcase nháp: happy path, boundary, error case. Mình không đưa thẳng cho QA, mà coi đó là bản nháp để rà soát. AI ít khi quên mấy case biên (giá trị bằng 0, chuỗi rỗng, vượt giới hạn), còn mình thì lúc mệt hay quên.
Mình không code, nhưng nhiều khi cần hiểu một flow đã chạy trong hệ thống để viết requirement cho phần mới. Mình mở file source lên, hỏi AI: "đoạn này xử lý gì, input output là gì, có gọi service nào khác không". Nó giải thích bằng tiếng Việt dễ hiểu. Mình nắm được flow thật thay vì đoán. Hồi mới qua mình cũng chưa đọc được source, giờ thì nhờ AI làm phiên dịch giữa mình và code.
Khi cần một con số để confirm scope, ví dụ "có bao nhiêu user chưa verify email trong 30 ngày qua", mình mô tả bằng tiếng Việt và nhờ AI viết câu SQL:
SELECT COUNT(*)
FROM users
WHERE email_verified = false
AND created_at >= NOW() - INTERVAL '30 days';
Mình đọc lại logic, hiểu nó đang đếm gì, rồi mới chạy. Không phải để thay analyst, mà để mình tự lấy được con số nhỏ phục vụ quyết định scope mà không phải chờ ai.
Đây là phần mình mở mỗi sáng. Cái dashboard mình nói từ đầu bài trông như này:
Workload dashboard tổng hợp 156 task của 6 product, 87.8% hoàn thành
Nó không tự nhiên mà có. Đằng sau là một workflow mình để AI chạy lặp lại mỗi ngày: input vào là tài liệu, meeting note, requirement mới; AI xử lý thành task; mình review lại scope và context; rồi lên ticket; cuối cùng dashboard tự tổng hợp số liệu.
Workflow AI quản lý workload trong một ngày: input, AI xử lý, BA review, lên task, dashboard tự cập nhật
Điểm mấu chốt là mình không coi dashboard này như báo cáo phải ngồi làm. Nó là sản phẩm phụ của việc mình làm hằng ngày. Mỗi lần mình hoặc AI đụng vào task log, con số tự cập nhật. Mình chỉ mở ra nhìn, không phải ngồi tô lại bảng Excel mỗi tối thứ Sáu. Nếu muốn xem cách mình để AI chạy nguyên một workflow nhiều bước, mình kể trong bài cách mình chạy workflow bằng skill.
Nói thật, không phải lúc nào AI cũng làm đúng. Mấy nguyên tắc giúp mình đỡ "lụi" nhất:
Cho nó context trước khi hỏi. Đừng hỏi trống không "viết user story đi". Hãy chỉ rõ tính năng gì, cho ai, format nào. Câu hỏi càng cụ thể, output càng đỡ phải sửa.
Yêu cầu nó đánh dấu chỗ tự suy luận. Mình hay bảo: "chỗ nào em tự đoán thì ghi rõ [cần xác nhận]". Nhờ vậy mình biết cái gì là của AI bịa, cái gì là mình đã chốt.
Bắt nó hỏi lại thay vì đoán. Thêm một câu "nếu thiếu thông tin thì hỏi mình trước khi viết". Đỡ được mấy lần nó tự điền bừa.
Luôn đọc lại trước khi gửi đi. AI đưa mình từ 0 lên 60%, nhưng 40% còn lại, phần hiểu đúng context của team, vẫn là việc của mình.
Lưu prompt nào chạy tốt. Prompt hay thì viết lại thành mẫu để lần sau dùng lại, hoặc đóng thành skill. Mình không gõ lại từ đầu mỗi lần.
Mình từng tưởng dùng AI là cứ hỏi rồi lấy kết quả dùng luôn. Hoá ra mấy cái bẫy dưới đây ai mới dùng cũng dính, mình cũng từng dính đủ:
Tin output 100% không kiểm. AI viết trôi chảy không có nghĩa là đúng. Có lần một bản tài liệu viết bằng AI lọt vào chi tiết không tồn tại trong hệ thống, vì AI điền theo best practice chung chứ không theo dự án. Phải đọc lại.
Hỏi quá chung chung. "Viết spec cho app đặt đồ ăn" thì nhận lại một bản generic copy ở đâu cũng được. Không có context team, không dùng được.
Quăng cả tài liệu mật vào tool công cộng. Cái này nguy hiểm. Phải biết tool nào được phép đưa data nội bộ, tool nào không. Hỏi team về policy trước.
Để AI quyết thay vì đề xuất. AI gợi ý scope thì tốt, nhưng người chốt scope phải là BA. Lẫn lộn hai vai trò này là lúc bắt đầu sai.
Ngại học vì nghĩ "mình non-tech". Mình mở IDE lần đầu cũng thấy lạ. Nhưng phần lớn việc chỉ là gõ tiếng Việt yêu cầu. Cái rào cản thường là cảm giác, không phải kỹ năng.
AI không quản lý workload thay mình. Nó dọn bớt phần overhead, để mình còn sức làm phần mà chỉ BA mới làm được: hiểu đúng vấn đề và chốt đúng scope.
Lần gần nhất bạn mở một ngày làm việc bằng cách ngồi tổng hợp lại task cũ thay vì bắt tay vào việc mới, bạn thấy mất bao lâu cho cái phần "dọn dẹp" đó? Và nếu cái phần đó tự chạy mỗi sáng, bạn sẽ dành thời gian được giải phóng cho việc gì?
Bài này thuộc series "Bước đầu trở thành BA thời AI". Đọc thêm: bắt đầu với Cursor và MCP cho Figma · cách mình họp cùng AI

Đầu năm 2025, AI bắt đầu phổ biến rộng - không còn là chuyện của riêng một nhóm tech-savvy nào nữa. Thời điểm đó mình đang làm BA ở LHD. Công ty bắt đầu ứn...

Lần đầu mình nghe đến MCP là khi các anh technical chung team LHD nhắc tới trong group chat - cái group nho nhỏ tụi mình lập ra để vừa cập nhật công nghệ v...

Trong các nơi mình đã từng làm BA, LHD là nơi cho mình nhiều nhất. Không phải vì lương cao hay dự án hot - mà vì đó là nơi nhận thức của mình về nghề BA tr...