Kỹ thuật tài liệu hóa prompt engineering: Các mẹo thực tế để xử lý các tình huống phức tạp

Từ khóa: Prompt engineering, Tài liệu hóa, Tình huống phức tạp, Mô hình phân tầng, Nhật ký lặp lại, Đánh giá hiệu quả Tóm tắt: Khi sử dụng mô hình lớn để giải quyết các vấn đề phức tạp, việc "viết prompt" chỉ là bước đầu tiên — cách biến prompt từ "lệnh một lần" thành "tài sản tri thức có thể tái sử dụng, hợp tác và tối ưu hóa" mới là yếu tố then chốt giúp AI triển khai ổn định. Bài viết sẽ dùng phép so sánh "viết thực đơn cửa hàng trà sữa" để phân tích logic cốt lõi của tài liệu hóa prompt engineering: từ "yêu cầu mơ hồ" đến "prompt chính xác", thiết kế tài liệu phân tầng trong các tình huống phức tạp, theo dõi sự tiến hóa của prompt qua nhật ký lặp lại, kiểm tra giá trị bằng ma trận hiệu quả. Cuối cùng thông qua ví dụ thực tế về "AI hỗ trợ khách hàng thương mại điện tử", bài viết hướng dẫn bạn biến kỹ thuật prompt engineering thành "sổ tay kỹ thuật có thể truyền lại".

Giới thiệu bối cảnh

Mục tiêu và phạm vi

Bạn đã từng gặp tình huống nào sau chưa?

Viết một "prompt hoàn hảo", khi kiểm thử thì hiệu quả tốt nhưng khi triển khai lại thường xuyên thất bại — vì bạn quên ghi chú rằng "prompt này chỉ áp dụng cho 'đơn hàng chưa giao'";
Nhân viên mới trong nhóm tiếp nhận prompt của bạn, sửa vài dòng khiến hiệu quả bị phá vỡ — vì họ không biết "tham số này nhằm tránh hiện tượng AI tạo ra nội dung sai lệch";
Khi xử lý các tình huống phức tạp như đối thoại đa vòng hoặc gọi công cụ, prompt ngày càng dài và cuối cùng trở thành "mã hỗn độn không ai hiểu được".

Mục tiêu cốt lõi của tài liệu hóa prompt engineering là biến "kinh nghiệm thiết kế prompt ngầm" thành "tài sản tri thức rõ ràng":

Giúp bản thân trong tương lai chỉnh sửa prompt không cần "đoán logic" lại;
Giúp nhóm làm việc không cần "truyền miệng" liên tục;
Giúp các tình huống phức tạp có thể tổ hợp linh hoạt như "xây dựng bằng khối".

Phạm vi bài viết:

Định nghĩa "tài liệu hóa prompt engineering" (không phải viết nội dung prompt mà là viết "logic đằng sau");
Bốn kỹ thuật thực tiễn trong tình huống phức tạp (mô hình phân tầng, mẫu biến, cây quyết định, nhật ký lặp lại);
Cách sử dụng tài liệu để giải quyết vấn đề "kiểm thử chuẩn, triển khai kém";
Ví dụ thực tế: Viết tài liệu prompt cho AI hỗ trợ khách hàng thương mại điện tử từ đầu.

Đối tượng người đọc kỳ vọng

Lập trình viên / kỹ sư thuật toán đang phát triển ứng dụng với mô hình lớn;
Product manager chịu trách nhiệm thiết kế sản phẩm AI (cần đồng bộ logic prompt với nhóm kỹ thuật);
Nhân viên vận hành / chăm sóc khách hàng thường xuyên làm việc với mô hình lớn (cần hiểu "giới hạn" của prompt).

Tổng quan cấu trúc tài liệu

