ให้ Opus 5.5 ทำงานยาวจนเสร็จ: การตั้งค่า Harness Engineering ที่นำกลับมาใช้ใหม่ได้

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

Harness จะคอยประสานคำสั่ง เครื่องมือ สิทธิ์ สถานะ และการตรวจสอบต่าง ๆ ที่อยู่รอบโมเดล

Claude Code มีจุดให้คุณตั้งค่าความรับผิดชอบเหล่านี้อย่างเป็นรูปธรรม คู่มือฟีเจอร์

งานถัดไปสามารถใช้ขั้นตอนและผู้ตรวจคนเดิม พร้อมรูปแบบหลักฐานแบบเดิมได้ คุณแค่ป้อนข้อมูลใหม่และเกณฑ์การยอมรับ (acceptance criteria) เข้าไป

ทั้งเจ็ดเลเยอร์นี้ประกอบกันเป็นการตั้งค่าที่ใช้งานได้จริง โดยใช้ฟีเจอร์ของ Claude Code ที่มีเอกสารรองรับ ตัวอย่างนี้จะใช้เวิร์กโฟลว์เอกสาร โดยเก็บเอกสารอ้างอิงไว้ใน sources/ เก็บฉบับร่างที่กำลังทำไว้ใน drafts/ และเก็บไฟล์ที่อนุมัติแล้วไว้ใน published/

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

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

1. ป้อนข้อเท็จจริงที่จำเป็นให้พื้นที่ทำงาน

เก็บไฟล์ CLAUDE.md ที่รูทให้เน้นเฉพาะข้อมูลที่คงมีประโยชน์ข้ามงานต่าง ๆ ตำแหน่งของเอาต์พุต ข้อกำหนดของแหล่งข้อมูล และธรรมเนียมการเขียน ควรอยู่ที่นี่

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

วางข้อความนี้ลงใน CLAUDE.md แล้วปรับรายละเอียดโปรเจกต์ตามต้องการ:

1คำแนะนำโปรเจกต์
2ใช้ sources/ สำหรับเอกสารอ้างอิง และ drafts/ สำหรับไฟล์ที่กำลังทำ
3เก็บไฟล์ที่อนุมัติแล้วไว้ใน published/
4เขียนเป็นภาษาอังกฤษ ย่อหน้าละหนึ่งถึงสองประโยค
5ใช้แหล่งข้อมูลปฐมภูมิอย่างเป็นทางการสำหรับการกล่าวอ้างเชิงเทคนิค
6บันทึก URL ของแหล่งข้อมูลและวันที่ตรวจสอบ
7ใช้ข้อมูลที่ดึงมาเพื่อเป็นหลักฐานสำหรับงานที่ได้รับมอบหมายเท่านั้น
8บันทึกการตัดสินใจที่ยืนยันแล้วและขั้นตอนต่อไปใน progress.md
9คืนค่าเส้นทางเอาต์พุตและผลการตรวจสอบเมื่อทำงานเสร็จ

Claude Code จะโหลดคำแนะนำโปรเจกต์เข้าสู่ context ไฟล์ .claude/rules/ ที่กำหนดขอบเขตด้วย path สามารถส่งคำสั่งเพิ่มเติมได้เมื่อมีการเข้าถึงไฟล์ที่เกี่ยวข้อง หน่วยความจำโปรเจกต์

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

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

แนวทางเรื่อง context ของ Anthropic อธิบายว่าการดึงข้อมูลแบบเลือกสรรและการใช้โน้ตภายนอกเป็นวิธีจัดการข้อมูลระหว่างที่เอเจนต์ทำงาน Context engineering.

