Operator Core

operator ไม่ได้ 'ใช้' AI ผ่านหน้าเว็บ แต่ปฏิบัติการ AI จากเครื่องของตนเอง โดยให้ AI เข้าถึงไฟล์ git และ terminal ได้โดยตรง นั่นคือสิ่งที่ Claude Code เป็น ก่อนติดตั้ง คุณต้องมีรากฐานสามอย่าง คือ terminal ที่ใช้รันคำสั่ง, editor (VS Code) ที่ใช้ดูและแก้ไขโค้ด และ package manager สำหรับติดตั้งเครื่องมือต่าง ๆ บน macOS terminal คือ Terminal.app หรือ iTerm2 ส่วนบน Windows ให้ใช้ WSL2 (Ubuntu) เพราะ Claude Code และเครื่องมือส่วนใหญ่ตั้งอยู่บนสมมติฐานของสภาพแวดล้อมแบบ Unix อย่าพยายามปฏิบัติการจาก PowerShell ล้วน ๆ เพราะจะทำให้งานยากขึ้นเป็นเท่าตัว

ขั้นแรกให้ตรวจสอบว่าคุณมีอะไรอยู่แล้วบ้าง เปิด Terminal แล้วรัน `node --version` และ `git --version` หาก `node` ไม่มีอยู่หรือมีเวอร์ชันต่ำกว่า v18 ให้ติดตั้ง Node LTS บน macOS วิธีที่สะอาดที่สุดคือ Homebrew ด้วยคำสั่ง `/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"` แล้วตามด้วย `brew install node git` หลังติดตั้ง Homebrew ตัวติดตั้งจะพิมพ์บรรทัด `eval "$(/opt/homebrew/bin/brew shellenv)"` ออกมา 2 บรรทัด ซึ่งคุณต้องเพิ่มเข้าไปในไฟล์ `~/.zprofile` หากคุณข้ามขั้นนี้ `brew` จะ 'หายไป' เมื่อเปิด terminal ใหม่ นี่คือปัญหา PATH แรกที่คุณจะพบและควรทำความเข้าใจให้ดี กล่าวคือ PATH เป็นรายชื่อโฟลเดอร์ที่ shell ใช้ค้นหาคำสั่ง หากเครื่องมือไม่ได้อยู่ในโฟลเดอร์เหล่านั้น shell จะตอบว่า `command not found` แม้ว่าไฟล์จะมีอยู่จริงบนดิสก์ก็ตาม

ติดตั้ง Claude Code ด้วยคำสั่ง `npm install -g @anthropic-ai/claude-code` แล้วตรวจสอบด้วย `claude --version` หาก npm ฟ้องปัญหาเรื่องสิทธิ์ (`EACCES`) อย่าใช้ `sudo npm` เพราะจะทำให้เกิดไฟล์ที่เป็นของ root ซึ่งคุณจะลบไม่ได้ในภายหลัง วิธีแก้ที่ถูกต้องคือชี้ให้ npm ใช้ prefix ที่อยู่ภายใน home ของคุณ ด้วย `npm config set prefix ~/.npm-global` แล้วเพิ่ม `export PATH=~/.npm-global/bin:$PATH` เข้าไปใน `~/.zshrc` จากนั้นโหลดใหม่ด้วย `source ~/.zshrc` ตอนนี้ `claude` จะเริ่มทำงานและขอให้คุณยืนยันตัวตนด้วยบัญชี Anthropic ผ่าน browser token นั้นจะถูกบันทึกไว้และคุณไม่ต้องกรอกซ้ำอีก

VS Code คือหน้าต่างที่คุณใช้มองโค้ด ขณะที่ Claude Code คือมือของคุณ ติดตั้งจาก code.visualstudio.com แล้วเปิด command palette ภายใน (Cmd+Shift+P) → 'Shell Command: Install code command in PATH' การทำเช่นนี้จะให้คำสั่ง `code .` ที่ใช้เปิดโฟลเดอร์ปัจจุบันใน VS Code จาก terminal ซึ่งเป็นท่าที่คุณจะทำเป็นร้อยครั้งต่อวัน ติดตั้ง extension อย่างน้อยเหล่านี้ คือ extension ทางการของภาษาที่คุณใช้, GitLens และ formatter อย่าง Prettier อย่าใส่ extension ถึง 40 ตัวจนทำให้ editor อืด เพราะแต่ละตัวคือพื้นที่เสี่ยงต่อการโจมตีและเป็นเสียงรบกวน

ขั้นตอนการทำงานจริงจะเหมือนเดิมเสมอ และคุณจะซึมซับมันในโมดูลนี้ คุณเปิด terminal เข้าไปยังโปรเจกต์ด้วย `cd ~/mi-proyecto` พิมพ์ `claude` เพื่อเริ่ม session และในอีกแท็บหนึ่ง (หรือ panel ที่แบ่งใน VS Code) คุณเปิด editor ไว้ด้วย `code .` Claude Code เสนอการเปลี่ยนแปลง คุณตรวจทานใน editor หรือด้วย `git diff` แล้วจึงยอมรับ terminal และ editor ไม่ได้แข่งกัน terminal คือที่ที่การกระทำเกิดขึ้น ส่วน editor คือที่ที่คุณตรวจสอบ ยกตัวอย่างใน MOONKEY LAB session ทั่วไปคือ `cd ~/xop && claude` แล้วสั่งให้แก้ไข component Astro ขณะที่คุณดูไฟล์นั้นใน VS Code

ตรวจสอบสภาพแวดล้อมทั้งหมดด้วยการทดสอบจริงก่อนปิดโมดูลนี้ สร้างโฟลเดอร์ `mkdir ~/lab-01 && cd ~/lab-01` เริ่มต้น git ด้วย `git init` รัน `claude` แล้วสั่งให้สร้างไฟล์ `hola.txt` ที่มีชื่อของคุณ ออกจาก Claude แล้วรัน `cat hola.txt` เพื่อยืนยันว่าไฟล์มีอยู่จริงบนดิสก์ และ `code .` เพื่อดูใน editor หากทั้งสี่ขั้นตอนทำงานได้ (terminal เข้าถึงโฟลเดอร์, claude เริ่มและเขียนได้, ไฟล์ปรากฏ, VS Code เปิดได้) แสดงว่าสภาพแวดล้อมของคุณพร้อมปฏิบัติการแล้ว จดบันทึกส่วนตัวเกี่ยวกับเวอร์ชันที่คุณติดตั้งไว้ให้แม่นยำ เพราะเมื่อมีอะไรพังในอีกเดือนข้างหน้า บันทึกนั้นจะช่วยคุณประหยัดเวลาไปทั้งบ่าย

