Cách xây dựng hệ thống outbound tự cải tiến trên Codex

Đầu năm nay, Andrej Karpathy (@karpathy) đã hướng một agent vào mã huấn luyện của chính mình và để nó chạy trong hai ngày. Nó đã chạy 700 thử nghiệm, giữ lại 20 thử nghiệm vượt qua benchmark, và giúp mô hình huấn luyện nhanh hơn 11%. Sau đó, anh ấy nói một điều khá thú vị: bất kỳ chỉ số nào bạn có thể đánh giá với chi phí thấp đều có thể giao cho một bầy agent.

Tỷ lệ phản hồi là một chỉ số có thể đánh giá với chi phí thấp. Tôi đã dành một thời gian để tìm hiểu vòng lặp đó trông như thế nào khi áp dụng cho outbound.

Bản dựng của tôi:

Codex đọc kết quả của tuần trước, chỉnh sửa các tệp chấm điểm và playbook mà hệ thống outbound chạy, chạy thử nghiệm, và mở một pull request. Nó đề xuất một thay đổi cho playbook kèm bằng chứng và điểm số, sau đó chờ con người phê duyệt. Việc gửi và hợp nhất nằm ngoài vòng lặp.

Tôi đã xây dựng vòng lặp đầu tiên vài lần: cảm nhận thị trường, chấm điểm tài khoản, viết từ tín hiệu, kiểm tra tin nhắn, ghi lại kết quả, học hỏi từ phản hồi. Bài viết này nói về vòng lặp thứ hai, vòng lặp chỉnh sửa vòng lặp đầu tiên.

Đó là bản dựng: GTM như mã nguồn được quản lý phiên bản và cải tiến từ thị trường.

Repo

Bắt đầu với thư mục. Cấu trúc quan trọng vì Codex chỉ có thể cải thiện những gì nó có thể đọc và chỉnh sửa.

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 được cố tình giữ đơn giản. config/scoring.yaml chứa các quy tắc quyết định tín hiệu nào quan trọng. prompts/ chứa các playbook viết tin nhắn. memory/outcomes.jsonl chứa những gì thị trường đã làm. evals/score.py là cổng kiểm soát xem một thay đổi được đề xuất có hữu ích hay không. AGENTS.md là luật mà Codex đọc trước khi chạm vào bất cứ thứ gì.

Chạy phiên bản đầu tiên ngoại tuyến. Không có CRM, không làm giàu dữ liệu, không có hệ thống gửi. Vòng lặp cải tiến nên tự chứng minh trên các tệp cục bộ trước khi đến gần một máy outbound thực sự.

Bước 1. Viết luật trước

Trước tệp chấm điểm, trước tệp prompt, hãy viết AGENTS.md. Đây là tệp giữ cho agent hữu ích và có giới hạn.

1# Quy tắc Outbound Tự Cải Tiến
2
3Bạn cải tiến một hệ thống outbound từ kết quả.
4
5Quy tắc cứng:
6- Không bao giờ gửi tin nhắn.
7- Không bao giờ scrape hoặc làm giàu thông tin người thật.
8- Không bao giờ tự hợp nhất.
9- Chỉ chỉnh sửa các tệp trong repo này.
10- Thay đổi một khái niệm tại một thời điểm.
11- Trích dẫn kết quả từ `memory/outcomes.jsonl` cho mọi thay đổi được đề xuất.
12- Cải tiến `evals/score.py` trước khi một thay đổi có thể trở thành PR.
13- Nếu eval không cải thiện, hãy hoàn tác chỉnh sửa và dừng lại.
14
15Các chỉnh sửa được phép:
16- `config/scoring.yaml`
17- `config/plays.yaml`
18- `prompts/*.md`
19
20Đầu ra yêu cầu:
21- các tệp đã thay đổi
22- lý do cho mỗi thay đổi
23- điểm số trước
24- điểm số sau
25- tóm tắt pull request

Luật có một nhiệm vụ: thu hẹp phạm vi công việc. Nếu không có nó, Codex sẽ cố gắng giúp đỡ bằng cách mở rộng phạm vi. Nó sẽ thêm nhiều dữ liệu hơn, chạm vào nhiều tệp hơn, gọi nhiều công cụ hơn, hoặc tự động hóa một bước lẽ ra phải nằm dưới sự kiểm soát của con người. Ở đây, công việc nhỏ hơn: đọc kết quả, đề xuất một thay đổi tệp, chứng minh nó có ích, sau đó chờ.

Điều gì là tốt. Bạn có thể đọc luật trước khi phê duyệt PR và biết chính xác Codex được phép làm gì.

