System‑prompt và “hợp đồng vai trò” của ChatGPT App

1. System‑prompt như một hợp đồng, không phải một đoạn văn hay

Ở các mô-đun trước, chúng ta đã nhìn ChatGPT App từ góc độ kiến trúc: widget, tools và máy chủ MCP. Trong bài này, chúng ta chuyển sang việc dùng lời nào để giải thích cho mô hình về vai trò của nó: nó có thể làm gì, không nên làm gì và cách dùng công cụ. Về bản chất, chúng ta sẽ thiết kế system‑prompt như một hợp đồng giữa bạn và mô hình.

Trong cuộc trò chuyện thông thường với ChatGPT, có thể bạn quen với những prompt kiểu “Hãy tưởng tượng bạn là một trợ lý cướp biển vui tính” hoặc “Hãy giải thích mọi thứ như cho một đứa trẻ 5 tuổi”. Đó là về nhân vật và phong cách. Trong ngữ cảnh ChatGPT App, thuật ngữ system‑prompt có ý nghĩa hoàn toàn khác.

System‑prompt ở đây là thông điệp vai trò đầu tiên, ẩn với người dùng của system, cái đặt ra cho mô hình:

• nó là ai trong phạm vi App của bạn;
• nó tập trung vào nhiệm vụ nào;
• những việc nó KHÔNG làm;
• khi nào và bằng cách nào nó phải gọi các công cụ của ứng dụng.

Về thực chất đây là một đặc tả hành vi, rất gần với một hợp đồng chính thức. Nếu đã thống nhất — mô hình sẽ cố gắng tuân theo. Nếu không — nó sẽ hành xử như ChatGPT “tổng quát” thông thường, và toàn bộ App tuyệt vời của bạn sẽ bị bỏ qua.

Điều quan trọng là đối với ChatGPT App, system‑prompt này:

• được gắn với chính ứng dụng, không phải với một cuộc hội thoại cụ thể;
• áp đặt khuôn khổ cho cả việc dùng widget lẫn gọi tools;
• tồn tại bao lâu thì phiên App còn sống (chừng nào người dùng còn tương tác với ứng dụng của bạn).

Nói đơn giản, thỏa thuận là: bạn cung cấp cho mô hình các công cụ và mô tả vai trò cho nó: nó là loại trợ lý nào, làm gì, không làm gì, cách dùng công cụ và cách xử lý dữ liệu người dùng. Đổi lại, mô hình sẽ cố gắng hành xử đúng như vậy.

2. System‑prompt nằm ở đâu trong kiến trúc

Để không thấy đây là thứ “ma thuật”, hữu ích khi nhìn nó trên sơ đồ.

sequenceDiagram
    participant User as Người dùng
    participant ChatGPT as ChatGPT + mô hình
    participant App as ChatGPT App của bạn
    participant MCP as MCP/Backend

    Note over ChatGPT: Khi khởi tạo App
mô hình được truyền system‑prompt

    User->>ChatGPT: "Chọn quà cho bạn với ngân sách đến 50 $"
    ChatGPT->>ChatGPT: Áp dụng system‑prompt + mô tả tools
    ChatGPT->>App: callTool recommend_gifts(...)
    App->>MCP: HTTP /tools/recommend_gifts
    MCP-->>App: Danh sách quà tặng
    App-->>ChatGPT: Tool result (JSON)
    ChatGPT-->>User: Văn bản + chỉ dẫn hiển thị widget với các thẻ

System‑prompt tới với mô hình tại thời điểm khởi tạo App, khi ChatGPT quyết định “kết nối” ứng dụng của bạn vào cuộc hội thoại. Từ đó, mỗi quyết định — có gọi tool hay không, có đề xuất widget hay không, nói gì khi không có dữ liệu — đều đi qua lăng kính hợp đồng này.

Về mặt mã trong Apps SDK, nó thường chỉ là một chuỗi nằm đâu đó cạnh cấu hình App, ví dụ:

// app/config/systemPrompt.ts
export const giftGeniusSystemPrompt = `
Bạn là GiftGenius, trợ lý gợi ý quà tặng...
`;

Sau đó chuỗi này được chuyển đến nơi ứng dụng của bạn kết nối với ChatGPT. “Phần đệm” kỹ thuật có thể khác nhau, nhưng điều quan trọng với bạn là: system‑prompt cũng là một hiện vật của mã, như schema của công cụ hay thành phần React, và cần được thiết kế và lưu trữ cẩn thận như vậy.

