[GN] Người không phải lập trình viên + Claude vận hành production suốt 238 ngày — điều gì đã hiệu quả và điều gì không?

(chajooin.com)

7 điểm bởi workdriver 2026-04-12 | 5 bình luận | Chia sẻ qua WhatsApp

Tôi là người vận hành đã tạo ra chajooin.com. Học hết cấp 3, làm xe tải chở hàng 8 năm (từ 2017~). Trong trạng thái không biết viết nổi dù chỉ một dòng code, vào ngày 16 tháng 8 năm 2025 tôi đã thực hiện commit đầu tiên cùng với Claude. Đã 238 ngày trôi qua, và hiện tại dịch vụ này mỗi ngày đều tự động thu thập dữ liệu và phát hành báo cáo.

Bài viết này không phải là ghi chép về việc "đã làm ra", mà là ghi chép về việc "đang làm ra và đang vận hành". Có khá nhiều bài chia sẻ về việc tạo prototype bằng vibe coding, nhưng trải nghiệm tiếp tục vận hành production thì hiếm hơn nên tôi viết ra. Đây không phải câu chuyện thành công mà là bản ghi chép thẳng thắn về những gì đã hoạt động và những gì không hoạt động.

Bối cảnh

Lĩnh vực: so sánh giá thị trường xe tải chở hàng (thị trường 17 nghìn tỷ won, không có hồ sơ chính thức về giá giao dịch thực tế)
Thử nghiệm trước đó: năm 2024 thuê ngoài turnkey 30 triệu won → từ bỏ vì quyền chủ động sửa đổi nằm ở bên outsource
Chuyển hướng: học AI 2 tháng vào tháng 7 năm 2025 → commit đầu tiên vào ngày 16 tháng 8

Stack

Frontend    Vite + React + TypeScript + Tailwind  
Backend     Node.js + Express + Prisma  
DB          PostgreSQL (Railway managed)  
수집        Playwright (headless) + 46 parser theo từng nguồn  
ML          LightGBM (Python, 75 features)  
배포        Railway (Docker)  
자동화      Node scheduler + thông báo Telegram  
AI 협업     Claude (phát triển chính) + GPT-4o (kịch bản shorts/prompt)  
인증        Naver/Kakao OAuth

Tôi không phải là người "lựa chọn" stack này. Tôi chỉ hỏi AI rằng "muốn làm cái này thì phải dùng gì?" rồi dùng theo câu trả lời. Về sau nhìn lại thì đó là một tổ hợp hợp lý. Giá trị thực tiễn của AI agent là ở chỗ nó gánh thay gánh nặng nhận thức trong việc lựa chọn.

Các con số (2025-08-16 ~ 2026-04-12)

Hạng mục	Giá trị
Tổng số commit	3,493
Số ngày có commit	189 ngày
Số file code	khoảng 1,500 (tính theo js/ts/py)
Rollback	20+ lần
Deploy thất bại	39 lần (2 ngày đầu setup Railway)
Số lần lặp lại cùng một bug nhiều nhất	7 lần (đơn vị giá)
Tin đăng đang hoạt động	khoảng 48,000 xe
Parser nguồn bên ngoài	46
CLAUDE.md	187 dòng, 24 quy tắc tuyệt đối
File memory	129

Phần 1. Xây dựng — 3 điều đã giúp hệ thống chạy được

1.1 CLAUDE.md — kiểm soát AI bằng quy tắc

Nếu cùng một bug xảy ra lần thứ hai thì câu kiểu "hãy cẩn thận nhé" là vô nghĩa. Cần viết quy tắc cụ thể vào file và để AI đọc nó mỗi khi bắt đầu một session.

"parser=nguồn gốc → chuẩn hóa=÷10,000 → DB=đơn vị 10,000 won. Cấm ×10,000 lên giá trị trong DB"  
"Nếu parser thất bại khi trích xuất năm sản xuất thì cấm gán getFullYear()"  
"Cấm thêm kakaotalk vào UA rewrite trong vercel.json"  
"Giá trị setInterval bắt buộc phải clamp bằng Math.min(value, 2^31-1)"

