Apple ปิดบั๊กรายงานเองหากผู้ใช้ไม่ยืนยันด้วยตนเองว่า ‘ยังไม่ถูกแก้’

 (lapcatsoftware.com)
1 คะแนน โดย GN⁺ 2026-03-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Apple ปิดบั๊กที่ถูกรายงานผ่าน Feedback Assistant โดยอัตโนมัติ หากผู้ใช้ไม่ ยืนยัน (verify) ด้วยตนเองว่า “ยังไม่ได้รับการแก้ไข”
  • สำหรับ บั๊กการรั่วไหลของข้อมูลส่วนตัวที่เกี่ยวข้องกับส่วนขยาย network filter (FB12088655) ซึ่งไม่มีการตอบกลับมานาน 3 ปี Apple กลับมาขอให้ยืนยันกะทันหัน และหากไม่มีการตอบกลับภายใน 2 สัปดาห์จะถือว่าแก้ไขแล้ว
  • แต่ถึงแม้ว่า นักพัฒนา Little Snitch จะยืนยันว่าปัญหาเดิมยังคงอยู่ใน macOS เวอร์ชันล่าสุด Apple ก็ยังปิดรายงานดังกล่าว
  • ขั้นตอนนี้ทำงานในลักษณะของ โครงสร้างที่ลดจำนวนบั๊กรายงานลงอย่างไม่เป็นธรรมชาติ และส่งผลให้ปัญหาคุณภาพที่แท้จริงถูกบดบัง
  • ผลลัพธ์คือ วิธีจัดการบั๊กของ Apple บั่นทอนความเชื่อมั่นของนักพัฒนา และถูกชี้ว่าเป็นปัญหาที่ขัดขวางวัฒนธรรมการให้ฟีดแบ็กแบบร่วมมือกัน

ปัญหาการปิดบั๊กรายงานอัตโนมัติของ Apple

  • นักพัฒนาที่รายงานบั๊กผ่าน Apple Feedback Assistant วิจารณ์แนวปฏิบัติของ Apple ที่ปิดรายงานเองโดยไม่ต้องมีการยืนยันจากผู้ใช้
    • Apple จะ ปิดรายงานโดยอัตโนมัติ หากผู้ใช้ไม่ยืนยันด้วยตนเองว่า “บั๊กยังไม่ได้รับการแก้ไข”
    • หลังจากเงียบหายไปหลายปี จู่ๆ ก็ส่งคำขอให้ยืนยัน และหากไม่มีการตอบกลับภายใน 2 สัปดาห์จะถือว่า “แก้ไขเสร็จแล้ว”
  • ในกรณีของ FB12088655 “Privacy: Network filter extension TCP connection and IP address leak” ที่ส่งไปเมื่อเดือนมีนาคม 2023 Apple ไม่ตอบกลับนาน 3 ปี ก่อนจะมาขอให้ยืนยันบน macOS 26.4 beta 4 ในเดือนมีนาคม 2026
    • ผู้รายงานไม่ได้ติดตั้งเบต้า OS ไว้ตลอดเวลา จึงตรวจสอบได้ยาก และเมื่อสอบถาม Apple ว่าแก้ไขแล้วหรือไม่ก็ ไม่ได้รับคำตอบที่ชัดเจน
    • Apple แจ้งว่า “หากไม่ยืนยันภายใน 2 สัปดาห์ จะถือว่าได้รับการแก้ไขแล้วและจะปิดรายงาน”
    • นักพัฒนา Little Snitch รายงานว่าสามารถทำให้ปัญหาเดิมเกิดซ้ำได้แม้ใน macOS 26.4 beta 4
    • และใน macOS 26.4 เวอร์ชันจริงก็ยังคงมีบั๊กเดียวกันอยู่
  • การที่ Apple เรียกร้องให้ผู้ใช้ยืนยันด้วยตนเองสำหรับบั๊กที่ยังไม่ได้รับการแก้ไข ถูกชี้ว่าเป็น ขั้นตอนที่ไม่มีประสิทธิภาพและไม่สมเหตุสมผล
    • มีการกล่าวถึงความเป็นไปได้ว่า ภายในองค์กรอาจมี โครงสร้างแรงจูงใจเพื่อทำให้จำนวนบั๊กรายงานลดลง
    • ส่งผลให้จำนวน “บั๊กที่ยังเปิดอยู่” ลดลง และทำให้ดูเหมือนคุณภาพดีขึ้นในตัวชี้วัดภายใน