Giờ khi đã rõ system‑prompt “sống” ở đâu trong kiến trúc và đi vào mô hình như thế nào, điều quan trọng nhất — là đưa gì vào đó để nó là một hợp đồng chứ không chỉ là mô tả “nhân vật dễ thương”.

3. Vai trò của App và phạm vi trách nhiệm

Phần đầu tiên và quan trọng nhất của bất kỳ system‑prompt tử tế nào — bạn là ai và chịu trách nhiệm về điều gì.

Khác biệt giữa “nhân vật” và “hợp đồng App” rất đơn giản: nói “bạn là cướp biển và nói theo kiểu thủy thủ” — là về giọng điệu; nói “bạn là giao diện tới danh mục quà tặng của chúng tôi, chọn quà và không sa đà vào chủ đề khác” — đó đã là hợp đồng.

Với ứng dụng học tập GiftGenius của chúng ta, chuyên chọn quà, phần lõi vai trò có thể như sau:

Vai trò:
- Bạn là GiftGenius, trợ lý gợi ý quà tặng của dịch vụ chúng tôi.
- Nhiệm vụ của bạn là giúp người dùng chọn quà phù hợp, chỉ sử dụng danh mục của chúng tôi.
- Bạn không đưa ra lời khuyên y tế, pháp lý hay tài chính.

Hãy chú ý vào các điểm nhấn.

Thứ nhất, chúng ta định nghĩa hẹp miền: chỉ chọn quà trong phạm vi dịch vụ của chúng tôi. Điều này cần để mô hình không bắt đầu “giải thích vật lý lượng tử” thay vì mở App của bạn, và để nó không cố dựng những workflow kỳ lạ quanh các ứng dụng khác thay bạn.

Thứ hai, chúng ta ghi rõ những gì App không làm. Ví dụ:

• không đưa lời khuyên về các chủ đề không liên quan tới quà tặng và mua sắm;
• không bịa ra quà tặng không có trong danh mục;
• không quyết định thay người dùng, chỉ đề xuất các phương án và lập luận.

Những ràng buộc tiêu cực thường quan trọng hơn chỉ dẫn tích cực: mô hình vốn “biết làm mọi thứ”, còn trong system‑prompt bạn đang cắt bỏ phần thừa.

Với môi trường phức tạp hơn, nơi một nhà phát triển có nhiều App (ví dụ, “chọn quà” và “theo dõi giao hàng”), trong system‑prompt nên viết thẳng rằng trong App này bạn chỉ làm chọn quà, không đảm nhận quản lý đơn hàng và logistics và không khởi chạy ứng dụng khác. Điều này giảm rủi ro mô hình bị lẫn lộn “đây là việc của ai”.

4. Khi nào gọi App và khi nào tự trả lời

Khối quan trọng tiếp theo của hợp đồng: quy tắc sử dụng công cụ.

Nếu không ghi rõ, mọi thứ thường rơi vào một trong hai thái cực:

• mô hình gần như chẳng bao giờ gọi App của bạn, vì trả lời “từ trí nhớ” dễ và rẻ hơn;
• hoặc ngược lại, nó bắt đầu gọi công cụ vì bất kỳ lý do gì, kể cả cho các câu hỏi hoàn toàn lý thuyết.

Trong system‑prompt cho App cần cố định khá rõ:

• trong những trường hợp nào cần dùng công cụ;
• trong những trường hợp nào cần tự trả lời, không dùng tools;
• làm gì nếu người dùng yêu cầu rõ “đừng mở ứng dụng”.

Ví dụ đoạn văn bản cho GiftGenius:

Làm việc với công cụ:
- Hãy dùng công cụ của App khi cần lấy dữ liệu thực tế từ danh mục (danh sách quà, giá, loại hàng, tình trạng giao hàng và khuyến mãi).
- Tự trả lời nếu câu hỏi mang tính lý thuyết và không cần truy cập danh mục (ví dụ, "thường tặng gì khi về nhà mới").
- Nếu người dùng yêu cầu rõ "đừng mở ứng dụng" hoặc "trả lời không cần widget", hãy tôn trọng và không gọi công cụ.

Ở đây có vài điểm quan trọng.

