ใช้เวลา 9 วันในการเปิดตัว bkamp.ai ด้วย Claude Code และได้นำเคล็ดลับนั้นมาใส่ไว้ในปลั๊กอิน bkit

 (bkit.ai)
2 คะแนน โดย agentkay 26 일 전 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp

bkit — ใช้ Claude Code ให้ “ถูกวิธี” ด้วย Context Engineering

ในเดือนธันวาคม 2025 ผมได้เปิดตัวบริการชื่อ bkamp.ai

  • 11 ไมโครเซอร์วิส
  • พอร์ทัลที่สร้างบน Next.js
  • AWS EKS + GitOps (ArgoCD)
  • โครงสร้างพื้นฐานด้วย Terraform

และผมนำทั้งหมดนี้ขึ้นสู่โปรดักชันได้ภายใน เพียง 9 วันเท่านั้น

ผู้พัฒนามีแค่ผมคนเดียว
และ AI ที่ใช้คือ Claude Code

บทความนี้ไม่ได้เล่าแค่ว่า “ทำได้เร็ว”

หลายกรณีศึกษาการพัฒนาด้วย AI มักอธิบายแบบนี้:

  • “สร้างด้วย AI ได้ภายใน N วัน”
  • “แค่เขียนพรอมป์ต์ให้ดีก็พอ”

แต่สิ่งที่ผมรู้สึกจริง ๆ ระหว่างการพัฒนา 9 วันนั้นแตกต่างออกไปอย่างสิ้นเชิง

AI เขียนโค้ดได้ดีจริง
แต่ AI ไม่ได้เป็นคนตัดสินใจว่าจะต้องเขียนอะไร

สิ่งที่ตัดสินเรื่องนั้นในท้ายที่สุดคือ:

  • การออกแบบ
  • กฎ
  • หน่วยงานของงาน
  • วิธีการตรวจสอบ

และผมนิยามสิ่งนี้ว่า Context Engineering

Context Engineering คืออะไร

ถ้าจะพูดให้สั้นคือ:

ไม่ใช่การเขียนพรอมป์ต์ให้เก่ง
แต่คือการ ออกแบบสภาพแวดล้อมที่ AI ใช้ทำงาน

ตัวอย่างเช่น:

  • สร้างเอกสารออกแบบก่อน
  • แบ่งหน่วยงานโดยอ้างอิงตามเอกสาร
  • สร้างกฎสำหรับตรวจสอบผลลัพธ์
  • สร้างวงจรที่ทำซ้ำได้

กล่าวคือ

AI ไม่ใช่ “ผู้เขียน”
แต่เป็น เอนจินที่เรนเดอร์ตามคอนเท็กซ์ที่กำหนดไว้

วิธีที่ใช้จริงใน bkamp

1. Day 0 — สร้างกฎก่อนเขียนโค้ด

คอมมิตแรกไม่มีโค้ดเลย

สิ่งที่ผมสร้างแทนคือ:

  • .claude/CLAUDE.md (ประมาณ 150 บรรทัด)
  • เอกสารข้อกำหนด
  • เอกสารกลยุทธ์

ในนั้นมีการกำหนดสิ่งต่อไปนี้:

  • วงจร PDCA (Plan → Do → Check → Act)
  • ทุกผลลัพธ์ต้องให้มนุษย์ตรวจสอบ
  • วางแผนเป็นภาษาเกาหลี โค้ดเป็นภาษาอังกฤษ คอมมิตเป็นภาษาเกาหลี
  • หน่วยงานของงานและวิธีดำเนินการ

กฎราว 100 บรรทัด นี้เป็นตัวกำหนดการพัฒนาทั้งหมดหลังจากนั้น

2. หน่วยงานของงานไม่ใช่ “ฟีเจอร์” แต่เป็น “เอกสาร”

โดยทั่วไปมักจะสั่งแบบนี้:

  • “ช่วยสร้างฟีเจอร์แชตให้หน่อย”

แต่ในการทำงานจริง ผมทำแบบนี้:

  • “ช่วย implement หัวข้อ 3.2 ของเอกสาร 7”

ความต่างนี้ใหญ่มาก

ในมุมของ AI:

  • ฟีเจอร์ → ต้องตีความ (มีความไม่แน่นอน)
  • เอกสาร → implement ตามนั้นได้เลย (มีความแน่นอน)

ผลลัพธ์คือ:

ความแปรปรวนของเอาต์พุตแทบหายไปหมด

3. หนึ่งวัน = หนึ่งวงจร PDCA

การพัฒนาดำเนินไปแบบนี้:

  • Plan (ออกแบบ)
  • Do (ลงมือทำ)
  • Check (วิเคราะห์ Gap)
  • Act (แก้ไข)

และวนซ้ำวงจรนี้ เป็นรายวัน

ข้อดีของวิธีนี้คือ:

  • คอนเท็กซ์อัปเดตล่าสุดอยู่เสมอ
  • ขอบเขตงานชัดเจน
  • AI เข้าใจชัดว่าตอนนี้ “ต้องทำอะไร”

4. สร้าง checkpoint แล้วกล้ารื้อใหม่อย่างเด็ดขาด

ในวันที่ 4 ผมปรับโครงสร้างฟรอนต์เอนด์ใหม่ทั้งหมด

