过去半年AI 编程从“新鲜玩具”变成了很多人每天都会用到的基础设施。不管是 IDE 里的代码补全还是让大模型帮忙解释报错、补测试、写文档AI/LLM 已经深度参与到了日常开发中。不过在参与开源项目、给团队仓库提交代码时我逐渐意识到一个问题AI 生成代码用起来很方便但如果缺少边界和策略它也会给代码库带来很不确定的风险。这个风险不一定是 AI 能力不够更多是使用方式太随意。这篇文章想分享一份适用于个人开发者、开源贡献者的“Personal policy for AI/LLM driven contribution”。这不算什么官方标准也不是要限制大家用 AI而是一套我踩过不少坑之后整理出来的使用边界和操作流程。主要内容包括AI/LLM 驱动贡献的核心概念、工具选型、五条基本原则、一次完整的实战流程以及高频问题排查和工程建议。如果你正在用 AI 写代码、提 PR、维护开源项目或者开始认真思考“AI 生成的代码到底能不能直接合入”这份策略会给你一个可以落地的参考。1. 为什么需要一份 AI/LLM 贡献策略1.1 AI 辅助编程已经变成日常今天打开 VSCode、Cursor、JetBrains 全家桶AI 插件几乎成了标配。很多团队已经用上了 GitHub Copilot、通义灵码、Codeium也会通过 OpenAI API、Claude API 或本地部署的开源模型来辅助开发。AI 不再只用在“写一段装饰器”这种小场景而是能参与需求分析、方案设计、单元测试、代码审查、文档编写等完整贡献链路。这就带来一个很实际的问题AI 确实可以提高产出速度但 AI 产出内容的可靠程度并不稳定。同样一句“帮我修复登录页面的 bug”不同模型、不同提示词、不同上下文会产生完全不同的结果。有些结果是教科书级别的有些则是看似合理但无法通过测试的伪代码。如果直接把这些内容推给远端仓库最后承担后果的还是开发者自己。这里说的“AI/LLM driven contribution”指的是以 AI 大模型作为辅助工具去完成开源或团队项目中的代码、文档、测试、审查等贡献动作。它的关键不在于“用了 AI”而在于“围绕 AI 建立一套可控的流程”。1.2 没有策略时会出现哪些问题我观察到的典型问题主要有四类第一类是“过度信任 AI 生成内容”。大模型给出的代码往往格式规范看起来很像能运行但可能引用了不存在的库函数或者 API 参数根本对不上。直接把这类代码合入主干分支轻则 CI 挂掉重则引入线上问题。第二类是“对许可证和版权不敏感”。AI 的训练数据来源非常复杂直接复制大段 AI 输出可能带上与项目许可证不兼容的内容。越是开源项目越需要在 PR 中声明 AI 辅助情况并保留人类审查记录。第三类是“提示词泄露敏感信息”。为了让 AI 更准确地解决问题很多人习惯把生产环境的配置、数据库结构、内部报错信息直接贴进对话框。这在个人本地环境还好一旦使用云端 API数据就会离开你的控制边界。第四类是“丧失代码所有权和责任感”。当团队成员发现代码是 AI 生成的就会形成一种“那不是我的代码”的心理暗示。这种暗示会降低代码审查的严格程度也会让问题定位变得困难。所以“个人策略”不是给 AI 设置限制而是给自己设置一套保护机制让 AI 成为放大器而不是责任的转移对象。1.3 这份策略适合谁适合人群很明确给开源项目提 PR 的贡献者、需要频繁写单元测试和文档的后端开发、独立做 side project 的开发者以及想在团队里推广 AI 辅助开发的人。读完这篇文章你可以得到三样东西一套判断“哪些环节可以交给 AI、哪些必须人工负责”的原则。一份可以直接复用或修改的 AI 辅助贡献流程包含提示词示例、Python 代码示例、pytest 测试示例、pre-commit 配置和 PR 描述模板。一份实际问题排查表覆盖编译失败、幻觉 API、安全漏洞、许可证争议等高频问题。2. AI/LLM 驱动贡献的核心概念与边界2.1 AI 辅助与完全自动化的区别很多人会把“AI 辅助开发”和“AI Agent 自动开发”混在一起。实际上这两者有本质区别。AI 辅助开发AI-assisted development的核心是人就在回路里。AI 负责生成候选代码、测试用例、文档初稿但人类负责理解、筛选、修改和最终决策。这种模式中AI 是“协作编辑器”你能掌控每一行进入代码库的内容。AI Agent 自动开发则更激进。它把任务拆解、代码编写、命令执行、测试运行甚至 PR 提交都交给 Agent 完成。人类只在最后检查结果。像最近讨论很多的 LLM Agent、AutoGPT、编程智能体框架就在往这个方向演进。个人策略建议从“AI 辅助”开始不要一上来就追求全自动。不是因为 Agent 不好而是因为它把“检查成本”推后了。全自动生成的代码一旦出错你从头审查的成本可能比直接手写更高。除非你已经对项目代码、AI 能力和审查流程有足够把握否则先让人工决策覆盖关键路径更稳妥。2.2 贡献链路中的人工把关点一次标准贡献通常包含需求澄清、方案设计、编写代码、补充测试、运行验证、代码审查、合并发布。在 AI/LLM 驱动贡献中前面的环节都可以让 AI 参与但有几个节点必须人工把关。首先是“方案设计”节点。AI 可以给出几种实现思路但最终选哪种要基于代码库现状、性能目标、兼容性约束来判断。这个判断不应完全交给 AI。其次是“核心逻辑”节点。业务核心逻辑、安全相关逻辑、金额计算、权限校验等不适合让 AI 生成后直接通过。AI 可以生成初版但你要逐行核对甚至重写关键分支。再次是“代码审查”节点。AI 可以帮你 review 代码但你需要自己再确认一遍。AI review 擅长发现代码风格、边界遗漏但很难理解业务意图和团队潜规则。最后是“合并发布”节点。CI 是否通过、测试覆盖率是否符合要求、格式是否正确、commit message 是否规范这些必须用真实工具验证不能只看 AI 判断。2.3 边界场景什么时候坚决不用 AI 生成除了明确“哪里能用 AI”策略里还需要明确“哪里不用”。我自己的经验是以下几类场景不属于 AI 生成范围涉及密钥、Token、数据库密码的代码需要精确到毫秒级的并发控制安全加密算法的实现需要满足特定合规要求的审计日志以及那些你完全看不懂、无法 review 的代码。如果 AI 生成了一段你读不懂但能通过测试的代码这恰恰是最危险的情况。因为在项目后续迭代中你无法维护它。我建议在个人策略里加一条凡是 AI 生成、但你无法逐行解释的代码一律重写或丢弃。3. 环境准备常用工具与模型选型3.1 主流 AI 编程助手当前 AI 编程工具有很多种选哪个主要取决于个人习惯和项目语言。GitHub Copilot老牌的代码补全工具跟 VSCode、JetBrains 集成得很好适合日常补全和生成重复代码。Cursor基于 VSCode 的 AI 原生编辑器可以对整个代码库建立索引支持跨文件提问和重构适合处理较大项目。Codeium / Windsurf免费或低成本选择支持常见 IDE 插件适合个人项目。通义灵码、文心快码等国内工具与国产 IDE 生态结合得更好也能处理中文需求描述。通过 API 调用 GPT、Claude、国产大模型灵活度最高适合写脚本、批处理、自动化测试生成。本文的重点不是评测工具而是帮你建立“无论用哪个工具都能生效”的策略。所以下面示例会尽量使用通用流程不绑定具体产品。3.2 版本要求与项目结构AI/LLM 辅助开发并不需要特殊运行环境。它依赖的往往是你本来就在用的开发环境Python 3.9、Node.js 16、Git、IDE 或代码编辑器。如果是通过 API 调用大模型需要准备好 API Key并注意把 Key 存进.env文件或本地环境变量不要写入代码仓库。如果是本地部署开源模型则需要一个至少能跑 7B 参数模型的机器通常建议 16GB 以上内存或独立显卡。作者在实际使用中发现模型能力对生成质量影响很大但 Prompt 的质量和上下文信息完整度往往比换一个更大参数的模型更能提升结果。下面用一个示例项目结构来说明后续的流程。它很小但包含了一段带业务逻辑的 Python 函数和对应的测试文件。my_project/ ├── app.py ├── test_app.py ├── .env ├── .pre-commit-config.yaml └── README.md这个结构足够演示“AI 生成、人工审查、测试验证、提交 PR”的完整流程。4. 制定个人策略五条基本原则4.1 原则一先理解再生成很多失败案例的根源是项目上下文太少导致 AI 只能靠猜测生成代码。比如直接问“帮我写一个限流器”AI 一定会给出一个通用版本但这个版本可能不符合项目的认证逻辑、数据库结构、配置中心方式。正确做法是在提示词中先交代项目背景、约束条件、输入输出格式和已存在的相关函数。哪怕多占用一些 token也比后期修改省时。下面是一个比较规范的需求描述示例。这里直接用自然语言描述需求让 AI 生成候选代码我有一个 Python 项目使用 Flask 写出 HTTP 登录接口。 数据库使用 PostgreSQL通过 SQLAlchemy ORM 操作。 用户表叫做 users包含字段id、username、password_hash、is_active、created_at。 请你实现一个 login 函数 1. 根据 username 查询用户 2. 如果用户不存在或 is_activeFalse返回统一错误信息避免用户枚举 3. 用 Werkzeug 的 check_password_hash 校验密码 4. 登录成功后生成 token 字符串并返回。 注意不要修改数据库模型不要引入新的依赖。请先给出实现思路再给出代码。加入“先给出实现思路再给出代码”这个要求后你会发现 AI 的输出明显更有条理也更容易审查。4.2 原则二核心逻辑人工负责代码可以分成两类。一类是样板代码DTO 类、配置读取、模型字段定义、基础 CRUD、测试数据构造这类代码交给 AI 生成效率最高。另一类是核心逻辑鉴权、支付、库存扣减、多线程并发控制、算法核心这些必须人工主导。个人策略建议AI 可以生成核心逻辑的“初稿”但初稿只作为灵感参考或评审素材不能直接进入主分支。你要把每个分支、每个异常路径都自己过一遍甚至重写。这里用一个简单的例子说明。下面这段是 AI 生成的一个“限制登录失败次数”的函数表面看起来很完整# 这是 AI 生成的初稿不能直接用于生产 def handle_login_fail(user_id: int): cache_key flogin_fail:{user_id} fails redis_client.get(cache_key) if fails is None: redis_client.set(cache_key, 1, ex300) else: new_count int(fails) 1 redis_client.set(cache_key, new_count, ex300) if int(redis_client.get(cache_key)) 5: # 实际项目中这里还应该标记用户锁定状态 return {locked: True} return {locked: False}这段代码存在不少问题并发下不是原子操作、redis_client.get与int转换没有异常保护、锁定状态没有持久化。人工审查时就应该把这些都改掉。使用 Redis 的INCR和EXPIRE原语会更合适并在连续失败达到阈值时把锁定写入数据库。这个改写逻辑可能只有两三行但价值比 AI 生成的部分大得多。4.3 原则三生成内容必须验证AI 生成的任何内容包括代码、测试、文档、配置都默认是不可信的要经过机器和人工双重验证。机器验证包括三件事编译或语法检查是否通过单元测试是否通过代码规范检查lint、format是否通过。人工验证包括阅读并理解代码核对是否符合需求检查边界条件、异常处理和性能影响。很多团队会加一层 Code Review让 AI 先做一轮 review再由人工 review。这种方式效率很高但前提是 Review 的人本身对代码有理解不能因为 AI review 过了就松懈。4.4 原则四标注 AI 参与在开源社区和团队协作中是否标注 AI 参与是专业度问题。如果你在 PR 描述中写清楚“本 PR 中哪些代码由 AI 辅助生成哪些由人工编写”维护者会更容易判断 review 重点。当然不是所有项目都强制要求但这个习惯可以避免很多潜在的许可证纠纷。下面是我常用的 PR 描述模板可以直接复制到 GitHub 的 PR 描述中## What type of PR is this? - [x] Bugfix - [ ] Feature - [ ] Refactor - [ ] Documentation ## AI-assisted contribution statement 本 PR 中使用 AI 辅助完成了以下内容 - 初版代码生成使用 LLM 生成了 login 函数的初版 - 单元测试生成使用 LLM 生成了未覆盖分支的测试用例 - 代码审查使用 LLM 进行了静态风格检查。 人工完成的修改 - 修复了登录失败计数器在并发下的原子性问题 - 补充了 user.locked 持久化字段 - 添加了 Redis 异常时的降级逻辑。 ## Checklist - [x] 已阅读并理解项目贡献指南 - [x] 已在本地运行所有测试 - [x] 已确认不会泄露密钥或敏感配置。写上这样的声明不是为了免责而是为了让协作更透明。4.5 原则五敏感信息不进入提示词提示词中的数据会发给云端模型服务。哪怕模型服务商声称不存储数据对企业项目和开源项目来说把生产环境配置、密码、密钥、内部 API 加进提示词也是高风险行为。个人策略的底线是代码中涉及到的密码、Token、AK/SK、数据库地址、用户手机号等字段一律用占位符替代截取日志时要先把 IP、用户标识等敏感字段脱敏在 IDE 插件里关闭“自动收集代码片段作为训练数据”的选项或至少阅读相关隐私协议。如果你需要在本地完成高敏感场景下的 AI 辅助可以选择本地部署小模型例如使用 Ollama 运行 Llama 3 或 Qwen 系列。这类方案在数据流上更可控代价是模型能力相对云端 API 弱一些需要更清晰的提示词来弥补。5. 实战案例用 LLM 辅助完成一次开源贡献5.1 场景设定假设你参与维护一个 Python 开源项目项目里有一个函数叫做calculate_discount负责计算订单折扣。最近有一个 issue 反馈当order_amount为 0 或负数时函数会抛出不友好的异常希望能优雅处理。项目结构如下orders/ ├── discount.py ├── test_discount.py ├── README.md └── pyproject.toml当前discount.py内容如下# 文件路径orders/discount.py def calculate_discount(order_amount: float, user_level: str) - float: 根据订单金额和用户等级计算折扣。 if user_level vip: rate 0.8 elif user_level normal: rate 1.0 else: raise ValueError(unknown user_level) return order_amount * rateissue 希望当订单金额是 0 或负数时返回 0.0当金额是正数时保留原有逻辑。现在我们要用 AI/LLM 辅助完成这次贡献。5.2 用 LLM 分析 issue 并生成候选补丁我们先把上下文整理成提示词发给大模型。推荐把当前代码、报错信息、期望行为都放进去。下面是项目中的一段代码读取并分析它。 python def calculate_discount(order_amount: float, user_level: str) - float: if user_level vip: rate 0.8 elif user_level normal: rate 1.0 else: raise ValueError(unknown user_level) return order_amount * rate需求当 order_amount 0 时函数返回 0.0当 user_level 不是 vip 或 normal 时仍然抛出 ValueError不改变函数名和外部返回类型现有测试可以继续通过。请先说明修改思路再输出完整的修改后代码。大模型的输出大致会是这样 python # 文件路径orders/discount.py def calculate_discount(order_amount: float, user_level: str) - float: 根据订单金额和用户等级计算折扣。 如果订单金额为 0 或负数直接返回 0.0。 if order_amount 0: return 0.0 if user_level vip: rate 0.8 elif user_level normal: rate 1.0 else: raise ValueError(unknown user_level) return order_amount * rate这一段看起来合理但还不能直接提交。原因在于如果用户等级不是vip也不是normal且订单金额为0函数会直接返回0.0而不会抛出原本的ValueError。这可能不符合项目预期。我们需要人工调整顺序保证“非法等级”仍然由原来的异常处理覆盖# 文件路径orders/discount.py def calculate_discount(order_amount: float, user_level: str) - float: 根据订单金额和用户等级计算折扣。 当订单金额为 0 或负数时返回 0.0。 if order_amount 0: return 0.0 if user_level not in (vip, normal): raise ValueError(unknown user_level) rate 0.8 if user_level vip else 1.0 return order_amount * rate这就是“核心逻辑人工负责”原则的体现AI 生成候选人工把关异常边界。5.3 用 LLM 生成单元测试补丁改好后需要补测试。把修改后的函数粘贴给模型并说明要覆盖哪些场景请为下面的函数编写 pytest 单元测试。 def calculate_discount(order_amount: float, user_level: str) - float: if order_amount 0: return 0.0 if user_level not in (vip, normal): raise ValueError(unknown user_level) rate 0.8 if user_level vip else 1.0 return order_amount * rate 请覆盖以下场景 1. vip 用户正数金额 2. normal 用户正数金额 3. 0 金额 4. 负数金额 5. 非法等级AI 输出测试代码可能如下人工 review 后可放入test_discount.py# 文件路径orders/test_discount.py import pytest from discount import calculate_discount def test_vip_user_gets_discount(): assert calculate_discount(100.0, vip) 80.0 def test_normal_user_pays_full(): assert calculate_discount(100.0, normal) 100.0 def test_zero_amount_returns_zero(): assert calculate_discount(0, vip) 0.0 def test_negative_amount_returns_zero(): assert calculate_discount(-10, normal) 0.0 def test_unknown_user_level_raises_error(): with pytest.raises(ValueError): calculate_discount(100.0, guest)5.4 用自动化工具验证代码在本地进入项目目录安装依赖并运行测试cd orders python -m pytest test_discount.py -v预期输出中应该能看到 5 个测试全部通过。接着运行一下代码风格检查例如ruff check .或black --check .。这些都是实际项目中常见的验证方式。如果没有安装 pytest可以这样安装pip install pytest如果你使用 pre-commit 这类工具可以在.pre-commit-config.yaml中配置基础校验让 AI 生成的代码在提交前被自动检查# 文件路径.pre-commit-config.yaml repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.5.0 hooks: - id: trailing-whitespace - id: end-of-file-fixer - repo: https://github.com/psf/black rev: 23.12.1 hooks: - id: black - repo: https://github.com/charliermarsh/ruff-pre-commit rev: v0.1.9 hooks: - id: ruff args: [--fix]注意pre-commit hook 版本号需要根据项目实际情况调整。核心思路是机器能检查的就不要让人工重复检查。5.5 提交 PR 并在描述中声明 AI 辅助完成本地验证后创建新分支并提交git checkout -b fix/discount-zero-amount git add orders/discount.py orders/test_discount.py .pre-commit-config.yaml git commit -m fix: handle non-positive order amount in discount calculation git push origin fix/discount-zero-amount提交时commit message 要规范描述清楚改动原因。然后在 GitHub 页面创建 PR按之前的原则四在 PR 描述中明确标注 AI 参与的部分。6. 常见问题与排查思路6.1 AI 生成的代码编译不过或测试不通过问题现象常见原因解决思路编译报错提示找不到某个函数或类AI 编造了不存在的 API把报错信息回传给模型要求基于实际版本重新生成测试失败函数返回结果不符合预期提示词没有描述清楚边界条件先补充清晰的输入输出规则再让 AI 生成本地依赖冲突运行环境不一致项目依赖版本和 AI 默认假设不一致在提示词贴出 requirements.txt 或 pyproject.toml 关键内容这类问题最有效的排查方式是“把真实报错带回对话”。不要笼统地说“代码不对”而是把错误堆栈、相关文件片段、Python/Node 版本一起贴出来。6.2 AI 生成了不存在的 API 或过时用法大模型在训练数据中见过大量不同版本的代码库所以可能生成过时 API。例如在调试 Spring AI 或 LLM 应用时不同版本的 SDK 对ChatClient、ChatModel等组件的包路径和初始化方式都不太一样。排查建议是优先查看官方文档和当前依赖版本而不是盲目相信 AI 输出。可以把官方文档的关键段落复制给模型并要求“只基于我提供的这段文档来生成代码”。这样能明显减少幻觉。6.3 AI 生成的代码存在安全风险常见的安全问题包括直接拼接 SQL、未做权限校验、把错误堆栈返回给前端、日志中打印明文密码。AI 生成的样板代码尤其容易在输入验证和异常处理上偷懒。解决方法人工审查时把“输入验证、权限校验、密钥管理”列为必查项。使用静态安全扫描工具例如 Bandit、Semgrep、CodeQL。对所有来自用户输入的内容保持不信任即使代码是 AI 生成的。6.4 版权与许可证争议这个问题在开源项目中比较敏感。虽然国内个人项目目前普遍不太关注但如果你准备提交到 Apache 2.0、MIT 或 GPL 项目至少要做到不直接粘贴大段来自聊天工具、博客、其他开源项目的完整代码除非你确认许可证兼容。在 PR 描述中如实说明 AI 辅助情况。保留原始人工设计与实现文档。如果项目明确禁止 AI 贡献就遵守项目规则不要偷偷使用。7. 把策略落进日常我的个人检查清单7.1 每次 AI 贡献前先说清楚上下文我给自己定的流程是AI 参与任何贡献前先在提示词里写清楚四件事——项目背景、本次需求、约束条件、期望输出格式。这样能避免大量无效往返。7.2 提交前逐项核对检查清单我平时会在项目根目录放一个AI_CONTRIBUTION_CHECKLIST.md文件内容类似下面这样。这个文件可以提交到仓库中也可以只放在本地。# AI 辅助贡献检查清单 - [ ] 我已经理解 AI 生成的核心逻辑能逐行解释 - [ ] 我已经验证代码可以在本机编译、测试通过 - [ ] 我已经检查过异常路径和边界条件 - [ ] 我已经确认没有在代码或日志中写入敏感信息 - [ ] 我已经阅读 AI 生成的代码没有发现明显安全问题 - [ ] 我在 PR 描述中声明了 AI 辅助情况 - [ ] 我确认项目的许可证允许 AI 辅助贡献。这份清单会根据使用场景持续更新。它本质上是把前面五条原则变成了可勾选的动作。7.3 在日常开发中平衡效率与责任你可以把 AI 用在最耗费时间的重复劳动上比如生成数据模型、补测试用例、写 commit message、做代码格式修复。也可以把 AI 作为初版 reviewer加速代码审查。但永远记住代码提交者的名字是你自己最终对代码负责的也是你自己。在实际项目中我还会保留一份“AI 使用日志”在本地记录当天哪个模型、哪个提示词产生了哪些代码。这不是强制要求但在排查“这段代码当时是怎么来的”时非常有用。8. 我的最终建议关于 AI/LLM 驱动贡献我最想分享的一点是不要把 AI 生成的代码当成“标准答案”而是把它当成“候选答案”。你自己的技术判断、项目理解和审查习惯才是代码质量的最终防线。我的个人策略并不复杂核心就三条第一AI 可以参与任何环节但核心决策必须由人来做。第二AI 生成的所有内容默认不可信必须经过机器验证和人工理解。第三在贡献到他人项目之前把 AI 参与情况说清楚把敏感信息隔离干净把测试真正跑过。如果你还在观望不妨从一个小 issue 开始按照本文的流程让 AI 帮你分析问题、生成初版代码、补充测试然后自己逐行审查并提交 PR。亲身体验过一次完整流程后你就能建立对这个工具更真实的判断也会逐渐形成属于你自己的 AI/LLM 驱动贡献策略。 AI/LLM驱动开源贡献的个人策略：边界、流程与实战
过去半年AI 编程从“新鲜玩具”变成了很多人每天都会用到的基础设施。不管是 IDE 里的代码补全还是让大模型帮忙解释报错、补测试、写文档AI/LLM 已经深度参与到了日常开发中。不过在参与开源项目、给团队仓库提交代码时我逐渐意识到一个问题AI 生成代码用起来很方便但如果缺少边界和策略它也会给代码库带来很不确定的风险。这个风险不一定是 AI 能力不够更多是使用方式太随意。这篇文章想分享一份适用于个人开发者、开源贡献者的“Personal policy for AI/LLM driven contribution”。这不算什么官方标准也不是要限制大家用 AI而是一套我踩过不少坑之后整理出来的使用边界和操作流程。主要内容包括AI/LLM 驱动贡献的核心概念、工具选型、五条基本原则、一次完整的实战流程以及高频问题排查和工程建议。如果你正在用 AI 写代码、提 PR、维护开源项目或者开始认真思考“AI 生成的代码到底能不能直接合入”这份策略会给你一个可以落地的参考。1. 为什么需要一份 AI/LLM 贡献策略1.1 AI 辅助编程已经变成日常今天打开 VSCode、Cursor、JetBrains 全家桶AI 插件几乎成了标配。很多团队已经用上了 GitHub Copilot、通义灵码、Codeium也会通过 OpenAI API、Claude API 或本地部署的开源模型来辅助开发。AI 不再只用在“写一段装饰器”这种小场景而是能参与需求分析、方案设计、单元测试、代码审查、文档编写等完整贡献链路。这就带来一个很实际的问题AI 确实可以提高产出速度但 AI 产出内容的可靠程度并不稳定。同样一句“帮我修复登录页面的 bug”不同模型、不同提示词、不同上下文会产生完全不同的结果。有些结果是教科书级别的有些则是看似合理但无法通过测试的伪代码。如果直接把这些内容推给远端仓库最后承担后果的还是开发者自己。这里说的“AI/LLM driven contribution”指的是以 AI 大模型作为辅助工具去完成开源或团队项目中的代码、文档、测试、审查等贡献动作。它的关键不在于“用了 AI”而在于“围绕 AI 建立一套可控的流程”。1.2 没有策略时会出现哪些问题我观察到的典型问题主要有四类第一类是“过度信任 AI 生成内容”。大模型给出的代码往往格式规范看起来很像能运行但可能引用了不存在的库函数或者 API 参数根本对不上。直接把这类代码合入主干分支轻则 CI 挂掉重则引入线上问题。第二类是“对许可证和版权不敏感”。AI 的训练数据来源非常复杂直接复制大段 AI 输出可能带上与项目许可证不兼容的内容。越是开源项目越需要在 PR 中声明 AI 辅助情况并保留人类审查记录。第三类是“提示词泄露敏感信息”。为了让 AI 更准确地解决问题很多人习惯把生产环境的配置、数据库结构、内部报错信息直接贴进对话框。这在个人本地环境还好一旦使用云端 API数据就会离开你的控制边界。第四类是“丧失代码所有权和责任感”。当团队成员发现代码是 AI 生成的就会形成一种“那不是我的代码”的心理暗示。这种暗示会降低代码审查的严格程度也会让问题定位变得困难。所以“个人策略”不是给 AI 设置限制而是给自己设置一套保护机制让 AI 成为放大器而不是责任的转移对象。1.3 这份策略适合谁适合人群很明确给开源项目提 PR 的贡献者、需要频繁写单元测试和文档的后端开发、独立做 side project 的开发者以及想在团队里推广 AI 辅助开发的人。读完这篇文章你可以得到三样东西一套判断“哪些环节可以交给 AI、哪些必须人工负责”的原则。一份可以直接复用或修改的 AI 辅助贡献流程包含提示词示例、Python 代码示例、pytest 测试示例、pre-commit 配置和 PR 描述模板。一份实际问题排查表覆盖编译失败、幻觉 API、安全漏洞、许可证争议等高频问题。2. AI/LLM 驱动贡献的核心概念与边界2.1 AI 辅助与完全自动化的区别很多人会把“AI 辅助开发”和“AI Agent 自动开发”混在一起。实际上这两者有本质区别。AI 辅助开发AI-assisted development的核心是人就在回路里。AI 负责生成候选代码、测试用例、文档初稿但人类负责理解、筛选、修改和最终决策。这种模式中AI 是“协作编辑器”你能掌控每一行进入代码库的内容。AI Agent 自动开发则更激进。它把任务拆解、代码编写、命令执行、测试运行甚至 PR 提交都交给 Agent 完成。人类只在最后检查结果。像最近讨论很多的 LLM Agent、AutoGPT、编程智能体框架就在往这个方向演进。个人策略建议从“AI 辅助”开始不要一上来就追求全自动。不是因为 Agent 不好而是因为它把“检查成本”推后了。全自动生成的代码一旦出错你从头审查的成本可能比直接手写更高。除非你已经对项目代码、AI 能力和审查流程有足够把握否则先让人工决策覆盖关键路径更稳妥。2.2 贡献链路中的人工把关点一次标准贡献通常包含需求澄清、方案设计、编写代码、补充测试、运行验证、代码审查、合并发布。在 AI/LLM 驱动贡献中前面的环节都可以让 AI 参与但有几个节点必须人工把关。首先是“方案设计”节点。AI 可以给出几种实现思路但最终选哪种要基于代码库现状、性能目标、兼容性约束来判断。这个判断不应完全交给 AI。其次是“核心逻辑”节点。业务核心逻辑、安全相关逻辑、金额计算、权限校验等不适合让 AI 生成后直接通过。AI 可以生成初版但你要逐行核对甚至重写关键分支。再次是“代码审查”节点。AI 可以帮你 review 代码但你需要自己再确认一遍。AI review 擅长发现代码风格、边界遗漏但很难理解业务意图和团队潜规则。最后是“合并发布”节点。CI 是否通过、测试覆盖率是否符合要求、格式是否正确、commit message 是否规范这些必须用真实工具验证不能只看 AI 判断。2.3 边界场景什么时候坚决不用 AI 生成除了明确“哪里能用 AI”策略里还需要明确“哪里不用”。我自己的经验是以下几类场景不属于 AI 生成范围涉及密钥、Token、数据库密码的代码需要精确到毫秒级的并发控制安全加密算法的实现需要满足特定合规要求的审计日志以及那些你完全看不懂、无法 review 的代码。如果 AI 生成了一段你读不懂但能通过测试的代码这恰恰是最危险的情况。因为在项目后续迭代中你无法维护它。我建议在个人策略里加一条凡是 AI 生成、但你无法逐行解释的代码一律重写或丢弃。3. 环境准备常用工具与模型选型3.1 主流 AI 编程助手当前 AI 编程工具有很多种选哪个主要取决于个人习惯和项目语言。GitHub Copilot老牌的代码补全工具跟 VSCode、JetBrains 集成得很好适合日常补全和生成重复代码。Cursor基于 VSCode 的 AI 原生编辑器可以对整个代码库建立索引支持跨文件提问和重构适合处理较大项目。Codeium / Windsurf免费或低成本选择支持常见 IDE 插件适合个人项目。通义灵码、文心快码等国内工具与国产 IDE 生态结合得更好也能处理中文需求描述。通过 API 调用 GPT、Claude、国产大模型灵活度最高适合写脚本、批处理、自动化测试生成。本文的重点不是评测工具而是帮你建立“无论用哪个工具都能生效”的策略。所以下面示例会尽量使用通用流程不绑定具体产品。3.2 版本要求与项目结构AI/LLM 辅助开发并不需要特殊运行环境。它依赖的往往是你本来就在用的开发环境Python 3.9、Node.js 16、Git、IDE 或代码编辑器。如果是通过 API 调用大模型需要准备好 API Key并注意把 Key 存进.env文件或本地环境变量不要写入代码仓库。如果是本地部署开源模型则需要一个至少能跑 7B 参数模型的机器通常建议 16GB 以上内存或独立显卡。作者在实际使用中发现模型能力对生成质量影响很大但 Prompt 的质量和上下文信息完整度往往比换一个更大参数的模型更能提升结果。下面用一个示例项目结构来说明后续的流程。它很小但包含了一段带业务逻辑的 Python 函数和对应的测试文件。my_project/ ├── app.py ├── test_app.py ├── .env ├── .pre-commit-config.yaml └── README.md这个结构足够演示“AI 生成、人工审查、测试验证、提交 PR”的完整流程。4. 制定个人策略五条基本原则4.1 原则一先理解再生成很多失败案例的根源是项目上下文太少导致 AI 只能靠猜测生成代码。比如直接问“帮我写一个限流器”AI 一定会给出一个通用版本但这个版本可能不符合项目的认证逻辑、数据库结构、配置中心方式。正确做法是在提示词中先交代项目背景、约束条件、输入输出格式和已存在的相关函数。哪怕多占用一些 token也比后期修改省时。下面是一个比较规范的需求描述示例。这里直接用自然语言描述需求让 AI 生成候选代码我有一个 Python 项目使用 Flask 写出 HTTP 登录接口。 数据库使用 PostgreSQL通过 SQLAlchemy ORM 操作。 用户表叫做 users包含字段id、username、password_hash、is_active、created_at。 请你实现一个 login 函数 1. 根据 username 查询用户 2. 如果用户不存在或 is_activeFalse返回统一错误信息避免用户枚举 3. 用 Werkzeug 的 check_password_hash 校验密码 4. 登录成功后生成 token 字符串并返回。 注意不要修改数据库模型不要引入新的依赖。请先给出实现思路再给出代码。加入“先给出实现思路再给出代码”这个要求后你会发现 AI 的输出明显更有条理也更容易审查。4.2 原则二核心逻辑人工负责代码可以分成两类。一类是样板代码DTO 类、配置读取、模型字段定义、基础 CRUD、测试数据构造这类代码交给 AI 生成效率最高。另一类是核心逻辑鉴权、支付、库存扣减、多线程并发控制、算法核心这些必须人工主导。个人策略建议AI 可以生成核心逻辑的“初稿”但初稿只作为灵感参考或评审素材不能直接进入主分支。你要把每个分支、每个异常路径都自己过一遍甚至重写。这里用一个简单的例子说明。下面这段是 AI 生成的一个“限制登录失败次数”的函数表面看起来很完整# 这是 AI 生成的初稿不能直接用于生产 def handle_login_fail(user_id: int): cache_key flogin_fail:{user_id} fails redis_client.get(cache_key) if fails is None: redis_client.set(cache_key, 1, ex300) else: new_count int(fails) 1 redis_client.set(cache_key, new_count, ex300) if int(redis_client.get(cache_key)) 5: # 实际项目中这里还应该标记用户锁定状态 return {locked: True} return {locked: False}这段代码存在不少问题并发下不是原子操作、redis_client.get与int转换没有异常保护、锁定状态没有持久化。人工审查时就应该把这些都改掉。使用 Redis 的INCR和EXPIRE原语会更合适并在连续失败达到阈值时把锁定写入数据库。这个改写逻辑可能只有两三行但价值比 AI 生成的部分大得多。4.3 原则三生成内容必须验证AI 生成的任何内容包括代码、测试、文档、配置都默认是不可信的要经过机器和人工双重验证。机器验证包括三件事编译或语法检查是否通过单元测试是否通过代码规范检查lint、format是否通过。人工验证包括阅读并理解代码核对是否符合需求检查边界条件、异常处理和性能影响。很多团队会加一层 Code Review让 AI 先做一轮 review再由人工 review。这种方式效率很高但前提是 Review 的人本身对代码有理解不能因为 AI review 过了就松懈。4.4 原则四标注 AI 参与在开源社区和团队协作中是否标注 AI 参与是专业度问题。如果你在 PR 描述中写清楚“本 PR 中哪些代码由 AI 辅助生成哪些由人工编写”维护者会更容易判断 review 重点。当然不是所有项目都强制要求但这个习惯可以避免很多潜在的许可证纠纷。下面是我常用的 PR 描述模板可以直接复制到 GitHub 的 PR 描述中## What type of PR is this? - [x] Bugfix - [ ] Feature - [ ] Refactor - [ ] Documentation ## AI-assisted contribution statement 本 PR 中使用 AI 辅助完成了以下内容 - 初版代码生成使用 LLM 生成了 login 函数的初版 - 单元测试生成使用 LLM 生成了未覆盖分支的测试用例 - 代码审查使用 LLM 进行了静态风格检查。 人工完成的修改 - 修复了登录失败计数器在并发下的原子性问题 - 补充了 user.locked 持久化字段 - 添加了 Redis 异常时的降级逻辑。 ## Checklist - [x] 已阅读并理解项目贡献指南 - [x] 已在本地运行所有测试 - [x] 已确认不会泄露密钥或敏感配置。写上这样的声明不是为了免责而是为了让协作更透明。4.5 原则五敏感信息不进入提示词提示词中的数据会发给云端模型服务。哪怕模型服务商声称不存储数据对企业项目和开源项目来说把生产环境配置、密码、密钥、内部 API 加进提示词也是高风险行为。个人策略的底线是代码中涉及到的密码、Token、AK/SK、数据库地址、用户手机号等字段一律用占位符替代截取日志时要先把 IP、用户标识等敏感字段脱敏在 IDE 插件里关闭“自动收集代码片段作为训练数据”的选项或至少阅读相关隐私协议。如果你需要在本地完成高敏感场景下的 AI 辅助可以选择本地部署小模型例如使用 Ollama 运行 Llama 3 或 Qwen 系列。这类方案在数据流上更可控代价是模型能力相对云端 API 弱一些需要更清晰的提示词来弥补。5. 实战案例用 LLM 辅助完成一次开源贡献5.1 场景设定假设你参与维护一个 Python 开源项目项目里有一个函数叫做calculate_discount负责计算订单折扣。最近有一个 issue 反馈当order_amount为 0 或负数时函数会抛出不友好的异常希望能优雅处理。项目结构如下orders/ ├── discount.py ├── test_discount.py ├── README.md └── pyproject.toml当前discount.py内容如下# 文件路径orders/discount.py def calculate_discount(order_amount: float, user_level: str) - float: 根据订单金额和用户等级计算折扣。 if user_level vip: rate 0.8 elif user_level normal: rate 1.0 else: raise ValueError(unknown user_level) return order_amount * rateissue 希望当订单金额是 0 或负数时返回 0.0当金额是正数时保留原有逻辑。现在我们要用 AI/LLM 辅助完成这次贡献。5.2 用 LLM 分析 issue 并生成候选补丁我们先把上下文整理成提示词发给大模型。推荐把当前代码、报错信息、期望行为都放进去。下面是项目中的一段代码读取并分析它。 python def calculate_discount(order_amount: float, user_level: str) - float: if user_level vip: rate 0.8 elif user_level normal: rate 1.0 else: raise ValueError(unknown user_level) return order_amount * rate需求当 order_amount 0 时函数返回 0.0当 user_level 不是 vip 或 normal 时仍然抛出 ValueError不改变函数名和外部返回类型现有测试可以继续通过。请先说明修改思路再输出完整的修改后代码。大模型的输出大致会是这样 python # 文件路径orders/discount.py def calculate_discount(order_amount: float, user_level: str) - float: 根据订单金额和用户等级计算折扣。 如果订单金额为 0 或负数直接返回 0.0。 if order_amount 0: return 0.0 if user_level vip: rate 0.8 elif user_level normal: rate 1.0 else: raise ValueError(unknown user_level) return order_amount * rate这一段看起来合理但还不能直接提交。原因在于如果用户等级不是vip也不是normal且订单金额为0函数会直接返回0.0而不会抛出原本的ValueError。这可能不符合项目预期。我们需要人工调整顺序保证“非法等级”仍然由原来的异常处理覆盖# 文件路径orders/discount.py def calculate_discount(order_amount: float, user_level: str) - float: 根据订单金额和用户等级计算折扣。 当订单金额为 0 或负数时返回 0.0。 if order_amount 0: return 0.0 if user_level not in (vip, normal): raise ValueError(unknown user_level) rate 0.8 if user_level vip else 1.0 return order_amount * rate这就是“核心逻辑人工负责”原则的体现AI 生成候选人工把关异常边界。5.3 用 LLM 生成单元测试补丁改好后需要补测试。把修改后的函数粘贴给模型并说明要覆盖哪些场景请为下面的函数编写 pytest 单元测试。 def calculate_discount(order_amount: float, user_level: str) - float: if order_amount 0: return 0.0 if user_level not in (vip, normal): raise ValueError(unknown user_level) rate 0.8 if user_level vip else 1.0 return order_amount * rate 请覆盖以下场景 1. vip 用户正数金额 2. normal 用户正数金额 3. 0 金额 4. 负数金额 5. 非法等级AI 输出测试代码可能如下人工 review 后可放入test_discount.py# 文件路径orders/test_discount.py import pytest from discount import calculate_discount def test_vip_user_gets_discount(): assert calculate_discount(100.0, vip) 80.0 def test_normal_user_pays_full(): assert calculate_discount(100.0, normal) 100.0 def test_zero_amount_returns_zero(): assert calculate_discount(0, vip) 0.0 def test_negative_amount_returns_zero(): assert calculate_discount(-10, normal) 0.0 def test_unknown_user_level_raises_error(): with pytest.raises(ValueError): calculate_discount(100.0, guest)5.4 用自动化工具验证代码在本地进入项目目录安装依赖并运行测试cd orders python -m pytest test_discount.py -v预期输出中应该能看到 5 个测试全部通过。接着运行一下代码风格检查例如ruff check .或black --check .。这些都是实际项目中常见的验证方式。如果没有安装 pytest可以这样安装pip install pytest如果你使用 pre-commit 这类工具可以在.pre-commit-config.yaml中配置基础校验让 AI 生成的代码在提交前被自动检查# 文件路径.pre-commit-config.yaml repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.5.0 hooks: - id: trailing-whitespace - id: end-of-file-fixer - repo: https://github.com/psf/black rev: 23.12.1 hooks: - id: black - repo: https://github.com/charliermarsh/ruff-pre-commit rev: v0.1.9 hooks: - id: ruff args: [--fix]注意pre-commit hook 版本号需要根据项目实际情况调整。核心思路是机器能检查的就不要让人工重复检查。5.5 提交 PR 并在描述中声明 AI 辅助完成本地验证后创建新分支并提交git checkout -b fix/discount-zero-amount git add orders/discount.py orders/test_discount.py .pre-commit-config.yaml git commit -m fix: handle non-positive order amount in discount calculation git push origin fix/discount-zero-amount提交时commit message 要规范描述清楚改动原因。然后在 GitHub 页面创建 PR按之前的原则四在 PR 描述中明确标注 AI 参与的部分。6. 常见问题与排查思路6.1 AI 生成的代码编译不过或测试不通过问题现象常见原因解决思路编译报错提示找不到某个函数或类AI 编造了不存在的 API把报错信息回传给模型要求基于实际版本重新生成测试失败函数返回结果不符合预期提示词没有描述清楚边界条件先补充清晰的输入输出规则再让 AI 生成本地依赖冲突运行环境不一致项目依赖版本和 AI 默认假设不一致在提示词贴出 requirements.txt 或 pyproject.toml 关键内容这类问题最有效的排查方式是“把真实报错带回对话”。不要笼统地说“代码不对”而是把错误堆栈、相关文件片段、Python/Node 版本一起贴出来。6.2 AI 生成了不存在的 API 或过时用法大模型在训练数据中见过大量不同版本的代码库所以可能生成过时 API。例如在调试 Spring AI 或 LLM 应用时不同版本的 SDK 对ChatClient、ChatModel等组件的包路径和初始化方式都不太一样。排查建议是优先查看官方文档和当前依赖版本而不是盲目相信 AI 输出。可以把官方文档的关键段落复制给模型并要求“只基于我提供的这段文档来生成代码”。这样能明显减少幻觉。6.3 AI 生成的代码存在安全风险常见的安全问题包括直接拼接 SQL、未做权限校验、把错误堆栈返回给前端、日志中打印明文密码。AI 生成的样板代码尤其容易在输入验证和异常处理上偷懒。解决方法人工审查时把“输入验证、权限校验、密钥管理”列为必查项。使用静态安全扫描工具例如 Bandit、Semgrep、CodeQL。对所有来自用户输入的内容保持不信任即使代码是 AI 生成的。6.4 版权与许可证争议这个问题在开源项目中比较敏感。虽然国内个人项目目前普遍不太关注但如果你准备提交到 Apache 2.0、MIT 或 GPL 项目至少要做到不直接粘贴大段来自聊天工具、博客、其他开源项目的完整代码除非你确认许可证兼容。在 PR 描述中如实说明 AI 辅助情况。保留原始人工设计与实现文档。如果项目明确禁止 AI 贡献就遵守项目规则不要偷偷使用。7. 把策略落进日常我的个人检查清单7.1 每次 AI 贡献前先说清楚上下文我给自己定的流程是AI 参与任何贡献前先在提示词里写清楚四件事——项目背景、本次需求、约束条件、期望输出格式。这样能避免大量无效往返。7.2 提交前逐项核对检查清单我平时会在项目根目录放一个AI_CONTRIBUTION_CHECKLIST.md文件内容类似下面这样。这个文件可以提交到仓库中也可以只放在本地。# AI 辅助贡献检查清单 - [ ] 我已经理解 AI 生成的核心逻辑能逐行解释 - [ ] 我已经验证代码可以在本机编译、测试通过 - [ ] 我已经检查过异常路径和边界条件 - [ ] 我已经确认没有在代码或日志中写入敏感信息 - [ ] 我已经阅读 AI 生成的代码没有发现明显安全问题 - [ ] 我在 PR 描述中声明了 AI 辅助情况 - [ ] 我确认项目的许可证允许 AI 辅助贡献。这份清单会根据使用场景持续更新。它本质上是把前面五条原则变成了可勾选的动作。7.3 在日常开发中平衡效率与责任你可以把 AI 用在最耗费时间的重复劳动上比如生成数据模型、补测试用例、写 commit message、做代码格式修复。也可以把 AI 作为初版 reviewer加速代码审查。但永远记住代码提交者的名字是你自己最终对代码负责的也是你自己。在实际项目中我还会保留一份“AI 使用日志”在本地记录当天哪个模型、哪个提示词产生了哪些代码。这不是强制要求但在排查“这段代码当时是怎么来的”时非常有用。8. 我的最终建议关于 AI/LLM 驱动贡献我最想分享的一点是不要把 AI 生成的代码当成“标准答案”而是把它当成“候选答案”。你自己的技术判断、项目理解和审查习惯才是代码质量的最终防线。我的个人策略并不复杂核心就三条第一AI 可以参与任何环节但核心决策必须由人来做。第二AI 生成的所有内容默认不可信必须经过机器验证和人工理解。第三在贡献到他人项目之前把 AI 参与情况说清楚把敏感信息隔离干净把测试真正跑过。如果你还在观望不妨从一个小 issue 开始按照本文的流程让 AI 帮你分析问题、生成初版代码、补充测试然后自己逐行审查并提交 PR。亲身体验过一次完整流程后你就能建立对这个工具更真实的判断也会逐渐形成属于你自己的 AI/LLM 驱动贡献策略。