Đây là bài thực hành tổng hợp (capstone) của module Prompt Engineering. Thay vì học thêm lý thuyết mới, bạn sẽ áp dụng toàn bộ những gì đã học ở các bài trước — concise prompt design, output shaping, few-shot vs zero-shot, chain-of-thought (CoT) optimization và prompt template — vào 8 tình huống prompt thực tế, trải đều các vai trò: kỹ sư phần mềm, QA, và product manager. Mỗi exercise đi theo cùng một khuôn: một prompt "BEFORE" dài dòng như bạn thường thấy trong công việc thực tế, phân tích những điểm gây lãng phí token, một prompt "AFTER" đã được nén lại, và ước tính mức tiết kiệm. Mục tiêu không chỉ là làm ngắn prompt — mà là làm ngắn đúng cách, không đánh đổi chất lượng output.

Quy trình Compression (The Compression Process)

Trước khi vào các exercise, hãy thống nhất quy trình 5 bước mà bạn sẽ lặp lại cho từng prompt. Đây là quy trình chuẩn nên áp dụng bất cứ khi nào bạn tối ưu một prompt đang chạy production, không riêng gì bài tập này.

1. Baseline & đo lường (Baseline & Measure). Trước khi sửa bất cứ điều gì, chạy prompt gốc và ghi lại ba số: số token input, số token output, và một đánh giá chất lượng (pass/fail theo rubric, hoặc điểm số nếu có LLM-as-judge). Không có baseline, bạn không thể chứng minh việc nén có hiệu quả hay không — bạn chỉ đang "cảm thấy" nó ngắn hơn.
2. Xác định nhóm lãng phí (Identify Waste Categories). Đọc lại prompt và gán nhãn cho từng câu/đoạn vào một trong các nhóm lãng phí phổ biến: (a) role framing (thiết lập vai trò cho model) dài dòng ("You are a world-class expert with 20 years of experience..."), (b) lặp lại instruction dưới nhiều hình thức khác nhau, (c) ví dụ dư thừa hoặc quá dài so với mức cần thiết, (d) thiếu ràng buộc output format khiến model phải "đoán" và thường trả lời dài hơn cần, (e) disclaimer/caveat không cần thiết, (f) yêu cầu giải thích/suy luận chi tiết khi task không cần CoT.
3. Cắt & cấu trúc lại (Cut & Restructure). Xóa hoặc gộp theo từng nhóm đã xác định ở bước 2. Ưu tiên: xóa trước, viết lại sau. Chuyển các đoạn văn xuôi thành danh sách gạch đầu dòng hoặc bảng khi liệt kê nhiều điều kiện. Thay thế mô tả output bằng schema cụ thể (JSON, XML tag, hoặc bảng markdown).
4. Kiểm chứng chất lượng không tụt (Validate No Regression). Chạy prompt "AFTER" trên cùng tập input test (ít nhất 5-10 case đại diện, bao gồm edge case) và so sánh output với baseline. Nếu chất lượng giảm, quay lại bước 3 — thường là bạn đã cắt nhầm một ràng buộc quan trọng chứ không phải một câu dư thừa.
5. Đo lại & ghi nhận (Re-measure & Record Savings). Đo token input/output của phiên bản mới, tính % giảm, và lưu lại cả hai phiên bản (before/after) kèm số liệu vào một nơi có quản lý phiên bản (versioned) — ví dụ file .md trong git hoặc prompt registry — để nhóm có thể tham khảo và không "vô tình" quay lại bản dài dòng sau này.

Mẹo: Luôn giữ lại phiên bản BEFORE trong git history hoặc changelog của prompt. Khi model nền tảng (base model) được nâng cấp, đôi khi một số ràng buộc bạn từng thêm vào để "ép" model tuân thủ không còn cần thiết nữa — nhưng bạn chỉ biết điều đó nếu còn bản gốc để so sánh lại.

Exercise 1: Customer Support Ticket Classifier

Bối cảnh: Một prompt được engineer viết để phân loại ticket hỗ trợ khách hàng vào các nhóm (billing, technical, account, other) và gán mức độ ưu tiên.

BEFORE:

You are an extremely experienced and highly skilled customer support operations expert who has worked at top-tier SaaS companies for over 15 years and has classified literally millions of support tickets with perfect accuracy. Your job today is to carefully and thoughtfully read through the customer support ticket that I am about to give you, and then classify it appropriately.

Please take your time to really think about this. First, read the entire ticket carefully from start to finish. Then, think about what the customer might really be asking about, even if they didn't state it directly. Consider the tone of the message as well, since tone can sometimes indicate urgency even when the customer doesn't explicitly say the issue is urgent.

Once you've thought about it, please classify the ticket into one of the following categories: Billing, Technical, Account, or Other. Please also assign a priority level of Low, Medium, High, or Urgent based on your judgment of how important and time-sensitive the issue is.

It's very important that you get this right because our support team relies on this classification to route tickets to the correct department, so please double check your answer before giving it to me. Also, please make sure to explain your reasoning in detail so that the support team can understand why you classified it the way you did, and please format your response nicely so it's easy to read, maybe with some headers or bullet points if that seems appropriate to you.

Here is the ticket:
"{{ticket_text}}"

Thank you so much for your help with this, I really appreciate it!

Phân tích lãng phí token: Prompt này chứa gần như đủ mọi lỗi kinh điển đã học ở các bài trước.