Luồng logic của bài viết: Kể chuyện → Phân tích khái niệm → Kỹ thuật trong tình huống phức tạp → Ví dụ thực tế → Công cụ gợi ý → Kết luận Giống như "hướng dẫn mở quán trà sữa": trước tiên kể lý do cần viết thực đơn (kể chuyện), sau đó giải thích cách phân cấp thực đơn (khái niệm), rồi dạy cách điều chỉnh thực đơn cho khách hàng khác nhau (kỹ thuật), cuối cùng dẫn bạn "tự làm một ly trà sữa" (ví dụ thực tế).

Danh mục thuật ngữ

Định nghĩa thuật ngữ cốt lõi

Prompt engineering: Kỹ thuật viết "lệnh" cho mô hình lớn, giống như viết "bản đồ nấu ăn" cho đầu bếp — bạn phải nói rõ "làm gì, làm thế nào, lưu ý gì".
Tài liệu hóa prompt engineering: Quá trình ghi lại "logic thiết kế prompt", ví dụ như "tại sao chọn lệnh này? Khi gặp lỗi thì điều chỉnh như thế nào? Những lỗi đã gặp trong quá trình kiểm thử?" — giống như phần "ghi chú" trong bản đồ nấu ăn.
Tình huống phức tạp: Yêu cầu mô hình lớn xử lý các tác vụ có nhiều biến, nhiều nhánh và tương tác đa vòng, ví dụ như "đối thoại đa vòng của hỗ trợ khách hàng thương mại điện tử", "gọi công cụ của AI phân tích dữ liệu", "hỏi đáp đa lĩnh vực của AI y tế".

Giải thích các khái niệm liên quan

Mẫu prompt: Khung prompt có thể tái sử dụng, ví dụ như "Bạn là nhân viên chăm sóc khách hàng của XX, khi trả lời câu hỏi, hãy hỏi {mã đơn hàng}", trong đó {mã đơn hàng} là biến.
Entropy thông tin: Mức độ "mơ hồ" của prompt — entropy càng cao, AI càng không biết nên làm gì; entropy càng thấp, hiệu suất AI càng ổn định (sẽ giải thích bằng công thức toán học ở phần sau).

Danh sách viết tắt

AI: Trí tuệ nhân tạo (Artificial Intelligence)
LLMs: Mô hình ngôn ngữ lớn (Large Language Models)

Khái niệm cốt lõi và mối liên hệ

Kể chuyện: Vấn đề "prompt engineering" trong quán trà sữa

Giả sử bạn mở một quán trà sữa tên là "Tiểu Thủy Trà". Ngày đầu tiên kinh doanh, bạn nói với nhân viên: "Làm một ly trà sữa trân châu." Kết quả:

Nhân viên A bỏ 5 muỗng đường (quá ngọt);
Nhân viên B bỏ 1 muỗng đường (không có vị);
Nhân viên C quên bỏ trân châu (khách hàng phàn nàn).

Bạn nhận thấy "lệnh mơ hồ" không ổn, nên viết một bản thực đơn cơ bản:

Công thức trà sữa trân châu: 300ml nước trà đỏ + 50ml kem sữa + 2 muỗng trân châu + 15g đường, khuấy đều trong 30 giây.

Giờ nhân viên làm ra trà sữa đều nhất — nhưng lại phát sinh vấn đề mới:

Khách hàng nói "Tôi muốn ít đường", nhân viên không biết "ít đường là giảm bao nhiêu";
Khách hàng hỏi "Có thể thêm hạt dẻ không?", nhân viên không biết "hạt dẻ thêm bao nhiêu, bao nhiêu tiền";
Trân châu nấu quá (quá mềm), nhân viên không biết "phải điều chỉnh thời gian nấu thế nào".

Lúc này bạn cần không phải "bản thực đơn chi tiết hơn", mà là "bản thực đơn có logic" — ví dụ:

Quy tắc đường: Đường bình thường 15g, ít đường giảm 5g, nửa đường giảm 7g, không đường 0g;

Quy tắc thêm nguyên liệu: Thêm hạt dẻ phải cộng 2 tệ, mỗi ly tối đa thêm 1 muỗng;

