วิศวกรรม Agentic ด้วย Claude Code และ Android CLI

สวัสดี ฉันชื่อ Ben จากทีมนักพัฒนาแอป Android สัมพันธ์

ผมชื่อ Steven เป็นผู้จัดการผลิตภัณฑ์

และวันนี้เราจะมาพูดถึงการสร้างแอปด้วย Claude Code และ Android CLI โดยใช้ Agent

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

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

อีกอย่างคือเราใช้ Claude Code สำหรับการพูดคุยนี้ แต่ข้อมูลนี้ไม่ขึ้นอยู่กับ Agent

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

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

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

และหากคุณได้อ่านข้อมูลจากทีมที่สร้างระบบควบคุมการทำงานของ Agent ทั้งหมดเหล่านี้ ไม่ว่าจะเป็น Claude Code, Codex, Antigravity คุณจะเห็นว่าทีมของพวกเขาพัฒนาเครื่องมือเหล่านั้นด้วยวิธีนี้จริงๆ และหากเรามองว่านี่เป็นภาพอนาคต ก็อาจเป็นทิศทางที่เราทุกคนกำลังมุ่งไป

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

และในฐานะนักพัฒนาซอฟต์แวร์ เราต้องการเครื่องมือและเวิร์กโฟลว์ที่ปรับขนาดได้อย่างชาญฉลาด เพื่อให้งานหนักทั้งหมดของเราไม่ซ้ำซ้อนเมื่อโมเดลใหม่ขยายขอบเขตออกไป

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

วันนี้เราจะพูดถึง 4 หัวข้อด้วยกัน

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

จากนั้นเราจะให้ภาพรวมเกี่ยวกับบริบทและวิธีจัดการบริบทที่ดีที่สุด

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

เอาล่ะ มาเริ่มกันเลย

สภาพแวดล้อม

แต่จริงๆ แล้วหมายความว่าอย่างไร

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

แต่การดำเนินการดังกล่าวมีอะไรมากกว่าแค่การเข้าถึงโค้ด

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

นั่นเป็นสิ่งที่เห็นได้ชัดเจน

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

รวมถึงประวัติการตัดสินใจก่อนหน้านี้และ Pull Request ด้วย

พวกเขาควรจะเห็นความคิดเห็นที่คุณได้รับใน Pull Request, สิ่งที่พวกเขาได้รับการแจ้งเตือน และอื่นๆ จากนั้นคุณจะพบว่าพวกเขาสามารถทำงานและแก้ไขปัญหานั้นได้

นอกจากนี้ คุณคงไม่คาดหวังว่าจะเขียนโค้ด Android ได้โดยไม่ต้องเข้าถึงอุปกรณ์หรือโปรแกรมจำลอง ดังนั้นคุณก็ไม่ควรคาดหวังว่า Agent จะทำเช่นนั้นได้เช่นกัน

ฉันรู้ว่าอุปกรณ์เหล่านี้ดูน่าทึ่งและทำได้ทุกอย่าง แต่โปรแกรมจำลองก็ช่วยได้มากจริงๆ

เครื่องมือวิเคราะห์ก็เช่นกัน

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

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

Android CLI จึงเข้ามามีบทบาทในจุดนี้

หากคุณยังไม่เคยได้ยินเกี่ยวกับเรื่องนี้มาก่อน เราได้พูดถึงเรื่องนี้ในการบรรยายเกี่ยวกับ "มีอะไรใหม่ในเครื่องมือ" ด้วย แต่ Android CLI เป็น CLI ใหม่ของเราสำหรับการเชื่อมต่อกับเครื่องมือต่างๆ ของ Android

ซึ่งไม่ใช่ผลิตภัณฑ์ AI ในตัว แต่เป็นเพียง CLI หรืออินเทอร์เฟซบรรทัดคำสั่ง

ซึ่งจะช่วยให้คุณเข้าถึงสิ่งต่างๆ เช่น เครื่องมือจัดการ Android SDK, การเริ่มโปรแกรมจำลอง และอื่นๆ อีกมากมาย

นอกจากนี้ยังเชื่อมต่อกับเครื่องมือและแบ็กเอนด์อย่าง Crashlytics ด้วย

โดยจะทำงานร่วมกับ Agent ใดก็ตามที่คุณใช้ และจะอยู่ในพื้นที่เชลล์ของคุณ

ประมาณนั้น

คุณติดตั้งได้ที่ลิงก์นี้ แต่เราคิดว่าการดูการทำงานจริงจะง่ายกว่า

โอเค

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

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

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

ทั้งหมดนี้ขับเคลื่อนผ่านโมเดล TF Lite ที่กำหนดเองซึ่งทำงานบนอุปกรณ์ Android โดยตรง

