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

ขอบคุณที่อ่านครับ! เมื่อก่อนมีหลายอย่างที่คนต้องคอยใส่ใจเองโดยตรง ไม่ว่าจะเป็นเอกสาร เทสต์เคส การตรวจสอบต่าง ๆ แต่ตอนนี้พอสามารถทำหลายส่วนร่วมกับ AI coding agent ได้แล้ว ก็รู้สึกว่าการดูแลโอเพนซอร์สเองมีความยากในการบริหารลดลงกว่าสมัยก่อนมากกว่าที่คิดครับ!

@xguru ดูเหมือนว่าลิงก์จะผิดนะครับ~

ใช่ครับ ถ้าดูแค่ประวัติคลิปบอร์ด ก็มีส่วนที่ทับซ้อนกันเยอะครับ แต่ Raycast มีฟีเจอร์อื่น ๆ อีกมากนอกจากคลิปบอร์ด เลยรู้สึกว่ามันเยอะเกินไปหน่อย

สิ่งที่ผมให้ความสำคัญมีประมาณนี้ครับ

อย่างแรกคือให้เบา และจัดการเฉพาะประวัติคลิปบอร์ดเท่านั้น ตอนนี้ขนาดประมาณ 2 MB ครับ

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

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

ต่อไปอยากให้สามารถเพิ่มฟีเจอร์หรือการจัดวางเองผ่านปลั๊กอินได้ แต่ส่วนนี้ยังไม่ได้กำหนดรายละเอียดชัดเจนครับ

ผมก็คิดว่า Raycast เป็นแอปที่ดีครับ และอยากพยายามให้เป็นตัวเลือกตามความชอบของแต่ละคนได้

ขอบคุณสำหรับความคิดเห็นครับ

สิ่งที่ยากที่สุดในเครื่องมือแบบนี้ไม่ใช่ฝั่งที่สะสมข้อมูล แต่เป็นฝั่งที่ทิ้งข้อมูล ซึ่งจุดที่แยก garden ออกมาเป็น lifecycle ต่างหากนั้นน่าสนใจครับ

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

เลยสงสัยว่าในหน้าเพจมีการระบุไหมว่าอิง ณ เวลาใด และเขียนขึ้นจากหลักฐานอะไร การเลือกเก็บเป็น Markdown ไว้ใน repository แล้วให้รีวิวผ่าน Git ผมมองว่าถูกทางในแง่นั้น แต่สิ่งที่เหลืออยู่ใน diff คือเวลาที่เอกสารถูกเปลี่ยน ไม่ใช่เวลาที่เนื้อหานั้นยังคงถูกต้องอยู่ครับ

ถ้าแค่ 1,700 รายการ เรื่องประสิทธิภาพแทบไม่มีความหมายแล้วครับ จะประมวลผลโดยตรงฝั่งฟรอนต์เอนด์หรือมีแบ็กเอนด์ก็แสดงผลได้ทันทีทั้งคู่ ดังนั้นผมคิดว่าเกณฑ์ตัดสินใจไม่ใช่เรื่องความเร็ว แต่คือจะต้องเขียนตรรกะ Python ที่มีอยู่ใหม่หรือไม่มากกว่า

ถ้าดูตามเกณฑ์นี้ Streamlit เหมาะที่สุดครับ สามารถ import ตรรกะการแมตช์มาใช้ได้เลย ส่วนหน้าจอก็มีแค่ selectbox 5 อันกับตารางผลลัพธ์ก็จบ ไม่ต้องเขียนโค้ดฟรอนต์เอนด์ ถ้าอัปขึ้น Streamlit Community Cloud ก็ได้ลิงก์แชร์ได้ฟรี และถ้าตั้งให้อ่าน JSON ตอนรันไทม์ แค่เปลี่ยนไฟล์ก็สะท้อนข้อมูลล่าสุดได้

