开头先给结论这篇 34 周周报写的是告别不是卸载教程。我跟一个 AI 编程助手合作了整整 34 周从最开始什么都问、什么代码都让它写到最后把它降级成“偶尔帮忙的实习生”中间经历过真香、翻车、重新定位三个阶段。如果你也在用 AI 写代码或者团队里正在评估要不要引入这类“机器人队友”这篇复盘值得看完。最核心的一句话放在前面AI 队友不是越强越有用而是边界越清楚越有用。能不能用好它取决于你什么时候敢用它什么时候坚决不用它。这篇文章不讲具体的产品名与版本对比只讲我这 34 周里的真实使用节奏、任务类型、翻车场景和评估方式。你可以代入自己正在用的任何 AI 编程工具里面的判断标准基本通用。1. 34周之后我为什么决定让机器人队友“降级”1.1 这段合作从热情高涨到理性评估的全过程刚开始的前 4 周体验确实好。写一个 Python 脚本、补一段单元测试、生成一个增删改查接口它基本几分钟就能出一版。我当时一度觉得团队里两个人干的活我一个人加一个 AI 就能顶下来。前 10 周我给它派的任务非常多频率高的时候一天几十次对话代码库里大量代码块都是 AI 生成的。到了第 12 周到第 18 周问题开始出现。不是它报错变多了而是它生成的代码“看起来没问题”却能在我没注意的地方埋雷。比如生成一个批量处理函数主流程是对的但遇到空文件、超大文件、权限不足、编码不一致时处理方式非常粗糙。我花在评审这些代码上的时间逐渐接近我原本自己写代码的时间。到第 20 周以后我养成了一个习惯每次使用前先判断这个任务值不值得交给它。这个习惯很重要因为它把我和 AI 的关系从“替我做”变成了“辅助我做”。真正促使我在第 34 周写这篇周报并决定降级合作的不是某一次灾难性故障而是连续两周的资源性价比失衡。我统计了一下两周内 AI 生成代码的采纳率从最初的 80% 左右下降到不到 50%。被拒绝的原因不是格式或语法而是业务逻辑理解偏差、边界处理缺失、以及风格不一致。1.2 真正让我改变的三个具体场景第一个场景是处理一个带历史状态机的订单模块。AI 生成的代码能通过单元测试但它不理解系统里哪些状态是历史遗留状态、哪些状态永远不应该再出现。它按照“标准业务逻辑”理解生成了一版会把历史数据重新激活的代码。这个 bug 在测试环境没有立刻暴露因为测试数据太干净了真实环境里才可能出现。第二个场景是重构一个老模块。代码库里有大量兼容历史版本的函数和判断逻辑AI 每次生成的代码都会试图“简化”这些逻辑。从代码整洁角度看它没错从线上稳定性角度看它很危险。重构时删除一段看似冗余的判断可能就删掉了一个保护机制。第三个场景是需求本身不清晰的时候。我让 AI 帮忙设计一个数据导入功能它效率极高半天就给出了方案和代码。但等我确认需求后发现它理解的需求方向和业务方真实意图完全不一样。生成越快返工越狠。这三个场景让我意识到AI 队友最大的问题不是能力下限而是它在能力范围内的“过度自信”。2. 机器人队友最值得用的四类任务2.1 样板代码与基础脚手架34 周下来我把 AI 用得最顺的场景排了一个序排第一的是样板代码和项目脚手架。新建一个后端服务时配置文件、路由注册、数据库连接、基础中间件这些内容重复度高、模式固定、出错后果也相对可控。交给 AI 生成后我会花很少时间检查关键配置项就可以继续往下开发。这类任务适合 AI是因为它的目标很明确生成一个结构正确的起点而不是创造复杂业务逻辑。判断标准也很直接如果这个任务在团队里已经有过两三个相似实现那么 AI 大概率能照着模式写出来。如果团队里完全找不到先例那就要警惕。2.2 单测用例与边界输入补充写单元测试这件事AI 的完成度比很多人预期的要高。它能根据一个函数的入参和返回值快速生成正常路径、空值路径、异常路径的用例骨架。不过我的经验是不能让 AI 自己独立完成全部测试用例。它很擅长生成正常用例也擅长生成一些常见的边界值比如零、负数、空列表、超长字符串。但业务定制的边界条件比如某个字段有 24 位编码规则、某些值组合被业务明确禁止需要人先补充进去。我的做法是先把自己知道的边界条件写成注释再让 AI 生成用例它会把这些注释翻译成代码效果比直接生成好很多。2.3 日志、注释与文档整理这部分是 AI 被低估的强项。我不是指自动生成那种“把代码翻译成中文”的注释而是指整理类的文档工作。比如这段代码的逻辑改了需要把接口说明文档同步更新比如一个模块的 README 写得不够完整需要补充参数说明和调用示例。这类任务没有创造性但很耗时。AI 处理这类任务的优势在于稳定、不烦躁而且不会在文档里加一些没用的感慨。我建议把这类任务当作验证 AI 能力的入门任务。如果一个 AI 助手连文档整理都做不好那就别指望它处理核心业务逻辑了。2.4 跨语言翻译与老代码迁移把 Java 代码翻译成 Python把 SQL 语句从一种方言改成另一种方言把旧接口封装成新接口这类任务 AI 的表现偶尔会惊艳但一定要控制范围。我的判断标准是翻译对象越“机械”越安全。比如纯算法、纯数据转换、纯格式转换这些翻译后容易验证输入输出一一对应。但涉及框架特性的翻译就要非常小心比如 Java 的 Spring 事务传播机制翻译到 Python 框架里语义并不完全等价。34 周里我有几次被惊艳到的时刻基本都是这类“翻译”任务。但也有一次被坑得很惨就是把一段依赖数据库事务隔离级别的旧代码翻译到另一个数据库时AI 完全没意识到隔离级别的差异。所以这类任务只能当作草稿不能当作终稿。3. 最容易翻车的场景以及怎么提前判断3.1 复杂业务状态流转看似正确实则危险我最想提醒的是这类场景业务状态多、状态之间有流转限制、不同角色操作会改变状态走向。AI 拿到这种需求时通常能生成一个看起来结构清晰的状态机代码有枚举、有状态转换表、有校验逻辑。但真实业务里状态流转往往不是一张干净的表格而是夹杂着各种例外。比如“管理员可以跳过某个校验”“历史单据不执行新规则”“接口幂等性要先判断旧状态”。这些例外不会写在需求文档的显眼位置AI 看不到就会按标准流程生成。提前判断的方法也很朴素如果这个模块的状态数量超过 5 个且存在不同角色权限影响流转路径那就不要全量交给 AI。最多让 AI 生成最基础的状态流转骨架再由人来补充例外逻辑。3.2 老系统兼容性AI 不认识你的历史包袱不少团队的系统已经运行了三五年代码里充满了历史包袱。这些包袱包括废弃但仍被老客户端调用的接口、为了兼容老数据而没有删除的字段、因为历史 bug 不得不多写一层判断的兼容逻辑。AI 的数据源基本上来自公开代码和通用知识它很难理解你们团队自己沉淀下来的历史包袱。我见过 AI 生成了新版分页接口逻辑很干净但它没有保留老系统里默认 pageSize 不能超过 100 的全局限制。测试环境没问题上线后一次大流量就把数据库打满了。所以我的建议很明确涉及老系统、老接口、老数据兼容的任务在让 AI 生成前必须把兼容性要求逐条写清楚否则默认它不知道。这不叫提示词工程这叫人肉背景补齐。3.3 需求本身不清晰时生成越快返工越狠这是一个很容易被忽略的规律。需求模糊的时候AI 并不会说“我不清楚”它会基于概率补一轮猜测而且猜测得有理有据。你会看到一个完整可运行的方案然后忍不住往那个方向走。第 16 周时产品经理说要做一个“批量导出优化”我没有追问细节就交给 AI 生成。AI 假设是优化导出速度、增加断点续传。但真正需求是导出文件在服务器上留存时间太长希望增加自动清理策略顺便控制并发导出数量。两套方案完全不同我白花了两天。现在我的规则是需求里凡是出现“优化”“支持”“提升”“完善”这类模糊词先追问三个问题。边界是什么输入输出是什么不可接受的结果是什么这三个问题问清楚了再考虑要不要用 AI。需求不清晰时AI 是最差的需求分析者因为它永远在给一个看似合理的答案。4. 34周里沉淀下来的协作规范4.1 上下文不能只靠对话要把约束写进代码目录很多人用 AI 编程助手的方式是在对话里粘贴一段代码然后说“帮我改一下”。这种方式对简单任务有效但对复杂任务非常不稳定。因为对话是有状态的一旦切换窗口或者隔了一晚上AI 就记不住前面的上下文了。我后来的做法是把关键约束写进项目里的约定文件。比如在项目根目录放一个约束说明写清楚路径规范、命名规范、禁止使用的依赖、数据库分页上限、日志格式要求等。然后每次让 AI 生成代码时让它先读这个文件再动手。这样即使对话中断约束也不会丢。这个方法听起来很笨但它解决了 AI 编程助手的最大痛点记忆不稳定。不要相信它能靠对话记住你的项目规则把规则落成文件才是真正的“给它装记忆”。4.2 评审优先级先看边界再看主流程AI 生成的代码评审时我从不先看主流程。主流程通常是对的因为主流程的逻辑在公开代码里大量存在AI 学得最好。我需要先看边界处理。具体的评审顺序我固定按这几步走输入参数不合法时会怎样数据为空、数据量极小、数据量极大时会怎样外部依赖超时或返回异常时会怎样并发调用时共享状态会不会出问题代码里有没有直接吞掉异常的 catch 块。这个顺序执行下来AI 代码里 80% 的问题都能在评审阶段发现。剩下的 20% 是业务语义问题只能靠人对需求的理解来兜底。4.3 每次迭代都要留“回滚点”AI 生成代码时我见过最多的错误操作就是让 AI 连续迭代每轮微调最后整个函数被改成了一团理论合理但没人完全理解的代码。我现在要求自己每次让 AI 修改前先把当前版本保存成一个独立文件或者至少确保版本控制里能快速回退。AI 的每一次修改都要能够独立验证不能连续修改五轮才检查一次。否则一旦第五轮结果不对你得从五轮前的版本重新开始浪费的时间比手动写还多。具体执行方式是每完成一个小功能点的修改立即跑一次检查。检查内容包括语法、单元测试、边界样例。检查通过后才允许进入下一轮修改。这个“小步快跑”的方式能让 AI 的错误被限制在最小范围内。5. 怎么判断一个 AI 助手值不值得继续用5.1 从功能列表转向四个可量化指标第 30 周左右我做了一个很关键的转变不再关注 AI 助手宣传的功能列表而是开始记录它在真实任务里的表现。我建立了四个指标来解决这个问题。第一个指标是采纳率也就是 AI 生成后被直接采纳、只有少量修改的代码比例。采纳率低于 40% 时说明这个工具对当前项目帮助有限。第二个指标是返工成本包括评审、修改、排查 AI 代码引入问题的总时间。第三个指标是多轮迭代成功率就是连续经过三轮对话后代码质量还能保持稳定。第四个指标是关键错误率也就是那些必须靠人肉才能发现的严重问题的出现频率。这四个指标不是一次性打完分就结束而是按周滚动统计。我使用了一个非常简单的表格来记录。指标统计方式我的警戒线采纳率直接采纳的生成代码数 / 生成总代码数低于 40% 需要重新定位用途返工成本评审与修改 AI 代码的周均耗时超过自己编写耗时的 60% 就不划算多轮迭代成功率连续三轮对话后代码仍可用的次数低于 50% 说明上下文管理有问题关键错误率需要人工介入才能发现的严重问题数每周超过 3 个必须停用5.2 我自己用的对照表和打分方式给 AI 助手打分时我不会只看整体表现而是按任务类型分开打分。同样一个工具在样板代码任务上可能是 9 分在遗留系统重构任务上可能只有 4 分。这两个分数合在一起算平均没有意义真正有意义的是你在什么任务上常用它它就在你最重要的任务类型上表现如何。我最后把“值不值得继续用”的判断简化成一句大白话如果我在关键路径上需要它的次数越来越少但每次需要它时它都能稳定输出那它就值得保留。如果我在关键路径上依赖它的次数很多但每次都要花大量时间给它的输出收尾那它就变成了负资产。这 34 周里有一个很典型的例子第 24 周时我一度想让 AI 起草日常周报省得出总结。但它生成的周报读起来永远像项目进展汇报缺少我想突出的风险提示和下一步动作。后来我改成只让它整理数据不碰结论。任务类型对了它的表现就好了很多。6. 告别不是删除是重新划分边界6.1 目前保留给机器人队友的岗位虽然标题写了“再见了我的机器人队友”但实际落地不是全部停用而是重新划定了一份岗位说明书。我保留了它最擅长且性价比最高的那部分职责把不适合的职责全部撤下来。目前保留的三个岗位新生代码的草案生成者尤其是接口、脚本、工具类函数测试用例的骨架编写者但由人补充业务边界文档整理和数据格式转换的执行者。这三个岗位有个共同特点产出可以被快速验证错误影响范围小。我不再让它独立负责核心业务模块、历史系统重构和需求分析因为这些岗位需要的是对团队历史、业务上下文和隐性格局的理解。6.2 团队协作里的交接记录和知识沉淀34 周的合作留给我最有价值的不是代码是一套和机器协作的流程记录。我把这套流程整理成了团队内部使用的交接文档内容包括哪些任务类型适合 AI、哪些不适合、评审顺序是什么、遇到输出异常时先查什么。这个交接过程很值得做。因为团队里每个人都可能使用 AI 工具每个人的使用方式差异很大。有人把 AI 当搜索引擎有人当代码生成器有人当讨论伙伴。如果没有一套统一的使用边界团队代码质量会被不同水平的 AI 使用方式拉偏。我在交接文档里写了这样一句话AI 是团队的实习生成语每个人都要评审它的代码而不是直接接受它的代码。这句话后来成了我们在协作规范里的核心原则。6.3 下一阶段的调整方向告别这个阶段的 AI 队友之后我下一阶段的调整方向主要有三个。第一个方向是减少“生成式”使用增加“评审式”使用。也就是说更少让 AI 从零生成大段代码更多用 AI 检查我写好的代码里有没有遗漏的边界条件。把它的定位从“替我写”调整为“帮我复查”。第二个方向是建立更细的任务拆分习惯。以前我会把一个大功能整体丢给 AI现在我会先把大功能拆成可以独立验证的小任务再逐个小任务选择是否使用 AI。拆分之后AI 的错误率明显下降。第三个方向是持续维护约束文件。随着业务演进项目里的约束会不断变化约束文件必须和代码一起更新否则 AI 参考的规则会逐渐失真。说到底跟 AI 队友合作 34 周我学会的不是怎么把需求描述得更像咒语而是怎么给协作划边界。哪些事情可以让机器做哪些事情必须自己扛这个判断比任何工具都重要。这篇周报是告别也是重新定位。希望读到这里的你不用踩完 34 周的坑就能早一点想清楚自己跟 AI 之间的协作边界。