Hiện tại có 24 điều. Tất cả đều được sinh ra sau những sự cố có thật.

1.2 Tách vai trò — con người làm kế hoạch/phán đoán, AI làm triển khai

Dù không đọc được code, tôi vẫn có thể đánh giá kết quả. Nếu xe Porter 2 tấn hiển thị 5 triệu won thì tôi có thể nói "cái này sai rồi", và nếu wing body với cargo ra cùng một mức giá thì tôi có thể nói "hãy tách chúng ra". Cảm nhận về domain đóng vai trò như kiểm thử.

1.3 File memory — giữ context giữa các session

Tôi tích lũy quyết định/thất bại/chính sách vào 129 file memory. Khi một session mới mở ra, nó đọc các memory liên quan để giữ lại các phán đoán trong quá khứ. Đây là cấu trúc dùng hệ thống file để bù đắp giới hạn context window của AI.

Phần 2. Vận hành — vấn đề khác với việc xây dựng

2.1 Những thứ đang chạy tự động

Ingestion tin đăng: scheduler thu thập dữ liệu từ nguồn bên ngoài → quality gate → phản ánh vào DB
Báo cáo giá thị trường: tự động tạo mỗi ngày → tự động đăng lên blog/cafe
Sinh kịch bản shorts: GPT-4o tạo kịch bản/prompt Sora theo từng phân khúc tải trọng (khâu tổng hợp video là bước riêng)
Huấn luyện lại ML: mỗi tuần 1 lần huấn luyện lại engine giá thị trường bằng dữ liệu mới
Giám sát: cảnh báo Telegram khi pipeline có bất thường

Nhà phát triển chỉ có một mình tôi.

2.2 Chi phí

Hạ tầng: Railway (PostgreSQL + Node + Playwright)
AI API: thuê bao Claude (dùng cho phát triển) + GPT-4o API (dùng để tạo shorts, ước tính khoảng 1 USD/tháng dựa trên api_usage_log)
Domain/OAuth: Naver/Kakao

2.3 Ghi chép ứng phó sự cố

Ô nhiễm dữ liệu 1,138 bản ghi (2/3): phát hiện bug fallback năm sản xuất → vá DB + pipeline tái xử lý + thêm quy tắc
Thông báo Slack không hoạt động suốt 6 tháng (phát hiện 18/3): vấn đề biến môi trường/đường dẫn → tái cấu trúc, hợp nhất thành một đường Telegram duy nhất
Tràn setInterval 32-bit (10/4): đăng nhập bị treo → hotfix + thêm quy tắc clamp
Màn hình trắng trên KakaoTalk (31/1): SEO UA rewrite bắt cả trình duyệt in-app của KakaoTalk → sửa danh sách UA

2.4 Trích một số quy tắc vận hành

Trong CLAUDE.md cũng có cả các quy tắc nhìn từ góc độ vận hành.

"Sau khi deploy hãy báo cáo bằng 3 con số: trạng thái server (health 200),  
 số lượt crawl hôm nay (nằm trong ±20% so với hôm qua), số tin đăng đang hoạt động (không biến động đột ngột)"  
  
"Khi sửa từ 4 file trở lên, khi đụng tới kết nối scheduler, khi thay đổi schema DB,  
 khi sửa lại khu vực đã từng bị revert trước đó → bắt buộc báo trước"  
  
"Thay đổi tạm thời (fallback/TODO/hardcoding) phải được ghi vào sổ theo dõi:  
 cần hoàn nguyên cái gì vào lúc nào, và nếu không hoàn nguyên thì sẽ xảy ra chuyện gì"

AI đọc các quy tắc này mỗi lần, và khi gặp tình huống tương ứng thì sẽ báo trước khi làm việc.

Phần 3. Những thứ đã không hoạt động

3.1 Cùng một bug lặp lại 7 lần — không nhìn được toàn bộ đường đi của dữ liệu

Lý do bug đơn vị giá xảy ra 7 lần là vì trong 6 giai đoạn thu thập → parser → chuẩn hóa → DB → API → UI, nếu chỉ sửa một chỗ thì nó lại phát sinh ở đường khác. Khả năng “nhìn toàn cục” là thứ mà tổ hợp người không phải lập trình viên + AI thiếu nhất. AI chỉ sửa đúng nơi được chỉ định, còn con người thì không biết rằng có những đường khác tồn tại.

