Skill Phân Tích Tài Liệu

Level: L4 — AI Skills (Bài 10/12)

3 tầng “làm việc với file” — nay hoàn thiện tầng thứ 3

Tầng	Bài học	Nội dung
1	L1 bài 7	Cơ chế đính kèm 1 file vào 1 tin nhắn (Vision, PDF support, Files API)
2	L3 bài 21	Cơ chế lưu trữ file bền vững trong Knowledge base của 1 Project (RAG)
3	L4 bài 38 (bài này)	Đóng gói 1 quy trình phân tích lặp lại được thành Skill — hoạt động trên file dù đến từ tầng 1 hay tầng 2

Bài này không dạy lại cách đính kèm hay lưu trữ file — chỉ dạy cách biến “phân tích tài liệu” thành 1 năng lực đóng gói, nhất quán.

1. Mục tiêu học tập

Sau bài này, bạn có thể:

• Giải thích rõ tầng thứ 3 (“quy trình”) khác tầng 1-2 (“cơ chế file”) như thế nào.
• Thiết kế 1 Skill phân tích tài liệu với quy trình nhiều bước, có kiểm tra chất lượng (feedback loop).
• Áp dụng mẫu hình “plan-validate-execute” cho tác vụ phân tích phức tạp, rủi ro cao (ví dụ: tài liệu pháp lý, hợp đồng).

2. Khái niệm cốt lõi

“Phân tích tài liệu” như 1 Skill nghĩa là gì? Đó là đóng gói 1 chuỗi bước cố định (trích xuất thông tin → tóm tắt → gắn cờ rủi ro/điểm cần chú ý → định dạng kết quả) thành 1 quy trình Claude tự áp dụng mỗi khi nhận 1 tài liệu thuộc loại đó — không quan trọng tài liệu đó tới bằng cách nào (đính kèm trực tiếp theo tầng 1, hay đã có sẵn trong Knowledge base theo tầng 2).

2 mẫu hình workflow chính thức phù hợp nhất cho tác vụ phân tích (đã học sơ lược ở bài 32, đào sâu áp dụng cụ thể ở đây):

1. Feedback loop (“validator → sửa → lặp lại”): với tác vụ cần độ chính xác cao, thêm 1 bước tự kiểm tra trước khi đưa kết quả cuối — ví dụ: “sau khi tóm tắt, đối chiếu lại từng điểm với nguyên văn, đảm bảo không suy diễn quá những gì tài liệu thực sự nói” (đây chính là kỷ luật Source Attribution Audit mà dự án AI Mastery Bible áp dụng cho mọi chapter — 1 dạng feedback loop thủ công, không phải Skill, nhưng cùng nguyên lý).
2. Plan-validate-execute: với tác vụ rủi ro cao (thay đổi nhiều điểm dữ liệu, hoặc tài liệu dài/phức tạp), Claude trước tiên tạo 1 kế hoạch có cấu trúc (danh sách các mục sẽ trích xuất), rồi validate kế hoạch đó trước khi thực thi đầy đủ, giúp bắt lỗi sớm thay vì phát hiện sai sót sau khi đã phân tích xong toàn bộ [S77].

3. Tại sao nội dung này quan trọng

Nếu không đóng gói thành Skill, mỗi lần bạn nhờ AI phân tích 1 tài liệu mới, bạn phải giải thích lại toàn bộ tiêu chí phân tích (“chú ý các điều khoản về X, bỏ qua phần Y, luôn tóm tắt theo cấu trúc Z…”) — đúng tình huống điển hình đáng đóng gói đã học ở bài 29. Đây cũng là ví dụ tốt cho thấy Skill hữu ích nhất khi áp dụng cho 1 loại tài liệu cụ thể, lặp lại (ví dụ: luôn phân tích hợp đồng thuê văn phòng cùng 1 mẫu) hơn là “phân tích tài liệu nói chung” (quá rộng, khó viết description cụ thể theo đúng nguyên tắc bài 32).

4. Cơ chế hoạt động

Khi Skill kích hoạt trên 1 tài liệu, Claude làm theo instructions đã đóng gói — không phân biệt tài liệu đó vừa được đính kèm (tầng 1) hay đã nằm sẵn trong Knowledge base 1 Project (tầng 2, bài 21). Điểm khác biệt duy nhất: nếu tài liệu tới từ Knowledge base, Claude có thể cần tìm/truy xuất nó trước qua cơ chế RAG đã học ở bài 21 — nhưng đó là bước xảy ra trước khi Skill phân tích được kích hoạt, không phải 1 phần của bản thân Skill.