CLAUDE.md คือไฟล์ข้อความที่อยู่ในรากของโปรเจกต์ ซึ่ง Claude Code อ่านโดยอัตโนมัติเมื่อเริ่มแต่ละ session มันไม่ใช่เอกสารสำหรับมนุษย์ (แม้จะใช้ประโยชน์ได้เช่นกัน) แต่เป็น context ที่ AI โหลดก่อนลงมือทำอะไร หาก `package.json` ของคุณบอกว่าเป็น React แต่คุณใช้ Astro หรือหากคุณมีกฎว่า 'อย่าเพิ่ม dependency โดยไม่มีเหตุผล' ไฟล์นี้คือที่อยู่ของกฎเหล่านั้น AI ไม่เดาวิจารณญาณของคุณ คุณเขียนให้มันครั้งเดียว แล้วมันก็นำกลับมาใช้ตลอดไป

ข้อผิดพลาดของผู้เริ่มต้นคือการเขียน CLAUDE.md แบบกว้าง ๆ ('นี่เป็นโปรเจกต์เว็บ ใช้แนวปฏิบัติที่ดี') ซึ่งไม่ได้ช่วยอะไรเลย เพราะ AI ถือว่าใช้แนวปฏิบัติที่ดีอยู่แล้ว คุณค่าอยู่ที่ความ เฉพาะเจาะจง และ ไม่ชัดเจนในตัว ว่า stack จริง ที่คุณใช้คืออะไร (ไม่ใช่ที่ดูเหมือนว่าใช้), ตารางใดในฐานข้อมูลของคุณที่เป็นของโปรเจกต์อื่นและห้ามแตะต้อง, คุณใช้รูปแบบ i18n แบบใด, อะไรที่แปลและอะไรที่ไม่แปล ลองดู CLAUDE.md จริงของ MOONKEY LAB มีส่วนหนึ่งชื่อ 'DB Supabase ใช้ร่วมกับ XHUB IRON' ซึ่งระบุตารางที่ห้ามแตะ (`iron_*`, `world_*`) และตารางที่อนุญาต (`profiles, progress, feedback, leads, proofs`) บรรทัดเดียวนี้ป้องกันไม่ให้ AI ลบข้อมูลของผลิตภัณฑ์อื่น นี่คือความรู้ประเภทที่มีแต่คุณเท่านั้นที่รู้ และไฟล์นี้บันทึกมันไว้

จัดโครงสร้าง CLAUDE.md ที่มีประสิทธิภาพเป็นส่วน ๆ ที่ชัดเจนด้วยหัวข้อ Markdown ส่วนที่สำคัญ ได้แก่ (1) วิสัยทัศน์ ประโยคเดียวว่าโปรเจกต์คืออะไร (2) Stack จริง เวอร์ชันและเครื่องมือที่แม่นยำ พร้อมระบุจุดที่ความเป็นจริงต่างจากภาพที่เห็น (3) โมเดลความปลอดภัยหรือโมเดลข้อมูล ใครแตะอะไรได้ (4) ข้อกำหนด ชื่อ โครงสร้างโฟลเดอร์ typography หรืออะไรก็ตามที่มีกฎ (5) โทน ข้อความที่มันสร้างควรมีน้ำเสียงอย่างไร (6) กฎเรื่องต้นทุน อะไรที่ห้ามทำ ใน MOONKEY ส่วนสุดท้ายเขียนตรง ๆ ว่า 'อย่าเพิ่ม dependency โดยไม่มีเหตุผล อย่าใช้ JS ในที่ที่ HTML/CSS เพียงพอ' ข้อห้ามที่เป็นรูปธรรม ไม่ใช่คำแนะนำคลุมเครือ

กฎทองคือ ทุกบรรทัดใน CLAUDE.md ต้องเปลี่ยนการตัดสินใจ หากประโยคใดไม่เปลี่ยนสิ่งที่ AI จะทำโดยปริยาย ให้ตัดทิ้ง 'เขียนโค้ดให้สะอาด' ไม่เปลี่ยนอะไรเลย ส่วน 'href ต้องรับรู้ locale ใช้ localizedPath(/ruta, locale) ไม่ใช่ /ruta ดิบ ๆ (จะพังภายใต้ prefix ของภาษา)' เปลี่ยนทุกลิงก์ที่มันสร้าง อย่างหลังคือทองคำ อย่างแรกคือไส้กรอก CLAUDE.md ที่มีเนื้อหาแน่น 80 บรรทัด มีค่ามากกว่าฉบับ 300 บรรทัดที่เต็มไปด้วยเรื่องชัดเจนในตัว และยังใช้ context น้อยกว่าในแต่ละ session

CLAUDE.md คือเอกสารที่มีชีวิต ไม่ใช่การวางรากฐานครั้งเดียวจบ ทุกครั้งที่ AI ทำผิดอย่างเป็นระบบ เช่น เพิ่ม dependency ที่คุณไม่ต้องการ ใช้รูปแบบ i18n ที่ผิด หรือแปลคำของแบรนด์ที่ไม่ควรแปล นั่นคือความผิดของไฟล์ ไม่ใช่ของ AI ให้กลับไปเพิ่มกฎนั้น เมื่อเวลาผ่านไป ไฟล์นี้จะกลายเป็นการกลั่นกรองของการแก้ไขทั้งหมดที่คุณเคยทำ ในทางปฏิบัติ session ที่ดีมักจบด้วย 'เพิ่มสิ่งนี้ลงใน CLAUDE.md เพื่อไม่ให้เกิดขึ้นอีก' และให้เก็บเรื่องที่เกี่ยวกับเครื่องและความชอบส่วนตัวของคุณไว้นอก CLAUDE.md ของ repo (สิ่งนั้นไปอยู่ในหน่วยความจำผู้ใช้หรือใน CLAUDE.local.md ที่ไม่ version) เพราะ CLAUDE.md ของ repo ทีมใช้ร่วมกัน

