Claude Code ทำงานอย่างไรในโค้ดเบสขนาดใหญ่: แนวทางปฏิบัติที่ดีและจุดเริ่มต้น

 (claude.com)
4 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Claude Code อ่านโค้ดเบสที่กำลังใช้งานอยู่โดยตรงผ่านการสำรวจระบบไฟล์ และใช้ grep กับการติดตาม reference บนเครื่องของนักพัฒนา โดยไม่ต้องอัปโหลดดัชนี
  • ประสิทธิภาพไม่ได้ขึ้นอยู่กับโมเดลอย่างเดียว แต่ขึ้นอยู่มากกับharnessและลำดับการตั้งค่าที่ประกอบด้วย CLAUDE.md, hooks, skills, plugins และเซิร์ฟเวอร์ MCP
  • ในรีโพซิทอรีขนาดใหญ่ การใช้ CLAUDE.md แบบบางและเป็นลำดับชั้น, การเริ่มจากไดเรกทอรีย่อย, การกำหนดขอบเขต test·lint และกฎการยกเว้น จะช่วยเพิ่มประสิทธิภาพในการสำรวจ
  • การผสานรวม LSP ช่วยให้ติดตามนิยามและ reference ตาม symbol แทนการค้นหาสตริง จึงลดการสำรวจผิดพลาดในโค้ดเบสขนาดใหญ่และหลายภาษา
  • การนำไปใช้ให้สำเร็จต้องมีการทบทวนการตั้งค่าทุก 3–6 เดือน และต้องมี DRI หรือ agent manager สำหรับดูแล plugin·สิทธิ์·กฎต่างๆ

Claude Code สำรวจในโค้ดเบสขนาดใหญ่อย่างไร

  • Claude Code ไล่ดูระบบไฟล์เหมือนวิศวกรซอฟต์แวร์ อ่านไฟล์ ใช้ grep ค้นหาสิ่งที่ต้องการ และติดตาม reference ทั่วทั้งโค้ดเบส
  • ทำงานแบบ โลคัลบนเครื่องนักพัฒนา โดยไม่ต้องสร้างหรือดูแลดัชนีของโค้ดเบส หรืออัปโหลดขึ้นเซิร์ฟเวอร์
  • เครื่องมือ AI coding ที่อิง RAG จะฝัง embedding ของทั้งโค้ดเบสและดึง chunk ที่เกี่ยวข้องตอน query แต่ในสภาพแวดล้อมขนาดใหญ่ pipeline สำหรับ embedding อาจตามความเร็วของการพัฒนาที่เปลี่ยนแปลงตลอดไม่ทัน
  • หากดัชนีสะท้อนสถานะเมื่อหลายสัปดาห์ หลายวัน หรือหลายชั่วโมงก่อน ก็อาจคืนค่าฟังก์ชันที่เปลี่ยนชื่อไปแล้ว หรือโมดูลที่ถูกลบไปตั้งแต่ sprint ที่แล้ว โดยไม่มีสัญญาณบอกว่าข้อมูลนั้นล้าสมัย
  • การค้นหาแบบ agentic ของ Claude Code ทำให้แต่ละอินสแตนซ์ของนักพัฒนาทำงานบนโค้ดเบสที่ยังมีชีวิตอยู่ได้ โดยไม่ต้องพึ่ง pipeline embedding หรือดัชนีกลาง
  • แต่ก็มีข้อเสีย: Claude จะทำงานได้ดีที่สุดเมื่อมี บริบทตั้งต้น มากพอที่จะรู้ว่าควรดูตรงไหน
  • ถ้าสั่งให้หาทุกอินสแตนซ์ของแพตเทิร์นที่คลุมเครือในโค้ดเบสระดับพันล้านบรรทัด ก็อาจชนข้อจำกัดของ context window ตั้งแต่ก่อนเริ่มงาน
  • ทีมที่จัดโครงสร้างโค้ดเบสไว้ดีและจัดลำดับบริบทด้วยไฟล์ CLAUDE.md และ skills จะได้ผลลัพธ์ที่ดีกว่า

