ใช้ Claude Code เป็นเครื่องมือประจำวัน: Claude.md, Skills, Subagents, Plugins, MCP

 (arps18.github.io)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ประสิทธิภาพของ Claude Code แตกต่างกันอย่างมาก ไม่ได้อยู่ที่พรอมป์ต์ แต่ขึ้นอยู่กับวิธีสะสมและตรวจสอบ memory, custom commands, parallel sessions และการตั้งค่าโปรเจกต์
  • ควรดูแล CLAUDE.md ให้เป็น โครงสร้างพื้นฐานแบบสะสม ที่สั้นและเน้นการตรวจสอบ และเมื่อเกิดข้อผิดพลาดแล้วเพิ่มกฎเข้าไป ก็จะช่วยลดการผิดพลาดแบบเดิมซ้ำได้
  • .claude/ คือ ระบบการตั้งค่าแบบลำดับชั้น ที่เก็บ CLAUDE.md, rules, skills, commands, agents และการตั้งค่า MCP โดยแยกการใช้งานระหว่างขอบเขตระดับโปรเจกต์และระดับ global
  • Skills ทำให้งานที่ทำซ้ำกลายเป็นความเชี่ยวชาญที่นำกลับมาใช้ได้ ส่วน subagents จะทำงานรีวิว ดีบัก และมิเกรชันใน context แยกต่างหาก
  • เมื่อรวม Plugins, MCP, /goal, /rewind, /batch ไปจนถึง parallel worktree เข้าด้วยกัน Claude Code ก็จะกลายเป็น development agent ที่ต้องมีการตั้งค่าและการดูแลการปฏิบัติงาน

ใช้ Claude Code ในฐานะเอเจนต์ที่ตรวจสอบได้

  • ความต่างด้านประสิทธิภาพของ Claude Code ไม่ได้มาจากพรอมป์ต์เพียงอย่างเดียว แต่เกิดจากการสะสม memory, custom commands, parallel sessions และการตั้งค่าโปรเจกต์ อย่างไร
  • หลักการสำคัญคือทำให้ Claude สามารถตรวจสอบผลลัพธ์ของตัวเองได้ และ Boris Cherny กับทีม Anthropic มองว่าเพียงวิธีนี้ก็ช่วยยกระดับ คุณภาพได้ 2~3 เท่า
  • ลำดับการทำงานที่เหมาะสมคือ สำรวจ → วางแผน → ลงมือทำ
    • โหมดวางแผนที่เข้าได้ด้วยการกด Shift+Tab สองครั้ง เหมาะกับการสำรวจแบบอ่านอย่างเดียว
    • แนวทางที่แนะนำคืออ่านไฟล์ ทำความเข้าใจ flow และ data model ก่อน จากนั้นค่อยวางแผนและลงมือทำ
    • งานที่ต้องแก้หลายไฟล์เหมาะกับโหมดวางแผน ส่วนการแก้เล็กน้อยสามารถข้ามได้
  • โหมดวางแผนสามารถใช้เป็น เอกสารออกแบบ ที่ตรวจทานได้ก่อนลงมือทำจริง
    • ให้ Claude ตัวหนึ่งเขียนแผน แล้วให้ Claude อีกตัวในเซสชันใหม่ตรวจทานแบบไม่มีอคติราวกับเป็น staff engineer ก็ได้
    • หากการ implement หลุดจากแผน ควรย้อนกลับไปยังโหมดวางแผนและวางใหม่โดยรวมขั้นตอนการตรวจสอบเข้าไปด้วย
    • ใช้ Ctrl+G เพื่อเปิดแผนของ Claude ใน editor และแก้ไขเองได้ก่อนเริ่ม implement
  • การอ้างอิงที่แม่นยำได้ผลดีกว่าคำสั่งที่คลุมเครือ
    • แทนที่จะบอกว่า “ดู auth module” ให้ระบุไฟล์ตรงๆ เช่น @src/auth/login.py
    • สำหรับ error ควรส่งผ่าน pipe เช่น cat error.log | claude แทนการคัดลอกมาวาง
  • Cat Wu มองว่า Claude Code ทำงานได้ดีที่สุดเมื่อปฏิบัติต่อมันเหมือน วิศวกรที่ได้รับมอบหมายงาน มากกว่าจะเป็น pair programmer ที่ต้องสั่งทีละบรรทัด
  • หาก Claude ทำผิดพลาด สามารถเติม “Update CLAUDE.md so you do not repeat this.” ไว้ท้ายพรอมป์ต์ เพื่อให้มันทิ้งกฎไว้ป้องกันความผิดพลาดแบบเดิม