ในการเขียนมัน อย่าเริ่มจากเทมเพลตเปล่า ๆ รัน `claude` ในโปรเจกต์ของคุณแล้วสั่งว่า 'สำรวจโครงสร้างของ repo อ่าน package.json และไฟล์ config แล้วเสนอร่าง CLAUDE.md ที่บันทึก stack จริงและข้อกำหนดที่คุณตรวจพบ' AI เก่งมากในการอ่านโค้ดของคุณเองและสรุปมัน จากนั้น คุณ เป็นผู้แก้ไข เพิ่มข้อห้ามที่มันไม่อาจรู้ได้ (ตารางของโปรเจกต์อื่น คำที่ไม่แปล การตัดสินใจเชิงธุรกิจ) แล้วลบสิ่งที่กว้าง ๆ ออก วงจรนี้ AI เสนอจากโค้ด คุณฉีดความรู้ที่อยู่ในหัวคุณเท่านั้นเข้าไป จะสร้างไฟล์ที่ซื่อตรงได้ภายในยี่สิบนาที

prompt ไม่ใช่คำถาม แต่เป็นคำสั่งงาน เมื่อคุณขอให้เพื่อนร่วมงานที่เก่งทำบางอย่าง คุณไม่พูดว่า 'แก้ login ที' แต่พูดว่า 'magic-link ของ Supabase ไม่ redirect หลังยืนยันตัวตน ลองตรวจ callback ใน src/lib/supabase.ts ปัญหาน่าจะอยู่ที่ URL ของ redirect ใน config' คุณให้บทบาทโดยนัย บริบท จุดโฟกัส และสมมติฐานแก่เขา prompt ที่ดีทำสิ่งเดียวกันอย่างชัดเจน เสาหลักสี่ต้นได้แก่ บทบาท (AI ต้องเป็นใคร: 'คุณคือวิศวกร Postgres ที่กำลังตรวจ RLS'), บริบท (สิ่งที่มันต้องรู้: stack ไฟล์ ข้อจำกัด), โครงสร้าง (คุณต้องการผลลัพธ์อย่างไร: 'ส่งกลับเฉพาะ SQL ไม่ต้องอธิบาย' หรือ 'แสดง 3 ทางเลือกพร้อม trade-off') และ เจตนา (เป้าหมายจริงเบื้องหลังคำขอ ไม่ใช่แค่ขั้นตอน)

บทบาท ไม่ใช่การแสดงละคร มันเปลี่ยนว่า AI จะกระตุ้นความรู้ใดและใช้มาตรฐานใด 'ตรวจโค้ดนี้ที' ให้การตรวจที่อ่อน ส่วน 'คุณคือผู้ตรวจสอบความปลอดภัยเชิงปฏิปักษ์ งานของคุณคือหักล้างข้ออ้างว่า RLS นี้ปลอดภัย จงหาเส้นทางการยกระดับสิทธิ์' ให้การวิเคราะห์ที่แตกต่างไปอย่างสิ้นเชิง เพราะคุณได้ให้จุดยืนแก่มัน ใน XCAP prompt สำหรับ research มีบทบาท 'นักวิเคราะห์ที่ไม่โกหกตัวเอง' พอดี เพราะอคติโดยปริยายของโมเดลคือการเอาใจ บทบาทคือสิ่งที่ต้านมันไว้

โครงสร้าง ของผลลัพธ์เป็นสิ่งที่ประหยัดเวลาคุณมากที่สุดและถูกลืมมากที่สุด หากคุณไม่ระบุรูปแบบ AI จะเลือกเอง และมักเป็นร้อยแก้วยาว ๆ ที่คุณต้องมาตัดทอน บอกให้ชัดว่าคุณต้องการอะไร 'ส่งกลับเป็น SQL block เดียวพร้อมวาง ไม่ต้องมีคอมเมนต์หรือคำอธิบาย' หรือ 'ตอบเป็นตารางสามคอลัมน์ ทางเลือก ข้อดี ความเสี่ยง' หรือ 'ขอ diff ไม่ใช่ไฟล์เต็ม' ใน MOONKEY ที่โทนคือ 'ชัดเจน ตรงไปตรงมา ไม่มีน้ำ ไม่มี emoji' prompt สำหรับสร้าง copy จะใส่ข้อจำกัดของรูปแบบนั้นตรง ๆ เพราะถ้าไม่ใส่ AI จะใส่เครื่องประดับที่คุณต้องมาลบด้วยมือทีหลัง

เจตนา คือเหตุผล และมันปลดล็อกวิธีแก้ที่คุณไม่ได้ขอ หากคุณพูดว่า 'เพิ่ม index ให้คอลัมน์นี้' AI ก็เพิ่ม หากคุณพูดว่า 'query นี้ใช้เวลา 2 วินาทีในหน้าบัญชี และผมอยากลดให้เหลือต่ำกว่า 200ms index เป็นความคิดแรกของผมแต่เปิดรับทางเลือกอื่น' มันอาจบอกคุณว่าปัญหาจริงคือ N+1 และ index ไม่ช่วย เมื่อคุณให้เจตนา AI สามารถตั้งคำถามกับวิธีแก้ที่คุณเสนอและให้ทางที่ดีกว่า เมื่อคุณให้แค่คำสั่ง มันก็ทำตามแบบหลับหูหลับตา

คลังอาวุธคือชุดของ prompt เหล่านี้ที่ถูก version และจัดระเบียบตามงาน ซึ่งคุณนำกลับมาใช้ใหม่ อย่าเริ่มจากศูนย์ทุกครั้ง จงมี prompt สำหรับ 'ตรวจสอบความปลอดภัยของ RLS', สำหรับ 'สร้าง copy ด้วยน้ำเสียงของแบรนด์', สำหรับ 'refactor component นี้โดยรักษาพฤติกรรมเดิม', สำหรับ 'เขียน commit message จาก diff' เก็บไว้ในไฟล์ `prompts.md` ในโปรเจกต์ของคุณหรือในโน้ต MOONKEY LAB มีหน้าเต็มหนึ่งหน้าคือ `/prompts` ที่อุทิศให้เรื่องนี้ เพราะคลังอาวุธคือสินทรัพย์ ทุก prompt ที่ปรับจนเข้าที่คืองานที่คุณไม่ต้องทำซ้ำ จงพารามิเตอร์ prompt ด้วยช่องว่าง `[ARCHIVO]`, `[RESTRICCIÓN]` ที่คุณเติมตอนใช้

