Cursor Annotate (Design Mode): ชี้บน UI แทนการพิมพ์อธิบาย ช่วย design review ได้แค่ไหน

คนที่เคยทำ design review น่าจะคุ้นกับ feedback แบบนี้ครับ "ปุ่มตรงนั้นดูแปลก ๆ" "ช่องว่างข้างบนเยอะไป" "ทำให้มันดูพรีเมียมขึ้นหน่อย" ทั้งจากลูกค้า จาก PM และบางทีก็จากตัวผมเอง ปัญหาไม่ใช่ว่าคนให้ feedback ผิด แต่ข้อความแบบนี้แปลงเป็นงานไม่ได้ dev ต้องเดาว่า "ตรงนั้น" คือตรงไหน และ "แปลก" คือแปลกยังไง

พอเราเริ่มส่งงาน UI ให้ agent ทำ ปัญหานี้ก็ยังอยู่ แค่ย้ายจากคนมาเป็นเครื่อง agent ต้องเดาจากคำว่า "การ์ดอันที่สองในหน้า pricing" ว่าหมายถึง component ไหนในโค้ด

ช่วงนี้มีหัวข้อเรื่อง Cursor ขึ้น trending ใน X เกี่ยวกับการทิ้งโน้ตบน UI ให้ agent แก้ ผมเลยตามไปอ่านเอกสารของ Cursor ว่าฟีเจอร์นี้ทำอะไรได้จริง และมันเปลี่ยนวิธีส่งต่องาน UI แค่ไหน

โพสต์นี้อยู่ในซีรีส์ Critical Thinking ต่อจากAnthropic เลิก coding interview จริงไหม ครับ ส่วน Design Mode เวอร์ชันแรก ผมเคยสรุปสั้น ๆ ไว้ตอนเขียนเรื่องCursor 3.0

จุดยืนของผมสั้น ๆ คือ การชี้บนหน้าจอแก้ปัญหา "ตรงไหน" ได้ดีมาก แต่ไม่ได้แก้ปัญหา "ทำไม" กับ "แค่ไหนถึงเรียกว่าเสร็จ" สองข้อหลังยังเป็นงานของคน

แหล่งต้นทาง: อะไรที่ผมยืนยันได้ และอะไรที่ยืนยันไม่ได้

ยืนยันไม่ได้

• หน้า trending ของ X ผมเปิดอ่านไม่ได้ เลยไม่รู้ว่าสรุปในหน้านั้นเขียนว่าอะไร และจะไม่อ้างถึงเนื้อหาในนั้น
• หน้า release notes ของ Cursor ยาวมาก ผมอ่านได้คำต่อคำเฉพาะบางช่วง รายการเรื่อง Design Mode ในเวอร์ชัน 3.24 และ 3.25 (เช่น CSS inspector และการเลือก parent element ด้วยปุ่มลูกศร) ผมเห็นแค่จากสรุป ยังไม่ได้เทียบกับข้อความจริง เลยไม่อ้างเลขเวอร์ชันของสองเรื่องนี้ ส่วนตัวฟีเจอร์ ผมอ้างจากหน้าเอกสารแทน
• ผมยังไม่ได้ลองทุกฟีเจอร์ในโพสต์นี้ด้วยตัวเอง ส่วนที่เป็นวิธีใช้ในงานจริงข้างล่างคือวิธีที่ผมจะใช้และสิ่งที่ผมจะตรวจ ไม่ใช่ผลที่ผมวัดมาแล้ว

ยืนยันได้

ผมอ่านจากหน้าของ Cursor เองสี่หน้าครับ

• เอกสาร Design Mode ไม่ระบุวันที่ เป็นแหล่งหลักเรื่องวิธีใช้
• บล็อก "Direct agents with visual prompts in Design Mode" ลงวันที่ 5 มิถุนายน 2026 โดย Erik Nilsson, Ian Huang และ Ryo Lu
• Changelog 3.0 วันที่ 2 เมษายน 2026 ที่เปิดตัว Design Mode ใน Agents Window
• Changelog "Design Mode Improvements" เวอร์ชัน 3.7 วันที่ 5 มิถุนายน 2026 ที่เพิ่ม multi-select และการพูดสั่ง

