“ทำเว็บบทความให้หน่อย ที่เหลือจัดการเองเลยนะ!”
AI ลุยงานเต็มที่ เพิ่มบทความ ทำหลายภาษา ใส่บทความที่เกี่ยวข้อง ลิงก์ภายใน ระบบค้นหา ตรวจคุณภาพ ตรวจความปลอดภัย ไปจนถึงระบบแก้อัตโนมัติ จากที่ควรเป็นร้านโชห่วยหน้าปากซอย กลายเป็นโรงงานยักษ์ที่มีฝ่ายแปล ฝ่ายตรวจ ห้องตรวจสอบบัญชี และ “คณะกรรมการอนุมัติลูกน้ำ”
สุดท้ายหน้าจอขึ้นมาว่า BUILD FAILED
AI: “แก้แล้วครับ” Build รอบต่อไป: พัง AI: “แก้อีกจุดแล้วครับ” พังอีก ล้มบอสตัวสุดท้ายได้ ก็มีบอสตัวสุดท้ายตัวใหม่โผล่มา บทความนี้จะอธิบายว่าทำไมถึงเป็นแบบนี้ และควรแก้ยังไง โดยใช้ Cloudflare Pages กับ Astro เป็นตัวอย่าง เป็นคำอธิบายทั่วไป ไม่ได้ฟันธงสาเหตุของเว็บไหนโดยเฉพาะ
1. Build คือการทำอะไร?
ต้นฉบับ Markdown รูปภาพ หน้าตาเว็บ และโค้ด เป็นแค่วัตถุดิบ ยังไม่ใช่เว็บที่เสร็จแล้ว Build คือการเอาวัตถุดิบพวกนี้มาแปลงเป็นหน้าเว็บและไฟล์ที่เบราว์เซอร์เปิดได้ ปกติ Astro จะสร้างไฟล์แบบคงที่ที่พร้อมขึ้นเว็บไว้ในโฟลเดอร์ชื่อ dist[1]
ต้นฉบับคือสูตรอาหาร Build คือการลงมือทำกับข้าว วางหัวหอมดิบกับตำราอาหารไว้บนโต๊ะแล้วบอกว่า “อาหารมาแล้วค่ะ” ลูกค้าคงไม่ยอม
2. Cloudflare ดูแลส่วนไหน?
Cloudflare Pages ดึงโค้ดจาก Git มารันคำสั่ง Build ที่เราตั้งไว้ แล้วเอาผลลัพธ์ขึ้นเว็บให้ได้[2] ลำดับทั่วไปคือ ดึงโค้ด → ติดตั้งเครื่องมือ → ตรวจเบื้องต้น → สร้างหน้าเว็บ → ตรวจผลลัพธ์ → Deploy (ขึ้นเว็บ) ขั้นตอนจริงขึ้นอยู่กับการตั้งค่าของแต่ละโปรเจกต์
Build คือการผลิต Deploy คือการส่งของและขึ้นเว็บ ถ้า Build รอบใหม่พัง เวอร์ชันนั้นก็ขึ้นเว็บไม่ได้ ตัวอาคารโรงงาน Cloudflare เป็นคนจัดให้ แต่สายการผลิตที่วกวนเหมือนเขาวงกตข้างใน หลายครั้งเป็นโค้ดของเว็บเราเอง
3. เว็บที่ลงบทความอัตโนมัติ วุ่นตั้งแต่ยังไม่ได้สร้างหน้าเว็บ
บล็อกธรรมดาแค่แปลงต้นฉบับเป็น HTML ก็จบ แต่ระบบลงบทความอัตโนมัติอาจเพิ่มงานอีกเพียบทั้งก่อนและหลัง เช่น บทความนี้ลงได้หรือยัง คำแปลครบไหม รหัสบทความกับ URL ตรงกันไหม บทความที่เกี่ยวข้องและลิงก์ภายในถูกไหม สร้างข้อมูลค้นหาได้ไหม หัวข้อ คำอธิบายรูป โฆษณา และกฎความปลอดภัยผ่านหมดหรือเปล่า
ดูทีละอย่างก็มีเหตุผลทั้งนั้น ปัญหาคือ แก้แค่บรรทัดเดียว ทุกแผนกต้องกลับไปเข้าแถวประชุมเช้าใหม่หมด แค่อยากแก้จุดเดียว พนักงานทั้งโรงงานใส่หมวกนิรภัยมารวมตัว
4. บทความกับภาษาเยอะขึ้น ทำไมถึงยากขึ้น?
10,000 หน้าไม่ได้แปลว่างานจะเพิ่มเป็น 10,000 เท่าเสมอไป แต่ไฟล์จะเยอะขึ้น บทความเชื่อมโยงกันมากขึ้น และทุกภาษาที่เพิ่มมาก็มี URL คู่กันกับข้อมูลค้นหาของตัวเอง ถ้า Build ทุกรอบเอาทุกบทความไปเทียบกับบทความอื่นทั้งหมด ยิ่งเว็บใหญ่ก็ยิ่งอืด
เพราะฉะนั้นควรคำนวณใหม่เฉพาะส่วนที่เปลี่ยน เก็บผลที่ใช้ซ้ำได้ไว้ และจับเวลาทุกขั้นตอน อะไรช้าให้ดูจากตัวเลข ไม่ใช่เดาเอา เพิ่มหนังสือเล่มเดียว แต่ต้องจัดชั้นหนังสือห้องสมุดใหม่ทั้งประเทศ บรรณารักษ์คงร้องไห้ก่อน
5. ทำไมแก้ error หนึ่งแล้วเจออีกตัว?
ถ้าขั้นตอนรันต่อกันเป็นแถว error ข้างหน้าจะบัง error ข้างหลังไว้ ตรวจต้นฉบับติด → แก้ → ตรวจลิงก์ติด → แก้ → สร้างหน้าเว็บติด → แก้ → ข้อมูลค้นหาติด วนไปเรื่อย ๆ
ไม่ได้แปลว่าการแก้ทุกครั้งสร้างบั๊กใหม่เสมอไป ปัญหาอาจมีอยู่หลายตัวตั้งแต่แรก แค่รอคิวอยู่ แต่ในทางกลับกัน การแก้ก็ทำของอื่นพังได้จริง จะรู้ว่าเป็นแบบไหนต้องดูจาก Log กับประวัติการแก้ไข เปิดประตูดันเจี้ยนก็เจอประตูอีกบาน และทุกบานเขียนว่า “ชั้นสุดท้าย”
6. สาเหตุที่ Build พังที่เจอบ่อย 6 แบบ
1) โค้ดและแพ็กเกจ: พิมพ์ผิด ขาดแพ็กเกจ เวอร์ชันไม่ตรง 2) ข้อมูลที่ใส่เข้าไป: ต้นฉบับหาย รูปแบบไม่ตรง 3) กฎการตรวจ: สร้างหน้าได้ แต่โดนกฎตรวจขวางไว้ 4) ทรัพยากร: ชนเพดานเวลา หน่วยความจำ หรือจำนวนไฟล์ 5) สภาพแวดล้อม: การตั้งค่าในเครื่องเรากับฝั่ง Cloudflare ไม่เหมือนกัน 6) ขั้นตอนขึ้นเว็บ: ตรวจรอบสุดท้ายหรืออัปโหลดไม่ผ่าน
Cloudflare Pages จะถือว่า Build พังเมื่อคำสั่ง Build จบด้วยรหัสที่ไม่ใช่ 0[2] แปลว่าคำว่า “Build failed” บรรทัดสุดท้ายเป็นแค่ผลลัพธ์ ไม่จำเป็นต้องเป็นต้นเหตุ ดูแค่หน้าปกนิยายสืบสวนก็ไม่รู้หรอกว่าใครเป็นคนร้าย
7. อ่าน Log ให้หา “จุดแรกที่พัง”
เปิด Build log ได้จากหน้ารายละเอียดการ Deploy ของ Cloudflare[3] อย่ามัวจ้องข้อความสีแดงบรรทัดสุดท้าย ให้หา ขั้นตอนแรกที่พังจริง ๆ แล้วแยกว่าเป็นเรื่องข้อมูล โค้ด กฎ ทรัพยากร หรือสภาพแวดล้อม ถ้ารันขั้นนั้นแยกได้ก็ลองทำให้พังซ้ำแยกออกมา แยกให้ออกว่าอะไรคือแก้ขัด อะไรคือแก้ที่ต้นเหตุ แก้เสร็จแล้วต้องเช็กว่าขั้นถัดไปผ่านด้วย
ตะโกน “รันใหม่ทั้งหมด!” 100 รอบ ไฟล์ที่ไม่มีอยู่ก็ไม่โผล่มาเอง ที่ต้องการไม่ใช่ความฮึด แต่เป็นเลขเครื่องที่พัง
8. ขีดจำกัดของ Cloudflare ไม่ได้มีแค่อันเดียว
ตามเอกสารทางการ ณ วันที่ 10 ตุลาคม 2026 Pages แบบฟรีให้ Build ได้ 500 ครั้งต่อเดือน รันพร้อมกันได้ 1 รายการ แต่ละครั้งหมดเวลาที่ 20 นาที และมีไฟล์แบบคงที่ได้สูงสุด 20,000 ไฟล์ต่อเว็บ[4] เว็บใหญ่ต้องระวังว่าไม่ได้นับแค่ HTML รูปภาพและไฟล์สำหรับค้นหาก็นับรวมด้วย
ส่วน Workers มีขีดจำกัดจำนวนคำขอและเวลาทำงานแยกอีกชุด คำขอของ Pages Functions อาจถูกนับรวมไปที่ Workers ได้ แต่ โควตา Workers หมด ไม่ได้แปลว่านั่นคือสาเหตุที่ Build ของ Pages พัง[4][5] ถ้าฝ่ายบัญชีตะโกนว่า “งบหมดแล้ว!” ถามก่อนว่ากระเป๋าไหน
9. ดูล้ำ ไม่ได้แปลว่าจำเป็น
ข้อมูลส่วนตัวรั่ว ช่องโหว่ความปลอดภัยร้ายแรง หรือหน้าสำคัญพัง แบบนี้ต้องหยุดไม่ให้ขึ้นเว็บ แต่ถ้าแค่ลำดับบทความที่เกี่ยวข้องดูไม่ค่อยเข้าที่ ต้องหยุดทั้งเว็บเลยไหม? นั่นเป็นอีกเรื่อง
แบ่งการตรวจเป็น 3 กลุ่ม: ต้องหยุดไม่ให้ขึ้นเว็บ / แค่เตือน / แยกไปรันเป็นรอบ ๆ ต่างหาก เกณฑ์คือความเสียหายจริงต่อคนอ่านและคนดูแลเว็บ ไม่ใช่ชื่อการตรวจฟังดูเท่แค่ไหน ถ้าปิดโรงงานถาวรเพราะลูกบิดประตูห้องตรวจมีฝุ่น แปลว่าฝ่ายตรวจยึดงานหลักไปแล้ว
10. กับดักของการบอก AI ว่า “จัดการเลย”
“ทำให้ติดอันดับ Google ด้วย” “เพิ่มภาษา” “อย่าให้พังอีก” “เพิ่มการตรวจอีกอัน” AI เพิ่มฟังก์ชันให้ได้เร็วมาก แต่ละอย่างดูถูกต้อง แต่ถ้าเอามาต่อกันเป็นสายเดียวหมด อาจกลายเป็น ระบบที่บทความเรื่องเดียวจะออกได้ต่อเมื่อทุกแผนกปั๊มตราครบ
เรื่องนี้ไม่ใช่ปัญหาของ AI อย่างเดียว คนเขียนเองก็เพิ่มฟีเจอร์เกินจนกลายเป็นหนี้ทางเทคนิคได้เหมือนกัน AI แค่ทำได้เร็วกว่า เราไม่ต้องเขียนโค้ดเองทุกบรรทัด แต่ต้องขีดเส้นให้ชัดว่าอะไรต้องรักษาไว้ อะไรรอได้ และควรหยุดตรงไหน สั่ง AI ให้กวาดพื้น มันตั้งคณะกรรมการกำกับหุ่นยนต์ดูดฝุ่นก่อน พื้นก็ยังสกปรกอยู่
11. กู้ระบบใน 3 ขั้น
ห้ามเลือดก่อน: พักฟีเจอร์ใหม่ไว้ก่อน รักษาเวอร์ชันล่าสุดที่ขึ้นเว็บได้ปกติไว้ แล้วหาจุดแรกที่พัง อย่าปิดการตรวจข้อมูลส่วนตัวหรือความปลอดภัยแบบส่ง ๆ
แยกงานออก: ใน Build ทุกรอบ ให้เหลือแค่การสร้างหน้าเว็บที่จำเป็นจริง ๆ งานหนักอย่างวิเคราะห์ทั้งเว็บหรือการตรวจเล็ก ๆ น้อย ๆ ให้แยกไปรันต่างหาก Cloudflare มี Build watch paths (ใช้กำหนดว่าไฟล์ไหนเปลี่ยนแล้วค่อยเริ่ม Build) และแคช Build[6][7] แต่แค่เปิดใช้ ไม่ได้ทำให้สคริปต์ที่เราเขียนเองซึ่งประมวลผลทั้งเว็บ เปลี่ยนไปทำเฉพาะส่วนที่เปลี่ยนโดยอัตโนมัติ
กันไม่ให้เกิดซ้ำ: จดเวลาของแต่ละขั้น ประเภทของ error จำนวนไฟล์ที่สร้าง อัตราที่ขึ้นเว็บสำเร็จ และเวลาที่ใช้กู้คืน ความสำเร็จไม่ใช่ “AI บอกว่าแก้แล้ว” แต่คือเวอร์ชันที่ผ่านการตรวจครบและขึ้นเว็บได้จริง
12. สรุป: บอสตัวสุดท้ายอาจเป็นสายไฟในโรงงานของเราเอง
ระบบที่มีบทความเยอะ หลายภาษา มีลิงก์ที่เกี่ยวข้องและตรวจคุณภาพ เป็นงานที่ยากจริง แต่ ไม่จำเป็นต้องยัดงานยาก ๆ ทั้งหมดไว้ใน Build รอบเดียว ลองถามใหม่ว่า คำเตือนนี้ทำไมต้องหยุดการขึ้นเว็บ ทำไมต้องคำนวณใหม่ทั้งหมดทุกครั้ง และงานไหนแยกไปทำต่อเองได้
ที่ดีที่สุดคือ ตอนเรานอนหลับ บทความเสี่ยงโดนกันไว้ บทความที่ปลอดภัยขึ้นเว็บตามปกติ และมีแค่ขั้นตอนที่พังเท่านั้นที่ส่งแจ้งเตือนมา
AI: “เสร็จหมดแล้ว!” คน: “แล้วขึ้นเว็บยัง?” AI: “Build พังครับ”
สิ่งเดียวที่ทำงานอัตโนมัติเต็มรูปแบบ คือเครื่องผลิตข้อแก้ตัว
เอกสารอ้างอิง (7 รายการ)
- Astro Docs, CLI reference: astro build docs.astro.build
- Cloudflare Docs, Build configuration (updated 2026-09-18) developers.cloudflare.com
- Cloudflare Docs, Debugging Pages (updated 2026-06-02) developers.cloudflare.com
- Cloudflare Docs, Pages limits (updated 2026-09-05) developers.cloudflare.com
- Cloudflare Docs, Workers limits (updated 2026-09-05) developers.cloudflare.com
- Cloudflare Docs, Build watch paths (updated 2026-04-21) developers.cloudflare.com
- Cloudflare Docs, Build caching (updated 2026-05-27) developers.cloudflare.com