3.2 Ô nhiễm dữ liệu 1,138 bản ghi — giá trị mặc định "tử tế" của AI

Khi parser thất bại trong việc trích xuất năm sản xuất, một đoạn code trả về getFullYear() đã được đưa vào. Từ góc nhìn của AI, có lẽ nó nghĩ rằng "năm hiện tại còn tốt hơn null". Kết quả: một chiếc Porter đời 2003 bị ghi vào DB thành đời 2026. Nếu không viết riêng cho AI rằng "không biết thì để null", nó sẽ tự điền vào một cái gì đó.

3.3 Thông báo Slack không hoạt động suốt 6 tháng — không giám sát hệ thống giám sát

Thông báo kết thúc trong trạng thái thất bại, và bản thân sự thất bại đó cũng không được ghi log, nên suốt 6 tháng mọi thứ im lặng. Trong thời gian đó pipeline có vài bất thường nhưng tôi lại tưởng là "không có vấn đề gì". Trong hệ thống được tạo bằng AI, trạng thái nguy hiểm nhất là trạng thái “trông có vẻ đang chạy tốt”. Hiện tại tôi đã đơn giản hóa về một đường Telegram duy nhất.

3.4 Tràn setInterval 32-bit — cái bẫy của ngôn ngữ

Nếu không biết setInterval chỉ nhận int32, bạn sẽ không biết rằng khi truyền 30 ngày tính bằng mili giây vào thì nó sẽ chạy ngay lập tức. Đăng nhập bị treo. AI không tự nguyện cảnh báo những edge case như vậy. Chỉ sau khi sự cố xảy ra thì quy tắc clamp mới được tạo ra.

3.5 ML overfitting — MAPE khi huấn luyện 8.56% vs thực chiến 42%

Sau khi đạt MAPE huấn luyện 8.56% với 75 features của LightGBM, tôi đã nghĩ là "ổn rồi". Thực chiến là 42%. Lý do: giới hạn mang tính cấu trúc của dữ liệu giá chào bán (không có giá giao dịch thực tế, hợp đồng khai thấp giá, margin của dealer). Một chuyên gia domain hẳn đã có thể biết điều này ngay từ đầu, nhưng tôi bị mắc kẹt trong suy nghĩ "chỉ cần kết quả học tốt là được".

Những suy nghĩ còn lại

Khi nhìn lại và tổng kết 238 ngày:

AI kéo tốc độ triển khai lên rất mạnh. Ngay cả người không biết code cũng có thể tạo ra một dịch vụ hoạt động được.
Nhưng chất lượng vận hành không tự động đi theo. Sự cố chắc chắn sẽ xảy ra, và AI sẽ không tự chủ động cảnh báo.
Công việc của người không phải lập trình viên chuyển từ viết code sang thiết kế quy tắc, giám sát và kiểm chứng. Việc chính trở thành đánh giá kết quả và ngăn tái diễn.

Đây là production do một mình tôi vận hành nên sample n=1. Tôi sẽ không khái quát hóa. Tôi tò mò về trải nghiệm của những người khác trong cùng điều kiện.

Liên kết

Dịch vụ: https://chajooin.com (so sánh·phân tích giá thị trường xe tải chở hàng)

Rất mong nhận được phản hồi. Đặc biệt tôi muốn biết mọi người giám sát trạng thái “trông có vẻ đang chạy tốt” như thế nào khi làm một mình.

5 bình luận

savvykang 2026-04-13

Vấn đề về trạng thái trông có vẻ đang vận hành tốt có lẽ có thể được giảm nhẹ phần nào nếu định kỳ thực hiện diễn tập khôi phục sự cố và xác định những đặc tính nào của dữ liệu được xem là bình thường.

workdriver 2026-04-13

Vâng, cảm ơn bạn vì ý kiến rất hay.
Khi hệ thống ngày càng lớn, đúng là việc quản lý trở nên quá sức.