Tôi để tác tử AI xây và vận hành cả website: 10 bài học thật sau mấy tháng

Tôi để tác tử AI xây và vận hành cả website: 10 bài học thật sau mấy tháng
12 Tháng 11, 2026

Cập nhật:

9 phút đọcHướng dẫn

Để tác tử AI xây và vận hành website nghĩa là giao cho một tác tử lập trình (AI agent biết đọc mã, sửa mã, chạy lệnh) phần lớn việc viết tính năng, triển khai và bảo trì, còn con người giữ vai trò đặt yêu cầu, duyệt và chịu trách nhiệm. OPCAIOS làm đúng như vậy với website opcaios.org, và bài này gồm 10 bài học rút ra từ ghi chú bộ nhớ dự án cùng mã nguồn. Mỗi bài học bắt nguồn từ một sự cố hoặc một quy tắc có thật, kèm cách sửa. Nếu bạn làm một mình và đang cân nhắc cách làm này, hãy đọc cùng hệ thống AI vận hành một mình và tác tử lập trình cho người không biết code.

Bài viết này dựa trên dữ liệu nào và không có gì?

Phần trung thực trước: OPCAIOS không có một mốc thời gian đẹp để khoe. Các ghi chú hiện còn trải khoảng từ cuối tháng 9 đến cuối tháng 10 năm 2026, tức khoảng một tháng ghi chép, nên "mấy tháng" trong tiêu đề chỉ là cách nói theo ghi nhận chung, không phải số liệu đo chính xác. Nguồn duy nhất là ghi chú bộ nhớ dự án và mã nguồn của OPCAIOS, đọc ngày 25/10/2026. OPCAIOS không công bố doanh thu hay lượng truy cập, chưa đo tỷ lệ thời gian tiết kiệm so với làm tay, và bài này không hứa rằng AI sẽ tự chạy website thay bạn. Ví dụ, khi một tính năng chưa chạy trọn vòng, ghi chú ghi thẳng "chưa kiểm tra đầu cuối" thay vì báo đã xong.

Sơ đồ vòng làm việc giữa người và tác tử AI trên website: yêu cầu, tác tử viết mã, build thử, kiểm tra bằng trình duyệt, người duyệt, triển khai, sao lưu và ghi nhật ký
Vòng làm việc người và tác tử: mỗi bước đều có điểm kiểm tra. Sơ đồ: OPCAIOS.

Website OPCAIOS gồm những phần nào và ai viết mã?

Website opcaios.org gồm blog, cửa hàng tài liệu và mẫu, khoá học, CRM nội bộ, chuỗi email, bộ công cụ SEO/GEO và nhiều trang quản trị. Gần như toàn bộ mã do tác tử lập trình viết theo yêu cầu của chủ website, dùng Next.js làm framework, cơ sở dữ liệu Postgres và máy chủ riêng chạy bằng pm2. Có nhiều phiên làm việc chạy cùng lúc trong cùng một thư mục mã. Chính chi tiết "nhiều phiên cùng một thư mục" tạo ra phần lớn bài học bên dưới, chẳng hạn hai lần commit nhầm file (bài 1) và một lần triển khai xoá nhầm file trên máy chủ (bài 2). Ngoài ra, tác tử không nhớ gì giữa các phiên, nên mọi quy tắc phải nằm trong ghi chú dự án (bài 10).

10 bài học

1. Khi nhiều phiên dùng chung một kho mã, chỉ commit đúng đường dẫn của mình

Khi nhiều phiên dùng chung một kho Git, quy tắc an toàn là chỉ commit đúng đường dẫn của phiên mình. Ghi chú dự án của OPCAIOS, làm việc qua Claude Code của Anthropic, ghi lại 2 lần cùng một lỗi trong năm 2026. Lần đầu, một lệnh commit thường cuốn theo phần việc đang chờ của phiên khác và bị đẩy lên kho GitHub từ xa. Lần hai, chỉ chạy git add cho file của mình vẫn chưa đủ, vì commit trần lấy cả thứ phiên khác đã đưa vào vùng chờ. Ví dụ giả định: một file cấu hình do phiên khác sửa dở đi cùng commit của bạn mà bạn không hay biết. Quy trình rút ra gồm 3 bước:

  1. Xem git diff --cached --stat để biết phần việc nào đang chờ.
  2. Đặt danh sách đường dẫn ngay trên lệnh commit, dạng git commit -m "..." -- <đường dẫn>.
  3. Kiểm tra lịch sử của file lạ trước khi đẩy lên kho từ xa.