Harness สำคัญพอๆ กับโมเดล

  • ประสิทธิภาพของ Claude Code ขึ้นอยู่กับ harness ที่สร้างไว้รอบโมเดลมากพอๆ หรือมากกว่าตัวโมเดลเอง
  • Harness นี้ประกอบด้วยจุดขยาย 5 ส่วนคือ CLAUDE.md, hooks, skills, plugins และเซิร์ฟเวอร์ MCP
  • แต่ละชั้นจะวางทับบนชั้นก่อนหน้า ดังนั้นลำดับที่ทีมใช้สร้างจึงสำคัญ
  • การผสานรวม LSP และ subagents ทำหน้าที่เป็นความสามารถเพิ่มเติมที่ช่วยเสริมการตั้งค่านี้

  • ไฟล์ CLAUDE.md

    • CLAUDE.md คือ ไฟล์บริบท ที่ Claude จะอ่านอัตโนมัติเมื่อเริ่มทุกเซสชัน
    • ไฟล์ที่ root ใช้เก็บภาพรวม ส่วนไฟล์ในไดเรกทอรีย่อยเก็บกฎเฉพาะพื้นที่
    • เนื่องจากมันถูกโหลดในทุกเซสชัน จึงควรเน้นเฉพาะสิ่งที่ใช้ได้กว้างๆ เพื่อหลีกเลี่ยงประสิทธิภาพที่ลดลง

  • Hooks

    • Hooks ไม่ได้เป็นแค่สคริปต์สำหรับป้องกันพฤติกรรมผิดพลาดของ Claude เท่านั้น แต่ยังมีคุณค่ามากกว่าในแง่ของการปรับปรุงการตั้งค่าอย่างต่อเนื่อง
    • stop hook สามารถย้อนดูสิ่งที่เกิดขึ้นในเซสชันและเสนอให้อัปเดต CLAUDE.md ขณะที่บริบทยังสดใหม่
    • start hook สามารถโหลดบริบทเฉพาะทีมแบบไดนามิก เพื่อให้นักพัฒนาได้รับการตั้งค่าที่เหมาะกับโมดูลของตัวเองโดยไม่ต้องตั้งค่าด้วยมือ
    • การตรวจอัตโนมัติอย่าง linting และ formatting ให้ผลสม่ำเสมอกว่า เมื่อบังคับใช้กฎผ่าน hook อย่างชัดเจน แทนที่จะหวังให้ Claude จำคำสั่งไว้เอง

  • Skills

    • Skills ช่วยคงความเชี่ยวชาญที่จำเป็นไว้แบบ on-demand โดยไม่ทำให้ทุกเซสชันบวมเกินไป
    • โค้ดเบสขนาดใหญ่อาจมีงานหลายสิบประเภท แต่ไม่จำเป็นต้องใส่ความเชี่ยวชาญทั้งหมดลงในทุกเซสชัน
    • Skills ใช้แนวทาง progressive disclosure โดยเก็บเวิร์กโฟลว์เฉพาะทางและความรู้โดเมนไว้นอกพื้นที่บริบท แล้วโหลดเมื่อจำเป็นเท่านั้น
    • เช่น skill สำหรับ security review จะถูกโหลดเมื่อ Claude ต้องประเมินช่องโหว่ ส่วน skill สำหรับจัดการเอกสารจะถูกโหลดเมื่อต้องอัปเดตเอกสารหลังมีการเปลี่ยนโค้ด
    • Skills สามารถกำหนดขอบเขตตาม path ได้ เช่น skill สำหรับ deploy ของทีมบริการชำระเงินอาจผูกไว้เฉพาะกับไดเรกทอรีนั้น และไม่ถูกโหลดอัตโนมัติเมื่อทำงานในส่วนอื่นของ monorepo

  • Plugins

    • Plugins คือวิธีนำการตั้งค่าที่ใช้ได้ผลไปเผยแพร่ โดยไม่ปล่อยให้กลายเป็น ความรู้ที่กระจัดกระจายอยู่กับบางคน
    • plugin จะรวม skills, hooks และการตั้งค่า MCP ไว้ในแพ็กเกจเดียวที่ติดตั้งได้
    • เมื่อนักพัฒนาใหม่ติดตั้ง plugin ตั้งแต่วันแรก ก็จะได้บริบทและความสามารถแบบเดียวกับคนที่ใช้ Claude อยู่แล้วทันที
    • การอัปเดต plugin สามารถกระจายให้ทั้งองค์กรผ่าน managed marketplaces
    • องค์กรค้าปลีกขนาดใหญ่แห่งหนึ่งสร้าง skill ที่เชื่อม Claude เข้ากับแพลตฟอร์มวิเคราะห์ภายใน เพื่อให้นักวิเคราะห์ธุรกิจดึงข้อมูลผลการดำเนินงานได้โดยไม่ต้องออกจากเวิร์กโฟลว์ และจากนั้นก็นำไปแจกจ่ายเป็น plugin ก่อน rollout ทั่วทั้งองค์กร

  • การผสานรวม Language Server Protocol

    • การผสานรวม Language Server Protocol (LSP) ทำให้ Claude มี ความสามารถในการสำรวจโค้ด แบบเดียวกับ IDE ของนักพัฒนา
    • IDE ส่วนใหญ่สำหรับโค้ดเบสขนาดใหญ่มี LSP ที่ใช้ขับเคลื่อน “go to definition” และ “find all references” อยู่แล้ว
    • เมื่อนำสิ่งนี้มาเปิดให้ Claude ใช้ ก็จะได้ ความแม่นยำระดับ symbol ที่ช่วยให้ติดตามการเรียกฟังก์ชันไปยังนิยาม ติดตาม reference ข้ามไฟล์ และแยกฟังก์ชันชื่อเดียวกันในคนละภาษาได้
    • หากไม่มี LSP, Claude จะต้องพึ่งการจับคู่แพตเทิร์นข้อความ ซึ่งอาจพาไปยัง symbol ที่ไม่ถูกต้อง
    • บริษัทซอฟต์แวร์ระดับองค์กรแห่งหนึ่งได้แจกจ่ายการผสานรวม LSP ทั่วทั้งองค์กรก่อน rollout Claude Code เพื่อให้การสำรวจ C และ C++ มีเสถียรภาพในสภาพแวดล้อมขนาดใหญ่
    • สำหรับโค้ดเบสหลายภาษา นี่เป็นหนึ่งในการลงทุนที่คุ้มค่าที่สุด

  • เซิร์ฟเวอร์ MCP

    • เซิร์ฟเวอร์ MCP คือวิธีที่ Claude ใช้เชื่อมกับ เครื่องมือภายใน แหล่งข้อมูล และ API ที่เข้าถึงโดยตรงไม่ได้
    • ทีมที่มีความพร้อมสูงสุดจะสร้างเซิร์ฟเวอร์ MCP เพื่อเปิดการค้นหาแบบมีโครงสร้างให้เป็นเครื่องมือที่ Claude เรียกใช้ได้โดยตรง
    • อีกหลายทีมใช้วิธีเชื่อม Claude เข้ากับเอกสารภายใน ระบบ ticket และแพลตฟอร์มวิเคราะห์

  • Subagents

    • Subagents แยกงานสำรวจออกจากงานแก้ไข
    • subagent คืออินสแตนซ์ Claude แบบแยกตัวที่มี context window ของตัวเอง รับงานไปทำ แล้วส่งกลับมาเฉพาะผลลัพธ์สุดท้ายให้ parent
    • หลังจากมี harness พร้อมแล้ว บางทีมจะเปิดใช้ subagent แบบอ่านอย่างเดียวเพื่อทำแผนที่ subsystem และเขียนผลลัพธ์ลงไฟล์ จากนั้นให้เอเจนต์หลักแก้ไขโดยอิงจากภาพรวมทั้งหมด

  • บทบาทของแต่ละองค์ประกอบและความสับสนที่พบบ่อย

    • CLAUDE.md: ไฟล์บริบทที่ Claude อ่านอัตโนมัติและถูกโหลดในทุกเซสชัน เหมาะกับกฎเฉพาะโปรเจ็กต์และความรู้เกี่ยวกับโค้ดเบส แต่ก็มักถูกใช้ใส่ความเชี่ยวชาญที่ควรอยู่ใน skill
    • Hooks: สคริปต์ที่ทำงานในช่วงเวลาสำคัญและถูก trigger จาก event เหมาะกับการทำงานอัตโนมัติให้คงเส้นคงวาและเก็บบทเรียนจากเซสชัน แต่มักถูกแทนที่ด้วย prompt ทั้งที่ควรรันอัตโนมัติ
    • Skills: ชุดคำสั่งแบบแพ็กเกจสำหรับงานเฉพาะประเภท โหลดแบบ on-demand เมื่อเกี่ยวข้อง เหมาะกับความเชี่ยวชาญที่ใช้ซ้ำข้ามหลายเซสชันและหลายโปรเจ็กต์ แต่มักถูกยัดรวมไว้ใน CLAUDE.md ทั้งหมด
    • Plugins: ชุดรวมของ skills, hooks และการตั้งค่า MCP ที่พร้อมใช้เสมอหลังตั้งค่า เหมาะกับการกระจายการตั้งค่าที่ใช้ได้ผลไปทั้งองค์กร แต่มักปล่อยให้การตั้งค่าที่ดีค้างอยู่เป็นความรู้เฉพาะคน
    • LSP: ระบบ code intelligence แบบเรียลไทม์ผ่านเซิร์ฟเวอร์เฉพาะภาษา พร้อมใช้เสมอหลังตั้งค่า เหมาะกับการสำรวจระดับ symbol ในภาษาแบบมี type และการตรวจจับข้อผิดพลาดอัตโนมัติ แต่มักถูกเข้าใจผิดว่ามันทำงานให้อัตโนมัติอยู่แล้ว
    • เซิร์ฟเวอร์ MCP: การเชื่อมต่อกับเครื่องมือและข้อมูลภายนอก พร้อมใช้เสมอหลังตั้งค่า เหมาะกับการเข้าถึงเครื่องมือภายในที่ Claude เข้าถึงตรงๆ ไม่ได้ แต่มักมีคนเริ่มจากการเชื่อม MCP ก่อนที่พื้นฐานจะพร้อม
    • Subagents: อินสแตนซ์ Claude แยกสำหรับงานเฉพาะ รันเมื่อถูกเรียกใช้ เหมาะกับการแยกงานสำรวจออกจากงานแก้ไขและงานขนาน แต่มักมีการพยายามทำทั้งสำรวจและแก้ไขในเซสชันเดียวกัน
    • LSP เข้าถึงผ่านชั้น plugin ส่วน subagents ไม่ใช่จุดขยายที่ต้องตั้งค่า แต่เป็นความสามารถด้านการมอบหมายงาน