Nơi nào nó hỏng. Luật trở thành một tài liệu tuân thủ. Nếu AGENTS.md cần một mục lục, thì nó đã quá lớn. Hãy giữ nó ở dạng vận hành.

Bước 2. Đưa phán đoán vào config

Hầu hết phán đoán outbound nằm trong đầu ai đó. Sau đó, nhóm mua phần mềm và mong đợi phần mềm cải thiện một quyết định mà nó không thể thấy.

Hãy đưa phán đoán vào một tệp.

1signals:
2  competitor_comparison:
3    weight: 8
4    reason: "người mua đang so sánh các lựa chọn thay thế"
5  implementation_page_visit:
6    weight: 6
7    reason: "người mua đang kiểm tra xem có thể cài đặt được không"
8  job_repost:
9    weight: 5
10    reason: "vị trí vẫn đang mở và gấp"
11  funding_event:
12    weight: 5
13    reason: "ngân sách hoặc nhiệm vụ có thể đã thay đổi"
14  generic_download:
15    weight: 1
16    reason: "quan tâm đến nội dung, ý định mua yếu"
17
18thresholds:
19  draft: 6
20  human_review: 10
21
22negative_signals:
23  student_research: -8
24  vendor_pitch: -6
25  competitor: -10

Tệp này bắt đầu như một giả thuyết có thể nhìn thấy. Nếu một lượt tải xuống chung chung nên được tính là 0, nhóm có thể chỉ vào dòng cụ thể và thay đổi nó. Nếu một lượt truy cập trang triển khai là tín hiệu mạnh hơn bạn nghĩ, Codex có thể đề xuất diff và hiển thị các hàng kết quả biện minh cho nó.

Đừng chôn logic này trong một hàm Python. Nếu quy tắc có thể nhìn thấy, nhóm có thể xem xét nó, tranh luận và cải thiện nó mà không cần biến một phán đoán bán hàng thành một sự tái cấu trúc kỹ thuật.

Điều gì là tốt. Tệp đủ nhỏ để có thể tranh luận. Năm tín hiệu là một phiên bản đầu tốt.

Nơi nào nó hỏng. Tệp chấm điểm trở thành một ngăn kéo linh tinh. Hai mươi tín hiệu, sáu ngưỡng, và các quy tắc ngoại lệ cho mọi trường hợp cạnh sẽ khiến bộ cải tiến quá khớp. Hãy bắt đầu hẹp và để kết quả cho bạn biết nút điều chỉnh tiếp theo nên ở đâu.

Bước 3. Viết kết quả dưới dạng bộ nhớ

Tệp quan trọng nhất là memory/outcomes.jsonl.

Một dòng cho mỗi lần tiếp xúc, được viết khi biết kết quả:

1{"date":"2026-07-01","account":"Northwind Finance","signal":"competitor_comparison","play":"migration_note","score":8,"outcome":"reply","reason":"hỏi về ghi chú di chuyển"}
2{"date":"2026-07-01","account":"Bluepeak Studio","signal":"generic_download","play":"resource_followup","score":1,"outcome":"no_reply","reason":"chỉ quan tâm nội dung"}
3{"date":"2026-07-02","account":"KiteOps","signal":"implementation_page_visit","play":"implementation_angle","score":6,"outcome":"reply","reason":"hỏi về thời gian triển khai"}
4{"date":"2026-07-02","account":"Atlas Recruiting","signal":"job_repost","play":"hiring_angle","score":5,"outcome":"bad_fit","reason":"yêu cầu nghiên cứu của sinh viên"}

Trường reason là toàn bộ vấn đề. no_reply hầu như không cho bạn biết gì. chỉ quan tâm nội dung cho lần chạy tiếp theo biết rằng tín hiệu này có thể không xứng đáng để soạn thảo. bad_fit chỉ hữu ích khi lý do giải thích tại sao. hỏi về thời gian triển khai là loại chi tiết có thể thay đổi một trọng số.

Xây dựng trình xác thực trước khi xây dựng bộ cải tiến:

1Xây dựng scripts/append_outcome.py.
2
3Nó chấp nhận:
4- date
5- tài khoản
6- tín hiệu
7- play
8- điểm số
9- kết quả: reply | meeting | no_reply | bad_fit | bounced
10- lý do
11
12Nó từ chối:
13- thiếu trường
14- kết quả không xác định
15- lý do trống
16- ngày trong tương lai
17
18Thêm các hàng hợp lệ vào memory/outcomes.jsonl.
19In ra hàng đã được thêm.