Xử lý trân châu: Nếu trân châu nấu quá mềm, thêm 1 muỗng đá để làm mát nhanh, giảm độ mềm.

Đây chính là bản chất của tài liệu hóa prompt engineering:

Prompt thông thường = bản thực đơn trà sữa (nói "làm gì");
Tài liệu prompt = bản thực đơn có logic (nói "vì sao làm vậy? Khi gặp lỗi thì xử lý như thế nào?");
Tình huống phức tạp = xử lý "nhiều yêu cầu khác nhau của khách hàng" (cần hệ thống tài liệu).

Giải thích khái niệm cốt lõi: Giải thích như giảng cho học sinh tiểu học về "bản đồ nấu trà sữa"

Khái niệm cốt lõi 1: Prompt engineering = viết "bản đồ nấu ăn có thể thực thi"

Mô hình lớn giống như một "bếp không kinh nghiệm nhưng biết nấu" — bạn phải viết rõ "làm gì" từng bước, nó mới làm đúng. Ví dụ:

Prompt không tốt: "Viết một bài về trà sữa" (quá mơ hồ, AI có thể viết "lịch sử trà sữa", "cách làm trà sữa", "tác hại của trà sữa");
Prompt tốt: "Viết một bài khoa học về trà sữa dành cho học sinh tiểu học, dùng cấu trúc ‘trà sữa đi từ vườn đến ly’, ngôn ngữ thân thiện, ví dụ như dùng từ ‘lá trà bé’, ‘sữa anh’ để nhân văn hóa" (rõ ràng về "đối tượng đọc", "cấu trúc", "phong cách ngôn ngữ").

Tóm lại: Cốt lõi của prompt engineering là "giảm entropy thông tin của AI" — biến yêu cầu mơ hồ thành "lệnh rõ ràng AI có thể hiểu".

Khái niệm cốt lõi 2: Tài liệu hóa prompt engineering = thêm "ghi chú" vào bản đồ nấu ăn

Bạn viết một bản thực đơn trà sữa, nhưng khi nhân viên dùng vẫn hỏi "tại sao dùng 300ml nước trà đỏ?" "Ít đường giảm bao nhiêu?" Lúc này bạn cần thêm ghi chú vào cuối thực đơn:

Tại sao dùng 300ml nước trà đỏ? — vì nếu nhiều sẽ che mất mùi sữa, ít sẽ khiến trà sữa quá nhạt; Ít đường giảm bao nhiêu? — dựa trên phản hồi khách hàng, giảm 5g phổ biến nhất; Nếu trân châu nấu quá mềm? — thêm đá để làm mát, giảm độ mềm.

Tài liệu hóa prompt engineering chính là phần "ghi chú" này: Ghi lại không phải "nội dung prompt", mà là "logic phía sau prompt" — ví dụ:

Vì sao chọn lệnh này? (ví dụ "dùng từ nhân văn hóa để dễ hiểu với học sinh tiểu học");
Khi gặp lỗi thì xử lý như thế nào? (ví dụ "nếu nội dung AI quá phức tạp, thêm giới hạn ‘nói gọn trong 100 chữ’");
Những lỗi đã gặp trong kiểm thử? (ví dụ "trước dùng từ chuyên môn, học sinh không hiểu, sau đổi sang từ nhân văn hóa").

Khái niệm cốt lõi 3: Tình huống phức tạp = "bữa tiệc cần nhiều thực đơn"

Nếu bạn tổ chức một bữa tiệc chủ đề trà sữa với 10 loại trà khác nhau (trân châu, hạt dẻ, rau câu, trà trái cây…), cần đáp ứng yêu cầu khác nhau (ít đường, lạnh, thêm gấp đôi nguyên liệu), lúc này bạn không cần "một cuốn sổ dày", mà là "hệ thống thực đơn phân cấp":

