บทความนี้เป็นหน้า สอน Claude Code แบบลงมือทำ สำหรับคนที่ติดตั้ง Claude Code แล้ว และอยากลอง workflow แรกให้จบในเวลาประมาณ 60 นาที เหมาะกับคนที่ค้นหา Claude Code วิธีใช้, สอนใช้ Claude Code หรืออยากเห็นตัวอย่างทำงานกับ repo จริง

ถ้าคุณยังไม่รู้ว่า Claude Code คืออะไร หรืออยากอ่านภาพรวม Opus 4.8, commands ใหม่, Skills, Subagents, MCP และ SPK ก่อน ให้เริ่มจาก คู่มือ Claude Code สำหรับมือใหม่ 2026 หน้านั้นเป็น pillar หลัก ส่วนหน้านี้คือ workshop ลงมือทำครับ

เป้าหมายของ tutorial นี้

ให้ Claude Code อ่าน project จริง
สร้างหรืออัปเดต CLAUDE.md
สั่งให้วางแผนก่อนแก้ไฟล์
แก้บั๊กเล็กหรือเพิ่ม test แบบควบคุม scope
รัน verification จริง ไม่จบแค่คำว่า done
ดู diff และเตรียม commit หรือ PR อย่างปลอดภัย

เนื้อหาในบทความนี้

Tutorial นี้ต่างจากคู่มือหลักอย่างไร?

หน้าใหญ่ของเราใช้ตอบคำถามกว้าง ๆ เช่น Claude Code คืออะไร เหมาะกับใคร ใช้ต่างจาก Cursor อย่างไร และควรเริ่มยังไง ส่วนหน้านี้จะไม่แข่ง intent นั้นครับ

หน้านี้ตอบคำถามอีกแบบ: เปิด Claude Code แล้วควรทำอะไรทีละขั้น เพื่อให้ได้งานจริงโดยไม่หลุด scope?

คู่มือหลัก: ภาพรวม, concept, ฟีเจอร์ใหม่, best practice, เครื่องมือใน ecosystem
หน้านี้: hands-on flow, prompt ที่ใช้จริง, stop condition, verification, diff review

ก่อนเริ่ม: เลือก project ที่เสี่ยงต่ำ

อย่าเริ่ม tutorial นี้กับ production payment, migration ฐานข้อมูล, auth flow สำคัญ หรือ repo ที่ไม่มี test เลย ถ้าเพิ่งเริ่ม ให้เลือกงานเล็กที่ rollback ได้ เช่น README, unit test, copy, lint fix หรือ bug ที่มี reproduction ชัด

มี git repository
รู้คำสั่ง run test หรือ build อย่างน้อย 1 คำสั่ง
มี branch แยก ไม่ทำบน production branch
ไม่มี secret อยู่ใน prompt หรือไฟล์ที่ตั้งใจให้ AI อ่าน

git status
git checkout -b claude-code-tutorial

ถ้า project ยังรกมาก ให้เริ่มจาก read-only ก่อนหนึ่งรอบ อย่าให้แก้ไฟล์ทันที

Step 1: เปิด Claude Code และให้มันอ่าน project ก่อน

เข้า folder project แล้วเปิด Claude Code:

cd your-project-folder
claude

Prompt แรกไม่ควรเป็น “แก้ให้หน่อย” แต่ควรให้มันทำความเข้าใจ context ก่อน:

อ่าน project นี้แบบ read-only ก่อน สรุปว่า project ทำอะไร โครงสร้างหลักอยู่ที่ folder ไหน มีคำสั่ง test/build/lint อะไร และมี risk อะไรที่ควรระวังก่อนแก้ไฟล์ ห้ามแก้ไฟล์ในรอบนี้

สิ่งที่คุณควรได้กลับมาไม่ใช่คำตอบสวย ๆ แต่เป็น map ของ project: entry point, tech stack, test command, config สำคัญ และจุดเสี่ยง

Step 2: สร้าง CLAUDE.md ให้ agent ไม่ต้องเดาทุกครั้ง