Đây là nơi sự tích lũy bắt đầu. Một dashboard có thể cho bạn biết một chiến dịch đang giảm. Một nhật ký kết quả sạch sẽ có thể cho Codex biết tín hiệu, play hoặc cụm từ nào nên thay đổi trước lần chạy tiếp theo.

Điều gì là tốt. Sau một tuần, một người lạ có thể đọc tệp và cho biết tín hiệu nào tạo ra phản hồi, play nào tạo ra các cuộc trò chuyện không phù hợp, và sở thích nội bộ nào mà thị trường bỏ qua.

Nơi nào nó hỏng. Nhóm điền ngược kết quả vào thứ Sáu từ trí nhớ. Các chiến thắng tồn tại, lý do không phù hợp mờ nhạt, và hệ thống học từ hư cấu. Hãy ghi dòng khi kết quả đến.

Bước 4. Xây dựng cổng eval

Trước khi Codex chỉnh sửa bất cứ thứ gì, nó cần một bài kiểm tra mà nó không thể giải thích.

Tạo evals/fixtures.yaml:

1cases:
2  - account: Northwind Finance
3    signals: [competitor_comparison, implementation_page_visit]
4    expected: human_review
5    note: "hai tín hiệu mạnh trên một tài khoản"
6
7  - account: Bluepeak Studio
8    signals: [generic_download]
9    expected: ignore
10    note: "chỉ quan tâm nội dung"
11
12  - account: KiteOps
13    signals: [implementation_page_visit]
14    expected: draft
15    note: "ý định triển khai nên vượt ngưỡng draft"
16
17  - account: Atlas Recruiting
18    signals: [job_repost, student_research]
19    expected: ignore
20    note: "dấu hiệu không phù hợp triệt tiêu tín hiệu"

Sau đó tạo evals/score.py:

1Xây dựng evals/score.py.
2
3Đọc config/scoring.yaml và evals/fixtures.yaml.
4
5Cho mỗi trường hợp:
61. Tính tổng trọng số cho mọi tín hiệu.
72. Thêm điểm phạt tín hiệu tiêu cực.
83. Phân luồng tài khoản:
9   - score >= thresholds.human_review => human_review
10   - score >= thresholds.draft => draft
11   - nếu không => ignore
124. So sánh luồng với expected.
13
14In ra mỗi dự đoán.
15In độ chính xác cuối cùng dưới dạng score=0.00 đến score=1.00.
16Thoát 0 chỉ khi độ chính xác là 1.00.

Cổng đầu tiên nên đủ nhỏ để hiểu và đủ sắc để bắt được một sai sót thực sự. Trong lần chạy đầu tiên của tôi, baseline đã thất bại một trường hợp:

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

Điều đó thật tốt. Hệ thống có ý định triển khai dưới ngưỡng draft, vì vậy nó bỏ qua một tài khoản mà fixture cho rằng xứng đáng nhận tin nhắn. Tốt hơn là bắt điều này trong một bài kiểm tra hơn là sau một tháng bỏ lỡ các tài khoản.

Điều gì là tốt. Một lệnh đưa ra một con số, và mọi trường hợp thất bại đều dễ kiểm tra.

Nơi nào nó hỏng. Fixture chỉ bao gồm các chiến thắng rõ ràng. Sau đó, mọi thay đổi liều lĩnh đều vượt qua. Hãy đưa các trường hợp xấu vào cổng: ý định yếu, không phù hợp, không phản hồi, tín hiệu cũ, và các tài khoản mà bạn ước hệ thống đã bỏ qua.

Bước 5. Để Codex đề xuất một thay đổi chấm điểm

Bây giờ Codex có thể chỉnh sửa.

Tạo prompts/improve_scoring.md:

1Bạn cải tiến hệ thống chấm điểm outbound.
2
3Đọc:
4- AGENTS.md
5- config/scoring.yaml
6- memory/outcomes.jsonl
7- evals/fixtures.yaml
8
9Công việc của bạn:
101. Tìm một quy tắc chấm điểm nên thay đổi.
112. Lý do phải trích dẫn memory/outcomes.jsonl.
123. Chỉ thay đổi config/scoring.yaml.
134. Chạy python3 evals/score.py.
145. Nếu điểm số cải thiện, giữ lại thay đổi.
156. Nếu điểm số giữ nguyên hoặc giảm, hoàn tác thay đổi và dừng lại.
16
17Đầu ra:
18- dòng chính xác đã thay đổi
19- các hàng kết quả gây ra nó
20- điểm trước
21- điểm sau
22- liệu thay đổi có nên trở thành PR không
23
24Không chỉnh sửa prompts.
25Không thêm tín hiệu mới.
26Không chạm đến việc gửi.