• Role framing quá đà: "extremely experienced... 15 years... millions of tickets with perfect accuracy" — không có nghiên cứu nào cho thấy role-play dài giúp phân loại chính xác hơn một role ngắn gọn nêu đúng vai trò cần thiết. Đây thuần là chi phí token không sinh ra giá trị.
• Hướng dẫn tư duy dư thừa (unnecessary CoT): Task này là phân loại — một tác vụ đơn giản, xác định rõ (well-defined), không cần model "suy nghĩ cẩn thận từ đầu đến cuối" hay "cân nhắc về tone". Yêu cầu suy luận sâu cho task đơn giản chỉ làm tăng token output mà không tăng độ chính xác đáng kể (đã học ở bài CoT optimization: CoT chỉ đáng giá khi task có nhiều bước suy luận).
• Thiếu ràng buộc output format ngay từ đầu, lại yêu cầu format "tùy model tự quyết": "format your response nicely... maybe with some headers or bullet points if that seems appropriate" — câu này vừa dư thừa vừa nguy hiểm, vì để model tự chọn cấu trúc khiến output không đồng nhất giữa các lần gọi, gây khó khăn khi downstream parse kết quả.
• Yêu cầu giải thích chi tiết không cần thiết: Với hệ thống tự động routing ticket, downstream code chỉ cần category + priority ở dạng có thể parse được. Yêu cầu "explain your reasoning in detail" tạo ra output dài gấp nhiều lần so với việc chỉ cần trả nhãn.
• Câu cảm ơn, disclaimer xã giao: "Thank you so much... I really appreciate it" không ảnh hưởng đến chất lượng model nhưng tốn token mỗi lần gọi — với hệ thống gọi hàng chục nghìn ticket/ngày, đây là chi phí tích lũy đáng kể.

AFTER:

Classify the support ticket below. Output only valid JSON, no extra text.

Schema:
{"category": "billing"|"technical"|"account"|"other", "priority": "low"|"medium"|"high"|"urgent"}

Ticket: "{{ticket_text}}"

Ước tính tiết kiệm token: BEFORE ~ 290 token (chưa tính nội dung ticket). AFTER ~ 45 token. Giảm khoảng 84%. Vì đây là tác vụ chạy hàng loạt (batch), mức giảm này nhân với số lượng ticket sẽ tạo ra khoản tiết kiệm chi phí rất lớn theo tháng.

Mẹo: Với các prompt chạy ở tần suất cao (high-volume, tự động, không có người đọc trực tiếp câu trả lời), hãy luôn hỏi: "Ai là consumer cuối của output này — con người hay code?" Nếu là code, cắt bỏ toàn bộ phần giải thích và chỉ giữ schema output mà hệ thống cần parse.

Exercise 2: Code Documentation Generator

Bối cảnh: Prompt dùng để sinh docstring/comment cho một function trong codebase, tích hợp vào pipeline CI hoặc tool nội bộ.

BEFORE:

I need you to act as a senior software engineer with deep expertise in writing clear, professional, and comprehensive code documentation. You have written documentation for major open source projects and you understand exactly what makes documentation useful versus what makes it cluttered and unhelpful.

I am going to give you a function written in one of several possible programming languages (it could be Python, JavaScript, TypeScript, Java, Go, or another language - you should be able to figure out the language from the syntax). Your task is to generate high-quality documentation for this function.

When writing the documentation, please make sure to include:
1. A clear description of what the function does, written in a way that's easy to understand
2. A description of every single parameter, including its type if you can infer it, and what it represents
3. A description of the return value, including its type
4. Any exceptions or errors that the function might throw or raise, if applicable
5. If you think it would be helpful, you can also include a usage example showing how someone might call this function

Please format the documentation using the appropriate convention for the language (for example, JSDoc for JavaScript/TypeScript, docstrings for Python, Javadoc for Java, etc.) since this will be automatically inserted into the codebase and needs to follow language conventions.

Please also make sure not to just restate the function name in the description - actually explain what the code is doing at a meaningful level, but don't go overboard with excessive detail either, just aim for something a competent developer would find useful and not annoying to read.

Here is the function:
{{code_snippet}}

Phân tích lãng phí token: Prompt này lãng phí ở khía cạnh khác — không phải role-play quá đà mà là liệt kê lại những điều model đã "biết ngầm" dựa trên convention.

• Role framing không cần thiết cho task kỹ thuật thuần túy: Việc sinh docstring không đòi hỏi "senior engineer đã viết doc cho major open source project" — model chỉ cần biết convention của ngôn ngữ, điều này có thể nêu trực tiếp mà không cần câu chuyện nền.
• Giải thích quá trình nhận diện ngôn ngữ: Đoạn "it could be Python, JavaScript... you should be able to figure out the language from the syntax" là dư thừa — model luôn tự nhận diện ngôn ngữ từ syntax mà không cần được nhắc, đây là năng lực mặc định.
• Danh sách 5 mục dùng văn xuôi lồng số, có thể nén thành cấu trúc gọn hơn: Nội dung 5 điểm là hợp lý và cần giữ, nhưng cách viết dài dòng ("A clear description of what the function does, written in a way that's easy to understand") có thể rút ngắn thành từ khóa mà không mất ý nghĩa.
• Đoạn hướng dẫn "không thái quá, không quá chán": "don't go overboard with excessive detail either, just aim for something a competent developer would find useful and not annoying to read" — ý tưởng đúng, nhưng diễn đạt vòng vo. Có thể nén thành một tính từ: "concise".
• Thiếu ví dụ định dạng ngay trong prompt (dùng few-shot rất ngắn thay vì mô tả bằng lời): Việc mô tả bằng câu chữ "format the documentation using the appropriate convention for the language" tốn nhiều token hơn là chỉ định rõ format cho 1-2 ngôn ngữ phổ biến nhất trong codebase của bạn (nếu biết trước ngôn ngữ chủ đạo).

