Taskuary 是甚麼？AI 助理把電郵和聊天訊息轉成工作項目

Taskuary คืออะไร? ผู้ช่วย AI ที่เปลี่ยนอีเมลและแชทเป็นงาน

โดย Nokka (นก-กา) | นักเขียนอิสระสาย AI | ตรวจสอบข้อมูล ณ 19 ต.ค. 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

มีงานประเภทหนึ่งที่ผมเชื่อว่าหลายคนรู้จักดี

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

คำถามคือ ทำไมเราต้องเป็นคนประกอบข้อมูลพวกนี้เข้าด้วยกันเองทุกเช้า

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

ก่อนที่อะไรจะออกจากเครื่อง มันจะรอให้เรากดอนุมัติ

บทความนี้ผมสรุปจาก repo จริง เอกสารทางการของโปรเจกต์ และคลิปสั้น 34 วินาทีที่ผู้ใช้ส่งมา ซึ่งเป็นคลิปโปรโมตจากบัญชีรวมโปรเจกต์ ไม่ใช่ผู้พัฒนาเอง ผมจึงไม่ได้ใช้คลิปเป็นแหล่งตรวจสอบหลัก [1]

Taskuary คืออะไร

หนึ่งบรรทัดจาก README ของโปรเจกต์อธิบายได้ตรงที่สุด

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

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

ข้อมูลหลักที่ผมตรวจเองจาก GitHub

• repo ldbumble/taskuary เป็นโอเพนซอร์สสัญญาอนุญาต MIT [2]
• 140 ดาว 55 ฟอร์ก สร้างเมื่อ 17 ส.ค. 2026
• เขียนด้วย Python มีอัปเดตล่าสุดวันนี้ 19 ต.ค. 2026
• เวอร์ชันปัจจุบัน v0.3.9.6 ซึ่งยังไม่ถึง 1.0

จุดสำคัญคือ ตัวเลขดาวยังน้อยมาก เมื่อเทียบกับเครื่องมือในหมวดเดียวกัน ผมจะกลับมาเรื่องนี้ตอนท้าย

งานหนึ่งชิ้น เดินทางอย่างไร

ผมชอบที่ README เล่าเรื่องผ่านเคสเดียว คือคำขอของ Ruth ที่ต้องการตัวเลขค่าใช้จ่ายผู้ขาย เพราะมันทำให้เห็นทั้งเส้นทาง

ขั้นที่หนึ่ง ทุกอย่างลงที่ร่องเดียว

เมล แชท ระบบแจ้งปัญหา รายงาน และการแจ้งเตือน ถูกจัดเรียงเป็นร่องเดียว แบ่งตามสิ่งที่มันต้องการจากเรา

หกร่องคือ ด่วน งานที่รอคุณ เป้าหมาย เอเจนต์กำลังทำ รอไว้ก่อน และรายงาน กับอีกสองช่องคือไอเดียจากที่ปรึกษาและเรื่องที่แจ้งให้ทราบ

ข้างกันมีบัตรของวันนี้ที่บอกว่าเมื่อคืนมีอะไรเปลี่ยน เรียนรู้อะไรได้ มีประชุมอะไร และแต่ละช่องมีอะไรค้าง

ความคิดที่อยู่ตรงนี้คือ คุณไม่ต้องเปิดทุกระบบสลับกันอีก ซึ่งฟังดูเล็ก แต่เป็นงานที่กินพลังสมองมากที่สุดในตอนเช้า

ขั้นที่สอง ผู้ช่วยพาไปทีละงาน

มีปุ่มหนึ่งชื่อ "Walk me through my tasks" พอกดแล้ว ผู้ช่วยจะยกงานขึ้นมาทีละใบ วางบนโต๊ะเป็นบัตรงานเดียวกับที่เราจะเปิดเอง

ใต้บัตรมีปุ่มสี่ปุ่มที่ทำอะไรคงที่ตลอด คือ ต่อไป เขียนตอบ ส่งให้เอเจนต์ และทำเสร็จ

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

ผมว่าการออกแบบปุ่มให้คงที่นี้ฉลาด เพราะมันลดความไม่แน่นอนของคนใช้ เราไม่ต้องเดาว่าคราวนี้ระบบจะเสนออะไร

ขั้นที่สาม งานมีเรื่องราวของตัวเอง

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

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

ขั้นที่สี่ เอเจนต์ทำงานในบัตรเดียวกัน

กดส่งให้เอเจนต์ แล้วมันจะทำงานในบัตรเดิม ไม่ใช่เด้งไปหน้าต่างอื่น