กรณีบั๊กรายงานอื่น ๆ

  • อีกกรณีหนึ่งคือบั๊ก FB22057274 “Pinned tabs: slow-loading target="_blank" links appear in the wrong tab”
    • แม้จะเป็นปัญหาที่เกิดซ้ำได้ 100% แต่ Apple กลับระบุว่า “การตรวจสอบเสร็จสิ้น - ไม่สามารถวินิจฉัยได้จากข้อมูลปัจจุบัน (Investigation complete - Unable to diagnose with current information)”
    • เมื่อมีการขอข้อมูลเพิ่มเติมในวันที่ 9 มีนาคม Apple ก็ไม่ตอบกลับ
  • ใน iPadOS 26.4 beta ยังเกิด บั๊ก Safari แครช ขึ้นใหม่ และ Apple ก็ ไม่ได้แก้ไขก่อนปล่อยเวอร์ชันสาธารณะ
    • ผู้เขียนวิจารณ์ว่า “ดูเหมือนจุดประสงค์ของเบต้าไม่ใช่เพื่อแก้บั๊ก แต่เพื่อทำให้คนที่รายงานบั๊กรำคาญมากกว่า”

การเปลี่ยนแปลงหลังขึ้นหน้าแรก Hacker News และการตอบสนองของ Apple

  • ทันทีหลังจากบทความนี้ขึ้นหน้าแรกของ Hacker News Apple ก็อัปเดตรายงาน FB22057274
    • Apple ขอให้ส่ง sysdiagnose log สำหรับปัญหา UI
    • ผู้เขียนชี้ว่าได้ส่ง ขั้นตอนการทำให้เกิดปัญหาซ้ำและวิดีโอบันทึกหน้าจอ ไปแล้ว และ sysdiagnose เป็น ข้อมูลที่ไม่จำเป็นและมีความเสี่ยงด้านความเป็นส่วนตัว
  • ผู้เขียนตอบกลับคำขอของ Apple ดังนี้
    • “บั๊ก UI ไม่จำเป็นต้องใช้ sysdiagnose และมันไม่ได้ช่วยอะไร”
    • โดยเสนอวิธีที่ทำให้ปัญหาเกิดซ้ำได้ โดยไม่ต้องใช้ Little Snitch คือใช้ Network Link Conditioner ใน Xcode Additional Tools เพื่อตั้งค่าโปรไฟล์อัปโหลดล่าช้า 3000ms ก็จะเห็นอาการเดียวกัน

คำแนะนำเกี่ยวกับ Xcode Additional Tools

  • Xcode Additional Tools มียูทิลิตีที่มีประโยชน์หลายอย่างรวมอยู่ด้วย และ สามารถดาวน์โหลดได้จากหน้า Apple Developer Downloads (ต้องล็อกอิน)