รูปแบบการตั้งค่า 3 แบบที่พบซ้ำใน deployment ที่ประสบความสำเร็จ

  • ทำให้โค้ดเบสขนาดใหญ่ยังสำรวจได้

    • ขอบเขตที่ Claude จะช่วยได้ในโค้ดเบสขนาดใหญ่ถูกจำกัดด้วย ความสามารถในการหาบริบทที่ถูกต้อง
    • ถ้าโหลดบริบทมากเกินไปในทุกเซสชัน ประสิทธิภาพจะลดลง แต่ถ้าน้อยเกินไป Claude ก็จะสำรวจแบบมองไม่เห็นภาพ
    • deployment ที่ได้ผลจะลงทุนตั้งแต่ต้นเพื่อทำให้โค้ดเบสอ่านง่ายสำหรับ Claude

    • ทำให้ไฟล์ CLAUDE.md บางและเป็นลำดับชั้น

      • Claude จะ โหลดเพิ่มแบบสะสม เมื่อเคลื่อนผ่านโค้ดเบสและพบไฟล์ CLAUDE.md
      • ไฟล์ที่ root ดูแลภาพรวม ส่วนไฟล์ในไดเรกทอรีย่อยดูแลกฎเฉพาะพื้นที่
      • ไฟล์ root ควรมีเพียงตัวชี้และข้อควรระวังสำคัญเท่านั้น เพราะนอกเหนือจากนั้นมักกลายเป็นสัญญาณรบกวน

    • เริ่มจากไดเรกทอรีย่อย ไม่ใช่ root ของรีโพซิทอรี

      • Claude ทำงานได้ดีที่สุดเมื่อขอบเขตถูกจำกัดไว้ที่ส่วนของโค้ดเบสที่เกี่ยวข้องกับงานจริง
      • ใน monorepo เรื่องนี้อาจขัดกับสัญชาตญาณ เพราะหลายเครื่องมือมักสมมติว่าต้องเริ่มจาก root
      • Claude จะไต่ขึ้นตามต้นไม้ไดเรกทอรีโดยอัตโนมัติและโหลดไฟล์ CLAUDE.md ทุกไฟล์ที่พบ ดังนั้นบริบทระดับ root จะไม่หายไป

    • กำหนดขอบเขตคำสั่ง test และ lint ตามไดเรกทอรีย่อย

      • ถ้า Claude เปลี่ยนแค่ service เดียวแต่ไปสั่งรัน test suite ทั้งหมด ก็จะ timeout และเสียบริบทไปกับ output ที่ไม่เกี่ยวข้อง
      • ไฟล์ CLAUDE.md ในไดเรกทอรีย่อยควรระบุคำสั่งที่ใช้กับส่วนนั้นของโค้ดเบสโดยเฉพาะ
      • วิธีนี้ใช้ได้ดีในโค้ดเบสแบบ service-oriented ที่แต่ละไดเรกทอรีมีคำสั่ง test และ build ของตัวเอง
      • แต่ใน monorepo ของภาษาแบบคอมไพล์ที่มี dependency ข้ามไดเรกทอรีลึกๆ การกำหนดขอบเขตแบบนี้จะยากกว่าและอาจต้องมีการตั้งค่า build รายโปรเจ็กต์

    • ใช้ไฟล์ .ignore เพื่อตัดไฟล์ที่สร้างอัตโนมัติ, build output และโค้ดของ third-party ออก

      • ถ้า commit กฎ permissions.deny ลงใน .claude/settings.json กฎการยกเว้นจะถูก เก็บไว้ในระบบควบคุมเวอร์ชัน
      • นักพัฒนาทุกคนในทีมจะได้ผลในการลดสัญญาณรบกวนแบบเดียวกันโดยไม่ต้องตั้งค่าแยก
      • ในบางโค้ดเบส ไฟล์ที่สร้างอัตโนมัติเองก็อาจเป็นเป้าหมายของการพัฒนา
      • นักพัฒนาที่ทำงานกับ code generator สามารถ override กฎยกเว้นระดับโปรเจ็กต์ใน local settings ของตัวเองได้โดยไม่กระทบทีมที่เหลือ

    • สร้างแผนที่โค้ดเบสถ้าโครงสร้างไดเรกทอรีไม่เพียงพอ

      • ในองค์กรที่โค้ดไม่ได้ถูกรวมไว้ในโครงสร้างไดเรกทอรีแบบทั่วไป ไฟล์ Markdown แบบเบาที่ root จะช่วยได้
      • การเขียนคำอธิบายหนึ่งบรรทัดสำหรับแต่ละโฟลเดอร์ระดับบนสุดและสิ่งที่อยู่ข้างใน จะกลายเป็น สารบัญ ที่ Claude ใช้ไล่ดูก่อนเปิดไฟล์
      • ถ้ามีโฟลเดอร์ระดับบนสุดเป็นร้อย ไฟล์ root ควรอธิบายเฉพาะโครงสร้างระดับสูงสุด และให้ CLAUDE.md ของไดเรกทอรีย่อยค่อยให้รายละเอียดระดับถัดไปแบบ on-demand ซึ่งเป็นแนวทางแบบลำดับชั้นที่ได้ผลที่สุด
      • ในกรณีที่ง่ายกว่า การ mention ไฟล์หรือไดเรกทอรีที่ Claude ควรอ้างอิงด้วย @ ก็ทำหน้าที่เดียวกันได้

    • ใช้เซิร์ฟเวอร์ LSP เพื่อค้นหาตาม symbol ไม่ใช่สตริง

      • ถ้า grep ชื่อฟังก์ชันที่พบบ่อยในโค้ดเบสขนาดใหญ่ อาจได้ผลลัพธ์นับพันรายการ และ Claude จะเสียบริบทไปกับการเปิดไฟล์เพื่อแยกว่าอะไรสำคัญ
      • LSP จะคืนเฉพาะ reference ที่ชี้ไปยัง symbol เดียวกัน จึงมีการกรองตั้งแต่ก่อนที่ Claude จะเริ่มอ่านอะไร
      • ในการตั้งค่า ต้องติดตั้ง code intelligence plugin สำหรับภาษานั้น และติดตั้งไบนารีของ language server ที่เกี่ยวข้อง
      • เอกสารของ Claude Code มีทั้ง plugin ที่ใช้ได้และวิธีแก้ปัญหา

    • ข้อยกเว้น

      • แม้แต่แนวทาง CLAUDE.md แบบลำดับชั้นก็ยังมี edge case ที่ใช้ไม่ได้
      • เช่น โค้ดเบสที่มีหลายแสนโฟลเดอร์และหลายล้านไฟล์ หรือระบบ legacy ที่อยู่บนระบบควบคุมเวอร์ชันที่ไม่ใช่ Git

  • ดูแลไฟล์ CLAUDE.md ตามการเปลี่ยนแปลงของความฉลาดของโมเดล

    • เมื่อโมเดลพัฒนา คำสั่งที่เขียนไว้สำหรับโมเดลปัจจุบันอาจกลายเป็นอุปสรรคต่อโมเดลในอนาคต
    • กฎใน CLAUDE.md ที่เคยช่วยชี้นำรูปแบบซึ่ง Claude เคยทำได้ยาก อาจไม่จำเป็นอีกต่อไป หรือกลับกลายเป็น ข้อจำกัด สำหรับโมเดลรุ่นใหม่
    • ตัวอย่างเช่น กฎที่บังคับให้แยกทุกการ refactor ออกเป็นการเปลี่ยนแปลงไฟล์เดียว อาจเคยช่วยโมเดลเก่ารักษาลำดับงานได้ แต่กลับขัดขวางการแก้ไขหลายไฟล์ที่ประสานกันได้ดีในโมเดลใหม่
    • Skills และ hooks ที่สร้างขึ้นเพื่อชดเชยข้อจำกัดเฉพาะของการให้เหตุผลของโมเดลหรือเครื่องมือ Claude Code จะกลายเป็น overhead หากข้อจำกัดนั้นหายไปแล้ว
    • Hook ที่ดักการเขียนไฟล์เพื่อบังคับ p4 edit ในโค้ดเบส Perforce จะซ้ำซ้อนทันทีเมื่อ Claude Code เพิ่มโหมด Perforce แบบเนทีฟ
    • ทีมควรคาดว่าจะต้องทบทวนการตั้งค่าอย่างจริงจังทุก 3–6 เดือน
    • หลังการออกรุ่นโมเดลใหญ่ๆ หากรู้สึกว่าประสิทธิภาพนิ่งหรือไม่ดีขึ้น ก็เป็นช่วงที่ควรทบทวนการตั้งค่าเช่นกัน

  • กำหนดเจ้าของการดูแลและการนำ Claude Code ไปใช้

    • การนำไปใช้จะไม่เกิดขึ้นจากการตั้งค่าทางเทคนิคเพียงอย่างเดียว
    • rollout ที่กระจายได้เร็วที่สุดล้วนมี การลงทุนด้านโครงสร้างพื้นฐาน ก่อนเปิดให้เข้าถึงวงกว้าง
    • ทีมเล็กๆ บางครั้งมีเพียงคนเดียว เป็นผู้เชื่อมเครื่องมือต่างๆ เข้าด้วยกัน เพื่อให้นักพัฒนาที่ได้ลอง Claude ครั้งแรกพบว่ามันทำงานเข้ากับเวิร์กโฟลว์ของตนได้ทันที
    • ที่บริษัทหนึ่ง วิศวกรไม่กี่คนสร้างชุด plugin และ MCP ที่พร้อมใช้ได้ตั้งแต่วันแรก
    • อีกบริษัทหนึ่งมีทีมที่ดูแลเครื่องมือ AI coding โดยเฉพาะและเตรียมโครงสร้างพื้นฐานก่อน rollout
    • งานลักษณะนี้มักอยู่ภายใต้องค์กรด้าน developer experience หรือ developer productivity ที่ดูแลการ onboard วิศวกรใหม่และการสร้างเครื่องมือสำหรับนักพัฒนา
    • ในหลายองค์กรเริ่มมีบทบาท agent manager ซึ่งเป็นงานลูกผสมระหว่าง PM กับวิศวกร สำหรับดูแล ecosystem ของ Claude Code
    • หากยังไม่มีทีมเฉพาะ รูปแบบขั้นต่ำที่ใช้งานได้คือมี DRI อย่างน้อยหนึ่งคน
    • DRI คนนี้ควรเป็นเจ้าของการตั้งค่า Claude Code, การตัดสินใจด้านการตั้งค่า, นโยบายสิทธิ์, plugin marketplace และกฎของ CLAUDE.md รวมถึงรับผิดชอบการทำให้สิ่งเหล่านี้ทันสมัยอยู่เสมอ
    • การนำไปใช้แบบล่างขึ้นบนช่วยสร้างแรงกระตือรือร้นได้ แต่ถ้าไม่มีคนรวมศูนย์สิ่งที่ได้ผล ก็อาจแตกกระจายเป็นส่วนๆ
    • จึงต้องมีบุคคลหรือทีมที่คอยรวบรวมและเผยแพร่แนวปฏิบัติของ Claude Code เช่น ลำดับชั้น CLAUDE.md แบบมาตรฐาน หรือชุด skills และ plugins ที่คัดสรรแล้ว
    • หากไม่มีงานส่วนนี้ ความรู้จะยังคงกระจัดกระจายอยู่กับแต่ละคน และการนำไปใช้จะชะงักงัน