AFTER:

Generate documentation for this function using the language's standard doc-comment convention (JSDoc, docstring, Javadoc, etc.). Include: description, each parameter (name, type, purpose), return value, exceptions if any. Concise, no example unless the function's usage isn't obvious from its signature.

{{code_snippet}}

Ước tính tiết kiệm token: BEFORE ~ 300 token. AFTER ~ 55 token. Giảm khoảng 82%. Vì prompt này chạy trên mỗi function trong một pull request (có thể vài chục lần/PR), mức nén này giảm đáng kể chi phí CI.

Mẹo: Khi output cần theo một convention đã được tiêu chuẩn hóa rộng rãi (JSDoc, Javadoc, PEP 257...), chỉ cần gọi tên convention thay vì diễn giải lại nó — model đã được train trên hàng triệu ví dụ của các convention này.

Exercise 3: Sprint Planning Assistant for Product Managers

Bối cảnh: Product manager dùng prompt để nhờ AI hỗ trợ sắp xếp backlog thành sprint tiếp theo, dựa trên capacity của team và độ ưu tiên.

BEFORE:

Hi! I'm a product manager and I need some help planning our upcoming two-week sprint. Let me give you some context first so you understand our situation properly.

Our team is a cross-functional agile team consisting of 5 engineers and 1 QA engineer. We work in two-week sprints and we use story points to estimate effort, following a modified Fibonacci scale (1, 2, 3, 5, 8, 13). Historically, our team's velocity has been around 34 story points per sprint, though it has varied somewhat between 28 and 40 points depending on holidays, engineers being out sick, or unexpected production issues that pull people away from planned work.

I'm going to give you a list of backlog items below, each with a story point estimate and a priority label (P0, P1, P2, or P3, where P0 is the most urgent/critical). I would like you to help me figure out which items we should include in the upcoming sprint.

When making your recommendation, please take into account: the priority of each item, the story point estimate, any dependencies between items if mentioned, and our team's historical velocity. Please also leave a small buffer of unused capacity (maybe around 10-15%) in case something unexpected comes up during the sprint, since that happens fairly often on our team.

Please explain your reasoning for each item you include or exclude, and at the end give me a summary of the total story points planned versus our velocity target. If you exclude any P0 items, please flag this very clearly since that would need to be discussed with stakeholders.

Here is the backlog:
{{backlog_items}}

Phân tích lãng phí token: Đây là dạng prompt phổ biến của product manager — bối cảnh nghiệp vụ hợp lý, nhưng trình bày theo văn phong hội thoại (conversational) khiến token bị "pha loãng".

• Mở đầu xã giao và giải thích ngữ cảnh vai trò không ảnh hưởng đến logic: "Hi! I'm a product manager and I need some help..." — câu chào và tự giới thiệu không thay đổi cách model xử lý bài toán tối ưu hóa backlog; có thể loại bỏ hoàn toàn.
• Thông tin nền lặp lại ở dạng văn xuôi khi có thể liệt kê dạng key-value: Các thông số (team size, sprint length, velocity, scale điểm) là dữ liệu cấu trúc, nhưng bị viết thành đoạn văn dài dòng "Our team is a cross-functional agile team consisting of..." — nên chuyển thành danh sách ngắn.
• Diễn giải quá chi tiết về lý do velocity dao động: Đoạn "though it has varied somewhat between 28 and 40 points depending on holidays, engineers being out sick..." là thông tin nền không ảnh hưởng trực tiếp đến quyết định cụ thể (model chỉ cần biết số velocity mục tiêu và buffer %, không cần biết tại sao nó dao động).
• Yêu cầu giải thích cho từng item riêng lẻ khi có thể yêu cầu output có cấu trúc gọn hơn: "explain your reasoning for each item you include or exclude" tạo ra output dài; có thể thay bằng yêu cầu lý do ngắn 1 dòng/item trong bảng, thay vì đoạn văn.
• Thiếu định dạng output rõ ràng ngay từ đầu: Không có schema/bảng được chỉ định trước, khiến model tự chọn cách trình bày (thường dài hơn cần thiết).

AFTER:

Plan our next 2-week sprint. Team: 5 eng + 1 QA. Velocity target: 34 pts (range 28-40). Leave ~12% buffer.

Rank backlog items by priority (P0 highest) and dependencies, select items fitting the target. Output as a table: Item | Points | Priority | Include (Y/N) | 1-line reason. End with: total points selected, and a flagged warning if any P0 item is excluded.

Backlog:
{{backlog_items}}

Ước tính tiết kiệm token: BEFORE ~ 320 token. AFTER ~ 75 token. Giảm khoảng 77%. Với PM thường lặp lại prompt này mỗi sprint (26 lần/năm) và đôi khi chạy vài phiên bản để so sánh phương án, mức nén này giúp tiết kiệm đáng kể mà vẫn giữ đủ dữ liệu để model ra quyết định đúng.