ประโยคเปิดของหน้าเอกสารสรุปไอเดียไว้ตรงที่สุดครับ

Design Mode lets you direct agents by leaving notes on your running app.

เรื่องชื่อต้องระวังนิดหนึ่ง เอกสารเรียกฟีเจอร์รวมว่า Design Mode แต่ปุ่มที่กดเรียกว่า Annotate และบอกว่า "Annotate is available in Cursor 3.24.18 or later." ส่วนเวอร์ชันก่อนหน้าจะเห็นเป็นปุ่มรูปปากกาชื่อ Design Mode แทน ถ้าใครเปิดแล้วไม่เจอปุ่ม Annotate ให้เช็กเวอร์ชันก่อนครับ

ฟีเจอร์นี้ทำอะไรได้ ตามเอกสาร

ส่วนนี้ผมสรุปจากเอกสารและ changelog ยังไม่ใส่ความเห็นครับ

เปิดใช้ที่ไหน อยู่ในเบราว์เซอร์ของ Cursor ใน Agents Window กดปุ่ม Annotate บน toolbar ของเบราว์เซอร์ หรือกด Cmd + Shift + D ตอนที่เบราว์เซอร์ถูกโฟกัสอยู่

ชี้ได้สี่แบบ

• คลิก element เพื่อเปิดโน้ต ก่อนคลิกกดลูกศรขึ้นลงเพื่อขยับไปเลือก parent หรือ child ได้ ซึ่งช่วยตอนที่ element ที่อยากได้ถูกลูกของมันบังอยู่
• multi-select กด Shift ค้างแล้วคลิกหลาย element ให้อยู่ในโน้ตเดียว changelog 3.7 บอกว่าใช้กับงานแบบทำให้อันหนึ่งเหมือนอีกอัน ลบเนื้อหาที่ซ้ำ หรือปรับทั้งกลุ่ม
• ลากกรอบพื้นที่ เอกสารเขียนว่า "Drag across the page to box in an area, then describe the change." และมีเครื่องมือวาด วงรี สี่เหลี่ยม และลูกศร ให้ขีดบนหน้าได้
• แก้ข้อความตรงนั้นเลย ดับเบิลคลิกที่ข้อความเพื่อแก้ Return เพื่อบันทึก Esc เพื่อย้อน และ "Text edits always wait for Send" คือแก้ข้อความแล้วจะยังไม่ส่งจนกว่าจะกดส่ง

นอกจากนี้ในโน้ตของ element เดียว มีปุ่ม Edit CSS properties เปิด CSS inspector ให้แก้ค่า CSS แล้วส่งไปพร้อมโน้ต และพูดแทนพิมพ์ได้ changelog 3.7 บอกว่าไมค์ยังใช้ได้ระหว่างที่ agent ทำงานอยู่ เพื่อพูดคิวงานถัดไปไว้

ส่งทีละโน้ต หรือรวมส่ง สวิตช์ Batch edits เริ่มต้นเป็นปิด ถ้าปิด กด Return แล้วโน้ตนั้นไปถึง agent ทันที ถ้าเปิด โน้ตจะเก็บเป็นหมุดมีหมายเลข แล้วกด Send ครั้งเดียวส่งทั้งหมด ส่วนโน้ตที่ส่งระหว่าง agent ยังทำงานอยู่ เอกสารบอกว่าจะถูกจัดการเหมือน follow-up ที่พิมพ์ต่อในแชทตามปกติ