Lần hai, OPCAIOS bắt được lỗi trước khi đẩy nhờ bước 3, rồi lùi commit và làm lại. Tác tử Claude Code của Anthropic không tự biết điều này, nên quy tắc phải được ghi vào ghi chú dự án.

2. Merge bản mới nhất rồi chạy thử đồng bộ trước khi triển khai

Triển khai an toàn nghĩa là merge bản mới nhất từ kho chung và chạy thử đồng bộ trước khi đẩy lên máy chủ. Quy trình của OPCAIOS dùng rsync để đồng bộ thư mục mã lên máy chủ, kèm tuỳ chọn xoá file không còn trong nguồn. Trong 1 lần triển khai năm 2026, phiên khác đã đẩy một file lên kho chung nhưng máy của chủ website chưa có, và lần triển khai xoá mất file đó trên máy chủ, làm bản build lỗi kiểu dữ liệu. Nhờ cơ chế build an toàn ở bài 3, trang vẫn chạy bản cũ. Từ đó quy trình gồm 4 bước:

  1. Lấy bản mới từ kho chung trên GitHub.
  2. Merge nếu bản mới đi trước máy của mình.
  3. Chạy rsync ở chế độ chạy thử.
  4. Đọc kỹ mọi dòng "sẽ xoá" mà file không do mình viết.

Trong thực tế, lần xoá nhầm đó, xảy ra khi làm việc với Claude Code của Anthropic, chỉ lộ ra vì bản build báo lỗi. Chi tiết nhỏ cũng đáng ghi: kết quả chạy thử rỗng do mạng đứt trông giống "không có gì bị xoá", nên phải kiểm tra lệnh thật sự thành công.

3. Build thử ở chỗ khác rồi mới hoán đổi

Build thử ở thư mục riêng rồi mới hoán đổi là lưới an toàn quan trọng nhất khi tác tử viết mã, vì tác tử sẽ có lúc viết mã không biên dịch được. Ban đầu OPCAIOS build thẳng tại chỗ. Trong khoảng 1 đến 2 phút đó, người dùng gặp lỗi vì các file tĩnh biến mất. Giải pháp là một script build vào thư mục riêng trong khi bản đang chạy vẫn phục vụ khách, mang theo các file tĩnh cũ. Quy trình gồm 3 việc:

  1. Build bản mới vào thư mục riêng, chưa đụng tới bản đang chạy.
  2. Hoán đổi thư mục và khởi động lại bằng pm2 khi build thành công.
  3. Quay lui bằng cách đổi lại thư mục nếu có sự cố.

Nếu build hỏng, trang không bị đụng tới. Ví dụ, lần build lỗi kiểu dữ liệu ở bài 2 (viết với Claude Code) không làm khách truy cập thấy trang lỗi, vì bản cũ vẫn phục vụ cho đến khi bản mới qua kiểm tra. Với Claude Code của Anthropic hay bất kỳ tác tử nào khác, đây là điều nên làm đầu tiên.

4. Nâng phiên bản lớn của framework phải đi đường riêng

Nâng phiên bản chính của framework cần quy trình riêng, vì script build thường không đủ. Thư viện được dùng chung giữa bản cũ và bản mới, nên quay lui không hoàn tác được việc nâng. Với lần nâng Next.js lên bản 15 cùng React 19 vào tháng 10 năm 2026, OPCAIOS làm theo 4 bước:

  1. Dựng bản mới ở thư mục riêng.
  2. Chạy thử trên một cổng khác và tắt các job nền.
  3. Chuyển bằng script có tự quay lui.
  4. Giữ lại bản cũ trong vài ngày để phòng khi cần quay lại.

Bài học thêm khi làm việc với Claude Code là tác tử có thể viết mã theo kiểu cũ vì quen API cũ, ví dụ các tham số trang đã đổi thành bất đồng bộ trong Next.js 15. Vì vậy sau khi nâng cấp, quy tắc mã mới phải được ghi vào ghi chú dự án để các phiên sau không viết sai. Với Claude Code của Anthropic, quy tắc mã mới nằm trong ghi chú dự án chứ không nằm trong trí nhớ của tác tử.

5. AI hay nhớ sai phiên bản, hãy ghi phiên bản thật vào ghi chú

Chính ví dụ trên cho thấy điều này: mô hình có xu hướng viết theo thói quen của phiên bản nó đã thấy nhiều nhất. Chúng tôi giải quyết bằng ghi chú ngắn "dự án đang ở phiên bản nào, quy tắc mã nào theo sau", để mọi phiên đọc trước khi viết. Tương tự, mọi thông tin dễ cũ như cổng, kết quả triển khai cũ đều phải kiểm tra lại trên hệ thống thật trước khi dùng, vì ghi chú chỉ là tham khảo.