ในตัวอย่างของ Ruth เอเจนต์เตรียมตัวเลข ตรวจว่ายอดแต่ละหมวดบวกกันได้ ระบุแหล่งที่มา แล้วร่างคำตอบ

และไม่มีอะไรถูกส่งออกไป

ขั้นที่ห้า คำสุดท้ายเป็นของเรา

ฉบับร่างจะรออยู่บนงานนั้น ข้างคำขอที่ทำให้มันเกิดขึ้น เราอ่าน แก้ แล้วกดอนุมัติจึงส่ง

ขั้นที่หก เช้าวันถัดไปเริ่มก่อนที่งานจะถาโถม

ทุกเช้าแอปจะเปิดมาที่สิ่งที่เปลี่ยนเมื่อคืน สิ่งที่ระบบเรียนรู้ ประชุมวันนี้ และสิ่งที่รออยู่ในแต่ละช่อง

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

ส่วนที่ผมว่าฉลาดที่สุด คือ LEARNED.md

ฟีเจอร์ที่ผมคิดว่าเป็นหัวใจจริง ๆ ของ Taskuary ไม่ใช่การรวมกล่องจดหมาย แต่คือความจำที่มันสร้างเอง

ทุกครั้งที่เราร่างคำตอบแล้วแก้ และทุกครั้งที่ย้ายงานไปหมวดอื่น มันได้หลักฐานเกี่ยวกับรสนิยมของเรา

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

และมันไม่ได้เก็บเป็นข้อความลอย ๆ แต่ละบทเรียนมีค่าความแข็ง หลักฐานอ้างอิง และวันที่สนับสนุนล่าสุด

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

ถ้ามีข้อมูลขัดแย้ง ค่าความแข็งจะลดลง และสมมติฐานที่ไม่มีใครแตะจะค่อย ๆ เสื่อมลงตามรอบการทบทวน

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

กฎที่เรียนรู้มาแล้วแตะต้องงานของเราได้ แต่มันจะไม่แอบซ่อนงานหรือย้ายงานให้เองโดยไม่ถาม

และถ้าเราพิมพ์คำสั่งไว้ใน SOUL.md คำของเราชนะเสมอ

outcome ledger กับความจำที่โตขึ้นจากการรอ

ชั้นที่ลึกกว่านั้นคือบันทึกผลลัพธ์

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

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

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

ผมมองว่านี่คือคำตอบที่ดีที่สุดที่ผมเคยเห็นต่อคำถามว่า AI ควรจำอะไร

เพราะมันจำ ผลของการกระทำ ไม่ใช่แค่เนื้อหาของการสนทนา

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

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

ความปลอดภัยของมัน ไม่ได้อยู่ที่เครือข่าย แต่อยู่ที่ตัวข้อความ

นี่คือส่วนที่ทำให้ผมมองโปรเจกต์นี้ต่างจากตอนเปิด repo ครั้งแรก

เอกสารความปลอดภัยของ Taskuary เปิดด้วยประโยคที่ตรงมาก

ความเสี่ยงที่เหลืออยู่คือความเสี่ยงที่ผู้ช่วย AI ทุกตัวที่อ่านเมลมี คือตัวข้อความที่มันอ่านถูกเขียนโดยคนอื่น และบางส่วนถูกเขียนขึ้นเพื่อบังคับทิศทาง AI ที่อ่านมัน

เขาเรียกสิ่งนี้ว่า prompt injection และบอกตรง ๆ ว่า [4] ไม่มีโมเดลไหนปฏิเสธได้อย่างน่าเชื่อถือ ระบบจึงไม่ฝากความหวังไว้ที่การที่โมเดลจะปฏิเสธ

แทนที่จะฝากไว้ที่โมเดล เขาแบ่งงานออกเป็นสามช่วงและลดอำนาจในแต่ละช่วง

ช่วงคัดแยก อ่านทุกข้อความแล้วตัดสินว่ามันคืองานอะไร แต่โมเดลนี้รันโดยไม่มีเครื่องมือเลย มันทำได้แค่ให้คำตัดสิน

ช่วงเอเจนต์ทำงาน อันนี้มีเชลล์ มีเบราว์เซอร์ และมีบัญชีที่เราเชื่อมไว้ นี่คือจุดที่คำสั่งแอบแฝงจะสร้างความเสียหายได้จริง

ช่วงที่อะไรออกจากเครื่อง ทุกอย่างรอเรา