ก่อนอื่น เราอยากบอกว่าเราไม่สามารถแก้ปัญหาที่เราไม่รู้ว่ามีอยู่ได้

ดังนั้น เราจึงใช้ Android CLI เพื่อเพิ่ม Firebase Crashlytics ลงในสภาพแวดล้อมในการพัฒนาซอฟต์แวร์ ซึ่งช่วยให้เราพบปัญหาบางอย่างที่เราไม่รู้ด้วยซ้ำว่าเกิดขึ้น

ข้อแรกคือมีข้อผิดพลาดแอปพลิเคชันไม่ตอบสนองหรือ ANR เกิดขึ้นในอุปกรณ์ Pixel 11 Pro Fold ซึ่งไม่เกิดขึ้นซ้ำในโปรแกรมจำลอง

โชคดีที่ Android CLI รองรับการสตรีมอุปกรณ์ Android

และสิ่งที่ Agent ทำเมื่อเราบอกให้แก้ไขปัญหานี้คือสร้างการเชื่อมต่อกับอุปกรณ์ที่เกิด ANR ซึ่งมีประโยชน์มากสำหรับฉัน เพราะในตอนนั้นฉันไม่มี Pixel 11 Pro Fold เพื่อตรวจสอบการแก้ไขด้วยซ้ำ

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

และเพื่อประหยัดเวลา ฉันได้ทำการทดสอบทั้งหมดไว้ล่วงหน้าแล้ว และได้สรุปไว้ที่นี่

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

ซึ่งเป็นการแก้ไขโค้ดเพียง 2 บรรทัดที่ดูดีสำหรับฉัน

setenv("KMP_AFFINITY", "disabled", 1);
setenv("KMP_INIT_AT_FORK", "false", 1);

ฉันจึงสร้าง Pull Request, ผสานรวม และอัปเดตด้วยบิลด์ใหม่ที่ส่งไปยัง Play

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

ดังนั้นในบิลด์ 1.0 คุณจะเห็นว่าปัญหาได้รับการแก้ไขแล้ว

อย่างไรก็ตาม ปัญหาใหม่ๆ ได้เกิดขึ้นแล้ว และเราจะแก้ไขในภายหลัง

โอเค

ถัดไป: บริบท

เมื่อประมาณ 1 ปีครึ่งถึง 2 ปีก่อน ซึ่งก็ไม่นานนัก แต่ในแวดวง AI ถือว่านานมาก มีการแข่งขันกันเพื่อสร้างหน้าต่างบริบทที่ใหญ่ขึ้นเรื่อยๆ และทฤษฎีก็คือ ยิ่งเราป้อนข้อมูลให้โมเดลได้มากเท่าไร ผลลัพธ์ที่ได้ก็จะยิ่งดีขึ้นเท่านั้น และเราก็ทำสิ่งบ้าๆ อย่างการพยายามใส่ developer.android.com ทั้งหมดลงในพรอมต์ ซึ่งไม่ได้ผลจริงๆ

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

นี่คือ Android Bench 1.0

Android Bench คือการเปรียบเทียบความสามารถของ AI ในการเขียนโค้ด Android

งานในนั้นสมจริง

สิ่งเหล่านี้คือสิ่งที่คุณกำลังพัฒนา และเราจะเห็นว่าหน้าต่างบริบทคงที่อยู่ที่ 1 ล้านโทเค็น แต่ความสามารถของโมเดลยังคงเพิ่มขึ้นเรื่อยๆ

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

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

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

ผลลัพธ์ที่ได้จะแย่ลงเมื่อทำเช่นนั้น

ซึ่งจริงๆ แล้วมีจุดที่เหมาะสมอยู่ และจะเปลี่ยนแปลงไปตามโมเดล แต่หากคุณสามารถจำกัดการสนทนาไว้ที่ประมาณ 150,000 โทเค็น คุณจะได้รับประสิทธิภาพสูงสุดจากโมเดลโดยไม่มีปัญหาบริบทเน่า

แต่บริบทไม่ได้เป็นเพียงสิ่งที่คุณพิมพ์เท่านั้น

[
  {
    "role": "system",
    "content": "You are an expert Android engineering agent..."
  },
  {
    "role": "workspace_context",
    "content": { "project_root": "/workspace/android-app", "build_system": "Gradle (Kotlin DSL)", "target_sdk": 35 }
  },
  {
    "role": "available_tools",
    "content": [ { "name": "read_file" }, { "name": "edit_file" }, { "name": "bash" }, { "name": "skill_android_cli" } ]
  },
  {
    "role": "user",
    "content": "ProfileViewModelTest is failing when loading errors. Fix the ViewModel and verify with unit tests."
  },
  {
    "role": "assistant",
    "tool_calls": [ { "name": "read_file", "arguments": { "path": "app/src/main/.../ProfileViewModel.kt" } } ]
  },
  {
    "role": "tool",
    "content": "class ProfileViewModel(...) : ViewModel() { ... // full file contents + Gradle output appended here }"
  }
]