5. Mental model

Tổng kết chuỗi ẩn dụ “file” xuyên 3 level: nếu bài 7 (L1) là đưa 1 tờ giấy cho chuyên gia đọc ngay, và bài 21 (L3) là để tờ giấy đó vào tủ hồ sơ cố định của văn phòng, thì bài 38 (L4) là dạy chuyên gia 1 quy trình chuẩn để đọc bất kỳ tờ giấy nào thuộc 1 loại cụ thể — dù tờ giấy đó đưa tay hay lấy từ tủ hồ sơ, quy trình đọc vẫn giống nhau.

6. Hướng dẫn từng bước

1. Chọn 1 loại tài liệu cụ thể bạn phân tích lặp lại (không phải “tài liệu nói chung”) — ví dụ: hợp đồng thuê, báo cáo tài chính hàng tháng, CV ứng viên.
2. Liệt kê các bước phân tích cố định: trích xuất mục nào, tóm tắt ra sao, gắn cờ điều gì là “cần chú ý”.
3. Xác định: tác vụ này có rủi ro cao (sai sót gây hậu quả lớn) không? Nếu có → thiết kế theo “plan-validate-execute” (mục 2); nếu tác vụ thường, độ rủi ro thấp → workflow tuyến tính đơn giản là đủ.
4. Viết SKILL.md theo đúng cấu trúc đã học (31-34): description nêu rõ loại tài liệu + khi nào dùng; instructions theo mức tự do phù hợp (bài 32) — phân tích tài liệu thường thuộc mức tự do “Cao” hoặc “Trung bình” (nhiều cách diễn đạt kết quả đều chấp nhận được), trừ khi cần định dạng output cực kỳ nghiêm ngặt.
5. Test với ít nhất 2-3 tài liệu thật thuộc đúng loại đã chọn.

7. Ví dụ thực tế

Skill dựng sẵn liên quan (bài 29): Anthropic có sẵn Skill PDF (pdf) cho các tác vụ tài liệu phổ biến [S75] — đây là ví dụ về Skill xử lý định dạng file (PDF nói chung), khác với Skill phân tích theo domain mà bài này hướng dẫn tự xây (ví dụ: phân tích hợp đồng cụ thể). 2 loại Skill này bổ sung nhau: Skill PDF xử lý việc đọc/trích xuất kỹ thuật, Skill phân tích domain (tự bạn xây) áp dụng tiêu chí đánh giá riêng của bạn lên trên nội dung đã trích xuất.

Ví dụ minh họa tự thiết kế (labeled synthesis, không phải trích nguồn) — Skill phân tích hợp đồng thuê văn phòng:

---
description: Analyzes office lease contracts and flags unusual clauses.
  Use when the user shares a lease/rental contract PDF or asks to review
  lease terms. Do NOT use for other contract types (employment,
  vendor, etc.).
---

## Instructions

1. Extract: rent amount, lease term, renewal conditions, termination
   clauses, deposit terms.
2. Compare each against standard market terms (see reference/market-norms.md).
3. Flag any clause that deviates significantly from standard terms.
4. Summarize in this format: [Key terms] → [Flags] → [Questions to ask
   landlord].
5. Before finalizing, re-check each flagged item against the original text
   to confirm it's not a misreading.

Bước 5 chính là 1 feedback loop đơn giản (đối chiếu lại nguyên văn trước khi kết luận) — áp dụng đúng nguyên tắc mục 2.

8. Prompt/template/workflow

Loại tài liệu: [cụ thể, không chung chung]
Các mục cần trích xuất: [liệt kê]
Tiêu chí gắn cờ "cần chú ý": [liệt kê]
Định dạng output mong muốn: [mô tả]
Có cần bước validate lại trước khi kết luận? [Có/Không — nếu tài liệu rủi
  ro cao, luôn chọn Có]

9. Visual hoặc diagram cần thiết

Hình 4.10 — 2 nguồn đầu vào (đính kèm L1 bài 7, Knowledge base L3 bài 21) hội tụ vào cùng 1 quy trình phân tích 5 bước.

10. Bài tập thực hành