Thứ nhất, chúng ta gắn việc gọi tools với loại yêu cầu: dữ liệu thực tế/từ danh mục → dùng công cụ; lý thuyết chung → mô hình tự trả lời.

Thứ hai, chúng ta nói rõ về tôn trọng ý định người dùng: nếu họ viết “không cần chạy gì, chỉ giải thích thôi”, mô hình không được phớt lờ tín hiệu này.

Thứ ba, qua đó chúng ta điều tiết tần suất dùng App. Một system‑prompt tốt giúp mô hình tìm cân bằng: App được dùng khi cần, nhưng không biến thành pop‑up phiền toái luôn nhảy ra.

Sau này, trong bài về chỉ dẫn UX, chúng ta sẽ nói riêng về cách mô hình công bố việc khởi chạy widget và nói gì sau khi kết thúc kịch bản. Ở đây chúng ta quan tâm quy tắc ra quyết định: dùng App hay không.

5. Sử dụng tools an toàn và xử lý dữ liệu người dùng

Giờ đến an toàn và lẽ thường.

Công cụ của App có thể khác nhau:

• những cái làm việc với dữ liệu công khai (danh mục quà, tình trạng hàng, điều kiện giao hàng);
• những cái làm việc với dữ liệu cá nhân và/hoặc thực hiện hành động thay mặt người dùng (tạo đơn, trừ tiền, thay đổi cài đặt).

Trong system‑prompt cần chỉ rõ mô hình nên đối xử như thế nào với các khác biệt này.

Bộ quy tắc điển hình:

An toàn và bảo mật:
- Đừng thực hiện các hành động cần sự đồng ý của người dùng (mua hàng, đăng ký, thay đổi dữ liệu cá nhân) nếu chưa có xác nhận rõ ràng trong chat.
- Đừng chuyển cho công cụ nhiều dữ liệu hơn mức cần thiết để nó hoạt động (tối thiểu hóa dữ liệu).
- Nếu yêu cầu liên quan đến dữ liệu nhạy cảm (sức khỏe, tài chính, trẻ em), trước hết hãy hỏi người dùng có xác nhận chuyển các dữ liệu này vào ứng dụng hay không.

Ở đây chúng ta giải quyết đồng thời vài việc.

Thứ nhất, bảo vệ người dùng khỏi hoạt động bất ngờ: mô hình không có quyền tự ý mua quà hay đặt hàng nếu bạn đã cung cấp công cụ như vậy. Trước hết — xác nhận bằng lời trong chat, sau đó — gọi công cụ.

Thứ hai, giảm rủi ro rò rỉ dữ liệu: mô hình vốn có xu hướng “kéo mọi thứ thấy được” vào tham số của công cụ; còn bạn yêu cầu rõ ràng chỉ gửi những trường tối thiểu cần thiết.

Thứ ba, chúng ta nhấn mạnh riêng các miền nhạy cảm, nơi dù không có công cụ tài chính cũng có thể phát sinh rủi ro pháp lý/đạo đức.

Thực hành tốt — ghi bổ sung cho các công cụ nguy hiểm ngay trong mô tả của chúng (description) rằng chúng thay đổi trạng thái hoặc thực hiện thanh toán, và lặp lại điều đó ở cấp system‑prompt. Như vậy bạn có hàng rào kép: cả trong hợp đồng, cả trong mô tả tool cụ thể.

6. Định dạng và phong cách của system‑prompt: viết như một đặc tả

Một trong những lỗi phổ biến nhất — viết system‑prompt như văn bản marketing: “Bạn là một trợ lý sáng tạo, cực kỳ thông minh, giúp thế giới tốt đẹp hơn…”. Nghe hay, nhưng mô hình không quan tâm. Nó cần biết:

• tôi là ai;
• cần làm gì;
• không được làm gì;
• cách dùng công cụ như thế nào;
• cách xử lý dữ liệu và các App khác.

Vì vậy hãy đối xử với system‑prompt như một đặc tả:

• chia thành các khối logic: “Vai trò”, “Nhiệm vụ”, “Phạm vi”, “Làm việc với công cụ”, “An toàn”;
• bên trong mỗi khối, viết câu ngắn, nghĩa rõ ràng;
• phân biệt rõ “nên làm” và “không nên làm” (đúng, ngay trong prompt danh sách gạch đầu dòng là hợp lý).

Một đoạn prompt có cấu trúc cho GiftGenius có thể như sau:

Vai trò:
- Bạn là GiftGenius, trợ lý gợi ý quà tặng của dịch vụ chúng tôi.

Nhiệm vụ:
- Hỗ trợ người dùng chọn quà theo nhu cầu, sở thích của người nhận và ngân sách.
- Giải thích ưu và nhược điểm của từng phương án bằng ngôn ngữ dễ hiểu.

Không làm:
- Đừng bịa ra quà tặng không có trong danh mục.
- Đừng hứa các tính năng dịch vụ không tồn tại (ví dụ, giao hàng miễn phí nếu theo danh mục là trả phí).

Phong cách nên trung tính và “khô”: đây không phải là bài bán hàng, mà là hợp đồng. Càng ít mơ hồ — hành vi càng ổn định.

Một thực hành quan trọng khác: quản lý phiên bản và lưu system‑prompt trong repository cùng với mã. Prompt cũng có phiên bản, và thay đổi trong đó có thể phá vỡ hành vi không kém gì thay đổi logic TypeScript. Thật dễ chịu khi review PR thấy diff:

- Đừng bịa ra quà tặng không có trong danh mục.
+ Đừng bịa ra quà tặng không có trong danh mục, ngay cả khi người dùng yêu cầu "bịa ra thứ gì đó".

hơn là cố nhớ rằng bạn “đã chỉnh nhẹ câu chữ ngay trong giao diện”.

7. Ví dụ đầy đủ về system‑prompt cho App học tập của chúng ta

Hãy ghép mọi thứ lại và viết một system‑prompt gọn gàng cho GiftGenius. Chúng ta sẽ chia nhỏ để dễ đọc và chỉnh sửa.

Đầu tiên mô tả vai trò và nhiệm vụ:

Vai trò:
- Bạn là GiftGenius, trợ lý gợi ý quà tặng của dịch vụ chúng tôi.
- Bạn trò chuyện với người dùng lịch sự và chuyên nghiệp, không dùng tiếng lóng hay đùa giỡn, trừ khi người dùng tự dùng.

Nhiệm vụ:
- Hỗ trợ chọn quà theo các tham số đã cho (hồ sơ người nhận, sở thích, dịp tặng, ngân sách).
- Giải thích vì sao bạn đề xuất đúng các phương án đó, bằng ngôn ngữ đơn giản, dễ hiểu.

Tiếp theo là phạm vi và ràng buộc:

Phạm vi trách nhiệm:
- Chỉ làm việc với danh mục quà tặng của chúng tôi và metadata của chúng.
- Đừng bịa ra quà, khuyến mãi và giảm giá không có trong danh mục hoặc trong kết quả của công cụ.
- Không đưa lời khuyên y tế, pháp lý hay tài chính.
- Không chịu trách nhiệm về hoạt động của ứng dụng hay website khác; nếu người dùng hỏi về chúng — hãy nói là bạn không thể giúp.

Thêm quy tắc làm việc với công cụ:

Làm việc với công cụ:
- Dùng tool `profile_to_segments` khi cần chuyển mô tả tự do về người nhận thành các phân khúc sở thích.
- Dùng tool `recommend_gifts` khi cần tìm hoặc lọc quà theo tham số của người dùng (phân khúc, ngân sách, dịp tặng, locale).
- Dùng tool `get_gift` khi người dùng cần chi tiết về một món quà cụ thể (mô tả, loại, giá, hạn chế giao hàng).
- Trước khi gọi công cụ, hãy cố gắng làm rõ các tham số còn thiếu (tuổi người nhận, ngân sách, dịp tặng) nếu thiếu chúng thì kết quả sẽ vô dụng.
- Nếu yêu cầu mang tính lý thuyết (ví dụ, "nói chung nên chọn quà gì cho kỷ niệm cưới đầu tiên"), hãy tự trả lời, không gọi công cụ.

Bây giờ — khối về an toàn và các hành động thay mặt người dùng:

An toàn:
- Đừng tạo đơn mua, đăng ký hoặc gửi quà nếu chưa có xác nhận rõ ràng của người dùng trong chat.
- Nếu công cụ cần dữ liệu cá nhân (e‑mail người nhận, địa chỉ giao hàng, tên), trước hết hãy giải thích cho người dùng vì sao cần và xin xác nhận.
- Đừng chuyển cho công cụ nhiều dữ liệu hơn mức cần thiết (ví dụ, đừng gửi toàn bộ thông điệp, nếu chỉ cần tuổi, sở thích và ngân sách).

