不绕弯子先说结论把AI当同事用效率确实有提升但提升的方式和大部分人想象的不太一样。它不是在“帮你写代码”这个层面省时间而是在“减少你从想法到草稿之间的距离”这个层面省时间。这个小半年里我陆续参与了四个不同类型的项目每个项目都刻意让AI深度介入从日常编码、脏活处理、技术方案设计到自动化流程搭建都有比较完整的记录。这篇复盘不聊那些“AI即将取代程序员”的宏大叙事就聊我在真实项目里怎么用、翻过哪些车、以及最后对“效率”这件事到底怎么看。1. 项目一把一个中等规模功能从零写出来AI初稿到底靠不靠谱1.1 项目背景和我的用法第一个项目是给公司内部系统做一个带权限管理的报表模块。这个模块不算难但涉及的地方多前端表格展示、后端查询接口、权限过滤、导出功能林林总总加起来改动涉及二十多个文件。以前这种活我一般花两到三个工作日这次我决定换一个打法——全程让AI先出初稿我来改。我用的方式是把这个需求拆成若干个小任务每个任务写一条足够具体的提示词让AI直接产出代码。比如“在现有FastAPI项目中新增一个报表查询接口支持date_from和date_to两个参数返回格式为JSON包含total和list两个字段list里每条数据有id, name, amount, created_at”。当时用的工具是装在我日常IDE里的一个AI插件类似Fitten Code那种定位的边写边补全和对话式生成都有。这个模式的真实体验是AI在“生成第一版代码”这个环节确实快快到什么程度我用自然语言描述一个接口需求基本三十秒内就能得到一份能跑的代码。但这里有个隐藏前提——你的需求描述必须足够精确。如果你只写“做一个报表导出功能”那你收获的也是泛泛的代码接口参数对不对、字段命名是否符合项目风格、异常处理有没有覆盖统统都要你来收拾。1.2 实际复盘中真正的提效点在哪复盘这个项目我的效率账本其实很有意思。纯粹写代码的时间AI大概帮我省了40%左右。但这个数字没有意义因为剩下60%的时间里我的工作从“写代码”变成了“判断代码”。举个例子。我让它生成一个权限过滤逻辑初稿里一个装饰器的顺序写错了导致权限校验永远在登录校验之前执行未登录用户直接打到401。这个bug我花了几分钟定位但如果是自己手写大概率不会犯这种低级错误。换句话说AI生成越多的代码你就需要投入越多的精力去审查。那这个项目到底省没省时间省了但省的环节很具体省掉的是从“空白文件”到“有代码可看”的心理启动成本。以前写一个大模块最难受的是开头哪怕心里知道要写什么盯着空白的编辑器就是不想动手。现在这个环节消失了你只需要先写提示词AI先把架子搭起来你后续的工作更接近于“带着要求去修改一份陌生团队写的代码”。这种模式下有个必须掌握的技巧提示词里必须交代清楚项目的现有约定。比如这个项目用的是哪个ORM、错误响应格式是什么、路由前缀是什么。你给的上下文越接近项目真实情况AI给出的代码就越少需要返工。我后来习惯在项目根目录放一个CONVENTIONS.md把数据库访问方式、接口返回模板、命名风格都写进去每次给AI描述需求时直接把文件内容贴进去。效果立竿见影返工率明显下降。2. 项目二脏活累活全扔给AISQL和CRUD才是提效最明显的地方2.1 为什么说这类场景收益最高第二个项目跟第一个截然不同没什么设计难度就是一个接一个的数据统计需求。比如“统计近30天每个渠道的注册转化漏斗”“把上周订单表里异常状态的数据捞出来”“给运营导出一份带同比环比结果的日报”。这类活的特点非常鲜明需求明确、流程重复、结果可验证。以前我每次拿到这种需求都要花半小时到一小时写SQL、调格式、对数据而且说实话写这种东西特别容易走神——不是不会写而是无聊一无聊就会犯低级错误比如时间边界算错、join条件漏掉一个。这次我把所有这种活都直接扔给AI提示词模式大概是这样的“有一张orders表字段有id, user_id, channel, amount, status, created_at还有一张users表字段有id, register_channel, register_time。请统计上个月每个渠道的下单用户数、订单总数、成交总额结果按成交总额降序用SQL写注意只统计status‘paid’的订单。”这个提示词看起来简单但里面包含了一个很重要的原则不要只描述目标要把字段名和表结构给全。AI在处理这类问题时最大的优势不是它能想出你没想到的解决方案而是它不会烦躁。你让它改8个版本的SQL每次加一个过滤条件它不会有情绪。这个特性在传统工作方式里是不存在的——你自己改第5版的时候已经开始烦躁了。2.2 提效数据的真实构成这个项目我做了一个粗略统计累计写了三十多条SQLAI生成和修改的时间加起来大概占了我过去手工操作时间的七分之一到八分之一。原来一小时的活现在大约五到十分钟搞定剩下的时间主要是检查和调整边界条件。关键点在于AI生成的SQL在“常见查询”上准确率相当高但在“隐含业务语义”的查询上会翻车。比如有一次查询涉及“退款后是否影响渠道转化数据”这个逻辑在我们业务里是有一个特殊处理的——退款订单要从转化分母里剔除。但单纯看表结构AI完全感知不到这个业务规则它的初稿把退款订单照常算进去了。如果我不了解业务直接拿去用数据就是错的。所以我的结论是AI在处理“语法正确”层面很强但在“业务正确”层面必须由人来把关。这里我养成了一个习惯每次AI生成SQL之后我会快速口算或用小数据集验证几个关键数字比如总单数是否和历史报表对得上、金额量级是否合理。数据会告诉你好多事情如果某个数看着敏感或是偏了多半是业务语义丢了。这类项目做多了以后我对“把AI当同事”这个定位有了新的理解——它不是帮你做决策的而是处理那些已经明确了“应该怎么做”的工作。SQL查询就是一个典型的“明确输入输出”的任务输入是表结构和统计口径输出是一条SQL。AI只是更快地完成了翻译过程。2.3 顺手解锁的另一个能力脚本化数据清洗这个项目进行到后期我开始不满足于让AI写SQL而是让它把整个数据输出到Excel的流程做成了一个小脚本。这个脚本可以接收日期参数自动跑查询、导出结果、按模板格式化。使用下来最大的改变不是省了那几分钟而是把“等待自己写代码的焦虑感”变成了“让工具去跑”。这里想特别聊一下很多人觉得让AI生成脚本不靠谱因为每个项目的环境不一样。但实际上你只要把报错信息原样贴回去给它它能很快修正。我用下来觉得模型处理和“修复错误”的能力其实比“第一次生成正确”的能力更可靠。所以别怕错错了就把错误往对话框里一贴让它自己解释、自己改这比你自己对着报错看半天要快得多。3. 项目三架构设计这种动脑子的事AI翻车的记录和我的补救办法3.1 一次真实的设计方案“翻车”第三个项目比较特殊是为现有系统重构一个订单状态机。这个系统比较复杂订单状态有十几个还牵扯到超时自动取消、退款回滚、异常状态补偿这些逻辑。考虑到AI在“写代码”方面的表现我动了念头——让它来出个方案。我把现有系统的状态流转图和核心代码贴给了AI要求它分析一下当前设计的问题并给出重构建议。结果它给出的方案怎么说呢从原理层面看很漂亮用了标准的有限状态机模型还引入了事件驱动架构。但如果真的照着落地需要改动现有系统的基础设施重构成本非常高周期至少两三个月。这是一个典型的“理论正确、实践不可行”的方案。这件事让我意识到一个问题AI在生成“看起来合理的方案”方面非常强甚至强到让人轻信。但它是基于“一般情况”在做推断而不是基于“你的真实约束条件”。它的答案在纸上自洽但没有办法自动感知你现有的技术栈现状、团队规模、排期压力。它的世界里没有“人月神话”这回事。3.2 如何让AI在方案设计上真正帮上忙经历过这次翻车之后我调整了用法。我再也不问它“你有什么建议”这种开放性问题了而是改成“连环追问”模式。我的做法是先让它列出现有方案的潜在问题每个问题都要求它给出具体代码路径作为佐证接着针对每个问题问它“如果修复这个问题可能引入哪些新问题”最后让它把所有问题按影响面排序并针对前三个问题给出低侵入的修复建议。整个过程我会加入自己的业务判断比如“超时取消逻辑在目前的架构里是有单独定时任务在跑的你提出的方案是否需要改动这个定时任务”——这类问题AI经常答不上来因为它看不到项目里的定时任务配置文件。这种方法本质上是把AI从“方案提供者”变成“思路挑战者”。它不是直接给你答案而是通过一系列提问逼迫把现有设计里的隐含假设暴露出来。真正有价值的产出往往是它列出来的问题清单——里面有一些确实是平时容易忽略的边界情况。另外我养成了一个新的习惯让AI写方案的“否决理由”。比如我给它一个方案草稿让它扮演一个非常挑剔的架构评审把方案里所有可能导致延期、引入新bug的点全部列出来。这个过程特别像办公室里的Red Team。AI不需要给出正确答案它只需要帮你想全“哪里有可能是错的”这个价值其实也不小。3.3 关于“AI会一本正经地胡说八道”的新理解网上都在说AI会幻觉会说瞎话。我原来的理解是“它编造事实”但实际用下来我发现它更常见的问题是“在错误的层级上给出正确感很强的建议”。比如你问它“这个模块怎么改更合理”它给你讲一个优雅的分布式架构。这个方案本身没有错但和你的问题不匹配——你只是想改一个内部逻辑它给你的方案却把整个团队拖入重构。我现在的处理方式是对所有AI给出的方案第一反应不是“它对不对”而是“它到底在回答我提出的问题还是在回答它想象中的问题”。如果是后者就需要你重新框定边界条件。这个经验非常有用可能是我小半年里最重要的一条心得。4. 项目四尝试让多个AI角色协作搭建一个半自动化的测试分析流程4.1 从“单点使用”到“AI流水线”的尝试第四个项目的出发点倒不是有明确的业务需求而是我想验证一个理念——如果单个AI能干活那把多个AI串起来是不是能做一个自动化流程。当时正好有一个需求每次版本发布前要做回归测试测试结果要看覆盖率报告和失败用例日志然后整理成一份给团队看的分析周报。整个流程涉及几个工具跑测试、收集报告、分析日志、生成摘要。我当时的设想是把AI拆成几个角色一个负责看覆盖率报告找遗漏一个负责分析失败日志推测原因还有一个负责把前两者的结论整理成周报。听起来很美实际上折腾了非常久。真实遇到的困难有点出人意料。最大的问题不是AI能力不足而是“流程编排”本身。单个AI在上下文里看到日志能写得头头是道但一旦要通过程序去调用AI的API把上一阶段的输出作为下一阶段的输入中间格式的稳定性就成了大问题。AI的输出不是严格的结构化数据它偶尔会在回答里加一句“根据以上分析我认为……”这句话就会让下游解析代码报错。4.2 我对“多AI协作”现状的判断这个项目最后跑通了一个简化版但也仅限于“半自动”——核心判断还是由人来下AI负责的是把信息初步过滤和整理。我的体会是当前阶段把多个AI串成流水线可行但离好用还有距离。如果你想尝试类似的思路我从这个项目里提炼出三个实操建议第一每个AI角色之间不要直接传自然语言加一道“结构化转换层”。比如让AI输出JSON然后用脚本做字段校验再喂给下一个AI。这一步能避免很多莫名其妙的脏数据。第二给每个AI卡一个非常窄的角色边界。不要让它自由发挥写清楚“你只需要分析日志中的ERROR级别条目不要做任何优化建议”。约束越窄输出越稳定。第三预设失败处理路径。AI流水线里任何一个环节都可能给你一个无法解析的输出你一定要在流程里面加好超时和重试不是重试一次两次而是重试三次以上因为不同时间窗口下同一个模型的处理倾向会有差异。4.3 这个项目带给我的反思从价值角度看这个项目算是四个项目里“性价比最低”的一个。投入了大量时间在工程化上最后得到的自动化程度却不高。但我从里面收获的东西可能最多——它逼着我思考了一个问题AI到底适合工作流里的哪个位置我的答案是AI适合做“有价值的中间层”而不适合做“端到端的全自动环节”。所谓有价值的中间层是说它能把大量低信息浓度的内容初步消化过滤出一个更小、更浓缩的集合给人类处理。但最终的判断、决策、兜底还是需要人来完成。这就好比一个刚入职的同事你安排它整理一份几百条日志的分析报告它能干能给你一个像模像样的初稿。但你不会让它直接拿着这个初稿去发全员邮件你一定会自己过一遍再修改、再确认。AI同理——它是一个干活很麻利的初级同事但不是最终签字的人。5. 效率的真相AI帮你省的不是“时间”而是“状态切换的损耗”5.1 一张完整的效率账本四个项目跑下来我对“效率提升”这件事有了一个更立体的认知。如果简单统计时间AI大概帮我省了三分之一到四分之一的纯工作量。但这点时间上的节省不是最重要的真正改变我工作体验的是另一个东西——注意力的连续程度。写代码这件事最消耗的其实不是手指在键盘上的时间而是“进入心流状态”和“从被打断中恢复”的时间。以前一个需求我可以拖到下午才动手因为一想到要从零开始写一个模块就有一种无形的阻力。现在完全没有这种问题我只需要把需求翻译成一段提示词AI在几秒内给我一个草稿。哪怕这个草稿只有六十分也远远好过空白页面因为它帮我跨过了那个最难的第一步。这是一个很微妙但很真实的效率提升AI没有让我的“思考速度”变快但它让我更容易进入“行动状态”。用一句行话来说它降低了行动的启动阈值。5.2 什么情况下AI反而让你更慢什么情况下效率翻倍复盘这四个项目我也能明确画出AI的“正负分界线”。AI让人更慢的情况集中在那些需要大量隐性知识、跨模块影响判断、且约束条件复杂的工作上。比如架构重构、关键路径上的缺陷排查、涉及多团队协作的方案设计。在这些场景里AI给的信息密度偏低你花在“评估AI建议”上的时间比它帮你省下的时间还多。AI让人效率翻倍的情况则集中在“需求清晰、单一职责、可验证结果”的重复性劳动上。CRUD接口、SQL查询、日志分析、单元测试生成、文档格式化、数据转换脚本都是典型代表。这些活没有任何惊喜可言但占了开发者日常工作量不小的比例。我后来给自己定了一个很简单的判断规则如果这个任务可以用“输入-处理-输出”三段来描述处理步骤是明确的结果是对错可分——那就扔给AI。如果这个任务需要先搞清楚“到底要什么”或者结果无法简单验证那就老老实实自己来不要浪费时间去调教AI。5.3 项目之外的一点个人体会我越来越觉得“把AI当同事用”这个比喻之所以成立是因为它的语义很准确。你和同事协作的时候不会期待对方替你思考不会期待对方了解所有背景也不会全盘信任对方交上来的东西。你需要做的是把需求说清楚、提供足够的上下文、验收结果、该打回就打回。这套协作模式放在AI身上完全成立而且比任何“AI自动替代人类”的叙事都更贴近现实。你训练的不是一个工具而是一个协作伙伴你要提升的不是AI的能力而是你自己“把需求讲清楚”的能力。这是一项真实存在、而且越来越稀缺的技能。如果你也想在日常工作里让AI真正发挥作用我的建议是从一个小需求开始最好是那种你已经知道怎么做、但写起来略显乏味的小需求。把完整的背景说明、表结构、代码约定放进去生成一份初稿然后像评审同事代码一样去审它。几次循环下来你自然会建立起感觉——它适合做什么、它会把什么事情做砸、提示词怎么调整能换来更多准确率。这四个项目只是AI协作方式的一部分切片远不是全貌但已经足够说明一个问题效率的真相不是那把锤子变快了而是你挥第一下的决心变小了。这是我小半年时间实打实的体会。