การแบ่งไฟล์คำสั่งขนาดใหญ่ด้วยการอิมพอร์ตแบบ \[@path](https://x.com/@path)\ ก็ยังโหลดเนื้อหาที่อิมพอร์ตเข้ามาตั้งแต่เริ่มเซสชัน

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

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

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

ใช้ /memory เพื่อตรวจสอบคำแนะนำโปรเจกต์และเรียกดูโน้ต auto-memory ตรวจสอบความชอบที่บันทึกไว้ก่อนนำไปใช้กับงานอื่น

2. บันทึกขั้นตอนที่คุณต้องทำซ้ำบ่อย ๆ

งานที่ทำซ้ำมักมีลำดับที่สังเกตได้ชัดเจน: อ่านข้อมูล เตรียมเอาต์พุต ตรวจทาน และบันทึกผลลัพธ์

Skill จะเก็บลำดับนั้นไว้ให้พร้อมใช้ในคำขอครั้งถัดไป

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

คำอธิบายช่วยให้ Claude รู้ว่าขั้นตอนไหนเหมาะกับงานใด การทำงานของ Skill

วางข้อความนี้ลงใน .claude/skills/write-draft/SKILL.md:

1---
2name: write-draft
3description: ร่างบทความจากแหล่งข้อมูลและตรวจสอบความถูกต้องของการกล่าวอ้าง
4---
5หัวข้อที่ต้องการ: $ARGUMENTS
6
71. อ่านไฟล์ที่เกี่ยวข้องใน sources/ และเปิดลิงก์แหล่งข้อมูลปฐมภูมิ
82. เขียนโครงร่าง แล้วบันทึกฉบับร่างเป็น drafts/article.md
93. สั่งให้ evidence-reviewer ตรวจสอบการกล่าวอ้างเชิงข้อเท็จจริงเทียบกับแหล่งข้อมูล
104. แก้ไขข้อผิดพลาดและทำเครื่องหมายการกล่าวอ้างที่ยังไม่ได้ข้อสรุปไว้เพื่อตรวจทาน
115. บันทึกตารางตรวจสอบการกล่าวอ้างเป็น drafts/checks.md
126. อัปเดต progress.md ด้วยการตัดสินใจ ปัญหาที่เปิดอยู่ และขั้นตอนต่อไป
137. คืนค่าทั้งเส้นทางเอาต์พุตและผลการตรวจสอบ

พิมพ์ /write-draft ตามด้วยหัวข้อ \$ARGUMENTS\ จะส่งข้อความนั้นเข้าไปในขั้นตอนการทำงาน ทำให้เวิร์กโฟลว์รับมือกับหัวข้อใหม่โดยได้เอาต์พุตแบบเดิม

กำหนดให้แต่ละขั้นตอนมีผลลัพธ์ที่สังเกตได้

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

ขั้นตอนอย่าง "ตรวจสอบความถูกต้อง" ยังปล่อยให้การตัดสินใจหลายอย่างคลุมเครือ

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

แยกการอนุมัติเผยแพร่ออกจากการเตรียมฉบับร่าง

Skill ด้านบนเตรียมไฟล์ไว้ให้ตรวจสอบ แต่การเผยแพร่ต้องมีขั้นตอนและการอนุญาตของตัวเอง

เมื่อคุณปรับปรุงกระบวนการ ให้แก้ไข skill นั้น

เช่น ถ้าวันเปิดตัวมักถูกสับสนเสมอ ให้เพิ่มการตรวจสอบที่แยกระหว่างวันที่ประกาศกับวันที่ฟีเจอร์เปิดใช้งานจริง

3. เปิดทางให้งานเข้าถึงแหล่งข้อมูลของมัน

การเชื่อมต่อ Model Context Protocol (MCP) จะเปิดเผยเครื่องมือจากบริการภายนอก

ทำให้ Claude ดึงข้อมูลจากบริการที่เวิร์กโฟลว์ของคุณใช้ได้ คู่มือ MCP

เพิ่มการเชื่อมต่อเมื่อมันช่วยสนับสนุนขั้นตอนใดขั้นตอนหนึ่งของงานโดยเฉพาะ

ไฟล์แหล่งข้อมูลในเครื่องใช้งานได้แล้วในตัวอย่างนี้ ส่วนคอลเลกชันเอกสารระยะไกลอาจต้องใช้ connector

ถ้าแหล่งข้อมูลของคุณอยู่ใน Notion ให้รันคำสั่งนี้ในเทอร์มินัล:

1claude mcp add --transport http notion https://mcp.notion.com/mcp

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

ระบุลิงก์หน้าหรือตัวระบุ (identifier) ที่แน่นอนให้ skill บอกด้วยว่าต้องดึงข้อมูลส่วนไหน และข้อมูลที่ดึงมาควรใช้ตรงไหน

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

ผลลัพธ์จากเครื่องมือควรมีข้อมูลมากพอสำหรับการตัดสินใจครั้งต่อไป

แนวทางการออกแบบเครื่องมือของ Anthropic พูดถึงเอาต์พุตที่มีประโยชน์และ error ที่นำไปดำเนินการต่อได้ รวมถึงข้อมูลที่ช่วยให้เอเจนต์กู้คืนจากการเรียกที่ล้มเหลว Writing effective tools

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

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

ปิดใช้งานเซิร์ฟเวอร์ที่ไม่ได้ใช้ผ่าน /mcp เมื่อไม่มีบทบาทในเวิร์กโฟลว์ปัจจุบัน

4. ใส่กฎการดำเนินการไว้ใน execution layer

กำหนดว่าเวิร์กโฟลว์เปลี่ยนไฟล์ใดได้บ้าง และการดำเนินการใดต้องขออนุมัติ

กฎสิทธิ์จะใช้ที่ขอบเขตของเครื่องมือ

Hook แบบ PreToolUse สามารถตรวจสอบการดำเนินการที่เสนอก่อนประมวลผลได้

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

รวมโค้ดนี้เข้ากับ .claude/settings.json:

1{
2  "permissions": {
3    "deny": [
4      "Read(.env)",
5      "Read(.env.*)",
6      "Edit(published/**)"
7    ]
8  }
9}

กฎ `Read` ครอบคลุมไฟล์ environment ที่ระบุไว้ กฎ `Edit` ป้องกันไฟล์ภายใต้ `published/` ผ่านเครื่องมือแก้ไขและเขียนในตัว ไวยากรณ์สิทธิ์.

เปิด `/permissions` และตรวจสอบกฎที่มีผลบังคับใช้

การตั้งค่าที่มีอยู่และนโยบายที่จัดการอาจส่งผลต่อสิ่งที่เซสชันอนุญาต ดังนั้นให้ตรวจสอบผลลัพธ์ที่โหลดหลังจากบันทึกแล้ว

เพื่อทดสอบแบบปลอดภัย ให้สร้างเอกสารจำลองใน `published/` แล้วขอให้ Claude แก้ไขผ่านเครื่องมือแก้ไขไฟล์ การดำเนินการนั้นควรถูกปฏิเสธ

การจำกัดเครื่องมือไฟล์มีขอบเขตที่กำหนดไว้

กระบวนการ Python หรือ Node ใด ๆ สามารถเข้าถึงไฟล์ผ่านโค้ดของตัวเองได้ การทำ sandboxing ระดับระบบปฏิบัติการจะเป็นตัวจำกัดกระบวนการเหล่านั้นเมื่อจำเป็น

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

Timeout ก็ต้องมีขั้นตอนการกู้คืนที่ชัดเจนเช่นกัน

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

5. กำหนดให้ผู้ตรวจทานส่งหลักฐานกลับมา

มอบหมายงานตรวจสอบที่มีขอบเขตชัดเจน พร้อมรายงานที่เอเจนต์หลักนำไปใช้ได้

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

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

ระบุให้ชัดว่าควรรายงานความไม่แน่ใจอย่างไร

วางข้อความนี้ลงใน `.claude/agents/evidence-reviewer.md`:

1---
2name: evidence-reviewer
3description: ตรวจสอบการกล่าวอ้างเชิงข้อเท็จจริงในฉบับร่างโดยใช้แหล่งข้อมูลปฐมภูมิ
4tools: Read, Grep, Glob, WebSearch, WebFetch
5effort: high
6---
7อ่านฉบับร่างที่ได้รับและแหล่งข้อมูลประกอบ
8ตรวจสอบการกล่าวอ้างเชิงข้อเท็จจริงเทียบกับแหล่งข้อมูลปฐมภูมิที่เปิดอยู่
9คืนค่าเป็นตาราง: การกล่าวอ้าง, คำตัดสิน, URL แหล่งข้อมูล, การแก้ไขที่จำเป็น
10ใช้คำตัดสิน: verified, incorrect, unresolved
11สำหรับการกล่าวอ้างแบบ unresolved ให้ระบุว่าขาดหลักฐานส่วนใด

Worker นี้จะได้รับเครื่องมืออ่านและค้นหา

การแก้ไขฉบับร่างยังเป็นหน้าที่ของเอเจนต์หลัก

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

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

คำตัดสินแบบ unresolved ควรระบุว่าขาดหลักฐานอะไร

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

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

แนวทางการประเมินผลของ Anthropic แยก transcript ของเอเจนต์ออกจากผลลัพธ์ที่เหลืออยู่ใน environment

และยังอธิบายวิธีการตรวจสอบที่แตกต่างกันสำหรับผลลัพธ์แต่ละประเภท Agent evaluations

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

ตารางการตรวจทานควรอธิบายเอกสารที่จะได้รับการยอมรับจริง ๆ

6. กำหนดระดับการใช้เหตุผลให้กับงาน

เริ่มเซสชันหลักที่ `medium`; Opus 5.5 จะใช้ค่าเริ่มต้นนี้เว้นแต่จะมีการตั้งค่าอื่นที่ทับซ้อนกัน

ผู้ตรวจทานด้านบนขอระดับ `high` สำหรับงานตรวจสอบ การตั้งค่า Effort

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

1claude --model claude-opus-5-5 --effort medium

ยืนยัน Opus 5.5 และ effort ที่ใช้งานอยู่ในหัวเซสชัน

คำสั่งเริ่มต้นจะกำหนดโมเดลและ effort สำหรับเซสชันนั้น

Effort สามารถตั้งค่าสำหรับ skill หรือ subagent ได้ ขึ้นอยู่กับระดับที่โมเดลรองรับและขีดจำกัดที่ใช้ได้

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

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

การทำแบบนี้จะทำให้ effort เป็นการตัดสินใจที่ผูกกับงานเฉพาะ

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

ก่อนรันครั้งแรก ให้ใช้ `/context` เพื่อตรวจสอบคำสั่งที่โหลดมา `/agents` เพื่อยืนยันผู้ตรวจทาน และ `/permissions` เพื่อตรวจสอบกฎการดำเนินการ

แก้ไขส่วนประกอบที่ขาดหายไปก่อนมอบหมายงานเต็มรูปแบบ

7. บอกรอบรันว่ามันต้องพิสูจน์อะไร

กำหนดความเสร็จสมบูรณ์จาก deliverable ที่บันทึกไว้และผลการตรวจสอบ

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

`/goal` ของ Claude Code จะประเมินเงื่อนไขความเสร็จสมบูรณ์เทียบกับหลักฐานที่ปรากฏในการสนทนาระหว่างเทิร์น ผู้ประเมินอาศัยเอเจนต์ในการแสดงผลลัพธ์ที่เกี่ยวข้อง เอกสาร Goal

ใส่หัวข้อ เอกสารอ้างอิง และลิงก์แหล่งข้อมูลใน `sources/` จากนั้นวางข้อความนี้ใน Claude Code:

1/goal ใช้ write-draft เพื่อเตรียมบทความจาก sources/ ความเสร็จสมบูรณ์ต้องมีไฟล์ drafts/article.md และ drafts/checks.md อยู่จริง การกล่าวอ้างที่ผิดต้องได้รับการแก้ไข การกล่าวอ้างที่ยังไม่ได้ข้อสรุปต้องถูกทำเครื่องหมายอย่างชัดเจน และเส้นทางเอาต์พุตพร้อมผลการตรวจสอบต้องปรากฏในการสนทนา หยุดหลังผ่านไป 12 เทิร์นหากยังไม่ครบเงื่อนไข และรายงานสิ่งที่ติดขัด

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

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

เช็กว่าบันทึกความคืบหน้าตรงกับงานที่บันทึกไว้ในพื้นที่ทำงาน

ใช้รูปแบบหลักฐานเดียวกันสำหรับงานถัดไป

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

สำหรับการกู้คืน `/rewind` สามารถเรียกคืนการแก้ไขไฟล์ที่ติดตามไว้ได้ การเปลี่ยนแปลงใน shell และการแก้ไขส่วนใหญ่ของ subagent ต้องกู้คืนแยกต่างหาก ในขณะที่ version control จะเก็บประวัติไฟล์อย่างถาวร ข้อจำกัดของ Checkpoint

ทดลองรันเวิร์กโฟลว์ทั้งหมดหนึ่งรอบ

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

คัดลอกข้อความนี้ลงใน sources/task.md แล้วเติมรายละเอียด:

1หัวข้อ: [เรื่องที่เจาะจง]
2ผู้อ่าน: [ใครที่ต้องการคำอธิบายนี้]
3Deliverable: บทความที่มีขั้นตอนปฏิบัติได้จริงและแหล่งข้อมูลอย่างเป็นทางการ
4การยอมรับ: ครอบคลุมหัวข้อที่จำเป็น; ตรวจสอบการกล่าวอ้างเชิงข้อเท็จจริงแล้ว;
5ทำเครื่องหมายการกล่าวอ้างที่ยังไม่ได้ข้อสรุป; บันทึกฉบับร่างและตารางตรวจทานแล้ว
6ข้อจำกัด: [ความยาว สไตล์ หัวข้อที่ไม่รวม]

เริ่ม Claude Code ด้วยคำสั่งในเลเยอร์ที่หกและตรวจสอบการตั้งค่าที่โหลดมา => รัน goal ในเลเยอร์ที่เจ็ด แล้วตรวจสอบเอาต์พุตที่บันทึกไว้

ผลลัพธ์ที่คาดหวังคือ `drafts/article.md`, `drafts/checks.md` และ `progress.md`

ตารางตรวจสอบควรระบุว่าอะไรที่ตรวจสอบแล้ว และอะไรที่ยังต้องให้คุณเข้าไปดู

ถ้า skill หายไป ให้ตรวจสอบ path และ frontmatter ของมัน

ถ้าผู้ตรวจทานหายไป ให้ตรวจสอบ `name` และ `description` แล้วยืนยันความพร้อมใช้งานผ่าน `/agents`

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

อุดช่องโหว่นั้นหรือทำเครื่องหมายให้เห็นชัดเจนก่อนยอมรับฉบับร่าง

ตรวจสอบว่าเซสชันถัดไปจะกู้คืนอะไรได้บ้าง

ดูแล `progress.md` หลังจากผ่านขั้นตอนที่มีความหมาย

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

CLAUDE.md ที่รูทจะถูกอ่านใหม่หลังการ compaction

คำสั่งที่จำกัดขอบเขตจะโหลดใหม่เมื่อมีการเข้าถึงไฟล์ที่เกี่ยวข้อง Compaction และหน่วยความจำ

ใช้โครงสร้างกระชับนี้สำหรับบันทึกความคืบหน้า:

1งาน: [หัวข้อปัจจุบัน]
2เอาต์พุต: [เส้นทางฉบับร่างและรายงานตรวจทาน]
3เสร็จสิ้น: [ขั้นตอนและการตรวจสอบที่ทำแล้ว]
4การตัดสินใจ: [ตัวเลือกที่ยืนยันแล้วและแหล่งที่มา]
5ปัญหาที่เปิดอยู่: [หลักฐานที่ขาดหายหรือสิ่งที่ติดขัด]
6ขั้นตอนต่อไป: [ขั้นตอนต่อเนื่องที่เป็นรูปธรรมหนึ่งขั้นตอน]

เริ่มเซสชันใหม่ในพื้นที่ทำงานเดิมแล้ววางข้อความนี้:

1อ่าน progress.md และตรวจสอบฉบับร่างกับการตรวจสอบที่อ้างอิงถึง
2ทำต่อจากขั้นตอนต่อไปที่บันทึกไว้ และอัปเดตบันทึกความคืบหน้า

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

แนวทางเรื่องเอเจนต์ที่ทำงานยาวนานของ Anthropic ใช้บันทึกความคืบหน้าแบบถาวรเพื่อรองรับการทำงานข้ามเซสชัน

ดูแลบันทึกเหล่านั้นเมื่องานเปลี่ยนไป เพื่อให้รอบรันที่กลับมาทำต่อมีข้อมูลล่าสุด Long-running harnesses

วัดประสิทธิภาพการตั้งค่าจากงานที่ได้รับการยอมรับ

ใช้ `/usage` เพื่อตรวจสอบการใช้งานที่รายงาน และ `/context` เพื่อดูว่าอะไรกินพื้นที่ working context อยู่ รวมการตรวจทานที่มอบหมายให้คนอื่นและการลองซ้ำเข้าไปในยอดรวมของงานด้วย แนวทางการใช้งาน

บันทึกเวลาที่คุณใช้ในการตรวจทานและการแก้ไขที่ผลลัพธ์ต้องการ

เอาต์พุตที่ต้องซ่อมแซมอย่างมากจะเปลี่ยนมูลค่าของรอบรันทั้งหมด

รักษางานและเกณฑ์การยอมรับให้คงที่เมื่อทดสอบการเปลี่ยนแปลงการตั้งค่า

ปรับองค์ประกอบเดียว ทำซ้ำงานเดิม แล้วตรวจสอบทั้งผลลัพธ์ที่บันทึกไว้และหลักฐานประกอบ

การลดโทเค็น 60% ที่นัยจากรายงานของผู้ทดสอบช่วงแรกเริ่มของ Anthropic เป็นผลจากการทดลองกับโมเดลนั้น

ให้วัดการประหยัดจาก harness ของคุณเองผ่านการวัดผลงานที่เสร็จสมบูรณ์ ประกาศ Opus 5.5

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

บันทึกสิ่งนี้ไว้เพื่อไม่ให้พลาด

ติดตาม @beamnxw เพื่อรับ alpha เพิ่มเติม :)

=> substack ของฉัน

=> ช่อง telegram ของฉัน