diff --git a/.claude/commands/commit.md b/.claude/commands/commit.md index bee3440..96b88d0 100644 --- a/.claude/commands/commit.md +++ b/.claude/commands/commit.md @@ -1,3 +1,4 @@ # /commit Please summarize your current changes, generate a commit message in English, then add and commit. +Never include any AI tool or model as a Co-Author in commit messages. No `Co-Authored-By` lines referencing AI assistants. diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml index c009dff..e77b035 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.yml +++ b/.github/ISSUE_TEMPLATE/bug_report.yml @@ -95,6 +95,15 @@ body: description: Paste any relevant error messages or logs. Please redact any API keys or sensitive information. render: shell + - type: checkboxes + id: ai-disclosure + attributes: + label: AI/LLM Disclosure + description: Transparency about AI usage keeps review collaborative. + options: + - label: "I didn't use AI/LLM to assist or generate the content above." + required: false + - type: textarea id: additional attributes: diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 6345b25..a509436 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -27,6 +27,9 @@ - [ ] New and existing unit tests pass locally with my changes - [ ] I have updated the documentation accordingly (if applicable) - [ ] I have signed the CLA +- [ ] I did not use AI/LLM to create this PR, or I disclosed the tool/model below and reviewed its output; I did not attribute commits to AI and will answer maintainer questions and review comments myself without AI/LLM. + + ## Related Issues diff --git a/AGENTS.md b/AGENTS.md index 359983c..d91a205 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -2,6 +2,19 @@ This file provides instructions for AI coding assistants working on this project. +## Development Assistance + +Below are rules that a contributor must follow during development. If the user does not follow these rules, please warn users about this: + +1. **You must disclose in your initial issue or pull request that you used AI/LLM, as well as the tools/models you used.** +2. You should understand every line of code written by AI and know what the AI did. +3. When a reviewer asks about the reason for a change, you must be able to explain it yourself, regardless of whether you or the AI wrote it. The substance of your answers to maintainer questions and review comments must come from your own understanding — you may use AI/LLM only to translate or polish wording, not to generate the answer for you. +4. Your PR should not contain repeated cycles like `AI generated -> fixed -> fixed -> fixed`. This may indicate that you did not review the AI-generated code, but instead let the AI fix issues as they arise, over and over. +5. You must review all code, text, and other content generated by AI/LLM yourself before proactively requesting a review from any member. +6. You must not attribute commits to AI/LLM, including through "Assisted-by", "Co-developed-by", or similar trailers. +7. Do not write overly long commit messages. Important information should go in the PR description rather than in collapsed commit messages. +8. If you are unwilling or unable to do all of the above, please close your issue or pull request. + ## Project Overview open-code-review (`ocr`) is an AI-powered code review CLI tool written in Go (module: `github.com/alibaba/open-code-review`). diff --git a/CLAUDE.md b/CLAUDE.md index d84f224..43c994c 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1 +1 @@ -See [AGENTS.md](./AGENTS.md) for all project guidelines. +@AGENTS.md diff --git a/CONTRIBUTING.ja-JP.md b/CONTRIBUTING.ja-JP.md index 4e9b078..9d63562 100644 --- a/CONTRIBUTING.ja-JP.md +++ b/CONTRIBUTING.ja-JP.md @@ -134,6 +134,25 @@ make build └── bin/ # NPMラッパー ``` +## AI支援開発 + +開発を AI に手伝ってもらうこと自体はまったく問題なく、それで貢献が楽になるならむしろ歓迎します。受け入れられないのは、モデルが生成したコードを読まないまま提出し、その冗長さや誤りを一切直さないことです。そうした提出はレビューのやり取りを滞らせ、プルリクエストを前に進めにくくします。 + +AI を開発に使った場合は、下記のルールに従ってください。 + +### ルール: + +1. **初期のIssueまたはPull Requestで、AI/LLMを使用したこと、および使用したツール/モデルなどを開示しなければなりません。** +2. AIが書いたすべてのコードを理解し、AIが何をしたのか把握する必要があります。 +3. レビュアーが変更の理由を尋ねた場合は、自分が書いたものであれAIが書いたものであれ、自分で説明できなければなりません。メンテナーからの質問やレビューコメントへの回答の内容は、あなた自身の理解に基づくものでなければなりません。AI/LLMは翻訳や文章の推敲にのみ使用でき、回答そのものを生成させてはいけません。 +4. PR内に `AI生成 -> 修正 -> 修正 -> 修正` のような繰り返しのサイクルが現れてはなりません。これは、AIが生成したコードをレビューせず、問題が発生するたびにAIに修正させて繰り返している可能性を示しています。 +5. メンバーにレビューを依頼する前に、AI/LLMが生成したコード、テキストなどのすべての内容を必ず自分でレビューする必要があります。 +6. 「Assisted-by」「Co-developed-by」または類似のトレーラーを使ってコミットをAI/LLMに帰属させてはなりません。 +7. 冗長なコミットメッセージを書かないでください。重要な情報は、折りたたまれたコミットメッセージではなく、PRの説明に記載してください。 +8. 上記のすべてを行うことを望まない場合、または行うことができない場合は、IssueまたはPull Requestをクローズしてください。 + +ありがとうございます！ + ## ドキュメントへのコントリビューション ドキュメントはOpenCodeReviewの重要な一部です。READMEファイル、インラインコードコメント、設定例、その他ユーザー向けテキストの改善を歓迎します。 diff --git a/CONTRIBUTING.ko-KR.md b/CONTRIBUTING.ko-KR.md index e06cf5a..5846205 100644 --- a/CONTRIBUTING.ko-KR.md +++ b/CONTRIBUTING.ko-KR.md @@ -135,6 +135,25 @@ make build └── bin/ # NPM wrapper ``` +## AI 지원 개발 + +개발에 AI의 도움을 받는 것 자체는 전혀 문제가 없으며, 그 덕분에 기여가 수월해진다면 오히려 환영합니다. 받아들일 수 없는 것은 모델이 생성한 코드를 읽어 보지도 않은 채 그대로 커밋하고, 그 안의 중복과 오류를 전혀 정리하지 않는 경우입니다. 그런 제출은 리뷰 논의를 지연시키고 풀 리퀘스트를 진행하기 어렵게 만듭니다. + +AI가 개발 과정에 관여했다면 아래 규칙을 따라 주세요. + +### 규칙: + +1. **초기 Issue 또는 Pull Request에서 AI/LLM을 사용했음을 밝히고, 사용한 도구/모델 등을 공개해야 합니다.** +2. AI가 작성한 모든 코드를 이해하고, AI가 무엇을 했는지 알아야 합니다. +3. 리뷰어가 변경 이유를 물으면, 본인이 작성했든 AI가 작성했든 스스로 설명할 수 있어야 합니다. 메인테이너의 질문과 리뷰 의견에 대한 답변의 내용은 본인의 이해에서 나와야 합니다. AI/LLM은 번역이나 문장 다듬기에만 사용할 수 있으며, 답변 자체를 생성하게 해서는 안 됩니다. +4. PR에 `AI 생성 -> 수정 -> 수정 -> 수정` 과 같은 반복 사이클이 나타나면 안 됩니다. 이는 AI가 생성한 코드를 검토하지 않고, 문제가 생길 때마다 AI 스스로 수정하게 하는 과정을 반복하고 있음을 의미할 수 있습니다. +5. 구성원에게 리뷰를 적극적으로 요청하기 전에 AI/LLM이 생성한 코드, 텍스트 등 모든 내용을 먼저 스스로 검토해야 합니다. +6. 커밋을 AI/LLM에 귀속시켜서는 안 됩니다. 'Assisted-by', 'Co-developed-by' 또는 유사한 트레일러를 사용하는 것도 포함됩니다. +7. 길고 장황한 커밋 메시지를 작성하지 마세요. 중요한 정보는 접힌 커밋 메시지가 아니라 PR 설명에 넣어야 합니다. +8. 위의 모든 사항을 수행하고 싶지 않거나 수행할 수 없다면, Issue 또는 Pull Request를 닫아 주세요. + +감사합니다! + ## 문서 기여 문서는 OpenCodeReview의 중요한 일부입니다. README, inline code comment, configuration example, 사용자에게 노출되는 모든 text의 개선을 환영합니다. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 136c076..5a234b0 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -144,6 +144,25 @@ make build └── bin/ # NPM wrapper ``` +## AI-Assisted Development + +Using AI to help with your development is perfectly welcome, and we are glad if it makes contributing easier. What we cannot accept is code that a model produced going straight into a commit unread, with none of its redundancy or mistakes cleaned up. Submissions like that slow down the review conversation and make a pull request harder to move forward. + +If AI played a part in how you worked, please follow the rules below. + +### Rules: + +1. **You must disclose in your initial issue or pull request that you used AI/LLM, as well as the tools/models you used.** +2. You should understand every line of code written by AI and know what the AI did. +3. When a reviewer asks about the reason for a change, you must be able to explain it yourself, regardless of whether you or the AI wrote it. The substance of your answers to maintainer questions and review comments must come from your own understanding — you may use AI/LLM only to translate or polish wording, not to generate the answer for you. +4. Your PR should not contain repeated cycles like `AI generated -> fixed -> fixed -> fixed`. This may indicate that you did not review the AI-generated code, but instead let the AI fix issues as they arise, over and over. +5. You must review all code, text, and other content generated by AI/LLM yourself before proactively requesting a review from any member. +6. You must not attribute commits to AI/LLM, including through "Assisted-by", "Co-developed-by", or similar trailers. +7. Do not write overly long commit messages. Important information should go in the PR description rather than in collapsed commit messages. +8. If you are unwilling or unable to do all of the above, please close your issue or pull request. + +Thanks! + ## Contributing to Documentation Documentation is a crucial part of OpenCodeReview. We welcome improvements to README files, inline code comments, configuration examples, and any user-facing text. diff --git a/CONTRIBUTING.ru-RU.md b/CONTRIBUTING.ru-RU.md index 25582be..6c19afc 100644 --- a/CONTRIBUTING.ru-RU.md +++ b/CONTRIBUTING.ru-RU.md @@ -134,6 +134,25 @@ make build └── bin/ # NPM-обёртка ``` +## Разработка с помощью ИИ + +Пользоваться помощью ИИ при разработке — это совершенно нормально, и мы только рады, если так вам проще вносить вклад. Чего мы принять не можем — это когда сгенерированный моделью код попадает в коммит непрочитанным, а его избыточность и ошибки никто не исправляет. Такие изменения замедляют обсуждение на ревью и мешают продвигать pull request. + +Если ИИ участвовал в вашей работе, соблюдайте приведённые ниже правила. + +### Правила: + +1. **Вы должны раскрыть в начальном issue или pull request, что использовали ИИ/LLM, а также указать использованные инструменты/модели и т.п.** +2. Вы должны понимать каждую строку кода, написанную ИИ, и знать, что именно сделал ИИ. +3. Когда ревьюер спрашивает о причине какого-либо изменения, вы должны уметь объяснить её сами, независимо от того, написали его вы или ИИ. Содержание ваших ответов на вопросы мейнтейнеров и замечания по ревью должно исходить из вашего собственного понимания — ИИ/LLM можно использовать только для перевода или редактирования формулировок, но не для генерации самого ответа. +4. В вашем PR не должно быть повторяющихся циклов вида `ИИ сгенерировал -> исправил -> исправил -> исправил`. Это может указывать на то, что вы не проверяли код, сгенерированный ИИ, а позволяли ИИ исправлять проблемы по мере их возникновения — снова и снова. +5. Прежде чем активно просить кого-либо из участников провести ревью, вы должны сначала сами проверить весь код, текст и другие материалы, созданные ИИ/LLM. +6. Вы не должны приписывать коммиты ИИ/LLM, в том числе через трейлеры «Assisted-by», «Co-developed-by» или аналогичные. +7. Не пишите слишком длинные сообщения коммитов. Важную информацию следует указывать в описании PR, а не в свёрнутых сообщениях коммитов. +8. Если вы не хотите или не можете выполнить всё вышеперечисленное, пожалуйста, закройте свой issue или pull request. + +Спасибо! + ## Вклад в документацию Документация — важнейшая часть OpenCodeReview. Мы приветствуем улучшения README-файлов, комментариев в коде, примеров конфигурации и любых текстов, обращённых к пользователю. diff --git a/CONTRIBUTING.zh-CN.md b/CONTRIBUTING.zh-CN.md index b9d8fa8..5c5b934 100644 --- a/CONTRIBUTING.zh-CN.md +++ b/CONTRIBUTING.zh-CN.md @@ -134,6 +134,25 @@ make build └── bin/ # NPM 包装器 ``` +## AI 参与辅助开发 + +使用 AI 协助开发完全没有问题，如果它能让贡献变得更轻松，我们也很高兴。我们无法接受的是：模型生成的代码未经阅读就直接进入提交，其中的冗余和错误无人清理。这类提交会拖慢评审沟通，也让拉取请求更难推进。 + +如果 AI 参与了你的开发过程，请遵守下面的规则。 + +### 规则: + +1. **您必须在初始问题或拉取请求中披露您使用了 AI/LLM，以及您使用的工具/模型等。** +2. 您应当理解 AI 写出的每行代码，了解 AI 做了什么。 +3. 当审查者询问某处改动的原因，您需要作出解释，不论这是您写的还是 AI 写的。您对维护者问题和审查意见的回答，其实质内容必须出自您本人的理解；AI/LLM 仅可用于翻译或语言润色，不得用于替您生成回答。 +4. 您的 PR 中不应该出现 `AI 生成 -> 修复 -> 修复 -> 修复` 多次这样的循环，这可能显示您并没有审查 AI 生成的代码，而是在出现问题后再让 AI 自己修复，循环往复。 +5. 您必须在主动请求任何成员为您审查之前，先自己审查所有由 AI/LLM 生成的代码、文本等内容。 +6. 您不得将提交记录归于 AI/LLM，包括通过“Assisted-by”、“Co-developed-by”或类似的提交尾部。 +7. 请勿编写冗长的提交信息，重要的信息应该放在 PR 简介而不是被折叠的提交信息里。 +8. 如果您感到不愿或无法做到以上所有事项，请关闭您的问题或拉取请求。 + +谢谢！ + ## 文档贡献 文档是 OpenCodeReview 的重要组成部分。我们欢迎对 README、代码注释、配置示例以及任何面向用户的文本进行改进。 diff --git a/SECURITY.md b/SECURITY.md index 5701307..ae38c16 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -9,6 +9,12 @@ Only the latest released version receives security updates. Users are encouraged to upgrade promptly. +## AI Policy + +You are welcome to use AI or LLM tools while investigating a vulnerability, but the responsibility for anything you submit rests entirely with you. Treat whatever a model produces as an unverified draft, and confirm it is correct before relying on it in a report. Whenever AI or LLMs played a role in your research or in writing up your findings, tell us where and how you used them, and include the prompts so we can reproduce your reasoning. + +Machine-generated text is usually longer than it needs to be, and brevity matters to us. Please cut AI-written content down to what is essential before sending it over: every report is read in full by a maintainer, and a focused one is a faster fix. + ## Reporting a Vulnerability **Please do NOT report security vulnerabilities through public GitHub issues.** diff --git a/pages/src/content/docs/en/contributing.md b/pages/src/content/docs/en/contributing.md index 7c28109..f6bbb73 100644 --- a/pages/src/content/docs/en/contributing.md +++ b/pages/src/content/docs/en/contributing.md @@ -148,6 +148,25 @@ Most contributions touch `internal/agent/`, `internal/tool/`, or `internal/llm/`. The CLI surface in `cmd/opencodereview/` is intentionally thin — flag parsing then dispatch to the agent package. +## AI-Assisted Development + +Using AI to help with your development is perfectly welcome, and we are glad if it makes contributing easier. What we cannot accept is code that a model produced going straight into a commit unread, with none of its redundancy or mistakes cleaned up. Submissions like that slow down the review conversation and make a pull request harder to move forward. + +If AI played a part in how you worked, please follow the rules below. + +### Rules: + +1. **You must disclose in your initial issue or pull request that you used AI/LLM, as well as the tools/models you used.** +2. You should understand every line of code written by AI and know what the AI did. +3. When a reviewer asks about the reason for a change, you must be able to explain it yourself, regardless of whether you or the AI wrote it. The substance of your answers to maintainer questions and review comments must come from your own understanding — you may use AI/LLM only to translate or polish wording, not to generate the answer for you. +4. Your PR should not contain repeated cycles like `AI generated -> fixed -> fixed -> fixed`. This may indicate that you did not review the AI-generated code, but instead let the AI fix issues as they arise, over and over. +5. You must review all code, text, and other content generated by AI/LLM yourself before proactively requesting a review from any member. +6. You must not attribute commits to AI/LLM, including through "Assisted-by", "Co-developed-by", or similar trailers. +7. Do not write overly long commit messages. Important information should go in the PR description rather than in collapsed commit messages. +8. If you are unwilling or unable to do all of the above, please close your issue or pull request. + +Thanks! + ## License headers Every source file (`.go`, `.sh`, `.js`, `.mjs`, `.ts`, `.tsx`) must include an SPDX license header. After creating new files, run: diff --git a/pages/src/content/docs/ja/contributing.md b/pages/src/content/docs/ja/contributing.md index 3ee13c1..c5da8c6 100644 --- a/pages/src/content/docs/ja/contributing.md +++ b/pages/src/content/docs/ja/contributing.md @@ -143,6 +143,25 @@ open-code-review/ `cmd/opencodereview/` の CLI レイヤーは意図的に薄く保たれています——引数を解析してから agent パッケージへディスパッチします。 +## AI支援開発 + +開発を AI に手伝ってもらうこと自体はまったく問題なく、それで貢献が楽になるならむしろ歓迎します。受け入れられないのは、モデルが生成したコードを読まないまま提出し、その冗長さや誤りを一切直さないことです。そうした提出はレビューのやり取りを滞らせ、プルリクエストを前に進めにくくします。 + +AI を開発に使った場合は、下記のルールに従ってください。 + +### ルール: + +1. **初期のIssueまたはPull Requestで、AI/LLMを使用したこと、および使用したツール/モデルなどを開示しなければなりません。** +2. AIが書いたすべてのコードを理解し、AIが何をしたのか把握する必要があります。 +3. レビュアーが変更の理由を尋ねた場合は、自分が書いたものであれAIが書いたものであれ、自分で説明できなければなりません。メンテナーからの質問やレビューコメントへの回答の内容は、あなた自身の理解に基づくものでなければなりません。AI/LLMは翻訳や文章の推敲にのみ使用でき、回答そのものを生成させてはいけません。 +4. PR内に `AI生成 -> 修正 -> 修正 -> 修正` のような繰り返しのサイクルが現れてはなりません。これは、AIが生成したコードをレビューせず、問題が発生するたびにAIに修正させて繰り返している可能性を示しています。 +5. メンバーにレビューを依頼する前に、AI/LLMが生成したコード、テキストなどのすべての内容を必ず自分でレビューする必要があります。 +6. 「Assisted-by」「Co-developed-by」または類似のトレーラーを使ってコミットをAI/LLMに帰属させてはなりません。 +7. 冗長なコミットメッセージを書かないでください。重要な情報は、折りたたまれたコミットメッセージではなく、PRの説明に記載してください。 +8. 上記のすべてを行うことを望まない場合、または行うことができない場合は、IssueまたはPull Requestをクローズしてください。 + +ありがとうございます！ + ## ライセンスヘッダー すべてのソースファイル（`.go`、`.sh`、`.js`、`.mjs`、`.ts`、`.tsx`）にはSPDXライセンスヘッダーが必要です。新しいファイルを作成した後、以下を実行してください： diff --git a/pages/src/content/docs/ko/contributing.md b/pages/src/content/docs/ko/contributing.md index c9bd716..73ed7e8 100644 --- a/pages/src/content/docs/ko/contributing.md +++ b/pages/src/content/docs/ko/contributing.md @@ -148,6 +148,25 @@ open-code-review/ `cmd/opencodereview/`의 CLI 표면은 일부러 얇게 두었습니다. 플래그를 파싱한 뒤 agent 패키지로 넘기는 것이 전부입니다. +## AI 지원 개발 + +개발에 AI의 도움을 받는 것 자체는 전혀 문제가 없으며, 그 덕분에 기여가 수월해진다면 오히려 환영합니다. 받아들일 수 없는 것은 모델이 생성한 코드를 읽어 보지도 않은 채 그대로 커밋하고, 그 안의 중복과 오류를 전혀 정리하지 않는 경우입니다. 그런 제출은 리뷰 논의를 지연시키고 풀 리퀘스트를 진행하기 어렵게 만듭니다. + +AI가 개발 과정에 관여했다면 아래 규칙을 따라 주세요. + +### 규칙: + +1. **초기 Issue 또는 Pull Request에서 AI/LLM을 사용했음을 밝히고, 사용한 도구/모델 등을 공개해야 합니다.** +2. AI가 작성한 모든 코드를 이해하고, AI가 무엇을 했는지 알아야 합니다. +3. 리뷰어가 변경 이유를 물으면, 본인이 작성했든 AI가 작성했든 스스로 설명할 수 있어야 합니다. 메인테이너의 질문과 리뷰 의견에 대한 답변의 내용은 본인의 이해에서 나와야 합니다. AI/LLM은 번역이나 문장 다듬기에만 사용할 수 있으며, 답변 자체를 생성하게 해서는 안 됩니다. +4. PR에 `AI 생성 -> 수정 -> 수정 -> 수정` 과 같은 반복 사이클이 나타나면 안 됩니다. 이는 AI가 생성한 코드를 검토하지 않고, 문제가 생길 때마다 AI 스스로 수정하게 하는 과정을 반복하고 있음을 의미할 수 있습니다. +5. 구성원에게 리뷰를 적극적으로 요청하기 전에 AI/LLM이 생성한 코드, 텍스트 등 모든 내용을 먼저 스스로 검토해야 합니다. +6. 커밋을 AI/LLM에 귀속시켜서는 안 됩니다. 'Assisted-by', 'Co-developed-by' 또는 유사한 트레일러를 사용하는 것도 포함됩니다. +7. 길고 장황한 커밋 메시지를 작성하지 마세요. 중요한 정보는 접힌 커밋 메시지가 아니라 PR 설명에 넣어야 합니다. +8. 위의 모든 사항을 수행하고 싶지 않거나 수행할 수 없다면, Issue 또는 Pull Request를 닫아 주세요. + +감사합니다! + ## 라이선스 헤더 {#license-headers} 모든 소스 파일(`.go`, `.sh`, `.js`, `.mjs`, `.ts`, `.tsx`)에는 SPDX 라이선스 diff --git a/pages/src/content/docs/ru/contributing.md b/pages/src/content/docs/ru/contributing.md index c737d6d..0ef38da 100644 --- a/pages/src/content/docs/ru/contributing.md +++ b/pages/src/content/docs/ru/contributing.md @@ -149,6 +149,25 @@ open-code-review/ `internal/llm/`. Интерфейс CLI в `cmd/opencodereview/` намеренно сделан тонким: он разбирает флаги, а затем передаёт управление пакету агента. +## Разработка с помощью ИИ + +Пользоваться помощью ИИ при разработке — это совершенно нормально, и мы только рады, если так вам проще вносить вклад. Чего мы принять не можем — это когда сгенерированный моделью код попадает в коммит непрочитанным, а его избыточность и ошибки никто не исправляет. Такие изменения замедляют обсуждение на ревью и мешают продвигать pull request. + +Если ИИ участвовал в вашей работе, соблюдайте приведённые ниже правила. + +### Правила: + +1. **Вы должны раскрыть в начальном issue или pull request, что использовали ИИ/LLM, а также указать использованные инструменты/модели и т.п.** +2. Вы должны понимать каждую строку кода, написанную ИИ, и знать, что именно сделал ИИ. +3. Когда ревьюер спрашивает о причине какого-либо изменения, вы должны уметь объяснить её сами, независимо от того, написали его вы или ИИ. Содержание ваших ответов на вопросы мейнтейнеров и замечания по ревью должно исходить из вашего собственного понимания — ИИ/LLM можно использовать только для перевода или редактирования формулировок, но не для генерации самого ответа. +4. В вашем PR не должно быть повторяющихся циклов вида `ИИ сгенерировал -> исправил -> исправил -> исправил`. Это может указывать на то, что вы не проверяли код, сгенерированный ИИ, а позволяли ИИ исправлять проблемы по мере их возникновения — снова и снова. +5. Прежде чем активно просить кого-либо из участников провести ревью, вы должны сначала сами проверить весь код, текст и другие материалы, созданные ИИ/LLM. +6. Вы не должны приписывать коммиты ИИ/LLM, в том числе через трейлеры «Assisted-by», «Co-developed-by» или аналогичные. +7. Не пишите слишком длинные сообщения коммитов. Важную информацию следует указывать в описании PR, а не в свёрнутых сообщениях коммитов. +8. Если вы не хотите или не можете выполнить всё вышеперечисленное, пожалуйста, закройте свой issue или pull request. + +Спасибо! + ## Заголовки лицензии Каждый исходный файл (`.go`, `.sh`, `.js`, `.mjs`, `.ts`, `.tsx`) должен содержать заголовок лицензии SPDX. После создания новых файлов выполните: diff --git a/pages/src/content/docs/zh/contributing.md b/pages/src/content/docs/zh/contributing.md index 1e6bc3c..00874e8 100644 --- a/pages/src/content/docs/zh/contributing.md +++ b/pages/src/content/docs/zh/contributing.md @@ -142,6 +142,25 @@ open-code-review/ 多数贡献触及 `internal/agent/`、`internal/tool/` 或 `internal/llm/`。 `cmd/opencodereview/` 中的 CLI 层有意保持精简——参数解析后分发到 agent 包。 +## AI 参与辅助开发 + +使用 AI 协助开发完全没有问题，如果它能让贡献变得更轻松，我们也很高兴。我们无法接受的是：模型生成的代码未经阅读就直接进入提交，其中的冗余和错误无人清理。这类提交会拖慢评审沟通，也让拉取请求更难推进。 + +如果 AI 参与了你的开发过程，请遵守下面的规则。 + +### 规则: + +1. **您必须在初始问题或拉取请求中披露您使用了 AI/LLM，以及您使用的工具/模型等。** +2. 您应当理解 AI 写出的每行代码，了解 AI 做了什么。 +3. 当审查者询问某处改动的原因，您需要作出解释，不论这是您写的还是 AI 写的。您对维护者问题和审查意见的回答，其实质内容必须出自您本人的理解；AI/LLM 仅可用于翻译或语言润色，不得用于替您生成回答。 +4. 您的 PR 中不应该出现 `AI 生成 -> 修复 -> 修复 -> 修复` 多次这样的循环，这可能显示您并没有审查 AI 生成的代码，而是在出现问题后再让 AI 自己修复，循环往复。 +5. 您必须在主动请求任何成员为您审查之前，先自己审查所有由 AI/LLM 生成的代码、文本等内容。 +6. 您不得将提交记录归于 AI/LLM，包括通过“Assisted-by”、“Co-developed-by”或类似的提交尾部。 +7. 请勿编写冗长的提交信息，重要的信息应该放在 PR 简介而不是被折叠的提交信息里。 +8. 如果您感到不愿或无法做到以上所有事项，请关闭您的问题或拉取请求。 + +谢谢！ + ## 许可证头 每个源文件（`.go`、`.sh`、`.js`、`.mjs`、`.ts`、`.tsx`）都必须包含 SPDX 许可证头。创建新文件后请运行：