CLAUDE.md คือ memory ระดับ project สำหรับบอกกติกาให้ Claude Code อ่านทุก session เช่นคำสั่ง test, folder ที่ห้ามแตะ, coding style, deploy rule และ proof ที่ต้องมี

ช่วยสร้าง CLAUDE.md จากไฟล์จริงใน project นี้ โดยใส่เฉพาะข้อมูลที่ verify จาก source แล้วเท่านั้น ต้องมี: purpose, source map, commands, conventions, guardrails, verification checklist และสิ่งที่ห้ามเดา

หลัง Claude เสนอไฟล์แล้ว อย่าเพิ่ง accept ทั้งหมดทันที ให้ตรวจ 3 อย่าง:

คำสั่ง test/build ถูกจริงไหม
มันอ้าง folder หรือ framework ที่ไม่มีอยู่จริงหรือเปล่า
มี rule ที่กว้างเกินไปจนขัด workflow ทีมไหม

ถ้าไม่แน่ใจ ให้สั่งเพิ่ม:

ก่อนเขียนไฟล์จริง ให้บอก evidence ของแต่ละ claim ว่ามาจากไฟล์ไหน ถ้า claim ไหน verify ไม่ได้ ให้ตัดออก

Step 3: ให้ Claude Code วางแผนก่อน edit

เลือกงานเล็ก 1 งาน เช่นเพิ่ม test ให้ function หนึ่งตัว หรือแก้ bug ที่มี error ชัด แล้วใช้ prompt แบบ plan-first:

งาน: เพิ่ม unit test ให้ pricing calculation จากไฟล์จริงใน project นี้ ก่อนแก้ไฟล์ให้สรุป plan, files ที่จะอ่าน, files ที่อาจเปลี่ยน, risk, และคำสั่ง verification ที่จะรัน รอ approval ก่อน edit

ถ้าใช้ Claude Code รุ่นใหม่ คุณใช้ /plan หรือ permission mode ที่เน้น read-only ก่อน edit ได้ เป้าหมายคือแยก “คิดให้ดี” ออกจาก “ลงมือแก้”

เช็ก plan ด้วยคำถามนี้:

scope เล็กพอไหม
มันจะเปลี่ยนไฟล์ที่ควรเปลี่ยนจริงไหม
verification วัดผลได้ไหม
มีอะไรเกี่ยวกับ secret, database, payment, customer data หรือ production ไหม

ถ้าตอบไม่ชัด ให้แก้ plan ก่อน ไม่ใช่รีบให้มัน edit

Step 4: ลงมือแก้แบบมี stop condition

เมื่อ plan ดูดีแล้ว ค่อย approve ให้แก้ไฟล์:

ไปต่อได้ แต่แก้เฉพาะไฟล์ใน plan นี้ ห้าม refactor นอก scope หลังแก้แล้วรัน test ที่ระบุไว้ ถ้า test fail ให้สรุปสาเหตุก่อนแก้เพิ่ม

ถ้า task มีเงื่อนไขจบชัด เช่น “test pricing ผ่าน” หรือ “build ผ่าน” ใช้ /goal ได้:

/goal pricing tests pass and git diff only touches pricing test files

ข้อควรระวัง: goal ที่ดีต้องวัดได้ ถ้าเขียนว่า “ทำให้ดีขึ้น” agent จะตีความกว้างเกินไป ให้เขียนเป็น test, build, screenshot, endpoint หรือ diff boundary แทน

Step 5: Verification ต้องเป็นของจริง

จุดที่คนใช้ AI coding พลาดบ่อยคือเชื่อสรุปว่า “แก้แล้ว” ทั้งที่ยังไม่ได้รันอะไรจริง Tutorial นี้ต้องจบด้วย proof เท่านั้น

ถ้าเป็น logic: run unit test ที่เกี่ยวข้อง
ถ้าเป็น UI: เปิดหน้าและเก็บ screenshot หรือ browser proof
ถ้าเป็น API: curl endpoint หรือ run integration test
ถ้าเป็น docs: check link และ command ใน docs
ถ้าเป็น security: run targeted review และดู diff เอง