agent ได้อะไรไปบ้าง ตรงนี้คือหัวใจของฟีเจอร์ครับ ตามเอกสาร แต่ละโน้ตส่งรายละเอียดของ element ไปด้วย ได้แก่ tag, id, class, attribute, selector path แบบ CSS, ข้อความที่มองเห็นได้ 200 ตัวอักษรแรก, ขนาดและตำแหน่ง และ computed style หกค่า (สีตัวอักษร สีพื้นหลัง ขนาดฟอนต์ ฟอนต์ display และ position) รวมถึง screenshot ที่ครอปเฉพาะ element หรือพื้นที่ที่วาดไว้ และ

In React, Vue, and Svelte apps, the details include the component name and component stack, so the agent can find the source.

บล็อกของ Cursor อธิบายต่างไปเล็กน้อย คือบอกว่ามี xpath และ props จาก fiber tree ด้วย และบอกว่าตอนวาดบนหน้า "The annotation sits over a frozen frame of the viewport" คือ agent เห็นหน้าจอในสภาพเดียวกับตอนที่เราขีด ซึ่งเอกสารไม่ได้พูดถึงทั้งสองเรื่องนี้ ผมถือว่าเอกสารเป็นตัวอ้างอิงหลักครับ เพราะบล็อกเขียนในวันเปิดตัวรอบอัปเดต และรายละเอียดอาจเปลี่ยนไปแล้ว

แยกคำโฆษณาออกจากข้อเท็จจริง

บล็อกเปิดตัวมีประโยคที่เป็นเป้าหมายของทีม Cursor ครับ

Design Mode, which we're updating today, is part of how we're shrinking the distance between what you see and what the agent understands.

ผมว่าเป้าหมายนี้ตรงกับปัญหาจริง แต่ขอแยกสามเรื่องที่เป็นคำของผู้ขายไว้

• "multitask ง่ายขึ้น" บล็อกบอกว่า Design Mode "makes managing multiple subagents possible" ข้อนี้เป็นคำอธิบายของ Cursor ไม่มีตัวเลขว่าเร็วขึ้นแค่ไหน หรือผิดน้อยลงแค่ไหน
• โมเดลที่แนะนำ ทั้งบล็อกและเอกสารแนะนำ Composer 2.5 ซึ่งเป็นโมเดลของ Cursor เอง บล็อกเขียนว่า "Composer 2.5 excels at this because it is both fast and strong at interface work." ผมไม่มีข้อมูลเทียบกับโมเดลอื่น เลยไม่สรุปตามนี้
• ไม่มีข้อมูลผลลัพธ์ ทั้งสี่หน้าไม่มีตัวเลขว่า agent แก้ถูกตั้งแต่ครั้งแรกบ่อยแค่ไหนเมื่อใช้โน้ตแบบนี้ เทียบกับพิมพ์อธิบายเอง

ข้อที่ยืนยันได้คือกลไก ว่าโน้ตส่งข้อมูลอะไรไปบ้าง ส่วนผลว่าดีขึ้นแค่ไหน ยังเป็นคำบอกเล่าของคนทำเครื่องมือครับ

มันช่วยอะไร จากมุม design review

จากตรงนี้ไปเป็นความเห็นของผมครับ

แก้ปัญหา "ตรงไหน" ได้จริง feedback UI ที่เสียเวลาที่สุดมักไม่ใช่ feedback ที่ยาก แต่เป็น feedback ที่ชี้ไม่ชัด การคลิกแล้ว agent ได้ selector, ชื่อ component และ screenshot ไปพร้อมกัน ตัดขั้นตอนเดาว่า "การ์ดอันที่สอง" คือไฟล์ไหนออกไปได้ทั้งขั้น สำหรับแอป React ที่ component ซ้อนกันหลายชั้น ข้อมูล component stack น่าจะช่วยมาก เพราะ element ที่เห็นบนจอมักไม่ได้อยู่ในไฟล์ที่ชื่อตรงกับมัน

