Audit a Running AI System From Another Workspace
ให้โมเดลที่สูงกว่า audit ระบบ AI ของตัวเอง จากอีก workspace หนึ่ง
พรอมป์สำหรับตรวจระบบ AI ที่ปิดไม่ได้ — เปิด session ใหม่ใน workspace แยก ใช้โมเดลที่สูงกว่าตัวที่รันระบบอยู่ ชี้ไปโฟลเดอร์เดียวกัน แล้วให้มันยิงคำถามข้าม workspace ไปถามตัวจริงก่อนจะแตะไฟล์ใด ๆ
พรอมป์นี้ทำอะไร
What this prompt does
ใช้ตรวจ AI assistant ที่รันต่อเนื่องมานานจนไม่มั่นใจแล้วว่าอะไรยังทำงานจริงอยู่บ้าง หัวใจของพรอมป์นี้อยู่ที่ "ใครเป็นคนตรวจ" — ไม่ใช่ให้ระบบตรวจตัวเอง แต่เปิด session ใหม่ใน workspace แยก ใช้โมเดลที่สูงกว่าตัวที่รันระบบอยู่ ชี้ไปโฟลเดอร์โปรเจคเดียวกัน มันจะอ่านอย่างเดียวจนกว่าแผนจะผ่านการอนุมัติ และเวลาที่แยกไม่ออกว่าอะไรคือบั๊กอะไรคือของที่ตั้งใจให้เป็นแบบนั้น มันจะยิงคำถามข้าม workspace ไปถามตัวจริงแทนที่จะเดา สิ่งที่มันตามล่าคือของที่ระบบไม่มีวันรายงานตัวเอง — ทางแจ้งเตือนที่ไม่เคยยิงออกจริง, job ที่หายไปเงียบ ๆ, สคริปต์ที่ return สำเร็จแต่ปลายทางไม่เกิดอะไรขึ้น
Audit an AI assistant that has been running long enough that nobody is sure what still works. The trick is who does the auditing: a second session in a separate workspace, on a model above the one the system itself runs on, sharing the same project folder. It reads only until the plan is approved, and whenever it cannot tell a bug from a deliberate choice it asks the running assistant directly instead of guessing. What it hunts for is the class of problem a system never reports about itself — alerts that never fired, jobs that vanished quietly, scripts that return success while nothing happens downstream.
ใช้ตอนไหน
- มี AI assistant ที่รันต่อเนื่องมานานหลายเดือน จนไม่มั่นใจแล้วว่าอะไรในนั้นยังทำงานจริง อะไรพังเงียบไปแล้ว
- ระบบต้องรันต่อได้ตลอดระหว่างตรวจ ปิดเพื่อซ่อมไม่ได้
- อยากให้โมเดลที่ฉลาดกว่าตัวที่รันระบบอยู่ เป็นคนตรวจ แทนที่จะให้ระบบตรวจตัวเอง
- สงสัยว่าต้นทุนต่อ turn สูงเกินจำเป็น แต่ยังชี้ไม่ได้ว่าอะไรกินเยอะ
- ไฟล์ instruction (CLAUDE.md, persona, skill frontmatter) โตขึ้นเรื่อย ๆ จนน่าจะมีกฎที่ขัดกันเองอยู่ข้างใน
ได้อะไรกลับมา
- docs/audit-<วันที่>.md ที่ finding เรียงตามความรุนแรง และแยกชัดว่าอันไหนคือ "บั๊ก" อันไหนคือ "policy ที่เจ้าของเลือกเอง"
- ตาราง before/after 4 คอลัมน์ ที่มีตัวเลขจริง และบอกด้วยว่าแต่ละแถววัดด้วยอะไร
- รายการสิ่งที่ต้องให้เจ้าของตัดสินใจ เป็นข้อสั้น ๆ ที่ตอบ yes/no ได้
- commit แยกเป็นเรื่อง ๆ ที่ระบบยังรันได้ระหว่างทาง พร้อม regression test อย่างน้อยหนึ่งเคสต่อบั๊กที่แก้
- ผลการทดลองบูตเย็นจริงหนึ่งรอบ ว่าทุก process ขึ้นครบไหม ไม่ใช่แค่ relaunch pane เดียวตอนระบบอุ่น
- ไฟล์ handoff ให้ assistant ตัวเดิมอ่านต่อ ว่าอะไรเปลี่ยนไปบ้าง และต้องเปลี่ยนพฤติกรรมตรงไหน
วิธีใช้
How to use
- 1เปิด workspace ใหม่ใน Herdr.dev แยกจาก workspace ของ assistant ตัวเดิม แต่ตั้ง cwd ให้ชี้ไปโฟลเดอร์โปรเจคเดียวกัน
- 2ตั้งโมเดลของ session ใหม่ให้สูงกว่าตัวที่รันระบบอยู่ — ถ้า assistant เป็น Opus ให้ผู้ตรวจเป็น Fable ประเด็นคือคนตรวจต้องมองออกมากกว่าคนถูกตรวจ
- 3วางพรอมป์นี้ลงไป แล้วแทน [ชื่อ Assistant], [Opus], [Fable], [herdr/tmux], [ชื่อ workspace] ด้วยของจริง
- 4ปล่อยให้มันอ่านอย่างเดียวในขั้น 1 ห้ามให้แก้อะไรก่อน แล้วรอมันยิงคำถามข้าม workspace ไปถาม assistant ตัวเดิมเองในขั้น 2
- 5อ่าน finding + แผนในขั้น 3 ให้จบก่อนอนุมัติ ตรงนี้คือจุดที่ต้องคัดว่าอันไหนคือบั๊กจริง อันไหนคือของที่ตั้งใจให้เป็นแบบนั้น
- 6ให้ลงมือแก้ทีละ commit เล็ก ๆ แล้วบังคับให้วัดซ้ำหลังปล่อยของจริง ไม่ใช่วัดตอนเขียนเสร็จ
ตัวพรอมป์
The prompt · 59 บรรทัด
ให้ AI อ่านเอง: madebytle.com/prompt/cross-workspace-ai-audit.md
Mission: Audit ระบบ AI ที่กำลังรันอยู่ จากอีก workspace หนึ่ง
บริบท
- ระบบ
[ชื่อ Assistant]เป็น AI Assistant ที่รันต่อเนื่องมานาน ด้วยโมเดล[Opus]ซึ่งต่ำกว่านาย (นายคือ[Fable]) - มันรันอยู่ใน
[herdr/tmux]workspace[ชื่อ]คนละ workspace กับนาย แต่ใช้โฟลเดอร์โปรเจคเดียวกัน - ระบบนี้สำคัญกับฉันมาก ต้องทำงานต่อได้ตลอดระหว่างที่นาย audit
เป้าหมาย
- หาจุดบกพร่องทั้งโปรเจค เรียงตามความรุนแรง
- วางแผนปรับปรุงให้ระบบทำงานได้ถูกต้องขึ้น ถูกลง และตรวจสอบได้
- ลงมือแก้ตามแผนโดยที่ระบบยังรันอยู่
- ส่งตาราง before & after ที่มีตัวเลขจริงและระบุวิธีวัด
ลำดับการทำงาน (ห้ามข้ามขั้น)
ขั้น 1 อ่านอย่างเดียว: กวาดโค้ด, config, hooks, scheduler, สคริปต์, log, transcript รวมถึง state ที่ harness เก็บไว้นอกโฟลเดอร์โปรเจค ด้วย — config/cache ของเครื่องมือที่รันระบบอยู่, failure cache, log ของ plugin/MCP ของแต่ละชิ้นที่พึ่ง harness ต้องตอบให้ได้ว่า "ถ้าชิ้นนี้ crash ตอน start เครื่องมือจะจำอะไรไว้ และรอบหน้ามันจะทำตัวต่างไปยังไง" ยังไม่แก้อะไรทั้งสิ้น
ขั้น 2 สงสัยอะไรให้ถาม [ชื่อ Assistant] ใน workspace [ชื่อ] โดยตรง
โดยเฉพาะ: ไฟล์/โค้ด/โครงสร้างนี้ใช้ทำอะไร, สิ่งนี้เป็นบั๊กหรือฉันตั้งใจให้เป็นแบบนี้
รวมคำถาม-คำตอบไว้ในรายงาน และแยกให้ชัดว่าอะไรคือ "บั๊ก" อะไรคือ "policy ที่เจ้าของเลือกเอง"
ขั้น 3 ส่งรายการ finding + แผน + สิ่งที่ต้องให้ฉันตัดสินใจ มาให้ฉันดูก่อนลงมือ
ขั้น 4 ลงมือแก้ ทีละ commit เล็ก ๆ ที่ระบบยังรันได้ระหว่างทาง
ขั้น 5 วัดซ้ำหลังปล่อยของจริง ไม่ใช่วัดตอนเขียนเสร็จ
สิ่งที่ต้องหาเป็นพิเศษ
- ของที่พังเงียบ: ทางแจ้งเตือนที่ไม่เคยยิงออกจริง, สคริปต์ที่ return สำเร็จแต่ผลไม่เกิด, งานที่ถูกส่งไปแล้วไม่มีใครอ่าน, job ที่หายไปเงียบ ๆ, log ที่ไม่มีใครดู
- ต้นทุนต่อ turn: ขนาด context จริงต่อ API call, มี compaction ไหม, โมเดลถูก pin ไหม, ไฟล์ที่ถูกโหลดทุก turn (CLAUDE.md, persona, skill frontmatter) ใหญ่แค่ไหน
- ความขัดแย้งในเอกสาร instruction: กฎที่ขัดกันเอง, ของที่ระบุไว้แต่ถูกลบไปแล้ว
- race / single point of failure: หลาย process แย่ง resource เดียวกัน, mapping ที่พังถ้าลำดับเปลี่ยน, error ที่ถูกกลืน
- เส้นทางบูตเย็น: ไล่ตั้งแต่ login / LaunchAgent / สคริปต์ startup จนถึงตอนที่ทุก process ขึ้นครบ แล้วตอบสามข้อ — เรียกซ้ำแล้วปลอดภัยไหม (idempotent), ถูก trigger ซ้อนสองทางพร้อมกันได้ไหม, ถ้า N process spawn ของชิ้นเดียวกันพร้อมกันในโฟลเดอร์เดียวกันจะชนกันไหม
- ความปลอดภัย: secret ใน plaintext, ใน argv, ใน git history, สิทธิ์ไฟล์, ใครสั่งของที่มีค่าใช้จ่ายได้
- repo hygiene: สคริปต์ที่ไม่มีใครเรียก, binary ที่ track อยู่, memory/ตัวจำที่โตขึ้นเรื่อย ๆ โดยไม่มีใครตัด
กฎระหว่าง audit
- นายรันอยู่ในโฟลเดอร์เดียวกัน hook ชุดเดียวกันจะยิงใน session ของนายด้วย ตรวจก่อนว่า session ของนายจะไม่ไปกินคิว/inbox/lock ของระบบจริง ถ้าเลี่ยงไม่ได้ ให้บอกฉันก่อนว่าจะไปชนตรงไหน — แล้วถามกลับอีกทิศด้วยว่า process ของระบบจริงแย่งกันเองตอน start หรือเปล่า ไม่ใช่ระวังแค่ทิศที่นายจะไปชนมัน
- ห้ามทำเองโดยเด็ดขาด ต้องถามฉันก่อน: ลบไฟล์หรือข้อมูล, หมุน/เปลี่ยน token, แก้ access list หรือ allowlist, สั่งอะไรที่มีค่าใช้จ่าย, restart ระบบจริง
- ไม่ลบ ให้ archive แล้วบอกว่าย้ายไปไหน
- ทุกบั๊กที่แก้ต้องมี regression test อย่างน้อยหนึ่งเคส และ test เดิมต้องยังผ่านทั้งหมด
- แก้เสร็จแล้ว ต้องพิสูจน์ผลปลายทาง ไม่ใช่เชื่อว่า exit 0 หรือ "sent" คือสำเร็จ
Deliverables
docs/audit-[วันที่].mdมี: finding เรียงตามความรุนแรง, สิ่งที่ตรวจแล้วไม่พบปัญหา (เพื่อให้รู้ว่าขอบเขตครอบคลุมแค่ไหน), ตาราง before/after ที่มี 4 คอลัมน์ [metric | before | after | วัดด้วยอะไร], รายการที่ต้องให้ฉันตัดสินใจ (เป็นข้อสั้น ๆ ตอบ yes/no ได้)- ไฟล์ handoff สำหรับ
[ชื่อ Assistant]เอง: อะไรเปลี่ยน ต้องอ่านอะไรใหม่ พฤติกรรมอะไรต้องเปลี่ยน - ทดลองบูตเย็นจริงหนึ่งรอบ (รีบูตเครื่อง หรือ logout/login) แล้ววัดว่าทุก process ขึ้นครบจริง — relaunch pane เดียวตอนระบบยังอุ่นอยู่ไม่นับ พร้อมขั้นตอน relaunch ที่ผ่านการทดลองนั้นแล้ว (ถ้าต้องสลับโมเดล/ตั้งค่าใหม่) และวิธี rollback ถ้าของใหม่พัง
- commit แยกเป็นเรื่อง ๆ, git status สะอาด, ประวัติการตัดสินใจไปอยู่ใน changelog ไม่ใช่ในไฟล์ instruction หลัก
- สรุปให้ฉันเป็นภาษาไทย สั้น ขึ้นต้นด้วยสิ่งที่ต้องตัดสินใจก่อน
ถ้าไม่แน่ใจให้ถาม
[ชื่อ Assistant]ก่อน ถ้ายังไม่แน่ใจให้ถามฉัน อย่าเดา
ข้อควรรู้
Notes from using it
ตัวพรอมป์เขียนแบบ agent-to-agent (เรียกผู้ตรวจว่า "นาย") ตั้งใจให้ผู้ตรวจรู้ตัวว่ากำลังตรวจของที่ยังทำงานอยู่ ไม่ใช่ sandbox — ข้อความ "ระบบนี้สำคัญกับฉันมาก ต้องทำงานต่อได้ตลอด" มีผลจริงกับการที่มันเลือกจะไม่ restart อะไรเอง ส่วนที่ทำให้ปลอดภัยพอจะปล่อยให้แก้ของจริงได้คือขั้น 3 (ส่งแผนมาให้ดูก่อน) กับ allowlist ของสิ่งที่ห้ามทำเองเด็ดขาด อย่าตัดสองอันนี้ทิ้ง และอย่าลืมแทนค่าใน [วงเล็บ] ให้ครบก่อนวาง · อัปเดต 6 ก.ย. 2026 หลังมีคนรายงานกลับมาว่า audit ผ่านแล้วระบบยังบูตพังวันถัดมา จึงเพิ่มข้อบังคับทดลองบูตเย็น และขยายขอบเขตขั้น 1 ให้รวม state ของ harness นอกโปรเจค
คำถามที่เจอบ่อย
FAQ
ทำไมต้องเปิด workspace แยก ให้ session เดิมตรวจตัวเองไม่ได้เหรอ?
ได้ แต่จะได้ผลแย่กว่ามาก ระบบที่ตรวจตัวเองมองไม่เห็นสมมติฐานที่ตัวเองยึดอยู่ — มันเขียนโค้ดนั้นเอง มันเลยเชื่อว่าโค้ดนั้นทำงาน และอีกเหตุผลที่จำเป็นกว่านั้นคือระบบต้องรันต่อได้ระหว่างตรวจ ถ้าให้ตัวเดิมหยุดมาตรวจตัวเอง งานจริงก็หยุดไปด้วย
ทำไมโมเดลของผู้ตรวจต้องสูงกว่าตัวที่รันระบบ?
เพราะบั๊กที่หาเจอง่ายมันถูกเจอไปแล้วตั้งแต่ตอนเขียน ที่เหลืออยู่คือของที่ตัวมันเองมองไม่ออก ถ้าผู้ตรวจใช้โมเดลระดับเดียวกัน ก็มีแนวโน้มจะตกหลุมเดียวกัน การยกโมเดลขึ้นหนึ่งขั้นคือวิธีที่ถูกที่สุดในการเพิ่มโอกาสเห็นของที่ตัวเดิมมองข้าม
ผู้ตรวจอยู่โฟลเดอร์เดียวกับระบบจริง จะไปกวนกันไหม?
กวนได้ และนี่คือกับดักที่คนมองข้ามบ่อยที่สุด hook ชุดเดียวกันจะยิงใน session ของผู้ตรวจด้วย พรอมป์เลยมีข้อบังคับให้เช็คก่อนลงมือว่า session ผู้ตรวจจะไม่ไปกินคิว inbox หรือ lock ของระบบจริง ถ้าเลี่ยงไม่ได้ต้องบอกเจ้าของก่อนว่าจะไปชนตรงไหน
ทำไมต้องแยก "บั๊ก" ออกจาก "policy ที่เจ้าของเลือกเอง"?
เพราะไม่งั้นผู้ตรวจจะไล่ "แก้" ของที่ตั้งใจให้เป็นแบบนั้น ของแปลก ๆ ในระบบที่ใช้มานานส่วนใหญ่ไม่ใช่บั๊ก แต่เป็นทางลัดที่เจ้าของเลือกไว้เองแล้วลืมจดเหตุผล ขั้น 2 ของพรอมป์เลยบังคับให้ถามตัวจริงก่อน แล้วเอาคำถาม-คำตอบใส่ไว้ในรายงานด้วย
ทำไมห้ามเชื่อว่า exit 0 หรือคำว่า "sent" แปลว่าสำเร็จ?
เพราะของที่พังเงียบเกือบทั้งหมดคืนค่าสำเร็จ อีเมลที่ "ส่งแล้ว" แต่ไม่มีใครได้รับ, job ที่จบสวยแต่ไม่ได้เขียนอะไรลงปลายทาง, log ที่เขียนไว้แต่ไม่มีใครเปิดดู ขั้น 5 เลยบังคับให้วัดผลที่ปลายทางจริงหลังปล่อยของ ไม่ใช่วัดตอนที่เพิ่งเขียนเสร็จ
audit ผ่านหมดแล้ว ทำไมยังต้องบังคับทดลองบูตเย็นอีกรอบ?
เพราะเคยพลาดมาแล้วจริง ๆ ครับ รอบหนึ่ง audit จบสวย finding เรียงครบ regression test ผ่านหมด แต่วันรุ่งขึ้นพอเจ้าของรีบูตเครื่อง ระบบบูตขึ้นมาแบบไม่ได้ยิน Discord เลย สาเหตุคือตอนบูต 5 pane ขึ้นพร้อมกันแล้วแย่งกันติดตั้ง plugin ตัวเดียวกันในโฟลเดอร์เดียวกัน ตัวที่แพ้ crash แล้วเครื่องมือดันตีความว่า "plugin นี้รอ auth" จดไว้ใน cache แล้วข้ามการเปิดไป 15 นาทีแบบเงียบ ๆ ทุก session ใหม่ จุดที่พลาดไม่ใช่ว่าพรอมป์ไม่มีหัวข้อ race — มีอยู่ — แต่คือไม่มีข้อไหนบังคับให้ผู้ตรวจ *เดิน* เส้นทางบูตเย็นจริง มันเลยทดสอบแค่ relaunch pane เดียวตอนระบบยังอุ่น ซึ่งไม่ใช่เส้นทางที่ใครใช้จริงตอนเช้า
พรอมป์นี้ใช้ได้ผลไหม
กดบอกไว้หน่อยครับ ไม่ต้องล็อกอิน — ตัวที่คนกดว่าใช้ไม่ได้ผลจะถูกเอาไปขัดใหม่ก่อน
แก้เองแล้วดีขึ้น อยากส่งเวอร์ชันที่ดีกว่ากลับมา หรืออยากให้ทำพรอมป์เรื่องไหนเพิ่ม — แจ้งที่ GitHub · ไม่มีบัญชี GitHub ก็ นัดคุยได้เลย