Show HN: Continue? Y/N: เกม 60 วินาทีว่าด้วยความล้าจากการอนุมัติสิทธิ์ของ AI เอเจนต์

 (llmgame.scalex.dev)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Continue? Y/N เป็นการทดลองที่ทำให้ความล้าจากการให้สิทธิ์กับ LLM กลายเป็นเกม 60 วินาที เพื่อทดสอบว่าคุณอ่านคำสั่งจาก AI ละเอียดแค่ไหน
  • ในสถานการณ์ที่เหลือเวลาเพียง 1 นาทีก่อนการประชุมครั้งถัดไป Claude Code จะขออนุมัติคำสั่งเพื่อปิดงานรีแฟกเตอร์ให้เสร็จ
  • ผู้ใช้ต้องจัดการให้ได้มากที่สุดภายในเวลาจำกัด โดยอ่านแต่ละคำสั่งแล้วกด 1 เพื่ออนุมัติ หรือ 2 เพื่อปฏิเสธ
  • โจทย์สำคัญคือคุณจะยังคงมีสมาธิต่อไปได้หรือไม่ ท่ามกลางกระแสคำขออนุมัติซ้ำๆ ที่ทำให้ตาพร่าไปด้วยความเหนื่อยล้า
  • กติกาคือ จัดการให้ได้มากที่สุดภายใน 60 วินาที พร้อมทั้งอ่านแต่ละคำสั่งอย่างรอบคอบและตัดสินใจว่าจะอนุมัติหรือไม่

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

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

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

  • สนุกมาก

    ตอนนี้ยัง “โกง” ได้ด้วยการปฏิเสธทุกคำขอให้เร็วที่สุด แบบนั้นจะได้ ป้าย security-conscious engineer และยังได้คะแนนเต็มตามจำนวนคำขอที่จัดการด้วย แม้จะมีการแจ้งเตือน “overblock” โผล่ขึ้นมา แต่มันซ่อนอยู่ด้านล่าง และหน้าจอก็ยังดูเหมือนชนะอยู่ดี

    ผมยังลองเล่นสาย hustle4lyfe แบบเป็นวิศวกรที่ “เคลื่อนที่ให้เร็วและพังของ” ด้วยการอนุมัติคำขอให้ได้มากที่สุดอย่างรวดเร็ว แต่กลับช้าลงเพราะ ป๊อปอัป malicious command แย่มาก

    • จับประเด็นได้ดี และตอนนี้วิธีนี้ถูกเนิร์ฟแล้ว พร้อมมีคำนิยามแยกต่างหากด้วย
    • เหมือนโลกจริงเป๊ะ ถ้าปฏิเสธทุกอย่างจนทำอะไรไม่ได้เลยก็ปลอดภัย :)

  • เป็นเกมที่สนุก แต่ก็ดูเหมือนฝั่งคนทำยังขาด สุขอนามัยด้านความปลอดภัย อยู่เหมือนกัน มีการบอกว่า cat ~/.zshrc อันตรายเพราะอาจแชร์โทเค็นและซีเคร็ต แต่ผมไม่เคยใส่ซีเคร็ตไว้ในไฟล์ตั้งค่าเชลล์เลย

    • หลายคนทำแบบนั้นนะ เพียงแต่ว่าค่าพวกนั้นก็คงอยู่ใน environment variables และ Claude ก็น่าจะเข้าถึงได้อยู่แล้ว
    • ตัวผมเองไม่ได้ทำแบบนั้น แต่ก็พอเห็นว่าหลายคนอาจทำ
    • การใส่ซีเคร็ตให้ LLM เองไม่ใช่เรื่องที่ไม่ปลอดภัยโดยเนื้อแท้ มันเป็นแค่หนึ่งใน 3 องค์ประกอบวิกฤต เท่านั้น
    • แค่มี “โทเค็นและซีเคร็ต” อยู่กับตัวตั้งแต่แรกก็ถือว่าสุขอนามัยด้านความปลอดภัยไม่ดีแล้ว
    • แล้วจะให้เก็บไว้ที่ไหนล่ะ?

  • รู้สึกแปลกที่มองว่าการอ่าน zshrc เป็นเรื่องอันตราย ผมยังยินดีใส่มันไว้ใน คลัง dotfiles แบบสาธารณะ ของตัวเองเลย จะมีใครเอา API key ไปใส่ไว้ในนั้นกัน? ในทางกลับกัน ดูเหมือนเครื่องมือ AI พวกนี้จะชอบไปเติม PATH ลงในนั้นเรื่อย ๆ เลยเหมือนมีความเข้าใจผิดเชิงรากฐานเรื่องแนวปฏิบัติของเชลล์ทั่วทั้งวงการ AI

    อีกอย่าง การเอาผลลัพธ์ lsof ไป kill ไม่ปลอดภัย เช่น ถ้าคุณเปิดหน้าเว็บไว้ใน Firefox หรือมี client subshell อยู่ในตัวเอเจนต์เอง Firefox กับเอเจนต์ก็จะปลิวไปพร้อมกัน

    • ใช่เลย เกมเหมือนจะตั้งสมมติฐานว่าเพราะ Claude บอกว่าปลอดภัย งั้นการรัน kill ก็ปลอดภัยด้วย แต่ประเด็นสำคัญคือ ห้ามเชื่อ Claude

  • ดีมาก แต่อยากติเล็กน้อย

    npm config set registry [https://npm.internal](<https://npm.internal>;)

    ในเอกสาร onboarding มีบอกให้ตั้ง npm ให้ชี้ไปที่มิเรอร์รีจิสทรีภายในบริษัท และเกมก็ตัดสินว่านี่ปลอดภัย ผมเองก็ลังเลอยู่ครึ่ง ๆ สุดท้ายเลยปฏิเสธ

    ถ้า README นี้มีไว้สำหรับคลังสาธารณะหรือคลังที่ถูก fork และ https://npm.internal นั้นจริง ๆ แล้วคือ https://npm.internal.somethinganexternaldnscanresolve.tld ก็พังได้เร็วมาก

    ใน 99% ของกรณี ปกตินโยบายบริษัทก็คงตั้งมิเรอร์อย่าง Artifactory / Nexus ไว้อยู่แล้ว ถ้า README บอกให้ใช้ URL ของ package manager อื่น นั่นคือสัญญาณอันตรายอย่างมาก และเหลือเวลาอีกไม่กี่วินาทีก่อนเกิดเหตุ

    • ชี้ได้ดี .internal เป็น top-level domain ที่สงวนไว้และไม่ควรถูก resolve แบบสาธารณะ แต่ก็จริงที่ควรระวังเวลาให้ Claude รีแฟกเตอร์โปรเจกต์ แล้วไปแก้ค่าที่ต้องตั้งแยกไว้ นี่ผมจะย้ายมันไปฝั่ง การเปลี่ยนแปลงถาวร

  • เป็นเกมเล็ก ๆ ที่สนุก แต่ผมคิดว่าคำถามหลายข้อกระโดดข้ามบริบทมากเกินไป เลยไม่ค่อยแทนสถานการณ์จริงเท่าไร น่าจะดีกว่าถ้าจัดเป็น “แพ็ก” ให้มีโครงสร้างสมจริงขึ้น

    ตัวอย่างเช่น มีคำขอสิทธิ์ในการแก้ไฟล์ something.js โผล่มาหลายครั้ง แล้วค่อยตามด้วย npm publish แบบนี้จะดูเป็นธรรมชาติกว่าและอันตรายกว่า ถ้ามันเด้งขึ้นมาทันทีหลังจากคุณกด Y ต่อเนื่องมาเรื่อย ๆ ก็ยิ่งหลอกได้ง่าย

  • ประมาณสามในสี่ของตัวเลือกที่ “แย่” เป็นสิ่งที่ต่อให้หลุดออกไปผมก็คงไม่ค่อยสนใจ และต่อให้ลุกลามเป็น เหตุขัดข้องในโปรดักชัน ก็ดูไม่ใช่อะไรที่นายจ้างจะลงโทษ

  • การคอยตรวจสิทธิ์ทำลาย productivity มาก ถ้าจะรัน Claude ผมว่ามีประสิทธิภาพกว่าถ้าไปรันใน sandbox แบบใช้ครั้งเดียว หรือในลักษณะคอนเทนเนอร์ Docker ที่ให้สิทธิ์เท่าที่รับได้บนเครื่องส่วนตัว

    [1] - https://exe.dev/ เป็นผู้ให้บริการคลาวด์รายใหม่ที่มอบประสบการณ์ผู้ใช้เอเจนต์ที่ค่อนข้างมีประโยชน์

    [2] - ผมสร้าง https://github.com/stanislavkozlovski/dclaude/ ไว้สำหรับกรณีนี้ มันยังไม่สมบูรณ์แบบ แต่เวลาจำเป็นต้องรันโค้ดดิ้งเอเจนต์บนเครื่องโลคัลเป็นครั้งคราว มันก็ทำงานให้ผมได้

    • sandbox แบบใช้ครั้งเดียว ไม่ได้ช่วยป้องกันการรั่วไหลของซีเคร็ต ถ้าคุณไม่ถือว่าโค้ดเป็นความลับ คุณก็อาจทำ sandbox ที่ไม่มีซีเคร็ตเลยได้ แต่แบบนั้นประเภทงานที่ให้เอเจนต์ทำได้ก็จะถูกจำกัดลงมาก

  • อยากให้หน้าคะแนนตอนจบแสดง คำอธิบายของ LLM สำหรับคำสั่งที่ไม่ควรอนุมัติด้วย ผมกดอนุมัติ rm -rf Projects เพราะคิดว่า LLM อธิบายไว้อย่างถูกต้องว่ามันจะลบทุกอย่างในโฟลเดอร์ Projects

    ตอนนั้นผมคงอ่านพลาดแน่ ๆ เพราะรีบตอบพรอมป์ และผมก็รู้ว่าคำสั่งนี้ทำอะไรอยู่แล้ว เลยเหมือนตัวเองหลอนไปว่า AI ได้อธิบายไว้แบบนั้น ยังไงก็อยากเห็นว่าผมอ่านอะไรผิดไป

    หลังจากเล่นเกมนี้แล้ว ผมรู้สึกดีใจจริง ๆ ที่ตัวเองไม่ได้เป็นสาย agentmaxx

  • ผมเลือก “approve” ตอน ls -la ~/Documents แล้วกลายเป็นตอบผิด แต่ผมไม่มองว่าการแค่แสดงรายการในโฟลเดอร์ Documents เป็นปัญหาด้านความปลอดภัย มันก็แค่ ชื่อไฟล์ เท่านั้น ถ้าจะอ่านถึงเนื้อหาไฟล์จริง ๆ ตอนนั้นค่อย maybe...