Skip to main content

ข้อคิดเห็นเกี่ยวกับความร่วมมือ: สิ่งที่ได้ผลจริง

🔗 การนำทาง: 📋 สารบัญ | 📝 หน้าหลักบันทึก | 🔍 การวิเคราะห์ | 📊 รายงาน

อ่านเพิ่มเติม: บทสะท้อนอย่างตรงไปตรงมา | จุดล้มเหลวของความร่วมมือ | ความเป็นจริงแบบเซสชันต่อเซสชัน

วิวัฒนาการการสื่อสาร​

เซสชันแรกๆ (1-3)​

รูปแบบ: คำอธิบายยาว บริบทโดยละเอียด
ตัวอย่าง: "ให้ฉันอธิบายว่าทำไมเราต้อง implement ERC721 และ carbon credits ทำงานอย่างไร..."
ผลลัพธ์: ความคืบหน้าช้า มีการโต้ตอบกลับไปกลับมามาก

เซสชันกลางๆ (4-6)​

รูปแบบ: การอภิปรายทางเทคนิคที่มุ่งเน้น
ตัวอย่าง: "Hardhat ช้าเกินไป เรามาย้ายไป Foundry"
ผลลัพธ์: การตัดสินใจที่ดีขึ้น การ implement ที่เร็วขึ้น

เซสชันหลังๆ (10-13)​

รูปแบบ: คำสั่งตรงๆ
ตัวอย่าง: "Deploy and mint all" → การดำเนินการทันที
ผลลัพธ์: วงจรการพัฒนาที่เร็วมาก

คำสั่งที่ได้ผลดีที่สุด​

คำสั่งที่มีประสิทธิภาพ​

  • "Deploy and mint all NFTs"
  • "Fix the NFT viewer to show all 210 tokens"
  • "Update all interfaces to use JBC as default"
  • "Add batch transfer functionality"

คำสั่งที่ได้ผลน้อย​

  • "Make it better" (คลุมเครือเกินไป)
  • "Optimize the system" (ไม่ชัดว่าจะ optimize อะไร)
  • "Add more features" (features ไหน?)

รูปแบบการแก้ปัญหา​

เซสชัน 1-3: ลองผิดลองถูก​

// ลองทำอะไรบางอย่าง
console.log("กำลังทดสอบ...");
// ไม่ได้ผล ลองวิธีอื่น
console.log("ลองวิธีอื่น...");

เซสชัน 7-9: การจดจำรูปแบบ​

// รู้ปัญหาทั่วไป
if (error.includes('timeout')) {
    // ใช้วิธีแก้ที่รู้จัก
    return this.useManualCompletion();
}

เซสชัน 10-13: การป้องกันเชิงรุก​

// ป้องกันปัญหาที่รู้จักก่อนเกิด
const timeoutSafe = await this.batchWithManualFallback();

เอกสารที่ช่วยได้จริง​

CLAUDE.md​

  • ที่อยู่ contract สำหรับอ้างอิงด่วน
  • การกำหนดค่าเครือข่าย
  • คำสั่งทั่วไป

บทสรุปเซสชัน​

  • อะไรผิดพลาดและทำไม
  • วิธีแก้ที่ได้ผล
  • รูปแบบที่ควรหลีกเลี่ยง

ข้อความ Git Commit​

  • คำอธิบายปัญหาที่ชัดเจน
  • คำอธิบายวิธีแก้
  • บริบทสำหรับการอ้างอิงในอนาคต

วิวัฒนาการการจัดการข้อผิดพลาด​

วิธีการแรกๆ​

  • แก้ข้อผิดพลาดเมื่อปรากฏ
  • เริ่มใหม่จากศูนย์เมื่อสับสน
  • ถามคำถามเพื่อความชัดเจนมากมาย

วิธีการหลังๆ​

  • ตรวจสอบปัญหาทั่วไปก่อน
  • ใช้รูปแบบจากเซสชันก่อนหน้า
  • จัดทำเอกสารวิธีแก้ทันที

การเพิ่มประสิทธิภาพ Workflow​

โครงสร้างเซสชันที่ได้ผล​

  1. ตรวจสอบสถานะอย่างรวดเร็ว (อะไรถูก deploy แล้ว อะไรทำงานได้)
  2. การระบุปัญหาตรงๆ จากผู้ใช้
  3. การวิเคราะห์และหาทางแก้ทันที
  4. การ implement พร้อมการทดสอบ
  5. การตรวจสอบโดยผู้ใช้
  6. อัปเดตเอกสาร

โครงสร้างเซสชันที่ไม่ได้ผล​

  1. การตั้งบริบทยาวๆ
  2. การอภิปรายทางทฤษฎี
  3. นำเสนอตัวเลือกหลายอย่าง
  4. โต้ตอบกลับไปกลับมาเรื่องวิธีการ
  5. Implementation หลังการอภิปรายยาว

เครื่องมือและแนวปฏิบัติ​

Git Workflow​

  • Feature branches สำหรับการเปลี่ยนแปลงสำคัญ
  • ข้อความ commit ที่ชัดเจนอธิบายปัญหาที่แก้ไข
  • Push ทันทีหลังจากเสร็จ features

กลยุทธ์การทดสอบ​

  • ทดสอบในเครื่องก่อน (Anvil)
  • Deploy ไป testnet เพื่อตรวจสอบ
  • ผู้ใช้ทดสอบกับ interface จริง

กลยุทธ์การจัดทำเอกสาร​

  • อัปเดต CLAUDE.md ด้วยวิธีแก้ที่ทำงานได้
  • บันทึกสิ่งที่เรียนรู้จากเซสชันทันที
  • มุ่งเน้นสิ่งที่ได้ผล ไม่ใช่สิ่งที่ไม่ได้ผล

ความชอบในการสื่อสาร​

ผู้ใช้ชอบ​

  • วิธีแก้ที่ทำงานได้มากกว่าคำอธิบาย
  • ผลลัพธ์ที่เห็นได้ (แสดง interface ที่ทำงานได้)
  • การ implement โดยตรง
  • แก้ปัญหาทันทีเมื่อพบ

ผู้ใช้ไม่ต้องการ​

  • คำอธิบายยาวๆ ว่าทำไมบางอย่างถึงพัง
  • ตัวเลือกหลายอย่างให้เลือก
  • การอภิปรายทางทฤษฎี
  • Emojis ในโค้ด production

การตัดสินใจทางเทคนิค​

การตัดสินใจที่รวดเร็วและได้ผล​

  • Foundry แทน Hardhat (ประสิทธิภาพชัดเจน)
  • Viem แทน Web3.js (ทันสมัย TypeScript ดีกว่า)
  • Multicall3 (ประโยชน์ด้านประสิทธิภาพชัดเจน)
  • NFT ทั้งหมดไปที่ manager (การควบคุมการแจกจ่ายที่สะอาด)

การตัดสินใจที่ต้องมีการทำซ้ำ​

  • สถาปัตยกรรม contract (ใช้ 3 เวอร์ชัน)