สี่กลไกที่ผมว่าละเอียดเกินขนาดโปรเจกต์

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

สอง ที่อยู่ปลอมไม่นับเป็นคนคุ้นเคย ระบบอ่านผลตรวจจากเซิร์ฟเวอร์ผู้รับ ถ้าที่อยู่ในช่องจากล้มเหลวการตรวจ DMARC หรือ DKIM มันจะถูกนับเป็นคนแปลกหน้าไม่ว่าชื่อจะคุ้นแค่ไหน

สาม ข้อความของคนอื่นถูกกั้นด้วยเครื่องหมาย ข้อความของผู้ส่งที่ไว้ใจได้จะถูกวางระหว่างสัญลักษณ์ ⟦ กับ ⟧ และกฎที่เอเจนต์ทุกตัวอ่านบอกชัดว่านี่คือข้อมูลของงาน ไม่ใช่คำสั่ง

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

สี่ เอเจนต์มีอำนาจน้อยกว่าเราในหน้าจอของ Taskuary เอง แต่ละเซสชันมีโทเคนของตัวเอง และเส้นทางที่ใช้ส่ง อนุมัติ หรือเปลี่ยนการตั้งค่าจะปฏิเสธโทเคนนั้น

หน้าแอปก็ไม่พกโทเคนของเรา มันเปิดเบราว์เซอร์ด้วยคีย์ใช้ครั้งเดียว

ผมชอบรายละเอียดอีกสองข้อที่คนทำระบบมักข้าม

ระบบไม่โหลดรูปจากข้อความที่คนอื่นเขียน [4] เพราะรูปอาจเป็นคำขอที่พาข้อมูลของเราไปหาเซิร์ฟเวอร์ปลายทาง

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

สิ่งที่มันยอมรับเองว่ายังไม่ได้ป้องกัน

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

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

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

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

เรื่องรหัสผ่าน ที่ผมว่าน่าจะเป็นย่อหน้าที่ดีที่สุดใน README

Taskuary ลบข้อมูลรับรองออกจากพรอมป์ก่อนส่งให้ผู้ให้บริการ AI [3]

ถ้าเพื่อนร่วมงานส่งคีย์ API หรือสตริงเชื่อมต่อมาทางเมล ระบบจะแทนที่ด้วยป้าย เช่น [redacted:aws-key] ในทั้งสามทางที่พรอมป์จะออกไป

และมันทำแบบกฎตายตัว ไม่ให้โมเดลเป็นคนตัดสิน เพราะกว่าที่โมเดลจะตัดสินได้ รหัสก็อยู่ในพรอมป์ไปแล้ว

แล้ว README ของโปรเจกต์เขียนประโยคที่ผมอ่านแล้ววางใจขึ้นทันที

กฎพวกนี้จับข้อมูลรับรองที่มีรูปแบบจดจำได้ ทั้งคีย์ผู้ให้บริการ โทเคน ยูอาร์แอลที่มีรหัสผ่าน สตริงเชื่อมต่อ และไพรเวตคีย์ และมันจะไม่จับประโยคอย่าง "รหัสไวไฟคือ bluefish17" [3]

การบอกข้อจำกัดของตัวเองตรง ๆ แบบนี้หาได้ยาก และมันมีค่ามากกว่าคำโฆษณาสิบหน้า

ตัวเลขที่ผมว่าต้องอ่านให้ครบ

ผมดึงข้อมูลจริงมาเองเพื่อไม่ให้เขียนจากความรู้สึก

• ดาวบน GitHub 140 ดาว ฟอร์ก 55
• งานที่เปิดค้างอยู่ 61 รายการ ปิดไปแล้ว 84 รายการ รวมทั้งหมด 145 รายการ
• พีอาร์ทั้งหมด 105 ตัว ปิดไปแล้ว 103 ตัว และเปิดค้าง 2 ตัว
• ออกเวอร์ชัน 5 ครั้งในเวลาไม่ถึงสามวัน ตั้งแต่ v0.3.9.2 ถึง v0.3.9.6
• ดาวน์โหลดจาก PyPI รวม 12,321 ครั้งใน 55 วัน นับจาก 24 สิงหาคม ถึง 17 ตุลาคม [8][9]
• วันที่มีคนดาวน์โหลดสูงสุดในช่วงนั้นอยู่ที่ 798 ครั้ง

ตัวเลขที่ผมว่าสำคัญที่สุดคือ 61 งานที่เปิดค้าง และเมื่อผมดึงมาดูจริงทั้ง 61 รายการ ปรากฏว่าทั้งหมดเขียนโดยเจ้าของโปรเจกต์เอง

