บทที่ 12 — ลงมือจริงหนึ่งรอบเต็ม
บทนี้รวมทุกอย่างเข้าด้วยกัน: งานจริงหนึ่งชิ้น ตั้งแต่ประโยคที่คุณพิมพ์สั่ง AI จนเว็บที่ลูกค้าเปิดได้เปลี่ยนไป
โจทย์ตัวอย่าง: เพิ่มปุ่ม "ขอใบเสนอราคา" ในหน้ารายละเอียดสินค้า ให้กดแล้วเด้งไปหน้าขอใบเสนอราคาพร้อมเติมรหัสสินค้าให้อัตโนมัติ
เดินทีละขั้น
หนึ่งงาน หนึ่งรอบเต็ม
1. เตรียมตัว
ดึงงานล่าสุดลงมาก่อนเสมอ กันไม่ให้ทำงานบนของเก่า
cd apexhuas
git checkout develop
git pull
2. สั่ง AI
บอกเป้าหมาย ข้อจำกัด และเกณฑ์ว่าเสร็จเมื่อไหร่ ไม่ต้องบอกวิธีเขียนโค้ด
เพิ่มปุ่มขอใบเสนอราคาในหน้าสินค้า
- กดแล้วไปหน้า /quote พร้อมเติม SKU ให้อัตโนมัติ
- ใช้ปุ่มจาก components/ui ที่มีอยู่ ห้ามสร้างสไตล์ใหม่
- ต้องใช้ได้ทั้งภาษาไทยและอังกฤษ
- เช็คจอมือถือ 390px ด้วย
- ให้ typecheck/lint/build ผ่านก่อนเปิด PR
3. AI ทำงาน
มันจะแตก branch, อ่าน AGENTS.md และ DESIGN.md, แก้ไฟล์, เพิ่มข้อความสองภาษา, รันตรวจ, เปิดเบราว์เซอร์ดูผล ถ้าไม่ผ่านก็วนแก้เอง
หน้าที่คุณตอนนี้: อ่านสิ่งที่มันรายงาน ถ้าเห็นมันเริ่มออกนอกลู่ให้ทักทันที
4. ตรวจงานก่อนเปิด PR
ดูว่ามันแตะไฟล์อะไรบ้าง มีไฟล์แปลกปลอมไหม แล้วเปิดเว็บในเครื่องกดปุ่มนั้นด้วยตัวเอง
git status
git diff
npm run dev # แล้วเปิด localhost:3000 กดจริง
5. เปิด PR เข้า develop
PR ต้องอธิบายว่าทำอะไร ทำไม ทดสอบอะไรมาแล้ว
gh pr create --base develop --title "Add quote CTA to product page"
6. รอ CI
ดูจนเขียวครบทุกด่าน ถ้าแดงให้อ่าน log แล้วบอก AI ว่าแดงเพราะอะไร (แปะ log ให้มันดูได้เลย)
gh pr checks --watch
7. merge เข้า develop
ตรงนี้ยังไม่มีอะไรขึ้นเว็บจริง เป็นการรวมงานเข้าเส้นหลักของทีม
gh pr merge <เลข> --merge --delete-branch
8. promote ขึ้น uat
เปิด PR จาก develop → uat แล้ว merge — คิดให้ดีก่อนกด เพราะหลังจากนี้ลูกค้าเห็นทันที
gh pr create --base uat --head develop --title "Promote: quote CTA"
9. ดูระบบ deploy ทำงาน
build image → push → server ดึงไปรัน → ตรวจสุขภาพเว็บ ดูได้ที่แท็บ Actions
gh run list --branch uat --limit 2
10. เปิดเว็บจริงยืนยัน
เปิด https://apexhuas.choiceflowhub.com แล้วกดปุ่มที่เพิ่งเพิ่มด้วยตัวเอง — health check บอกได้แค่ว่าเว็บขึ้น ไม่ได้บอกว่าฟีเจอร์ทำงานถูก
จบรอบ
Checklist ก่อนกด merge เข้า uat
พิมพ์แปะไว้ข้างจอได้เลย
ตรวจ 6 ข้อนี้ก่อนปล่อยของ (คลิกดูว่าทำไม)
คลิกชั้นใดก็ได้เพื่อดูรายละเอียด
CI เขียวครบทุกด่าน
เปิดดูเองบน GitHub อย่าเชื่อคำบอกเล่าของใครรวมถึง AI — ถ้าแดงแม้ด่านเดียว ห้าม merge
เปิดดูฟีเจอร์ด้วยตาตัวเอง
อย่างน้อยในเครื่อง (npm run dev) เพราะการตรวจอัตโนมัติจับได้แค่โค้ดพัง ไม่ได้จับว่าใช้งานแล้วตรงใจหรือไม่
ดูรายการไฟล์ที่เปลี่ยน
ในแท็บ Files changed ของ PR — ถ้ามีไฟล์ที่ไม่น่าเกี่ยวข้องโผล่มา ให้ถามก่อนว่าทำไม
ไม่มีความลับหลุดเข้ามา
ไล่สายตาหา token, รหัสผ่าน, connection string ถ้าหลุดขึ้น repo ถือว่ารั่วแล้ว ต้องเปลี่ยนของจริงทันที
เอกสารอัปเดตแล้วถ้าจำเป็น
แตะ API/ฐานข้อมูล/flow หลัก ต้องอัปเดตเอกสารใน PR เดียวกัน ไม่งั้นเอกสารจะโกหกในอีกไม่กี่สัปดาห์
รู้ว่าจะย้อนกลับยังไงถ้าพัง
รู้ว่ามี image ป้ายเวอร์ชันเก่าอยู่ และรู้คำสั่งย้อนกลับ — ความมั่นใจไม่ได้มาจากการหวังว่าจะไม่พัง แต่มาจากการรู้ว่าถ้าพังแล้วทำยังไง
จังหวะที่ควรหยุดแล้วถามคน
AI จะเดินหน้าทำต่อเสมอถ้าคุณไม่ห้าม — สถานการณ์เหล่านี้ควรหยุดคุยกับทีมก่อน
เดินหน้าได้ vs ควรหยุดถาม
เดินหน้าได้เลย
- เพิ่ม/แก้หน้าเว็บตามที่ตกลงไว้
- แก้บั๊กที่มีวิธีแก้ชัดเจน
- ปรับข้อความ ปรับสไตล์ตามระบบดีไซน์เดิม
- เพิ่มเทสต์ เพิ่มเอกสาร
ควรหยุดถามก่อน
- เปลี่ยนโครงสร้างฐานข้อมูลที่มีข้อมูลจริงอยู่
- เพิ่ม library ตัวใหญ่หรือเปลี่ยนเทคโนโลยีหลัก
- แตะระบบ auth, การชำระเงิน, หรือสิทธิ์การเข้าถึง
- ตัดสินใจเรื่องธุรกิจ (ราคา ค่าส่ง นโยบายคืนสินค้า)
- ลบข้อมูลหรือลบทรัพยากรบน cloud
- งานที่ใหญ่เกินกว่าจะรีวิวไหวใน PR เดียว
30 วันแรกของคุณควรเป็นแบบไหน
เส้นทางจากมือใหม่สู่คนที่ปล่อยของเองได้
-
สัปดาห์ที่ 1 — อ่านและลอง
clone repo, รันเว็บในเครื่อง, อ่าน AGENTS.md กับ implementation-plan.md, เปิดดู PR เก่า 3-4 อันว่าเขาทำกันยังไง
-
สัปดาห์ที่ 2 — งานเล็กจบเอง
หยิบงานเล็ก ๆ (แก้ข้อความ ปรับ layout) ทำครบวงจร: สั่ง AI → รีวิว → PR → CI → merge เข้า develop
-
สัปดาห์ที่ 3 — ลงสนามจริง
รับงานฟีเจอร์จริงหนึ่งชิ้น และลอง promote ขึ้น uat ด้วยตัวเองครั้งแรก โดยมีคนดูอยู่ห่าง ๆ
-
สัปดาห์ที่ 4 — เข้าใจทั้งท่อ
ลอง SSH เข้า server ดู log จริง, ลองย้อนเวอร์ชันใน environment ทดสอบ, อ่าน ADR ทั้งหมดให้เข้าใจว่าทำไมระบบเป็นแบบนี้
ข้อสอบปลายทาง
-
เปิด GitHub ดูผล CI ด้วยตาตัวเอง แล้วเปิดเว็บกดใช้ฟีเจอร์นั้นจริง ๆ ทั้งสองอย่างใช้เวลารวมไม่ถึง 2 นาที แต่กันการปล่อยของพังขึ้นเว็บได้จริง
-
1) เปิดแท็บ Actions ดูว่างาน deploy ผ่านหรือแดง 2) ถ้าผ่านแต่เว็บพัง ให้ย้อน image กลับเวอร์ชันก่อนหน้าเพื่อให้เว็บกลับมาก่อน 3) ค่อยไล่ log หาสาเหตุ — ลำดับสำคัญ: ทำให้ใช้งานได้ก่อน แล้วค่อยหาสาเหตุ
-
อย่าสั่งรวดเดียว ให้แบ่งเป็นก้อนที่รีวิวไหว (โครงสร้างข้อมูล → หน้าจอ → ต่อ provider จริง) และเรื่องการชำระเงินต้องคุยกับทีม/ลูกค้าก่อนเสมอ เพราะเป็นทั้งเรื่องธุรกิจและความปลอดภัย ไม่ใช่เรื่องที่ AI ควรตัดสินใจแทน
บทสุดท้าย: คำสั่งที่ใช้บ่อย ศัพท์ และปัญหาที่เจอบ่อย — ไว้เปิดดูตอนทำงานจริง