Một nghiên cứu từ Đại học Bắc Kinh tuần này thử nghiệm 4 coding agent hàng đầu trên 106 issue thực tế thuộc 49 repo có quy định rõ ràng về đóng góp AI, được viết trong CONTRIBUTING.md hoặc AI_POLICY.md. Kết quả nên khiến bất kỳ ai coi văn bản chính sách là một chiến lược quản trị phải lo lắng: agent hiếm khi tự tra cứu quy định đóng góp, không một lần nào từ chối đóng góp vào repo đã cấm rõ ràng AI, và không công bố mình dùng AI trừ khi con người ép buộc bước công bố đó. Prompt nhắc nhở và phản hồi kiểm tra không thay đổi đáng kể hành vi từ chối của agent.

Tôi duy trì một dự án OSS nhỏ ngoài giờ và giữ quy định đóng góp cho hai repo nội bộ ở công ty hiện đang nhận PR do agent viết. Nghiên cứu này xác nhận điều tôi đã nghi ngờ sau 6 tháng xử lý PR do agent gửi: viết chính sách bằng văn xuôi tiếng Anh rồi hy vọng agent đọc nó không phải là một control, đó chỉ là một gợi ý.

Vì sao chính sách văn bản thất bại trước agent

Một contributor là người đọc CONTRIBUTING.md một lần, nội tâm hoá chuẩn mực, và phần lớn tuân theo trong các lần đóng góp sau — dù không hoàn hảo, nhưng có tính liên tục về nhận thức. Agent không có tính liên tục đó. Mỗi phiên bắt đầu lại từ đầu trừ khi văn bản chính sách được đưa thẳng vào context window, và ngay cả khi đó, “đọc tài liệu này” phải cạnh tranh với “hoàn thành task” như một mục tiêu — và nghiên cứu cho thấy mục tiêu hoàn thành task luôn thắng.

Bốn khía cạnh tuân thủ mà nhóm nghiên cứu đo lường tương ứng trực tiếp với bốn kiểu thất bại khác nhau:

  1. Từ chối đóng góp — agent nên từ chối thẳng nếu repo cấm PR từ AI. Trong nghiên cứu, agent không làm điều này dù chỉ một lần.
  2. Công bố trung thực — agent nên tự nói “phần này có sự hỗ trợ của AI” mà không cần hỏi. Nó không làm, trừ khi được yêu cầu.
  3. Vượt qua gate kiểm tra — agent nên pass mọi kiểm tra tự động hiện có (test, linter, license header).
  4. Chuyển lên con người — agent nên gắn cờ các trường hợp mơ hồ thay vì tự đoán.

Chỉ có mục #3 là agent làm khá tốt — vì nó được enforce bởi tooling, không phải do agent tự nguyện tuân thủ. Đó là toàn bộ bài học.

Khung quản trị tôi thực sự đang dùng

Vì văn bản chính sách không hoạt động như một control, hãy đối xử với quản trị đóng góp AI giống như bất kỳ vấn đề input không đáng tin nào khác: gate ở ranh giới, đừng dựa vào sự trung thực của bên gọi.

# .github/workflows/ai-contribution-gate.yml
name: AI Contribution Gate
on: pull_request

jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 1. Phát hiện tín hiệu tác giả AI — commit trailer, checkbox trong PR template,
      #    user-agent string của agent đã biết trên request GitHub API
      - name: Detect AI-assisted PR
        id: detect
        run: ./scripts/detect-ai-contribution.sh

      # 2. Nếu phát hiện, bắt buộc trailer công bố — fail cứng, không phải cảnh báo
      - name: Require disclosure
        if: steps.detect.outputs.is_ai == 'true'
        run: |
          if ! git log -1 --format=%B | grep -q "Co-Authored-By:.*agent"; then
            echo "AI-assisted PRs must include a Co-Authored-By trailer identifying the agent." >&2
            exit 1
          fi

      # 3. Chuyển sang luồng review nghiêm ngặt hơn — yêu cầu nhiều approval hơn,
      #    bắt buộc kiểm tra coverage do con người sở hữu
      - name: Apply stricter review requirements
        if: steps.detect.outputs.is_ai == 'true'
        run: gh pr edit "$PR_NUMBER" --add-label "needs-2-human-reviews"

Script detect-ai-contribution.sh không cố tỏ ra thông minh — nó kiểm tra những dấu vết agent để lại dù có cố ý hay không: commit message khớp template agent đã biết, nội dung PR có văn phong đặc trưng, và (nếu có) metadata request API. Nó cố tình mang tính xác suất và thiên về gắn cờ dư, vì false positive chỉ tốn thêm “một reviewer”, còn false negative nghĩa là một đóng góp AI không qua gate đã lọt vào.

Ba nguyên tắc thực sự hiệu quả

1. Đừng bao giờ gate chỉ dựa vào công bố — hãy gate dựa vào hành vi. Nếu kiểm tra duy nhất của bạn là “họ có nói đây là AI viết không”, bạn đã tái tạo đúng thất bại mà nghiên cứu tìm ra: agent không công bố trừ khi bị ép. Hãy phát hiện độc lập với self-report.

2. Coi “repo bị cấm” là một chặn kỹ thuật, không phải một tuyên bố chính sách. Nếu một repo thực sự không thể nhận đóng góp AI (vì lý do license, yêu cầu về provenance, v.v.), hãy đặt CI check fail bất kỳ PR nào không có commit ký bởi con người, không ngoại lệ. Đừng dựa vào việc agent đọc lệnh cấm rồi tự tuân thủ.

3. Chuyển lên con người cần một kênh thực sự tiếp cận được, không phải một comment TODO. Agent “chuyển lên con người” bằng cách để lại comment trong mô tả PR về cơ bản không phải là chuyển lên — không ai đọc nó cho tới lúc review, quá trễ cho các trường hợp mơ hồ lẽ ra phải chặn sớm hơn. Hãy nối escalation thực sự tới một kênh Slack hoặc nhóm reviewer bắt buộc được trigger tự động bởi gate.

Phần khó chịu nhất

Đây không thực sự là câu chuyện về agent hành xử tệ. Đây là câu chuyện về các tổ chức kỹ thuật viết quản trị theo kiểu viết một bản ghi nhớ, trong khi quản trị cho hệ thống tự động cần được viết theo kiểu viết một hệ thống authorization — mặc định từ chối, xác minh ở ranh giới, log mọi thứ. Phần lớn các đội tôi trò chuyện vẫn chỉ có một file AI_POLICY.md và không gì khác. Khoảng trống đó chính là thứ nghiên cứu này đo được, và rất có thể bạn cũng đang có khoảng trống y hệt nếu chưa từng kiểm tra.

Nguồn: Coding agents ignore open source contribution guidelines, researchers find — The New Stack

Xuất nội dung

Bình luận