6. Kiểm tra bằng chạy thật, không chỉ đọc mã

Tác tử rất tự tin khi báo "xong". Ở những tính năng chưa chạy trọn vòng, ghi chú của chúng tôi ghi thẳng "chưa kiểm tra đầu cuối" (ví dụ luồng nhận quà khi đã đăng nhập, hay webhook đơn hàng khi chưa có cơ sở dữ liệu cục bộ). Với phần giao diện và tốc độ, chúng tôi dùng bản chạy cục bộ ở chế độ dữ liệu giả và đo bằng trình duyệt thật. Ví dụ: một vòng lặp vẽ hiệu ứng chạy mãi ghi biến CSS lên cả khối lớn từng làm trang chậm rõ rệt; chỉ khi đo mới thấy, đọc mã khó thấy. Lưu ý chúng tôi cũng rút ra: đo tốc độ cục bộ rất nhiễu, hãy lấy trung vị nhiều lần thay vì tin một lần chạy.

7. Nội dung do AI viết phải qua tay người duyệt, không tự đăng

Hệ thống bài SEO tự động của chúng tôi mỗi ngày chỉ tạo bản nháp và đưa vào hàng chờ duyệt. Nó chấm điểm SEO/GEO, viết lại một lần nếu điểm thấp, rồi dừng ở đó. Lý do có hai: chính sách của công cụ tìm kiếm về nội dung sản xuất hàng loạt, và quy tắc của chủ website là không đưa số liệu hay lời hứa bịa vào trang. Chúng tôi không bật chế độ tự đăng. Xem thêm kiểm toán nội dung AI trước khi đăng.

8. Dữ liệu thật thắng mã mặc định, và phải sao lưu trước khi sửa

Một bài học dễ gây hiểu nhầm: nội dung các trang hệ thống được lưu trong cơ sở dữ liệu, nên sửa giá trị mặc định trong mã không làm đổi trang đang chạy. Tác tử sửa mã xong báo "đã đổi" nhưng trang vẫn y nguyên. Cách xử lý của chúng tôi: khi thêm nội dung vào mã, phải gộp thêm vào dữ liệu thật, và luôn sao lưu giá trị cũ trước khi sửa dữ liệu trên máy chủ. Cũng vì vậy các sao lưu có tên và dấu thời gian được giữ lại sau mỗi lần sửa dữ liệu.

9. Sao lưu phải mã hoá, ra ngoài máy chủ và đã thử khôi phục

Bản sao lưu website được mã hoá trước khi đẩy lên kho lưu trữ đám mây, giữ theo hạn định và đã được chạy thử khôi phục. Cụm từ khoá giải mã lưu ở hai nơi tách biệt, vì mất cả hai nơi thì các bản sao lưu thành vô dụng. Chúng tôi chỉ tin một bản sao lưu sau khi khôi phục thành công một lần. Đọc thêm bảo mật dữ liệu kinh doanh khi dùng AI.

10. Ghi nhật ký và ghi chú, vì bộ nhớ của tác tử không kéo dài giữa các phiên

Mỗi phiên bắt đầu gần như từ số 0, nên mọi bài học trên chỉ sống được nhờ ghi chú dự án, trạng thái hệ thống và nhật ký ngày. Một chi tiết đáng nhớ: một lần thư mục tạm của phiên làm việc bị xoá giữa chừng, nên bản nháp đang viết phải được giữ ở chỗ bền cho tới khi triển khai xong. Ngoài ra chúng tôi dành một đợt rà soát bảo mật riêng (giới hạn nguồn được phép tải, kiểm tra nguồn gốc yêu cầu ghi dữ liệu, giới hạn tần suất dùng chung) và ghi kết quả thành quy tắc, để tác tử sau khỏi phải phát minh lại.

Bảng tóm tắt

Việc Tác tử dễ sai ở đâu Biện pháp
Commit nhiều phiên Cuốn nhầm file người khác Đường dẫn rõ trên lệnh commit
Triển khai Xoá file của phiên khác Merge, chạy thử đồng bộ, đọc dòng xoá
Build Hỏng mã, trang lỗi Build vào thư mục riêng rồi hoán đổi
Phiên bản Viết theo API cũ Ghi quy tắc phiên bản vào ghi chú
Nội dung Số liệu bịa, đăng hàng loạt Bản nháp, người duyệt
Dữ liệu Sửa mã mà trang không đổi Sao lưu rồi cập nhật cả dữ liệu thật

Kinh nghiệm của OPCAIOS