วนซ้ำที่ prompt ไม่ใช่ที่ผลลัพธ์ เมื่อผลออกมาแย่ ปฏิกิริยาของผู้เริ่มต้นคือแก้คำตอบด้วยมือ ปฏิกิริยาของ operator คือถามตัวเองว่า 'prompt ขาดข้อมูลอะไรไป' แล้วแก้ที่ prompt หาก AI ใช้ tab แต่คุณต้องการ space อย่าแก้ที่ไฟล์ ให้เพิ่ม 'ย่อหน้าด้วย 2 space' ลงใน prompt แล้วบันทึกไว้แบบนั้นตลอดไป ทุกการแก้ไขที่คุณใส่ลงในเทมเพลตคือการแก้ไขที่คุณไม่ต้องทำซ้ำอีก เมื่อเวลาผ่านไป prompt ในคลังอาวุธของคุณจะคมราวมีดผ่าตัด และผลลัพธ์จะออกมาดีตั้งแต่ครั้งแรก ซึ่งคือเป้าหมาย คือการเลิกวนซ้ำ

Git แก้ปัญหาเพียงข้อเดียว แต่เป็นข้อที่สำคัญที่สุด คือความสามารถในการย้อนกลับไปยังสถานะใด ๆ ก่อนหน้าของโปรเจกต์ ทุกครั้งที่คุณ `commit` คุณแช่แข็งภาพถ่ายของโปรเจกต์ที่คุณกลับไปได้เสมอ สิ่งนี้เปลี่ยนจิตวิทยาการทำงานของคุณ เมื่อรู้ว่าสถานะที่ดีล่าสุดถูกบันทึกไว้แล้ว คุณปล่อยให้ AI ทำการเปลี่ยนแปลงเชิงรุกได้โดยไม่กลัว เพราะที่แย่ที่สุดคือ `git restore` แล้วย้อนกลับ operator ที่ไม่มี Git ทำงานด้วยความกลัว แต่ด้วย Git เขาทำงานได้เร็ว ขั้นตอนขั้นต่ำคือ `git status` เพื่อดูว่าอะไรเปลี่ยน, `git add -p` เพื่อตรวจและเลือกการเปลี่ยนแปลงทีละส่วน, `git commit -m 'mensaje'` เพื่อแช่แข็ง และ `git log --oneline` เพื่อดูประวัติของคุณ

วงจรประจำวันคือ ดู-ตรวจ-แช่แข็ง หลัง session ของ Claude Code อย่า เชื่อว่าการเปลี่ยนแปลงถูกต้อง ให้รัน `git diff` แล้วอ่านว่ามันแตะต้องอะไรกันแน่ ที่นี่คุณจะค้นพบว่า AI เปลี่ยนสิ่งที่ไม่ควร ลบบรรทัดไปโดยไม่ตั้งใจ หรือเพิ่ม dependency `git diff` คือเครื่องมือตรวจทานอันดับหนึ่งของคุณและคุณใช้มันในทุก session เมื่อ diff ทำให้คุณมั่นใจแล้วเท่านั้น คุณจึงทำ `git add` และ `git commit` นิสัยนี้ อ่าน diff ก่อนยอมรับ คือสิ่งที่แยก operator ออกจากคนที่ copy-paste แบบหลับหูหลับตา

commit ควรเป็นแบบ atomic คือหนึ่ง commit หนึ่งการเปลี่ยนแปลงเชิงตรรกะ พร้อมข้อความที่อธิบาย เหตุผล ไม่ใช่ว่าทำอะไร 'แก้ login' นั้นแย่ (มันเป็นอะไรหรือ) ส่วน 'แก้ redirect ของ magic-link: URL ของ callback ไม่ได้รวม locale และพังภายใต้ /en/' นั้นดี อีกหกเดือนข้างหน้า ข้อความนั้นจะบอกคุณว่าทำไมคุณถึงแตะไฟล์นั้น Claude Code เก่งมากในการเขียน commit message จาก diff สั่งว่า 'เขียน commit message สำหรับการเปลี่ยนแปลงเหล่านี้ พร้อมอธิบายเหตุผล' แล้วมันมักทำได้แม่นยำ แต่จงตรวจ บางครั้งมันบรรยายว่าทำอะไรและคุณต้องขอเหตุผลจากมัน

branch คือจักรวาลคู่ขนานสำหรับทดลองโดยไม่แตะต้องสิ่งที่ใช้งานได้ branch หลัก (`main`) คือเวอร์ชันที่เสถียรของคุณ เมื่อจะลองอะไรที่เสี่ยง การ refactor ใหญ่ feature ใหม่ คุณสร้าง branch ด้วย `git checkout -b mi-experimento` ทำงานที่นั่น ถ้าได้ผลดีก็ merge ถ้าได้ผลแย่ก็ลบทิ้ง โดยที่ `main` ไม่รับรู้เลย กฎปฏิบัติของ operator คือ อย่าทำงานบน `main` โดยตรงสำหรับการเปลี่ยนแปลงที่ไม่ใช่เรื่องเล็กน้อย จงสร้าง branch ใน MOONKEY LAB ทุกการเปลี่ยนแปลงด้านความปลอดภัยหรือ RLS ไปอยู่ใน branch ของตัวเอง และ merge ก็ต่อเมื่อ `get_advisors` ให้ไฟเขียวเท่านั้น

GitHub คือ Git บนคลาวด์ เป็นสำเนาสำรองระยะไกลของคุณและเป็นที่ที่โปรเจกต์ถูก deploy คุณเชื่อม repo ในเครื่องกับมันด้วย `git remote add origin git@github.com:usuario/repo.git` แล้วส่งขึ้นด้วย `git push` จากนั้น `git push` หลังทุก session ที่ดีจะเก็บงานของคุณไว้นอกเครื่อง หากดิสก์คุณพัง โปรเจกต์ก็ยังอยู่ นอกจากนี้ platform อย่าง Cloudflare Pages (ที่ deploy MOONKEY LAB จาก `garciafradepablo-pixel/xop`) เฝ้าดู repo บน GitHub ของคุณ และเผยแพร่ทุก push ไปยัง `main` โดยอัตโนมัติ ดังนั้น Git ไม่ได้เป็นเพียงการ version แต่เป็นเครื่องยนต์ของ deploy ที่คุณจะเห็นในโมดูลถัดไป ในการสื่อสารกับ GitHub จาก terminal ให้ติดตั้ง CLI `gh` และยืนยันตัวตนด้วย `gh auth login`