การประเมินโดยรวม

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

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

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

 
GN⁺ 2026-03-27
ความคิดเห็นจาก Hacker News

  • ดูเหมือนว่าผู้เขียนคงไม่เคยเจอกับ ซอฟต์แวร์องค์กร
    เวลาโปรแกรมเมอร์ได้รับบั๊กรายงาน ก็มักใช้มุกคลาสสิกแบบ “ผมยังทำให้เกิดซ้ำไม่ได้ คุณลองบนเวอร์ชันล่าสุดหรือยัง?” แล้วก็ถ่วงเวลาโดยไม่ทำอะไร
    ถ้ายืนยันไม่ได้ก็จะปิดเป็น “ผู้ใช้ทำผิด” หรือ “ทำซ้ำไม่ได้”
    วิธีรับมืออย่างเดียวคือบอกว่า “ครับ/ค่ะ ตรวจสอบแล้ว” ทั้งที่จริงไม่ได้ตรวจสอบ

    • ผมเคยใช้บริการซัพพอร์ตแบบเสียเงินของ Microsoft ซึ่งพวกเขาจะขอ หลักฐานประกอบ ตลอด
      ถ้าในล็อกเห็นแอนติไวรัส ก็จะปิดเรื่องทันทีพร้อมบอกว่า “ไปถามฝั่งนั้นสิ”
    • ถ้ามองจากภายใน มันอาจไม่ใช่ความมุ่งร้าย แต่เป็นเรื่องของ ประสิทธิภาพเทียบกับต้นทุน
      เพราะมีลำดับความสำคัญทางธุรกิจที่สำคัญกว่าบั๊กที่ผู้ใช้คนเดียวแจ้งเข้ามาอีกมาก
      ถึงอย่างนั้น ในมุมผู้ใช้ก็น่าเสียดายอยู่ดี
    • ในโอเพนซอร์สก็เหมือนกัน stalebot จะปิด issue เก่า ๆ อัตโนมัติ
    • ผมเลยได้เรียนรู้วิธีทำ GIF สำหรับรีโปรดิวซ์ปัญหา ให้ดีพอจะใส่ในอีเมลได้ทันที
      นักพัฒนาส่วนใหญ่ไม่รู้วิธีทดสอบผลิตภัณฑ์ของตัวเอง หรือไม่ก็ขี้เกียจทำ
    • ผมเคยอยู่มาทั้งสองฝั่ง
      ตอนทำซัพพอร์ตเทคนิคสำหรับองค์กร ผมต้องรับเคสใหม่อย่างน้อยวันละสองเคส และดูแลพร้อมกันเกิน 20 เคส
      ความโล่งใจเวลาปิดเคสที่ไม่มีความคืบหน้าเป็น “ปิดเพราะไม่มีการใช้งาน” นั้นมากจริง ๆ
      ต่อมามีกฎว่าต้องติดต่อสามครั้งก่อนปิด กลายเป็นฝันร้ายไปเลย
      สุดท้ายแล้ว ระบบราชการของบริษัทยักษ์ใหญ่ ทำทุกอย่างพัง

  • Apple มีท่าทีเหมือน ภาวนาให้บั๊กหายไปเอง
    ตอนนี้ผมก็ไม่ส่งบั๊กรายงานแล้ว
    โดนเมินยังพอรับได้ แต่ปัญหาคือพวกเขาปฏิบัติกับผมเหมือนเป็น QA ที่ไม่ได้รับเงิน
    โดยคาดหวังให้ผมทุ่มแรงมหาศาลเพื่อพิสูจน์ว่าบั๊กมีอยู่จริง

    • Microsoft ก็คล้ายกัน โดยเฉพาะกับปัญหาที่เกี่ยวกับ Azure หรือ 365
      เหมือนคิดว่า “นี่คือซอฟต์แวร์ของคุณ งั้นคุณก็ไปดีบักเองสิ”

  • โปรเจกต์โอเพนซอร์สก็ทำแบบเดียวกัน คือ ปิด issue ที่ stale อัตโนมัติ
    การถือว่าแก้แล้วโดยอัตโนมัติเพียงเพราะเวลาผ่านไปช่วงหนึ่งมันไม่สมเหตุสมผลเลย

    • ในมุมผู้ดูแลโปรเจกต์ ลำดับความสำคัญอาจต่างออกไป
      ข้อดีของโอเพนซอร์สคือคุณแก้เองได้ ส่ง PR ได้ หรือจะ fork ไปแก้เองก็ได้
    • ถ้า stalebot ไม่ได้ปิด แต่แค่ ติดป้าย stale ไว้ก็ยังพอรับได้
      การกรองตั๋วเก่า ๆ น่าจะสมเหตุสมผลกว่า

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

    • เมื่อก่อนผมเคยทำงานเชื่อม Mac เข้ากับ ActiveDirectory และคำตอบประจำของ Apple คือ “works on 17!”
      ซึ่งจริง ๆ หมายความว่าในเครือข่ายภายในของ Apple มันไม่เกิดปัญหา
    • บางคนก็บอกว่า “เปิดทิ้งไว้เฉย ๆ ไม่ได้หรือ?”
      การปิดก็แค่เป็นการซ่อนปัญหา และ การเปิดค้างไว้ไม่ได้มีต้นทุน
    • Apple ไม่ได้บอกว่า “ทำซ้ำไม่ได้” หรือ “แก้แล้ว” แต่แค่บอกให้ไปลองบน “macOS 26.4 beta 4”
      การต้องติดตั้งเบต้านั้นไม่มีประสิทธิภาพสำหรับผู้ใช้ยิ่งกว่าเดิม
      ผมให้ทั้งโปรเจกต์ตัวอย่าง Xcode และขั้นตอนรีโปรดิวซ์ครบแล้ว
      ผมมั่นใจว่า Apple ไม่ได้ทำอะไรเลย
      น่าจะเป็นการ โชว์เคลียร์บั๊ก เพื่อเตรียม macOS 27 ก่อน WWDC มากกว่า
    • ถ้าเป็นบริษัทอย่าง Apple ก็ควรมีเครื่องมือที่ จับสถานะของระบบได้ครบถ้วน เพื่อเอาไปรีโปรดิวซ์ได้

  • ตอนทำงานที่ Facebook กับ Google ผมเห็น ลูกเล่นในการจัดการบั๊ก มาเยอะ
    หลังมี SLA ก็มีการลดความสำคัญของบั๊กลงแบบประดิษฐ์ หรือโยนกลับให้ผู้ใช้ด้วยคำถามว่า “ยังเป็นปัญหาอยู่ไหม?”
    พอเวลาผ่านไปก็บอกว่า “เวอร์ชันนั้นเลิกใช้แล้ว” แล้วปิดทิ้ง
    บางทียังฝืน รวม เข้ากับบั๊กอื่นเพื่อเลี่ยงความรับผิดชอบอีกด้วย
    สุดท้ายเรื่องพวกนี้ก็มาจาก ตัวชี้วัดผลงานขององค์กร (SLA)
    เพราะงั้นตอนนี้ผมแทบไม่ส่งบั๊กรายงานแล้ว

    • จริง ๆ แล้ววิศวกรอยากแก้บั๊กนะ
      แต่ฝ่ายบริหารสั่งว่า “ตอนนี้ให้โฟกัสโปรเจกต์ AI”
      แล้วก็ยังมาบ่นอีกว่า “ทำไมบั๊กเยอะจัง”
    • ผมเองก็เคยลด p2/s2 ลงเป็น p3/s3
      ผมคิดว่าการเมินเฉยเฉย ๆ ยังซื่อสัตย์กว่าการปิดทิ้ง
      ฝ่ายผู้นำผลักดันให้เกิด การไตรเอจแบบบังคับ ในลักษณะนี้
      การบล็อกการแจ้งเตือนอัตโนมัติเป็นปัญหา
    • เหตุผลที่แยก priority กับ severity ก็เพราะว่า
      เช่น ต่อให้เว็บไซต์ล่มทั้งเว็บ แต่ถ้าช่วงนี้เป็น นอกฤดูกาลใช้งาน ก็อาจไม่ใช่ P0
      แต่ในทางปฏิบัติคุณภาพข้อมูลมักแย่จนเอาไปทำรายงานไม่ได้
      ดังนั้นการมีค่าความสำคัญเดียวจึงใช้งานได้จริงกว่า
      stalebot ก็เลยเหมือนเข้ามาปิด issue ที่ถูกเมินเหล่านี้แทน
    • ที่บริษัทยักษ์ใหญ่ที่ผมเคยอยู่ก็คล้ายกัน
      เขาแยก severity สำหรับลูกค้า กับ priority ภายในองค์กรออกจากกัน
      Salesforce “Lightning Experience” ช้า มาก ทั้งที่ชื่อดูเหมือนจะเร็ว
      เครื่องมือภายในกลับเร็วและมีประสิทธิภาพกว่ามาก
    • ทั้งหมดนี้เป็นตัวอย่างคลาสสิกของ ปัญหาตัวแทน (principal-agent problem)

  • ที่ ElevenLabs ก็มีเรื่องแบบเดียวกัน
    พอส่งบั๊กรายงานไป AI จะตอบกลับอัตโนมัติ แล้วภายใน 48 ชั่วโมงก็ถูกทำเป็น stale

    • มีพนักงานของ ElevenLabs เข้ามาบอกว่า ถ้าส่งผ่าน GitHub โอเพนซอร์สรีโพซิทอรี จะมีคนมาตอบเอง

  • อีกไม่นาน LLM agent น่าจะแก้ปัญหาพวกนี้ได้
    มันอาจคอมเมนต์อัตโนมัติว่า “ยังไม่ถูกแก้” และคอย bump อัตโนมัติ เป็นระยะ ๆ ว่า “สิ่งนี้กระทบกับเวิร์กโฟลว์สำคัญ”

    • ถ้าผู้ดูแลปิด issue เอเจนต์ก็อาจโพสต์ บทความบล็อกวิจารณ์ อัตโนมัติได้เหมือนกัน

  • ผมเคยส่งบั๊กให้ Microsoft แล้วหลายเดือนต่อมาก็ได้รับคำตอบว่า “ทำซ้ำไม่ได้”
    ที่จริงในช่วงนั้นมันถูกแก้ทางอ้อมจากการแก้อื่นไปแล้ว
    ทำให้ผมตระหนักว่าตัวเองเป็นเหมือน คนตาบอดที่คลำได้แค่ส่วนหนึ่งของช้าง

  • ผมเป็นอดีตพนักงาน Apple
    ตัวติดตามบั๊กภายในของ Apple เรียกว่า Radar และทุก issue ต้องผ่านขั้นตอน “Verify” ก่อนถึงจะปิดได้
    ภายนอกดูเหมือนเป็นกระบวนการประกันคุณภาพ แต่ในความเป็นจริง Radar จำนวนมากจะค้างอยู่ในสถานะ Verify ตลอดกาล
    ทีมต่าง ๆ ถูกประเมินจาก “จำนวน Radar ที่ยังไม่ verify” จึงมักปิดทิ้งแบบบังคับหลังเวลาผ่านไปช่วงหนึ่ง

    • ทีมส่วนใหญ่ใช้ Verify เป็นเหมือน สถานะ Closed โดยพฤตินัย
      ภาพลวงตาว่า “ไม่มีบั๊กเลย” ทำให้เกิด ตัวชี้วัดผลงานที่บิดเบี้ยว
    • ทางแก้คือควรวัด “จำนวนบั๊กที่ถูกเปิดใหม่” ไปพร้อมกันด้วย
    • ข้อความใน Feedback Assistant ที่ว่า “ลองตรวจสอบบนเบต้าล่าสุด” เป็นคนละเรื่องกับสถานะ Verify ของ Radar
      จึงไม่ควรตีความว่า Apple engineer ได้พยายามแก้จริงแล้ว

  • ที่บริษัท ผมเคยเข้าประชุมกับเพื่อนร่วมงานเพื่อ เคลียร์ backlog
    และจัดการบั๊กเก่า ๆ ที่เกิดครั้งเดียวแล้วจบ
    กระบวนการแบบนี้พบได้ทั่วไปมาก