绝代小李1. 先对齐一个前提：50%这个数字不是随便喊出来的
先说结论：50%不是我为了写文章凑出来的数字，是在过去大半年里，五个不同类型项目里实际记录的工作时长对比结果。我习惯在项目开始时建一个简单的耗时表，记录编码、调试、写测试、查文档这几类工作花掉的时间，改完一个功能就记一笔。文章标题里的50%，是这段记录汇总后的平均数，不是峰值，也不是某个特别顺的项目的极端值。
这个数字有个重要前提：基线是我的正常编码速度，不是新手速度，也不是故意放慢的对照组速度。 我用了接近十年的传统编码方式，写过从嵌入式到Web后端的各种破烂和还算能看的代码，对自己的产出速度有比较稳定的认知。在引入AI编码助手之前，我先花了三周记录了几个常规需求的完成时长，之后才切换到AI辅助的工作流，保证对比不是凭感觉。这也是为什么我一直劝身边人：想评估AI编码工具到底对你有没有用，先别急着看别人的案例，自己先记两周基线数据，否则很容易被幸存者偏差带跑。
还要说清楚一个边界：50%省的是编码阶段的时间，不是项目全周期的50%。需求沟通、方案设计、联调、业务验收这些环节，AI帮不了多少忙，该花的时间一分也少不了。我见过的很多失望案例，都是期待AI把整个项目周期缩短一半，结果发现只缩短了写代码那段，就说“AI不行”。这属于预期管理问题，不是工具问题。
后面五个案例，每个都包含四部分：项目大概是个什么活，我原本怎么写，用了AI之后怎么写的，以及最终省了多少时间。案例覆盖的范围我也刻意做了区分，有前端页面、有后端接口、有老项目加功能、有测试补齐、有临时脚本排查问题，尽可能让不同技术栈和不同工作习惯的人都能找到对应的参照。先声明一下，为了叙述方便，文里的项目名字都是化名，代码也做了简化，关键逻辑和非敏感的交互方式保留，方便你复现思路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 案例一：管理后台的CRUD页面，从两天压到五小时
2.1 这是个什么项目
某供应链系统的内部管理后台，技术栈是Vue 3加Element Plus，后端是Spring Boot。需求是给“供应商档案”模块加一组标准的增删改查页面，包含列表查询、分页、排序、状态筛选、新增表单、编辑回显、删除确认、批量启用禁用，外加一个导入Excel的功能。听起来很常规，但这种页面有一堆琐碎细节：表单校验规则、日期格式化、状态标签颜色、表格列宽、弹窗层级、查询参数序列化，每个都得手工处理。
2.2 没有AI辅助的时候，我一般怎么干
老读者应该都有经验：CRUD页面的时间大头不在“会写”，而在“写对”。Vue组件结构不复杂，但十几个表单项的校验规则、与后端字段名的对齐、分页组件和状态枚举的映射，动辄就是几百行模板代码。我通常的流程是先搭一个历史项目里的相似页面当模板，复制过来改字段，改完再对着后端接口文档挨个核对参数名。这个过程最磨人，因为复制过来的模板总有残留字段，搜索替换又容易漏掉驼峰命名的大小写差异。两天时间是常态，其中真正“写代码”可能只占四五个小时，其余时间都在翻接口文档和对字段名。
2.3 引入AI后的实际做法
这次我改变了一下策略。先把后端同事给的接口文档整理成一份简短的字段清单，然后给AI编码助手一段这样的描述：
text复制生成一个Vue 3 + Element Plus的供应商档案管理页面。
字段清单：
- 供应商编码（文本，必填，唯一性校验）
- 供应商名称（文本，必填，长度2-50）
- 所属分类（下拉，数据来自 /api/category/list）
- 合作状态（下拉，枚举：合作中、已暂停、已终止，值为字符串）
- 联系人（文本）
- 联系电话（文本，长度11，数字校验）
- 合作开始日期（日期，格式 YYYY-MM-DD）
- 备注（多行文本，最长200字）
列表需要支持分页、状态筛选、批量启用禁用，删除有二次确认。
生成完成后，我再补上导入Excel的弹窗部分。
AI生成的第一版页面就包含了完整的表格、表单弹窗、校验规则和分页逻辑，和手写的结构基本一致。我花时间最多的地方是核对生成代码里用到的字典项名称，因为后端的枚举值和字段清单里写的略有差异，改了大约五处。导入Excel的部分AI生成不了完整方案，因为它不知道后端接收的格式是JSON还是二进制流，这部分我保留了之前写过的工具函数，组合了进去。
2.4 时间对比和实测感受
| 阶段 | 未用AI时 | 用AI后 |
|---|---|---|
| 列表页面框架搭建 | 约3小时 | 约40分钟 |
| 表单、校验、回显 | 约5小时 | 约1.5小时 |
| 与后端接口联调对字段 | 约6小时 | 约2小时 |
| Excel导入及其他杂项 | 约4小时 | 约1小时 |
| 总计 | 约18小时 | 约5小时 |
这个案例的“省时”来源很明显：AI把模板代码的产生和基础校验规则的书写变成了生成任务，我只需要做差异调节。但我必须说清楚，这类任务AI表现好，是因为CRUD页面结构化程度极高、行业里有海量训练样本，它不是真的“理解”业务，而是把最常见写法预测了出来。越常见的活，它越强，这一点在后面几个案例里还会反复看到。
提示：这类页面别让AI一口气生成整个业务模块的十几个文件，我试过，生成速度可以很快，但文件间的引用关系和状态管理往往对不上，返工时间反而比手写更久。最好的粒度是“一个页面一次生成”或“一个组件一次生成”，生成一个检查一个。
3. 案例二：给遗留老项目加功能，AI最快体现价值的地方
3.1 老项目的棘手之处
第二个案例是一个运行了五年多的Java单体项目，没有单元测试，代码注释少得可怜，核心业务逻辑揉在一个几千行的Service类里。需求是在原有的订单流程中加一个新状态：当订单被风控拦截时，不允许走原定的自动审核逻辑，而是转入一个人工复核队列。听起来改动不大，难点在于得先搞清楚“自动审核逻辑”是从哪一行开始、哪些条件组合会触发、改了之后会不会影响其他状态分支。
这种任务的痛苦不在写代码，而在读代码。我接手时对着那几千行的Service类看了整个下午，才大致画出主流程的调用链。中间还踩过坑：搜一个方法名时搜出了八处相似的调用，其中三处是废弃代码，两处是不同业务的同名方法，最后剩下的才是真正要改的位置。
3.2 AI辅助阅读和定位的过程
这次我的做法是先把关键文件的代码复制给AI助手，让它做两件事：
- 描述这个Service类里订单主流程的处理顺序，梳理状态流转的路径。
- 标出“自动审核”逻辑的所有入口方法和被调用位置。
AI返回的结果是一张清晰的流程描述，比我自己读图省了将近半天。更重要的是，它替我把几个容易被忽略的分支找了出来，比如某个catch块里也有状态更新、某个子方法是上一个需求留下的死代码。我顺着它给的线索挨个核实，加上新状态时就知道该在哪个判断节点插入分支，而不是拍脑袋在大概的位置写下if。
新增代码本身并不复杂，大致是这样：
java复制if (OrderStatus.FROZEN.equals(order.getStatus())) {
order.setStatus(OrderStatus.MANUAL_REVIEW);
orderReviewService.createReviewTask(order);
return;
}
但这一段代码写在哪个方法里、放在哪个判断之前，才是这个需求的真正工作量。AI在这里扮演的角色不是生成器，而是快速阅读理解器，帮我把熟悉陌生代码的时间明显压缩了。
3.3 为什么说这是AI最被低估的场景
很多人提到AI编码想到的是新项目、新页面，实际我用下来，存量系统的维护和改造才是收益最稳定、风险又最低的场景。原因很简单：旧代码不是AI写的，AI不会对它有先入为主的偏爱，拿来做信息提取和逻辑梳理反而客观。而且旧项目通常没有测试，人工读代码又慢又容易遗漏，AI先过一遍能抓出很多藏在角落里的调用路径。
不过这里有个很关键的教训：AI梳理的逻辑，必须自己回到源码里验证一遍。我在这个项目里就遇到过它把两个同名变量当成同一个的情况，虽然那次影响不大，但足以提醒我不能盲信。AI阅读代码的能力是模式识别，不是真正的理解，它擅长总结，但总结错的时候你识别不出来，就会带偏思路。
3.4 时间数据
这次需求从开始读代码到提交，总计约7小时，其中AI辅助梳理和验证花了3小时左右。按照我过去在类似老项目里加状态的经验，这个活正常要一天半到两天，考虑到底层逻辑复杂，省下的时间接近60%。而且质量上有额外收益：它帮我发现的死代码和异常分支，后来在Code Review时被同事专门提了一句“这个分支处理得比之前完整”。
4. 案例三：单元测试批量补齐，AI省下的是重复劳动
4.1 补测试的苦活累活
第三个案例是一个数据转换服务，负责把第三方渠道传过来的订单数据转换成内部标准格式。服务本身逻辑不复杂，但字段映射规则多样，有几十种渠道类型，每种渠道的容错处理还不一样。这个服务的代码覆盖率之前只有百分之十几，技术债背了很久。业务方当时提了个要求：核心转换逻辑的覆盖率要提高到80%以上，为后续重构铺路。
补测试这事，懂的人都懂，不难，但是烦。几十个渠道类型的测试用例写下来，大量是复制粘贴改参数，而且边界值、空值、异常输入这些要自己想全，很容易漏。人工按照老办法写，一天能写完两个渠道类型就算效率高的。
4.2 AI生成测试的具体效果
这次我的做法分三步。先挑一个最简单的渠道类型，把我手工写过的测试作为范例给AI看，让它理解我的断言风格和命名习惯。然后让它按照同样的风格，批量生成其余渠道类型的测试代码。最后我再集中审查生成结果，重点看边界值和异常场景有没有被覆盖到。
举例来说，原始代码里有一个方法：
python复制def normalize_amount(value, channel_type):
if value is None:
return 0.0
if channel_type == "TYPE_A":
return round(float(value), 2)
return round(float(value), 4)
AI生成的测试里，除了正常值，还自动带上了 None、空字符串、非数字字符串、超大数值、负数和带多位小数的浮点数，这些恰好是我手工写测试时最容易漏掉的情形。它甚至会模拟渠道类型传错、未知渠道类型的情况，断言结果是否符合函数里兜底逻辑。这比我预想的要全。
4.3 实际的时间收益
这个模块最终补了200多个测试用例，我花费的时间大约是三个工作日。如果按之前的速度手工写，这类重复度极高的测试补充工作，我觉得至少得七个工作日。省下的时间主要来自两个方面：一是初始代码的编写被完全跳过，二是AI生成的测试用例覆盖面广，减少了来回补用例的循环。
要注意的是，生成测试不能无脑全收。我踩过一个明显的坑：AI会按照函数当前的实现去倒推断言，这会导致测试变成“验证现状”而不是“验证正确性”。比如某个函数里有一个明显不合理的默认值，AI会把它当成正确行为写进断言，这样测试跑得通，却保护不了未来的重构。所以每次生成完，我都会花时间做一页纸的审查清单：理想行为是什么、当前实现是什么、有没有差异。有差异的断言一律手工改，不然测试就是在给bug盖公章。
4.4 一个值得用的小技巧
如果你也想让AI生成高质量测试，给它一个“坏测试”作为反例会很有帮助。我会在对话里贴一段历史上有问题的测试代码，同时说明问题在哪里（比如断言只验证了返回值存在、没有校验具体数值）。AI会理解你的质量标准，生成结果会明显更严格。这个技巧我目前每次都用，效果稳定。
5. 案例四：临时数据处理脚本，从两小时到二十分钟
5.1 数据脚本的特殊之处
第四个案例不是业务项目，是一个数据排查任务。当时线上有一批历史订单的金额字段出现了异常，几十万条数据分布在多个数据表里，需要写脚本把疑似异常的数据捞出来，按规则做初步分类，最后导出一份报表给运营同事核对。
这个活的特点很鲜明：一次性任务，不需要长期维护，但需要快速准确。 正常我的思路是先写一段SQL做粗筛，然后用Python脚本处理Excel和JSON的转换，再对关键字段做统计。问题在于这个流程里有大量零碎的代码：连接数据库、处理空值、格式化时间、输出Excel、处理编码问题，每一个单独都不难，连起来却非常消耗时间，而且容易在小细节上卡住。
5.2 AI在这里扮演的角色
我用AI编码助手的方式很直接：把数据表的结构描述、需要的输出格式、判定异常的规则，用一段自然语言描述清楚，让它直接生成Python脚本。
text复制连接SQLite数据库中的orders表，字段有 order_id, channel, amount, status, created_at。
需要：
1. 找出amount为NULL或金额小于0的记录
2. 找出status为'completed'但是amount大于100万元的可疑记录
3. 按渠道分组统计可疑记录数量，输出CSV到 output_report.csv
4. 时间字段转换为ISO格式，编码用UTF-8
请生成完整可运行的脚本。
生成的脚本几乎能直接跑，只在数据库连接的读取路径上做了一处小修改。原本我要花大半时间处理的日期格式转换，它用了统一的工具函数处理好了。整个任务从开始到导出报表，大约花了20分钟，这还是在包含检查异常数据结果的情况下。
5.3 这类任务用AI的收益逻辑
数据脚本类任务省时间的根源在于：它高度依赖“对常用库的熟练调用”，而AI对pandas、os、csv这些标准库和常用库的用法熟悉度，超过大多数人的记忆。人写起来最费劲的“我记得有这个函数但参数是什么来着”，对AI来说反而是最擅长的部分。更重要的是，一次性脚本不需要考虑长期的架构约束，AI生成的临时代码风格是否统一根本不重要，能跑、能出正确结果就够了。
5.4 盘点时间账
这个任务的最终耗时：
| 步骤 | 未用AI时 | 用AI后 |
|---|---|---|
| SQL粗筛逻辑设计 | 约20分钟 | 约5分钟 |
| Python数据处理脚本编写 | 约80分钟 | 约12分钟 |
| 调试运行中的小问题 | 约30分钟 | 约5分钟 |
| 总计 | 约130分钟 | 约22分钟 |
需要说明的是，这次省时间有个重要前提：我完全清楚自己的判定规则是什么，AI只是帮我把它翻译成代码。如果连业务规则都没想清楚，指望AI替你想，那只能得到一份看起来合理但没法用的脚本。AI压缩的是翻译时间，不是决策时间。
注意：数据脚本涉及真实数据和敏感字段时，务必在脱敏环境里操作，不要直接把线上数据传给AI工具。我一般会在本地的模拟数据集上验证逻辑，确认无误后再对接真实数据源。这个习惯建议养成。
6. 案例五：半夜排查线上日志，AI当debug副驾驶
6.1 事故背景和我的初始困境
第五个案例是一次线上问题排查。某个内部服务在凌晨出现大量超时报警，日志里堆满了同一个错误码，但当时值班的人（也就是我）凌晨三点爬起来，脑子还没完全清醒，对着几万行日志一时不知道从哪里下手。按老办法我会先grep出错误码附近的上下文日志，再一台一台机器看时间线，然后猜某个下游服务是不是出了状况。这个过程在没有AI辅助时，通常要一小时以上，遇到日志里时间戳格式不统一，还得先写脚本归一化，非常崩溃。
6.2 AI辅助排查的实际操作
这次我把一小段有代表性的日志直接贴给了AI助手，附带一句描述：“以下是某服务的错误日志，请帮我列出可能的排查方向，并标注关键时间点和调用链信息。”AI很快返回了几个要点：某一类错误在所有日志中占比最高、错误发生前有一个数据库连接池的告警、时间戳显示问题集中在某个特定时段的批次任务上。
顺着这些线索，我很快就锁定了一个可疑点：当天凌晨有个定时任务在处理一个新增的渠道类型时，未正确初始化下游连接信息，导致批量失败并引发连锁超时。放到以前，这个方向恐怕得等我自己把日志看两遍才能想到。AI在这里做的不是分析，而是把高频特征先从噪音里捞出来，降低了我做初步筛分的注意力开销。
6.3 冷静评估：AI排查的边界
我必须诚实地说，AI没有替我找到根因，它只是缩短了我找到根因前的时间。真正确定问题、写修复代码、灰度验证，这些还是我自己完成的。但它确实把“爬日志”和“找特征”这两步明显加快了，对于凌晨三点还要保持头脑清醒的运维场景来说，这个帮助最直接。
不管AI给了多少条线索，日志里的原始信息才具有最高可信度。那次AI提示“数据库连接池告警”是重要特征，我顺着排查后确认它确实关联，但AI没注意到日志尾部还有一条例外信息提示的是“任务队列已满”，实际根因反而和队列消费积压的关系更大。这再次印证了一件事：AI是可以被测试的假设生成器，不是结论机。 它给的可能方向越多，越需要靠人的工程判断去收敛。
6.4 时间上的客观对比
这个场景我没有精准计时，但根据经验，凌晨排查类似问题通常需要一到两个小时才能定位到可疑服务。这次从贴日志到基本锁定方向，花了大约15分钟，后面写修复代码和验证发布又多花了四十分钟。综合算下来，整个事件的处置时间大约节省了40%到50%，这个案例虽然不像代码生成那样有精确的数据，但面对按分钟计费的故障时间，这个省幅已经很可观了。
7. 五个案例背后的工作流设计，才是省时间的真正原因
7.1 省时间的本质不是“AI写得快”，而是“拆任务方式变了”
如果把五个案例放在一起看，你会发现一个共性：我并不是把整个需求扔给AI让它全自动实现，而是把每个任务拆成了更小、更清晰、更适合人机协作的单元。CRUD页面拆成“生成框架”和“人工对接接口文档”两步；老项目加功能拆成“AI梳理代码”和“人工确认逻辑分支”两步；测试补齐拆成“AI批量生成”和“人工审查断言”两步。
这个意识转变是我用AI编码大半年之后最大的收获。很多人在AI编码工具上觉得不好用，往往是因为任务模式还停留在“整体交给AI”，希望一个描述生成一个完整可运行的功能模块。AI一旦做得不完美，就得出“垃圾”的结论。但真实的工作流应该更接近驾驶辅助：车的底盘、转向、刹车是人在控制，AI只是在特定路段接手了一部分操作。
7.2 任务拆解的实用颗粒度
我给自己定的一个经验基线是：输入给AI的任务，应该是你本来能凭直觉拆分的、20分钟到2小时内能手工完成的小单元。 比这个更大的任务，AI生成结果的不可控因素会快速上升；比这个更小的任务（比如改个变量名），自己动手反而更快。
以这个基线为准，我会在开工前多花几分钟，把一个需求切成清单，例如：
- 框架代码、重复模板：交给AI生成。
- 业务流程梳理、旧代码阅读：交给AI做初稿，但必须人工验证。
- 接口参数、业务规则确认：必须人工去核对文档或同事沟通。
- 边界条件、异常分支设计：AI可以提建议，但最终我要自己拍板。
7.3 上下文管理的三个小技巧
任务拆好了，还得保证AI真正理解上下文。我总结了三个稳定的技巧：
- 给AI一个“明确角色和输出物”的指令：不要说“帮我看看这段代码”，要说“你是这个模块的维护者，请输出这段代码中所有对外部API的调用清单，按调用的先后顺序排列”。输出物定义越清楚，返工越少。
- 一个对话窗口只做一类事：如果我把“生成页面”和“梳理旧代码逻辑”混在同一个对话里，多次之后模型会因为上下文混乱而产生前后矛盾的回答。现在我严格按“一对话一任务类型”来管理，代码审查和代码生成永远分开。
- 必要时候直接把核心文件喂给它：有些AI工具支持把整个文件关联进上下文，我建议把关联范围控制在当前改动相关的文件，不要关联整个项目。文件太多之后，AI的注意力会被稀释，反而容易忽略关键信息。
7.4 每天固定时段用AI，形成稳定预期
这是另一个影响省时效果的隐性因素。我前几个月用AI是“想起才用”，有时忙起来干脆继续手写，效率提升很不稳定。后来我强迫自己每天第一个任务先尝试用AI辅助完成一小块工作，无论是一段脚本、一段测试，还是让AI读一段代码，先把协作流程跑起来。这样做的好处是：失败的成本低、成功时可以积累自信用起来更有底。稳定使用下来，我发现省时效果不是线性的，而是越用越明显，因为你逐渐摸清了它的边界和你的边界。
8. AI编码的边界：哪些活千万别交给它
8.1 越“标准”的活越省时间，越“独特”的活越省不了
从前面的案例能看出一条清晰的线索：凡是结构化程度高、行业共性强的任务，AI的“省时率”就高，比如CRUD页面、测试代码、临时脚本、日志初筛；反之，越是和特定业务强绑定、需要大量领域决策的任务，AI能帮的就极其有限，比如复杂业务状态机的设计、多系统间一致性的取舍、核心算法方案的验证。这个边界我越用越清楚，它直接决定了你在哪类任务上该投入多少时间调教AI。
8.2 我在几个方向上不再指望AI
安全敏感的代码改不动。 涉及权限校验、加密逻辑、支付对账、审计追踪这类代码，我会全手工写完再找同事做双重Review。AI生成的这部分代码也不敢直接合入，因为安全逻辑的错误往往不是语法层面的，而是设计层面的，AI没法判断你的威胁模型是什么。
没有明确验收标准的活交给AI，容易得到“看起来对但实际没用”的结果。 这是最多人踩的坑。你问AI“帮我优化一下这段代码”，它永远能给你一份优化后的代码，问题是优化标准是什么、性能瓶颈是不是真的在那里、优化后是否改变了行为边界？如果连自己都说不清楚验收标准，AI给你的就是一坨漂亮的表面工夫。
“让AI解释一段你完全不理解的领域代码”很危险。 它能把代码解释得头头是道，但如果你连业务背景都不懂，就完全无法判断它解释得对不对。这种情况下，我宁可先去把业务文档看明白，再回来用AI辅助。
8.3 人机协作中，人需要保住的三块阵地
用AI越久，我越觉得这个问题不是“AI能不能替代程序员”，而是“程序员该守住什么”。我的体会是，有三件事绝对不能交给AI，一旦让渡出去，你的工程判断力会退步：需求落地的决策判断、质量标准的定义、对代码行为的最终解释权。这三件事都要求你对系统的真实运行状态有第一手的感知，AI只是缩短你获得感知的时间，永远替代不了你形成理解的那一步。
8.4 最后分享一个我的个人习惯
每次用AI生成代码之后，我都会先自己通读一遍，把不懂的地方标出来，实在想不通就亲自跑一遍或加一组日志验证，然后才合入。这个习惯让我的代码Review通过率一直比较稳定，也让我在AI生成内容面前保持了一个朴素的判断标准：你合入的代码，自己必须能解释清楚每一行是干什么的，解释不清的，要么改到懂，要么不提交。 这样做，AI省下的时间才不会变成以后加倍偿还的技术债，50%的效率提升才是有意义的提升。