Mẹo: Với vai trò product manager, hãy tập thói quen chuyển ngữ cảnh nghiệp vụ (business context) sang dạng key-value hoặc bảng trước khi đưa vào prompt — không phải viết như đang giải thích cho một đồng nghiệp mới vào team. Model không cần được "làm quen" với ngữ cảnh, nó chỉ cần dữ liệu để tính toán.

Exercise 4: Automated Test Case Generator (QA)

Bối cảnh: QA engineer dùng prompt để sinh test case (bao gồm edge case) từ một đặc tả (spec) chức năng, phục vụ viết test script hoặc test plan.

BEFORE:

You are a meticulous and highly experienced QA engineer who is famous for finding bugs that other people miss because you always think about edge cases that most people wouldn't even consider. You've been doing quality assurance testing for many years across many different types of applications including web apps, mobile apps, and APIs, and you have a really strong intuition for what could possibly go wrong with any given feature.

I'm going to describe a feature to you, and I want you to generate a comprehensive list of test cases for it. Please think very carefully and thoroughly about all the different ways this feature could be tested, including:
- Happy path scenarios (the normal, expected way a user would use this feature)
- Negative test cases (what happens when things go wrong, invalid input, etc.)
- Edge cases and boundary conditions (things at the very limits of what's allowed)
- Any security-related concerns if applicable
- Any performance-related concerns if applicable

For each test case, please provide: a short descriptive title, the preconditions needed before running the test, the exact steps to execute the test, and the expected result.

Please make sure your test cases are really thorough because we've had issues in the past with test coverage being too shallow and bugs slipping through to production, so I would rather have too many test cases than too few. Take your time and really think this through carefully before responding.

Feature description:
{{feature_spec}}

Phân tích lãng phí token: Prompt được viết với tâm lý "nói nhiều để model làm kỹ hơn" — một ngộ nhận phổ biến, vì chất lượng đến từ cấu trúc yêu cầu rõ ràng, không phải từ số lượng từ mô tả tính cách.

• Role-play quá dài để "truyền cảm hứng" cho model: "famous for finding bugs that other people miss... strong intuition" không có tác dụng đo lường được lên chất lượng test case; một câu ngắn nêu rõ vai trò QA và các nhóm test cần cover là đủ.
• Liệt kê 5 loại test case bằng văn xuôi giải thích lại từng loại là gì: Với các thuật ngữ tiêu chuẩn trong ngành QA (happy path, negative test, edge case, security, performance), model đã hiểu rõ định nghĩa — không cần giải thích lại "the normal, expected way a user would use this feature".
• Câu "take your time and really think this through carefully" mang tính CoT ép buộc không cần thiết: Với task sinh danh sách test case (không phải suy luận logic nhiều bước phức tạp), câu này chỉ làm tăng độ dài suy luận nội bộ và output mà không tăng coverage một cách đáng kể so với việc chỉ nêu rõ các nhóm cần cover.
• Bối cảnh về "vấn đề từng gặp trong quá khứ" không cần thiết cho model: "we've had issues in the past with test coverage being too shallow" — lý do nghiệp vụ này hợp lý để giải thích cho con người, nhưng với model chỉ cần một chỉ dẫn trực tiếp: "ưu tiên coverage rộng" là đủ, không cần câu chuyện.
• Thiếu định dạng bảng ngay từ đầu: Yêu cầu 4 trường (title, precondition, steps, expected result) được nêu bằng văn xuôi tuần tự thay vì bảng, khiến model có xu hướng trả lời theo đoạn văn dài hơn bảng có cấu trúc.

AFTER:

Generate test cases for the feature below. Cover: happy path, negative, edge/boundary, security, performance (if relevant). Be thorough — prefer over-coverage to gaps.

Output as a table: ID | Title | Precondition | Steps | Expected Result

Feature:
{{feature_spec}}

Ước tính tiết kiệm token: BEFORE ~ 300 token. AFTER ~ 55 token. Giảm khoảng 82%. Vì QA thường chạy prompt này cho mỗi feature/user story trong sprint (hàng chục lần/sprint), đây là một trong những khoản tiết kiệm dễ nhân rộng nhất trong toàn team.

Mẹo: Đừng nhầm giữa "yêu cầu thoroughness" (đầy đủ) với "viết prompt dài dòng". Bạn có thể yêu cầu model cover rộng bằng một câu ngắn ("prefer over-coverage to gaps") — độ dài của yêu cầu không quyết định độ rộng của output, cấu trúc yêu cầu mới quyết định.

Exercise 5: Security Review Prompt (Engineering)

Bối cảnh: Engineer dùng prompt để nhờ LLM review một đoạn code (ví dụ endpoint xử lý authentication) nhằm phát hiện lỗ hổng bảo mật trước khi merge.

BEFORE:

I want you to act as an elite application security expert and penetration tester with certifications like OSCP and CISSP, someone who has spent their entire career finding vulnerabilities in production code before attackers do. You have an extremely deep understanding of the OWASP Top 10, common vulnerability patterns, secure coding practices across many languages and frameworks, and you've reviewed thousands of pull requests professionally.

I'm going to show you a piece of code that handles part of our authentication flow, and I need you to review it extremely carefully for any possible security vulnerabilities. Please think step by step, very thoroughly, going through the code line by line, and consider things like: SQL injection, cross-site scripting (XSS), authentication bypass, insecure session handling, improper input validation, hardcoded secrets or credentials, insecure cryptographic practices, timing attacks, and any other OWASP-related concerns you can think of, even if they seem unlikely given the context, because I would rather be safe than sorry given that this is authentication-related code which is extremely sensitive.

For every issue you find, please explain: what the vulnerability is, why it's a problem (please explain this in detail so I can understand the actual risk), how severe you think it is (please use a scale like Critical/High/Medium/Low), and a suggested fix with example code if possible.

If you don't find any issues, please still explain what you checked for so I know the review was thorough and not just a rubber stamp.

Here's the code:
{{code_snippet}}

Phân tích lãng phí token: Đây là một prompt có nội dung nghiệp vụ đúng đắn — security review đúng là cần thoroughness — nhưng cách viết lặp đi lặp lại ý "hãy kỹ lưỡng" theo nhiều hình thức khác nhau, đây chính là dạng lãng phí token phổ biến nhất khi người viết prompt lo lắng về chất lượng.

• Role framing với danh sách chứng chỉ và thành tích không ảnh hưởng đến khả năng phát hiện lỗ hổng của model: "OSCP and CISSP... reviewed thousands of pull requests" chỉ là câu chuyện nhân thân không kiểm chứng được (narrative) và không thay đổi năng lực thực tế của model — chỉ cần nêu vai trò "security reviewer" áp dụng OWASP Top 10.
• Liệt kê lại toàn bộ danh mục OWASP bằng câu dài dòng thay vì tham chiếu ngắn: Việc gọi tên "OWASP Top 10" đã đủ để model tự triển khai các nhóm lỗ hổng liên quan (SQLi, XSS, auth bypass...) mà không cần liệt kê hết từng loại trong câu.
• Lặp lại yêu cầu "kỹ lưỡng" ba lần dưới ba cách diễn đạt khác nhau: "extremely carefully", "very thoroughly, going through the code line by line", "even if they seem unlikely... rather be safe than sorry" — cùng một ý được nhắc lại theo 3 cách, không tăng thêm độ kỹ lưỡng thực tế của model so với nêu một lần rõ ràng.
• Yêu cầu giải thích rủi ro "chi tiết" cho từng issue kèm hướng dẫn về mức độ nghiêm trọng viết thành câu dài: Có thể nén thành cấu trúc bảng cố định (severity, risk, fix) thay vì mô tả bằng lời cách trình bày.
• Yêu cầu giải thích "đã kiểm tra gì" ngay cả khi không tìm thấy lỗi: Ý này hợp lý để tránh việc review chỉ mang tính hình thức (rubber-stamp review), nhưng có thể nén xuống một câu điều kiện ngắn thay vì đoạn văn riêng.

AFTER:

Security review this authentication code against OWASP Top 10 (SQLi, XSS, auth bypass, session handling, input validation, hardcoded secrets, crypto, timing attacks). Be exhaustive — this is auth code.

For each finding, output as a table: Vulnerability | Severity (Critical/High/Medium/Low) | Risk | Suggested Fix (with code)

If no issues found, list the checks performed instead.

Code:
{{code_snippet}}

Ước tính tiết kiệm token: BEFORE ~ 330 token. AFTER ~ 80 token. Giảm khoảng 76%. Vì security review thường chạy trên nhiều file/PR, và đôi khi được gọi lặp lại (self-consistency, nhiều lần review độc lập rồi so sánh), mức nén này ảnh hưởng trực tiếp đến chi phí của cả quy trình review tự động.

Mẹo: Đối với các prompt "nhạy cảm" như security review, đừng nhầm lẫn giữa "được phép kỹ lưỡng" và "phải viết prompt dài". Bạn có thể ra lệnh "be exhaustive" bằng một cụm từ ngắn có trọng lượng ngữ nghĩa cao — model đã học được ý nghĩa của "exhaustive" mà không cần bạn diễn giải lại nó thành 3 câu.

Exercise 6: Product Requirements Summarizer

Bối cảnh: PM hoặc business analyst cần tóm tắt một tài liệu PRD (Product Requirements Document) dài thành bản tóm tắt ngắn để gửi cho stakeholder không có thời gian đọc bản đầy đủ.

BEFORE:

I have a fairly long and detailed product requirements document that I need help summarizing. The document covers a new feature we're planning to build, and it includes background context, user problems we're trying to solve, proposed solutions, technical considerations, success metrics, and a rough timeline.

What I need is for you to read through the entire document carefully and create a summary version of it that captures all of the most important points, but in a much shorter format so that busy stakeholders like our VP of Product and our engineering director can quickly understand what's being proposed without having to read the whole thing.

When creating the summary, please make sure to preserve the most critical information, such as: what problem we're solving and why it matters, what the proposed solution is at a high level, any important technical constraints or dependencies that stakeholders should be aware of, how we'll measure success, and the rough timeline including any key milestones or deadlines.

Please try to keep the summary reasonably concise - I'd say ideally somewhere in the range of maybe 200 to 300 words or so, though you can go a bit over if there's genuinely important information that needs to be included and cutting it would lose important meaning. Please organize the summary in a way that's easy to scan quickly, since these stakeholders are busy and won't have time to read dense paragraphs.

Here's the full document:
{{prd_document}}

Phân tích lãng phí token: Điểm đặc biệt của prompt này là phần input ({{prd_document}}) vốn đã rất dài — nên phần instruction "meta" (không phải nội dung cần tóm tắt) lại càng cần được nén tối đa, vì nó là overhead nhân với mọi lần chạy.

• Giải thích lại nội dung tài liệu trước khi giao việc: "The document covers a new feature... background context, user problems... technical considerations, success metrics, and a rough timeline" — đây là mô tả những gì có trong input, nhưng model sẽ tự đọc và thấy nội dung đó khi nhận document, không cần được báo trước bằng lời.
• Giải thích lý do cần tóm tắt (đối tượng đọc là ai, vì sao họ bận): "so that busy stakeholders like our VP of Product... won't have time to read dense paragraphs" là ngữ cảnh nghiệp vụ hợp lý cho con người đọc prompt, nhưng có thể nén thành một cụm ngắn "for time-constrained executives" mà vẫn giữ đủ tín hiệu định hướng văn phong.
• Liệt kê các mục cần giữ lại bằng câu dài, lặp cấu trúc "what... how... any...": 5 mục cần giữ là hợp lý và cần thiết, nhưng có thể chuyển thành danh sách từ khóa ngắn thay vì câu hoàn chỉnh.
• Chỉ định độ dài mơ hồ, có điều kiện ngoại lệ dài dòng: "somewhere in the range of maybe 200 to 300 words or so, though you can go a bit over if..." — nên chốt một con số rõ ràng (ví dụ "≤250 words") vì giới hạn mơ hồ khiến model không có mục tiêu rõ để tối ưu độ dài, dễ dẫn đến output dài hơn cần thiết.
• Yêu cầu "dễ scan" diễn đạt bằng câu văn thay vì chỉ định format cụ thể: Có thể thay bằng chỉ định trực tiếp "dùng bullet có heading" thay vì mô tả gián tiếp "organize in a way that's easy to scan quickly".

AFTER:

Summarize the PRD below for time-constrained executives (VP Product, Eng Director). Max 250 words. Use headers + bullets, not dense paragraphs.

Must include: problem & why it matters, proposed solution (high-level), key technical constraints/dependencies, success metrics, timeline & milestones.

PRD:
{{prd_document}}

Ước tính tiết kiệm token: BEFORE (phần instruction, không tính PRD) ~ 280 token. AFTER ~ 60 token. Giảm khoảng 79% cho phần overhead. Vì phần input PRD không đổi (không nén được nhiều mà không mất thông tin), khoản tiết kiệm chính nằm ở overhead — nhưng nếu prompt này chạy hàng chục PRD/quý, tổng tiết kiệm vẫn đáng kể.

Mẹo: Khi input đã dài sẵn (tài liệu, log, transcript...), đừng lãng phí thêm token để "tóm tắt trước" nội dung input bằng lời trong phần instruction. Model đọc trực tiếp input — hãy dồn ngân sách token vào việc ràng buộc output (độ dài, cấu trúc, nội dung bắt buộc) vì đó là phần bạn kiểm soát được.

Exercise 7: Agentic Tool Selection Prompt (Engineering)

Bối cảnh: Prompt hệ thống (system prompt) cho một AI agent cần quyết định gọi tool nào (ví dụ: search_database, send_email, create_ticket, no_action) dựa trên yêu cầu của người dùng, trong một vòng lặp agentic.

BEFORE:

You are an intelligent AI agent that has been equipped with several tools that you can use to help accomplish tasks on behalf of the user. It is very important that you choose the correct tool for the situation, because choosing the wrong tool could result in unintended consequences, wasted resources, or a poor experience for the user.

Here are the tools that are available to you:

1. search_database - Use this tool when the user is asking a question that requires looking up information that might be stored in our internal database, such as customer records, order history, or product information. Only use this when you genuinely need to look something up; don't use it if you already know the answer or if the question doesn't require database access.

2. send_email - Use this tool when the user has explicitly asked you to send an email to someone, or when the workflow clearly requires notifying someone via email as a necessary step. Be very careful with this tool because sending an email is an action that has real-world consequences and cannot be undone, so please only use it when you are confident it's the right thing to do and you have all the necessary information (recipient, subject, and body content).

3. create_ticket - Use this tool when the user is reporting a problem or requesting something that should be tracked as a formal support ticket or task, such as a bug report or a feature request. Make sure you have enough information about the issue before creating the ticket, including a clear description of the problem.

4. no_action - Use this when none of the above tools are appropriate, for example when the user is just asking a general question that you can answer directly from your own knowledge, or when you need to ask a clarifying question before you can proceed.

Before selecting a tool, please think carefully about what the user is actually trying to accomplish, and consider whether you have enough information to proceed or whether you should ask a clarifying question first. Please don't call a tool if you're not confident it's the right one - it's better to ask for clarification than to guess incorrectly.

Once you've decided, please output your decision along with the reasoning behind why you chose that particular tool over the others.

User request: {{user_message}}

Phân tích lãng phí token: Đây là dạng prompt agentic nên phần lãng phí đến từ cả cấu trúc mô tả tool (nên là danh sách schema, không phải văn xuôi giải thích) và từ yêu cầu giải thích lý do (reasoning) không cần thiết khi hệ thống downstream chỉ cần biết tool nào được gọi với tham số gì.

• Đoạn mở đầu nhấn mạnh "hậu quả của việc chọn sai tool" mà không thêm thông tin hành động: "It is very important that you choose the correct tool... could result in unintended consequences" là một câu nhắc nhở mang tính cảm xúc, không cung cấp tiêu chí cụ thể nào để quyết định — có thể bỏ hoàn toàn vì các mô tả tool cụ thể bên dưới đã đủ để định hướng.
• Mô tả từng tool bằng đoạn văn dài, lặp cấu trúc "Use this tool when...": Với agent có nhiều tool (ở đây 4, thực tế production có thể hàng chục), mỗi tool tốn 40-60 token mô tả bằng văn xuôi; nếu chuyển sang định dạng bảng/schema ngắn, mỗi tool có thể giảm xuống 15-20 token — mức tiết kiệm này nhân theo số lượng tool, càng nhiều tool càng lãng phí nếu giữ văn xuôi.
• Cảnh báo lặp lại về rủi ro "không thể hoàn tác" cho send_email nhắc lại ý đã có trong role framing đầu bài: Ý "hậu quả thực tế, không thể hoàn tác" đã ngụ ý trong toàn bộ phần mở đầu, việc nhắc lại riêng cho send_email là dư thừa — có thể đánh dấu bằng một flag ngắn kiểu (irreversible — confirm all fields present).
• Yêu cầu output kèm "reasoning behind why you chose that particular tool": Trong một agent loop production, orchestrator code cần tool name + parameters ở dạng structured (ví dụ tool-calling API chuẩn), không cần đoạn văn giải thích — nếu cần observability/debug, nên log riêng ở tầng khác (ví dụ qua reasoning trace ẩn), không nhồi vào mỗi lần gọi.
• Câu hướng dẫn "hãy suy nghĩ cẩn thận... nên hỏi rõ hơn là đoán sai" viết thành đoạn văn xuôi dài dòng: Ý này quan trọng (ưu tiên no_action/hỏi lại khi không chắc) nhưng nên là một rule ngắn, đặt cạnh mô tả no_action thay vì một đoạn riêng.

AFTER:

You are an agent with 4 tools. Pick exactly one per turn, or none if unsure — ask a clarifying question instead.

- search_database: lookup internal data (customers, orders, products). Skip if answer already known.
- send_email(to, subject, body): only when explicitly requested or workflow requires it. Irreversible — require all 3 fields before calling.
- create_ticket(description): for bug reports / feature requests. Require a clear problem description first.
- no_action: general questions, or insufficient info — ask a clarifying question.

Rule: if uncertain which tool applies, prefer no_action and ask for clarification.

User request: {{user_message}}

Ước tính tiết kiệm token: BEFORE ~ 380 token. AFTER ~ 110 token. Giảm khoảng 71%. Vì đây là system prompt được gửi lại ở mỗi bước trong vòng lặp agentic (không chỉ một lần), mức nén ở system prompt có tác động nhân bản (multiplicative) rất lớn theo số turn — đây là một trong những nơi compression đáng đầu tư công sức nhất trong toàn bộ hệ thống agentic.

Mẹo: Với tool description trong agentic system, hãy viết như bạn viết docstring cho API, không phải như giải thích cho người mới học — súc tích, có schema tham số rõ ràng, và đặt rule ưu tiên (khi nào chọn no_action) ngay cạnh tool liên quan thay vì tách thành đoạn văn riêng ở cuối.

Exercise 8: Full Rewrite Challenge — Combined Prompt

Bối cảnh: Đây là bài tổng hợp — một prompt thực tế mà một feature team (gồm engineer, QA, PM) cùng dùng để nhờ AI review một feature request từ khâu yêu cầu đến khâu kỹ thuật, tích hợp gần như tất cả các lỗi đã thấy ở 7 exercise trước, cộng thêm vấn đề few-shot dư thừa và template không nhất quán.

BEFORE:

You are an incredibly experienced, multi-talented technical product consultant who has deep expertise across product management, software engineering, and quality assurance, having spent over a decade working with high-performing cross-functional teams at leading technology companies. Your insights are highly valued because you're able to see a feature request from every angle - the business angle, the technical angle, and the quality/testing angle - all at once.

I'm going to give you a feature request that was submitted by one of our stakeholders, and I need your comprehensive analysis of it. Please take your time and think through this very thoroughly and carefully, considering multiple perspectives before responding.

Specifically, here's what I need from you:

First, from a product management perspective, please assess whether this feature request is clearly defined, whether it addresses a real user problem, and whether the priority seems appropriate given what you know. Please explain your reasoning in detail.

Second, from an engineering perspective, please think about what the technical implementation might look like at a high level, whether there are any obvious technical risks or complexities, and roughly how complex this might be to build (you can use a rough T-shirt size like Small/Medium/Large/Extra-Large if that's helpful, or story points if you prefer).

Third, from a QA perspective, please think about what kinds of testing this feature would need, and whether there are any tricky edge cases or quality risks that the team should be aware of before starting work.

Here's an example of the kind of analysis format I'm looking for, just so you have a sense of the style and depth I want (though your actual response should of course be about the feature request I give you below, not this example):

Example feature: "Add a dark mode toggle to the settings page"
Example analysis: "From a PM perspective, this is well-defined and addresses a common accessibility/preference need, though the priority seems Medium since it's a nice-to-have rather than blocking any core workflow. From an engineering perspective, this would likely require a Medium amount of work - implementing a theme system, updating all UI components to respect it, and persisting the user's preference - I'd estimate around 8 story points. From a QA perspective, key things to test would include: toggle persistence across sessions, visual regression on every screen, and interaction with any existing accessibility settings."

Now please provide your comprehensive analysis for the following feature request, following a similar structure and level of detail as the example above, though feel free to adjust based on what's actually relevant to this specific feature:

{{feature_request}}

Please make sure your final response is well-organized, easy to read, and provides genuine actionable value to the team, since we'll be using this analysis to help decide whether and how to move forward with building this feature.

Phân tích lãng phí token: Đây là phiên bản "tổng hợp mọi lỗi" — hãy áp dụng lại toàn bộ quy trình compression 5 bước ở đầu bài để xử lý.

• Role framing "đa năng" dài dòng kết hợp 3 vai trò khác nhau vào một đoạn văn: "multi-talented technical product consultant... decade working with high-performing cross-functional teams" — có thể nén thành một câu chỉ rõ 3 lăng kính cần phân tích (PM, Engineering, QA) mà không cần câu chuyện nền nhân vật.
• Yêu cầu "suy nghĩ thật kỹ, từ nhiều góc nhìn" lặp lại ý đã ngụ ý trong chính cấu trúc 3 phần (First/Second/Third) phía sau: Câu "think through this very thoroughly and carefully, considering multiple perspectives" là dư thừa vì cấu trúc 3 phần liền sau đã tự nhiên buộc model phải xem xét đa góc nhìn.
• Few-shot example dài và không cần thiết cho task có cấu trúc đơn giản, rõ ràng: Đây là lỗi đặc trưng của việc lạm dụng few-shot khi zero-shot với instruction rõ ràng đã đủ (đã học ở bài few-shot vs zero-shot: few-shot đáng giá khi task có định dạng mơ hồ hoặc phong cách đặc thù khó diễn đạt bằng lời; ở đây chỉ cần liệt kê 3 góc nhìn + yêu cầu định dạng ngắn là đủ, không cần ví dụ minh họa dài hơn cả phần instruction chính).
• Mỗi góc nhìn (PM/Eng/QA) được diễn giải bằng một đoạn văn dài với nhiều câu hỏi phụ lồng nhau: Ví dụ phần Eng có 3 câu hỏi phụ ("technical implementation... obvious technical risks... roughly how complex") viết thành văn xuôi liên tục — nên tách thành các trường ngắn trong một schema/bảng.
• Câu kết yêu cầu "well-organized, easy to read, genuine actionable value" mang tính khẩu hiệu, không có ràng buộc cụ thể: Câu này không cho model biết chính xác định dạng nào là "well-organized" — nên thay bằng chỉ định format cụ thể (bảng, heading theo 3 vai trò).

AFTER:

Analyze the feature request below from 3 perspectives. Output as 3 sections with these exact headers:

## PM
Is the problem well-defined and real? Priority (P0-P3) + 1-line justification.

## Engineering
High-level approach. Risks/complexity. Size estimate (S/M/L/XL or story points).

## QA
Key test areas + trickiest edge case to watch for.

Keep each section to 2-4 sentences. Be direct — this feeds a go/no-go decision.

Feature request:
{{feature_request}}

Ước tính tiết kiệm token: BEFORE ~ 480 token (bao gồm ví dụ few-shot dài). AFTER ~ 95 token. Giảm khoảng 80%. Đây là mức giảm lớn nhất trong 8 exercise vì prompt gốc kết hợp cả role framing dài dòng, CoT dư thừa, few-shot không cần thiết, và thiếu output schema — bốn lỗi cộng dồn cho một tỷ lệ nén rất cao.

Mẹo: Khi một prompt "phình to" theo thời gian vì nhiều người góp ý thêm vào ("thêm ví dụ cho rõ", "thêm câu nhắc kỹ hơn"...), hãy coi đó là dấu hiệu cần một lần compression toàn diện theo quy trình 5 bước, thay vì tiếp tục vá thêm câu chữ — càng vá, mức lãng phí càng cộng dồn theo cấp số cộng, không tự triệt tiêu nhau.

Tổng kết: Các kỹ thuật Compression đã áp dụng

Bảng dưới đây tổng hợp kỹ thuật chính từ mỗi topic của module đã được vận dụng vào từng exercise, giúp bạn nhìn lại toàn cảnh và biết nên tra cứu lại phần lý thuyết nào khi gặp lỗi tương tự trong công việc thực tế.

Nhìn vào bảng, có một quy luật chung xuất hiện lặp lại: phần lớn lãng phí token nằm ở role framing dài dòng và thiếu output schema, chứ không phải ở nội dung nghiệp vụ cần truyền đạt. Ngược lại, CoT và few-shot chỉ nên cắt khi task thực sự đơn giản/định dạng rõ ràng — với Exercise 5 (security review), CoT tối giản vẫn được giữ lại vì task đòi hỏi suy luận nhiều bước thật sự. Đây chính là ranh giới quan trọng nhất của compression: cắt token không có giá trị, giữ lại token tạo ra chất lượng.

Mẹo: Sau khi hoàn thành 8 exercise này, hãy áp dụng ngay quy trình 5 bước vào 2-3 prompt bạn đang dùng thật trong công việc. Đo baseline, phân loại lãng phí, nén, kiểm chứng, đo lại — và ghi số liệu cụ thể (% giảm) để báo cáo lại cho team. Đây chính là cách biến kiến thức trong module này thành giá trị đo lường được, chứ không chỉ là bài tập trên giấy.