ทำให้ feedback อยู่บนของจริง ไม่ใช่บนภาพนิ่ง design review ที่ผมเจอบ่อยคือรีวิวกันบน mockup แล้วไปเจอปัญหาจริงตอนข้อมูลจริงเข้า ข้อความยาวกว่าที่คิด รูปสัดส่วนไม่ตรง การชี้บนแอปที่รันอยู่บังคับให้เราคุยกันบนหน้าที่ผู้ใช้จะเห็นจริง

multi-select ตรงกับภาษาที่คนรีวิวใช้ feedback จำนวนมากเป็นเรื่องความสัมพันธ์ เช่น "ปุ่มนี้ควรหน้าตาเหมือนปุ่มนั้น" "สองการ์ดนี้ควรสูงเท่ากัน" การเลือกหลายตัวแล้วบอกความสัมพันธ์ ใกล้กับวิธีที่ designer คิดมากกว่าการแก้ทีละจุด

แก้ข้อความเองได้ ลดรอบที่ไม่จำเป็น คำผิด ป้ายปุ่มที่ไม่ตรง ข้อความ error ที่ลูกค้าอยากเปลี่ยนคำ เป็นงานที่ทุกวันนี้ต้องเขียน ticket ส่งต่อ ถ้า PM หรือ PO แก้ข้อความบนหน้าจอแล้วส่งไปให้ agent ทำต่อได้ งานเล็กพวกนี้น่าจะหายจาก backlog ได้เยอะ

Batch edits เหมาะกับรอบรีวิว ผมชอบที่ค่าเริ่มต้นคือปิด แต่ในรอบ design review ผมจะเปิดไว้ครับ เพราะ feedback หลายข้อมักเกี่ยวกัน ถ้าส่งทีละข้อ agent อาจแก้ข้อแรกแบบที่ทำให้ข้อสามต้องแก้ใหม่ การเก็บให้ครบแล้วส่งรวมทำให้ agent เห็นภาพทั้งหมดก่อนลงมือ อันนี้เป็นการคาดของผม ยังไม่ได้วัด

handoff ระหว่าง PM, designer, dev และ agent เปลี่ยนยังไง

ในทีมที่ผมดูแล งาน UI เดินแบบนี้มาตลอด designer ทำแบบ PM เขียน ticket dev ทำ แล้ว designer หรือ PM มารีวิวรอบสุดท้าย ซึ่งรอบสุดท้ายมักเป็นรอบที่ feedback ไหลกลับมาเป็นข้อความยาว ๆ ใน chat พร้อม screenshot ที่วงด้วยสีแดง

Annotate ทำให้ขั้นสุดท้ายนี้สั้นลงได้ครับ คนรีวิวชี้บนหน้าจอแล้วโน้ตไปถึง agent ตรง ๆ แต่ผมว่ามีสามเรื่องที่ต้องคิดก่อนเปิดให้ทุกคนใช้

ใครเป็นคนกดส่ง ถ้า PM หรือ designer ส่งโน้ตให้ agent แก้โค้ดได้เอง dev จะกลายเป็นคนตรวจผล แทนที่จะเป็นคนรับ feedback นั่นอาจดีกับงานเล็ก แต่ถ้าไม่ตกลงกันก่อน dev จะเจอ diff ที่ไม่รู้ว่ามาจาก feedback ข้อไหน และไม่รู้ว่าใครอนุมัติ ผมจะตกลงกันว่าโน้ตจากคนที่ไม่ใช่ dev ต้องผ่าน dev ก่อน merge เสมอ

feedback ที่หายไปจากระบบติดตามงาน ทุกวันนี้ feedback อยู่ใน ticket ย้อนดูได้ว่าใครขออะไร พอ feedback ไปอยู่ในโน้ตบนหน้าจอแล้วกลายเป็นข้อความในแชทกับ agent ทันที ประวัติของการตัดสินใจจะไปอยู่ในแชท ซึ่งคนอื่นในทีมอาจไม่เห็น สำหรับงานลูกค้าที่ต้องตอบได้ว่าเปลี่ยนเพราะใครขอ ผมยังอยากให้ feedback ที่เปลี่ยนพฤติกรรมหรือ scope มี ticket อยู่ครับ

