[PATCH 1/4] docs/zh_CN: translate coding-assistants.rst

[Dongliang Mu <dzm91@hust.edu.cn>]

Translate the AI coding assistant guidance into Chinese. Link to the
existing Chinese license-rules.rst guide while keeping untranslated
document references on their English paths.

Update the translation through commit 1e035297ffda
("docs: remove Assisted-by references")
---
 .../zh_CN/process/coding-assistants.rst       | 74 +++++++++++++++++++
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/translations/zh_CN/process/coding-assistants.rst

diff --git a/Documentation/translations/zh_CN/process/coding-assistants.rst b/Documentation/translations/zh_CN/process/coding-assistants.rst
new file mode 100644
index 000000000000..2a432d1dc401
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/coding-assistants.rst
@@ -0,0 +1,74 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:翻译:
+ - 慕冬亮 Dongliang Mu <dzm91@hust.edu.cn>
+
+AI 编程助手
++++++++++++
+
+本文为使用 AI 工具及 AI 辅助功能参与 Linux 内核开发的开发者提供指导。
+
+协助 Linux 内核开发的 AI 工具应遵循标准的内核开发流程：
+
+* Documentation/translations/zh_CN/process/development-process.rst
+* Documentation/translations/zh_CN/process/coding-style.rst
+* Documentation/translations/zh_CN/process/submitting-patches.rst
+
+有关 AI 编程助手生成内容的准则，参见：
+
+* Documentation/process/generated-content.rst
+
+许可和法律要求
+==============
+
+所有贡献都必须符合内核的许可要求：
+
+* 所有代码必须与 GPL-2.0-only 兼容
+* 使用适当的 SPDX 许可证标识符
+* 详情参见 Documentation/translations/zh_CN/process/license-rules.rst
+
+Signed-off-by 与开发者来源认证
+==============================
+
+AI 代理 **不得** 添加 Signed-off-by 标签。只有人类才能依法作出
+开发者来源认证（DCO）。人类投稿者负责：
+
+* 审查所有由 AI 生成的代码
+* 确保符合许可要求
+* 添加自己的 Signed-off-by 标签，以确认符合 DCO 要求
+* 对贡献承担全部责任
+
+查找和修复缺陷的流程
+====================
+
+使用 AI 助手查找和修复缺陷时，**必须** 至少遵循以下步骤：
+
+1. 开始之前，完整阅读上面列出的流程文档，以及请求中提及的其他文档。
+   不要只依赖关键词搜索找到的片段。
+2. 记录提交 ID，并按指示定位缺陷。
+3. 对于发现的任何非显而易见的缺陷，尝试编写复现程序，验证缺陷看起来
+   确实存在。若缺少复现程序，报告可能被忽略，因为提交给维护者的许多
+   未经验证的缺陷报告最终被证明无效。如果最终发现判断有误，就在此停止。
+4. 编写修复补丁。这一步不可省略：除极少数情况外，能够发现缺陷的 AI 助手
+   也能够修复它。通常最好在发现缺陷的同一会话中编写修复，因为此时大语言
+   模型仍保留着相关的推理上下文，修复也会更好、更准确。
+5. 构建并通过复现程序或重新运行完整分析来验证修复；丢弃无效的修复并
+   尝试其他方案。修复不能引入构建警告，且必须通过 checkpatch.pl 检查
+   （参见
+   Documentation/translations/zh_CN/process/submitting-patches.rst）。
+6. 将有效的修复提交，并在提交说明中详细描述问题、解决方案和 Fixes 标签。
+   不要添加 Signed-off-by 标签。
+7. 使用 scripts/get_maintainer.pl 找出维护者和邮件列表。
+   具体操作见
+   Documentation/translations/zh_CN/process/security-bugs.rst。
+8. 说明哪些工作未能完成。如果修复无法构建或测试，或者无法编写复现程序，
+   应明确说明：维护者目前在分析未经验证的报告和未经测试的修复上浪费了
+   太多时间。
+9. 阅读 Documentation/process/threat-model.rst，判断缺陷属于漏洞
+   还是普通缺陷，并将结论交由报告者复核（助手绝不能自行发送任何
+   内容）。普通缺陷按以下文档所述方式投稿：
+   Documentation/translations/zh_CN/process/submitting-patches.rst；
+   漏洞按以下文档所述方式报告：
+   Documentation/translations/zh_CN/process/security-bugs.rst。
-- 
2.51.0