Ponytail ทำให้ AI เขียนโค้ดน้อยลงได้อย่างไร

Ponytail คืออะไร

Ponytail คือชุดกฎที่ทำให้เอเจนต์เขียนโค้ดด้วย AI เขียนโค้ดน้อยลง โครงการนี้อธิบายตัวเองไว้ในประโยคเดียวว่า: "ทำให้เอเจนต์ AI คิดเหมือนนักพัฒนาอาวุโสที่ขี้เกียจที่สุดในห้อง โค้ดที่ดีที่สุดคือโค้ดที่คุณไม่เคยเขียน" โครงการนี้ใช้สัญญาอนุญาต MIT ไม่มี runtime ของตัวเอง และไม่มีส่วนใดในโครงการที่ทำงานโดยการ execute โครงการนี้เป็นข้อความที่ใส่ไว้ในคำสั่งของเอเจนต์ โดยจัดแพ็กเกจเป็น skill สำหรับ host ที่โหลด skill ได้ และเป็นไฟล์กฎแบบข้อความธรรมดาสำหรับ host ที่ไม่รองรับการโหลด skill

repository คือ DietrichGebert/ponytail โครงการนี้สร้างขึ้นเมื่อ 12 June 2026 และมีดาวเกิน 90,000 ดวงภายใน 1 August 2026 release ล่าสุดที่ติด tag ณ วันที่ 1 August 2026 คือ v4.8.4 ซึ่งเผยแพร่เมื่อ 29 June 2026 และหน้า releases แสดง tag 10 รายการในช่วงวันที่ 14 ถึง 29 June เพียงช่วงเดียว โครงการที่พัฒนาในอัตรานี้จะเปลี่ยนแปลงไปเมื่อคุณอ่านเนื้อหานี้ ดังนั้นให้ระบุ tag แบบตายตัวก่อนนำไปสร้างสิ่งใดต่อยอด

เครื่องมือไม่ใช่จุดเริ่มต้น: หยุดที่ขั้นแรกที่ใช้งานได้

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

1. สิ่งนี้จำเป็นต้องมีหรือไม่ สิ่งนี้คือ YAGNI (คุณจะไม่จำเป็นต้องใช้สิ่งนี้) หากคำตอบคือไม่ ให้ข้ามไป
2. สิ่งนี้มีอยู่แล้วใน codebase นี้หรือไม่ ให้ใช้ helper หรือรูปแบบที่มีอยู่แล้ว
3. standard library ทำสิ่งนี้ได้หรือไม่ ให้ใช้
4. ฟีเจอร์ดั้งเดิมของ platform รองรับสิ่งนี้หรือไม่ ให้ใช้
5. dependency ที่ติดตั้งไว้แล้วแก้ปัญหานี้ได้หรือไม่ ให้ใช้
6. เขียนเป็นบรรทัดเดียวได้หรือไม่ ให้เขียนเป็นบรรทัดเดียว
7. จากนั้นจึงเขียนโค้ดขั้นต่ำที่ใช้งานได้

สิ่งที่ทำให้งานสำเร็จคือการเรียงลำดับ ไม่ใช่ขั้นใดขั้นหนึ่งเพียงลำพัง เมื่อ Agent ได้รับคำขอให้สร้าง date picker ก็จะเขียน date picker เพราะนั่นคือสิ่งที่ได้รับคำสั่งให้ทำ บันไดนี้บังคับให้ตรวจสอบขั้นที่ 4 ก่อน และขั้นที่ 4 ระบุว่า browser มี <input type="date"> อยู่แล้ว บันทึก benchmark ของโครงการระบุกรณีนี้ไว้อย่างชัดเจนว่า date picker ซึ่งมีความยาว 404 บรรทัดเมื่อไม่มีกฎนี้ ลดเหลือ 23 บรรทัดเมื่อมีกฎนี้ เพราะ Agent เลือกใช้ native input แทนการสร้าง component ส่วน colour picker ก็ลดจาก 287 บรรทัดเหลือ 23 บรรทัดด้วยเหตุผลเดียวกัน

