Giáo trình ôn tập WordPress bài bản + Vibe Coding

Chương 6 – Vibe Coding — Build, Test, Debug hiệu quả

← Chương Trước Chương Tiếp →

Đây là ngày biến “điểm yếu tưởng tượng” thành điểm mạnh thật sự. Mục tiêu: có 1 câu chuyện mạch lạc, đáng tin, cho thấy bạn KIỂM SOÁT AI chứ không PHỤ THUỘC vào nó.

PHẦN A: TẠI SAO “VIBE CODING” KHÔNG PHẢI ĐIỂM YẾU NẾU KỂ ĐÚNG CÁCH

1. Vấn đề thực sự nhà tuyển dụng lo ngại

Khi nghe “chỉ vibe coding gần đây”, nhà tuyển dụng không lo bạn dùng AI — họ lo 2 điều cụ thể:

Bạn có hiểu code AI sinh ra không, hay chỉ copy-paste mù quáng?
Khi AI sai (mà AI luôn có lúc sai), bạn có tự debug/sửa được không?

Vậy câu chuyện của bạn phải trả lời thẳng đúng 2 nỗi lo này — không né tránh, không giả vờ “tôi vẫn code tay 100%” (dễ bị hỏi xoáy lộ ra ngay).

2. Khung câu chuyện chuẩn (STAR rút gọn cho tình huống này)

“10 năm em code WordPress core từ tay — hiểu rõ hooks, security, database. Gần đây em chuyển sang AI-assisted coding để tăng tốc độ, nhưng vai trò của em đã thay đổi từ ‘người gõ code’ sang ‘người kiến trúc + reviewer’. Em viết spec rõ ràng, để AI sinh code nhanh, rồi em review kỹ — đặc biệt là phần security vì AI hay bỏ sót sanitize/nonce. Khi có bug, em vẫn là người đọc log, xác định nguyên nhân, rồi mới quay lại nhờ AI sửa đúng chỗ.”

Đây là câu chuyện đáng tin vì nó thừa nhận thực tế (dùng AI nhiều) NHƯNG khẳng định rõ vai trò kiểm soát vẫn ở bạn.

PHẦN B: QUY TRÌNH BUILD VỚI AI — BÀI BẢN, KHÔNG TUỲ TIỆN

1. Bước 1 — Viết Spec trước khi để AI code

Nguyên tắc: Input mơ hồ → Output mơ hồ, khó review. Input rõ ràng → Output đoán trước được, dễ kiểm tra đúng/sai.

Spec tệ:

“Làm cho tôi 1 form liên hệ”

Spec tốt (cụ thể, có ràng buộc rõ):

“Tạo shortcode [contact_form] cho WordPress. Form có 3 trường: tên (required), email (required, validate format), nội dung (required). Xử lý bằng hook init, không dùng admin-ajax. Bắt buộc: wp_nonce_field để chống CSRF, sanitize_text_field/sanitize_email cho input, esc_html khi hiển thị lại nếu có lỗi validate. Lưu vào bảng custom wp_contact_messages qua $wpdb->insert với prepared statement.”

Vì sao spec tốt quan trọng: Bạn liệt kê rõ ràng requirement bảo mật ngay trong spec — buộc AI phải làm đúng từ đầu, thay vì bạn phải tự phát hiện thiếu sót sau khi review (dễ bỏ sót nếu không kiểm tra kỹ).

2. Bước 2 — Luôn đọc lại code AI sinh ra, đặc biệt checklist Security

Checklist review nhanh khi AI sinh code có xử lý input/output:

[ ] Có nonce field + verify không (nếu có form)?
[ ] Input có được sanitize đúng loại không (sanitize_text_field vs sanitize_email vs absint)?
[ ] Output có escape đúng ngữ cảnh không (esc_html vs esc_attr vs esc_url)?
[ ] Query DB có dùng $wpdb->prepare() không, hay nối chuỗi trực tiếp?
[ ] Có check current_user_can() nếu là hành động cần quyền không?
[ ] Hook được gọi đúng thời điểm không (VD: register_post_type trong init, không phải top-level)?

Kinh nghiệm thực tế đáng kể khi phỏng vấn:

“Em từng thấy AI sinh code query $wpdb mà quên prepare(), hoặc quên esc_attr() khi in giá trị vào input value. Vì em hiểu rõ nguyên tắc sanitize/escape từ nền tảng cũ, em bắt được ngay những lỗi này — đây chính xác là lý do em nghĩ 10 năm kinh nghiệm WordPress core vẫn cực kỳ giá trị dù giờ code nhanh hơn nhờ AI.”

3. Bước 3 — Dùng AI đúng chỗ nó mạnh nhất

AI mạnh khi:

Sinh boilerplate lặp lại (CPT registration, REST route skeleton, class structure).
Viết code theo pattern đã biết rõ, chỉ khác chi tiết (VD: 5 CPT gần giống nhau).
Convert/refactor code từ dạng này sang dạng khác (procedural → OOP).
Viết test case, viết docblock, giải thích code cũ khó hiểu.

AI yếu / cần người kiểm soát khi:

Quyết định kiến trúc tổng thể (nên tách custom table hay dùng postmeta — cần hiểu business context).
Đánh giá đánh đổi hiệu năng (AI không biết traffic thực tế site bạn, không tự đề xuất đúng cache strategy).
Bảo mật context-specific (AI không biết endpoint này có bị public hay không nếu bạn không nói rõ trong spec).

PHẦN C: TEST — QUY TRÌNH CÓ HỆ THỐNG

1. Môi trường Local Dev

Kể tên cụ thể công cụ đã dùng (tăng độ tin cậy câu trả lời):

LocalWP / DevKinsta: 1-click tạo site WP local, có sẵn phpMyAdmin, SSL, dễ switch PHP version để test compatibility.
Docker (docker-compose với image wordpress + mysql): phù hợp khi cần môi trường giống production, hoặc làm việc nhóm cần đồng bộ config.

2. Test thủ công có hệ thống — checklist thay vì “click thử cho vui”

Khi test 1 tính năng mới, kiểm tra theo các trục:

Quyền user: test với admin, editor, subscriber, và cả khách chưa login — hành vi có đúng như mong đợi ở từng cấp quyền không?
Edge case dữ liệu: input rỗng, input quá dài, ký tự đặc biệt (<script>, dấu nháy đơn/kép), số âm, số 0.
Trạng thái JS tắt: nếu tính năng dùng AJAX, thử tắt JS xem có fallback hợp lý không (hoặc chí ít không bị lỗi trắng trang).
Trình duyệt/thiết bị: ít nhất Chrome + Safari (đặc biệt quan trọng nếu dùng CSS/JS mới).

3. Testing tự động — PHPUnit cho WordPress (biết khái niệm, không cần thành thạo)

class Test_Book_CPT extends WP_UnitTestCase {

    public function test_book_post_type_registered() {
        $this->assertTrue( post_type_exists( 'book' ) );
    }

    public function test_book_price_meta_saves_correctly() {
        $post_id = $this->factory->post->create([ 'post_type' => 'book' ]);
        update_post_meta( $post_id, '_book_price', 150000 );

        $this->assertEquals( 150000, get_post_meta( $post_id, '_book_price', true ) );
    }
}

WP_UnitTestCase là class có sẵn từ WordPress test suite — nó tự tạo 1 DB test riêng, rollback sau mỗi test, có sẵn $this->factory để tạo dữ liệu giả (post, user, term…) nhanh mà không cần insert tay.

Câu trả lời mẫu khi bị hỏi “có viết unit test không”:

“Với dự án nhỏ/thời gian gấp, em ưu tiên test thủ công có checklist rõ ràng. Với dự án lớn hơn hoặc cần maintain lâu dài, em viết PHPUnit test cho các phần logic quan trọng — đặc biệt là các hàm xử lý dữ liệu (không phải UI), vì đó là nơi regression dễ xảy ra nhất khi code được sửa nhiều lần qua AI.”

PHẦN D: DEBUG — QUY TRÌNH VÀ CÔNG CỤ

1. Bật chế độ Debug đúng cách

// wp-config.php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );    // ghi lỗi vào wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // KHÔNG hiện lỗi ra màn hình (đặc biệt trên production)

Điểm hay bị hỏi: vì sao tách riêng WP_DEBUG_LOG và WP_DEBUG_DISPLAY? Vì hiện lỗi PHP trực tiếp ra trang (WP_DEBUG_DISPLAY = true) trên site thật là rủi ro bảo mật — lỗi có thể lộ đường dẫn server, tên bảng DB, cấu trúc code cho kẻ tấn công. Cách chuẩn: log vào file (debug.log), không hiện public.

2. Đọc `debug.log` có hệ thống

tail -f wp-content/debug.log

Đọc từ dưới lên (lỗi mới nhất), chú ý phân biệt:

PHP Fatal error: code dừng hẳn, phải sửa ngay.
PHP Warning: code vẫn chạy nhưng có vấn đề (VD: gọi hàm với tham số thiếu).
PHP Notice: cảnh báo nhẹ (VD: dùng biến chưa định nghĩa) — nên sửa nhưng không khẩn cấp.
PHP Deprecated: dùng hàm/cú pháp cũ, sẽ bị loại bỏ ở version PHP sau — quan trọng khi lên kế hoạch upgrade PHP.

3. `error_log()` — debug thủ công có kiểm soát

error_log( 'Book ID đang xử lý: ' . print_r( $book_id, true ) );
error_log( 'Data nhận được: ' . wp_json_encode( $data ) );

So với var_dump()/die() giữa chừng — error_log() không làm gián đoạn luồng chạy của trang, phù hợp khi cần debug trên môi trường gần giống production mà không muốn user thấy trang trắng.

4. Query Monitor — công cụ debug WordPress-specific quan trọng nhất

Đã nhắc ở Ngày 4, nhắc lại vì đây là công cụ phải kể tên khi phỏng vấn hỏi về debug:

Xem toàn bộ query SQL chạy trong request, query nào chậm, query nào lặp lại (dấu hiệu N+1).
Xem hook nào chạy, theo thứ tự nào, hàm callback nào gắn vào — cực hữu ích khi debug plugin conflict (2 plugin cùng hook vào 1 filter, ai override ai).
Xem HTTP request ra ngoài (API call) — thời gian phản hồi, có bị timeout không.

5. Debug hiệu quả với AI — biến thành kỹ năng, không phải điểm yếu

Cách đưa context đúng để AI debug hiệu quả (nên kể chi tiết này khi phỏng vấn — cho thấy tư duy, không chỉ paste lỗi):

Thay vì chỉ paste:

“Lỗi rồi, sửa giúp tôi”

Cách làm bài bản:

Copy nguyên văn dòng lỗi từ debug.log (không tóm tắt lại — dễ mất chi tiết quan trọng).
Đưa kèm đoạn code liên quan trực tiếp tới dòng lỗi (không đưa cả file nếu không cần).
Nói rõ đã thử gì rồi (tránh AI đề xuất lại cách đã test không được).
Nói rõ môi trường (PHP version, WP version) nếu lỗi liên quan tương thích.

Câu trả lời mẫu:

“Em không paste nguyên lỗi rồi hỏi ‘sao vậy’ — em luôn kèm log gốc, đoạn code liên quan, và những gì đã thử. Cách đưa context tốt giúp AI debug chính xác hơn nhiều, và bản thân việc chuẩn bị context đó cũng là lúc em tự thu hẹp phạm vi nghi vấn — nhiều lúc chưa hỏi AI em đã tự tìm ra nguyên nhân.”

PHẦN E: XÂY DỰNG “CÂU CHUYỆN” HOÀN CHỈNH ĐỂ KỂ KHI PHỎNG VẤN

Ghép lại thành 1 đoạn trả lời tự nhiên khi bị hỏi trực tiếp “sao dạo này chỉ vibe coding”:

“Em có 10 năm làm WordPress từ core — hiểu rõ hooks, database, security, performance. Khoảng thời gian gần đây em chuyển sang làm việc với AI-assisted coding để tăng tốc độ ra sản phẩm, nhưng cách em làm việc vẫn theo quy trình bài bản: em viết spec rõ ràng trước khi để AI sinh code, review kỹ theo checklist bảo mật — đặc biệt là sanitize/escape/nonce vì đây là chỗ AI hay bỏ sót nếu spec không nói rõ. Khi có bug, em vẫn là người đọc log, dùng Query Monitor để khoanh vùng, rồi mới quay lại làm việc với AI để sửa đúng chỗ chứ không đoán mò. Em nghĩ nền tảng WordPress core 10 năm giúp em dùng AI hiệu quả và an toàn hơn, chứ không phải AI thay thế kiến thức đó.”

Tại sao câu chuyện này hiệu quả:

Thừa nhận thẳng thắn (không né tránh) — tạo độ tin cậy.
Chỉ ra cụ thể: bạn làm gì (spec, review, debug) — không nói chung chung “tôi vẫn hiểu code”.
Kết ở đúng thông điệp nhà tuyển dụng cần nghe: kinh nghiệm nền tảng + AI là công cụ, không phải sự thay thế.

PHẦN F: THỰC HÀNH TAY

Chọn 1 tính năng nhỏ đã làm ở các ngày trước (VD: form liên hệ Ngày 3), thử viết lại spec chi tiết theo format Phần B.1 trước khi đưa AI code lại từ đầu — so sánh chất lượng output với/không có spec rõ.
Cố tình để AI viết 1 đoạn code có lỗi bảo mật nhẹ (VD: quên esc_attr), tự luyện mắt review theo checklist Phần B.2.
Bật WP_DEBUG_LOG, cố tình gây lỗi (gọi hàm không tồn tại), đọc debug.log, luyện thói quen đọc log trước khi hỏi AI.
Viết ra giấy/gõ lại đoạn “câu chuyện hoàn chỉnh” ở Phần E theo giọng văn của chính mình — không học thuộc máy móc, phải nghe tự nhiên khi nói ra miệng.

PHẦN G: TỰ KIỂM TRA CUỐI NGÀY

2 nỗi lo thực sự của nhà tuyển dụng khi nghe “chỉ vibe coding” là gì? (Có hiểu code AI sinh ra không; có tự debug được khi AI sai không)
Kể 3 mục trong checklist review code AI sinh ra liên quan tới security.
Vì sao WP_DEBUG_DISPLAY nên để false trên site thật? (Tránh lộ thông tin nhạy cảm — đường dẫn, cấu trúc DB — cho kẻ tấn công qua lỗi hiển thị công khai)
Kể tên công cụ debug WordPress-specific quan trọng nhất và nó giúp gì. (Query Monitor — xem query chậm/lặp, hook nào chạy, request API ra ngoài)
Tự nói (không nhìn tài liệu) đoạn “câu chuyện hoàn chỉnh” ở Phần E bằng giọng văn của chính mình, trong vòng 60 giây.

📝 2,972 từ 📅 14/07/2026 👁 4 lượt đọc

← Chương Trước Chương Tiếp →