แต่ก่อนหน้านั้น มีสิ่งหนึ่งที่ต้องทำเสมอคือ:

  • สร้าง checkpoint ที่ rollback ได้

เมื่อทำแบบนี้:

ถึงล้มเหลวก็ยังปลอดภัย
→ เลยสามารถเปลี่ยนโครงสร้างครั้งใหญ่ได้อย่างกล้า ๆ

5. ค่อยรวมอินฟราสตรักเจอร์ทีเดียวในตอนท้าย

ในวันที่ 8 ภายในวันเดียว ผมรวมสิ่งต่อไปนี้เข้าด้วยกัน:

  • Terraform
  • Kubernetes
  • CI/CD
  • ArgoCD

เหตุผลที่ทำได้ก็ง่ายมาก:

เพราะก่อนหน้านั้นทุกโครงสร้างถูกจัดระเบียบไว้เรียบร้อยแล้ว

แพตเทิร์นสำคัญที่ได้จากตรงนี้

แพตเทิร์นที่ถูกทำซ้ำตลอด 9 วันนี้มีดังนี้:

  1. กำหนดกฎก่อน
  2. สร้างการออกแบบก่อน
  3. ทำงานโดยยึดเอกสารเป็นหลัก
  4. วนซ้ำด้วยวงจร PDCA
  5. สร้าง checkpoint
  6. แก้ความไม่สอดคล้องกันที่เอกสาร
  7. โค้ดเป็นสิ่งสุดท้าย

แต่จะรักษาวิธีนี้ต่อไปได้จริงหรือ

ตรงนี้เองที่เกิดปัญหา

วิธีนี้ทรงพลังมาก แต่:

ถ้าจะให้มนุษย์คอยดูแลรักษาต่อเนื่อง มันหนักเกินไป

  • ต้องจำกฎอยู่ตลอด
  • ต้องคอยทำให้เอกสารถูกต้องสอดคล้องกัน
  • ต้องรักษาวินัย PDCA ทุกครั้ง

เพราะแบบนั้นจึงเกิด bkit ขึ้นมา

bkit คืออะไร

bkit คือปลั๊กอินสำหรับ Claude Code

แต่ไม่ได้เป็นเพียงเครื่องมือธรรมดา

มันคือการนำวิธีทำงานที่ใช้ใน bkamp
มาสร้างเป็นระบบแบบตรงตัว

แนวคิดที่สำคัญที่สุด: PDCA = state machine

ใน bkit มีการ implement PDCA ไว้แบบนี้:

  • สถานะ: plan, design, do, check, act ฯลฯ
  • การเปลี่ยนผ่าน: กฎการย้ายระหว่างสถานะ
  • guard: การตรวจสอบเงื่อนไข

ตัวอย่างเช่น:

  • ถ้าอัตราความสอดคล้องระหว่างการออกแบบกับการ implement มากกว่า 90% → ผ่าน
  • ถ้าไม่ใช่ → รันลูปแก้ไขอัตโนมัติ

กล่าวคือ

“ตรวจทาน → แก้ไข” จะถูกวนซ้ำโดยอัตโนมัติ

โครงสร้างที่เปลี่ยน Context Engineering ให้เป็นระบบ

bkit ประกอบด้วยองค์ประกอบต่อไปนี้:

  • Skills (ความรู้เชิงโดเมน)
  • Agents (พฤติกรรมตามบทบาท)
  • PDCA state machine
  • ระบบ inject context
  • Quality Gate (การตรวจสอบ)
  • Audit Log (บันทึก)
  • Feedback Loop (การวนซ้ำอัตโนมัติ)

ถ้าจะสรุปทั้งหมดนี้ในประโยคเดียว:

ไม่ใช่การใช้ AI
แต่เป็นการ สร้างระบบที่ AI ใช้ทำงาน

ผลลัพธ์

ผลลัพธ์ที่ได้จากวิธีนี้มีดังนี้:

  • รองรับ Claude Code ต่อเนื่อง 79 เวอร์ชัน
  • การทดสอบมากกว่า 4,000 รายการ ล้มเหลว 0
  • กฎตรวจสอบ CI มากกว่า 200 รายการ
  • Docs และ Code ซิงก์กันอย่างสมบูรณ์

บทสรุป

นี่ไม่ใช่เรื่องที่ AI ฉลาดขึ้น

แต่มันคือเรื่องของการเลื่อนงานของมนุษย์ให้มาอยู่ข้างหน้าก่อน

  • ออกแบบก่อน
  • วางกฎก่อน
  • ตรวจสอบก่อน

หลังจากนั้น:

  • AI เป็นผู้ลงมือทำ
  • ระบบเป็นผู้ตรวจสอบ
  • มนุษย์เป็นผู้อนุมัติ

TL;DR

  • มีข้อจำกัดถ้าพึ่งพรอมป์ต์อย่างเดียว
  • Context Engineering คือแกนหลัก
  • AI ไม่ใช่ผู้เขียน แต่เป็นตัวเรนเดอร์
  • เวิร์กโฟลว์สำคัญกว่าตัวโมเดล

ลิงก์

หากมีความคิดเห็นหรือฟีดแบ็กเกี่ยวกับแนวทางนี้ ผมยินดีมาก ๆ ครับ

บทความที่เกี่ยวข้อง

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น