ความขี้เกียจในที่นี้ไม่ได้หมายถึงความประมาท และ ruleset ก็ระบุเรื่องนี้ไว้อย่างชัดเจน รายการ "never lazy about" ครอบคลุมการทำความเข้าใจปัญหาก่อนตัดสินใจ การตรวจสอบ input ที่ trust boundary การจัดการข้อผิดพลาดเพื่อป้องกันข้อมูลสูญหาย ความปลอดภัย การเข้าถึงได้ และทุกสิ่งที่คุณระบุขอโดยตรง นอกจากนี้ยังขอให้มีการตรวจสอบขนาดเล็กที่รันได้ 1 รายการต่อ logic ที่ไม่ใช่เรื่องง่าย กฎนี้ลดการคิดค้นสิ่งใหม่ แต่ไม่ได้ลดความถูกต้อง

สิ่งที่ repository จัดส่งจริง

• AGENTS.md ชุดกฎที่ทำงานตลอดเวลา ซึ่งรวบรวมแนวคิดทั้งหมดไว้ในไฟล์เดียวที่คุณอ่านจบได้ภายในห้านาที
• skills/ponytail/SKILL.md นิยาม skill พร้อมคำแนะนำอาร์กิวเมนต์เป็น lite, full หรือ ultra
• ไฟล์กฎภายใต้ไดเรกทอรีเฉพาะของ editor เช่น .cursor/rules/ และ .windsurf/rules/ สำหรับโฮสต์ที่อ่านกฎได้แต่ไม่โหลด skill
• hooks/, benchmarks/, examples/ และ scripts/

อาร์กิวเมนต์ intensity จะเปลี่ยนระดับความเข้มงวดของกฎ lite จะสร้างสิ่งที่คุณขอ และระบุตัวเลือกที่เข้มงวดน้อยกว่าไว้ในบรรทัดเดียว full เป็นค่าเริ่มต้นและบังคับใช้ลำดับขั้น ultra เป็นการตั้งค่าแบบสุดโต่งตามแนวคิด YAGNI โดยเลือกการลบมากกว่าการเพิ่ม และจะโต้แย้งกับข้อกำหนดนั้นเอง

โฮสต์ที่รองรับ skill จะมีคำสั่ง slash เพิ่มด้วย /ponytail กำหนดระดับ /ponytail-review ตรวจสอบ diff เพื่อค้นหาการออกแบบที่ซับซ้อนเกินจำเป็น /ponytail-audit ตรวจสอบทั้ง repository /ponytail-debt รวบรวมทางลัดที่คุณเลื่อนการทำไว้ และ /ponytail-gain แสดงตารางคะแนน benchmark โฮสต์ที่อ่านได้เฉพาะไฟล์กฎจะได้รับชุดกฎโดยไม่มีคำสั่ง

หากต้องการอ่าน source code ก่อนที่จะเชื่อถือ ให้ clone tag แทน branch:

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

สำหรับ Claude Code เอกสารของโครงการระบุให้ติดตั้ง plugin แทน และ 2 บรรทัดต่อไปนี้เป็นไปตามเอกสาร ณ วันที่ 1 August 2026:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

เส้นทางของ plugin จะอ้างอิง default branch แทน tag ดังนั้นคำสั่งที่ใช้กำกับ agent ของคุณอาจเปลี่ยนแปลงระหว่าง session ได้ นี่คือข้อแลกเปลี่ยนที่คุณยอมรับเพื่อความสะดวกของคำสั่งอัปเดต

เหตุใด agent ที่ทำงานเท่าที่จำเป็นจึงมีค่าใช้จ่ายถูกกว่าบน VPS

diff ที่ agent เขียนจะยังคงอยู่ในบทสนทนา ใน turn ถัดไป model จะอ่าน diff นั้นอีกครั้งในฐานะ context รวมถึงไฟล์ทุกไฟล์ที่ agent เปิดเพื่อสร้าง diff ดังกล่าวด้วย ดังนั้นการเปลี่ยนแปลง 500 บรรทัดจึงเพิ่มภาระให้กับทุก turn ถัดไปใน session ไม่ใช่เฉพาะ turn ที่สร้างการเปลี่ยนแปลงนั้น นี่คือสาเหตุที่การ refactor ที่ขยายเกินขอบเขตทำให้ agent ดูช้าลงและทำงานแย่ลงเมื่อ session ดำเนินต่อไป: window จะเต็มไปด้วย output ของ agent เอง ทำให้พื้นที่ที่เหลือสำหรับโค้ดจริงของคุณลดลง การควบคุมเรื่องนี้คือหัวข้อทั้งหมดของ การจัดการ context window ของ coding agent