HTML แบบสแตติก deploy ง่ายกว่าก็จริง แต่ต้องย้ายตรรกะ Python ไปเป็น JS ถ้าการคำนวณคะแนนซับซ้อนแม้แต่นิดเดียว เวลาก็จะหมดไปกับการ port ตรงนั้นหลายวัน ถ้าเป้าหมายคือแสดงให้เห็นว่ามันทำงานได้ภายในสัปดาห์นี้ ผมว่าไม่ควรแบกรับความเสี่ยงนั้นครับ

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

ดูเหมือนว่าจะรองรับฟีเจอร์เกือบทั้งหมดที่มีใน Raycast แล้ว ไม่ทราบว่ามีจุดไหนที่แตกต่างกันบ้างครับ?

โอ้... ในโพสต์ Show GN ผมอยากเห็นอินไซต์แบบนี้ควบคู่ไปกับการบอกว่า “ทำอะไรขึ้นมา” อยู่เสมอ พอได้เห็นโพสต์แบบนี้แล้วตื่นเต้นเลยครับ 555

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

แม้จะเป็น public benchmark ก็เพิ่งเคยเห็นตัวเลขที่เจาะจงขนาดนี้เป็นครั้งแรกครับ ขอบคุณมากครับ

สัดส่วน 159 กรณี / 76 กรณี / 3,197 กรณี สะดุดตาเป็นพิเศษ กรณีที่ตัดสินไม่ได้ (ไม่มี ID) มีจำนวนมากอย่างท่วมท้น — สุดท้ายก็หมายความว่าความซ้ำซ้อนส่วนใหญ่อยู่ในช่วงที่ตามรอยกันไม่ได้ตั้งแต่แรก และยืนยันอีกครั้งว่าห้ามอุ่นใจเพียงเพราะคิดว่า "มี audit log ก็พอ"

แนวทางที่ให้ความสำคัญกับการสร้าง (POST) ก่อนนั้นตรงกับการออกแบบของเราอย่างพอดี เหตุผลที่เราตั้งใจจะใส่ idempotency key กับ event การสร้างก่อนใน hash chain ก็เพราะจุดนี้นี่เอง

ข้อเสนอเรื่อง email message ID ผมจะนำไปปรับใช้ทันทีเลยครับ แค่เพิ่มข้อกำหนดว่า "การตอบกลับต้องมี entity ID เสมอ" ในสเปกของเครื่องมือภายใน ก็ทำให้ความสามารถในการตรวจสอบย้อนหลังของ audit log เปลี่ยนไปมากจริง ๆ ครับ ถ้าใช้ ID เป็น anchor ใน hash chain ก็ตรวจสอบได้จากการคำนวณเลยว่าเกิดรายการซ้ำหรือไม่

ไม่ทราบว่าพอจะทราบไหมครับว่าเคส "ไม่มี ID" จำนวน 3,197 กรณีนั้นกระจุกอยู่กับเครื่องมือประเภทไหนบ้าง? นอกจากอีเมลแล้ว ผมอยากทราบว่ามีเครื่องมือที่คืนมาแค่ "สำเร็จ/ล้มเหลว" อยู่มากแค่ไหนครับ

ตอนนี้กำลังปรับแต่งอยู่ ถ้าเสร็จภายในสัปดาห์นี้ก็น่าจะดูเรียบร้อยขึ้นอีกหน่อย :)

คุณเพิ่มฟีเจอร์สลับเป็นภาษาเกาหลีให้แล้วสินะครับ :)
ขอบคุณมากจริง ๆ ครับ

ผมก็ดีใจมากเหมือนกันที่ได้เจอคนที่ทำอะไรคล้าย ๆ กันครับ!

แม้ก่อนยุค Claude จะมาถึง ผมก็เคยทุ่มเวลากับ Rust ค่อนข้างมาก ทั้งทำ API และ CLI ด้วย Rust ครับ!

