• 作者：劉哲佑
• 背景：如果想要長期貢獻並取得社群信任，關於 AI 的使用有一些想補充的看法。

PR description 只提重點，盡量不要有 AI 感

• 如果一句話可以講完，就不用把 Agent 列出的所有驗證步驟都留下來。例如跑過的 unit tests 不必全部列出，畢竟 CI 也會直接驗證；但如果想特別提到關鍵的測試案例，列出來沒關係。
• 可以直接假設 reviewer 是沒耐心看完長篇大論的人。

耐心看過每一行 prod code path，並了解對應的行為

• 對於有點規模的功能或修復，需要理解這個改動對上層模組、整個 component，甚至整個 Airflow 架構來說是否合理。
• CI、static check script 我自己不會這麼嚴謹，但至少要確認改動可以達到預期行為。

Code review 可以用 Agent，但應該是第二層防線，而不是第一層

• Agent 有時候沒辦法指出上一點提到的架構缺失。
• 盡量不要只留一個 LGTM 就 approve。即使是 Fable 5、GPT 6 寫出來的 code，親自掃過每一行還是很容易找到可以更好的地方。

確認達到以上條件，再把 PR 開成 open to review

提醒自己改的是重要的開源基礎建設

不夠嚴謹的 patch 反而會造成更長遠的 regression，其實不利於專案的長期發展。

以上也是我自己在盡力遵守的（有時候趕 timeline 也會不小心太 vibe，但還是會想辦法守住）。