Thực đơn cơ bản: Quy tắc chung cho tất cả trà sữa (ví dụ "dùng nước trà tươi", "khuấy 30 giây");
Thực đơn theo loại: Quy tắc đặc thù cho từng loại trà (ví dụ "trà sữa hạt dẻ phải thêm 1 muỗng hạt dẻ", "trà trái cây phải thêm 20g trái cây tươi");
Thực đơn tùy chỉnh: Quy tắc điều chỉnh cho từng khách hàng (ví dụ "ít đường giảm 5g", "nóng không đá").

Prompt engineering trong tình huống phức tạp cũng tương tự — ví dụ như "AI hỗ trợ khách hàng thương mại điện tử" cần xử lý nhiều nhiệm vụ như "tra cứu đơn hàng", "hoàn tiền", "đổi hàng", "khiếu nại", còn phải đối phó với tình huống bất thường như "khách hàng nổi giận", "cung cấp thông tin thiếu". Lúc này bạn cần chia prompt thành tài liệu phân tầng — lớp cơ bản (quy tắc chung), lớp lĩnh vực (quy tắc ngành), lớp tình huống (nhiệm vụ cụ thể), lớp điều chỉnh (xử lý lỗi).

Mối quan hệ giữa các khái niệm: Giống như "hợp tác nhóm trong quán trà sữa"

Mối quan hệ giữa prompt engineering, tài liệu hóa và tình huống phức tạp giống như "bếp, thực đơn, bữa tiệc" trong quán trà sữa:

Prompt engineering là "bếp": Trả lời yêu cầu thành lệnh có thể thực thi (làm trà sữa);
Tài liệu hóa là "thực đơn": Ghi lại kinh nghiệm của bếp thành tri thức có thể truyền lại (cách làm, lý do làm như vậy);
Tình huống phức tạp là "bữa tiệc": Cần bếp dùng thực đơn để làm ra nhiều món phù hợp (xử lý tác vụ đa biến, đa nhánh).

Cụ thể:

Prompt engineering × Tài liệu hóa: Prompt là "làm gì", tài liệu là "tại sao làm vậy" — không có tài liệu, prompt giống như "thực đơn không có ghi chú", nhân viên dễ thay đổi sai lệch;
Tài liệu hóa × Tình huống phức tạp: Tình huống phức tạp cần "tài liệu phân tầng" — giống như bữa tiệc cần "nhiều thực đơn", mỗi cuốn xử lý một chiều vấn đề;
Prompt engineering × Tình huống phức tạp: Tình huống phức tạp cần "prompt chính xác hơn" — giống như bữa tiệc cần "thực đơn chi tiết hơn", ví dụ "hạt dẻ nấu 10 phút", "trà trái cây chọn trái cây mùa".

Hình ảnh minh họa nguyên lý khái niệm: Mô hình phân tầng tài liệu hóa prompt engineering

Sử dụng ví dụ "AI hỗ trợ khách hàng thương mại điện tử", vẽ sơ đồ mô hình phân tầng tài liệu hóa prompt engineering:

【Tài liệu prompt】
├─ Lớp cơ bản: Quy tắc chung (ví dụ "thân thiện, chuyên nghiệp, dùng ngôn ngữ đời thường")
├─ Lớp lĩnh vực: Quy tắc ngành (ví dụ "vấn đề đơn hàng phải hỏi mã đơn hàng, hoàn tiền phải xác nhận chưa mở gói")
├─ Lớp tình huống: Nhiệm vụ cụ thể (ví dụ "tra cứu đơn hàng → hỏi mã đơn hàng; hoàn tiền → hỏi chưa mở gói")
└─ Lớp điều chỉnh: Xử lý lỗi (ví dụ "khách hàng nổi giận → trước tiên an ủi: ‘Rất xin lỗi gây phiền toái’")

Lợi ích của mô hình này:

Module hóa: Thay đổi nội dung lớp nào cũng không ảnh hưởng lớp khác (ví dụ thay đổi giọng điệu lớp cơ bản không cần sửa lớp tình huống);
Khả năng mở rộng: Khi thêm nhiệm vụ mới, chỉ cần thêm một lớp tình huống (ví dụ thêm nhiệm vụ "đổi hàng", thêm "đổi hàng → hỏi có lỗi kỹ thuật hay không");
Dễ hiểu: Thành viên nhóm có thể nhanh chóng xác định "quy tắc nào thuộc lớp nào" (ví dụ "hỏi mã đơn hàng" thuộc lớp lĩnh vực).