Điều chúng tôi dám khẳng định chỉ gồm những gì nằm trong ghi chú: các sự cố trên có xảy ra, quy tắc đi kèm có áp dụng. Chúng tôi chưa đo được tỷ lệ thời gian tiết kiệm so với làm tay, và không có số liệu doanh thu hay truy cập để chứng minh "hiệu quả". Cách làm này phù hợp khi bạn chịu khó viết quy tắc và duyệt đầu ra, không phù hợp nếu bạn muốn "giao hết rồi quên". Một số phần chúng tôi chưa kiểm chứng đầu cuối, và ghi chú nói rõ điều đó.

Câu hỏi thường gặp

Tác tử AI có thể tự vận hành website hoàn toàn không?

Theo trải nghiệm của chúng tôi thì không. Nó viết mã và chạy nhiều việc lặp, nhưng triển khai, duyệt nội dung, sao lưu và quyết định vẫn cần người. Chúng tôi không có bằng chứng cho mô hình "tự chạy hoàn toàn".

Quy tắc nào nên làm đầu tiên?

Quy tắc nên làm đầu tiên là build thử ở thư mục riêng, rồi mới hoán đổi và có cách quay lui. Đây là lưới an toàn rẻ nhất trước các lỗi mã do AI viết, vì tác tử sẽ có lúc tạo ra mã không biên dịch được. Trong website opcaios.org, cách làm này đã giúp một lần triển khai xoá nhầm file vẫn không làm hỏng trang đang chạy: bản cũ tiếp tục phục vụ khách trong khi bản mới báo lỗi kiểu dữ liệu. Thứ tự gợi ý cho người mới gồm 3 bước. Đầu tiên, dựng build vào thư mục riêng và học cách quay lui bằng cách đổi lại thư mục. Tiếp theo, ghi mỗi sự cố thành một dòng quy tắc trong ghi chú dự án, vì tác tử không nhớ gì giữa các phiên. Cuối cùng, thêm bước chạy thử đồng bộ và đọc các dòng "sẽ xoá" trước mỗi lần triển khai. Ví dụ giả định: bạn mới có một website nhỏ, làm việc với Claude Code, và một tác tử như Claude Code của Anthropic, hãy bắt đầu từ bước 1 trước khi nghĩ đến CRM hay chuỗi email.

Làm sao tránh xung đột khi nhiều phiên làm việc cùng lúc?

Chỉ commit đúng đường dẫn của mình, merge bản mới nhất trước khi triển khai và chạy thử đồng bộ để đọc các dòng xoá. Nếu có thể, hãy tách mỗi phiên một nhánh hoặc thư mục riêng.

Nội dung AI viết có nên tự đăng không?

Chúng tôi chọn không: mọi bài SEO tự động đều là bản nháp chờ duyệt tay. Đó là lựa chọn của chúng tôi, không phải quy định pháp lý.

Tôi mới bắt đầu thì nên học gì?

Người mới nên học cách giao việc, đọc kết quả và kiểm tra, trước khi học viết mã. Ba kỹ năng này là nền của cả 10 bài học trong bài, vì tác tử Claude Code của Anthropic viết phần lớn mã trên opcaios.org còn con người giữ việc đặt yêu cầu, duyệt và chịu trách nhiệm. Lộ trình gợi ý gồm 3 bước. Đầu tiên, tập viết yêu cầu đủ rõ để tác tử làm đúng một việc nhỏ. Tiếp theo, tập đọc kết quả và chạy thử thật bằng trình duyệt, vì tác tử rất tự tin khi báo "xong" dù tính năng chưa chạy trọn vòng. Cuối cùng, tập ghi quy tắc vào ghi chú dự án sau mỗi sự cố, như cách OPCAIOS làm với lỗi commit nhầm file và lỗi triển khai xoá nhầm. Ví dụ, sau một lần build hỏng, hãy ghi "build vào thư mục riêng trước" vào ghi chú thay vì chỉ sửa lỗi rồi quên. Bạn có thể xem khoá đào tạo ứng dụng AI của OPCAIOS.

Nguồn: ghi chú bộ nhớ dự án và mã nguồn nội bộ của OPCAIOS (đọc ngày 25/10/2026); điều chưa kiểm chứng: thời gian vận hành chính xác, mức tiết kiệm công sức, doanh thu và lượng truy cập (chúng tôi không đo/không công bố); Kinh nghiệm là của OPCAIOS.

Lê Quốc Nghĩa
Người xây dựng OPCAIOS

Để lại bình luận

Email của bạn sẽ không hiển thị công khai. Bình luận sẽ hiển thị sau khi được duyệt.