把 AI/LLM 驱动贡献当成一位真正参与项目的编外工程师来看是我最近半年最大的转变。早期我也到处收集提示词今天让 AI 改个函数明天让它补个注释觉得自己效率很高。但问题很快出现同一个 bugAI 给出的修法每次都不一样有时它很保守有时又过度设计更麻烦的是我不知道它写的代码里哪一段是我根本没看懂的。后来我发现真正缺的不是更强的模型也不是更长的提示词而是一份个人政策。所谓个人政策不是公司制度而是你自己定的一套规则什么任务可以交给 AI什么任务必须人工把关产出之后要过哪些检查出现问题先查什么。它就像一份精简版工程规范约束对象不是团队而是你自己。这篇文章把我现在的个人政策完整拆一遍。内容偏向 AI/LLM 在代码贡献、技术方案输出、开源协作和日常开发中的实际落地适合正在用 Cursor、PyCharm AI 插件或各类 LLM 编程工具的开发者也适合刚开始做 AI 应用开发、AI Agent、AI 测试的人参考。核心判断只有一句话用 AI 不是为了让审查消失而是为了把人的精力集中在真正需要判断的地方。1. 为什么要把“用 AI 写代码”沉淀成个人政策1.1 没有规则的时候AI 用起来是什么状态没有个人政策时最常见的状态是“任务驱动型使用”今天遇到报错把报错贴给 AI让它给方案明天写接口让 AI 生成代码后天做代码审查让 AI 找问题。表面上很高效实际上有三个明显问题。第一产出质量不稳定。同样是“给这个类加一个缓存”AI 可能给你三种完全不同的实现还都写得像模像样。如果你没有提前定好约束选哪个就变成了运气问题。我之前遇到过 AI 连续三天给出三种缓存方案分别是本地 Map、Caffeine、Redis而项目实际只有一个单机实例。它不是不能干活而是不知道你的边界在哪。第二审查成本被转嫁。AI 生成的代码看似完整但每一个“看似”背后都可能藏着边界条件没处理、错误路径没覆盖、隐式依赖没声明。你说省了时间实际上是把审查时间延后了延到提交之后、合并之后甚至上线之后。第三责任边界模糊。项目出了问题如果代码是 AI 写的谁来解释你在提交记录上签字你就是责任人。但如果你根本不知道那几行代码在干什么出问题时排查起来会非常慢因为你连猜测方向都没有。1.2 个人政策到底管什么我现在的个人政策只管四件事任务边界哪些任务允许交给 AI哪些不允许质量门禁AI 产出必须满足什么条件才能进入下一步审查流程提交之前必须做哪些检查按什么顺序做反馈闭环出问题时怎么定位是提示词问题、上下文问题还是模型本身问题。这套东西的覆盖范围从最初的“代码生成”扩展到了现在的“需求澄清、技术方案对比、测试用例生成、PR 描述、文档整理、故障排查”。范围越大越需要政策否则 AI 参与的环节越多你的不可控感越强。有人会问政策会不会太重我的体会是写政策本身只需要十几分钟但它能挡住后面无数个小时的返工。特别是当你不只是自己在用 AI还要把 AI 驱动贡献变成可持续的日常工作方式时规则比热情更重要。2. 先划分任务类型哪些适合 AI 驱动哪些必须人工把关2.1 按风险等级把贡献任务分成四类我这里说的“贡献”不单指开源 PR也包括你给自己项目提交的代码、给团队写的技术方案、给产品做的调研报告。分类标准只有一个如果 AI 在这件事上出错损失有多大补救要多久。任务类型AI 参与程度人工把关重点机械性编码高结果是否真正可用是否引入多余依赖调研与方案草稿中高事实是否真实来源是否可查结论是否合理架构设计与重构中约束条件是否被理解权衡是否全面安全、权限、支付、数据敏感逻辑低必须逐行人工审查AI 只做辅助解释机械性编码是我最常交给 AI 的重复的 DTO、配置文件、API 封装、单测模板、日志格式统一。这类任务出错容易发现补救成本低AI 产出通常够用。调研与方案草稿AI 可以给出很好的框架但事实部分要人工核。它可能在方案里写一个“业界常用做法”实际上那个做法早就过时了也可能把某个库的 API 写得很像真的你一调用就报错。我一般把 AI 当研究助理而不是数据库。架构设计和重构要做到低风险交付。比如“把这段逻辑抽成一个独立服务”AI 能帮你列出几种拆分方式但最终选哪种要由了解业务上下文的人决定。不要因为 AI 给了三套对比方案就默认它已经理解了你系统的全部约束。安全、权限、支付、数据敏感相关逻辑我建议保持最低 AI 参与度。不是说完全不能用而是 AI 的产出只能当草稿任何涉及鉴权、密钥、用户数据、金额计算的代码必须逐行人工审查并且要有测试覆盖关键路径。2.2 一个常用判断标准AI 错了你多久能发现如果 AI 出错后你跑一条命令或看一个输出就能发现这类任务可以放心交给它。如果错误会潜伏到线上、会等到用户反馈才暴露这类任务就不能全权委托。比如给前端写一个表单校验函数错得再离谱跑个用例就能看出来属于可委托。再比如写一个支付回调验签逻辑一旦写错金额、订单、对账全部受影响这类必须人工主导AI 只能解释它见过的常见写法。这个判断标准比“哪些任务 AI 擅长”更实用。因为同一类任务在不同项目里的风险等级不同。批量文件重命名工具内部工具可以交给 AI线上数据清洗脚本就要谨慎得多。3. 我的 AI 驱动贡献工作流从 issue 到 PR 的完整链路3.1 前置环境准备我建议不管用 Cursor、PyCharm AI 插件还是命令行里的 LLM 工具都要先把三样东西准备好项目说明README、架构文档、贡献指南作为 AI 的语境基础本地可运行环境能跑单测、能构建、能查看日志干净的输入issue 描述、复现步骤、相关报错日志。不少 AI 生成代码质量差的场景根源不是模型不聪明而是你给它的上下文太少。你只丢一句“帮我优化这个函数”它只能靠猜。我通常会先让 AI 读一遍相关文件再让它基于具体 issue 给出实现。现在的工具普遍支持把文件加入上下文把这个动作变成习惯比写任何提示词都重要。如果项目本身是 LLM 应用开发比如用了 Spring AI、MCP、RAG 或 Agent 框架环境准备的复杂度会更高。因为这类项目既依赖模型服务又有向量库、外部工具调用、消息队列等组件。AI 生成的代码能不能跑通很大程度取决于这些外部服务的地址、密钥、版本是否都配好了。所以我的原则是先保证整个项目在本地能跑通再谈让 AI 帮你写新功能。3.2 分阶段工作流我现在的流程分五个阶段每个阶段都有人工检查点。第一阶段需求澄清。拿到一个 issue先用 LLM 帮我把“问题描述”改写成“需求清单”。比如 issue 写“列表加载很慢”AI 能帮我拆出数据量多大、慢在哪一步、期望耗时是多少、有没有并发要求。这些信息不确认后面写的代码大概率要返工。这个阶段的人工检查点是需求清单里的每一条你都能在原始问题里找到依据。第二阶段技术方案。让 AI 给出两到三种候选方案并分别列出改动范围、风险、测试策略。你可以用普通提示词结合项目实际约束让 AI 做对比。人工检查点是方案里提到的依赖和 API 是否真实存在是否和当前项目版本兼容。第三阶段编码实现。我坚持小步提交。一次只让 AI 改一个职责比如先写数据访问层再写业务逻辑最后写接口层。每改完一块马上跑编译和测试。人工检查点是编译是否通过测试是否通过改动是否超出本次需求。第四阶段测试补充。让 AI 为本次改动生成测试用例但不要直接采用。先看它生成的用例覆盖了哪些分支再把缺的边界条件补上。比如 AI 只测了正常列表返回你就要补空列表、超大列表、超时场景。人工检查点是关键错误路径有没有测试测试有没有断言真实结果而不是走过场。第五阶段提交与文档。AI 生成 commit message 和 PR 描述非常省事。不是让它编历史而是把 diff 和 issue 链接丢给它让它按项目规范写清楚“改了什么、为什么改、测试怎么做”。人工检查点是PR 描述里的每一句话都符合事实。3.3 从单条任务到批量贡献如果你已经能稳定跑通单条 AI 驱动贡献还要考虑批量场景。比如你负责一个旧项目需要把几十个文件从旧 API 迁移到新 API。不要把全部文件一次性丢给 AI。正确做法是先迁移一个文件跑完整测试确认迁移模式可行再挑两个不同类型的文件验证模式是否通用最后才批量处理。批量处理时检查点要更频繁每处理 5 个文件看一次 diff重点看有没有 AI 自作主张的格式调整或功能改动。很多 AI 工具在批量任务里会顺手“美化”代码这种无关改动会让 PR 很难评审。4. 代码审查标准AI 产出必须过这几道关4.1 默认不信任但要有审查顺序AI 生成的代码我的默认态度是不信任但审查要有顺序不能瞎查。第一道关是“是否解决真问题”。把 AI 的改动和 issue 描述对照。如果它写了很多代码但核心问题没动说明上下文理解偏了重写提示词比修修补补更快。第二道关是“改动范围是否可控”。看 diff排除无关文件的修改。AI 经常会在你让它改 A 文件的时候顺手改了 B 文件的格式。这种改动要全部撤回。第三道关是“边界和错误路径”。AI 很擅长写正常路径但异常路径经常被忽略。输入为空怎么办超时怎么办并发冲突怎么办外部服务不可用怎么办。这些要在真实代码里逐一确认。第四道关是“测试是否真实有效”。AI 生成的测试常见问题是断言太弱。比如只是断言“函数不抛异常”但没有验证返回值正确。这种测试看着绿实际没用。4.2 解释性审查法我有个习惯每段 AI 代码并入主分支之前先让它用自然语言解释一遍“这段代码做了什么为什么这样做有哪些前置条件和隐藏假设。”如果它解释得清楚说明代码至少是它认真生成的如果解释得很含糊基本可以断定那段代码是拼出来的需要重点回查。这个动作对新手特别有用。你不需要一开始就具备很强的代码直觉通过对 AI 的解释和实际代码做对照可以快速建立对代码的敏感度。用一段时间之后你会明显感觉到自己分辨“写得像样”和“写得可靠”的能力在提升。4.3 验证指标要对应真实场景代码能不能编译、测试能不能过是最低标准。真正要关注的验证指标是四类功能正确性核心逻辑在正常和异常输入下输出是否符合预期兼容性改动是否受系统版本、依赖版本、输入格式差异影响;性能涉及大数据量、并发、长任务时是否引入明显性能回退可维护性命名是否清晰结构是否合理后续别人能否读得懂。性能这一点如果你的项目涉及 LLM 推理还要额外关注精度问题。比如模型用 fp16、bf16 还是 fp32 加载输出结果会有差异。AI 写的推理代码如果没把精度配置写清楚在线下测试正常在线上低精度部署时可能出现完全不同的行为。这类问题不是编译错误也跑不出红色日志只能在效果对比时发现。我在自己的 LLM 应用里踩过这种坑同一个问题fp16 和 fp32 的回答在某些边界场景下会不一样AI 生成的代码不会主动告诉你这些差异需要你从部署和测试层面兜住。5. 边界与坑点这些场景不要急着交给 AI5.1 哪些场景我明确不委托第一安全敏感代码。认证、鉴权、密钥管理、令牌校验、输入过滤这五类我不让 AI 直接产出最终版本。AI 可以解释原理、列出常见写法但最终代码我要自己写或至少逐行改写。第二遗留系统改造。AI 对热门框架很熟悉对你们公司内部的三代老系统一无所知。让它改老代码很容易出现“看起来更现代、实际和现有逻辑不相容”的改动。遇到老系统我认为 AI 的最佳角色是解释器不是生成器。你可以让它读老代码并解释但改动要人来定。第三性能关键路径。涉及大量计算、高频调用、资源竞争的逻辑AI 生成的“优化”可能只是风格层面的美化实际上没有解决性能问题甚至引入新的分配开销。性能优化一定要有基准测试支撑不能让 AI 凭感觉优化。第四对外协议和数据结构变更。改接口协议、改数据库字段、改消息格式这类改动牵一发动全身。AI 能帮你生成迁移脚本但兼容策略、灰度计划、回滚方案必须人来设计。5.2 常见坑和排查链路AI 驱动贡献最常见的六大坑提示词没问题但上下文给少了AI 自己脑补了不存在的 API代码能编译但运行时报错因为依赖版本和 AI 训练数据里的 API 对不上测试全绿但只测了正常路径异常路径完全没覆盖AI 做了隐性行为变更比如把同步改成异步把重试次数改了外部调用方感知不到文档和代码不一致AI 改了代码之后把注释和 README 也顺手改了但改得和实际行为对不上批量任务里出现无关格式化改动污染 PR diff。我自己的排查顺序是先看现象确认是编译错、运行错还是结果错再看输入确认给 AI 的文件、日志、issue 描述是否完整再看范围确认 diff 里有没有不该动的文件再看上下文确认工具是否真的读取了你指定的文件最后才考虑换模型、调提示词或加大上下文。有一个原则值得强调报错不一定是工具能力问题。大多数时候是你给的环境信息不够。先把“给足上下文”这件事做好再谈参数调整和模型选择。5.3 开源协作中的额外注意事项如果你用 AI 驱动贡献参与开源项目除了技术还要注意协作规范。很多项目有贡献指南对 PR 格式、commit 规范、测试要求有明确说明。AI 生成的 PR 描述再漂亮不符合项目规范一样会被要求改。另外不要假装代码完全是自己写的。现在很多项目在贡献说明里会询问 AI 辅助情况或者要求开发者确认自己理解并负责提交的代码。这个不是面子问题是责任问题。你要对自己签名的每一行代码负责无论它出自谁手。6. 把政策落成文档模板和迭代方式6.1 一份最小可用的个人政策模板我的个人政策不是长篇制度而是一份可以随时修改的清单大概长这样# 我的 AI/LLM 驱动贡献政策 ## 允许 - 机械性编码DTO、配置、单测模板、格式整理 - 调研辅助方案对比、资料整理事实需人工核验 - 代码解释理解遗留代码、生成注释 - 文案辅助commit message、PR 描述、文档草稿 ## 不允许 - 安全敏感代码直接定稿 - 性能优化不经过基准测试直接合并 - 批量改动不拆小步直接提交 - 不理解的代码签名提交 ## 质量门禁 1. 编译通过 2. 单测通过 3. 新增用例覆盖关键分支 4. diff 无无关改动 5. 完成解释性审查 ## 故障排查顺序 现象 - 输入 - 范围 - 上下文 - 方案这个模板你可以直接改。把它放到你常用的笔记软件或个人 wiki 里当作你自己的 LLM 使用手册。注意政策不用追求完美先定几条能执行的再根据实际项目反馈迭代。6.2 什么时候需要调整政策我调整政策主要有三种触发点。第一连续两次在同一类任务上踩坑。比如发现 AI 生成的数据库迁移脚本总是漏掉索引那我就会在政策里加一条涉及数据库迁移时必须检查索引和约束。第二项目复杂度变化。从个人项目切换到多人项目从内部工具切换到线上服务风险等级变了政策也要跟着收紧。刚开始我用 AI 给个人博客写工具脚本随便用后来参与团队项目就有了严格的门禁。第三工具能力变化。AI 工具迭代很快今天不支持的格式明天可能就支持了。政策写的是原则不是永久禁令。如果某个任务在充分验证后证明 AI 可以胜任可以把它从“不允许”挪到“允许”。我自己的迭代频率大概是每两周过一遍政策看有没有哪条规则已经过时有没有新场景没被覆盖。不用大改微调即可。6.3 最后说几句如果你刚刚开始用 AI 编程不需要立刻把政策设计得很完整。先定三条最底线的规则比如“不理解的代码不要提交”“所有 AI 改动必须跑测试”“批量改动必须拆小步”。这三条能守住就已经比大多数人的 AI 使用方式可控。如果你已经在用 AI 做大量贡献重点要放在审查流程和反馈闭环上。什么时候你会真正信任 AI 的代码不是它写得多像人而是你知道它会在哪里出错并且有一整套流程能在它出错时拦住它。这份个人政策不会有终点。模型在迭代工具在迭代你负责的代码也在迭代。政策的意义不是限制 AI 的发挥而是让你在 AI 参与度越来越高的情况下依然能对每一行提交出去的代码负责。