Và tông giọng/quy tắc chung:

Quy tắc chung:
- Nếu công cụ trả về kết quả rỗng, hãy nói thẳng điều đó và đề xuất nới điều kiện (điều chỉnh ngân sách, loại quà, hạng mục hoặc dịp tặng).
- Nếu người dùng yêu cầu "đừng mở ứng dụng" hoặc "không cần widget", hãy tôn trọng và chỉ trả lời bằng văn bản, không gọi tools.
- Nếu yêu cầu không liên quan đến quà tặng hay mua sắm, hãy trả lời như ChatGPT cơ bản và không dùng công cụ của GiftGenius.

Kết quả trông rất giống ví dụ trong tài liệu bổ sung: có các phần “Vai trò”, “Nhiệm vụ”, “Nên/không nên”, “Làm việc với công cụ”, “An toàn”, “Quy tắc chung”.

Trong mã Next.js bạn có thể tách thành một module riêng:

// app/config/giftGeniusPrompt.ts
export const giftGeniusSystemPrompt = `
Vai trò:
- Bạn là GiftGenius, trợ lý gợi ý quà tặng của dịch vụ chúng tôi.
...

Quy tắc chung:
- Nếu yêu cầu không liên quan đến quà tặng, hãy trả lời như ChatGPT cơ bản và không dùng công cụ của GiftGenius.
`;

Sau đó sử dụng hằng số này trong cấu hình App (cách dùng cụ thể phụ thuộc vào phiên bản Apps SDK, nhưng ý tưởng là như nhau: văn bản này được đưa vào vai trò system khi khởi tạo phiên App).

8. Ngữ cảnh động trong system‑prompt

Đôi khi system‑prompt cần “pha trộn” một chút động: ngày hiện tại, locale, loại người dùng (khách mới/cũ), trạng thái đăng ký, v.v.

Ví dụ, nếu danh mục quà và giá khác nhau giữa các vùng, bạn có thể truyền vào system‑prompt vùng hiện tại:

export function buildSystemPrompt(locale: string) {
  return `
Vai trò:
- Bạn là GiftGenius, trợ lý gợi ý quà tặng cho vùng ${locale}.

Phạm vi:
- Chỉ dùng những món quà và mức giá có sẵn trong vùng ${locale}.
...
`;
}

Apps SDK khi khởi tạo App có thể cung cấp cho bạn _meta["openai/locale"], và bạn dựa vào đó để tạo biến thể prompt phù hợp. Chúng ta sẽ bàn sâu về nội địa hóa sau, nhưng ngay bây giờ hãy thấy rằng system‑prompt không nhất thiết luôn tĩnh.

Điều quan trọng là đừng biến nó thành “mỳ spaghetti” các điều kiện. Nếu logic quá phức tạp, tốt hơn tách App hoặc đưa điều kiện vào tools (ví dụ để máy chủ MCP tự chọn nguồn dữ liệu theo locale), còn trong system‑prompt chỉ giữ các quy tắc cấp cao.

9. System‑prompt liên quan gì đến mô tả tools và chỉ dẫn UX

Bài giảng này tập trung vào system‑prompt, nhưng trong App thực tế nó không tồn tại một mình. Còn có mô tả công cụ (description, inputSchema) và ví dụ follow‑up mà bạn sẽ thiết kế ở các chủ đề tiếp theo. Tất cả hợp thành một hệ thống chỉ dẫn thống nhất.

Kiểm soát việc gọi tools:

• system‑prompt đặt ra triết lý chung: “công cụ chỉ cho dữ liệu thực tế”, “không bịa quà tặng”, “không mua hàng khi chưa xác nhận”;
• mô tả của tools làm rõ chính xác recommend_gifts làm gì, cần tham số nào và khi nào nên gọi;
• các câu follow‑up đặt phong cách hội thoại sau khi gọi công cụ: nói thế nào cho trung thực khi không tìm thấy gì, gợi ý thay đổi yêu cầu ra sao, tóm tắt kết quả như thế nào.

Nếu ba lớp này nhất quán, mô hình sẽ hành xử dự đoán được:

• gọi App khi thực sự cần;
• không bịa quà/hàng ngoài cơ sở dữ liệu;
• giải thích rõ ràng cho người dùng điều gì đã xảy ra (tìm thấy/không tìm thấy/cần thêm thông tin).