ระบบคิดค่าใช้จ่ายทั้ง token ที่ส่งเข้าและ token ที่ส่งออก ดังนั้น diff ที่มีขนาดลดลงครึ่งหนึ่งจึงถูกลง 2 ครั้ง คือถูกลงเมื่อเขียน และถูกลงอีกครั้งในทุก turn ที่อ่าน diff นั้นซ้ำ หากคุณกำลังติดตามค่าใช้จ่ายในระบบ self-hosted ไฟล์คำสั่งเป็นตัวควบคุมที่ใช้งานได้โดยไม่มีค่าใช้จ่าย การควบคุมค่าใช้จ่ายที่ AI agent เรียกเก็บจากคุณ เริ่มต้นจากปริมาณ output และ วิธีที่ coding agent ใช้ token อธิบายว่าเหตุใดการอ่านซ้ำจึงมีผลมากกว่าที่คนส่วนใหญ่คาดไว้

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

บน server ความเสี่ยงจะเปลี่ยนไป เพราะ agent มักทำงานโดยไม่มีใครเฝ้าดู agent ที่ทำงานใน session ของ tmux หรือทำงานตาม timer มีเวลาหลายชั่วโมงในการต่อยอดจากการตัดสินใจที่ผิดพลาดก่อนที่คุณจะเห็น นี่คือความเสี่ยงในทางปฏิบัติของ การเรียกใช้ coding agent บน VPS และเป็นเหตุผลที่ผู้ทำ loop engineering ให้ความสำคัญกับคำสั่งถาวรมากกว่า prompt แต่ละรายการ กฎในไฟล์ที่เปิดใช้งานตลอดเวลาจะมีผลกับ turn 200 ส่วนกฎที่คุณพิมพ์ใน chat จะมีผลกับ turn 3

การเพิ่ม dependency ใหม่เป็นค่าใช้จ่ายแฝงอีกประการหนึ่ง Rung 5 ระบุให้ใช้สิ่งที่ติดตั้งไว้แล้ว ทุก package ที่ agent เพิ่มเองจะเป็นสิ่งที่คุณต้อง patch ในภายหลัง และจะรวมอยู่ในทุก container image ที่คุณสร้างจาก repository นั้น

ตัวเลขการทดสอบประสิทธิภาพของ Ponytail เองระบุว่าอย่างไร

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

[
  {
    "label": "Lines of code",
    "single_shot_pct": 93,
    "agentic_pct": 54
  },
  {
    "label": "Cost per run",
    "single_shot_pct": 63,
    "agentic_pct": 20
  },
  {
    "label": "Wall clock time",
    "single_shot_pct": 74,
    "agentic_pct": 27
  }
]

คอลัมน์ single shot มาจากโมเดลเปล่าที่ตอบชุดพรอมต์ขนาดเล็กทั้งแบบมีและไม่มี rule โดยใช้ค่ามัธยฐานจากการรันซ้ำที่ลงวันที่ 13 และ 17 June 2026 ส่วนคอลัมน์ agentic มาจาก session ของ Claude Code แบบ headless ที่แก้ไข full-stack-fastapi-template ของ tiangolo ซึ่งเป็น repository จริงที่ใช้ FastAPI และ React โดยดำเนินการกับ feature ticket 12 รายการ แต่ละรายการรัน 4 ครั้งด้วย Haiku 4.5 และประเมินจาก git diff ที่เหลืออยู่

ให้พิจารณาคอลัมน์ที่สอง ผลลัพธ์แบบ agentic ใช้บรรทัดโค้ดน้อยลง 54 เปอร์เซ็นต์ มีค่าใช้จ่ายต่ำลง 20 เปอร์เซ็นต์ และใช้เวลา wall clock น้อยลง 27 เปอร์เซ็นต์ เมื่อเทียบกับ 93 เปอร์เซ็นต์และ 74 เปอร์เซ็นต์ตามลำดับสำหรับตัวชี้วัดเดียวกันในการตั้งค่าแบบ single shot README อธิบายเหตุผลไว้อย่างตรงไปตรงมา: baseline แบบ single shot เป็นโมเดลเปล่าที่ “ตอบพร้อมตัวเลือกหลายแบบและคำอธิบายประกอบ” ซึ่งเป็นสิ่งที่เอาชนะได้ง่าย เมื่อวัดเทียบกับ agent จริงที่ทำงานจริง ผลลัพธ์ที่ได้จะลดลง แต่ยังคงเป็นผลลัพธ์จริง ซึ่งเป็นข้อเท็จจริงที่มีประโยชน์มากกว่า