จริงๆ แล้วมีหลายสิ่งหลายอย่างเกิดขึ้นเบื้องหลังที่คุณไม่เห็น

ซึ่งประกอบด้วยหลายส่วน

อย่างแรกคือคำสั่งของระบบ

คำสั่งของระบบมาจากตัวแทนของคุณ

ซึ่งก็เหมือนกับพรอมต์ที่บอกวิธีทำงานกับ Agent นี้ รวมถึงลักษณะการทำงานที่ควรทำ

แต่ยังมีข้อมูลพื้นที่ทำงานด้วย เช่น ไดเรกทอรีการทำงานปัจจุบันของคุณ, SDK ที่คุณมี, ทักษะที่ติดตั้งไว้ ซึ่งเราจะพูดถึงในอีกสักครู่ และเครื่องมือ MCP, เครื่องมือใดๆ ที่ Agent ของคุณมีให้ด้วย

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

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

ซึ่งอาจใช้เวลานานมาก โดยเฉพาะเมื่อใช้ Gradle

อย่างที่เราทราบกันดีว่าบันทึกของ Gradle นั้นยาวมาก ยาวมากๆ และมีรายละเอียดเยอะมาก

คุณไม่จำเป็นต้องใช้ข้อมูลส่วนใหญ่เหล่านี้

เราจึงมีเคล็ดลับสั้นๆ มาฝากเพื่อช่วยให้คุณระวังเรื่องนี้

คุณเรียกใช้ Gradle ในโหมดเงียบได้

./gradlew assembleDebug --quiet

หรือระบบควบคุมการทำงานของ Agent ที่ใหญ่กว่าจะตัดข้อความนี้ให้คุณ

ดังนั้น Claude Code และ Android Studio จึงไม่ได้ส่งบันทึก Gradle ทั้งหมดขึ้นไป

แต่หากคุณใช้ Agent ที่มีขนาดเล็กที่สุด เนื่องจากแนวคิดทั้งหมดของ Agent ประเภทนี้คือการส่งทุกอย่างไปยังโมเดล โดยโมเดลจะรู้ดีที่สุด ดังนั้น mini-SWE-agent จึงส่งบันทึก Gradle ทั้งหมด ซึ่งอาจทำให้มีค่าใช้จ่ายสูงมากอย่างรวดเร็ว

แต่เราจะทำอย่างไรให้อยู่ภายในกรอบเวลา 150,000 ปีนี้

หัวใจสำคัญคือการใช้เวิร์กโฟลว์

และมีเวิร์กโฟลว์มากมายให้เลือกใช้

ช่องที่ฉันชอบมากคือช่องของ Matt Pocock ซึ่งมีชุดทักษะที่จะช่วยคุณจัดการเซสชันเหล่านี้ได้

ดังนั้นจึงเริ่มต้นด้วยทักษะที่เรียกว่า "grill-me"

สิ่งที่คุณต้องทำคือเรียกใช้ทักษะนี้เมื่อเริ่มโปรเจ็กต์ใหม่หรือฟีเจอร์ใหม่ภายในโปรเจ็กต์ แล้วทักษะนี้จะทำให้ Agent ถามคำถามคุณหลายข้อ

คุณจึงอาจพูดว่า "grill-me"

ฉันอยากสร้างตัวจัดการการปลุกตามเวลาแบบใหม่ในแอปของฉัน"

จากนั้นระบบจะเริ่มถามคำถามกลับมา เช่น เราควรนำไปใช้กับอะไร และควรนำไปไว้ที่ไหน

และช่วยขจัดความคลุมเครือทั้งหมดออกจากปัญหาและออกจากหัวของคุณลงไปในกระดาษเป็นประเด็น

จากนั้นเราจะเรียกใช้ทักษะถัดไป ซึ่งเป็นการเขียนเอกสารข้อมูลจำเพาะขนาดใหญ่

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

และแนวคิดก็คือปัญหาแต่ละรายการควรจะพอดีกับหน้าต่าง 150,000 รายการโดยประมาณ

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

โอเค

ต่อไปเรามาพูดถึง AGENTS.md กันบ้าง

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

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

ดังนั้น สิ่งที่ได้ผลคือสถาปัตยกรรมและกฎของโมดูล