Sơ đồ luồng Mermaid: Quy trình tài liệu hóa prompt engineering

flowchart TD
    A[Phân tích yêu cầu: Xác định "làm gì"] --> B[Thiết kế prompt ban đầu: Viết "lệnh có thể thực thi"]
    B --> C[Kiểm thử lặp lại: Kiểm tra hiệu quả, tìm lỗi]
    C --> D[Thu thập tài liệu: Ghi lại "logic phía sau prompt"]
    D --> E[Xác minh & tối ưu: Dùng tài liệu kiểm tra prompt có đúng yêu cầu không]
    E --> F[Triển khai: Đưa prompt vào sản phẩm]
    F --> C[Kiểm thử lặp lại: Tiếp tục tối ưu dựa trên hiệu quả thực tế]
    
    %% Output
    A -->|Output| Tài liệu yêu cầu (mục tiêu người dùng, điều kiện ràng buộc)
    B -->|Output| Mẫu prompt ban đầu (lệnh, ngữ cảnh, định dạng đầu ra)
    C -->|Output| Báo cáo kiểm thử (trường hợp thất bại, lý do điều chỉnh)
    D -->|Output| Tài liệu prompt (mô hình phân tầng, nhật ký lặp lại)
    E -->|Output| Kế hoạch tối ưu (prompt đã điều chỉnh, đánh giá hiệu quả)

Luồng chính của quy trình là "lặp lại" — prompt không phải "viết đúng một lần", mà là "kiểm thử → ghi chú → tối ưu → kiểm thử lại" lặp đi lặp lại. Tài liệu chính là "bộ nhớ" của chu trình này — giúp bạn nhớ "đã gặp lỗi gì", "tại sao phải điều chỉnh như vậy".

Bốn kỹ thuật thực tế trong tình huống phức tạp

Tiếp theo chúng ta sẽ khám phá "kỹ thuật sống còn" trong tình huống phức tạp — những kỹ thuật được rút ra từ "bản đồ nấu trà sữa", giúp giải quyết các vấn đề như "prompt ngày càng rối rắm", "hợp tác nhóm khó khăn", "hiệu quả triển khai kém".

Kỹ thuật 1: Sử dụng "mô hình tài liệu phân tầng" để phân giải logic phức tạp — giống như "hệ thống thực đơn của quán trà sữa"

Tại sao cần phân tầng?

Prompt trong tình huống phức tạp thường chứa "quy tắc đa chiều", ví dụ như "AI hỗ trợ khách hàng thương mại điện tử" cần cân nhắc:

Quy tắc chung (thân thiện, chuyên nghiệp);
Quy tắc ngành (vấn đề đơn hàng phải hỏi mã đơn hàng);
Quy tắc nhiệm vụ (tra cứu đơn hàng → hỏi mã đơn hàng; hoàn tiền → hỏi chưa mở gói);
Quy tắc xử lý lỗi (khách hàng nổi giận → an ủi).

Nếu gom hết quy tắc vào một prompt, sẽ trở thành "mã hỗn độn" — ví dụ:

Bạn là nhân viên chăm sóc khách hàng thân thiện của XX, trả lời câu hỏi chuyên nghiệp, dùng ngôn ngữ đời thường; đối với vấn đề đơn hàng phải hỏi mã đơn hàng, hoàn tiền phải xác nhận chưa mở gói; khi tra cứu đơn hàng hỏi mã đơn hàng, hoàn tiền hỏi chưa mở gói; nếu khách hàng nổi giận, trước tiên an ủi "Rất xin lỗi gây phiền toái".

Giải pháp của mô hình phân tầng: Chia các quy tắc theo chiều khác nhau thành "bốn lớp", mỗi lớp xử lý một chiều vấn đề.

