วิธีสร้างระบบ Outbound ที่พัฒนาตัวเองได้บน Codex

เมื่อต้นปีนี้ Andrej Karpathy (@karpathy) ชี้เอเยนต์ไปที่โค้ดเทรนของตัวเองแล้วปล่อยให้มันทำงานเป็นเวลาสองวัน มันรันการทดลอง 700 ครั้ง, เก็บไว้ 20 ครั้งที่เอาชนะเกณฑ์มาตรฐาน, และทำให้โมเดลเทรนเร็วขึ้น 11% จากนั้นเขาก็พูดอะไรที่น่าสนใจมาก: เมตริกใดๆ ที่คุณสามารถประเมินได้ด้วยต้นทุนต่ำ สามารถส่งมอบให้ฝูงเอเยนต์จัดการได้

อัตราการตอบกลับเป็นเมตริกที่คุณสามารถประเมินได้ด้วยต้นทุนต่ำ ฉันใช้เวลาพอสมควรตั้งแต่นั้นมาเพื่อหาว่าลูปนั้นหน้าตาเป็นยังไงเมื่อชี้ไปที่การส่งออก (outbound)

การสร้างของฉัน:

Codex อ่านผลลัพธ์ของสัปดาห์ที่แล้ว, แก้ไขไฟล์การให้คะแนนและ play files ที่ระบบ outbound ใช้, รันการทดสอบ, และเปิด pull request มันเสนอการเปลี่ยนแปลงเพลย์บุ๊กพร้อมหลักฐานและคะแนนที่แนบมา จากนั้นรอให้มนุษย์อนุมัติ การส่งและการรวมโค้ด (merge) ยังคงอยู่นอกลูป

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

นี่คือสิ่งที่สร้างขึ้น: GTM (Go-to-Market) เป็นโค้ดที่มีการกำหนดเวอร์ชันซึ่งปรับปรุงจากตลาด

repo

เริ่มต้นที่โฟลเดอร์ โครงสร้างมีความสำคัญเพราะ Codex สามารถปรับปรุงเฉพาะสิ่งที่มันอ่านและแก้ไขได้

1codex-self-improving-outbound/
2  AGENTS.md
3  README.md
4  config/
5    scoring.yaml
6    plays.yaml
7  prompts/
8    improve_scoring.md
9    improve_prompt.md
10    pr_summary.md
11  memory/
12    outcomes.jsonl
13  evals/
14    fixtures.yaml
15    score.py
16  scripts/
17    append_outcome.py
18    run_codex_step.sh
19    propose_improvement.py
20    open_pr.sh
21    weekly_tune.sh
22  examples/
23    outcomes.sample.jsonl
24    weekly-pr.md

repo นั้นตั้งใจให้เรียบง่าย config/scoring.yaml เก็บกฎที่ตัดสินว่าสัญญาณใดสำคัญ prompts/ เก็บ plays ที่เขียนข้อความ memory/outcomes.jsonl เก็บสิ่งที่ตลาดทำ evals/score.py คือประตูที่บอกว่าการเปลี่ยนแปลงที่เสนอนั้นช่วยได้หรือไม่ AGENTS.md คือกฎหมายที่ Codex อ่านก่อนที่จะแตะต้องอะไร

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

ขั้นตอนที่ 1. เขียนกฎหมายก่อน

ก่อนไฟล์การให้คะแนน, ก่อนไฟล์ prompt, ให้เขียน AGENTS.md นี่คือไฟล์ที่ทำให้เอเยนต์มีประโยชน์และอยู่ในขอบเขต