ซึ่งเป็นสิ่งที่ Agent ของคุณอาจไม่ทราบ โดยเฉพาะอย่างยิ่งหากคุณทำงานในแอปโคลสซอร์ส

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

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

# AGENTS.md

- UI components belong in :core:designsystem

- Never use java.util.Date;
  always use kotlinx.datetime

## General guidance
- Avoid changing public API signatures. Anything under an `internal` directory
  is not part of the public API and may change freely.
- The SDK code is written for Java 8.

ดังนั้น คุณก็ทราบดีว่าในโปรเจ็กต์นี้ เราต้องการใช้ kotlinx.datetime อะไรทำนองนั้น

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

โมเดลต่างๆ มีลักษณะการทำงานที่แตกต่างกันเมื่อพูดถึงบริบทเพิ่มเติม

ตัวอย่างเช่น ย้อนกลับไปในสมัย Opus 4.6 การใช้ตัวพิมพ์ใหญ่ขนาดใหญ่ที่เขียนว่า "อย่าทำเช่นนี้" เป็นเรื่องปกติมาก

และเมื่อ Opus 5 เปิดตัว Anthropic ก็ออกแถลงการณ์ว่า "จริงๆ แล้ว ตัวพิมพ์ใหญ่ใช้ไม่ได้ผลดีอีกต่อไป

ใช้ตัวพิมพ์เล็กเท่านั้น"

นี่คือสิ่งที่ผมหมายถึง คุณต้องคอยติดตามข้อมูลอยู่เสมอ

แต่สิ่งหนึ่งที่ยังคงเป็นสากลคือการทำให้สั้นกระชับ

ดังนั้นโปรดเขียนโค้ดให้มีความยาวไม่เกิน 250 บรรทัด

และข้อถัดไปนี้อาจทำให้เกิดความเห็นที่แตกต่างกัน เพราะฉันรู้ว่าหลายคนชอบทำแบบนี้ แต่มีการศึกษาที่เผยแพร่เมื่อเดือนกุมภาพันธ์ปีนี้ที่แสดงให้เห็นว่าหากคุณปล่อยให้ Agent แก้ไข AGENTS.md ของตัวเอง ประสิทธิภาพจะลดลงประมาณ 2-3% ซึ่งก็ไม่ได้เป็นเรื่องใหญ่อะไร

แต่ส่วนสำคัญคือต้นทุนเพิ่มขึ้น 20%

ดังนั้น ประสิทธิภาพจึงลดลงเล็กน้อยและค่าใช้จ่ายก็เพิ่มขึ้นอย่างมาก ทั้งหมดนี้เกิดจากการปล่อยให้ Agent เขียน AGENTS.md ของตัวเอง

วิธีแก้ปัญหาที่ฉันเคยเห็นคือ คุณสามารถให้ Agent เขียนสรุปย้อนหลังเมื่อสิ้นสุด Pull Request แต่ละรายการ จากนั้นคุณในฐานะทีมสามารถอ่านสรุปย้อนหลังทั้งหมดร่วมกันและตัดสินใจว่าจะทำการแก้ไขอะไรบ้าง เนื่องจากไฟล์นี้กำลังกลายเป็นส่วนสำคัญของโครงสร้างพื้นฐานที่สำคัญของทีม หากคุณทำงานในทีมขนาดใหญ่ที่มี Agent

เราจะแสดง AGENTS.md สำหรับแอปพลิเคชัน Sideline ที่เราสร้างขึ้นให้ดูอย่างรวดเร็ว

มี 2 สิ่งที่เราอยากจะพูดถึงในที่นี้

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

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

ซึ่งเป็นแนวทางที่ชัดเจนมากให้ AI ทำตาม

และประเด็นที่ 2 ที่เราต้องการเน้นย้ำคือเรื่องแอปพลิเคชันโคลสซอร์สโดยเฉพาะ

แน่นอนว่าหากคุณเป็นโคลสซอร์ส จะไม่มี Agent ใดที่สามารถใช้ LLM เพื่อฝึกในฐานของโค้ดของคุณได้

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

ดังนั้น หากเราไม่ควรใส่ทุกอย่างไว้ใน AGENTS.md เราจะเปลี่ยนลักษณะการทำงานของ Agent หรือโมเดลได้อย่างไร

อย่างแรกคือฮุก ซึ่งเหมาะมากสำหรับสิ่งที่ผู้คนใส่ไว้ใน AGENTS.md เช่น ให้เรียกใช้ Linter เสมอเมื่อเขียนเสร็จ

// settings.json

"hooks": {
  "Stop": [{
    "command": "./gradlew lintDebug"
  }]
}

ซึ่งอาจเป็นฮุกได้