Governance และ rollout

  • ในองค์กรขนาดใหญ่ โดยเฉพาะอุตสาหกรรมที่มีข้อกำกับดูแล คำถามด้าน governance จะเกิดขึ้นตั้งแต่ระยะแรก
  • ประเด็นสำคัญคือใครควบคุมได้ว่าใช้ skills และ plugins อะไรได้บ้าง จะป้องกันไม่ให้วิศวกรหลายพันคนสร้างของเดียวกันซ้ำอย่างอิสระได้อย่างไร และจะทำอย่างไรให้โค้ดที่ AI สร้างต้องผ่านกระบวนการ review แบบเดียวกับโค้ดที่มนุษย์เขียน
  • ในช่วงแรก แนะนำให้เริ่มจากชุด skills ที่ผ่านการอนุมัติอย่างชัดเจน ขั้นตอน code review ที่บังคับใช้ และการเข้าถึงแบบจำกัด แล้วค่อยขยายเมื่อความเชื่อมั่นเพิ่มขึ้น
  • การ deploy ที่ราบรื่นที่สุดมักเกิดในองค์กรที่ตั้ง คณะทำงานข้ามสายงาน ตั้งแต่ต้น โดยมีตัวแทนจากวิศวกรรม ความปลอดภัยสารสนเทศ และ governance มาร่วมกันกำหนดข้อกำหนดและ roadmap ของ rollout