โครงการระบุข้อควรระวังไว้เอง และข้อควรระวังนี้เป็นปัจจัยที่กำหนดว่าแนวทางนี้จะช่วยคุณได้หรือไม่ การประหยัดจะมากที่สุดเมื่อมีความเสี่ยงที่จะพัฒนาระบบเกินความจำเป็นอย่างแท้จริง และเกือบเป็นศูนย์สำหรับโค้ดที่มีขนาดเล็กที่สุดอยู่แล้ว ticket 12 รายการใน repository เดียวที่ใช้ Python และ TypeScript ไม่สามารถใช้ทำนายผลลัพธ์สำหรับ repository ของคุณได้ หากตัวเลขนี้มีความสำคัญต่อคุณ ให้รันการเปรียบเทียบกับ ticket ของคุณเองทั้งแบบมีและไม่มี rule แล้วนับจำนวนบรรทัดด้วยตนเอง

รูปแบบที่คุณคัดลอกไปใช้ได้วันนี้โดยไม่ต้องติดตั้งอะไร

โครงสร้างนี้เป็นข้อความ ดังนั้นคุณจึงไม่จำเป็นต้องติดตั้งปลั๊กอินเพื่อใช้แนวคิดนี้ ให้คัดลอกบล็อกลักษณะนี้ไปไว้ในไฟล์คำสั่งที่เอเจนต์ของคุณอ่านอยู่แล้ว ไม่ว่าจะเป็น AGENTS.md, CLAUDE.md หรือไฟล์กฎของเอดิเตอร์ของคุณ

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

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

# ponytail: global lock, per-account locks if throughput matters

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

ตำแหน่งที่วางบล็อกมีความสำคัญพอๆ กับเนื้อหา ไฟล์ที่เอเจนต์โหลดทุกครั้งจะกำหนดพฤติกรรมของทุกครั้งที่ทำงาน รวมถึงครั้งที่คุณไม่ได้เฝ้าดู ความแตกต่างนี้เป็นหัวข้อของ การเขียน AGENTS.md ที่เอเจนต์ของคุณปฏิบัติตามจริง และเป็นเหตุผลที่ควรเก็บรูปแบบนี้ไว้ในไฟล์ที่ commit แล้ว แทนที่จะเก็บไว้ในประวัติ shell (shell history)

จุดที่กฎนี้ไม่เหมาะสมอีกต่อไป

ลำดับขั้นนี้ออกแบบมาสำหรับการพัฒนาฟีเจอร์ใน codebase ที่มีอยู่แล้ว ซึ่งโดยทั่วไปสามารถนำโค้ดกลับมาใช้ซ้ำได้ และมักเป็นแนวทางที่ถูกต้อง ลำดับขั้นนี้ไม่เหมาะกับโปรเจกต์ greenfield เพราะระดับที่ 2 ไม่มีอะไรให้นำกลับมาใช้ซ้ำ และระดับที่ 5 ไม่มีอะไรติดตั้งไว้ ดังนั้น agent จึงตกไปที่ระดับที่ 7 ทุกครั้ง นอกจากนี้ยังไม่เหมาะในช่วงที่คุณต้องการสร้าง abstraction อย่างแท้จริง หากคุณกำลังจะเพิ่มผู้เรียกใช้บล็อกโค้ดที่คัดลอกไว้เหมือนกันเป็นรายที่ 4 แนวทาง "ส่วนต่างที่สั้นที่สุด" จะทำให้คุณมีสำเนาที่ 5

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

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

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

FAQ

Ponytail ทำงานร่วมกับ agents ที่ไม่ใช่ Claude Code ได้หรือไม่

ได้ Ponytail มีให้ใช้งานในรูปแบบ skill สำหรับ host ที่โหลด skill ได้ ซึ่งรวมถึง Claude Code, Codex, OpenCode, Gemini และรายการอื่น ๆ ที่ระบุไว้ใน README ส่วน editor ที่อ่าน rule file แต่ไม่โหลด skill เช่น Cursor, Windsurf, Cline และ Copilot จะใช้ ruleset ที่ทำงานเสมอจาก rules directory ที่ตรงกัน และจะไม่มี slash command เนื้อหาจะเหมือนกันทั้งสองกรณี ดังนั้นความแตกต่างที่สำคัญคือ host ของคุณเก็บข้อความนั้นไว้ใน context ทุก turn หรือเฉพาะเมื่อมีการเรียกใช้ skill

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