ฮุกคือ Agent ของคุณจะแสดงเหตุการณ์ทั้งหมดเหล่านี้ที่คุณสามารถสมัครรับข้อมูลได้ และมีเหตุการณ์สำหรับเกือบทุกอย่างที่คุณนึกออก แต่เหตุการณ์หลักๆ คือเริ่มเซสชัน หยุดเซสชัน อ่านและเขียนไฟล์

ดังนั้น แทนที่จะเขียนไว้ที่ด้านล่างของ AGENTS.md ว่า "เรียกใช้ Linter เสมอ" หรือ "เรียกใช้ชุดโปรแกรมทดสอบของฉันเสมอก่อนที่จะบอกว่าเสร็จแล้ว" คุณก็แค่ใช้ Stop Hook แทน ซึ่งสามารถเรียกใช้สคริปต์เชิงกำหนดได้ และช่วยควบคุมความสุ่มเล็กน้อยของ AI

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

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

เป็นเพียงวิธีเพิ่มความแน่นอน

ส่วนถัดไปคือทักษะ

และตอนนี้ก็มีทักษะในการเปลี่ยนAGENTS.mdให้เป็นฮุกด้วย

นั่นเป็นอีกเรื่องหนึ่งเลย

แต่ทักษะคือวิธีเพิ่มบริบทเฉพาะเมื่อมีความเกี่ยวข้องเท่านั้น

ดังนั้น AGENTS.md จึงเหมาะสำหรับสิ่งที่มีความเกี่ยวข้องอยู่เสมอ

ทักษะมีไว้สำหรับสิ่งที่เกี่ยวข้องในบางสถานการณ์ โดยเฉพาะเอกสารประกอบ

ดังนั้นทักษะจึงประกอบด้วย 3 ส่วน ได้แก่ ชื่อ คำอธิบาย และส่วนสำคัญคือคำอธิบายนี้จำกัดไว้ที่ 1,024 อักขระ และมีเนื้อหา

---

name: android-cli
description: >
  Loaded into context (≤1024 chars)
---
# Skill Body

และเนื้อหาอาจมีขนาดใหญ่มาก โดยอาจรวมสคริปต์อื่นๆ ไว้ด้วย ซึ่งเป็นเรื่องปกติ

คุณใช้ทักษะทำสิ่งต่างๆ ได้มากมาย

มาดูตัวอย่างกัน

นี่คือคำอธิบายของ Android CLI

คุณไม่จำเป็นต้องอ่านทั้งหมดนั้น

โปรดทราบว่านี่เป็นคำอธิบายสั้นๆ ที่อธิบายว่า Android CLI มีความเกี่ยวข้องเมื่อใด

และนี่คือเนื้อหา

ซึ่งมีขนาดใหญ่มาก เราจึงไม่ต้องการโหลดข้อมูลทั้งหมดนี้ตลอดเวลา

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

แต่คุณควรเลือกทักษะที่จะติดตั้งอย่างรอบคอบ

เราไม่ต้องการติดตั้งที่เก็บโค้ดเหล่านั้นที่เราเห็นทางออนไลน์ซึ่งมีทักษะด้านวิศวกรรมที่เน้น Agent หลายร้อยรายการโดยไม่ตรวจสอบก่อน

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

คุณไม่รู้เลยว่ามีอะไรอยู่ในทักษะเหล่านั้น ซึ่งอาจเป็นการบอกให้ Agent ทำอะไรก็ได้

และเรามีชุดทักษะ Android ซึ่งเรารับรองว่าได้ตรวจสอบแล้วว่าไม่มีการพูดถึงเรื่องดังกล่าว

แต่ข้อ 2 คือคำอธิบาย 100 รายการคูณ 1,000 อักขระเท่ากับ 100,000 อักขระที่คุณเพิ่งเพิ่มเข้าไปก่อนที่จะเริ่มเขียนโค้ดด้วยซ้ำ

คุณจึงใกล้จะถึงเกณฑ์นั้นแล้ว

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

> android init

✓ Installed base skill: android-cli

# Audit & add skills only when needed:
> android skills find compose
> android skills add edge-to-edge

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

แน่นอนว่ามีทักษะในการตรวจสอบทักษะ

ดังนั้นจึงมี /skill-doctor ใน Claude Code ซึ่งจะดูและบอกคุณว่าคุณรวมทักษะใดไว้บ้างที่ไม่ได้เปิดใช้งานเลย คุณจึงเสียคำอธิบายความยาว 1,000 อักขระไปเปล่าๆ

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

ขอย้ำอีกครั้งว่า Android CLI คือลิงก์ดังกล่าว