1# กฎของระบบ Outbound ที่ปรับปรุงตัวเองได้
2
3คุณปรับปรุงระบบ outbound จากผลลัพธ์
4
5กฎที่ห้ามละเมิด:
6- ห้ามส่งข้อความเด็ดขาด
7- ห้าม scrape หรือ enrich คนจริง
8- ห้าม self-merge (รวมโค้ดด้วยตัวเอง) เด็ดขาด
9- แก้ไขเฉพาะไฟล์ใน repo นี้เท่านั้น
10- เปลี่ยนแนวคิดทีละหนึ่งอย่าง
11- อ้างอิงผลลัพธ์จาก memory/outcomes.jsonl สำหรับทุกการเปลี่ยนแปลงที่เสนอ
12- ปรับปรุง evals/score.py ก่อนที่การเปลี่ยนแปลงจะกลายเป็น PR
13- ถ้า eval ไม่ดีขึ้น ให้ยกเลิกการแก้ไขของคุณและหยุด
14
15การแก้ไขที่อนุญาต:
16- config/scoring.yaml
17- config/plays.yaml
18- prompts/*.md
19
20ผลลัพธ์ที่ต้องส่งออก:
21- ไฟล์ที่เปลี่ยนแปลง
22- เหตุผลสำหรับการเปลี่ยนแปลงแต่ละครั้ง
23- คะแนนก่อนการเปลี่ยนแปลง
24- คะแนนหลังการเปลี่ยนแปลง
25- สรุป pull request

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

หน้าตาของผลลัพธ์ที่ดี คุณสามารถอ่านกฎหมายก่อนอนุมัติ PR และรู้ได้อย่างแน่ชัดว่า Codex ได้รับอนุญาตให้ทำอะไรได้บ้าง

จุดที่พัง กฎหมายกลายเป็นเอกสารการปฏิบัติตามข้อกำหนด ถ้า AGENTS.md ต้องมีสารบัญ แสดงว่ามันใหญ่เกินไปแล้ว ทำให้มันใช้งานได้จริง

ขั้นตอนที่ 2. ย้ายการตัดสินใจไปที่ config

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

ย้ายการตัดสินใจไปไว้ในไฟล์

1signals:
2  competitor_comparison:
3    weight: 8
4    reason: "ผู้ซื้อกำลังเปรียบเทียบทางเลือก"
5  implementation_page_visit:
6    weight: 6
7    reason: "ผู้ซื้อกำลังตรวจสอบว่าสามารถติดตั้งสิ่งนี้ได้หรือไม่"
8  job_repost:
9    weight: 5
10    reason: "ตำแหน่งงานยังเปิดรับและเร่งด่วน"
11  funding_event:
12    weight: 5
13    reason: "งบประมาณหรือคำสั่งอาจเปลี่ยนแปลง"
14  generic_download:
15    weight: 1
16    reason: "ความสนใจในเนื้อหา, ความตั้งใจซื้อต่ำ"
17
18thresholds:
19  draft: 6
20  human_review: 10
21
22negative_signals:
23  student_research: -8
24  vendor_pitch: -6
25  competitor: -10

ไฟล์นี้เริ่มต้นเป็นสมมติฐานที่มองเห็นได้ ถ้าการดาวน์โหลดทั่วไปควรนับเป็นศูนย์ ทีมสามารถชี้ไปที่บรรทัดที่แน่นอนและเปลี่ยนแปลงได้ ถ้าการเยี่ยมชมหน้า implementation เป็นสัญญาณที่แรงกว่าที่คุณคิด Codex สามารถเสนอ diff และแสดงแถวผลลัพธ์ที่พิสูจน์ได้

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

หน้าตาของผลลัพธ์ที่ดี ไฟล์มีขนาดเล็กพอที่จะโต้แย้งได้ ห้าสัญญาณเป็นเวอร์ชันแรกที่ดี

จุดที่พัง ไฟล์การให้คะแนนกลายเป็นลิ้นชักรวมขยะ ยี่สิบสัญญาณ, หกเกณฑ์, และกฎยกเว้นสำหรับทุกกรณีขอบจะทำให้ระบบปรับปรุง overfit (พอดีเกินไป) เริ่มต้นแคบๆ และปล่อยให้ผลลัพธ์บอกคุณว่าปุ่มหมุนต่อไปควรอยู่ที่ไหน

ขั้นตอนที่ 3. เขียนผลลัพธ์เป็นหน่วยความจำ

ไฟล์ที่สำคัญที่สุดคือ memory/outcomes.jsonl

หนึ่งบรรทัดต่อการติดต่อหนึ่งครั้ง, เขียนเมื่อทราบผลลัพธ์:

1{"date":"2026-07-01","account":"Northwind Finance","signal":"competitor_comparison","play":"migration_note","score":8,"outcome":"reply","reason":"asked for migration notes"}
2{"date":"2026-07-01","account":"Bluepeak Studio","signal":"generic_download","play":"resource_followup","score":1,"outcome":"no_reply","reason":"content-only intent"}
3{"date":"2026-07-02","account":"KiteOps","signal":"implementation_page_visit","play":"implementation_angle","score":6,"outcome":"reply","reason":"asked about implementation timeline"}
4{"date":"2026-07-02","account":"Atlas Recruiting","signal":"job_repost","play":"hiring_angle","score":5,"outcome":"bad_fit","reason":"student research request"}

ฟิลด์ reason คือประเด็นสำคัญ no_reply บอกคุณแทบจะไม่มีอะไรเลย content-only intent บอกการรันครั้งต่อไปว่าสัญญาณนี้อาจไม่สมควรได้รับ draft bad_fit จะมีประโยชน์ก็ต่อเมื่อเหตุผลอธิบายว่าทำไม asked about implementation timeline คือรายละเอียดประเภทที่สามารถเปลี่ยนน้ำหนักได้

สร้าง validator ก่อนที่จะสร้าง improver:

1สร้าง scripts/append_outcome.py
2
3มันรับ:
4- date
5- account
6- signal
7- play
8- score
9- outcome: reply | meeting | no_reply | bad_fit | bounced
10- reason
11
12มันปฏิเสธ:
13- ฟิลด์ที่ขาดหายไป
14- outcomes ที่ไม่รู้จัก
15- reason ที่ว่างเปล่า
16- วันที่ในอนาคต
17
18ต่อแถวที่ถูกต้องต่อท้าย memory/outcomes.jsonl
19พิมพ์แถวที่ต่อท้าย

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

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

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

ขั้นตอนที่ 4. สร้างประตู eval

ก่อนที่ Codex จะแก้ไขอะไร มันต้องการการทดสอบที่มันไม่สามารถอธิบายให้พ้นตัวได้

สร้าง evals/fixtures.yaml:

1cases:
2  - account: Northwind Finance
3    signals: [competitor_comparison, implementation_page_visit]
4    expected: human_review
5    note: "สัญญาณแรงสองสัญญาณในบัญชีเดียว"
6
7  - account: Bluepeak Studio
8    signals: [generic_download]
9    expected: ignore
10    note: "ความตั้งใจเฉพาะเนื้อหา"
11
12  - account: KiteOps
13    signals: [implementation_page_visit]
14    expected: draft
15    note: "ความตั้งใจในการติดตั้งควรผ่านเกณฑ์ draft"
16
17  - account: Atlas Recruiting
18    signals: [job_repost, student_research]
19    expected: ignore
20    note: "ตัวบ่งชี้ที่ไม่เหมาะสมหักล้างสัญญาณ"

จากนั้นสร้าง evals/score.py:

1สร้าง evals/score.py
2
3อ่าน config/scoring.yaml และ evals/fixtures.yaml
4
5สำหรับแต่ละกรณี:
61. รวมน้ำหนักสำหรับทุกสัญญาณ
72. เพิ่มบทลงโทษสัญญาณเชิงลบ
83. เส้นทางบัญชี:
9   - score >= thresholds.human_review => human_review
10   - score >= thresholds.draft => draft
11   - อื่นๆ => ignore
124. เปรียบเทียบเส้นทางกับ expected
13
14พิมพ์แต่ละการทำนาย
15พิมพ์ความแม่นยำสุดท้ายเป็น score=0.00 ถึง score=1.00
16ออก 0 เฉพาะเมื่อความแม่นยำคือ 1.00

ประตูแรกควรมีขนาดเล็กพอที่จะเข้าใจและคมพอที่จะจับพลาดจริง ในการรันครั้งแรกของฉัน, baseline ล้มเหลวในหนึ่งกรณี:

1Northwind Finance: predicted=human_review expected=human_review
2Bluepeak Studio: predicted=ignore expected=ignore
3KiteOps: predicted=ignore expected=draft
4Atlas Recruiting: predicted=ignore expected=ignore
5score=0.75

นั่นเป็นสิ่งที่ดี ระบบมี implementation intent ต่ำกว่าเกณฑ์ draft ดังนั้นมันจึงละเว้นบัญชีที่ fixture บอกว่าสมควรได้รับข้อความ ดีกว่าที่จะจับสิ่งนี้ได้ในการทดสอบมากกว่าหลังจากพลาดบัญชีไปเป็นเดือน

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

จุดที่พัง Fixture มีแต่ชัยชนะที่เห็นได้ชัด จากนั้นทุกการเปลี่ยนแปลงที่ประมาทก็ผ่านไป ใส่กรณีที่ยากในประตู: ความตั้งใจที่อ่อนแอ, ไม่เหมาะสม, ไม่มีการตอบกลับ, สัญญาณที่เก่า, และบัญชีที่คุณหวังว่าระบบจะข้ามไป

ขั้นตอนที่ 5. ให้ Codex เสนอการเปลี่ยนแปลงการให้คะแนนหนึ่งอย่าง

ตอนนี้ Codex สามารถแก้ไขได้

สร้าง prompts/improve_scoring.md:

1คุณปรับปรุงระบบการให้คะแนน outbound
2
3อ่าน:
4- AGENTS.md
5- config/scoring.yaml
6- memory/outcomes.jsonl
7- evals/fixtures.yaml
8
9งานของคุณ:
101. ค้นหากฎการให้คะแนนหนึ่งข้อที่ควรเปลี่ยนแปลง
112. เหตุผลต้องอ้างอิง memory/outcomes.jsonl
123. เปลี่ยนเฉพาะ config/scoring.yaml
134. รัน python3 evals/score.py
145. ถ้าคะแนนดีขึ้น ให้เก็บการเปลี่ยนแปลงไว้
156. ถ้าคะแนนคงที่หรือลดลง ให้ยกเลิกการเปลี่ยนแปลงของคุณและหยุด
16
17ผลลัพธ์:
18- บรรทัดที่เปลี่ยนไป
19- แถวผลลัพธ์ที่ทำให้เกิดการเปลี่ยนแปลง
20- คะแนนก่อน
21- คะแนนหลัง
22- ว่าการเปลี่ยนแปลงควรกลายเป็น PR หรือไม่
23
24ห้ามแก้ไข prompts.
25ห้ามเพิ่มสัญญาณใหม่.
26ห้ามแตะระบบจัดส่ง.

รันผ่านตัวห่อ repo:

1scripts/run_codex_step.sh improve_scoring

เวอร์ชันแรกของ improver ของฉันทำผิดพลาดที่มีประโยชน์ มันไล่ตามสัญญาณตอบกลับที่ดูสะอาดที่สุด competitor_comparison มีอัตราการตอบกลับที่แรงที่สุดในบันทึกผลลัพธ์เล็กๆ ดังนั้น improver ต้องการเพิ่มน้ำหนักนั้น eval ยังคงอยู่ที่ 0.75 ดังนั้นการเปลี่ยนแปลงจึงถูกปฏิเสธ

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

รอบที่สองพบการแก้ไขที่เล็กที่สุดที่ช่วยได้:

1- implementation_page_visit: 4
2+ implementation_page_visit: 6

eval ผ่าน:

1Northwind Finance: predicted=human_review expected=human_review
2Bluepeak Studio: predicted=ignore expected=ignore
3KiteOps: predicted=draft expected=draft
4Atlas Recruiting: predicted=ignore expected=ignore
5score=1.00

นั่นคือช่วงเวลาที่ลูปมีประโยชน์ มันเปลี่ยนกฎหนึ่งข้อ, ด้วยเหตุผลหนึ่งข้อ, และพิสูจน์การเปลี่ยนแปลงกับ fixture

หน้าตาของผลลัพธ์ที่ดี diff ที่เสนอควรน่าเบื่อและตรวจสอบได้: หนึ่งบรรทัดที่เปลี่ยนไป, เหตุผลหนึ่งข้อที่ backed by outcome, eval หนึ่งข้อที่ดีขึ้น

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

ขั้นตอนที่ 6. ปรับปรุงไฟล์ prompt แยกกัน

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

บรรทัดที่ใช้ได้ผลเมื่อเดือนที่แล้วเริ่มฟังดูคุ้นชิน คำถามที่ได้รับการตอบกลับในเซ็กเมนต์หนึ่งถูกมองข้ามในอีกเซ็กเมนต์ วลีที่รู้สึกเฉียบคมภายในถูกลงโทษโดยตลาด ปฏิบัติต่อการปรับปรุง prompt เป็นเลนแยกต่างหาก เพื่อที่ Codex จะได้ไม่ผสมการให้คะแนนและ copy ใน PR เดียวกัน

สร้าง config/plays.yaml:

1plays:
2  migration_note:
3    prompt_file: prompts/plays/migration_note.md
4    use_when:
5      - competitor_comparison
6    banned_lines:
7      - "thought this might be relevant"
8      - "quick question"
9
10  implementation_angle:
11    prompt_file: prompts/plays/implementation_angle.md
12    use_when:
13      - implementation_page_visit
14    banned_lines:
15      - "checking out our solution"
16      - "would love to chat"

จากนั้นสร้าง prompts/improve_prompt.md:

1คุณปรับปรุง play outbound หนึ่ง play
2
3อ่าน:
4- AGENTS.md
5- config/plays.yaml
6- memory/outcomes.jsonl
7- ไฟล์ prompt สำหรับ play ที่เลือก
8
9เลือกหนึ่ง play ที่มีผลลัพธ์อย่างน้อย 10 รายการ
10
11ค้นหา:
12- บรรทัดหรือโครงสร้างที่ปรากฏในผลลัพธ์เชิงบวก
13- บรรทัดหรือโครงสร้างที่ปรากฏในผลลัพธ์ no_reply หรือ bad_fit
14- วลีใดๆ ที่ควรถูกแบน
15
16ทำการแก้ไขเล็กน้อยหนึ่งครั้งใน prompt ของ play นั้น
17
18กฎ:
19- ห้ามเปลี่ยนการให้คะแนน
20- ห้ามสร้าง play ใหม่
21- ห้ามเพิ่มช่องทางใหม่
22- อ้างอิงแถวผลลัพธ์
23- เขียนคำสั่งก่อนและหลัง
24
25จากนั้นรัน copy eval ถ้ามี
26ถ้าไม่มี copy eval ให้เปิด PR เป็น review_required

การปรับปรุงบางอย่างสามารถให้คะแนนโดยอัตโนมัติได้ การปรับปรุงอื่นๆ ยังต้องใช้รสนิยม ถ้าไม่มี copy eval, Codex สามารถเสนอการแก้ไข prompt ได้ แต่มันควรทำเครื่องหมาย PR สำหรับการตรวจสอบ แทนที่จะแสร้งทำเป็นว่าการแก้ไขได้รับการพิสูจน์แล้ว

หน้าตาของผลลัพธ์ที่ดี Codex พูดว่า "วลีนี้ปรากฏในเจ็ดผลลัพธ์ที่ไม่มีการตอบกลับ ดังนั้นฉันจึงเพิ่มมันเข้าไปใน banned_lines" หรือ "การตอบกลับเชิงบวกอ้างอิงรายละเอียดการใช้งานในประโยคแรก ดังนั้นฉันจึงปรับ play ให้ต้องการสิ่งนั้น"

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

ขั้นตอนที่ 7. ส่งการเปลี่ยนแปลงเป็น pull requests

นี่คือเลเยอร์ควบคุม Codex แก้ไขไฟล์, รัน eval, และเขียนสรุป PR มนุษย์ตรวจสอบและ merge

สร้าง prompts/pr_summary.md:

1เขียนสรุป pull request สำหรับการปรับปรุง outbound นี้
2
3รวม:
41. อะไรที่เปลี่ยนไป
52. ทำไมถึงเปลี่ยน, อ้างอิงแถวผลลัพธ์
63. คะแนนก่อน
74. คะแนนหลัง
85. ไฟล์ที่เปลี่ยน
96. ความเสี่ยง
107. สิ่งที่ผู้ตรวจสอบที่เป็นมนุษย์ควรตรวจสอบ
11
12ทำให้สั้น
13อย่าอ้างว่าการเปลี่ยนแปลงนั้นใช้งานได้จริง

สร้าง scripts/open_pr.sh:

1#!/usr/bin/env bash
2set -euo pipefail
3
4branch="codex/weekly-tune-$(date +%Y-%m-%d)"
5
6git checkout -b "$branch"
7git add config prompts evals memory
8git commit -m "Codex weekly outbound tune"
9
10body="$(cat outputs/pr-summary.md)"
11
12python3 scripts/create_pr.py \
13  "$branch" \
14  "Codex weekly outbound tune" \
15  "$body"

PR ควรอ่านเหมือนเพื่อนร่วมทีมเขียน:

1Changed:
2- เพิ่ม implementation_page_visit จาก 4 เป็น 6.
3
4Why:
5- KiteOps มีความตั้งใจในการดูหน้า implementation และตอบกลับพร้อมระยะเวลาในการติดตั้ง
6- คะแนนก่อนหน้านี้ส่งบัญชีนี้ไปที่ ignore
7
8Before:
9- eval score 0.75
10
11After:
12- eval score 1.00
13
14Reviewer check:
15- ตรวจสอบว่าความตั้งใจในการติดตั้งนั้นเฉพาะเจาะจงเพียงพอ
16- ให้ดาวน์โหลดทั่วไปอยู่ในระดับต่ำ
17- Merge เฉพาะเมื่อตรงกับการตัดสินใจขายจริง

นั่นคือระบบความปลอดภัย Codex ทำงานที่น่าเบื่อ ผู้ปฏิบัติงานรักษามาตรฐาน

หน้าตาของผลลัพธ์ที่ดี หนึ่ง PR ต่อสัปดาห์, diff เล็ก, เหตุผลชัดเจน, eval ผ่าน

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

ขั้นตอนที่ 8. วางมันบนจังหวะเวลา

อย่ารันสิ่งนี้หลังทุกการตอบกลับ นั่นคือวิธีที่ระบบ overfit กับบัญชีที่เสียงดังหนึ่งบัญชี

ปล่อยให้สัปดาห์ผ่านไป, ปล่อยให้ผลลัพธ์สะสม, จากนั้นปรับแต่ง

สร้าง scripts/weekly_tune.sh:

1#!/usr/bin/env bash
2set -euo pipefail
3
4cd "$(dirname "$0")/.."
5
6python3 evals/score.py || true
7scripts/run_codex_step.sh improve_scoring
8python3 evals/score.py
9scripts/run_codex_step.sh pr_summary > outputs/pr-summary.md
10scripts/open_pr.sh

จากนั้น cron:

10 8 * * MON cd ~/codex-self-improving-outbound && scripts/weekly_tune.sh

ถ้าคุณใช้ GitHub Actions, ให้คงรูปร่างเดียวกัน:

1name: weekly-outbound-tune
2
3on:
4  schedule:
5    - cron: "0 8 * * 1"
6  workflow_dispatch:
7
8jobs:
9  tune:
10    runs-on: ubuntu-latest
11    steps:
12      - uses: actions/checkout@v4
13      - uses: actions/setup-python@v5
14        with:
15          python-version: "3.11"
16      - run: pip install -r requirements.txt
17      - run: python3 evals/score.py || true
18      - run: scripts/weekly_tune.sh

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

หน้าตาของผลลัพธ์ที่ดี PR รายสัปดาห์ปรากฏขึ้นพร้อมหลักฐาน, diff, และผลลัพธ์ eval คุณ merge, แก้ไข, หรือปิดมัน

จุดที่พัง งานรัน, ไม่มีใครตรวจสอบ, และ PRs กองพะเนินเทินทึก ระบบที่ปรับปรุงตัวเองได้ยังคงมีนิสัยอย่างหนึ่งของมนุษย์: อ่าน diff

เวอร์ชัน clone-and-run

repo ควรมาพร้อมกับสี่คำสั่ง:

1git clone <repo>
2cd codex-self-improving-outbound
3python3 -m venv .venv
4source .venv/bin/activate
5pip install -r requirements.txt
6python3 evals/score.py
7python3 scripts/propose_improvement.py

การรันครั้งแรกที่คาดหวัง:

1score=0.75
2changed config/scoring.yaml
3implementation_page_visit: 4 -> 6
4score=1.00
5open PR for human review

การสาธิตแบบออฟไลน์พิสูจน์สัญญาไฟล์ การรัน Codex พิสูจน์ลูปการแก้ไข หลังจากนั้น, แทนที่ตัวอย่างผลลัพธ์ด้วยของคุณเอง, เปลี่ยนชื่อสัญญาณ, เพิ่ม plays ของคุณ, และสร้าง fixture ที่สะท้อนถึงบัญชีที่คุณหวังว่าระบบจะจัดเส้นทางต่างออกไป

อย่าเริ่มต้นด้วยการเชื่อมต่อระบบจัดส่ง เริ่มต้นด้วยการพิสูจน์ลูปการปรับปรุง

เวอร์ชันเต็ม: max

repo นี้คือเลเยอร์แบบแมนนวล มันทำงานจากไฟล์, สัญญาณสาธารณะ, และแผน Codex ของคุณ มันสอนโครงสร้างเพราะทุกกฎถูกเปิดเผย

yourmax.ai คือระบบเดียวกันที่ซ่อนรอยต่อไว้

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

repo แสดงเลเยอร์การปรับแต่งตัวเองที่ทีมส่วนใหญ่ไม่เคยสร้าง: ผลลัพธ์กลายเป็นการเปลี่ยนแปลงกฎที่เสนอ, การเปลี่ยนแปลงกฎที่เสนอผ่านประตู, และมนุษย์เป็นผู้ตัดสินใจ merge ว่าอะไรจะใช้งานได้จริง max นำตรรกะการดำเนินงานเดียวกันนั้นมาใช้และรันเป็นระบบที่มีการจัดการ

ถ้าคุณต้องการ repo เต็ม, คุณสามารถแจ้งให้ฉันทราบและฉันจะส่งให้คุณ