ไม่ และ ruleset ระบุเรื่องนี้ไว้อย่างชัดเจน รายการ "never lazy about" ระบุถึงการตรวจสอบ input ที่ trust boundary, การจัดการ error เพื่อป้องกันข้อมูลสูญหาย, ความปลอดภัยและ accessibility รวมทั้งกำหนดให้มีการตรวจสอบขนาดเล็กที่รันได้ 1 รายการสำหรับ logic ที่ไม่ใช่เรื่องพื้นฐานแต่ละส่วน สิ่งที่ rule นี้ตัดออกคือโครงสร้างที่ถูกสร้างขึ้นโดยไม่มีความจำเป็น เช่น abstraction ที่ไม่มีใครร้องขอและ dependency ที่ไม่มีใครต้องใช้ หาก agent ของคุณเริ่มตัดการทดสอบหลังจากติดตั้งสิ่งนี้ สาเหตุคือมี instruction อื่นใน config ของคุณเองที่มีลำดับความสำคัญสูงกว่า ดังนั้นให้อ่าน file ที่ agent โหลดเป็นลำดับสุดท้าย

ตัวเลขด้านความเร็วและค่าใช้จ่ายที่เผยแพร่ไว้เชื่อถือได้หรือไม่

ตัวเลขเหล่านี้เป็นผลการวัดของโครงการเอง ซึ่งเผยแพร่พร้อมวิธีการวัด และควรอ่านโดยเข้าใจตามนั้น ตัวเลข single shot เปรียบเทียบกับ model เปล่าที่ตอบกลับพร้อมตัวเลือกและคำอธิบายประกอบ ซึ่ง README เองระบุว่าเป็น baseline ที่มีข้อจำกัด ตัวเลข agentic มาจาก session ของ Claude Code แบบ headless บน repository ที่ใช้ FastAPI และ React จำนวน 1 แห่ง มี ticket 12 รายการ ทำการรันรายการละ 4 ครั้ง โดยใช้ Haiku 4.5 ตัวเลขเหล่านี้เป็นตัวเลขที่ถูกต้องสำหรับการตั้งค่านั้น แต่ไม่ใช่การคาดการณ์สำหรับ codebase ของคุณ เพราะโครงการยังระบุด้วยว่าการประหยัดจะลดลงจนเกือบเป็นศูนย์กับ code ที่มีความกระชับอยู่แล้ว

ต้องติดตั้งสิ่งใดเพื่อให้ได้รับประโยชน์หรือไม่

ไม่ ladder นี้เป็นเพียงข้อความ และการวาง block ที่เทียบเท่ากันลงใน instruction file ที่ agent ของคุณอ่านอยู่แล้วจะให้ผลลัพธ์ส่วนใหญ่ได้ plugin ช่วยจัดเตรียม wording ที่มีการดูแลอยู่ ระดับความเข้มข้น command สำหรับ review และแนวทางการอัปเดต การทดลองใช้ block ที่คัดลอกมาก่อนคือคำตอบใน rung 1 สำหรับคำถามว่าจำเป็นต้องติดตั้งหรือไม่

จะหยุด agent ที่ทำงานโดยไม่มีผู้ดูแลไม่ให้สร้างสิ่งต่าง ๆ มากเกินไปตลอดคืนได้อย่างไร

ใส่ rule ไว้ใน instruction file ที่ทำงานเสมอ แทนการใส่ไว้ในข้อความแชต เพื่อให้ rule มีผลใน turn 200 ของการทำงานระยะยาว ไม่ใช่เฉพาะใน turn 3 จากนั้นให้จำกัดความเสียหายแยกต่างหาก โดยให้ agent ใช้ checkout ที่อนุญาตให้ทำเสียหายได้ แทนการใช้สำเนาเดียวที่คุณมี และกำหนดให้มนุษย์ตรวจสอบ diff ก่อน merge ทุกครั้ง rule ที่กำหนดให้ diff มีขนาดเล็กจะลดปริมาณสิ่งที่คุณต้องอ่าน แต่ไม่ได้ตัดสินว่าอะไรจะถูกนำเข้า และไม่ควรทำเช่นนั้น