ชี้ได้แม่นขึ้น ไม่ได้แปลว่าขอได้ถูกขึ้น ข้อนี้สำคัญที่สุด ลูกค้าที่บอกว่า "ทำให้ดูพรีเมียมขึ้น" ถ้าได้เครื่องมือนี้ไป ก็จะคลิกที่การ์ดแล้วพิมพ์ว่า "ทำให้ดูพรีเมียมขึ้น" เหมือนเดิม agent รู้แล้วว่าการ์ดไหน แต่ยังไม่รู้ว่าพรีเมียมแปลว่าอะไร และมันจะเลือกให้เรา ซึ่งเป็นปัญหาเดียวกับที่ผมเขียนไว้ในการรับ requirement จากลูกค้าที่ยังไม่ครบ เครื่องมือย้ายความกำกวมจาก "ตรงไหน" ไปอยู่ที่ "อะไร" ไม่ได้ทำให้มันหายไป

ข้อจำกัดที่ต้องรู้ก่อนใช้

บางข้อมาจากเอกสาร บางข้อเป็นการคาดของผมจากวิธีที่มันทำงาน ผมแยกไว้ในแต่ละข้อครับ

• ใช้ได้ในเบราว์เซอร์ของ Cursor ใน Agents Window เท่านั้น (จากเอกสาร) ไม่ใช่ extension ใน Chrome ที่ลูกค้าเปิดอยู่ คนรีวิวต้องมี Cursor เวอร์ชันที่รองรับ และต้องเปิดแอปผ่าน Cursor สำหรับลูกค้าที่ไม่ได้ใช้ Cursor ฟีเจอร์นี้ใช้ตรง ๆ ไม่ได้ คนในทีมต้องเป็นคนแปล feedback ลงไปเอง
• ต้องมีแอปที่รันอยู่ (จากเอกสาร ส่วนที่เป็น dev server เป็นการตีความของผม) เอกสารพูดถึงการทิ้งโน้ตบน "running app" และบอกว่าถ้า dev server hot reload การเปลี่ยนแปลงจะขึ้นตอน agent ทำเสร็จ ในทางปฏิบัติแปลว่าคนรีวิวต้องมีโปรเจกต์ที่รันบนเครื่องได้ ซึ่งสำหรับ PM หรือ designer หลายคนไม่ใช่เรื่องเล็ก ทั้งการติดตั้ง environment ข้อมูลทดสอบ และ secret ต่าง ๆ
• canvas tab ทำได้น้อยกว่า (จากเอกสาร) ใน canvas tab ยังเป็นปุ่มปากกาแบบเดิม โน้ตไปที่แชทตรง ๆ ไม่มี Batch edits และแก้ข้อความในหน้าไม่ได้
• screenshot และข้อความบนหน้าถูกส่งไปกับโน้ต (กลไกจากเอกสาร ส่วนผลด้านความเป็นส่วนตัวเป็นการคาดของผม) โน้ตส่งทั้ง screenshot และข้อความที่มองเห็นของ element ไปเป็น context ของ agent ถ้าหน้าที่รีวิวมีข้อมูลลูกค้าจริง ชื่อ เบอร์โทร ยอดเงิน ข้อมูลพวกนั้นก็ไปด้วย ก่อนใช้กับโปรเจกต์ลูกค้า ผมจะเช็กนโยบายข้อมูลของ Cursor และสัญญากับลูกค้าก่อน และรีวิวด้วยข้อมูลทดสอบเท่านั้น
• agent ยังต้องผ่าน code review และ QA (ความเห็นของผม) โน้ตที่ชี้แม่นทำให้ agent เริ่มถูกที่ แต่ไม่ได้รับประกันว่ามันแก้ถูกวิธี การแก้ CSS ที่ element เดียวอาจทำให้หน้าอื่นที่ใช้ component เดียวกันเปลี่ยนตาม หรือ agent อาจแก้ด้วยค่าตายตัวแทน design token ที่มีอยู่ หน้าจอที่ดูถูกต้องตรงจุดที่ชี้ ไม่ได้แปลว่าทั้งระบบถูกต้อง ผมเขียนเรื่องนี้ไว้ละเอียดในGreen Check ไม่ได้แปลว่าถูก
• เห็นแค่สภาพหน้าจอตอนนั้น (การคาดของผม) โน้ตบันทึกหน้าจอขนาดเดียว สถานะเดียว ถ้า feedback เป็นเรื่องที่ต้องดูหลายขนาดจอ หรือหลายสถานะ เช่น ตอนโหลด ตอนว่าง ตอน error การชี้ครั้งเดียวไม่พอ ต้องบอก agent ให้ชัดว่าต้องรองรับสถานะไหนบ้าง