สมมติฐานและข้อจำกัดเมื่อนำไปใช้ในองค์กร

  • Claude Code ถูกออกแบบมาโดยมี สภาพแวดล้อมวิศวกรรมซอฟต์แวร์แบบดั้งเดิม เป็นศูนย์กลาง ซึ่งหมายถึงวิศวกรเป็นผู้มีส่วนร่วมหลักในโค้ดเบส รีโพซิทอรีใช้ Git และโค้ดจัดตามโครงสร้างไดเรกทอรีมาตรฐาน
  • โค้ดเบสขนาดใหญ่ส่วนใหญ่เข้ากับกรอบนี้ แต่ game engine ที่มี asset ไบนารีขนาดใหญ่ สภาพแวดล้อมควบคุมเวอร์ชันที่ไม่เป็นแบบดั้งเดิม หรือสภาพแวดล้อมที่ผู้ไม่ใช่วิศวกรมีส่วนร่วมในโค้ดเบส จะต้องมีงานตั้งค่าเพิ่มเติม
  • รูปแบบที่เสนอมาอิงกับการตั้งค่าแบบดั้งเดิมและใช้งานได้จริงในหลายสภาพแวดล้อมของลูกค้า
  • ความซับซ้อนที่เหลือต้องอาศัยการตัดสินใจให้เหมาะกับโค้ดเบส เครื่องมือ และโครงสร้างองค์กรของแต่ละแห่ง
  • ทีม Applied AI ของ Anthropic ทำงานร่วมกับทีมวิศวกรรมโดยตรงเพื่อแปลงรูปแบบเหล่านี้ไปเป็นข้อกำหนดเฉพาะของแต่ละองค์กร

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