ผมเพิ่งคิดได้ไม่นานว่าควรแทนที่ tmux ดังนั้นแม้จะเพิ่งเลิกใช้ tmux จริง ๆ ได้ไม่นาน แต่ก็เคยทำ multiplexer เอง และตั้งแต่วันที่สองก็พยายามลดการใช้ tmux ให้น้อยที่สุดครับ!
ตรงนี้นอกจากเรื่องความสมบูรณ์ของงานแล้ว ผมคิดว่าอีกเหตุผลใหญ่คือถ้ามี fallback ไปยังเครื่องมืออื่นที่ไม่ใช่เครื่องมือที่ผมทำเอง มันกลับกลายเป็นที่หลบภัย ทำให้ผมไม่ตั้งใจพัฒนาต่อเท่าที่ควรครับ

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

แล้วเมื่อเทียบกับโปรแกรมอย่าง orca ที่ได้รับการสนับสนุนจากบริษัท เรื่องแรงจูงใจของโปรเจกต์ที่ทำแบบส่วนตัวนั้น ผมกลับมองในแง่บวกครับ
แน่นอนว่าไม่มีแรงจูงใจอะไรใหญ่เท่ากับการมีภาระทางการเงินเพิ่มขึ้น แต่ผมปรับ workflow ทั้งหมดให้เข้ากับเครื่องมือที่ผมใช้เองไว้แล้ว ดังนั้นถ้าผมจะทำงานตอนนี้ ผมก็อยู่ในสถานะที่ต้องปรับปรุงเครื่องมือนี้ จึงพยายามแบ่งเวลาส่วนตัวให้มากที่สุดมาลงกับการปรับปรุงเครื่องมือเหล่านี้ครับ
แน่นอนว่ามีปัญหาว่าทุกอย่างจะจบลงทันทีที่แรงจูงใจของผมหายไป แต่เพื่อป้องกันสถานการณ์นั้น ผมจงใจปรับ workflow ของตัวเองให้เหมาะกับเครื่องมือของผมไว้ เพื่อพยายามหลีกเลี่ยงไม่ให้เกิดแบบนั้นครับ!
ส่วนตัวแล้ว ตอนนี้ผมก็ยังคิดว่าสิ่งที่ด้อยกว่าเครื่องมือคู่แข่งไม่ใช่ด้านเทคนิค แต่มีแค่ด้านการตลาดเท่านั้น ดังนั้นการเปิดเผยออกมาเพื่อรับฟีดแบ็กก็น่าจะเป็นเหตุผลสำคัญมากครับ

ที่ทำ GPU rendering นั้นไม่ใช่เพื่อรองรับ Windows มากกว่า แต่เป็นความท้าทายทางเทคนิคและการปรับแต่งประสิทธิภาพสำหรับโปรแกรมที่ใช้พื้นที่หน้าจอเทอร์มินัลเต็ม ๆ ครับ
ส่วนตัวผมไม่ได้ใช้ Windows เพื่อการพัฒนามานานแล้ว จึงยังไม่ได้คิดลึกเรื่องการรองรับ OS นี้ แต่ตอนนี้ดูเหมือนว่าพื้นฐานจะมีค่อนข้างพร้อมแล้ว เลยคิดว่าน่าจะลองท้าทายดูสักครั้งครับ

เป้าหมายของผมคือแค่ให้การพัฒนาโดยรวมของผมจบได้ด้วย copad ตัวเดียว และเพื่อสิ่งนั้นผมก็ทำระบบ plugin ไว้แล้วครับ!
ดังนั้นฟีเจอร์ที่ต้องใช้ GUI ผมจึงพยายาม implement ลงใน copad ให้มากที่สุดครับ

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

Samsung ที่เคยเก็บบันทึกการให้คำปรึกษาภายในบริษัทไว้ในโฟลเดอร์วินัยของฝ่ายบุคคล ก็สมกับเป็นบริษัทชั้นนำระดับโลกจริง ๆ

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