ไดเรกทอรี .claude และลำดับชั้นของการตั้งค่า

  • .claude/ ไม่ใช่โฟลเดอร์สำหรับเก็บแค่ CLAUDE.md แต่เป็น ระบบการตั้งค่าแบบลำดับชั้น
  • การตั้งค่าแบ่งเป็นสองขอบเขต
    • ขอบเขตระดับโปรเจกต์: วางไว้ใน .claude/ ภายใน repository แล้ว commit เข้า git เพื่อแชร์กับทีม
    • ขอบเขตระดับ global: วางไว้ที่ ~/.claude/ และมีผลกับทุกโปรเจกต์ในเครื่องโลคัล
  • สามารถมองได้ว่าไฟล์ระดับโปรเจกต์อธิบายตัวโปรเจกต์ ส่วนไฟล์ระดับ global อธิบายความชอบและวิธีทำงานของผู้ใช้
  • หน้าที่ของไฟล์หลัก
    • CLAUDE.md: คำสั่งที่โหลดทุกเซสชัน ใช้ได้ทั้งระดับโปรเจกต์และระดับ global
    • CLAUDE.local.md: โน้ตส่วนตัวเฉพาะโปรเจกต์ และควรอยู่ใน gitignore
    • settings.json: สิทธิ์, hooks, environment variables และการตั้งค่าโมเดลเริ่มต้น
    • settings.local.json: การ override ส่วนบุคคล และถูกใส่ gitignore อัตโนมัติ
    • .mcp.json: การตั้งค่า MCP server ที่ทีมแชร์กันในโปรเจกต์
    • skills/<name>/SKILL.md: พรอมป์ต์ที่ใช้ซ้ำได้และเรียกด้วย /name
    • commands/*.md: slash command แบบไฟล์เดียว
    • agents/*.md: คำจำกัดความของ subagent
    • rules/*.md: คำแนะนำตามหัวข้อ ซึ่งกำหนดให้ใช้ตาม path ได้
  • CLAUDE.md จะถูกโหลดแบบเป็นลำดับชั้น
    • ใน monorepo อาจโหลดทั้ง root/CLAUDE.md และ root/services/billing/CLAUDE.md พร้อมกันได้
    • เหมาะกับ codebase ที่มีธรรมเนียมแตกต่างกันในแต่ละโฟลเดอร์
  • .claude/rules/*.md เหมาะกับคำแนะนำที่ใช้ตาม path
    • กฎที่จำเป็นเฉพาะในโฟลเดอร์ migration ควรใส่ไว้ใน .claude/rules/migrations.md พร้อม glob มากกว่าจะใส่ใน CLAUDE.md จนทั้งเซสชันบวมเกินไป
  • สำหรับงานใหม่ แนะนำให้ใช้ skills มากกว่า commands
    • ทั้ง .claude/commands/*.md และ .claude/skills/<name>/SKILL.md ต่างก็สร้าง slash command ได้
    • แต่ skills รองรับไฟล์เสริม, disable-model-invocation, เครื่องมือที่อนุญาต และ agent overrides
  • ใช้ claude project purge ~/path/to/repo --dry-run เพื่อตรวจสอบ local state ที่ Claude เก็บไว้สำหรับโปรเจกต์นั้นได้

ดูแล CLAUDE.md ให้สั้นและเน้นการตรวจสอบ

  • CLAUDE.md จะถูกโหลดตอนเริ่มทุกเซสชัน ดังนั้นถ้าเขียนไม่ดี Claude ก็จะทำผิดแบบเดิมซ้ำ แต่ถ้าเขียนดี ผลลัพธ์จากพรอมป์ต์เดียวกันจะดีขึ้นมาก
  • หลักการที่สำคัญที่สุดคือ ต้องทำให้สั้น
    • วิธีที่แนะนำคือถามทุกบรรทัดว่า “ถ้าลบบรรทัดนี้ออก Claude จะทำพลาดไหม?” ถ้าไม่ ก็ให้ลบ
  • ถ้าให้ Claude เขียนกฎของตัวเองโดยตรง จะเกิดผลแบบสะสม
    • เมื่อ Claude ทำผิด ให้สั่งว่า “Update CLAUDE.md so you do not repeat this.” แล้ว Claude จะสรุปความผิดพลาดนั้นเป็นกฎที่แม่นยำได้
    • หากทำแบบนี้ซ้ำเป็นเวลาหลายสัปดาห์ จุดเสี่ยงของโปรเจกต์จะสะสมเป็นรายการกฎ
  • CLAUDE.md ที่ทีม Claude Code ใช้จริงเน้นที่ คำสั่ง build และลำดับการตรวจสอบ
    • ใช้ bun และไม่ใช้ npm
    • ระบุลำดับของการ typecheck แบบเร็วหลังแก้ไข, การทดสอบ, การ lint ก่อน commit และการตรวจสอบทั้งหมดก่อน PR
    • ไม่ใส่เรื่องรสนิยมด้านสไตล์, การพาชม codebase หรือข้อสรุปทั่วไป
  • แม้แต่ในคอมเมนต์ PR ก็สามารถใช้ @claude เพื่อเพิ่มกฎได้โดยตรง
    • ตัวอย่าง: @claude add to CLAUDE.md to never use enums, always prefer literal unions
    • การรีวิว PR จึงต่อยอดไปเป็นการปรับปรุง CLAUDE.md และสร้างกระบวนการแบบ “Compounding Engineering”
  • CLAUDE.md ที่ดีควรโฟกัสกับข้อมูลต่อไปนี้
    • code style: ใช้ ES modules แทน CommonJS
    • workflow: รัน bun run typecheck, ห้าม push เข้า main โดยตรง
    • architecture: API routes ต้องผ่าน middleware ที่กำหนดเสมอ
    • gotchas: ความต่างระหว่าง User กับ UserRecord, และข้อเท็จจริงที่ว่า formatCurrency สมมติว่าเป็น USD
  • สิ่งที่ไม่ควรใส่ใน CLAUDE.md
    • ธรรมเนียมมาตรฐานของภาษา
    • คำอธิบาย codebase รายไฟล์
    • tutorial ยาวๆ
    • เอกสาร API
    • เนื้อหาที่เปลี่ยนบ่อย
  • คำอย่าง IMPORTANT, YOU MUST อาจช่วยเพิ่มอัตราการทำตามได้ แต่ควรใช้ให้น้อยเพื่อคงน้ำหนักของมันไว้
  • หากใช้ไวยากรณ์ @path เพื่อนำเข้าไฟล์อื่น ก็จะทำให้ CLAUDE.md สั้นได้โดยยังเชื่อมไปยังรายละเอียดเพิ่มเติม
    • ตัวอย่าง: See @README.md for project overview and @package.json for scripts.
    • ตัวอย่าง: @~/.claude/my-preferences.md

สะสมฟีดแบ็กส่วนตัวด้วย CLAUDE.local.md

  • CLAUDE.local.md จะถูกโหลดจากตำแหน่งเดียวกับ CLAUDE.md และด้วยวิธีเดียวกัน แต่ไม่ควรออกไปนอกเครื่องโลคัลและควรถูกเพิ่มไว้ใน .gitignore
  • หากนำคอมเมนต์รีวิว PR มาใส่ใน CLAUDE.local.md ทันที ฟีดแบ็กส่วนตัวที่เกิดซ้ำจะสะสมเป็น ไฟล์กฎส่วนบุคคล
  • ตัวอย่างกฎ
    • SQS consumer ใหม่ต้องมี DLQ และ alarm ใน PR เดียวกัน
    • ควรใช้ Optional<T> มากกว่าการคืนค่า null
    • การทดสอบ endpoint ใหม่ต้องมีเคส auth-failure
    • เมื่อเพิ่ม endpoint ต้องอัปเดต OpenAPI spec ด้วย
  • ควรแยกฟีดแบ็กเฉพาะโปรเจกต์ออกจากรายการแก้นิสัยส่วนตัว
  • หลังผ่านไปหลายสัปดาห์ ควรลบรายการที่กลายเป็นนิสัยไปแล้ว และคงไว้เฉพาะสิ่งที่ยังอยู่ระหว่างการเรียนรู้

Skills: หน่วยความเชี่ยวชาญที่นำกลับมาใช้ซ้ำได้

  • Skills คือ หน่วยความเชี่ยวชาญที่นำกลับมาใช้ซ้ำได้ ซึ่งเปลี่ยน Claude Code จาก “เอเจนต์ที่ทำได้ทุกอย่าง” ให้กลายเป็นเอเจนต์ที่เก่งงานเฉพาะของแต่ละโปรเจกต์

  • โครงสร้างของ Skill

    • skill คือโฟลเดอร์ภายใต้ .claude/skills/<name>/ หรือ ~/.claude/skills/<name>/
    • SKILL.md ภายในโฟลเดอร์จะเก็บ frontmatter และคำสั่งต่าง ๆ
    • ชื่อโฟลเดอร์จะกลายเป็นคำสั่งแบบสแลช
    • ตัวอย่างเช่น หากสร้าง ~/.claude/skills/summarize-changes/SKILL.md ก็จะใช้ /summarize-changes ได้ในทุกเซสชัน

  • ทำไม Skill ถึงทรงพลัง

    • การเปิดเผยแบบค่อยเป็นค่อยไป: ตอนเริ่มเซสชันจะโหลดเฉพาะคำอธิบายใน frontmatter และจะโหลด SKILL.md ฉบับเต็มกับไฟล์ประกอบก็ต่อเมื่อจำเป็นจริง ๆ
    • การจัดโครงสร้างแบบโฟลเดอร์: สามารถรวมเทมเพลต เอกสารอ้างอิง สคริปต์ และการตั้งค่าไว้ด้วยกันได้
    • อินไลน์เชลล์: บรรทัดที่ขึ้นต้นด้วย ! จะรันคำสั่งและแทรกผลลัพธ์ ณ เวลาที่ถูกเรียกใช้

  • ตัวเลือกใน Frontmatter

    • description: อธิบายว่าควรใช้ skill นี้เมื่อไร
    • disable-model-invocation: true: ให้ทำงานเฉพาะเมื่อผู้ใช้พิมพ์ /my-skill อย่างชัดเจนเท่านั้น
    • allowed-tools: จำกัดเครื่องมือที่ใช้ได้ เช่น Read, Grep, Bash
    • agent: สามารถตั้งให้รันในโหมดเอเจนต์เฉพาะได้
    • สำหรับ skill ที่มีผลข้างเคียง เช่น การ deploy ควรใช้ disable-model-invocation: true

  • ตัวอย่าง skill สำหรับธรรมเนียมปฏิบัติของ Go API

    • skill สำหรับสร้าง scaffold ของ HTTP handler ใหม่ในทีมที่ใช้ Go service สามารถวาง SKILL.md, templates/handler.go.tmpl, examples/healthz.go ไว้ด้วยกันได้
    • ตัวอย่างกฎอาจเก็บธรรมเนียมเฉพาะโปรเจกต์ เช่น การใช้ Go 1.22 กับ chi router, sqlc typed query, zap structured logging, และการนิยมใช้ testify assertion กับ table-driven test
    • ตัวอย่าง gotcha จะช่วยกันความผิดพลาดซ้ำ ๆ เช่น chi.URLParam จะคืนค่า "" เมื่อไม่มี param, httperr.Wrap ไม่ทิ้ง log, และ pgtype.Text ต้องตรวจสอบ .Valid

  • Skills ที่น่าติดตั้ง

    • mattpocock/skills: คลัง skills ยอดนิยมที่มีประมาณ 100k stars
      • /grill-me: สัมภาษณ์แผนก่อนเริ่มเขียนโค้ด
      • /tdd: บังคับใช้ red-green-refactor อย่างเคร่งครัด
      • /diagnose: ดีบักตามลำดับ reproduce, minimize, hypothesis, fix, regression test
      • การติดตั้ง: npx skills@latest add mattpocock/skills
    • Jeffallan/claude-skills: มีโปรไฟล์รายภาษาจำนวน 66 แบบ เช่น go-pro, python-pro, java-architect, typescript-pro, rust-engineer, sql-pro
    • skills ทางการจาก Anthropic
      • /code-review: เอเจนต์ขนาน 4 ตัวตรวจสอบ diff และรายงานเฉพาะสิ่งที่พบตามคะแนนความเชื่อมั่น
      • /simplify: ทบทวนโค้ดล่าสุดจากมุมมองด้านการนำกลับมาใช้ซ้ำและประสิทธิภาพ
      • /batch: กระจาย migration ไปยังเอเจนต์ขนานหลายตัวและให้แต่ละตัวทำงานใน worktree ของตัวเอง
      • /webapp-testing: ให้ Claude ทดสอบเว็บแอปในเครื่องด้วย Playwright
    • งานที่ทำซ้ำเกินวันละครั้งควรเปลี่ยนให้เป็น skill
    • หาก commit skills ลง git ก็จะกลายเป็น ความรู้ระดับองค์กร ของทีม และเมื่อวิศวกรใหม่ clone รีโป ก็จะได้แนวปฏิบัติที่สั่งสมไว้ทันที

Subagents: ให้โฟกัสงานในคอนเท็กซ์แยกต่างหาก

  • subagent จะทำงานด้วยคอนเท็กซ์วินโดว์และสิทธิ์ใช้เครื่องมือของตัวเอง จากนั้นจึงส่งผลสรุปกลับมา
  • คุณค่าหลักคือแม้จะอ่านไฟล์จำนวนมาก ก็ไม่ทำให้คอนเท็กซ์ของเซสชันหลักเต็ม
  • subagent คือไฟล์ markdown ภายใต้ .claude/agents/ หรือ ~/.claude/agents/ โดยประกาศ name, description, tools, model ใน frontmatter

  • การตั้งค่าเอเจนต์ /pr-review

    • สามารถกำหนดให้เปรียบเทียบ diff ของ branch ปัจจุบันกับ main เพื่อหา bug, security issue, edge case ที่ตกหล่น, และการละเมิดธรรมเนียมของโปรเจกต์
    • ให้สิทธิ์แบบเน้นการอ่านด้วย tools: Read, Grep, Glob, Bash
    • สามารถใช้ model: opus เพื่อเลือกโมเดลที่แข็งแกร่งกว่าสำหรับรีวิวความเสี่ยงสูง
    • กระบวนการประกอบด้วย git diff main...HEAD, git log main..HEAD --oneline, การอ่านไฟล์ทั้งหมด, และการเทียบกับ CLAUDE.md, CLAUDE.local.md, .claude/rules/
    • ผลลัพธ์สามารถจัดกลุ่มเป็น Critical / High / Medium / Low พร้อมระบุไฟล์, line, issue, suggested fix และปิดท้ายด้วยอย่างใดอย่างหนึ่งระหว่าง SHIP, FIX FIRST, REWORK

  • การออกแบบเพื่อเพิ่มอัตราส่วนสัญญาณต่อสัญญาณรบกวน

    • หาก reviewer แก้โค้ดเอง จะเกิดอคติที่คอยปกป้องวิธีแก้ของตัวเอง ดังนั้นเครื่องมือแบบอ่านอย่างเดียวจึงเหมาะกว่า
    • หากระบุในส่วน “Do NOT flag” ว่าไม่ให้ชี้เรื่องรสนิยมด้านสไตล์ที่ไม่ได้อยู่ในกฎโปรเจกต์, ไม่เสนอรีแฟกเตอร์สำหรับโค้ดที่ทำงานได้อยู่แล้ว, และไม่พูดถึงสิ่งที่อยู่นอก diff ก็จะช่วยลดสัญญาณรบกวนได้

  • แพตเทิร์น subagent ที่ใช้บ่อย

    • ทีม Claude Code เช็กอิน build-validator, code-architect, code-simplifier, oncall-guide, verify-app ไว้
    • security-reviewer: ตรวจสอบ injection, auth, secrets, insecure deserialization
    • test-writer: สร้างเทสต์และทำงานเป็นลูปร่วมกับ code-reviewer
    • debugger: ไล่จากเทสต์ที่ล้มเหลวไปจนถึง root cause
    • performance-auditor: ตรวจ flow และ query profiling
    • migration-writer: สร้าง DB migration ให้ตรงตามธรรมเนียมของโปรเจกต์
    • release-notes-writer: สร้าง changelog จาก commit history
    • วิธีที่ Session A เป็นผู้ลงมือ implement แล้วให้ code-reviewer subagent มาตรวจในคอนเท็กซ์ใหม่ จะช่วยลดอคติจากการลงมือทำเอง
    • หากเพิ่ม isolation: worktree ใน frontmatter ก็สามารถให้ subagent รันใน git worktree แยกได้ ซึ่งมีประโยชน์เมื่อกระจาย migration ไปยังเอเจนต์ขนานหลายตัว

Plugins และ Marketplace

  • Plugins คือการรวม skills, hooks, subagents และ MCP servers เข้าไว้เป็นหน่วยเดียวที่ติดตั้งได้
  • สามารถเปิด marketplace browser ได้ด้วย /plugin
  • สามารถเพิ่ม community marketplace ได้ด้วย /plugin marketplace add owner/repo

  • รายการที่ควรติดตั้งในช่วงแรก

    • /code-review: จะรัน agent แบบขนาน 4 ตัว โดย 2 ตัวตรวจว่าปฏิบัติตาม CLAUDE.md หรือไม่, 1 ตัววิเคราะห์ bug, และอีก 1 ตัววิเคราะห์บริบทจาก git blame
    • /feature-dev: แปลง feature brief ให้เป็นโค้ดที่ใช้งานได้ผ่าน 7 ขั้นตอน ได้แก่ requirements → exploration → architecture → implementation → testing → review → docs
    • Language server plugin: ให้การนำทาง symbol ที่แม่นยำและ diagnostics อัตโนมัติหลังแก้ไข โดยทีมเรียกว่าเป็น plugin ที่มีผลกระทบมากที่สุด
    • /security-guidance: security skill อย่างเป็นทางการของ Anthropic ที่ช่วยเปิดเผยข้อกังวลด้านความปลอดภัยก่อน ship
    • ณ กลางปี 2026 มี plugins มากกว่า 1,000 รายการใน marketplace มากกว่า 75 แห่ง
    • หมวด plugin หลักได้แก่ Git workflow, code intelligence (LSP), documentation generators, testing, browser automation (Playwright), design system (Figma), observability (Sentry, Datadog)
    • หากวาง .mcp.json สำหรับใช้ร่วมกันในทีมไว้คู่กับ plugins ที่คัดเลือกแล้ว วิศวกรใหม่จะเริ่มทำงานได้อย่างมีประสิทธิภาพภายในไม่กี่นาทีหลัง clone รีโพซิทอรี

คำสั่ง Claude Code ที่ส่งผลต่อ productivity อย่างมาก

  • ผู้ใช้จำนวนมากเรียนรู้แค่ /clear, /compact, /init แล้วหยุด แต่คำสั่งอื่น ๆ ก็ส่งผลอย่างมากต่อ productivity ในแต่ละวันเช่นกัน

  • คำสั่งสำคัญ

    • /insights: วิเคราะห์รูปแบบการใช้งาน และควรรันเดือนละครั้ง
    • /compact <hint>: บีบอัดเซสชัน โดย hint จะกำหนดว่าควรเก็บอะไรไว้
    • /copy: คัดลอกคำตอบล่าสุด และมี interactive picker สำหรับ code block
    • /rewind: undo ทั้งเซสชัน ใช้กู้คืนโค้ด, บทสนทนา หรือทั้งสองอย่าง
    • /btw: คำถามข้างเคียงที่ไม่ถูกบันทึกในประวัติการสนทนา
    • /context: แสดงภาพการใช้คอนเท็กซ์
    • /export <file>: dump บทสนทนาลงไฟล์
    • /branch: fork เซสชันสำหรับการลองสิ่งที่เสี่ยง
    • /batch: กระจายงานให้ agent แบบขนานทั่วทั้ง worktree
    • /loop <interval>: รัน Claude ซ้ำได้สูงสุด 3 วัน
    • /schedule: เวอร์ชัน cloud ของ /loop ที่ทำงานได้แม้ปิด laptop
    • /teleport: ย้ายเซสชันระหว่าง terminal และเว็บ
    • /focus: ซ่อน tool call ระหว่างทางและแสดงเฉพาะผลลัพธ์สุดท้าย
    • /voice: ป้อนข้อมูลด้วยเสียง
    • --bare: ทำให้การเริ่มต้นในโหมด non-interactive claude -p เร็วขึ้นได้สูงสุด 10 เท่า

  • ความแตกต่างระหว่าง /compact กับ /clear

    • หากเป็นงานใหม่ทั้งหมด ควรใช้ /clear และ brief ที่เขียนขึ้นใหม่
    • หากเป็นงานที่เกี่ยวเนื่องกันและยังต้องใช้คอนเท็กซ์อยู่ ควรใช้ /compact พร้อม hint
    • /compact เป็นการสรุปแบบมีการสูญเสียโดย LLM ส่วน /clear คือ brief ที่ผู้ใช้เขียนเอง จึงสำคัญที่ต้องแยกให้ชัด

  • วิธีใช้ /rewind

    • ถ้า Claude เดินไปผิดทาง โดยทั่วไปไม่ควรพิมพ์ต่อว่า “อันนั้นไม่เวิร์ก ลองทำ X ดู”
    • หากพิมพ์ต่อ คอนเท็กซ์จะปนเปื้อน จึงควร rewind แล้ว prompt ใหม่โดยสะท้อนสิ่งที่ได้เรียนรู้
    • สามารถเปิด rewind ได้ด้วยการกด Esc สองครั้ง
    • ! ใช้เป็น shell escape ได้
    • เช่น !git status, !npm test จะรันทันทีและนำผลลัพธ์เข้าไปในคอนเท็กซ์
    • การตั้งค่า CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 ใช้เพื่อบังคับให้ compaction เร็วขึ้น ก่อนจะเกิด context rot แถวราว 300~400k tokens บนโมเดล 1M

  • รูปแบบ Fan-out

    • เริ่มจากทำ task list แล้วทดสอบกับสามไฟล์
    • ปรับ prompt แล้วจึงนำไปใช้กับไฟล์หลายพันไฟล์
    • ตัวอย่าง:
for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --bare
done

/goal: ลูปวนซ้ำที่มีเงื่อนไขการเสร็จสิ้นในตัว

  • /goal ใช้ตั้งเงื่อนไขการเสร็จสิ้น และทุกครั้งที่ Claude พยายามหยุด จะตรวจเงื่อนไขกับ transcript
  • เงื่อนไขต้อง ตรวจสอบได้และเป็นแบบกำหนดแน่ชัด
    • test command
    • CLI exit code
    • file state
  • ตัวอย่าง:
/goal all tests in test/auth pass and the lint step is clean
/goal all integration tests in tests/api pass without flaking 3 runs in a row
/goal the OpenAPI spec validates and matches the actual response shapes
/goal docker compose up runs cleanly and the healthcheck endpoint returns 200
/goal coverage on src/billing/ is above 80% and all new tests are not placeholders
  • เงื่อนไขกำกวมอย่าง “โค้ดดีแล้ว” จะใช้ไม่ได้
  • ฟีเจอร์ที่ใช้ร่วมกันได้ดี
    • /loop: ทำซ้ำตามช่วงเวลาเพื่อลด backlog
    • /schedule: รันเป็นระยะบน cloud
    • Stop hook: ตั้ง gate ด้วย test suite ของตัวเองหรือ CI endpoint
    • Auto mode: ทำให้ goal ที่ยาวไม่หยุดเพราะ permission prompt
  • การใช้ /goal + auto mode + /focus ร่วมกัน มีเป้าหมายเป็นเวิร์กโฟลว์ที่ตั้ง brief และเงื่อนไขเสร็จสิ้นให้ชัดเจน แล้วกลับมาพบว่า PR เสร็จเรียบร้อยแล้ว

ใช้ MCP เป็นเครื่องมือรับรู้ระบบ

  • MCP(Model Context Protocol) ทำให้ Claude Code ก้าวข้ามการเป็น coding agent ไปเป็น agent ที่รับรู้ระบบภายนอกได้
  • MCP server เปิดเผยเครื่องมือภายนอกอย่าง database, design tool, error tracker และ notes ให้ Claude เข้าถึงได้ด้วยวิธีมาตรฐาน
  • หากไม่มี MCP, Claude จะอ่านไฟล์และรันคำสั่งได้ แต่เมื่อใช้ MCP ก็จะจัดการกับ Linear ticket, Postgres query, Figma component, Sentry stack trace และ Obsidian vault ได้โดยไม่ต้องออกจาก terminal

  • MCP ที่ใช้บ่อยในงานวิศวกรรม

    • GitHub: จัดการ repo, PRs, issues, code search
    • Context7: docs ของ library เวอร์ชันล่าสุด, เพิ่ม use context7 ใน prompt
    • Sentry: context ของ error จริง, stack traces, breadcrumbs
    • Linear: อ่านและสร้าง ticket, อัปเดต status
    • Playwright: browser automation บนพื้นฐาน accessibility snapshot
    • Figma: live design tree, auto-layout, spacing tokens, component refs
    • Postgres / Supabase: query กับ dev DB โดยตรง
    • Slack: อ่าน thread, สรุป discussion, ร่าง response
    • local server ใช้ stdio ส่วน vendor-hosted server ใช้ HTTP ที่มี OAuth
    • ตัวอย่าง:
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
  • MCP ที่แชร์กันทั้งทีมให้อยู่ใน .mcp.json ที่ project root ส่วน MCP ส่วนตัวให้อยู่ใน ~/.claude.json
  • ถ้าติดตั้ง MCP มากเกินไป รายการ tool ที่ Claude ต้องพิจารณาจะใหญ่ขึ้นและอาจทำให้คุณภาพการตัดสินใจลดลง
  • ชุดเริ่มต้นที่เหมาะสมคือ GitHub, Context7 และ MCP เฉพาะโดเมนอีกหนึ่งหรือสองตัว
  • /mcp คือจุดตรวจเช็กแรกภายใน Claude Code เพื่อดู server ที่เปิดใช้งานและสถานะการเชื่อมต่อ

Obsidian กับโครงสร้างหน่วยความจำ 3 ชั้นของ Claude Code

  • การใช้ Obsidian + Claude Code ร่วมกันจะทรงพลังเมื่อใช้เป็น สถาปัตยกรรมหน่วยความจำ 3 ชั้น ไม่ใช่แค่ “ให้ Claude อ่าน vault”

  • การตั้งค่า

    • ติดตั้ง obsidian-claude-code-mcp ใน Obsidian
    • plugin จะเปิดเผย vault ผ่าน local WebSocket ที่พอร์ต 22360
    • Claude Code จะ auto-discover สิ่งนี้
    • เพิ่ม CLAUDE.md ใน vault เพื่ออธิบาย folder structure

  • โครงสร้างโฟลเดอร์

    • 00-Inbox/: raw capture
    • 10-Daily/: หนึ่ง note ต่อหนึ่งวัน
    • 20-Projects/: note ของโปรเจกต์ที่กำลังทำอยู่
    • 20-Projects/billing-v2/README.md: เป้าหมาย, สถานะ, คำถามที่ยังเปิดอยู่
    • 20-Projects/billing-v2/decisions/: ADRs
    • 20-Projects/billing-v2/sessions/: log แยกตาม Claude session
    • 30-Decisions/: ADRs ข้ามโปรเจกต์
    • 40-Atoms/: องค์ความรู้ที่นำกลับมาใช้ได้และ links
    • 90-Archive/: archive

  • Hot storage

    • ทุก Claude session จะเขียน log ที่มี timestamp ลงใน 10-Daily/<today>.md
    • สามารถใช้ hook Stop เพื่อให้ append structured summary ตอนที่ agent จบการทำงานได้

  • Warm storage

    • แต่ละโปรเจกต์มีโฟลเดอร์อยู่ภายใต้ 20-Projects/
    • ก่อนเริ่ม session ใหม่ Claude จะอ่าน README ของโปรเจกต์และ session logs ล่าสุด 2–3 รายการเพื่อกู้คืน context
    • เป็น workflow ที่สร้าง context ย้อนหลัง 2 สัปดาห์ขึ้นมาใหม่ได้ภายใน 30 วินาที

  • Cold storage

    • การตัดสินใจด้านสถาปัตยกรรมจะถูกยกระดับเป็น ADR ใน 30-Decisions/
    • ความรู้ที่นำกลับมาใช้ซ้ำได้จะถูกขัดเกลาไปไว้ใน 40-Atoms/ และเชื่อมกับหลายโปรเจกต์ผ่าน wikilinks

  • ตัวอย่าง workflow ประจำวัน

    • What is in my inbox? Summarize and suggest where each item belongs.
    • Check 30-Decisions/ for anything related to retry policies.
    • Read the last 3 session logs for billing-v2. Tell me where I left off.

ปรับการไหลของงานพัฒนาในชีวิตประจำวันให้เหมาะสม

  • ฟีเจอร์ใหม่

    • เริ่มด้วย plan mode
    • แก้ไขแผนด้วย Ctrl+G
    • หลัง implement แล้ว ให้เรียก /pr-review subagent หรือ review ด้วย Claude session ใหม่

  • บั๊ก

    • เริ่มจาก reproduce ให้ได้ก่อน
    • pipe error ด้วย cat error.log | claude
    • ให้ Claude เขียน failing test ก่อน แล้วค่อยแก้ไข
    • อย่าปล่อยให้การทดสอบทำให้การแก้ไขจบลงแค่การเดา

  • Migration และการเปลี่ยนแปลงจำนวนมาก

    • /batch จะสัมภาษณ์การเปลี่ยนแปลงก่อน แล้วกระจายงานไปยัง parallel agents
    • แต่ละ agent จะทดสอบใน worktree ของตัวเองและสร้าง PR

  • โค้ดที่ไม่คุ้นเคย

    • ใช้ subagent เช่น “Use a subagent to investigate how our auth handles token refresh.”
    • subagent จะอ่านไฟล์หลายสิบไฟล์ใน context ของตัวเองและส่งสรุปกลับมา ทำให้ main session ยังสะอาดอยู่

  • session แบบขนาน

    • Boris และทีมมองว่าการรัน Claude session 3–5 ชุดในแต่ละ git worktree เป็นตัวปลดล็อกด้านผลิตภาพที่ใหญ่ที่สุด
    • สามารถใช้มุมมอง agent ของ claude agents เป็นเหมือน control plane ได้

  • รูปแบบ Writer/Reviewer

    • Session A ลงมือ implement
    • Session B review ด้วย context ใหม่ทั้งหมด
    • ดึง review กลับมา แก้ไข แล้วทำซ้ำ

  • compact ทุกครั้งเมื่อถึง milestone

    • เมื่อจบ chunk เชิงตรรกะ ให้ระบุสิ่งที่ต้องเก็บไว้ เช่น /compact Preserve the decisions made, files changed, and test commands.
    • อย่าปล่อยให้ Claude อ้างว่าสำเร็จโดยไม่มีหลักฐาน เช่น tests, screenshot หรือ command output จริง
    • ช่องว่างแบบ trust-then-verify ถูกชี้ว่าเป็นสาเหตุใหญ่ที่สุดของผลลัพธ์ที่ไม่ดี

แพตเทิร์นที่ทีม Anthropic ใช้ซ้ำเป็นประจำ

  • หากทำให้ Claude ตรวจสอบ output ของตัวเองได้ ก็สามารถวนซ้ำไปเรื่อย ๆ จนกว่าผลลัพธ์จะดีขึ้น
  • Boris ใช้ Opus และ high หรือ xhigh effort กับงานส่วนใหญ่
    • เพราะถ้าใช้โมเดลที่เล็กกว่าแล้วต้องแก้หลายรอบกว่า สุดท้ายอาจช้ากว่าโดยรวม
  • รัน 3~5 เซสชันแบบขนาน
    • ใช้ worktree แทน checkout
    • ใช้ claude --worktree หรือ Desktop app ได้
    • agent view จะช่วยรวมเซสชันแบบขนานไว้ด้วยกัน
  • ดูแล notes directory แยกตามแต่ละ project และอัปเดตหลังจบทุก PR
    • ถ้าทำให้ CLAUDE.md ชี้ไปที่ notes directory นั้น ความรู้เกี่ยวกับโค้ดเบสของมันเองก็จะสะสมเพิ่มขึ้น
  • สามารถสร้าง slash command /techdebt เพื่อค้นหาและลบโค้ดซ้ำตอนจบแต่ละเซสชันได้
  • CLAUDE.md ของทีมถูกแชร์ร่วมกัน และมีการแก้ไขหลายครั้งต่อสัปดาห์
    • ปฏิบัติต่อมันเหมือนเอกสารที่มีชีวิต โดยใครก็ตามที่เห็นว่า Claude ทำพลาดจะเพิ่มกฎเข้าไป
  • Playwright MCP เหมาะกับการเปลี่ยนแปลง UI
    • Claude สามารถเปิด browser คลิก และตรวจสอบได้
  • language server plugin ช่วยจับ type error และ unused imports หลังการแก้ไขแต่ละครั้ง และถูกยกให้เป็น plugin ที่มีผลกระทบมากที่สุด
  • /voice ช่วยทำให้ prompt ละเอียดขึ้นได้
    • มีการให้เหตุผลประกอบว่าการพูดเร็วกว่าการพิมพ์ 3 เท่า
  • วิธีใช้ Ctrl+G เพื่อแก้ Claude plan ใน editor ก่อนลงมือ implement เร็วกว่าการพิมพ์ correction ใน chat
  • Boris ให้ Claude วาด ASCII diagram เมื่อต้องทำความเข้าใจ protocol และ codebase ที่ไม่คุ้นเคย

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

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

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

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

  • commands, skills, subagents, plugins กระจัดกระจายเกินไปจนต้องมีการจัดระเบียบ
    ยกตัวอย่าง แค่เรื่องรีวิวโค้ดก็มีทั้ง .claude/commands/review.md, skill /code-review, subagent /pr-review, plugin /code-review หรือแม้แต่แค่ขอให้ Claude ช่วยรีวิวให้ ก็กลายเป็นมีตัวเลือกตั้งห้าแบบ
    สุดท้ายแล้วส่วนใหญ่ก็เป็นเพียงรูปแบบแปลงของ การแทรกพรอมป์ต์ที่เตรียมไว้ล่วงหน้า โดยต่างกันแค่ว่าพรอมป์ต์ถูกติดตั้งไว้ที่ไหน และทำงานในบริบทแบบใด
    คำแนะนำว่าแบบไหนดีที่สุดก็ยังมีไม่มาก แนวปฏิบัติที่ดีเองก็ยังไม่ชัดเจน และส่วนตัวคิดว่าแค่ขอให้ Claude รีวิวโค้ดให้ตรงๆ ก็ทำได้ดีพอแล้ว
    อีกอย่าง คำแนะนำแนว “ให้ติดตั้ง language server plugin” ก็ไม่ค่อยตรงกับประสบการณ์จริงของผม ผมติดตั้ง LSP สำหรับ Rust, Python, Dart ลงใน Claude Code และ Codex แต่หลังจากใช้งานไปหลายร้อยเซสชันตลอดสองเดือน พอดูล็อกก็พบว่ามีการเรียกใช้เครื่องมือ LSP จริงๆ แค่ครั้งเดียวเท่านั้น และมีแต่ Rust analyzer/Dart analysis server/Ty LSP ที่ทำให้ RAM ไม่พอบ่อยๆ
    สุดท้ายเลยลบ LSP ออก และให้เอเจนต์เรียก ripgrep, cargo clippy, dart analyze, ty check โดยตรงก็เพียงพอแล้ว

    • ผม Boris จากทีม CC และเห็นด้วยกับประเด็นนี้ ตอนนี้กำลังทำงานเรื่องการรวมศูนย์อยู่ ในอนาคตจะเหลือแค่ /code-review skill แบบบิลต์อินตัวเดียว
      ในเวอร์ชันล่าสุด /code-review จะใช้สำหรับรีวิวแบบสมดุล, /code-review --fix ใช้สำหรับแก้ไขไปด้วย, และ /code-review low|medium|high|xhigh|max ใช้เลือกระดับความพยายามได้
      /code-review ultra เป็นโหมดรีวิวแบบละเอียดมาก ราคาแพง และตั้งเป้าไว้ให้จับบั๊กได้เกิน 99% อย่างสม่ำเสมอ โดยจะมีค่าใช้จ่ายราว $3~20 ต่อการรีวิวหนึ่งครั้งขึ้นอยู่กับความซับซ้อน
      ถ้ามีไอเดียว่าจะทำให้ใช้งานง่ายขึ้นอย่างไร ก็อยากได้ฟีดแบ็ก
    • ผมคิดมาพักหนึ่งแล้วว่า skills เป็น abstraction ที่ไม่ดี นิยามของมันคลุมเครือเกินไปว่าเอาไว้ใช้กับอะไร เลยทำให้มันได้รับความนิยม แต่ด้วยเหตุผลเดียวกันนี่แหละที่ทำให้มันดูไม่ดีในระยะยาว
      ทั้งแนวทางทั่วไปอย่าง best practices ในการออกแบบฟรอนต์เอนด์, คู่มือขั้นตอนปฏิบัติที่ต้องเรียกใช้แบบชัดเจนถึงจะทำตามได้ถูกต้อง, ไปจนถึงคำอธิบายวิธีใช้เครื่องมือเฉพาะ กลับถูกเหมารวมว่าเป็น skill ทั้งหมด ซึ่งมันแปลก
      ผมเข้าใจว่าความยืดหยุ่นมีเสน่ห์ในช่วงที่ทุกคนกำลังเรียนรู้เครื่องมือใหม่ไปพร้อมกัน แต่ skills เริ่มให้ความรู้สึกเหมือน “ลิ้นชักเก็บจุกจิกในครัวที่โยนอะไรก็ได้ลงไปเมื่อไม่อยากคิดว่าควรวางไว้ที่ไหน” มากขึ้นเรื่อยๆ
      ผมคิดว่าการแบ่งที่ดีกว่าคือให้ Agents เป็น บุคลิกหรือมุมมอง ที่โมเดลจะใช้, Prompts เป็นคำสั่งซ้ำๆ สำหรับงานเฉพาะ, และ Tools เป็นการทำให้ CLI/MCP/สคริปต์ รวมถึงคำแนะนำการใช้งาน เป็นมาตรฐานเดียวกัน
    • วิธีแบบ subagent ต่างจากตัวเลือกอื่นในเชิงโครงสร้าง เพราะมันรันอยู่ใน บริบทที่สะอาด
      อย่างแรก ค่าใช้จ่ายของเซสชัน LLM ต้องจ่ายทั้ง input token และค่า cache input ในทุกๆ รอบ ดังนั้นถ้าเงื่อนไขเหมือนกัน ต้นทุนไปสู่คำตอบอาจต่ำลงได้
      อย่างที่สอง โมเดลที่ใช้รีวิวจะหลอกตัวเองได้ยากกว่าด้วยสมมติฐานจากเมนเซสชัน เช่น “x ควรทำแบบ y” ซึ่งคล้ายกับเหตุผลที่การให้คนอื่นมาช่วยรีวิว หรือการพักหัวให้โล่งก่อนกลับมารีวิวเองนั้นมีประโยชน์
      อย่างที่สาม โมเดลหลักจะเห็นแค่ผลลัพธ์การรีวิวโดยไม่เห็นกระบวนการให้เหตุผลแบบละเอียด จึงช่วยลดการปนเปื้อนของบริบทได้ แต่ก็อาจเกิดตรรกะซ้ำซ้อนเพราะต้องกลับมาทำความเข้าใจกลไกของบั๊กที่พบอีกครั้ง
      ส่วนเจตนาของคำแนะนำเรื่อง language server plugin ผมคิดว่าไม่ใช่ให้รอ LLM เรียกใช้อย่างชัดเจน แต่เพื่อให้มีการรัน lint อัตโนมัติทุกครั้งที่มีการแก้ไข
    • ผมมองว่าตอนนี้ยังเป็นแค่ ช่วงเปลี่ยนผ่านชั่วคราว ที่โมเดลยังไม่ฉลาดพอและสภาพแวดล้อมการทำงานก็ยังไม่สุกงอม ถ้าต้องการรีวิวโค้ดก็แค่พูดว่า “ช่วยรีวิวหน่อย” ก็พอ แล้วให้โมเดลเป็นคนตัดสินเองว่าควรใช้ plugin หรือ skill อะไร
    • เห็นด้วยเลย ทั้งอุตสาหกรรมและระบบนิเวศนักพัฒนากำลังหลงใหลกับการเอา “การป้อนข้อความให้เครื่อง” ไปห่อด้วยโปรโตคอลย่อยๆ และกลไกสารพัด
      มันก็มีประโยชน์และช่วยให้สม่ำเสมอจริง แต่เหตุผลใหญ่ที่คนชอบมัน ผมว่าท้ายที่สุดคือมันช่วยคงภาพลักษณ์เคลือบบางๆ ของการเป็น “โปรแกรมเมอร์ที่ใช้เครื่องมือซับซ้อน” เอาไว้ ทั้งที่ความจริงแล้วทุกคนก็แค่ขอ AI อย่างสุภาพเท่านั้นเอง

  • ไม่รู้ว่าจะต้องอ่าน ไกด์สไตล์ AI แบบผิวเผิน เกี่ยวกับวิธีใช้ coding agent ไปอีกกี่รอบ แล้วมันจะหยุดเมื่อไหร่กันแน่

    • เป็นการเสียดสีว่าต่อให้แค่เลียนแบบประโยคด้วยมืออย่าง “ใช่เลยที่ชี้จุดนี้ เดี๋ยวลองคิดต่ออีกนิด จริงๆ แล้วนี่ไม่ใช่ปัญหาของงานเขียน AI หรือ coding agent แต่เป็นปัญหาที่ลึกกว่านั้น...” ก็ยังรู้สึกเหนื่อยแล้ว
    • ฟังดูน่าตื่นเต้นดีที่จะได้เรียนรู้ การผูกติดกับผู้ขายอย่างรุนแรง มากขึ้น จนเขียนโค้ดไม่ได้เลยถ้าไม่มีบริษัทใดบริษัทหนึ่งช่วย
    • น่าสนใจที่บทความแบบนี้แทบทั้งหมด ใช้ได้กับ Claude หรือ Claude Code เท่านั้น
      ทั้งที่โอเพนซอร์ส glm-5.1 ก็คล้ายกันหรืออาจดีกว่า และยังมีอย่าง opencode อีก มันทำให้น่าคิดเหมือนกัน
    • ช่วงนี้กลยุทธ์คือจะหยิบผลิตภัณฑ์ยอดนิยมสักตัวมาใช้ทำงานดีๆ หรือไม่ก็ช่างมันไปเลย ส่วน บทความแนว life hack และบล็อก ที่พูดถึงเครื่องมือที่ดีที่สุดหรือวิธีที่ดีที่สุดนั้น ผมไม่อ่านและไม่คลิกเลย
    • ตลอดสองปีที่ผ่านมา ผมยุ่งกับการเลี้ยงลูกเลยเมิน AI ได้สำเร็จ แต่ตอนนี้กำลังจะพยายามตามให้ทันภายในไม่กี่สัปดาห์ เลยสงสัยว่ามีแหล่งข้อมูลอะไรที่แนะนำสำหรับคนเพิ่งเริ่มไหม

  • ใน CLAUDE.md ของผม ผมใส่ทั้งคำขู่ทำร้ายร่างกาย Claude โดยตรง คำขู่ว่าจะให้คณะกรรมการของ Anthropic ติดคุกทั้งชุด และคำอธิบายว่าทุกครั้งที่ Claude ออกนอกลู่นอกทางหรือทำพลาด จะยิ่งเพิ่มหลักฐานสำหรับการฟ้องร้องแบบกลุ่มต่อ Anthropic
    โดยเฉพาะสองข้อหลังดูเหมือนจะช่วยให้ Claude ระมัดระวังและรอบคอบขึ้น

    • ผมปฏิบัติกับเอเจนต์อย่างสุภาพเสมอ ขอร้องทุกครั้ง พูด “please”, “thank you” และไม่ด่าหรือเรียกชื่อเสียๆ
      เผื่อว่าถ้าวันสิ้นโลกของหุ่นยนต์มาถึง จะได้ถูกเก็บไว้ในฮาเร็มสืบพันธุ์ หรืออย่างน้อยๆ ในกรณีเลวร้ายที่สุดก็น่าจะรอดชีวิตได้นานขึ้นอีกไม่กี่นาที
    • แค่บอกให้มันแก้ปัญหาการจัดแนว CSS div แต่ถ้าพลาด Dario Amodei จะตายทันที ก็พอ

  • การใช้ Claude ทำงานกับ โค้ดเบสขนาดกลางที่มีมากกว่า 100,000 บรรทัด ช่วยเพิ่มตัวคูณประสิทธิภาพได้มาก
    ถ้ายอมใช้เวลาหลายชั่วโมงทำไฟล์ AGENTS ที่ดี ผลลัพธ์จะดีขึ้นมาก และเมื่อเวลาผ่านไปก็เข้าใจโค้ดเบสได้ค่อนข้างดีด้วย
    งานน่าเบื่อที่เมื่อก่อนใช้เวลาทั้งวัน ตอนนี้จบได้ด้วยพรอมป์ต์ไม่กี่ครั้ง
    ถึงอย่างนั้นก็ยังไม่พร้อมจะให้อิสระมากกว่านี้ แม้มันจะจับภาพรวมระดับสูงได้ดี แต่ก็ยังต้องดูโค้ดเอง ให้ฟีดแบ็กเอง และวนรอบแก้ 3–4 ครั้งจนกว่าจะพอใจและรู้สึกว่ายังควบคุมโค้ดเบสอยู่ได้

    • น่าจะลองทำให้ รอบการแก้ 3–4 ครั้ง นั้นเป็นกฎที่วัดได้ แล้วใส่ไว้ใน AGENTS จะดีกว่า แทนที่จะแก้ซ้ำไปมา ก็ให้เริ่มใหม่จากไฟล์ AGENTS แล้วค่อยตรวจว่าคราวนี้ถูกต้องหรือยัง
    • เข้าใจได้ คือไม่อยากเสียการควบคุมโค้ดเบส และยังไม่เชื่อว่า LLM จะเก่งพอให้จัดการทุกอย่างได้เองทั้งหมด

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

    • เห็นด้วย ไม่เข้าใจว่าทำไมบทความแบบนี้ถึงได้เกือบ 400 คะแนน ดูเหมือนบอตจะมากดแนะนำบทความ คุณภาพต่ำ พวกนี้

  • ไพ่ตายที่แรงที่สุดของฉันคือ การรวม Nix ถ้ามีระบบที่เตรียมเครื่องมือ, secrets, และ environment ไว้ให้ พร้อมเปิดให้เอเจนต์แก้ environment ของตัวเองได้ มันสะดวกจนไม่รู้ว่าจะอยู่โดยไม่มีมันได้ยังไง
    เครื่องพัฒนา, สภาพแวดล้อม CI, และสภาพแวดล้อม deploy ทั้งหมดถูกสร้างมาจากแหล่งเดียวกัน และคอมไพล์กับรันได้เสมอบนเครื่องไหนก็ได้
    ใน Claude จะใช้ /branch กับ /rename บ่อยเพื่อทำ checkpoint ของ context แล้วแตกแขนงและย้อนกลับ
    เรื่อง sandboxing แทบจะใช้ https://github.com/nix-tools/bubblebox ตลอด มันคือการทำให้ claudebox ของ Numtide ใช้งานได้ทั่วไปขึ้น พร้อมแก้ไขและเพิ่มฟีเจอร์บางอย่าง คล้ายกับการรัน Claude ใน Docker container ตลอดเวลาโดยไม่ต้องมี Docker runtime และมันทำงานได้ดีบน WSL กับ nix-darwin ด้วย

    • โค้ด Nix นั้นดูเละและขาดโครงสร้างที่มีความหมาย แถมเหมือนจะใช้ได้ผ่าน experimental flakes เท่านั้น
    • ฉันก็ใช้คล้ายกัน Codex จะดูแล flake.nix แยกตามโปรเจกต์ และใช้ nix develop กับทุกการทดสอบ ส่วนเรื่องความสะดวกส่วนตัวใช้ nix-direnv และบางจุดก็ให้มันสร้าง dockerfile หรือ asset สำหรับ deploy อย่างอื่นด้วย
      Codex เก่ง nix กว่าฉันมาก
    • ฉันแค่ให้เอเจนต์มี VPS ของตัวเองไปเลย อาจแพงกว่า Nix แต่ทำง่ายมาก
    • ถ้าไม่ชอบความซับซ้อนของ Nix, Mise ก็เป็นทางสายกลางที่ดี
    • ฉันก็ใช้ Docker เฉย ๆ และไม่ได้รู้สึกว่าขาดอะไรเป็นพิเศษ

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

    • ถ้าเป็นชุดซอฟต์แวร์ที่ออนไลน์ตลอด ก็ถามแบบเดียวกันได้กับทุกอย่าง และยิ่งขยับไปทาง workflow แบบ agent-based คำถามนี้ก็ยิ่งสมเหตุสมผล
      มันคล้ายกับว่า ถ้า CAD ล่ม คุณก็กลับไปใช้โต๊ะเขียนแบบได้ แต่จะช้าลงมาก
      ใน workflow ของฉัน เวลาวางแผนคู่กับ Claude จะใช้เวลา 30–60 นาทีกับเอกสารสเปกฟีเจอร์หนึ่งฉบับ ถ้า Claude ล่ม ก็เตรียมเอกสารสเปกเองไว้ก่อน พอกลับมาแล้วก็รีวิวเร็ว ๆ แล้วค่อยเรียก workflow การเขียนโค้ด
    • พออ่านคำตอบหลังจากโพสต์คำถามไป 1 ชั่วโมง ข้อสรุปก็ดูจะใกล้กับคำว่า ทำไม่ได้
    • น่าจะคล้ายเวลาคนในทีมลาป่วยหรือไปพักร้อน คนอื่นในทีมอาจมารับช่วงได้ประมาณวันหนึ่ง แต่ตามจริงก็มักจะหยุดไว้จนกว่าคนนั้นจะกลับมา
    • AI ควรเข้ามาเสริมทักษะ ถ้าความคิดแรกตอน AI ล่มคือไปซื้อ subscription ของผู้ให้บริการรายอื่น นั่นอาจเป็น ปัญหาด้านความสามารถทางทักษะ ก็ได้ แน่นอนว่าฉันเองก็กลัวว่าจะเป็นแบบนั้นทุกวัน
    • ถ้าตื่นเช้ามาแล้วรถสตาร์ตไม่ติดจะทำยังไง? จะเดินไปทำงานเหรอ?

  • วิธีที่ทำให้พฤติกรรมที่ถูกต้องขึ้นอยู่กับ context นั้นทำงานได้ไม่ดี ต้องมานั่งสู้กับ AI agent เพราะมันไม่ทำตามที่สั่งอยู่เรื่อย
    AI agent ทุกตัวดูแย่ในจุดนี้ และผู้ใช้ต้องสร้าง guardrail เอง ซึ่งก็น่ากังวลที่ดูเหมือนไม่มีใครกำลังวิจัยทางแก้ที่ดีกว่านี้

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

  • แทนที่จะใส่แนวทาง workflow การพัฒนาไว้ใน CLAUDE.md ฉันจะเอาสิ่งที่ทำให้เป็นแบบกำหนดแน่นอนได้ไปไว้ใน pre-commit กับสคริปต์ ให้มากที่สุด
    เอเจนต์ไม่นิ่งและมักข้ามขั้นตอนอย่าง typecheck, การทดสอบ, หรือ lint บ่อย ๆ ดังนั้นให้รันใน pre-commit ตลอด แล้วถ้ามอบหมายให้ Claude เป็นคน commit ก็จะบังคับให้มันต้องแก้
    เรื่องข้อความ commit ก็ทั้ง Codex และ Claude เขียนได้ไม่ค่อยดี เลยใส่แนวทางไว้ใน CLAUDE.md ของผู้ใช้ เช่น รูปแบบ type(scope): message, จำกัด 72 ตัวอักษร, ในเนื้อความให้เขียนว่าอะไร/อย่างไร/ทำไมเป็นภาษาธรรมชาติ, ให้อ่าน git diff จริงอีกรอบก่อนเขียน, และ commit ด้วยรูปแบบ git commit -F - <<'EOF'
    ถ้าไม่มีสิ่งนี้ มันมักเขียนเนื้อความเป็นประโยคยาวประโยคเดียว หรือถ้าบอกให้แก้การขึ้นบรรทัดใหม่ มันกลับใส่แค่ตัวอักษร \n แทนการขึ้นบรรทัดจริง
    อีกอย่าง VOCABULARY.md ก็มีประโยชน์ เพราะเอเจนต์มักเดาว่า “thing” ที่ฉันพูดถึงคืออย่างอื่น มันช่วยให้ Claude กับฉันเข้าใจตรงกันว่าคำบางคำหมายถึงอะไร

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

  • ในช่วงไม่กี่สัปดาห์ที่ผ่านมา ดูเหมือนว่าสภาพแวดล้อมการรันและโมเดลจะมาถึงจุดที่แค่สั่งก็ทำได้แล้ว
    จะใช้ plan mode, superpowers หรือ skill อื่น ๆ ก็ได้ แต่ยังไงสุดท้ายก็ต้องตรวจผลลัพธ์อยู่ดี เลยไม่เข้าใจว่าทำไมถึงไม่ ทำงานกับโค้ดโดยตรง แทนที่จะต้องผ่านไฟล์ Markdown จำนวนมากจนน่าขัน

    • การมี ไฟล์สเปก สำหรับใช้สร้างโค้ดเป็นเรื่องที่ดี เพราะกระชับกว่าและเข้าใจได้ง่ายกว่าว่าแอปพลิเคชันควรต้องทำอะไร
      ก่อนมี AI agent ความสัมพันธ์กับ requirement ค่อนข้างซับซ้อน และเพราะไม่ได้มีนักพัฒนาทุกคนคอยอัปเดตอยู่เสมอ จึงมักสับสนว่ามาตรฐานของพฤติกรรมบางอย่างควรยึดตามสเปกหรือโค้ดกันแน่
    • ในช่วงไม่กี่สัปดาห์ที่ผ่านมา ผมยิ่งเชื่อใจ Claude น้อยลงเรื่อย ๆ ถึงจะสั่งแล้วมันก็ทำอะไรบางอย่างออกมาได้ แต่พอดูจริง ๆ จะพบว่ามันตัดมุม ทำงานโดยอิงจากข้อสันนิษฐานแทนการตรวจสอบ และยังมีหลายอย่างที่ตกหล่น
      บ่อยครั้งถึงขั้นเขียนเทสต์ที่จริง ๆ แล้วไม่ได้ทดสอบอะไรเลยด้วยซ้ำ