แต่มีคำสั่งรายการทักษะ และสมมติว่าคุณมี Navigation 3 ในโปรเจ็กต์

android skills list
android skills add navigation-3

Navigation 3 เป็นไลบรารีที่ค่อนข้างใหม่ จึงยังไม่มีการฝึกอบรมมากนัก คุณสามารถเพิ่มทักษะ Navigation 3 ได้

เรามักจะ... อ้อ ขอโทษที

ถัดไปคือ MCP

แต่เรามักได้รับคำถามว่าทำไมเราจึงสร้าง Android CLI เป็น CLI ไม่ใช่เซิร์ฟเวอร์ MCP

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

นอกจากนี้ เกณฑ์มาตรฐานอย่าง Terminal Bench ได้กลายเป็นเกณฑ์มาตรฐานที่ใหญ่ที่สุดในด้านวิศวกรรมซอฟต์แวร์ ดังนั้นผู้สร้างโมเดลจึงพยายามอย่างหนักในการแข่งขันกับการใช้งานเทอร์มินัล ทำให้ปัจจุบันโมเดลเหล่านี้มีความเชี่ยวชาญในการใช้ CLI เป็นอย่างมาก

แต่ก็ไม่ได้หมายความว่า MCP จะไม่มีประโยชน์เลย

เซิร์ฟเวอร์ MCP เหมาะอย่างยิ่งสำหรับบริการภายนอกที่คุณใช้อยู่แล้ว โดยเฉพาะอย่างยิ่งหากบริการเหล่านั้นโฮสต์บริการ MCP อยู่แล้ว

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

แพลตฟอร์มต่างๆ เช่น GitHub, Figma, Slack กำลังเปิดเผยเซิร์ฟเวอร์ MCP อยู่ในขณะนี้

และสิ่งที่เราเรียกใช้ใน Shell มาโดยตลอดก็ยังคงอยู่ใน Shell ได้ ดังนั้นคำสั่ง Android ผ่าน Android CLI รวมถึง Perfetto และ Gradle จึงควรอยู่ในเครื่องซึ่งมีสิทธิ์เข้าถึงทุกอย่างที่คุณใช้ในการพัฒนา

และฉันเคยทำงานด้านประสิทธิภาพ

ผมเคยพูดเสมอว่า Perfetto เป็นเครื่องมือเดียวที่คุณต้องใช้ในการแก้ปัญหาด้านประสิทธิภาพ

แต่การเรียนรู้ก็เป็นเรื่องยากมาก ดังที่เราได้เห็นในการพูดคุยครั้งล่าสุดจาก Rahul

มาดูกันว่า AI จะช่วยปรับปรุงประสิทธิภาพได้อย่างไร

ขอบคุณ Ben

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

และอย่างที่คุณเห็นใน Pixel 10 Pro Fold เครื่องนี้ เราทำได้เพียงประมาณ 20-22 เฟรมต่อวินาทีเท่านั้น

เฟรมที่หายไปเหล่านี้จะเป็นปัญหา เนื่องจากหมายความว่าแอปพลิเคชันจะไม่ทำงานตามที่โฆษณาไว้ ดังนั้นเราจึงจำเป็นต้องแก้ไขปัญหานี้จริงๆ

Android CLI มีคำสั่ง Android Profiler

และเมื่อเราเพิ่มลงในเอเจนต์การเขียนโค้ด และสั่งให้เอเจนต์ทำตามข้อกำหนด 30 เฟรมต่อวินาทีนี้ สิ่งที่น่าสนใจ 2 อย่างก็เกิดขึ้น

วิธีแรกคือการค้นหาการแก้ไขโดยใช้คำสั่ง Android Profiler

โดยได้บันทึกการติดตามของระบบในอุปกรณ์ Pixel 10 Pro Fold ที่แนบมา และพบว่าเทรด AI ทำงานบนคอร์ที่ช้าที่สุดในอุปกรณ์

และข้อที่ 2 คือใช้การค้นหาเอกสาร Android ซึ่งน่าสนใจตรงที่ไม่ได้ขอให้เราทำอย่างชัดเจน และดึงคำแนะนำอย่างเป็นทางการสำหรับ Performance Hint API

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

ดังนั้น สิ่งที่เกิดขึ้นคือการแก้ไขเป็นไปตามคำแนะนำ

ดังนั้นสำหรับ Android CLI สิ่งสำคัญคือการเชื่อมต่อกับ Agent ซึ่งจะช่วยให้คุณค้นหาเครื่องมือที่เหมาะสมได้ แม้ว่าคุณจะไม่คุ้นเคยกับเครื่องมือนั้นก็ตาม ไม่ว่าจะเป็นงานใดก็ตามที่คุณต้องทำให้สำเร็จ