อย่างไรก็ตาม มีข้อสังเกตหนึ่งที่อาจเป็นประโยชน์ต่อการออกแบบ idempotency key

เพื่อแยกแยะระหว่าง “เรียกสองครั้ง” กับ “ดำเนินการสองครั้ง” ผมลองเปรียบเทียบ entity ID ที่อยู่ใน response ดูครับ เพราะถ้าเรียกด้วย argument เดิมสองครั้งแล้ว response ID ต่างกัน ก็แปลว่ามีการสร้างขึ้นจริงสองรายการ แต่ถ้าเหมือนกันก็แปลว่า API dedup ให้เอง

อิงจาก benchmark Toolathlon ในบรรดาการเรียกซ้ำของเครื่องมือที่เปลี่ยนสถานะ:

ID ต่างกัน (เกิดการสร้างซ้ำจริง): 159 กรณี ID เหมือนกัน (API dedup): 76 กรณี ไม่มี ID ให้ตัดสินไม่ได้: 3,197 กรณี

จากตรงนี้เห็นรูปแบบอย่างหนึ่งครับ 159 กรณีที่ ID ต่างกันล้วนเป็นเครื่องมือกลุ่มสร้างทั้งหมด (สร้างเอกสาร, สร้างสเปรดชีต, อัปโหลดไฟล์, สร้างควิซ) ในทางกลับกัน กลุ่มอัปเดต (patch, update, enroll) ไม่มีกรณีที่ ID ต่างกันเลย เพราะชี้ไปยังเป้าหมายเดิม จึงไม่ได้ถูกสร้างขึ้นใหม่

กล่าวคือ หากจะใส่ idempotency key ฝั่งการสร้าง (POST) น่าจะควรให้ความสำคัญก่อนครับ ส่วนฝั่งอัปเดตดูเหมือนว่าหลายกรณีจะมีความเป็น idempotent ตามธรรมชาติอยู่แล้ว

และปัญหาเรื่องอีเมลที่พูดถึงก่อนหน้านี้ก็กลับมาเกี่ยวตรงนี้อีกครับ การส่งอีเมลมี response เป็นเพียงสตริง “สำเร็จ” จึงเปรียบเทียบ ID ไม่ได้ แม้จะใส่ idempotency key ก็ไม่มีทางยืนยันจาก trace เพียงอย่างเดียวได้ว่ามันทำงานจริงหรือไม่ หากออกแบบเครื่องมือภายใน แค่ให้ผลลัพธ์การส่งคืน message ID ก็จะตรวจสอบได้ใน audit log และน่าจะเข้ากันได้ดีกับวิธี hash chain ที่คุณพูดถึงด้วยครับ

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

เหมือนเป็นตะกร้าใส่ภาพหน้าจอเลยนะครับ

มี numba ที่ใช้แนวทาง JIT compilation ซึ่งเป็นไอเดียคล้ายกัน แต่ตัวนี้ให้ความรู้สึกว่าครอบคลุมได้มากกว่า

ถ้าแค่ปล่อยอะไรอย่าง gps oss 120b ออกมา ก็น่าจะดูพอมีน้ำหนักอยู่บ้าง แต่ก็ไม่แน่ใจเหมือนกันครับ

ดังนั้นทางที่ดีที่สุดคือการนำ LLM แบบปิดออกสู่ตลาดให้มีราคาถูกที่สุดเท่าที่จะทำได้ หากการเข้าถึงปัญญาประสิทธิภาพสูงเพิ่มขึ้น แรงจูงใจในการพัฒนาโมเดลแบบ open-weight ก็จะลดลงไปเอง และองค์กรทั่วไปก็ยังสามารถเป็นผู้นำทางเทคโนโลยีได้ แต่เอาเข้าจริง Anthropic กลับเป็นผู้ให้บริการที่กีดกันมากที่สุดในตลาดไม่ใช่หรือ?