1 ความคิดเห็น

 
GN⁺ 2 시간 전
ความคิดเห็นจาก Hacker News

  • ดูเหมือนว่าสำนวนที่ว่าไปสำรวจโค้ดเบส “เหมือนวิศวกรซอฟต์แวร์” กับข้อสรุปจะขัดกันเอง
    การเติมโค้ดอัตโนมัติหรือ LSP ก็ใช้อยู่ตลอดและมีประโยชน์ ซึ่งนั่นก็เป็นรูปแบบหนึ่งของ ดัชนี ไม่ใช่หรือ? ก็เลยสงสัยว่าทำไม Claude ถึงใช้สิ่งนั้นไม่ได้
    วิศวกรซอฟต์แวร์ยังจำโค้ดเบสได้ด้วย ซึ่งจริง ๆ ก็ใกล้เคียงกับ RAG และยังมีความเคยชินจากการกด CMD+P เพื่อหาไฟล์ที่ต้องใช้ด้วย
    ไม่จำเป็นต้องเป็นแบบเรียลไทม์สำหรับทั้งโค้ดเบสที่มีวิศวกรหลายพันคนแก้พร้อมกัน แค่ดู branch ที่ฉันทำงานอยู่ให้ดีก็พอ
    การไล่เดินระบบไฟล์ตั้งแต่ต้นเพื่อสำรวจโค้ดเบสเกิดขึ้นไม่บ่อย ปกติก็มีแค่ตอนเจอโค้ดเบสใหม่ ๆ และถึงอย่างนั้นก็ยังเรียกว่าเป็นประสบการณ์ที่ดีที่สุดได้ยาก

    • นี่ตรงกับวิธีทำงานของฉันเป๊ะ
      ฉันเรียนรู้วิธีสำรวจโค้ดเบสขนาดใหญ่ตั้งแต่ยุคก่อนมี LSP และใช้ vim มานานโดยหาไฟล์ที่เกี่ยวข้องด้วย grep
      ตอนลองใช้ Claude Code ครั้งแรกเมื่อปีที่แล้ว ความรู้สึกคือ “อะไรเนี่ย มันทำแบบเดียวกับที่ฉันกำลังจะทำเลย”
    • คำตอบอยู่ในบทนำของบทความ
      Claude Code ตั้งสมมติฐานว่ากำลังทำงานกับ monorepo หลายล้านบรรทัด ระบบ legacy ที่มีมาหลายสิบปี และสถาปัตยกรรมแบบกระจายที่คร่อมหลายสิบ repository
      เพราะอย่างนั้นมันจึงถูกปรับให้เหมาะกับ กรณีทั่วไป ที่ใช้เครื่องมือทนทานซึ่งทำงานได้ทุกที่ โดยเฉพาะในโค้ดเบสขนาดใหญ่และยุ่งเหยิง
      แต่ก็จริงเหมือนกันว่าถ้าเป็น repository เล็ก ๆ ที่จัดระเบียบดีแล้ว ก็ควรใช้และมีเครื่องมือที่ดีกว่านี้
      อย่างน้อย Codex ก็ทำงานแบบนั้น และเช่นจะใช้ go doc ก่อนค่อย grep
    • ในโค้ดเบสที่ใหญ่จริง ๆ grep กับ find จะ timeout
      ถ้าทำงานในสเกลนั้นจะสังเกตได้เร็วว่า Claude ไม่ได้ใช้เครื่องมือที่เตรียมไว้เพื่อให้ค้นหาได้
    • ในย่อหน้าสั้น ๆ มีถ้อยคำที่ฟังดูดีหลายอย่าง แต่จริง ๆ แล้วดูเหมือนเป็นคำกล่าวที่ปนความหวัง
      คำว่า “เหมือนวิศวกรซอฟต์แวร์” ถูกแค่บางส่วน
      คนก็ใช้การค้นหา symbol เหมือนกัน แต่จะค้นหาจาก symbol ที่จำได้ในบริบทของงานเฉพาะ
      วิธีที่ Claude Code ค้นหา symbol แบบกวาดทั่ว ตอนนี้ไม่เหมือนวิธีทำงานของวิศวกร
      แค่พิมพ์ผิดตัวเดียวเอเจนต์ก็อาจสรุปว่าต้องไปเขียนอะไรใหม่ และถึงจะโชคดีได้อ่านไฟล์ก็ยังหลอนได้ง่าย
      มันไม่ใช่วิธีทำงานกับโค้ดเบสขนาดใหญ่ด้วย
      ส่วนที่ว่า “ใช้ grep เพื่อหาให้ตรงกับที่ต้องการ” นี่ติดใจมากเป็นพิเศษ
      จะ grep ก็ต้องรู้ก่อนว่าจะ grep อะไร และถ้าผลลัพธ์ออกมาหลายพันรายการก็ต้องตรวจทั้งหมด
      ถ้าได้ผลแบบนั้น คนจะคิดหาวิธีทำให้ผลลัพธ์แคบลง ไม่ใช่ไล่ดูแบบทื่อ ๆ
      แนวทางในบทความนี้จึงคล้ายคำอธิบายเพื่อทำให้วิธีปัจจุบันดูสมเหตุสมผล มากกว่าจะเป็นคำแนะนำที่แข็งแรง
      คำว่า “ไม่จำเป็นต้องมีการทำดัชนีโค้ดเบส” ก็อาจจริง แต่ก็แค่หมายถึงสุดท้ายแล้วใช้ grep-read-grep ขยายบริบทไปเรื่อย ๆ จนวันหนึ่งเจอคำตอบ
      มันฟังคล้ายกับการบอกว่า “นักพัฒนาทำเองได้โดยไม่ต้องมี Claude Code เพราะงั้น Claude Code ก็ไม่จำเป็น”
      ผมคิดว่าข้อความ “ไม่จำเป็น” แบบนี้ผิด เพราะมันสื่อกับชุมชนราวกับเป็นสัจพจน์ของการตัดสินใจ
      โดยรวมแล้วบทความนี้ซื่อตรงเรื่องต้นทุนระดับองค์กร
      หลายองค์กรเริ่มมีบทบาท “agent manager” ซึ่งเป็นส่วนผสมระหว่าง PM กับวิศวกร เพื่อดูแล ecosystem ของ Claude Code และบอกว่าทีมควรทบทวนการตั้งค่าอย่างมีนัยสำคัญทุก 3–6 เดือน
      นี่สะท้อนความจริงของการใช้ Claude Code ขนาดใหญ่ โดยไม่มีชั้น code intelligence ที่สร้างไว้ล่วงหน้าได้อย่างแม่นยำ
      ทิศทางอาจตั้งมาไม่ผิด แต่พออ่านจบจะเหลือความรู้สึกว่า “เราแก้ปัญหานี้ไม่ได้ และนี่คือขีดจำกัดของเรา”
    • ต่อให้กำลังสำรวจบางส่วนของโค้ดเบสตั้งแต่ต้น ก็ยังมีส่วนที่แทบไม่เปลี่ยนเลย และการสำรวจใหม่ทุกครั้งก็ เปลืองโทเค็น มาก
      จุดที่ฉันเถียงกับ Claude บ่อยมากก็คือการทำให้มันสำรวจน้อยลงมาก ๆ
      ฉันรู้จักสิ่งที่แทบไม่เปลี่ยนพวกนั้นดีกว่าและเร็วกว่าการให้มันไล่ดูแบบช้าและแพง
      แต่สุดท้ายมันก็ลงรูเดิม ๆ ทุกครั้ง

  • มีเกร็ดหนึ่งคือฉันกำลังออกแบบโปรเจ็กต์สำหรับ LLM onboarding และ orchestration แล้ว Claude เลือกอ่านแค่ 40 บรรทัดแรกของแต่ละไฟล์
    ต่อมาในอีก session หนึ่ง Claude ที่กำลังหาสาเหตุของคุณภาพต่ำก็เจอข้อบกพร่องนั้น และแก้โค้ดให้ทำ การวิเคราะห์ AST โดยใช้บรรทัดเอกสารและ input/output ของ function signature เป็นอินพุต
    แนวทางเริ่มต้นของ Claude แย่มากจริง ๆ
    เลยสงสัยว่า Claude Code ต้องถูกแก้และรีวิวอีกมากแค่ไหนถึงจะดีขึ้น หรือจริง ๆ แล้วมันจะสร้างโค้ดที่ดีได้ตั้งแต่แรกหรือไม่
    ถ้าสรุปให้ทั่วไป Claude สามารถแก้การตัดสินใจแย่ ๆ ที่เป็นจุดเฉพาะและระบุได้ เช่น “อ่านแค่ 40 บรรทัดแรก”
    เพราะข้อบกพร่องถูกแยกได้และตามย้อนกลับไปยังโค้ดชิ้นเดียวได้
    แต่ปัญหาคุณภาพซอฟต์แวร์จริง ๆ มักเกิดจากการตัดสินใจเล็ก ๆ หลายอย่างที่แต่ละอย่างดูสมเหตุสมผล แต่รวมกันแล้วให้ผลลัพธ์แย่
    พอเป็นแบบนั้นก็ไม่มีข้อไหนที่เป็น “ข้อบกพร่อง” ชัด ๆ ดังนั้นเครื่องมือที่สร้างองค์ประกอบคุณภาพต่ำทีละชิ้น อาจไม่มีทางลู่เข้าไปสู่โค้ดที่ดีได้ เพราะแต่ละชิ้นเมื่อดูแยกกันแล้วก็เหมือนจะใช้ได้

    • ดูเหมือนมันถูกฝึกมาให้ ส่องซอร์สโค้ดผ่านรูแคบ ๆ เพื่อรักษาบริบท
      ในกรณีแบบนี้อาจเหมาะกับการใช้ตรรกะย่อยหรือ sub-agent แบบเต็มตัว
      เช่น มอบหมายให้ sub-agent ว่า “ช่วยไล่ดูไฟล์นี้แล้วสรุปให้หน่อย พร้อมทำเครื่องหมายส่วนที่เกี่ยวกับ X และ Y เดี๋ยวฉันดูต่อในบริบทหลักเอง”
      หรืออาจให้มันคอยเฝ้าดู workflow หลักเป็นระยะ แล้วถ้าตัดสินได้ว่ามีบางอย่างในไฟล์ที่กำลังคิดอยู่เกี่ยวข้องกับงานปัจจุบันหรืออาจเปลี่ยนทิศทางได้ ก็ให้แทรกเข้ามา

  • ถามว่า Claude Code ทำงานกับโค้ดเบสใหญ่ ๆ ยังไง? ง่ายมาก
    ต่อให้เป็นโปรเจ็กต์เล็ก มันก็ซัดไปถึง 35% ของลิมิตใช้งาน 5 ชั่วโมง ตั้งแต่ prompt แรก และถ้าไม่ตอบเร็วภายใน 5 นาที cache ก็หาย ทำให้ prompt ถัดไปต้องจ่ายอีก 12–15%

    • บทความที่ลิงก์ไว้กำลังอธิบายวิธีเลี่ยงเรื่องนี้
      ถ้าปล่อยให้มันลุยโค้ดเบสใหญ่แบบไร้เดียงสา มันก็เผาโทเค็นหนักระหว่างหาข้อมูลจริง

  • Claude Code ไม่น่าจะตรวจโค้ดเบสแล้วสร้าง harness ที่มีประสิทธิภาพให้อัตโนมัติได้หรือ?
    ฉันลองกำหนด CLAUDE.md, AGENTS.md, skills, plugin แล้ว แต่ก็ยังไม่ได้ผลเท่าที่คนอื่นพูดกัน
    เช่น ต่อให้มี LSP plugin Claude Code ก็ไม่ใช้การ rename symbol ของ LSP แต่กลับค่อย ๆ แก้ไฟล์ทีละไฟล์ หรือแม้จะระบุใน prompt ว่าถ้ามีเงื่อนงำบางอย่างให้เรียกใช้ skill ก็ยังไม่เรียก
    ฉันใช้งานผิดหรือเปล่า? อยากรู้ว่ามีตัวอย่าง harness ที่แข็งแรงพอให้ก็อปไปใช้ได้ไหม

    • นี่เป็น จุดเจ็บปวด ที่ลากมาหลายปีและยังไม่ถูกแก้เลยแม้แต่น้อย
      ต่อให้บอกว่า “ถ้า A ให้ทำ X ทำ B, C, D แล้วทำ A” มันก็ยังไม่ใช้ X อยู่ดี
      เพราะมัน “ลืม”
      เราเชื่อไม่ได้ว่าเวลาที่ใช้ไปกับการสร้างกฎจะได้ผลตอบแทนจริง ๆ แต่กลับเชื่อได้ว่ามันจะล้มเหลวเข้าสักวัน
      ทั้ง RAG, harness และ skills ต่างก็เคยบอกว่าจะมาแก้เรื่องนี้ แต่ในโลกจริงก็ยังแก้ไม่ได้
    • ฉันเลิกใช้ /init และเลิกทำไฟล์ CLAUDE.md หรือ AGENTS.md ที่อธิบายโค้ดเบสแล้ว
      สิ่งที่เหลือไว้มีแค่วิธีสำรวจโค้ดเบสกับการบอกให้ใช้ git log เวลาสืบค้น ซึ่งก็น่าจะซ้ำซ้อนอยู่ดี
      ฉันเองก็ไม่รู้คำตอบ
      โค้ดเบสที่ทำอยู่มีประมาณ 100,000 บรรทัด ไม่แน่ใจว่านับว่าใหญ่ไหม แต่สำหรับฉันมันคือ repository ที่ใหญ่ที่สุดเท่าที่เคยทำงานมา
    • ในบางกรณี การใช้ hooks ที่ผูกสคริปต์ไว้และยัดข้อมูลเข้า context window ดูจะได้ผล
      เพื่อจำกัดบริบท ฉันต้องตัดข้อความ linter ที่ไม่จำเป็นออกบางส่วน
      linter หรือเครื่องมือตรวจสอบตามภาษาที่ติดตั้งผ่าน repository ของแพ็กเกจระบบปฏิบัติการและเรียกจากสคริปต์ได้ก็ช่วยได้เหมือนกัน
      การผสมกันของโมเดลกับบริบทของ skill ก็สร้างความต่างได้
      skill ที่ “ใช้ได้” ใน 4.6 อาจไม่เข้ากับ 4.7 มากนัก โดย 4.7 ต้องการคำสั่งที่ชัดเจนกว่า แต่ค่อนข้างเสถียรกว่า 4.6
      การอัปเดต skill ก็อาจช่วยได้ และควรเปรียบเทียบการทดสอบกับการรันก่อนและหลัง
      Claude Code ยังใส่การเรียกเครื่องมือที่ไม่จำเป็นเข้า context ด้วย ดังนั้นถ้าคุณชอบ beads เป็นต้น ก็อาจต้องกดไม่ให้มันทำงาน

  • ไม่เห็นด้วยกับคำกล่าวเรื่องการทำดัชนีโค้ดเบส
    ใน PHPStorm หรือ IDE อื่นของ JetBrains การทำดัชนี ทำงานได้ดีพอสมควร

    • ดัชนีของ PHPStorm ยอดเยี่ยมมาก
      แทบไม่เคยพังเลย และถึงจะพังก็ซ่อมง่าย ฉันก็ไม่เคยได้ผลลัพธ์เก่าค้าง
      ถ้าคุณเคยใช้เครื่องมือค้นหาของ Claude คุณจะไม่แปลกใจเลยที่ทีมนี้ไม่รู้อะไรเกี่ยวกับการทำดัชนี
      มันน่าไม่เข้าใจที่บริษัทซึ่งสินค้าหลักเป็นแชตแบบข้อความ กลับทำให้ผู้ใช้ค้นหาข้อความในแชตนั้นได้ไม่สะดวก
    • Claude Code ใช้ MCP ของ JetBrains เพื่อใช้ดัชนีนั้นได้
    • เป็นคำกล่าวที่แปลกมาก
      หรือว่านี่คือบทความขยะจาก AI? GitHub Copilot ก็มี local index ที่ดีพอสมควร
      การเอาโค้ดเข้า vector database ไม่ใช่ปัญหาที่ยากขนาดนั้น

  • บทความนี้ชัดเจนเลยว่า Claude เขียน
    มีแต่ คำฟุ่มเฟือย และแทบไม่มีเนื้อหาจริง

  • แปลกดีที่บอกว่ารวมถึงภาษาอย่าง C, C++, C#, Java, PHP ซึ่งทีมต่าง ๆ ไม่ได้เชื่อมโยงกับเครื่องมือเขียนโค้ดด้วย AI อยู่ตลอด
    ทำไมถึงคาดว่า Claude Code จะทำงานกับภาษาเหล่านั้นได้ไม่ดี? แล้วควรให้นึกถึงภาษาอะไร Python กับ JavaScript เหรอ?

  • ในอุตสาหกรรมที่เปลี่ยนกันเป็นรายเดือน ไม่ใช่รายสัปดาห์ น่าสนใจที่บอกว่ามีเวลาพอให้เห็นรูปแบบชัดเจนแล้ว และรูปแบบนั้นประสบความสำเร็จกับโค้ดเบสขนาดใหญ่
    เกณฑ์วัดความสำเร็จ คืออะไร? แค่ไม่ลบฐานข้อมูล production? ทีมทำงานเร็วขึ้น? อายุโค้ดเบสยืนยาวขึ้น? หรือทีมปฏิบัติการมีความสุขมากขึ้น?

    • ถ้าฐานข้อมูล production หายเพราะเครื่องมือ AI ก็อยากย้ำอีกครั้งว่านั่นคือความล้มเหลวของตัวนักพัฒนาเองและขององค์กรที่ให้ สิทธิ์ production ระดับลบทรัพยากรได้
      ฉันไม่เคยทำงานในบริษัทที่ให้สิทธิ์เข้าถึงแบบไร้ขีดจำกัดระดับนั้น

  • ทุกวันนี้ความเครียดของฉันมาจากการที่ Claude Code ไม่ทำตามคำสั่งทั้งหมด และยิ่งโค้ดเบสใหญ่ก็ยิ่งแย่
    ไม่อยากให้เข้าใจผิดนะ Claude น่าทึ่งและฉันชอบมันมาก
    แต่ไม่มีทางเลยที่จะจ้างแค่ Claude Code มาดูแลโค้ดเบสหรือเพิ่มฟีเจอร์ให้ได้
    ฉันคอยเพิ่มรายการความจำเกี่ยวกับความผิดพลาดในอดีตอยู่เรื่อย ๆ แต่ปัญหาการเมินคำสั่งสำคัญก็ยังเกิดขึ้นราว 90% อยู่ดี
    วิธีเดียวที่จะหลีกเลี่ยงได้คือเฝ้ามันทุกงานแบบใกล้ชิดและรีวิวผลลัพธ์อย่างหนัก
    Claude Code ยอดเยี่ยมสำหรับงานเอกสารและการทำความเข้าใจโค้ดเบสใหญ่ ๆ แต่ไม่เก่งกับงานแก้ไขที่ต้องเข้าใจภาพรวมทั้งหมด
    ตัวอย่างเช่น ในโค้ดเบสมี registry pattern อยู่ราว 10 แบบที่ใช้กับหลายเอนทิตีทั่วทั้งระบบ และแม้จะมีกฎชัดเจนว่า “ให้ใช้ registry pattern ตัวนี้ตัวเดียว” แต่ Claude Code ก็ยังไปสร้าง registry แยกอิสระตามเอนทิตี 4 ตัว
    ฉันต้องแทบตะโกนใส่ Claude Code อยู่ครึ่งวันเพื่อให้มันทำงานง่าย ๆ นี้ให้ถูก สุดท้ายก็แก้เองเพื่อประหยัดเวลาและความเครียด

  • เขาไม่ได้อธิบายด้วยซ้ำว่าแต่ละไฟล์ CLAUDE.md ควรมีอะไรอยู่ในนั้นบ้างแบบ เจาะจงเป็นรูปธรรม เลยไม่รู้ว่ามันสำคัญแค่ไหน

    • ให้ปลา: อ่านได้ที่นี่ https://code.claude.com/docs/en/best-practices#write-an-effe...
      สอนจับปลา: 1) ติดตั้ง skill-creator อย่างเป็นทางการ 2) ใช้ลิงก์ด้านบนสร้าง claude-md-improver 3) ให้มันไปศึกษาหัวข้อ progressive-disclosure จากเอกสารทางการแล้วปรับปรุง skill 4) นำ skill ใหม่ไปใช้กับไฟล์ CLAUDE.md และยอมรับการเปลี่ยนแปลง