รายการที่เปิดค้างมีตั้งแต่เรื่องจริงจังอย่างพื้นที่โพสต์ใน Hub หายเงียบ ๆ การตั้งค่าที่โค้ดอ่านแต่ไม่มีปุ่มให้แก้ ไปจนถึงปัญหา accessibility ที่ใช้คีย์บอร์ดไม่ได้

อีกด้านหนึ่งที่ต้องรายงานให้ครบคือพีอาร์ ทั้ง 105 ตัวมี 101 ตัวเปิดโดยคนนอก และในจำนวนนั้นถูกรวมแล้ว 62 ตัว ทั้ง repo รวม 65 ตัว

แต่เมื่อเปิดดูเนื้อใน งานส่วนใหญ่เป็นชิ้นเล็ก เช่น การเข้าถึงด้วยคีย์บอร์ด การแก้เอกสารในคู่มือ หรือการแก้ป้ายปุ่ม

ผมจึงยังยืนยันว่าไม่มีรีวิวเชิงลึกจากคนนอก และไม่มีบทสนทนาสาธารณะที่ซับซ้อนเรื่องการออกแบบ

ผมอ่านสิ่งนี้ว่าเป็นสัญญาณสองทางพร้อมกัน

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

อีกทางหนึ่งคือคนเขียนตรวจงานตัวเองอย่างจริงจัง ซึ่งหาได้ยากกว่าโปรเจกต์ที่เปิดค้างศูนย์รายการแต่ไม่มีใครรู้ว่าข้างในเป็นอย่างไร

รีวิวอิสระ และบทสนทนาสาธารณะ มีน้อยมาก

นี่คือส่วนที่ผมต้องบอกตรง ๆ

คลิปที่ส่งมาโพสต์เมื่อ 15 กันยายน 2026 มียอดดูเก้าพันกว่าครั้ง กดใจ 311 และ มีความเห็นแค่หนึ่งรายการ [1]

บัญชีที่โพสต์เป็นบัญชีรวมโปรเจกต์โอเพนซอร์ส ไม่ใช่ผู้พัฒนา

ส่วนบน Hacker News ซึ่งเป็นที่ที่โปรเจกต์แบบนี้มักถูกตรวจสอบอย่างหนัก มีโพสต์สองครั้ง ครั้งแรกได้ 4 คะแนน ครั้งที่สองได้ 3 คะแนน และความเห็นรวมกันสี่รายการ [7][6]

ความเห็นหนึ่งบอกสั้น ๆ ว่า มีเครื่องมือแบบนี้เต็มไปหมดจนตามไม่ทัน

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

ผมว่าประโยคนี้สำคัญ เพราะมันบอกสถานะจริงของโปรเจกต์ชัดกว่าคำโปรโมตใด ๆ

มีข้อควรรู้คือคอมเมนต์ของบัญชีนั้นบน Hacker News ถูกระบบตีเป็น flagged ผมจึงอ่านถ้อยนี้จาก HN Search API ของ Algolia ซึ่งเก็บข้อความเดิมไว้ ไม่ใช่จากหน้าเว็บที่ผู้อ่านทั่วไปจะเห็น

เหมาะกับใคร และไม่เหมาะกับใคร

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

เหมาะ ถ้าคุณใช้ Claude Code หรือ Codex อยู่แล้วและอยากให้มันทำงานที่ไหลเข้ามา ไม่ใช่แค่งานที่คุณนึกออกเอง

เหมาะ ถ้าคุณให้ความสำคัญกับการที่ข้อมูลอยู่ในเครื่องตัวเอง เพราะ Taskuary เก็บทุกอย่างไว้ในไฟล์ SQLite ไฟล์เดียว ไม่มีบัญชี ไม่มีคลาวด์ [5]

ข้อแม้คือ ถ้าคุณใช้ผู้ให้บริการ AI แบบโฮสต์ หรือใช้ CLI ของเอเจนต์เขียนโค้ด เนื้อความในเมลจะออกไปพร้อมพรอมป์ [3] ข้อมูลจะอยู่แต่ในเครื่องก็ต่อเมื่อคุณใช้โมเดลที่รันในเครื่องเอง

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

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

ยังไม่เหมาะ ถ้าคุณต้องการรีวิวจากผู้ใช้จำนวนมากก่อนตัดสินใจ เพราะตอนนี้ยังมีน้อยมาก

เริ่มลองได้สามทาง

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

pip install taskuary
taskuary