ไฟล์ `.gitignore` สำคัญพอ ๆ กับ commit มันระบุไฟล์ที่ Git ต้อง เพิกเฉย ที่นี่ใส่ `node_modules/` (ติดตั้งใหม่จาก package.json ได้ ไม่ต้อง version), ไฟล์ `.env` (ความลับ อย่า ส่งคีย์ขึ้น GitHub) และ artifact ของ build การส่งไฟล์ `.env` ที่มีคีย์ขึ้น repo สาธารณะคือหนึ่งในเหตุการณ์ความปลอดภัยที่พบบ่อยที่สุดในโลก และเมื่อคีย์ถูกส่งขึ้นไปแล้ว แม้คุณจะลบ commit มันก็ยังอยู่ในประวัติ ต้อง rotate คีย์นั้นใหม่ ด้วยเหตุนี้ `.gitignore` จึงถูกตั้งค่า ก่อน commit แรก สั่ง Claude Code ว่า 'สร้าง .gitignore สำหรับโปรเจกต์ Astro ที่ใช้ Supabase' แล้วตรวจว่ามันรวม `.env` และ `node_modules` ไว้

การ automate เริ่มจากสิ่งเล็ก ๆ คำสั่งที่คุณทำซ้ำกลายเป็น script หากทุกครั้งที่ทำเสร็จคุณพิมพ์ `npm run build && git add -A && git commit -m wip && git push` นั่นคือ script `deploy.sh` สี่บรรทัดที่คุณรันด้วย `./deploy.sh` หลักการคือ สิ่งที่คุณทำมากกว่าสามครั้ง จงบันทึกไว้ สั่ง Claude Code ว่า 'สร้าง bash script ที่ build, commit พร้อม timestamp และ push และยกเลิกถ้า build ล้มเหลว' เครื่องหมาย `&&` ระหว่างคำสั่งรับประกันอยู่แล้วว่าถ้าอันหนึ่งล้มเหลว อันถัดไปจะไม่รัน ซึ่งคือสิ่งที่คุณต้องการพอดีใน deploy

การ deploy เว็บไซต์ static สมัยใหม่แทบฟรีในการตั้งค่าและเรียกว่า deploy ต่อเนื่อง platform อย่าง Cloudflare Pages เฝ้าดู repo บน GitHub ของคุณ ทุกครั้งที่คุณ `git push` ไปยัง `main` พวกเขา clone repo ของคุณ รันคำสั่ง build (`npm run build` สำหรับ Astro) และเผยแพร่ผลลัพธ์ไปยัง URL จริง MOONKEY LAB ทำงานแบบนี้พอดี `git push` ไปยัง repo `garciafradepablo-pixel/xop` แล้วไม่กี่วินาทีต่อมาการเปลี่ยนแปลงก็อยู่ที่ `moonkeylab.pages.dev` คุณไม่ได้ส่งไฟล์ผ่าน FTP ไม่ได้แตะ server ท่า deploy เพียงท่าเดียวของคุณคือ `git push` สิ่งนี้เชื่อมโมดูล Git เข้ากับโมดูลนี้ Git ไม่ได้เพียง version แต่เป็นไกปืนของ deploy

การตั้งค่า deploy ต่อเนื่องเป็นกระบวนการที่ทำครั้งเดียว คุณเชื่อมบัญชี Cloudflare (หรือ Vercel หรือ Netlify) กับ GitHub เลือก repo แล้วประกาศสองสิ่ง คือคำสั่ง build (`npm run build`) และโฟลเดอร์ผลลัพธ์ (`dist` ใน Astro) Cloudflare บันทึก config นั้นไว้ และจากนั้นทุก push จะกระตุ้น build หาก build ล้มเหลว มันจะ ไม่ เผยแพร่ เว็บไซต์เดิมของคุณยังคงอยู่ นั่นคือคุณสมบัติด้านความปลอดภัยที่มหาศาล commit ที่พังไม่ทำเว็บคุณล่ม มันเพียงไม่ถูก deploy และแจ้งเตือนคุณ คุณจะเห็น log ของ build ใน panel ของ Cloudflare เมื่อมีอะไรล้มเหลวใน deploy แต่ทำงานได้ในเครื่อง log นั้นคือสิ่งแรกที่คุณอ่าน

environment variable คือสะพานเชื่อมระหว่าง deploy กับความลับของคุณ และตรงนี้มันตัดกับความปลอดภัย โค้ดของคุณต้องการ URL ของ Supabase และ anon key แต่สิ่งเหล่านั้น ไม่ ถูก hardcode ใน repo (คุณเห็นแล้วในโมดูล Git) ในเครื่องมันอยู่ใน `.env` ใน deploy คุณใส่มันลงใน panel ของ Cloudflare เป็น environment variable และ platform ฉีดมันเข้าไปใน build ข้อแตกต่างสำคัญที่คุณจะเรียนเชิงลึกใน Ops & Security คือ anon key ของ Supabase นั้น อยู่ในฝั่ง client ได้ (ถูกป้องกันด้วย RLS) แต่ service-role key ไม่ มีวันได้ เพราะมันให้สิทธิ์เข้าถึงทั้งหมดโดยข้ามความปลอดภัยทั้งปวง การรู้ว่าคีย์ใดไปอยู่ที่ใดคือสมรรถนะของ operator

ระดับถัดไปคือการ automate งานที่เกิดซ้ำซึ่งไม่ขึ้นกับ push คือสิ่งที่ต้องรันตามตารางเวลา นี่คืองานตั้งเวลา (cron) ใน XCAP เช่น มี 'autopilot tick' ลูปที่รันเป็นช่วง ๆ เพื่อรับข้อมูลตลาดและอัปเดต ledger ของ Market Memory โดยไม่มีใครกดปุ่ม แนวคิดทั่วไปคือ คุณกำหนดคำสั่งและตารางเวลา ('ทุกวันเวลา 6:00', 'ทุก 15 นาที') แล้ว platform รันมันเอง สำหรับเว็บ static เรื่องนี้มักอยู่ใน serverless function (Cloudflare Workers) หรือใน cron job หัวใจของ operator คือลูปต้องซื่อตรงและ idempotent คือรันสองครั้งต้องไม่ทำให้ข้อมูลซ้ำ และต้องสะสมการเรียนรู้แทนที่จะเป็นเสียงรบกวน ซึ่งคือวินัยของ 'capital invariant' ใน XCAP พอดี ที่สถานะเปลี่ยนเฉพาะในเหตุการณ์จริง ไม่ใช่ทุก tick