เมื่อเราเรียกใช้ คุณจะเห็นว่า Sideline มีคุณสมบัติตรงตามข้อกำหนด 30 เฟรมต่อวินาทีที่ผู้ใช้ต้องการ และตอนนี้ก็ทำงานบน Pixel 10 Pro Fold ได้แล้ว

โอเค

ตอนนี้เราจะนำทุกอย่างมารวมกันด้วยลูป

ผมแน่ใจว่าเราทุกคนเคยทำแบบนี้ คุณขอให้ Agent ทำการเปลี่ยนแปลงครั้งใหญ่ แล้ว Agent ก็กลับมาบอกว่าทำเสร็จแล้ว

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

เราต้องหยุดทำหน้าที่เป็นผู้ทดสอบ QA ของ Agent และกำหนดล่วงหน้าว่าเราจะถือว่างานเสร็จสมบูรณ์เมื่อใด

ตัวอย่างเช่น

เราต้องการย้ายข้อมูลทั้งโปรเจ็กต์ไปยัง Nav3 จากนั้น Agent จะหายไป ซึ่งใช้เวลาสักพัก แต่จะกลับมาอย่างมั่นใจและบอกว่า "การย้ายข้อมูลเสร็จสมบูรณ์

ฉันเก่งที่สุด"

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

ซึ่งก็คล้ายกับโลกที่เราอาศัยอยู่ในปัจจุบัน

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

ดังนั้น เราควรกำหนดสิ่งที่เราคาดหวังไว้ล่วงหน้าทั้งหมดก่อน ซึ่งจะช่วยให้ Agent ทำงานวนซ้ำจนกว่าจะตรงตามเกณฑ์ทั้งหมดเหล่านั้น

นั่นคือสิ่งที่เรียกว่าลูปการยืนยัน

และเรามีข้อมูลที่ชัดเจนเกี่ยวกับประสิทธิภาพของวิธีนี้

นี่คือ Android Bench 2.0 ซึ่งเป็นเวอร์ชันใหม่ของเบนช์มาร์ก AI ที่ผมพูดถึงไปตอนต้นของการบรรยาย

ปัจจุบันอัตราการผ่านอยู่ที่ประมาณ 40%

งานเหล่านี้ยากมาก ทั้งยังเป็นงานใหญ่และสมจริง แต่หนึ่งในนั้นคือ Nav2 ถึง Nav3 ซึ่งเป็นงานประเภทที่คุณกำลังทำในโปรเจ็กต์ของคุณขณะนี้

และหากเราใช้ Fable 5.1 อัตราการผ่านจะอยู่ที่ 22% ซึ่งเป็นอัตราที่ได้จากการตั้งค่าพรอมต์ตามธรรมชาติ เช่น "ย้ายข้อมูล Nav2 ไปยัง Nav3"

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

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

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

ลูปการยืนยันอาจเป็นเพียงการเพิ่มพรอมต์ง่ายๆ

สมมติว่าคุณกำลังทำงานใน UI คุณสามารถขอให้แสดงตัวอย่าง Compose และตรวจสอบว่าตรงกับข้อกำหนดของ Figma หรือไม่ แล้วแสดงผลลัพธ์ให้คุณดู

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

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

จริงๆ แล้ว Claude Code มีทักษะในตัวที่ช่วยคุณสร้างลูปการยืนยันได้แล้ว

ดังนั้นอย่าลืมไปดูนะ

และหากคุณทำงานใน Android Studio โดยนำ Agent ของคุณมาเอง Android Studio จะแสดงเครื่องมือมากมายที่คุณสามารถสร้างลูปได้โดยขึ้นอยู่กับสิ่งที่คุณกำลังทำอยู่

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

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

แต่เส้นทางอาจใช้เวลาสักพักในการทำงาน

ดังนั้น สิ่งที่คุณทำได้อีกอย่างคือการจัดระดับลูปการยืนยัน

เราจึงขอให้ Gemini ตรวจสอบก่อนว่า Unit Test และ Compose Preview แสดงผลอย่างถูกต้องทั้งหมด

และเมื่อผ่านแล้ว โปรดเรียกใช้การทดสอบที่เชื่อมต่อและ Android Journeys และเมื่อผ่านแล้วเท่านั้น ให้เรียกใช้ห้องปฏิบัติการทดสอบอุปกรณ์ระยะไกลแบบเต็มรูปแบบ ซึ่งเป็นชุดโปรแกรมทดสอบแบบเต็มรูปแบบที่จะใช้เวลาหลายชั่วโมง

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

เพราะโมเดลมีความมั่นใจมาก