Chạy nó qua wrapper repo:

1scripts/run_codex_step.sh improve_scoring

Phiên bản đầu tiên của bộ cải tiến của tôi đã mắc một sai lầm hữu ích. Nó đuổi theo tín hiệu phản hồi trông rõ ràng nhất. competitor_comparison có tỷ lệ phản hồi mạnh nhất trong nhật ký kết quả nhỏ, vì vậy bộ cải tiến muốn tăng trọng số đó. Eval vẫn ở 0.75, vì vậy thay đổi bị từ chối.

Đó chính xác là lý do tại sao cổng tồn tại. Một hệ thống yếu hơn sẽ chấp nhận câu chuyện vì nó nghe có vẻ hợp lý. Hệ thống này đã hỏi một câu hỏi tốt hơn: liệu thay đổi có sửa được sai sót đã biết không?

Lần thử thứ hai tìm thấy chỉnh sửa nhỏ nhất có ích:

1- implementation_page_visit: 4
2+ implementation_page_visit: 6

Eval đã vượt qua:

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

Đó là khoảnh khắc vòng lặp trở nên hữu ích. Nó đã thay đổi một quy tắc, vì một lý do, và chứng minh thay đổi đó với một fixture.

Điều gì là tốt. Diff được đề xuất nhàm chán và có thể truy vết: một dòng thay đổi, một lý do dựa trên kết quả được đính kèm, một eval được cải thiện.

Nơi nào nó hỏng. Codex thay đổi ba trọng số và hai prompt cùng một lúc. Lúc đó không ai biết thay đổi nào đã giúp ích. Hãy giữ luật nghiêm ngặt: một khái niệm mỗi đề xuất.

Bước 6. Cải tiến tệp prompt riêng biệt

Chấm điểm chỉ là một nửa hệ thống. Các mẫu tin nhắn cũng suy giảm theo thời gian.

Một dòng đã hoạt động tháng trước bắt đầu nghe quen thuộc. Một câu hỏi nhận được phản hồi trong một phân khúc bị bỏ qua ở phân khúc khác. Một cụm từ cảm thấy sắc bén nội bộ bị thị trường trừng phạt. Hãy coi việc cải tiến prompt như một làn đường riêng để Codex không trộn lẫn chấm điểm và copy trong cùng một PR.

Tạo 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"

Sau đó tạo prompts/improve_prompt.md:

1Bạn cải tiến một play outbound.
2
3Đọc:
4- AGENTS.md
5- config/plays.yaml
6- memory/outcomes.jsonl
7- tệp prompt cho play đã chọn
8
9Chọn một play có ít nhất 10 kết quả.
10
11Tìm:
12- các dòng hoặc cấu trúc xuất hiện trong kết quả tích cực
13- các dòng hoặc cấu trúc xuất hiện trong kết quả no_reply hoặc bad_fit
14- bất kỳ cụm từ nào nên bị cấm
15
16Thực hiện một chỉnh sửa nhỏ cho prompt của play đó.
17
18Quy tắc:
19- Không thay đổi chấm điểm.
20- Không tạo play mới.
21- Không thêm kênh mới.
22- Trích dẫn các hàng kết quả.
23- Viết hướng dẫn trước và sau.
24
25Sau đó chạy copy eval nếu có.
26Nếu không có copy eval, mở PR dưới dạng review_required.

Một số cải tiến có thể được chấm điểm tự động. Những cải tiến khác vẫn cần gu thẩm mỹ. Nếu không có copy eval, Codex có thể đề xuất chỉnh sửa prompt, nhưng nên đánh dấu PR để xem xét thay vì giả vờ chỉnh sửa đã được chứng minh.

Điều gì là tốt. Codex nói, "Cụm từ này xuất hiện trong bảy kết quả không phản hồi, vì vậy tôi đã thêm nó vào banned_lines," hoặc "các phản hồi tích cực trích dẫn chi tiết triển khai ở câu một, vì vậy tôi đã thắt chặt play để yêu cầu điều đó."

Nơi nào nó hỏng. Bộ cải tiến viết lại toàn bộ giọng văn vì một tin nhắn nhận được phản hồi. Các chỉnh sửa prompt nên nhỏ hơn bản năng của bạn.

Bước 7. Gửi thay đổi dưới dạng pull request

Đây là lớp kiểm soát. Codex chỉnh sửa tệp, chạy eval, và viết tóm tắt PR. Một con người xem xét và hợp nhất.

Tạo prompts/pr_summary.md:

1Viết tóm tắt pull request cho cải tiến outbound này.
2
3Bao gồm:
41. Nội dung đã thay đổi.
52. Tại sao nó thay đổi, trích dẫn các hàng kết quả.
63. Điểm số trước.
74. Điểm số sau.
85. Các tệp đã thay đổi.
96. Rủi ro.
107. Người xem xét nên kiểm tra gì.
11
12Giữ ngắn gọn.
13Không tuyên bố thay đổi đã có hiệu lực.

Tạo 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 nên đọc như thể một đồng đội đã viết nó:

1Đã thay đổi:
2- Tăng implementation_page_visit từ 4 lên 6.
3
4Tại sao:
5- KiteOps có ý định trang triển khai và đã phản hồi với thời gian triển khai.
6- Điểm số trước đây đã định tuyến tài khoản này vào ignore.
7
8Trước:
9- eval score 0.75
10
11Sau:
12- eval score 1.00
13
14Người xem xét kiểm tra:
15- Đảm bảo ý định triển khai đủ cụ thể.
16- Giữ các lượt tải xuống chung chung ở mức thấp.
17- Chỉ hợp nhất nếu điều này phù hợp với phán đoán bán hàng thực tế.

Đó là hệ thống an toàn. Codex làm công việc tẻ nhạt. Người vận hành giữ tiêu chuẩn.

Điều gì là tốt. Một PR mỗi tuần, diff nhỏ, lý do rõ ràng, eval vượt qua.

Nơi nào nó hỏng. Ai đó cho Codex quyền hợp nhất vì việc xem xét cảm thấy như một rào cản. Khoảnh khắc đó phân tách một hệ thống cải tiến khỏi một hệ thống trôi dạt.

Bước 8. Đặt nó vào nhịp độ

Đừng chạy cái này sau mỗi phản hồi. Đó là cách một hệ thống quá khớp với một tài khoản ồn ào.

Hãy để tuần trôi qua, để kết quả tích lũy, sau đó điều chỉnh.

Tạo 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

Sau đó cron:

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

Nếu bạn dùng GitHub Actions, hãy giữ cấu trúc tương tự:

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

Chạy hai lần điều chỉnh đầu tiên bằng tay. Đọc từng diff. Quan sát Codex cố gắng thay đổi gì khi mẫu còn ít. Một khi các đề xuất trở nên nhàm chán, hãy đặt nó vào lịch trình.

Điều gì là tốt. Một PR hàng tuần xuất hiện kèm bằng chứng, diff, và kết quả eval. Bạn hợp nhất, chỉnh sửa, hoặc đóng nó.

Nơi nào nó hỏng. Công việc chạy, không ai xem xét, và PR chất đống. Một hệ thống tự cải tiến vẫn có một thói quen của con người: đọc diff.

Phiên bản clone-and-run

Repo nên được ship với bốn lệnh:

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

Lần chạy đầu tiên dự kiến:

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

Bản demo ngoại tuyến chứng minh các hợp đồng tệp. Lần chạy Codex chứng minh vòng lặp chỉnh sửa. Sau đó, thay thế các kết quả mẫu bằng kết quả của bạn, đổi tên các tín hiệu, thêm play của bạn, và xây dựng một fixture phản ánh các tài khoản mà bạn ước hệ thống đã định tuyến khác đi.

Đừng bắt đầu bằng việc kết nối việc gửi. Hãy bắt đầu bằng việc chứng minh vòng lặp cải tiến.

Phiên bản đầy đủ: max

Repo này là lớp thủ công. Nó chạy từ các tệp, tín hiệu công khai, và kế hoạch Codex của bạn. Nó dạy cấu trúc vì mọi quy tắc đều được hiển thị.

yourmax.ai là cùng một hệ thống với các đường nối được ẩn đi.

Thay vì một repo bạn tự kết nối, max là agent bạn sử dụng trực tiếp. Nó phát hiện chuyển động trên thị trường, quyết định ai đáng liên hệ và tại sao ngay bây giờ, soạn thảo các bài tiếp cận qua email và LinkedIn để bạn phê duyệt, và tiếp tục cải tiến từ các kết quả.

Repo cho thấy lớp tự điều chỉnh mà hầu hết các nhóm không bao giờ xây dựng: kết quả trở thành các thay đổi quy tắc được đề xuất, các thay đổi quy tắc được đề xuất chạy qua một cổng, và con người hợp nhất quyết định những gì trở thành hiện thực. max lấy cùng logic vận hành đó và chạy nó như một hệ thống được quản lý.

Nếu bạn muốn toàn bộ repo, bạn có thể cho tôi biết và tôi sẽ gửi nó cho bạn.