Thiết kế mô hình phân tầng (ví dụ AI hỗ trợ khách hàng thương mại điện tử)

Lớp	Tác dụng	Nội dung ví dụ
Lớp cơ bản	Xác định "hình ảnh" và "phong cách chung" của AI	Bạn là nhân viên chăm sóc khách hàng thân thiện của XX, trả lời câu hỏi bằng ngôn ngữ đời thường, tránh thuật ngữ kỹ thuật, mỗi câu không quá 50 từ.
Lớp lĩnh vực	Xác định quy tắc đặc thù ngành	1. Vấn đề đơn hàng: Phải hỏi mã đơn hàng; 2. Vấn đề hoàn tiền: Phải xác nhận hàng chưa mở gói; 3. Vấn đề đổi hàng: Phải xác nhận hàng có lỗi kỹ thuật.
Lớp tình huống	Xác định bước thực thi nhiệm vụ cụ thể	- Tra cứu đơn hàng: Xin chào, vui lòng cung cấp mã đơn hàng để tôi tra cứu trạng thái vận chuyển. - Hoàn tiền: Xin chào, bạn có chắc hàng chưa mở gói không? Nếu chưa, vui lòng cung cấp mã đơn hàng. - Đổi hàng: Xin chào, bạn có lỗi kỹ thuật trên sản phẩm không? Nếu có, vui lòng cung cấp mã đơn hàng và mô tả lỗi.
Lớp điều chỉnh	Xác định quy tắc xử lý trường hợp đặc biệt	1. Khách hàng nổi giận: Trước tiên an ủi: "Rất xin lỗi gây phiền toái, tôi sẽ cố gắng giúp bạn giải quyết." 2. Khách hàng cung cấp thiếu thông tin: Nhắc nhở: "Vui lòng cung cấp mã đơn hàng để tôi giúp bạn nhanh hơn."

Lợi ích của mô hình phân tầng

Dễ chỉnh sửa: Nếu muốn thay đổi "phong cách thân thiện", chỉ cần sửa lớp cơ bản; muốn thêm "đổi hàng", chỉ cần thêm nội dung lớp tình huống.
Hợp tác rõ ràng: Product manager chịu trách nhiệm lớp cơ bản (xác định hình ảnh AI), kỹ sư chịu trách nhiệm lớp lĩnh vực (quy tắc ngành), vận hành chịu trách nhiệm lớp điều chỉnh (xử lý lỗi) — mỗi người làm việc riêng, không ảnh hưởng lẫn nhau.
Dễ bảo trì: Khi có lỗi, có thể nhanh chóng xác định lớp nào sai (ví dụ khách hàng phàn nàn "AI không hỏi mã đơn hàng", chỉ cần kiểm tra lớp lĩnh vực).

Kỹ thuật 2: Sử dụng "mẫu biến" để quản lý nội dung động — giống như "tùy chọn thêm nguyên liệu trong quán trà sữa"

Tại sao cần biến?

Trong tình huống phức tạp, prompt thường chứa "nội dung động" — ví dụ như "AI hỗ trợ khách hàng thương mại điện tử" cần sử dụng thông tin thay đổi như "mã đơn hàng", "tên sản phẩm", "trạng thái vận chuyển". Nếu viết thủ công từng lần, rất dễ sai và mất thời gian.

Giống như "tùy chọn thêm nguyên liệu" trong quán trà sữa: khách hàng muốn thêm hạt dẻ, bạn không cần viết lại "bản đồ trà sữa hạt dẻ", chỉ cần thêm biến "{nguyên liệu}" vào bản đồ cơ bản — ví dụ "300ml nước trà đỏ + 50ml kem sữa + {trân châu/hạt dẻ} + 15g đường".

Thiết kế mẫu biến

Cốt lõi của mẫu biến là "trích xuất nội dung động thành biến, dùng dấu chỗ trống thay thế", ví dụ:

Prompt gốc: "Xin chào, đơn hàng của bạn (mã đơn hàng: 123456) đang ở trạng thái đã xuất kho."
Mẫu biến: "Xin chào, đơn hàng của bạn (mã đơn hàng: {order_id}) đang ở trạng thái {logistics_status}."

Trong đó order_id và logistics_status là biến, cần lấy từ hệ thống bên ngoài (ví dụ hệ thống đơn hàng thương mại điện tử).

Yếu tố cần ghi chú trong tài liệu mẫu biến

Mẫu biến không chỉ là "đặt dấu chỗ", mà cần ghi chú "thông tin meta của biến" — ví dụ:

Tên biến	Nguồn	Yêu cầu định dạng	Giá trị mặc định	Ghi chú
order_id	Hệ thống đơn hàng thương mại điện tử	Số 6 chữ số	Không	Phải điền, nếu không không tra cứu được trạng thái vận chuyển
logistics_status	Hệ thống vận chuyển	Giá trị liệt kê: đã xuất kho/vận chuyển/đã nhận	Không	Phải lấy từ hệ thống, không được tự tạo
user_name	Hệ thống thông tin người dùng	Chuỗi (2–4 ký tự)	Người dùng thân mến	Nếu không có tên, dùng giá trị mặc định

Lợi ích của mẫu biến

Tái sử dụng dễ dàng: Cùng một mẫu có thể dùng cho nhiều người (ví dụ người A có mã 123, người B có mã 456, chỉ cần thay đổi giá trị biến);
Dễ bảo trì: Nếu định dạng biến đổi (ví dụ mã đơn hàng từ 6 chữ số thành 8), chỉ cần cập nhật trong tài liệu, không cần sửa tất cả prompt;
Tránh tạo nội dung sai lệch: Nguồn và ghi chú của biến giúp AI tuân thủ — ví dụ "logistics_status phải lấy từ hệ thống", tránh AI tự tạo trạng thái vận chuyển.

Kỹ thuật 3: Sử dụng "tài liệu cây quyết định" để xử lý logic đa nhánh — giống như "cây yêu cầu khách hàng trong quán trà sữa"

Tại sao cần cây quyết định?

Trong tình huống phức tạp, prompt thường chứa "logic đa nhánh" — ví dụ như "AI hỗ trợ khách hàng thương mại điện tử" xử lý "yêu cầu hoàn tiền" cần phân tích:

Hàng có chưa mở gói không?

Có → Hỏi mã đơn hàng → Xử lý hoàn tiền;
Không → Yêu cầu thêm thông tin.

Cây quyết định giúp quản lý các nhánh logic này một cách rõ ràng.

Kỹ thuật 4: Sử dụng "nhật ký lặp lại" để theo dõi tiến hóa của prompt — giống như "bản ghi chú cải tiến thực đơn"

Tại sao cần nhật ký?

Khi prompt được sử dụng trong thực tế, nó thường xuyên cần điều chỉnh. Nhật ký giúp bạn ghi lại quá trình tối ưu và lý do điều chỉnh.

Nội dung nhật ký

Thời điểm điều chỉnh;
Lý do điều chỉnh;
Nội dung mới;
Hiệu quả sau khi điều chỉnh.

Ví dụ:

12/04/2025: Điều chỉnh prompt khi gặp lỗi "AI không hỏi mã đơn hàng" → Thêm quy tắc "Trước khi xử lý đơn hàng, hỏi mã đơn hàng" vào lớp lĩnh vực.

Lợi ích của nhật ký

Tránh lặp lại lỗi cũ;
Ghi nhớ lý do điều chỉnh;
Hỗ trợ phân tích hiệu quả của các thay đổi.

Thẻ: prompt engineering tài liệu hóa mô hình lớn trí tuệ nhân tạo phân tích logic

Đăng vào ngày 11 tháng 6 lúc 23:38

Thành phố Cuồng loạn

Kỹ thuật tài liệu hóa prompt engineering: Các mẹo thực tế để xử lý các tình huống phức tạp