Hãy Ngừng Viết Prompt Dài Dòng: Áp Dụng Design-Log Để Xây Dựng Công Cụ AI Chính Xác Hơn

Trong lĩnh vực phát triển phần mềm hiện đại, đặc biệt là khi làm việc với các công cụ bảo mật và tự động hóa dựa trên AI, một trong những thách thức lớn nhất là vấn đề "bức tường ngữ cảnh" (context wall). Đây là lúc các mô hình AI bắt đầu mất dấu vết lịch sử dự án và đưa ra các quyết định không nhất quán khi cơ sở mã (codebase) mở rộng.

Để giải quyết vấn đề này, phương pháp Design-Log Methodology đã ra đời như một giải pháp thay thế cho việc viết prompt (lệnh) một cách hỗn loạn. Thay vì cố gắng nhồi nhét mọi thứ vào cửa sổ chat, phương pháp này đề xuất một cách tiếp cận có cấu trúc hơn nhiều.

Vấn đề của vòng lặp "Prompt và Sửa"

Là một nhà nghiên cứu và người đam mê công nghệ thường xuyên xây dựng các công cụ bảo mật, tôi nhận thấy rằng các mô hình AI lớn (như ChatGPT hay Claude) rất dễ tạo ra mã có vẻ đúng nhưng lại âm thầm đi chệch khỏi kiến trúc bảo mật dự định.

Quy trình truyền thống là viết prompt -> AI sinh mã -> sửa lỗi -> viết lại prompt là một quy trình mong manh và tốn thời. Tôi từng phải dành hàng giờ để sao chép kết quả từ terminal dán vào cửa sổ chat, chỉ để nhận ra rằng môi trường phát triển của mình bị lộn xộn bởi các gói không cần thiết và cấu hình sai lệch. Thậm chí, khi sử dụng các IDE tích hợp AI hay các công cụ đầu cuối thông minh, tôi thường xuyên chạm đến giới hạn ngữ cảnh và làm gián đoạn toàn bộ quy trình làm việc.

Phương pháp Design-Log là gì?

Thay vì ném những câu lệnh khổng lồ vào trợ lý AI và làm quá tải cửa sổ ngữ cảnh, tôi đã bắt đầu áp dụng phương pháp Design-Log. Ý tưởng cốt lõi rất đơn giản: Duy trì một thư mục ./design-log/ (hoặc ./design/) trong kho lưu trữ Git của bạn.

Thư mục này chứa các tài liệu markdown ghi lại các quyết định thiết kế, thảo luận và kế hoạch triển khai tại thời điểm chúng được thực hiện. Nhật ký này đóng vai trò như "bộ não chung" giữa nhà phát triển và AI, cho phép AI đóng vai trò là một kiến trúc sư cộng tác thay vì chỉ là một trình tạo mã.

Cách triển khai thực tế

Với mỗi tính năng mới hoặc bài kiểm thử, tôi bắt đầu bằng một tệp nhật ký thiết kế ghi lại các yêu cầu bảo mật, mô hình mối đe dọa và hành vi mong đợi.

Ví dụ, khi xây dựng trình quét lỗ hổng mới, tôi sẽ viết vào file log:

Nhiệm vụ #12: Triển khai một công cụ network fuzzer tôn trọng giới hạn tốc độ (rate-limiting) và tránh kích hoạt báo động giả trên WAF. Chúng ta sẽ sử dụng trình tạo payload ngẫu nhiên với logic backoff có thể cấu hình.

Trước khi viết bất kỳ dòng mã nào, AI sẽ đọc nhật ký này. Sau đó, nó sẽ đặt các câu hỏi làm rõ như "Bạn có muốn hỗ trợ cả TCP và UDP cho fuzzer này không?" và tham chiếu các tài liệu được sử dụng cho lý luận của nó trong nhật ký. Điều này tạo ra sự cộng tác theo kiểu Socratic: AI không bị ảo giác (hallucinate) mà xác thực các giả định trước khi triển khai.

4 Nguyên tắc vàng của Design-Log

Để phương pháp này hoạt động hiệu quả, tôi đã thêm 4 quy tắc vào hệ thống prompt của mình:

• Đọc trước khi viết: Luôn kiểm tra nhật ký thiết kế trước.
• Thiết kế trước khi triển khai: Không có mã nào được viết cho đến khi nhật ký được phê duyệt.
• Lịch sử bất biến: Khi triển khai bắt đầu, thiết kế bị đóng băng; sử dụng git diff để theo dõi các thay đổi.
• Sử dụng phương pháp Socratic: Đặt câu hỏi và ghi lại câu trả lời.

Kết quả đạt được

Kết quả là quá trình phát triển nhanh hơn và đáng tin cậy hơn nhiều. Tôi không còn lãng phí thời gian để mò mẫm trong hàng trăm dòng mã do AI tạo ra để sửa các vấn đề vi phạm nguyên tắc bảo mật. Thay vào đó, tôi có thể xây dựng với sự tự tin vì AI và tôi đã đồng thuận về kiến trúc ngay từ ngày đầu tiên.

Phương pháp này tạo ra các quy trình công việc có thể truy xuất và sẵn sàng để kiểm toán, điều cực kỳ quan trọng khi phát triển các công cụ xử lý dữ liệu nhạy cảm hoặc tương tác với các hệ thống trực tiếp.

Nếu bạn đang sử dụng AI để xây dựng các công cụ bảo mật hay phần mềm nói chung, hãy thử phương pháp Design-Log Methodology. Nó biến AI từ một "thợ code" đôi khi tốt thành một đối tác thực sự trong phát triển an toàn và hiệu quả.