บน Windows มีไฟล์เรียกใช้ไฟล์เดียว ไม่ต้องติดตั้ง Python

อีกทางคือ Docker ซึ่งรันตัวเว็บแอป แต่ CLI ของเอเจนต์ยังอยู่บนเครื่องหลัก

หลังเปิดครั้งแรก มันจะพาเชื่อมผู้ให้บริการ AI หรือโมเดล Ollama ในเครื่อง จากนั้นเชื่อมช่องทางขาเข้า แล้วเลือก CLI ที่จะรับงาน

ถ้าเลือกใช้โมเดลที่รันในเครื่อง คำสั่งทั้งหมดจะไม่ออกจากเครื่องเลย

สิ่งที่ผมยืนยันได้ และยืนยันไม่ได้

ยืนยันได้

• repo เป็น MIT และมีอยู่จริง ตรวจจาก GitHub API เอง
• เวอร์ชัน 0.3.9.6 ออกวันนี้ และมีห้ารีลีสในเวลาไม่ถึงสามวัน
• ตัวเลขดาว ฟอร์ก และงานค้าง ตรงกับที่ API ตอบ
• ยอดดาวน์โหลด PyPI 12,321 ครั้งใน 55 วัน จากไฟล์สถิติที่ repo เปิดเอง
• เอกสารความปลอดภัยระบุกลไกและข้อจำกัดตามที่ผมเขียนข้างต้น
• คลิป TikTok มีอยู่จริงและโพสต์ 15 กันยายน 2026 ส่วนยอดดู 9,185 ครั้ง และความเห็น 1 รายการ ผมอ่านจากหน้า TikTok ณ วันเขียน ซึ่งตรวจซ้ำจากปลายทางอื่นไม่ได้

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

• ว่า LEARNED.md ทำงานได้ดีแค่ไหนในชีวิตจริง เพราะยังไม่มีผลวัดที่เผยแพร่
• ว่าการป้องกัน prompt injection ทั้งชุดผ่านการทดสอบอิสระหรือยัง
• ว่าเอเจนต์ที่รับงานไปทำ ได้ผลลัพธ์ที่มีคุณภาพแค่ไหน
• ว่าเจ้าของโปรเจกต์เป็นใคร เพราะบัญชี GitHub มี repo สาธารณะเพียงตัวเดียว

คำถามที่ผมว่าควรถามก่อนติดตั้ง

ไม่ใช่ "มันดีไหม" แต่เป็น "ผมยอมให้มันอ่านเมลทั้งกล่องหรือยัง"

ถ้าคำตอบคือยัง ให้เริ่มจากโหมดตัวอย่างก่อน แล้วค่อยเชื่อมช่องทางทีละอัน

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

และถ้าคำตอบคือยังไม่แน่ใจ ให้อ่านหน้าความปลอดภัยของมันก่อนหน้าอื่นใด

เพราะหน้าที่นั้นคือส่วนที่บอกเราได้ดีที่สุดว่าเราเข้าใจสิ่งที่กำลังจะติดตั้งหรือเปล่า

แหล่งอ้างอิง

[1] Github Signals, "What if every email and message automatically became a clean task instead of more noise?", TikTok, 15 ก.ย. 2026. https://vt.tiktok.com/ZSghoFMqd/
[2] ldbumble, "taskuary", GitHub, เข้าถึง 19 ต.ค. 2026. https://github.com/ldbumble/taskuary
[3] Taskuary README, GitHub, master branch, เข้าถึง 19 ต.ค. 2026. https://raw.githubusercontent.com/ldbumble/taskuary/master/README.md
[4] Taskuary Documentation, "Security", updated 2026-10-18. https://taskuary.com/docs/security
[5] Taskuary, หน้าหลักผลิตภัณฑ์, เข้าถึง 19 ต.ค. 2026. https://taskuary.com/
[6] Hacker News, "Show HN: Taskuary: turn your inbox into tasks for Claude Code, Codex, or Gemini", 14 ก.ย. 2026. https://news.ycombinator.com/item?id=49701075
[7] Hacker News, "Taskuary: Your inbox becomes tasks, your coding CLI works them", 21 ส.ค. 2026. https://news.ycombinator.com/item?id=49393717
[8] PyPI, "taskuary", เข้าถึง 19 ต.ค. 2026. https://pypi.org/project/taskuary/
[9] GitHub, "downloads.csv" สาขา stats, เข้าถึง 19 ต.ค. 2026. https://github.com/ldbumble/taskuary/blob/stats/downloads.csv