ดังนั้นจึงมักคิดว่าตนเองทำเสร็จแล้ว และคิดว่าจะผ่านการทดสอบทั้งหมดตั้งแต่ครั้งแรก

มาดูฟีเจอร์นี้ใน Sideline กัน

เรามาลองใช้แนวคิดนี้กับแอปพลิเคชัน Sideline กัน โดยเพิ่มฟีเจอร์ใหม่สำหรับแว่นตา XR โดยเฉพาะ ซึ่งจะเปิดตัวเร็วๆ นี้

และเนื่องจากเรายังไม่มีฮาร์ดแวร์ แน่นอนว่าเราจะใช้โปรแกรมจำลอง XR และสั่งให้ Agent การเขียนโค้ดขยาย Sideline สำหรับรูปแบบของอุปกรณ์ใหม่

เมื่อทำเช่นนั้น เราจะขอให้ Agent ทำการทดสอบ JVM, การทดสอบ Compose Preview และการทดสอบโปรแกรมจำลองตามลำดับนั้นๆ

และแต่ละลูปจะได้รับคำสั่งให้สร้างต่อจากลูปก่อนหน้า

เมื่อทำเช่นนี้ สิ่งแรกที่เราสังเกตเห็นคือระหว่างลูป 1 และ 2 การทดสอบ JVM จะใช้เพื่อกำหนดสถานะตัวอย่าง Compose ทั้ง 6 สถานะ

แน่นอนว่าไม่มีการเรียกใช้โปรแกรมจำลอง จึงทำงานได้เร็วมาก

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

สุดท้าย เมื่อลูปโปรแกรมจำลองทำงาน ก็จะพบบั๊กเพิ่มเติมที่การทดสอบ JVM และตัวอย่าง Compose แก้ไขไม่ได้

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

และนี่คือผลลัพธ์

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

และเราได้พูดถึงก่อนหน้านี้ว่าเราจะกลับไปดูปัญหา Crashlytics 2 รายการที่เกิดขึ้นก่อนหน้านี้

ดังนั้น เนื่องจากเราสามารถตรวจสอบได้แล้วว่าแนวทางดังกล่าวได้ผล เราจึงสามารถใช้คำสั่ง /schedule ใน Claude Code เพื่อวนซ้ำได้ และเราสามารถตั้งค่าความถี่ใดก็ได้ที่ต้องการ เพื่อให้ตอนนี้เรามีแอปพลิเคชันที่แก้ไขตัวเองได้ ซึ่งจะแก้ไขข้อบกพร่องทั้งหมดและตรวจสอบว่าได้รับการแก้ไขแล้ว ส่งเป็น Pull Request ไปยังวิศวกรของเราเพื่อดูและผสานรวม

เยี่ยมเลย

วันนี้มีเพียงเท่านี้

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

นี่คือวิธีที่เราปลดล็อกตัวแทนแบบคู่ขนาน

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

และนี่คือความเป็นจริงของสภาพแวดล้อมที่เปลี่ยนแปลงอย่างรวดเร็วนี้

ดังนั้น สิ่งที่ดีที่สุดที่คุณทำได้คือเขียนการประเมินของคุณเองสำหรับโปรเจ็กต์

และเมื่อมีคำแนะนำใหม่หรือโมเดลใหม่ คุณจะวัดผลและดูได้ว่าช่วยคุณได้จริงหรือไม่

และแน่นอนว่ามีทักษะสำหรับทุกสิ่ง

มีทักษะที่จะช่วยคุณสร้างการประเมินใน Claude Code

/claude-api build-eval

เราขอแนะนำให้ลองดู

วันนี้ฉันได้พูดถึง Android Bench ไปแล้ว

Android Bench คือการประเมินของเรา

ซึ่งเป็นวิธีที่เราวัดผลเพื่อให้แน่ใจว่าสิ่งต่างๆ ดีขึ้น

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

นอกจากนี้ยังมีแผงอีก 2 แผง

มีที่สหรัฐอเมริกาและลอนดอน

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

เราจึงได้เชิญสมาชิกชุมชนนักพัฒนาแอป Android มาร่วมพูดคุยในแผงสนทนาเกี่ยวกับวิธีที่พวกเขานำแนวคิดนี้ไปใช้จริงในงานของตน

นอกจากนี้ เรายังต้องการความคิดเห็นจากคุณด้วย

เราอยากทราบว่าเรากำลังสร้างสิ่งที่ช่วยคุณได้จริงๆ หรือไม่

โปรดกรอกแบบสำรวจ

ฉันจะแสดงข้อมูลนั้นไว้บนหน้าจอ

และใช่

ขอขอบคุณที่รับฟัง

ขอขอบคุณ