สรุป proof แบบสั้น ๆ: คำสั่งที่รัน, ผลลัพธ์, ไฟล์ที่เปลี่ยน, risk ที่เหลือ และสิ่งที่ยังไม่ได้ verify ห้ามบอกว่าเสร็จถ้ายังไม่ได้รัน verification

ถ้าใช้ /code-review ได้ ให้รันหลังมี diff:

/code-review high

ถ้างานคือ cleanup ไม่ใช่หาบั๊ก ใช้ /simplify แทน เพื่อไม่ให้ review mode ขยาย scope เกินจำเป็น

Step 6: ดู diff ก่อน commit หรือ PR

ก่อน commit ให้ดู diff เองเสมอ:

git diff
npm test

จากนั้นให้ Claude ช่วยสรุป commit ได้ แต่คุณต้องเป็นคนตัดสินใจว่า scope ผ่านไหม:

ช่วยสรุป diff นี้เป็น commit message และ PR note แบบสั้น ๆ แยกเป็น changes, verification, risk ห้ามใส่ claim ที่ไม่มีใน diff หรือผล test

ถ้า diff มีไฟล์นอก scope ให้หยุดก่อน อย่า commit รวม เพราะนี่คือจุดที่ AI agent มักเผลอแตะเกินงาน

ทางลัดสำหรับคนอยากเริ่มแบบมีระบบ: SPK Jumpstart

ถ้าไม่อยากประกอบ workflow เองทั้งหมด ลองใช้ AI Sprint Kit (SPK) ได้ครับ มันเป็น Claude Code plugin ที่แพ็ก skills และ subagents สำหรับงาน plan, code, review, debug, deploy และ wiki memory ไว้แล้ว

/plugin marketplace add apipoj/spk
/plugin install spk@spk
/spk:jumpstart เพิ่ม unit test ให้ pricing calculation

ข้อดีของ /spk:jumpstart คือมันพาคุณเริ่มจากการ prime repo, route งาน, เสนอ plan และขอ confirmation ก่อน implement เหมาะกับคนที่อยากให้ Claude Code ทำงานเป็น workflow มากกว่า prompt เดี่ยว ๆ

อยากให้ AI coworker มี sandbox ทำงานจริง?

SPK ช่วยจัด workflow ใน Claude Code ส่วนถ้าคุณอยากมี workspace/sandbox สำหรับให้ agent ทำงานต่อเนื่อง มี memory, tools, approvals และแยกจากเครื่องหลัก ดู OPB Stack ได้ครับ

Checklist จบ tutorial

Claude Code อ่าน project และสรุป source map แล้ว
มี CLAUDE.md หรืออย่างน้อยมี project rules ที่ชัด
งานแรกเล็กพอและมี branch แยก
Claude เสนอ plan ก่อน edit
ไฟล์ที่เปลี่ยนอยู่ใน scope
รัน verification จริงแล้ว
ดู git diff เองก่อน commit
มี note ว่าอะไร verify แล้วและอะไรยังไม่ verify

ถ้าทำครบ แปลว่าคุณไม่ได้แค่ “ลอง Claude Code” แต่เริ่มใช้มันเป็น workflow ที่ควบคุมได้แล้ว

เรียนต่อแบบเป็นระบบ

ถ้าคุณอยากเข้าใจ Claude, Claude Code, Claude Cowork, Project, Skills, MCP และ Proof Standard แบบเอาไปใช้กับงานจริง ดูคอร์ส Claude + Claude Cowork จาก Zero สู่ Hero! บน Data-Espresso Learn ได้ครับ

หรือถ้ายังอยากอ่านภาพรวมก่อน กลับไปที่ คู่มือ Claude Code สำหรับมือใหม่ 2026

แหล่งอ้างอิง

อ่านแล้ว: 1,327

สอน Claude Code 2026: Tutorial Workshop 60 นาที แก้บั๊ก เขียนเทสต์ เปิด PR ด้วย AI