การ automate โดยไม่มี observability เป็นอันตราย ระบบที่รันเองและล้มเหลวเงียบ ๆ แย่กว่าระบบที่ทำด้วยมือ สำหรับการ automate ทุกอย่าง จงมีวิธีรู้ว่ามันทำงานหรือไม่ build ของ Cloudflare ส่งอีเมลถึงคุณหากล้มเหลว งาน cron ต้อง log ผลลัพธ์ไว้ในที่ที่คุณตรวจดู กฎคือ อย่า automate สิ่งที่คุณตรวจสอบในภายหลังไม่ได้ จงเริ่มจากเวอร์ชันที่รันและแจ้งเตือนคุณเสมอ และต่อเมื่อคุณไว้ใจมันแล้วจึงปล่อยให้มันรันเองจริง ๆ deploy อัตโนมัติโดยไม่ตรวจ log ครั้งแรกคือวิธีที่เว็บที่พังถูกเผยแพร่สู่ production โดยที่คุณไม่รู้ตัว

ความแตกต่างพื้นฐานไม่ใช่เรื่องโมเดล แต่เป็นเรื่องกระบวนทัศน์ ChatGPT คือบทสนทนา คุณพิมพ์ AI ตอบเป็นข้อความ และคุณ copy ข้อความนั้นไปยังโปรเจกต์ด้วยมือ context อยู่ในเธรด และเมื่อเธรดยาวเกินไปหรือคุณปิดมัน context นั้นก็ระเหยไป Claude Code คือ operator มันอยู่ใน terminal ของคุณ อ่านและเขียนไฟล์ของคุณโดยตรง รันคำสั่ง ทำ commit context ไม่ได้อยู่ในบทสนทนาชั่วคราว แต่อยู่ใน CLAUDE.md และใน repo ของคุณ ซึ่งถาวรและถูก version การย้ายคือการนำความรู้ของคุณจากที่ที่ถูกลบ ไปสู่ที่ที่คงอยู่

เริ่มด้วยการตรวจสอบว่าคุณมี context มีค่าอะไรติดอยู่ใน ChatGPT บ้าง น่าจะมีเธรดที่คุณนิยาม stack ของโปรเจกต์ การตัดสินใจด้านสถาปัตยกรรม ข้อกำหนดด้านสไตล์ prompt ที่ใช้ได้ผลดี ทั้งหมดนั้นคือสินทรัพย์ที่ตอนนี้มีอยู่แค่ในเธรด ขั้นแรกของการย้ายคือการดึงมันออกมา สำรวจบทสนทนาสำคัญแล้วดึงการตัดสินใจที่คงทน (ไม่ใช่ทั้งแชต แต่เป็นข้อสรุป) 'เราใช้ Astro ไม่ใช่ React เพราะ X', 'โทนคือตรงไปตรงมาไม่มี emoji', 'DB ใช้ร่วมกับโปรเจกต์อื่นและตารางเหล่านี้แตะไม่ได้' นั่นคือวัตถุดิบของ CLAUDE.md พอดี

หัวใจของการย้ายคือการสร้าง CLAUDE.md จาก context ที่ดึงออกมานั้น สิ่งที่ใน ChatGPT คุณต้องพิมพ์ซ้ำตอนเริ่มทุกเธรด ('จำไว้ว่าผมใช้ Astro และ Supabase และโทนคือ...') ใน Claude Code คุณเขียนครั้งเดียวใน CLAUDE.md แล้วมันโหลดเองในทุก session ตลอดไป สิ่งนี้เชื่อมโดยตรงกับโมดูล OC-02 การย้ายไม่ใช่อะไรมากไปกว่าการเทขน context ที่กระจัดกระจายในเธรดของคุณลงในไฟล์หน่วยความจำถาวร แบบฝึกหัดที่ดีคือขอ ChatGPT เองว่า 'สรุปการตัดสินใจทางเทคนิคและข้อกำหนดทั้งหมดของเธรดนี้เป็น bullet สำหรับไฟล์ context' แล้วใช้ผลลัพธ์นั้นเป็นร่าง

เปลี่ยนวิธีที่คุณขอสิ่งต่าง ๆ ด้วย ใน ChatGPT คุณขอ 'เขียนโค้ดสำหรับ X ให้หน่อย' แล้วได้ block หนึ่งที่คุณ paste ใน Claude Code คุณขอ 'สร้างไฟล์ src/lib/x.ts ที่ทำ X ตามข้อกำหนดของ CLAUDE.md แล้วแสดง diff ให้ดู' AI สร้างไฟล์ในที่ของมัน คุณตรวจ diff ด้วย git แล้ว commit ท่า copy-paste หายไป สิ่งนี้ต้องการการลบนิสัยเก่า เลิกมอง AI เป็นเครื่องผลิตข้อความ และเริ่มมองมันเป็นผู้ร่วมงานที่ลงมือกับโปรเจกต์ของคุณ ตอนแรกมันยากที่จะไว้ใจว่ามันจะแตะไฟล์ที่ถูกต้อง ด้วยเหตุนี้ `git diff` และ commit จากโมดูล OC-04 จึงเป็นตาข่ายนิรภัยของคุณ

การย้ายที่ดีหมายถึงการตั้งระบบให้ครบ ไม่ใช่แค่เปลี่ยนเครื่องมือ ระบบของ operator คือ repo ที่มี git, CLAUDE.md ที่มี context, .gitignore ที่ปกป้องความลับ, คลังอาวุธ prompt ใน prompts.md และ deploy ต่อเนื่องที่เชื่อมไว้ เมื่อคุณมีห้าองค์ประกอบนี้ คุณเลิก 'ใช้ AI' และตั้งการปฏิบัติการขึ้นแล้ว แต่ละโมดูลก่อนหน้าใน Operator Core คือชิ้นส่วนหนึ่ง โมดูลนี้ประกอบมันเข้าด้วยกันโดยการย้ายโปรเจกต์จริงจากความวุ่นวายของเธรด ChatGPT มาสู่ระบบที่มีเอกสารนั้น ผลลัพธ์คือ session ใหม่ใด ๆ ของคุณหรือของผู้ร่วมงาน จะเริ่มต้นโดยมี context ทั้งหมดโหลดไว้แล้ว