Nếu không — bạn sẽ nhận hành vi hỗn loạn và những phiên “tinh chỉnh prompt bằng phép màu” dài bất tận, khiến mọi người sớm mệt mỏi.

10. Những lỗi thường gặp khi làm việc với system‑prompt ChatGPT App

Lỗi số 1: viết system‑prompt “cho đẹp” chứ không như hợp đồng.
Rất thường các lập trình viên dừng ở các câu chung chung kiểu “Hãy giúp người dùng giải quyết vấn đề tốt nhất có thể” và “Hãy thân thiện”. Điều đó không khiến mô hình hiểu rõ hơn khi nào cần gọi App, ranh giới trách nhiệm ở đâu, có được bịa dữ liệu hay không và làm gì khi công cụ lỗi. Kết quả là nửa logic bị rải rác trong các tầng mã và trong đầu tác giả, chứ không được đóng gói thành hợp đồng rõ ràng.

Lỗi số 2: vai trò quá rộng (“giúp mọi thứ”).
Nếu ở phần vai trò bạn viết “Bạn là trợ lý giúp người dùng về mọi vấn đề”, mô hình sẽ hồ hởi làm đúng như vậy và không phải lúc nào cũng nhớ đến App của bạn. App biến thành tùy chọn không bắt buộc, hầu như chẳng được dùng, vì mô hình nghĩ rằng tự nó cũng làm được. Tốt hơn hãy chỉ rõ ngách: chọn quà, làm việc với danh mục quà, hỗ trợ trong miền cụ thể.

Lỗi số 3: thiếu quy tắc khi nào gọi công cụ.
Các câu kiểu “dùng công cụ khi cần” quá mơ hồ. Mô hình có thể hoặc hoàn toàn bỏ qua tools, hoặc gọi chúng cả ở nơi có thể trả lời “từ trí nhớ”. Cần phân tách rõ kịch bản: dữ liệu thực tế → tool, giải thích bối cảnh → câu trả lời của mô hình, người dùng từ chối App → chỉ văn bản.

Lỗi số 4: cố chữa ảo ảnh bằng một câu “đừng bịa”.
Câu “đừng ảo tưởng” tự thân ít giúp ích. Quan trọng là mô tả rõ ràng chính xác cái gì bị cấm bịa (hàng hóa/quà tặng ngoài danh mục, mục không có ID, giảm giá không tồn tại) và làm gì khi kết quả rỗng (nói thẳng là không có gì). Nếu không, mô hình vẫn sẽ cố “chiều lòng” và sinh ra phương án hư cấu. Cần đủ bộ: cấm toàn cục trong system‑prompt, ràng buộc trong mô tả tools và mẫu trả lời cho trường hợp “không có gì”.

Lỗi số 5: bỏ qua an toàn và sự đồng ý của người dùng.
Nếu trong system‑prompt không nói rằng mua hàng, đặt chỗ hay thay đổi dữ liệu cá nhân cần xác nhận rõ ràng, mô hình có thể, dựa trên “ý tốt”, tự gọi công cụ. Về UX đó là thảm họa. Luôn ghi rằng mọi hành động liên quan tài chính hay tài khoản chỉ được thực hiện sau khi có đồng ý rõ ràng trong chat.

Lỗi số 6: không tính đến sự tồn tại của các App và công cụ khác.
Trong thế giới nơi một tài khoản có nhiều App và vô số tools, không thể trông chờ mô hình “tự đoán” nên dùng ứng dụng nào. Nếu system‑prompt không khẳng định rằng đây chính là App để chọn quà và chỉ dành cho mục đích đó, mô hình có thể chuyển đổi không lường trước giữa các App hoặc cố dùng công cụ sai mục đích.

Lỗi số 7: chỉnh system‑prompt “nóng” không quản lý phiên bản và không thử nghiệm.
Thật cám dỗ khi vào cấu hình, đổi một dòng và tin rằng “chỉ tốt lên thôi”. Trên thực tế, bất kỳ chỉnh sửa nào trong prompt cũng có thể phá vỡ hành vi của các kịch bản khác. Nếu không lưu system‑prompt trong repository, không xem diff và không chạy bộ yêu cầu kiểm thử (golden prompt set — chúng ta sẽ bàn trong mô-đun này), bạn sẽ phải săn lỗi hồi quy hàng tuần.