1. Chọn 1 loại tài liệu bạn thường xuyên cần phân tích (hoặc dùng ví dụ hợp đồng thuê ở mục 7 làm bài tập giả lập).
2. Điền đầy đủ khung thiết kế ở mục 8.
3. Viết SKILL.md hoàn chỉnh, áp dụng đúng cấu trúc 31-34.
4. Thử nghiệm Skill với 1 tài liệu đính kèm trực tiếp (tầng 1) — có hoạt động đúng không?

11. Checklist

Đặt lại checklist

• Chọn đúng 1 loại tài liệu cụ thể, không phải 'tài liệu nói chung'.
• Phân biệt được vai trò của Skill (quy trình phân tích) với cơ chế file (tầng 1/2 đã học trước).
• Biết khi nào cần thêm bước validate (rủi ro cao) và khi nào không cần.
• Test được Skill với tài liệu thật.

12. Lỗi thường gặp

• Thiết kế Skill quá chung chung (“phân tích mọi loại tài liệu”) — khó viết description cụ thể, dễ kích hoạt nhầm hoặc cho kết quả không nhất quán.
• Bỏ qua bước validate cho tài liệu rủi ro cao — dẫn tới kết luận sai không bị phát hiện (bỏ sót 1 điều khoản quan trọng trong hợp đồng).
• Nhầm vai trò Skill phân tích với Skill xử lý định dạng file (như Skill PDF dựng sẵn) — 2 việc khác nhau, có thể dùng cùng lúc, không thay thế nhau.

13. Giới hạn & khi nào KHÔNG nên áp dụng

• Không áp dụng cho tài liệu chỉ phân tích 1 lần, không lặp lại — dùng Prompt/hỏi trực tiếp là đủ (bài 29).
• Bài này không dạy cách trích xuất kỹ thuật từ PDF/hình ảnh — đó thuộc phạm vi Skill dựng sẵn (pdf, docx…) hoặc cơ chế Vision/PDF support đã học ở L1 bài 7.

14. An toàn & quản trị (Safety/Governance)

Tài liệu cần phân tích (hợp đồng, báo cáo tài chính, hồ sơ ứng viên) thường chứa thông tin nhạy cảm. Áp dụng đúng nguyên tắc quản lý dữ liệu nhạy cảm đã học từ L1 bài 2, và đặc biệt lưu ý: nếu Skill có bước “so sánh với chuẩn thị trường” dùng dữ liệu bên ngoài (như reference/market-norms.md ở ví dụ mục 7), đảm bảo dữ liệu tham khảo đó không vô tình chứa thông tin của khách hàng khác bị rò rỉ chéo.

15. Best practices

1. Luôn thêm bước validate lại (feedback loop) cho tài liệu có hậu quả thật nếu phân tích sai (pháp lý, tài chính).
2. Giữ description hẹp đúng 1 loại tài liệu cụ thể — dễ viết chính xác hơn, dễ tránh kích hoạt nhầm hơn Skill “phân tích chung chung”.
3. Với tài liệu dài, cân nhắc dùng mẫu hình “domain-specific organization” (bài 33) nếu có nhiều loại điều khoản/mục cần tra cứu riêng biệt.

16. Nội dung nâng cao (không bắt buộc)

Với khối lượng phân tích lớn (ví dụ: phân tích hàng loạt hợp đồng cùng lúc), mẫu hình “plan-validate-execute” (mục 2) có thể mở rộng thêm 1 bước: tạo 1 file kế hoạch trung gian (ví dụ extraction-plan.json) liệt kê mọi tài liệu + mục cần trích xuất, validate toàn bộ kế hoạch 1 lần, rồi mới thực thi hàng loạt — giảm rủi ro sai sót lặp lại trên nhiều tài liệu cùng lúc so với xử lý từng tài liệu độc lập không có kế hoạch tổng thể.

17. Nguồn tham khảo

[S77] Skill authoring best practices, Anthropic — mẫu hình feedback loop, plan-validate-execute · [S75] Agent Skills (Overview), Anthropic — Skill PDF dựng sẵn, đối chiếu vai trò khác biệt · Dẫn chiếu (không trích dẫn mới): L1 bài 7, L3 bài 21; dự án AI Mastery Bible tự thân (Source Attribution Audit như 1 dạng feedback loop thủ công).

18. Ngày kiểm chứng

Claim kỹ thuật kiểm chứng qua nguồn Tier 1 (S75, S77) ngày 2026-07-12. Ví dụ Skill phân tích hợp đồng (mục 7) là minh họa tự thiết kế, gắn nhãn rõ không phải trích nguồn.