Đây là bài tổng hợp cuối module, ráp lại toàn bộ kiến thức đã học (tool cốt lõi, xác thực, cách dùng trên từng client) thành một quy trình end-to-end mà bạn có thể áp dụng ngay cho công việc thật: một epic mới bắt đầu với hàng chục tài liệu rải rác trên Drive — PRD cũ, biên bản họp bổ sung, feedback từ user research, deck thuyết trình cho leadership — và việc của bạn là biến khối tài liệu hỗn loạn đó thành một spec kỹ thuật duy nhất, đáng tin cậy, có thể bắt tay code ngay.
Quy trình này chia thành ba bước rõ ràng: tìm và xếp hạng tài liệu liên quan, trích xuất và hoà giải các requirement (có thể mâu thuẫn nhau giữa các nguồn), và cuối cùng tạo ra một spec đã được review kèm liên kết ngược về tài liệu gốc để dễ audit sau này.
Tổng Quan Workflow: Từ Tìm Kiếm Tài Liệu Đến Requirement Có Thể Hành Động
Trước khi vào chi tiết từng bước, cần hiểu rõ vì sao quy trình này cần đến ba bước tách biệt thay vì gộp thành một prompt "đọc hết rồi viết spec luôn" — cách làm tưởng như nhanh hơn nhưng trong thực tế lại kém tin cậy hơn nhiều.
Vấn đề với cách làm "một prompt cho tất cả". Khi bạn yêu cầu agent tự tìm, tự đọc, tự tổng hợp, tự viết spec trong một lượt duy nhất, agent phải cân bằng nhiều việc khác nhau (tìm đúng tài liệu, hiểu đúng nội dung, phát hiện mâu thuẫn, viết văn bản có cấu trúc) trong cùng một chuỗi suy luận dài — sai sót ở bước tìm kiếm (bỏ sót một tài liệu quan trọng, hoặc đọc nhầm bản cũ) sẽ lan sang toàn bộ kết quả cuối mà bạn khó phát hiện, vì bạn chỉ nhìn thấy sản phẩm cuối cùng, không thấy được các bước trung gian agent đã làm.
Lý do tách thành ba bước có checkpoint. Mỗi bước tạo ra một sản phẩm trung gian bạn có thể review độc lập trước khi cho agent tiếp tục: danh sách tài liệu đã xếp hạng (bước 1), bảng requirement đã hoà giải kèm cảnh báo mâu thuẫn (bước 2), rồi mới tới spec hoàn chỉnh (bước 3). Cách này giống với nguyên tắc "review từng PR nhỏ" hơn là "review một PR khổng lồ gộp cả tháng code" — sai sót được bắt sớm, ở đúng bước gây ra nó, và effort sửa lại nhỏ hơn rất nhiều so với việc phát hiện sai ở bước cuối rồi phải làm lại từ đầu.
Công cụ dùng trong workflow này. Toàn bộ ví dụ dưới đây dùng chung bộ tool Google Drive MCP đã giới thiệu ở đầu module (gdrive_search, gdrive_list_files, gdrive_read_file), có thể chạy trên bất kỳ client nào bạn đã cấu hình — Claude Code, Gemini CLI, OpenCode hay Cursor — vì bản chất tool và prompt không phụ thuộc vào client, chỉ khác nhau ở cách khai báo config đã nói ở các bài trước.
Mẹo: Trước khi bắt đầu quy trình ba bước, hãy hỏi rõ với product owner hoặc lead của epic: "Có tài liệu nào chắc chắn KHÔNG nên đưa vào spec (ví dụ ý tưởng đã bị bỏ, hoặc bản draft cũ không còn giá trị)?" Việc loại trừ chủ động này giúp bước 1 (tìm kiếm) không bị nhiễu bởi tài liệu đã lỗi thời nhưng vẫn còn tồn tại trên Drive.
Bước 1: Tìm Kiếm Và Xếp Hạng Tài Liệu Liên Quan Trên Drive
Mục tiêu của bước này không phải là đọc hết nội dung, mà là xây một danh sách candidate đã được xếp hạng độ liên quan và độ mới, để bạn (con người) duyệt qua và loại bỏ những gì rõ ràng không cần thiết trước khi giao cho agent đọc sâu ở bước 2.
Tìm trên Google Drive tất cả file (Docs, Sheets, Slides, PDF) có
liên quan tới epic "Loyalty Tier Upgrade" — dùng các từ khoá:
"loyalty tier", "membership upgrade", "tier benefits", "điểm thành viên".
Tìm cả trong folder "Product / Loyalty" và tìm rộng trên toàn Drive
vì có thể có tài liệu cũ không được tổ chức đúng folder.
Với mỗi file tìm được, liệt kê: tên file, mimeType, modifiedTime,
và một dòng preview ngắn (nếu tool trả về được) để tôi hình dung
sơ bộ nội dung. Sắp xếp theo modifiedTime giảm dần.
Agent sẽ gọi gdrive_search với nhiều biến thể từ khoá (cả tiếng Anh và tiếng Việt, vì công ty bạn có thể pha trộn cả hai ngôn ngữ trong tài liệu), gộp kết quả lại và loại trùng theo fileId. Đây là lúc bạn — con người — cần trực tiếp duyệt qua danh sách, vì agent không biết tài liệu nào đã "hết hạn" về mặt nghiệp vụ dù vẫn còn tồn tại trên Drive.
Sau khi có danh sách, thu hẹp lại rõ ràng trước khi qua bước tiếp theo:
Từ danh sách trên, loại bỏ 3 file sau vì đã lỗi thời (tôi confirm
với product owner): "Loyalty Ideas - Brainstorm (old)",
"Tier System v0 (deprecated)", "Old Points Calculation Draft".
Với các file còn lại, xếp vào 2 nhóm: "Nguồn chính" (PRD, design
doc chính thức) và "Nguồn bổ sung" (meeting note, feedback, deck
thuyết trình) — vì nguồn chính nên được ưu tiên khi có mâu thuẫn
ở bước sau.
Việc phân nhóm "nguồn chính" và "nguồn bổ sung" ngay ở bước 1 là chuẩn bị quan trọng cho bước 2 — khi phát hiện mâu thuẫn giữa hai tài liệu, bạn cần biết ngay tài liệu nào nên được tin tưởng hơn mà không phải dừng lại tra cứu giữa chừng.
Mẹo: Luôn tìm rộng trên toàn Drive kèm với tìm trong folder cụ thể, đừng chỉ giới hạn theo folder — rất nhiều tài liệu quan trọng (đặc biệt các file được tạo trong buổi họp nhanh, "quick note") thường nằm sai chỗ do người tạo không cẩn thận về việc tổ chức folder, và bạn sẽ bỏ sót requirement quan trọng nếu chỉ tìm đúng theo cây thư mục "chuẩn".
Bước 2: Trích Xuất, Loại Trùng Và Hòa Giải Requirement Xung Đột
Đây là bước phức tạp nhất về mặt suy luận, vì tài liệu business viết ở nhiều thời điểm khác nhau, bởi nhiều người khác nhau, gần như luôn có ít nhất vài điểm không khớp nhau — việc của agent là làm rõ những điểm đó ra, không phải tự âm thầm chọn một phiên bản và bỏ qua phiên bản khác.
Đọc toàn bộ nội dung các file trong nhóm "Nguồn chính" đã xác định
ở bước trước. Với mỗi file, trích ra danh sách requirement liên
quan tới: điều kiện lên hạng, benefit theo từng hạng, và cách tính
điểm. Ghi rõ nguồn (tên file) cho mỗi requirement.
Sau đó đọc các file trong nhóm "Nguồn bổ sung", làm tương tự.
Cuối cùng, tổng hợp lại theo 3 chủ đề (điều kiện lên hạng, benefit,
cách tính điểm), và với mỗi chủ đề:
- Nếu tất cả nguồn đồng thuận: ghi thành một requirement duy nhất,
trích nguồn từ file mới nhất.
- Nếu có mâu thuẫn giữa nguồn chính và nguồn bổ sung: ưu tiên nguồn
chính, nhưng vẫn ghi rõ nguồn bổ sung nói khác thế nào — không
âm thầm bỏ qua.
- Nếu mâu thuẫn giữa hai nguồn chính với nhau (cả hai đều là PRD
chính thức): đánh dấu [CẦN CONFIRM VỚI PRODUCT OWNER], không tự
quyết định bên nào đúng.
Kết quả của bước này nên là một bảng requirement rõ ràng, mỗi dòng có cột nguồn và cột trạng thái (đồng thuận / ưu tiên nguồn chính / cần confirm). Đây chính là sản phẩm trung gian quan trọng nhất của toàn quy trình — bạn dành thời gian review kỹ bảng này hơn là review spec cuối, vì spec cuối chỉ là văn bản hoá lại đúng những gì đã được xác nhận ở bước này.
Với các requirement được đánh dấu [CẦN CONFIRM VỚI PRODUCT OWNER],
soạn sẵn một email/message ngắn liệt kê rõ từng điểm mâu thuẫn,
kèm trích dẫn nguyên văn từ hai tài liệu, để tôi gửi trực tiếp cho
product owner xin quyết định cuối.
Yêu cầu agent soạn sẵn nội dung hỏi lại, thay vì chỉ báo "có mâu thuẫn", giúp bạn tiết kiệm thời gian đáng kể — bạn chỉ cần đọc, chỉnh nhẹ văn phong, và gửi đi, thay vì phải tự tổng hợp lại từ đầu bảng mâu thuẫn agent đã tìm ra.
Mẹo: Không bao giờ để agent tự quyết định "chọn phiên bản nào đúng" khi hai nguồn cùng cấp độ tin cậy (ví dụ cả hai đều là PRD chính thức) mâu thuẫn nhau. Luôn yêu cầu agent trả quyết định đó về cho người có thẩm quyền nghiệp vụ — vai trò của AI ở bước này là làm rõ vấn đề nhanh và đầy đủ, không phải thay thế người ra quyết định.
Bước 3: Tạo Spec Đã Review Và Link Ngược Về Tài Liệu Gốc
Sau khi bảng requirement ở bước 2 đã được bạn (và product owner, với các điểm cần confirm) chốt lại, bước cuối là chuyển hoá thành một spec kỹ thuật hoàn chỉnh, có cấu trúc chuẩn để dev bắt tay code, kèm liên kết ngược về tài liệu gốc để ai đọc sau này cũng tra cứu được nguồn.
Dựa vào bảng requirement đã được confirm (tôi đã cập nhật trạng
thái các dòng "CẦN CONFIRM" thành quyết định cuối), viết technical
spec theo cấu trúc:
1. Overview — 2-3 câu tóm tắt mục tiêu epic
2. Functional Requirements — dạng bullet, mỗi bullet có ID (FR-01,
FR-02...), kèm link Drive tới tài liệu nguồn (dùng webViewLink
lấy được từ gdrive_search/gdrive_read_file)
3. Data Model — nếu tài liệu nguồn có nhắc tới cấu trúc dữ liệu
(ví dụ bảng tính điểm, điều kiện hạng), thể hiện lại dưới dạng
bảng hoặc pseudo-schema
4. Out of Scope — những điểm được nhắc trong tài liệu gốc nhưng
product owner đã quyết định không làm ở phase này
5. Open Questions còn lại (nếu có, sau khi đã confirm hết các
mâu thuẫn chính)
Lưu vào file specs/loyalty-tier-upgrade.md trong repo hiện tại.
Việc yêu cầu link webViewLink ngược về file Drive gốc cho mỗi requirement là chi tiết nhỏ nhưng có giá trị lớn về lâu dài — sáu tháng sau khi có ai hỏi "requirement FR-07 lấy từ đâu ra", bạn (hoặc bất kỳ ai đọc spec) chỉ cần click link, không cần lục lại trí nhớ hay hỏi vòng quanh team.
Bước cuối cùng, luôn nên có một lượt agent tự rà soát lại chính spec nó vừa viết, đối chiếu với bảng requirement gốc để bắt các lỗi rơi rớt trong quá trình viết văn xuôi:
Đọc lại file specs/loyalty-tier-upgrade.md vừa tạo, đối chiếu từng
Functional Requirement với bảng requirement gốc đã confirm. Liệt
kê rõ nếu có requirement nào bị thiếu, bị diễn giải sai ý nghĩa
so với bảng gốc, hoặc bị gộp nhầm hai requirement khác nhau thành một.
Bước rà soát này thường phát hiện ra một vài chỗ agent vô tình làm mượt văn phong tới mức làm sai lệch nhẹ ý nghĩa gốc — hiện tượng khá phổ biến khi agent chuyển từ bảng dữ liệu sang văn xuôi có cấu trúc, và luôn đáng để dành thêm một lượt kiểm tra trước khi coi spec là bản final gửi cho team dev.
Mẹo: Luôn giữ lại bảng requirement trung gian (kết quả bước 2) như một artifact riêng trong repo (ví dụ
specs/loyalty-tier-upgrade.requirements-source.md), song song với spec cuối cùng. Khi có tranh luận về việc "spec có đúng ý ban đầu không" trong tương lai, bảng nguồn này là bằng chứng để đối chiếu, độc lập với cách spec cuối đã được viết lại thành văn xuôi.
Mẹo Và Lưu Ý Thực Chiến
Vài điều rút ra sau khi áp dụng quy trình ba bước này cho nhiều epic thực tế ở các team sản phẩm khác nhau:
- Quy trình này tốn nhiều lượt tương tác hơn cách làm "một prompt cho tất cả", nhưng tổng thời gian thực tế (bao gồm cả thời gian bạn phải sửa sai sau đó) lại ngắn hơn — vì sai sót được bắt ở đúng bước gây ra nó, không lan tràn sang bước sau.
- Với epic nhỏ (dưới 5 tài liệu nguồn), có thể gộp bước 1 và bước 2 lại nếu bạn tự tin đã biết rõ tài liệu nào liên quan từ đầu — quy trình ba bước phát huy giá trị rõ nhất khi số tài liệu nguồn lớn (trên 10-15 file) hoặc khi có nhiều người viết tài liệu ở các thời điểm khác nhau.
- Luôn lưu lại toàn bộ prompt đã dùng cho epic đó (ví dụ trong một file
docs/epics/loyalty-tier-upgrade/prompts-log.md) — epic sau tương tự có thể tái sử dụng gần như nguyên vẹn bộ prompt này, chỉ cần đổi tên epic và từ khoá tìm kiếm.
Mẹo: Sau khi hoàn thành một epic theo quy trình này, dành 10 phút viết lại prompt đã dùng thành một template chung (thay các tên riêng bằng biến placeholder như
{EPIC_NAME},{KEYWORDS}) và lưu vào một thư mục playbook chung của team. Qua vài epic, bạn sẽ có một bộ playbook Drive MCP trưởng thành, giúp người mới trong team áp dụng ngay quy trình này mà không cần học lại từ đầu.