คุณค่าที่คุณจะรู้สึกทันทีคือความต่อเนื่อง ใน ChatGPT การกลับมาทำโปรเจกต์หลังผ่านไปหนึ่งสัปดาห์หมายถึงการอ่านเธรดซ้ำและนึกว่าคุณค้างไว้ตรงไหน ในระบบที่ย้ายแล้ว คุณเปิด terminal `cd` ไปที่โปรเจกต์ `claude` แล้ว AI ก็รู้ stack ข้อกำหนด และข้อห้ามอยู่แล้วเพราะมันอยู่ใน CLAUDE.md ส่วนคุณก็เห็นว่าค้างไว้ตรงไหนใน `git log` โปรเจกต์ทำเอกสารตัวเอง ความต่อเนื่องนี้คือสิ่งที่ทำให้ปฏิบัติการหลายโปรเจกต์พร้อมกันได้โดยไม่ปนกัน เหมือนที่จำเป็นเมื่อคุณดูแล XNLAB, XHUB, XCAP, Espejo และโรงเรียนนี้คู่ขนานกัน แต่ละอันมี CLAUDE.md, repo และ context ที่แยกออกจากกัน ทั้งหมดปฏิบัติการด้วยขั้นตอนเดียวกัน

การตรวจสอบ ไม่ใช่ การ test อัตโนมัติ และ ไม่ใช่ เรื่องความปลอดภัยเพียงอย่างเดียว มันคือวินัยทั่วไปในการพิสูจน์ว่าการเปลี่ยนแปลงมีพฤติกรรมตามที่คุณคาดหวัง ก่อน เผยแพร่ มันมีสี่ระดับที่ใช้ตามลำดับและคุณแทบไม่เคยต้องใช้ทั้งสี่ (1) มัน compile/เริ่มทำงานโดยไม่มี error หรือไม่ (2) diff บอกในสิ่งที่คุณคิดว่าขอไปหรือไม่ (3) พฤติกรรมที่สังเกตได้เปลี่ยนตามที่คาดหรือไม่ (4) คุณทำสิ่งที่เคยทำงานได้พังหรือไม่ (regression)

ระดับที่ถูกและบังคับ คือ อ่าน diff ก่อนยอมรับอะไร `git diff` (หรือ panel diff ของ editor) Claude Code เก่งในการบรรยายสิ่งที่มันทำ และห่วยในการเปิดเผยสิ่งที่มันทำเกิน ไฟล์ที่คุณไม่ได้ขอให้แตะ, `console.log` ที่ลืมไว้, dependency ที่เพิ่ม, block ที่ลบ 'เผื่อ' หาก diff แตะมากกว่าที่ประโยคของคุณขอ นั่นคือสัญญาณ ไม่ใช่ความบังเอิญ กฎคือ อย่ายอมรับการเปลี่ยนแปลงที่คุณไม่เข้าใจ diff ทีละบรรทัด

'ดูเหมือนจะใช้ได้' คือคำโกหกที่สบายใจซึ่งมีสามหน้า หน้าที่ 1 มันเริ่มทำงานโดยไม่มี error → คุณสับสนระหว่าง 'ไม่ crash' กับ 'ทำสิ่งที่ถูกต้อง' หน้าที่ 2 ผมลองหนึ่งครั้งด้วย happy case → คุณไม่ได้ลอง input ว่าง ข้อมูลซ้ำ ผู้ใช้ไม่มีสิทธิ์ หน้าที่ 3 AI บอกผมว่ามันตรวจแล้ว → AI ไม่ได้รันอะไรเลย มันทำนายข้อความ ยาแก้พิษคือสิ่งเดียวกันเสมอ คือสังเกตพฤติกรรมจริงด้วยตาตัวเอง ไม่ยอมรับรายงานของคนที่ทำการเปลี่ยนแปลง (ไม่ว่ามนุษย์หรือ AI)

smoke test คือเส้นทางที่สั้นที่สุดที่พิสูจน์ว่าชิ้นส่วนหลักยังหายใจอยู่ มันไม่ใช่ความครอบคลุมทั้งหมด แต่เป็น 20% ของการทดสอบที่ดักจับ 80% ของหายนะ สำหรับเว็บ จงเปิด `npm run dev` เปิด route ที่คุณแตะ ทำ action หลัก ดูว่าสิ่งที่คาดเกิดขึ้น สำหรับ script จงรันด้วย input ที่รู้ค่าแล้วเทียบผลกับสิ่งที่คุณ รู้ ว่ามันควรให้ จงนิยาม smoke test ก่อน ขอการเปลี่ยนแปลง ไม่ใช่หลัง เพื่อไม่หลอกตัวเองด้วยการปรับการทดสอบให้เข้ากับผลลัพธ์

ข้ออ้างเหนือการสังเกต อย่ามองหน้าจอเพื่อหาการยืนยัน จงนิยามข้อความที่หักล้างได้ไว้ล่วงหน้า ผิด: 'ดูซิว่าโหลดดีไหม' ถูก: 'เมื่อส่งฟอร์มโดยไม่มี email ต้องปรากฏ error "ต้องระบุ email" และต้องไม่มีแถวถูก insert ใน `leads`' การตรวจสอบที่ดีสามารถเขียนเป็นประโยคที่จะเป็นเท็จชัด ๆ หากการเปลี่ยนแปลงล้มเหลว หากคุณเขียนประโยคนั้นไม่ได้ แสดงว่าคุณไม่รู้ว่ากำลังตรวจสอบอะไร

regression การเปลี่ยนแปลงใหม่มักทำของเก่าพัง คำถามที่แยก senior ออกจาก junior ไม่ใช่ 'feature ของผมทำงานไหม' แต่คือ 'อะไรที่เคยทำงานได้ที่การเปลี่ยนแปลงของผมอาจทำพัง' ในโรงเรียนนี้ การแตะ `galaxy.ts` อาจทำให้แผนที่ SVG และทุกหน้า constelación พัง เพราะมันถูกสร้างจากไฟล์เดียวกัน ก่อนเผยแพร่ จงนึกในใจว่าสิ่ง อื่น ใดบ้างที่ขึ้นกับสิ่งที่คุณแตะ แล้วตรวจอย่างน้อยหนึ่งอย่าง

วิธีใช้ Claude Code เป็น ผู้ตรวจสอบ โดยไม่มอบวิจารณญาณให้มัน จงสั่งให้มันรันคำสั่งจริง (`npm run build`, test, script) แล้ว paste ผลลัพธ์ ดิบ มาให้ ไม่ใช่บทสรุปของมัน 'รัน build แล้ว paste ผลลัพธ์เต็มมาให้' นั้นตรวจสอบได้ ส่วน 'build ทำงานไหม' ชวนให้เกิดการหลอน AI ตรวจสอบด้วยการรันและแสดงหลักฐาน คุณตรวจสอบด้วยการอ่านหลักฐานนั้น ไม่มีวันสลับกัน