design review ที่ยังไม่พร้อม QA

มีอีกเรื่องที่ผมอยากแยกไว้ครับ ในทีม junior ผมเจอบ่อยว่างานถูกส่งมา "ให้ดู design" ทั้งที่ยังไม่พร้อม QA เช่น ปุ่มยังกดไม่ได้ ข้อมูลยังเป็น mock สถานะ error ยังไม่ได้ทำ

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

วิธีที่ผมจะใช้คือแยกรอบให้ชัดครับ รอบ design review ใช้ Annotate ชี้ได้เต็มที่ แต่ทุกคนรู้ว่ายังไม่ใช่รอบตรวจรับ ส่วนรอบ QA ยังใช้ acceptance criteria ที่เขียนไว้ก่อน ไม่ใช่ใช้ความรู้สึกว่า "ดูดีแล้ว" ซึ่งเป็นเหตุผลเดียวกับที่ผมเขียนไว้ในยุค agent = คุณต้องเขียน AC เหมือน PO คือการชี้บอก agent ได้ว่าต้องแก้ตรงไหน แต่ AC เป็นตัวบอกว่าแก้แล้วถือว่าผ่านหรือยัง

ถ้าผมจะเขียนโน้ตให้ agent

ผมคิดว่าโน้ตที่ดีบน Annotate ยังต้องมีสามส่วนเหมือน feedback ที่ดีทั่วไปครับ การคลิกตอบส่วนแรกให้แล้ว อีกสองส่วนยังต้องพิมพ์หรือพูดเอง

1. ตรงไหน การคลิก การเลือกหลายตัว หรือการลากกรอบ ส่วนนี้เครื่องมือช่วยเต็มที่
2. เปลี่ยนเป็นอะไร บอกเป็นค่าหรือเป็นตัวอ้างอิง เช่น "ให้ใช้ระยะห่างเท่ากับการ์ดด้านซ้าย" หรือ "ใช้สี primary จาก theme" ดีกว่า "ทำให้ห่างกว่านี้"
3. ขอบเขตแค่ไหน แก้เฉพาะหน้านี้ หรือแก้ที่ component ซึ่งจะกระทบทุกหน้า ข้อนี้ agent เดาเองไม่ได้ และเป็นข้อที่ผิดแล้วเสียหายที่สุด

ตัวอย่างสมมตินะครับ ไม่ใช่งานจริง แทนที่จะคลิกปุ่มแล้วพิมพ์ว่า "ปุ่มเล็กไป" ผมจะเลือกปุ่มนั้นพร้อมปุ่มหลักในหน้าเดียวกัน แล้วพิมพ์ว่า "ให้ปุ่มนี้ขนาดเท่าปุ่มหลัก แก้เฉพาะหน้านี้ ห้ามแก้ component Button กลาง ถ้าต้องแก้ component ให้หยุดและถามก่อน"

Checklist ก่อนใช้ Annotate กับงานจริง

ก่อนเริ่ม

