ทำผลลัพธ์ที่ดีด้วย Claude Code
(dzombak.com)- ในช่วงไม่กี่เดือนที่ผ่านมา ได้ทดลองใช้ LLM programming agents หลายตัว และพบว่า Claude Code เป็นเครื่องมือที่น่าพอใจที่สุด
- ด้วย Claude Code จึงสามารถสร้างโปรแกรมและโปรเจ็กต์ได้ราว 12 รายการ ภายในเวลาอันสั้น และทำงานที่ปกติคงไม่ได้เริ่มเพราะข้อจำกัดด้านเวลาได้
- ปัจจัยสำคัญในการใช้งานให้ได้ผลคือ การเขียนสเปกให้ชัดเจน, การจัดเตรียมเอกสารที่มีโครงสร้างโปรเจ็กต์ วิธี build และ lint, การขอให้ AI รีวิวโค้ดของตัวเอง และการใช้ global agent guide แบบปรับให้เข้ากับตนเอง
- เนื่องจากโค้ดที่ AI เขียนมักอาจ ไม่ถูกต้องหรือไม่มีประสิทธิภาพ จึงต้องตรวจทานโค้ดและ test case ทั้งหมดด้วยตนเองเสมอ และหากการทดสอบยังไม่พอ ก็ต้องเพิ่มเองหรือให้ AI เขียนแล้วตรวจซ้ำอีกครั้ง
- ภาคผนวกที่เผยแพร่เป็น global agent guide มี แนวทางการพัฒนาอย่างละเอียด เช่น แผนการ implement แบบเป็นขั้นตอน, test-driven development, ปรัชญาที่เน้นความเรียบง่าย ความชัดเจน และการใช้งานได้จริง, มาตรฐานคุณภาพ และกระบวนการแก้ปัญหา
ประสบการณ์และผลลัพธ์จากการใช้ Claude Code
- ในช่วงหลายเดือนที่ผ่านมา ได้ทดลองใช้ LLM programming agents หลายตัว และโดยเฉพาะอย่างยิ่งพบว่าประสบการณ์การใช้ Claude Code ดีที่สุด
- แม้จะไม่ได้ไร้ปัญหาเสียทีเดียว แต่ก็สามารถทำโปรแกรมและโปรเจ็กต์ได้มากกว่า 12 รายการในเวลาอันสั้น
- หากไม่มี Claude Code ก็คงแทบเป็นไปไม่ได้ที่จะทำงานทั้งหมดนี้ให้เสร็จภายในช่วงเวลาเดียวกัน
- หลายงานเป็นโปรเจ็กต์ที่คงไม่ได้ลองเริ่มด้วยซ้ำ เพราะใช้เวลามากเกินไป
กลยุทธ์การใช้งาน Claude Code
- เขียนสเปกให้ชัดเจน
- ก่อนเริ่มโปรเจ็กต์ ให้จัดทำเอกสารความต้องการและบริบทให้ชัดเจนเพื่อส่งต่อให้เอเจนต์
- วิธีนี้ช่วยกำหนดทิศทางและขอบเขตของการเขียนโค้ดให้ชัดเจน
- จัดทำเอกสารโครงสร้างโปรเจ็กต์
- เตรียมเอกสารที่รวมวิธีรัน build, lint และ test
- ทำให้เอเจนต์สำรวจ codebase และทำงานได้อย่างมีประสิทธิภาพมากขึ้น
- ขอให้เอเจนต์รีวิวโค้ด
- ให้ Claude Code รีวิวโค้ดที่สร้างขึ้นเองโดยตรง เพื่อค้นหาจุดปรับปรุงหรือบั๊กที่ไม่คาดคิด
- ใช้ global guide ส่วนตัว
- ใช้
~/.claude/CLAUDE.mdซึ่งบรรจุกฎส่วนตัว เช่น แนวทางการแก้ปัญหา, การใช้ TDD, การรักษาความเรียบง่ายและความชัดเจน, การจำกัดจำนวนครั้งที่ลอง (3 ครั้ง) เพื่อคงกระบวนการพัฒนาให้สม่ำเสมอ
- ใช้
การตรวจสอบโค้ดที่ LLM เขียน
- โค้ดที่ AI สร้างมักมีปัญหาอย่าง ข้อผิดพลาดเชิงตรรกะ, ประสิทธิภาพลดลง, หรือ การทดสอบไม่สมบูรณ์
- ผู้เขียนตรวจทานโค้ดทั้งหมดแบบ manual และยืนยันการทำงานด้วยตนเอง
- เพิ่ม test case ที่ขาดไปด้วยตนเอง
- หรือให้ AI เขียน แล้วตรวจทานโค้ดและการทดสอบอีกครั้ง
- ในสภาพแวดล้อมการทำงานแบบมืออาชีพ เมื่อชื่อของตนอยู่ใน PR ก็เน้นย้ำว่า ความรับผิดชอบต่อคุณภาพขั้นสุดท้ายเป็นของตัวเอง
ประเด็นสำคัญของ “global” agent guide ส่วนตัว
คู่มือนี้จัดการผ่านไฟล์ ~/.claude/CLAUDE.md
-
ปรัชญาและหลักการสำคัญ
- ค่อยเป็นค่อยไป: เปลี่ยนแปลงทีละเล็ก และต้อง compile กับ test ผ่านเสมอ
- เรียนรู้จากโค้ดเดิม: วิเคราะห์แพตเทิร์นของโค้ดและวางแผนก่อน implement
- ให้ความสำคัญกับการใช้งานจริง: ใช้วิธีที่ยืดหยุ่นตามสถานการณ์ของโปรเจ็กต์
- ให้ความสำคัญกับความชัดเจน: โค้ดที่อ่านง่ายและเจตนาชัดเจน หลีกเลี่ยงลูกเล่นที่ไม่จำเป็น
-
นิยามของความเรียบง่าย
- ฟังก์ชันและคลาสมีหน้าที่เดียว
- หลีกเลี่ยงการทำ abstraction เร็วเกินไป
- ลดความซับซ้อน และมุ่งสู่โค้ดที่ไม่ต้องอธิบายเพิ่มเติม
-
กระบวนการทำงาน
- 1. วางแผนและกำหนดขั้นตอน:
- งานที่ซับซ้อนให้แบ่งเป็น 3~5 ขั้น แล้วบันทึกไว้ใน
IMPLEMENTATION_PLAN.md - ระบุเป้าหมายของแต่ละขั้น, เกณฑ์ความสำเร็จ, test case และสถานะความคืบหน้า
- งานที่ซับซ้อนให้แบ่งเป็น 3~5 ขั้น แล้วบันทึกไว้ใน
- 2. ลำดับการ implement:
- ทำความเข้าใจ → เขียน test (red) → implement ขั้นต่ำสุด (green) → refactor → commit
- 3. ประเมินใหม่หลังลองครบ 3 ครั้ง:
- เมื่อไม่สำเร็จ ให้บันทึกสิ่งที่ลอง, ข้อผิดพลาด และสาเหตุ
- สำรวจทางเลือก (2~3 แนวทาง)
- ทบทวนการออกแบบพื้นฐานหรือการแยกปัญหาใหม่
- ลองใช้แพตเทิร์นหรือฟีเจอร์อื่น
- 1. วางแผนและกำหนดขั้นตอน:
-
มาตรฐานทางเทคนิค
- ให้ความสำคัญกับ composition และใช้ dependency injection
- ใช้ interface เพื่อให้ทดสอบได้ง่าย
- data flow แบบ explicit
- แนะนำ TDD และห้ามปิดการทดสอบ
-
กฎคุณภาพโค้ด
- ทุก commit ต้อง compile สำเร็จ, test ผ่าน, มีการทดสอบสำหรับฟีเจอร์ใหม่ และเป็นไปตาม code style
- ก่อน commit ให้รัน formatter และ linter, รีวิวการเปลี่ยนแปลงด้วยตนเอง และเขียน commit message ที่อธิบายว่า “ทำไม”
-
การจัดการข้อผิดพลาด
- fail fast พร้อมข้อความที่เฉพาะเจาะจง
- ให้ context ที่จำเป็นต่อการ debugging
- จัดการ exception ในระดับที่เหมาะสม และห้ามกลบข้อยกเว้น
-
เกณฑ์การตัดสินใจ
- 1. ความง่ายในการทดสอบ
- 2. ความอ่านง่ายที่ยังเข้าใจได้แม้ผ่านไป 6 เดือน
- 3. ความสอดคล้องกับแพตเทิร์นของโปรเจ็กต์
- 4. ความเรียบง่าย
- 5. ความง่ายต่อการเปลี่ยนแปลง
-
การผสานเข้ากับโปรเจ็กต์
- วิเคราะห์ฟีเจอร์ที่คล้ายกันอย่างน้อย 3 รายการ
- ใช้แพตเทิร์นและไลบรารีเดิมซ้ำ
- ใช้ test utility เดียวกัน
- หากจะนำเครื่องมือใหม่เข้ามา ต้องมีเหตุผลที่หนักแน่น
-
quality gate
- test ทั้งหมดต้องผ่าน
- ปฏิบัติตามกฎของโปรเจ็กต์
- ไม่มีคำเตือนจาก linter
- commit message ชัดเจน
- การ implement สอดคล้องกับแผน
- TODO ต้องมีหมายเลข issue
-
แนวทางการทดสอบ
- ทดสอบโดยยึด พฤติกรรม ไม่ใช่การ implement
- ถ้าเป็นไปได้ให้มี assertion เดียวต่อหนึ่งการทดสอบ
- ใช้ชื่อที่ชัดเจนเพื่ออธิบาย scenario
- ใช้ test utility เดิมซ้ำ
- การทดสอบต้องเป็น deterministic
-
สิ่งที่ห้ามอย่างเด็ดขาด
- bypass hook ด้วย
--no-verify - ปิดการทดสอบ
- commit โค้ดที่ compile ไม่ได้
- คาดเดาโดยไม่มีการตรวจสอบ
- bypass hook ด้วย
-
สิ่งที่ต้องทำเสมอ
- commit แบบค่อยเป็นค่อยไป
- อัปเดตเอกสารอย่างต่อเนื่อง
- เรียนรู้จาก implementation เดิม
- หากล้มเหลว 3 ครั้ง ให้ประเมินแนวทางใหม่
โครงการโอเพนซอร์สที่สร้างด้วย Claude Code
- reverse proxy ที่รับรู้ HTML/XML (cdzombak/xrp)
- ธีม Solarized สำหรับ VS Code (สว่าง/มืด) (cdzombak/dzsolarized-vscode)
- ตัวสร้าง RSS สำหรับ Flickr photostream (cdzombak/flickr-rss)
- เครื่องมือ metadata สำหรับคลังภาพ Lychee (cdzombak/lychee-meta-tool)
- รายงานสถานะ screen lock ของ macOS ผ่าน MQTT (cdzombak/macos-screenlock-mqtt)
- ตั้งชื่อรูป Bird Buddy ใน Lychee อัตโนมัติ (cdzombak/lychee-birb-title)
- จัดหมวดหมู่รูปภาพอัตโนมัติด้วย local LLM (cdzombak/lychee-ai-organizer)
- ระบบอัตโนมัติสำหรับติดตั้งซอฟต์แวร์แบบชุดบน macOS (cdzombak/mac-install)
- โปรเจ็กต์บริการ RSS (cdzombak/rss.church)
- ส่งออกรูป Flickr ทั้งหมด/บางส่วนพร้อมเก็บรักษา metadata (cdzombak/flickr-exporter)
- ตัวสร้างแกลเลอรี HTML แบบ static (cdzombak/gallerygen)
5 ความคิดเห็น
การที่ได้ผลลัพธ์ที่ดี หมายความว่าได้อ้างอิงโค้ดที่คนอื่นทำไว้แล้วอย่างดีใช่ไหม
สิ่งที่ผู้เขียนทำมานี่ทุกคนก็ทำกันมาตั้งนานแล้ว เลยอย่าเอาเรื่องไม่จำเป็นมาคุยอวดเลย
ถ้าเทียบกันระหว่าง LLM แล้ว ทำไมถึงคิดว่า Claude ดีที่สุด น่าจะเขียนเหตุผลให้ชัดเจน ซึ่งจะเป็นบทความที่มีความหมายมากกว่ามาก
เช่น การเปรียบเทียบโค้ดที่สร้างขึ้นจริง ความถี่ของ compile error ความเสถียรในการทำความเข้าใจบริบท ฯลฯ
จริง ๆ แล้วตัวที่เก่งที่สุดในการทำความเข้าใจบริบทคือ Gemini (1 ล้านโทเค็น)
ทำแต่ของที่แทบไม่มีประโยชน์ แล้วก็เขียนยืดยาวเสียเปล่า
อาจจะมีประโยชน์สำหรับบางคนก็ได้นะ ฮ่าๆ
ความคิดเห็นบน Hacker News
วันนี้เป็นครั้งแรกที่ผมประสบความสำเร็จจริงจังกับ Claude และ coding agent ก่อนหน้านี้เคยใช้ Cursor แต่ตอนนี้กำลังลอง Claude ควบคู่กับตัวอื่น ๆ อยู่ด้วย อย่างที่บทความบอกไว้ หัวใจสำคัญคือการเขียนสเปกให้ชัดเจน ผมใช้เวลา 2 ชั่วโมงเขียนเอกสาร 12 ขั้นตอนด้วยตัวเองเพื่อจัดระเบียบวิธีการพัฒนาและใส่ข้อมูลพื้นหลังไว้ด้วย Claude ก็สร้างโค้ดตามขั้นตอนนั้นไปทีละลำดับ เท่าที่ผมประเมินน่าจะประหยัดเวลาไปได้ราว 6–10 ชั่วโมง จากนี้ผมจะตรวจทาน ทดสอบ แล้วค่อย ๆ ปรับจูนและเพิ่มฟีเจอร์ต่อไป ความสำเร็จครั้งนี้เกิดจากการที่ผมเขียนทุกขั้นตอนที่ Claude ต้องทำไว้อย่างชัดเจนเอง กล่าวคือผมเป็นคนออกแบบภาพรวมทั้งหมด แล้ว Claude ก็แค่ทำตามคำสั่ง กระบวนการนี้ทำให้ผมมั่นใจว่านักพัฒนาระดับกลางขึ้นไปคงยังไม่ถูก AI แทนที่ในเร็ว ๆ นี้ แต่การได้เห็น Claude อ่านสเปกยาว ๆ แล้วดึงออกมาเป็นโค้ดที่เป็นระเบียบและมีเอกสารกำกับก็เป็นประสบการณ์ที่น่าทึ่งจริง ๆ ยอดเยี่ยมมากที่ผมไม่ต้องลงมือเขียนโค้ดเอง
ผมได้ผลลัพธ์ที่ดีกับ Claude โดยไม่ต้องเตรียมตัวหนักขนาดนี้ ผมแทบจะสั่ง Claude ทีละขั้นเหมือนตอนเขียนโค้ดเอง ทุกครั้งก็ให้มันนำส่วนที่เปลี่ยนไปใช้ทันทีแล้วคอมมิต จากนั้นผมค่อยตรวจ diff ถ้า Claude ทำอะไรเพี้ยนก็ขอให้แก้ทันที และผมจะบอก reference ของโค้ดหรือฟังก์ชันเดิมที่อยากให้นำไปใช้ด้วย วิธีนี้ทำให้ได้ผลลัพธ์ที่ยอดเยี่ยมโดยพิมพ์น้อยลงและใช้เวลาน้อยลงมาก
แนะนำให้อ่าน “Programming as Theory Building” ของ Naur นี่เป็นประสบการณ์ที่สอนให้รู้ว่าต้องเข้าใจปัญหาในเชิงทฤษฎีและสร้างโมเดลด้วยตัวเองอย่างไร ไม่อย่างนั้น LLM อาจสร้างทฤษฎีของตัวเองขึ้นมาแบบผิด ๆ ได้
อ่าน “Programming as Theory Building” - Naur
อย่างที่บทความบอก สเปกที่ชัดเจนสำคัญมากจริง ๆ ตอนนี้ผมกำลังสร้างภาษาโปรแกรมด้วย Claude และสัมผัสเรื่องนี้ได้โดยตรง การเขียนโปรแกรมเต็มไปด้วยการตัดสินใจเล็ก ๆ น้อย ๆ มากมาย ถ้าไม่กำหนดแนวทางให้ชัด LLM ก็จะเดาเอาเองเป็นส่วนใหญ่ ซึ่งมักเลือกผิด และความผิดพลาดเล็ก ๆ เหล่านี้เมื่อสะสมรวมกันก็อาจนำไปสู่ผลลัพธ์ที่ผิดได้
ถ้าแบ่งปันตัวอย่างเอกสารสเปกแบบนี้ได้ก็คงดีมาก สำหรับคนที่กำลังหัดพัฒนาเองและทดลองใช้ Claude Code การได้เห็นว่าข้อมูลแบบไหนและลึกแค่ไหนถึงจะมีประโยชน์ น่าจะช่วยได้มาก
จริง ๆ แล้วนักพัฒนาระดับกลางและระดับซีเนียร์จำนวนไม่น้อยก็ยังเขียนสเปกที่ดีไม่ได้ แต่ผมเห็นด้วยกับเจตนาที่ต้องการจะสื่อ
การสร้าง ~/.claude/CLAUDE.md แล้วใส่กฎลงไป ดูแล้วแทบไม่มีผลมากนัก Claude ไม่ใช่มนุษย์และไม่ได้ใช้เหตุผลอย่างระมัดระวังกับโค้ดทีละบรรทัด คำแนะนำที่เป็นนามธรรมและกำกวมไม่ได้ทำให้มันเปลี่ยนโค้ดจริง ๆ และยังมีปัญหาที่เรียกว่า 'context rot' อยู่ด้วย
(คำอธิบายของ context rot: เป็นปรากฏการณ์ที่ LLM สูญเสียหรือบิดเบือนบริบทระหว่างการสนทนาหรือการทำงานที่ยาวนาน ดูลิงก์อ้างอิง: https://news.ycombinator.com/item?id=44564248)
ในทางปฏิบัติ การยัดกฎสารพัดอย่างไว้ในไฟล์เดียวแล้วคาดหวังให้ AI ปฏิบัติตามเองนั้นเป็นไปไม่ได้ ถ้าจะทำแบบนั้นต้องสร้าง sub-agent สำหรับแต่ละกฎ แล้วแยกออกไปเป็น pipeline แบบทั่วไปที่ไม่พึ่ง AI แต่พอทำอย่างนั้นต้นทุนก็จะเพิ่มขึ้นแบบทวีคูณ
ถ้าเป็นเรื่องต้นทุน หลังจาก workflow เริ่มนิ่งแล้วก็สามารถใช้ LLM ที่ราคาถูกกว่าได้ (แม้ค่าใช้จ่ายในการดำเนินงานยังสูงอยู่) สามารถลดต้นทุนได้ด้วย fine-tuning, การปรับแต่ง prompt, เทคนิค distillation เฉพาะทาง ฯลฯ เรื่องนี้มีงานวิจัยจำนวนมากอยู่แล้ว
อยากรู้ว่าใน CLAUDE.md ควรใส่อะไรไว้บ้าง
ถ้าดูตัวอย่างโปรเจกต์ด้านล่างของหน้า จะเห็นว่าส่วนใหญ่เป็นซอฟต์แววร์ที่ปรับให้เหมาะกับเป้าหมายเฉพาะอย่างเดียว ต่อไปโปรเจกต์โอเพนซอร์สน่าจะพัฒนาไปในทิศทางนี้เช่นกัน คือมีความเฉพาะทางมากเพื่อสนองความต้องการของคนคนเดียว ผมคิดว่าซอฟต์แวร์แบบนี้ (utility) จะค่อย ๆ กลายเป็นโค้ดใช้แล้วทิ้งที่ LLM สร้างขึ้นในครั้งเดียว
วิธีที่ผมใช้กับ Claude Code เปลี่ยนไปเรื่อย ๆ ผมยังไม่เคยทำให้ Claude Code สร้างฟีเจอร์ที่มีความหมายจริง ๆ แล้วนำเข้าแอปเว็บขนาดใหญ่ของบริษัทได้สำเร็จโดยตรง สเปกช่วยได้บ้าง แต่สุดท้ายมันก็มักไหลไปในทิศทางแปลก ๆ และติดลูปของการเลือกผิดซ้ำ ๆ อาจเป็นข้อจำกัดของ Claude หรืออาจเป็นเพราะสเปกของผมยังไม่แม่นพอ ผมทดลองมาเยอะแล้ว แต่กับงานที่ “ท้าทายหรือใช้ความรู้โดเมนเฉพาะสูง” มักล้มเหลวบ่อยจนเลิกพยายามไปแล้ว ตอนนี้ตามคำแนะนำของเพื่อน ผมเริ่มใช้ Claude กับงาน backlog ที่แทบไม่กินพลังใจแทน เช่น ให้มันสร้าง Playwright tests ใน workspace ใหม่สำหรับงานที่ผมไม่ได้ผูกพันมาก ปรากฏว่าประสบความสำเร็จมาก ผมอธิบาย user experience ให้ Claude ฟังเหมือนอธิบายให้คนฟัง แล้วบอก path ของ dev server ให้มัน จากนั้นสั่งให้ใช้ Playwright MCP เพื่อหาว่าควรใช้ feature ไหนอย่างไร ทำเอกสารขั้นตอนการรัน เขียนเทสต์ และดีบัก error รวมถึงให้ไปค้นโค้ด UI ในโปรเจกต์เพื่อเพิ่ม selector แบบ
data-testidด้วย ผมสรุปกระบวนการทั้งหมดไว้ใน master task.md และสั่งให้สร้าง task markdown แยกสำหรับแต่ละฟีเจอร์ วิธีนี้ได้ผลดีมาก โดยเฉพาะกับฟีเจอร์ซับซ้อนที่มีผู้ใช้เบราว์เซอร์ 2 คนโต้ตอบกันแบบไม่ค่อยตรงไปตรงมา ถึงจะไม่แม่น 100% แต่ยิ่งซับซ้อนก็แค่ต้องช่วยปรับบริบทและแก้โค้ดเพิ่มอีกนิด โดยรวมแล้วมันช่วยจัดการงานน่ารำคาญที่ปกติอาจกินเวลาหลายวันได้ในคราวเดียวสิ่งที่ได้ผลดีที่สุดคือทำให้ CLAUDE.md เป็นไฟล์มินิมัลไม่เกิน 100 บรรทัดให้มากที่สุด
package.jsonซ้ำไปซ้ำมา ระหว่าง flow การพัฒนา/ทดสอบ จากประสบการณ์ของผม Claude มักพยายามเขียนเทสต์ทั้งหมดล่วงหน้าในครั้งเดียว หรือไม่ก็ไปลงมือ implement ทั้งหมดก็ต่อเมื่อ import ล้มเหลวเท่านั้น (ซึ่งไม่ใช่ TDD ที่ถูกต้อง) ผมเลยสร้าง hook ชื่อ TDD-Guard เพื่อบังคับให้ผ่านทีละหนึ่งเทสต์เท่านั้น ให้เทสต์ล้มเหลวด้วยเหตุผลที่ถูกต้อง และ implement เฉพาะโค้ดขั้นต่ำที่ทำให้เทสต์ผ่าน คุณภาพโค้ดก็ดูแลด้วยการทำ automation ผ่าน husky, lint-staged, commitlint ฯลฯ ซึ่งให้ผลดีมาก แบบนี้จะเหลือ context ไว้ให้ข้อมูลที่สำคัญกว่ามากขึ้น ผมเห็นด้วยว่าถ้า Claude Code ตัน สุดท้ายวิธีที่ดีที่สุดก็คือนักพัฒนาต้องลงมาแทรกแซงเอง เพียงแต่ถ้าเป็นไกด์ที่กว้างเกินไปก็น่าเสียดายผมทำงานกับ Claude Code ทุกวันมานานกว่าหนึ่งเดือนแล้ว เคยใช้ Cursor, Q และตัวอื่น ๆ แต่ Claude Code เหนือกว่ามาก เคล็ดลับที่บทความพูดถึงก็ตรงกับสิ่งที่ผมค้นพบเองหลายอย่าง
ถ้าจะเสริมอีกนิด:
ผมเริ่มจาก session ระดมไอเดียกับ Claude บนเว็บคอนโซล อธิบายเป้าหมายของโปรเจกต์ วางกรอบ domain modeling และ milestones แบบกว้าง ๆ ถ้าเป็นโปรเจกต์เล็กก็สรุปกันได้ภายในไม่กี่ชั่วโมงจากการคุยไปมา ตรงนี้จะได้ CLAUDE.md เวอร์ชันแรกออกมา
พอเริ่มโปรเจกต์จริง Claude จะอ่านทั้ง global CLAUDE.md และ project CLAUDE.md ของผมก่อนเริ่ม ทุก session ก็ทำแบบนี้
ระหว่างทำงาน ผมยังสั่งให้ Claude Code อัปเดต project CLAUDE.md ต่อเนื่องด้วย โดยให้มันทำเครื่องหมายความคืบหน้าตามแผน และตอนท้าย session ก็ให้เขียนสรุปโปรเจกต์ วิธีการทำงาน และวิธีนำทางในโค้ดลงไป มันเหมือนเป็นความจำระยะยาว ได้ผลดีมาก
ต่อให้มี guideline ดีแค่ไหน Claude ก็ยังมีแนวโน้มจะพุ่งนำไปก่อนอยู่ดี เพราะงั้นงานที่ผมมีส่วนร่วมด้วยจะบังคับให้มันโฟกัสทีละขั้นแบบ increment เล็ก ๆ แต่ถ้าเป็นงานใช้ครั้งเดียวหรือ prototype ก็ปล่อยให้มันลงมือทำได้เต็มที่
CLAUDE.md ระดับโปรเจกต์ควรสั้น กระชับ และไม่ยาวเกินไป แล้วค่อยย้ายรายละเอียดที่ลึกกว่านั้นไปไว้ในโฟลเดอร์ย่อย โดยใช้ไฟล์ระดับบนสุดเหมือนเป็นแผนที่ เวลาออกแบบฟีเจอร์แต่ละอย่าง Claude ก็จะเข้าไปดูโฟลเดอร์ที่เหมาะสม อ้างอิง context ที่จำเป็น และวางแผน implementation ทีละขั้น พอจบแต่ละขั้น ผมจะสั่งให้ Claude อัปเดตแผน implementation ตาม context ใหม่ วิธีนี้ช่วยให้ context ไหลต่อไปยังขั้นถัดไปอย่างเป็นธรรมชาติ และยังรีเซ็ตหน้าต่างเพื่อเริ่มขั้นถัดไปด้วยมุมมองใหม่ได้ด้วย
ผมกำลังใช้ Claude Code สร้างเกม ASCII แนว factorio ตอนช่วงแรกปล่อยให้มันเขียนโค้ดแทบไม่มีการเฝ้าดู และมันก็ทำฟีเจอร์หลักส่วนใหญ่ได้ในทีเดียว (save/load, options, debug, map generation, construction, belts, crafting, QoL ฯลฯ) แต่พอเริ่มแก้รายละเอียด กลับเจอว่าถ้าเปลี่ยนการเคลื่อนที่ ตัวสายพานก็พังตามไปด้วย อะไรหลายอย่างพังต่อเนื่อง ผมเลยให้มันเพิ่ม automation ด้วย Playwright แต่คุณภาพเทสต์ต่ำและมีการเรียก
sleepเต็มไปหมด พอดูโค้ดละเอียด ๆ ก็พบว่าโครงสร้างเป็น React frontend ที่ใช้useEffectและไม่ได้ออกแบบแบบ game engine ที่เหมาะสม มันไม่ค่อยรักษากฎของ hook และเข้าใจเรื่อง timing ไม่ดีนัก รอบนี้เลยเริ่มทำใหม่ตั้งแต่ต้นด้วย game engine แบบ tick-based และเพิ่ม code review เข้าไปด้วย ความเร็วช้าลงก็จริง แต่พัฒนาได้แข็งแรงขึ้นมาก ถ้าทำเดโมดี ๆ เสร็จแล้วตั้งใจจะเอาไปโพสต์ Show HNถ้าใครเหมือนผมที่ใช้ทั้งบัญชี Claude สำหรับงานและส่วนตัว ก็สามารถสลับบัญชีได้ง่าย ๆ ด้วยวิธีแบบนี้:
alias claude-personal="CLAUDE_CONFIG_DIR=~/.claude-personal claude"บล็อกว่าด้วยการใช้หลายบัญชี Claude อย่างมีประสิทธิภาพ
ทุกคนชอบพูดว่า “หัวใจสำคัญคือเขียนสเปกให้ชัดล่วงหน้าเพื่อให้ context” แต่จากประสบการณ์ของผม มันไม่ได้เวิร์กเสมอไป ผมเคยนั่งทำ CC session กับผู้เชี่ยวชาญตัวจริงโดยใช้ Opus 4 & Sonnet 4 อีกฝ่ายเตรียม spec ที่ชัดมาก แต่ผลลัพธ์ก็ไม่ได้ดีกว่าวิธีของผมเท่าไรนัก (คือคิดฟีเจอร์อะไรได้ก็สั่งไปตามนั้น ใช้ context แยกเป็นเรื่อง ๆ และไม่ใช้ CLAUDE.md) workflow แบบอิงสเปกมักลืมเรื่องสำคัญอยู่เรื่อย ๆ หรือไม่ก็แต่งสิ่งที่ไม่มีในเอกสาร context ขึ้นมาเองแบบสุ่ม ๆ (แม้แต่เรื่องที่ห้ามไว้แล้วก็ตาม) ในขณะที่วิธีของผมอย่างเช่น “เพิ่มหน้า crud สำหรับ invoice ให้หน่อย ก่อนอื่นลองวิเคราะห์ codebase ก่อน” กลับได้ผลดีกว่า นี่เป็นแค่ประสบการณ์เชิงเล่าเรื่องของผม แต่ผมทำโปรเจกต์กับ Claude มาแล้วมากกว่า 100 โปรเจกต์ และยังไม่มั่นใจว่าวิธีไหนดีกว่าอย่างชัดเจน นอกจากการมี hook แยกไว้คอยกันไม่ให้ Claude ก้าวล้ำเกินขอบเขต ถึงจะมีหลายคนบอกว่าแนวทางอิงสเปกดีกว่า แต่พอขอให้แสดงให้ดูจริง ๆ กลับพบว่าหลายคนใช้เวลาไปมากกับการคอยแก้สิ่งที่ผิดอย่างเห็นได้ชัดซ้ำแล้วซ้ำอีก บางครั้งถึงกับเขียนใน CLAUDE.md ว่า “ห้ามทำแบบนี้เด็ดขาด” แล้วมันก็ยังชอบทำอยู่ดี