การตรวจสอบให้ได้สัดส่วนกับความเสี่ยง (การตรวจสอบทุกอย่างไม่ได้มีต้นทุนเท่ากัน) การเปลี่ยนข้อความ copy อ่าน diff ก็พอ การแตะ RLS, trigger ของ Postgres หรือ flow การจ่ายเงิน build + smoke + regression + ตรวจ advisor operator ที่เป็นผู้ใหญ่ปรับความพยายามในการตรวจสอบให้เข้ากับต้นทุนของการผิดพลาด ไม่ตรวจสอบทุกอย่างเท่ากันและไม่ไว้ใจทุกอย่างเท่ากัน

สัญญาณการเสื่อมของ context เรียงตามลำดับการปรากฏ (1) AI ถามคุณซ้ำในสิ่งที่คุณตอบไปแล้ว (2) มัน re-implement โค้ดที่มีอยู่แล้วหรือ undo การเปลี่ยนแปลงที่ตกลงกัน (3) คำตอบของมันกลายเป็นกว้าง ๆ สูญเสียชื่อเฉพาะของโปรเจกต์คุณ (4) มันแก้ไฟล์ผิดหรือกุ path ขึ้นมา ทันทีที่คุณเห็นสัญญาณ 1-2 คุณอยู่ในเขตสีแดงแล้ว อย่ารอสัญญาณ 4 เพราะถึงตอนนั้นคุณกำลังเก็บกวาดความเสียหาย ไม่ใช่ก้าวหน้า

สัญชาตญาณที่ถูกต้องขัดสามัญสำนึก เมื่อ session หลุดราง การหยุดและ restart เร็วกว่า การยืนยันต่อ การต่อสู้กับ context ที่อิ่มตัวคือดอกเบี้ยทบต้นเชิงลบ ทุกรอบเพิ่มเสียงรบกวนซ้อนเสียงรบกวน คำถามไม่ใช่ 'ผมจะอธิบายให้มันดีกว่านี้ได้อย่างไร' แต่คือ 'context นี้ยังช่วยผมอยู่หรือกีดขวางผมแล้ว' หากกีดขวาง การแก้ไม่ใช่ prompt ที่ดีกว่า แต่คือ context ใหม่

handoff วิธี restart โดย ไม่ สูญเสีย state ก่อนปิด session ที่หลุดราง จงขอบทสรุปการส่งต่อ 'สรุปเป็น block เดียวว่าเรากำลังพยายามทำอะไร ตัดสินใจอะไรไป แตะไฟล์ใด อะไรค้างอยู่ และขั้นตอนถัดไปที่เป็นรูปธรรมคืออะไร' block นั้นคือ state ที่พกพาได้ของคุณ session ใหม่ → paste บทสรุป → Claude Code เริ่มด้วย context สดและความทรงจำเรื่องสำคัญ โดยไม่ลากเสียงรบกวนมา handoff เปลี่ยนการ restart ที่สูญเสียทั้งหมดให้เป็นการ restart ที่ต้นทุนแทบเป็นศูนย์

หน่วยความจำถาวรของคุณอยู่บนดิสก์ ไม่ใช่ใน window สิ่งที่สำคัญจริง ๆ ต้องไม่อยู่แค่ในแชต มันอยู่ใน `CLAUDE.md` (การตัดสินใจของโปรเจกต์ ข้อกำหนด สิ่งที่ห้ามแตะ) และในไฟล์โน้ตของ repo session ใหม่ที่อ่าน `CLAUDE.md` ของคุณก็รู้สิ่งสำคัญอยู่แล้ว กฎคือ หากการตัดสินใจหนึ่งคุณจะต้องใช้พรุ่งนี้ อย่าทิ้งไว้ในแชต จงเขียนลงใน `CLAUDE.md` context window คือ RAM ที่ลบง่าย ส่วน repo คือดิสก์ของคุณ

การป้องกัน session สั้นและโฟกัสเดียวชนะการวิ่งมาราธอน หนึ่ง session = หนึ่งเป้าหมายที่จำกัดขอบเขต 'แก้การตรวจสอบ RLS' เป็น session ที่ดี ส่วน 'refactor backend ทั้งหมด' เป็นมาราธอนที่จะเสื่อมกลางทาง เมื่องานใหญ่ จงแบ่งเป็น session ที่เป็นอิสระต่อกันโดยมี handoff คั่นระหว่างกัน อย่ายัดทั้งหมดลงใน window เดียวที่รับไม่ไหว

การมอบหมายให้ subagent การทำงานคู่ขนานและการแยก context subagent คือ session ลูกที่มี context window ของ ตัวเอง ซึ่งคุณให้งานที่จำกัดขอบเขตและผลงานที่นิยามไว้ ได้ประโยชน์สองอย่าง (1) การทำงานคู่ขนาน subagent หนึ่งตรวจสอบความปลอดภัยขณะอีกตัวเขียน test (2) การแยก subagent เผา context ของมันสำรวจไฟล์มหึมาแล้วส่งคืนเฉพาะบทสรุปให้คุณ โดยไม่ปนเปื้อน session หลักของคุณ คุณมอบหมายสิ่งที่สำรวจแล้วเทอะทะแต่รายงานแล้วกระชับ

วิธีเขียนคำสั่งงานที่ดีให้ subagent ทำราวกับว่า subagent ไม่มีความทรงจำเกี่ยวกับบทสนทนาของคุณ เพราะมันไม่มีจริง ๆ path แบบสมบูรณ์ context ที่ครบในตัว และผลงานที่ชัดเจน ('ส่ง X กลับมาให้ผม') คำสั่งที่คลุมเครือให้ subagent แย่กว่าการไม่มอบหมาย คุณเผา window ทั้งอันไปเพื่อรับขยะกว้าง ๆ subagent โดดเด่นในงานที่มีขอบเขตชัด ไม่ใช่ใน 'ช่วยผมเรื่องนี้หน่อย'

การกู้ประเด็นเมื่อ Claude Code หลงทางกลางงาน อย่าดันต่อ จงหยุด ขอให้มันบอกด้วย คำพูดของมัน เองว่ามันคิดว่ากำลังทำอะไรและทำไม หากเวอร์ชันของมันไม่ตรงกับของคุณ นั่นแหละคือจุดเบี่ยงเบน จงแก้มันอย่างชัดเจนหรือทำ handoff ไปยัง session สะอาด ตัวเลือกที่แย่ที่สุดคือของมือใหม่ คือให้คำสั่งเพิ่มซ้อนบนโมเดลที่เข้าใจผิดไปแล้ว สุมการแก้ไขทับความเข้าใจผิดพื้นฐาน