• Cursor เป็นเวอร์ชัน 3.24.18 ขึ้นไป ถ้าจะใช้ปุ่ม Annotate และทุกคนที่รีวิวใช้เวอร์ชันใกล้กัน
• คนรีวิวรันโปรเจกต์บนเครื่องได้ หรือมีคนในทีมเปิดให้ในรอบรีวิว
• หน้าที่จะรีวิวใช้ข้อมูลทดสอบ ไม่มีข้อมูลลูกค้าจริงที่จะติดไปกับ screenshot
• เช็กแล้วว่าสัญญาและนโยบายข้อมูลของลูกค้าอนุญาตให้ส่ง screenshot ของงานเข้าเครื่องมือ AI
• ตกลงกันแล้วว่ารอบนี้คือ design review หรือ QA

ตอนเขียนโน้ต

• ทุกโน้ตบอก "เปลี่ยนเป็นอะไร" ไม่ใช่แค่ "ตรงนี้ไม่ดี"
• บอกขอบเขตว่าแก้เฉพาะจุด หรือแก้ที่ component กลาง
• อ้างอิง design token หรือ element อื่นในหน้าแทนค่าที่คิดเอง
• feedback ที่เกี่ยวกันส่งรวมด้วย Batch edits แทนการส่งทีละข้อ
• feedback ที่เปลี่ยนพฤติกรรมหรือ scope ยังมี ticket ไม่ได้อยู่แค่ในแชทกับ agent

หลัง agent แก้

• ดู diff ว่า agent แก้ไฟล์ไหน และแก้ component กลางหรือเปล่า
• เปิดหน้าอื่นที่ใช้ component เดียวกัน ดูว่าไม่มีอะไรเปลี่ยนตามโดยไม่ตั้งใจ
• ดูหลายขนาดจอและหลายสถานะ ไม่ใช่แค่สภาพที่ชี้ไว้
• dev ที่รับผิดชอบโค้ดส่วนนั้น review ก่อน merge แม้โน้ตจะมาจาก PM หรือ designer
• ผ่าน acceptance criteria ไม่ใช่แค่ "ดูเหมือนที่ชี้ไว้แล้ว"

ท้ายที่สุด

ผมว่า Annotate เป็นเครื่องมือที่ตรงกับปัญหาจริงครับ ช่องว่างระหว่าง "สิ่งที่คนรีวิวเห็น" กับ "สิ่งที่คนแก้เข้าใจ" เป็นต้นเหตุของรอบแก้งาน UI จำนวนมาก และการส่ง selector, component stack กับ screenshot ไปพร้อมโน้ตเป็นวิธีปิดช่องนั้นที่สมเหตุสมผล ส่วนข้อที่ว่าช่วยได้มากแค่ไหน ตอนนี้ยังเป็นคำของ Cursor เอง ยังไม่มีตัวเลขให้ดู

สิ่งที่ผมเก็บไว้คือการแยกให้ออกว่าเครื่องมือแก้ปัญหาส่วนไหน การชี้แก้ปัญหา "ตรงไหน" แต่ feedback ที่แย่ส่วนใหญ่ไม่ได้แย่เพราะชี้ไม่ถูก มันแย่เพราะไม่รู้ว่าอยากได้อะไร และไม่รู้ว่าแค่ไหนถึงพอ สองข้อนี้ต้องมาจากคนที่เข้าใจผู้ใช้และลูกค้า ไม่ว่าจะส่งผ่านเครื่องมืออะไรก็ตาม

ก่อนกดส่งโน้ตให้ agent ผมจะถามตัวเองข้อเดียวครับ "ถ้าส่งโน้ตนี้ให้ dev ที่เป็นคน ไม่ใช่ agent เขาจะแก้ได้ถูกโดยไม่ต้องถามกลับไหม" ถ้าคำตอบคือไม่ได้ การคลิกให้แม่นขึ้นก็ไม่ได้ช่วยอะไรครับ