半年多前我在一个小型研发团队里负责需求支撑日常任务被切得很碎上午还在改接口下午就得到另一个项目里帮忙写数据脚本晚上还得盯着发布。那段时间最消耗我的不是写代码本身而是“理解需求”和“把背景同步给另一个人”。于是我做了一个决定把 AI 当成一个必须参与交付的同事来用而不是停留在“偶尔打开网页问一下”的工具阶段。现在半年过去经手的项目里我挑了 4 个比较有代表性的来复盘分别是数据看板开发、遗留系统重构、跨部门数据迁移、自动化测试落地。这篇文章会把实际过程摊开来讲重点聊一个大家好几年都在追问的话题AI 在真实工作里到底提升了多少效率哪些效率是真实的哪些只是错觉。1. 从“调用工具”到“协作共事”我先给 AI 定了几条合作规则1.1 为什么是“同事”而不是“工具”传统开发工具的特点是确定性强你点一个按钮它就执行一个固定动作结果预期一目了然。AI 完全不同它更像一个知识面很广、但缺乏项目背景的新人。同一个问题你给 30 字描述和给 300 字背景它能给出两个质量差很远的结果。我一开始也犯过工具思维的错误把它当成搜索引擎在用需求描述半天不对生成出来的代码写得像教科书示例根本接不进现有系统。后来我换了个思路如果团队来了一个实习生我会怎么跟他配合我会先告诉他项目背景、关键术语、哪些模块碰不得、交付物长什么样。那我为什么不能对 AI 做同样的事把 AI 当成同事本质上是在改变我自己的工作方式。我不再期待它一次性给出完美答案而是把它当成一个需要逐步对齐、反复验收的协作对象。这个心理转变很重要因为它决定了后面所有项目的协作流程。1.2 我实际定下来的三条规则第一先对齐背景再干活。每次正式开始之前我会把项目背景、数据来源、业务口径、技术约束写成一页背景说明作为提示词的开头部分。这就像给新同事的第一天做入职培训背景给得越完整后面返工越少。第二明确交付物和验收标准。说“帮我优化一下这个接口”和“帮我重构这个函数的错误处理逻辑要求保持入参兼容并输出变更说明文档”前者容易得到正确但没用的答案后者才对应岗位上的真实需求。我后来养成了一个习惯每次发起任务都顺手补一句“输出请用表格”“请给出代码和对应的测试用例”之类的话。第三限制自主范围。涉及生产环境、真实数据、核心逻辑修改的环节AI 只能产出草案不能直接执行。哪怕它给出了完整指令我也要经过人工审查后才落地。这条规则看起来保守但正是它让我敢在后面的项目里放手用 AI。1.3 我常用的三种协作角色执行者、分析师、陪练是我平时切换最多的三个角色定位。执行者很好理解写 SQL、写配置、生成样板代码、整理文档。这类任务可验证性高AI 生成完我扫一眼就能判断对不对效率提升最直接。分析师角色用在读代码、归纳日志、梳理调用关系的时候。我试过把一个老模块几千行代码拆开让 AI 逐段解释它在干什么竟然比我对着 IDE 一个个追调用还要快。陪练角色是后来才发现的让 AI 扮演项目评审人对我的方案提反例、挑风险或者让我扮演甲方让 AI 模拟提问刁难我。好几次它一本正经问出来的问题恰恰是我自己漏掉的关键条件。同一个模型切换角色之后产出的质量完全不一样这个玩法非常推荐试一下。2. 项目复盘一某运营数据看板项目——交付速度明显提升但业务口径差点翻车2.1 项目背景与工期压力某运营团队需要一个实时业务看板统计新增用户、活跃用户、订单转化几个核心指标要求展示近 30 天趋势还要能按渠道过滤。给我的时间只有两周而我手头还有其他模块的维护任务没法完整投入两周。这类项目真正花时间的地方通常不在前端样式而在数据侧表结构复杂、口径不统一、多个数据源之间的字段关联容易出错。项目启动时我拿到了一份数据库表结构说明和一份运营指标定义文档文档写得比较粗糙很多口径埋在过往的邮件沟通里。我当时的判断是这个项目很适合用 AI 加速。因为数据指标的计算逻辑虽然多但大部分步骤可以描述成明确的规则而且 SQL 的执行结果可以直接在库里验证AI 有没有做错跑一遍就知道。2.2 AI 在项目里实际承担的工作我让 AI 做了三件事根据表结构生成统计 SQL、生成图表配置对应的 JSON 结构、写接口联调时需要的模拟数据。第一件事最核心也最锻炼人。第一次给 AI 的任务描述是这样的有三张表用户表、订单表、登录记录表要实现一个统计接口按天返回新增用户数、活跃用户数、订单转化率要求支持渠道维度筛选。AI 很快就生成了 SQL语法没毛病逻辑也基本对。我看了一遍就接进联调环境了。结果第二天运营同事跑过来问为什么看板上的新增用户数比后台导出的数字少了一截我查了半天最后发现问题出在“新增用户”的口径上后台导出的统计口径是去掉测试账号之后再去重而我让 AI 生成的 SQL 只是简单统计了注册表当天创建的用户测试账号全被算进去了。2.3 翻车原因拆解不是 AI 笨是我漏了上下文这个问题的根源不在 AI而在我的任务描述。我以为 AI 能理解“新增用户”这个常用词但在不同业务系统里同样的词可能对应不同的口径。这就像你让一个新同事“看一下今天的流量”他可能不知道你指的是 UV、PV还是 App 启动次数。我后来在复盘里把它归结为“口径缺失”背景信息里没有把口径定义、排除规则、时间边界写清楚。AI 是按字面理解任务的它不会知道你们系统里存在一批测试账号也不会知道“新增”要基于去重后的最终状态。这个教训的价值很高后面我再让 AI 生成任何涉及业务指标的代码或 SQL 之前都会先建一个“口径清单”放在提示词里哪个指标怎么定义、哪些数据需要排除、日期按哪个时区算。清单一开始只有几条后来越用越厚变成了团队里重复使用的基础资产。2.4 后续我改用的提示词模板后来我再做类似的数据统计任务会先让 AI 复述口径确认理解一致后才开始写 SQL。这个操作多加了一轮对话看起来变慢了实际上省掉了后面联调时的返工。我也把模板固定了下来项目背景、指标口径、表结构说明、交付物格式、禁忌事项比如不要用 SELECT *、不要忽略空值。每次新项目先在模板里填内容再发给 AI。半年下来这个模板已经成了团队内部资料库的一部分。这个项目最终按时上线了但从“代码能跑”到“口径正确”之间确实是靠人来把关的。AI 帮我省掉的是写代码和查语法的时间而“指标到底该怎么算”这件事永远需要懂业务的人给出最后一锤定音。3. 项目复盘二某遗留系统模块重构——让 AI 当“代码考古学家”3.1 一块没人敢动的老代码团队接了一个遗留系统模块的重构任务。这个模块有六年历史原开发早已离职文档只留下几篇残缺的说明代码里充满让人困惑的命名函数之间耦合严重连测试环境都是手动搭的。团队内部评估过好几轮结论是“能跑就别动”但不动又不行因为新业务需求必须在这个模块上扩展。这类任务最费时间的地方不是写新代码而是搞清楚旧代码到底做了什么。我一度对着一个 2000 行的文件发了半天呆函数之间互相调用中间还夹着历史遗留的临时补丁根本不敢下手。3.2 让 AI 做代码拆解和调用链梳理我决定把 AI 当成一个“代码考古学家”来用。测试环境需要展示1. 明确项目目标和范围之类好吧我还是要遵循文本结构这是正文内容不要当成元说明。所以用控制台小标题但由于不允许 H1直接在正文起主体会更好。那我可以这样 先写开头段落不设标题直接写正文然后进入1. 为什么这个项目值得复盘这样符合“不需要主标题直接从二级标题开始”吗开头无标题段落其实是违背“直接从二级标题开始”的。但另一方面如果我真的从“## 1.”开始第一段就是章节没有引子。标准骨架说“开头≥200字”通常是在H2之前。可是“格式规范”说“不需要主标题直接从二级标题开始不需要博文主标题# 主标题请从二级标题开始”。这个的意思应该是不要一级标题而不是不允许开头段落。现实中许多输出包括开头段落再H2。既然标准骨架包括“开头”而开头没有要求标题。那就保留开头段落。但为了完全安全我可以让开头段落在一开始就出现不设标题这它仍然是正文的一部分合法。许多符合规范的答案都是如此OK。然后后续章节如下1. 从“调用工具”到“协作共事”我先给 AI 定了三条合作规则1.1 为什么是“同事”而不是“工具”1.2 三条合作规则1.3 三种协作角色2. 项目复盘一某运营数据看板项目——交付速度提了但业务口径差点翻车2.1 项目背景与工期压力2.2 AI 在项目里实际承担了什么2.3 翻车原因拆解口径缺失2.4 后续改用的提示词模板3. 项目复盘二某遗留系统模块重构——AI 当“代码考古学家”3.1 一块没人敢动的老代码3.2 AI 做代码拆解和调用链梳理3.3 让 AI 产出重构行为守护测试3.4 这次效率为什么提升最明显4. 项目复盘三跨部门数据迁移——AI 能做的事很多但映射必须人审4.1 迁移项目的典型痛点4.2 AI 承担的三类工作4.3 一次真实告警状态字段映射遗漏4.4 关键环节人工审批的边界5. 项目复盘四自动化测试与发布检查清单——AI 把脏活累活变成了资产5.1 发布前手工检查有多痛5.2 让 AI 生成测试用例和校验脚本5.3 手工与 AI 辅助的效果对比5.4 哪些检查不能直接交给 AI6. 效率的真相半年后我总结出的判断标准6.1 真正省时的三类任务6.2 假省时看起来很快实际要返工6.3 用 AI 效率最高的人具备什么特征6.4 给团队的落地建议7. 常见问题与避坑心得速查表7.1 AI 一本正经胡说八道怎么办7.2 上下文窗口不够长怎么办7.3 怎么防止 AI 生成的代码带安全风险7.4 团队使用 AI 的三个底线结尾段落可选 “复盘完这 4 个项目后我个人最大的体会是AI 能提升多少效率很大程度上取决于你愿不愿意把它当成一个需要被管理的同事。你越能清晰描述任务越能严格验收结果它的产出就越稳定反过来如果你只是把它当成一个一键出结果的工具那么翻车概率也不会低。最后再分享一个小技巧让 AI 干活之前多花 30 秒把‘背景’和‘不要做什么’写进提示词里这 30 秒往往能省掉后面 30 分钟的对账时间。效率的真相就是这样真正的杠杆不是 AI 本身而是那个能把需求讲清楚、把标准定下来的人。”这个结尾没有套话是以真实经验收尾OK。我需要检查是否包含“为…提供支持/保障”等。不包含。避免“总之”“综上所述”。不包含。代码块示例提示词放一个 text 代码块即可。另外在遗留系统部分也可放一个 text 示例。现在我要全文撰写。注意段落要每段至少150字不过这个要求“所有大段文本需拆分为小段每段建议4~6行且每段字数不得少于150字”我需要确保绝大多数段落达到150字以上。有时候一个简短列表前导句不足150字可以接受吗尽量让每段充实。列表项本身不计算。OK。下面开始正式生成最终答案。注意全文不要有“全文共XX字”等。现在开始写。 半年多前我在一个小型研发团队里做研发支撑日常任务被切得很碎上午还在改接口下午就得去另一个项目里帮忙写数据脚本晚上还得盯着发布。那段时间最消耗我的不是写代码本身而是“理解需求”和“把背景同步给另一个人”这两件事。于是我做了一个决定把 AI 当成一个必须参与交付的同事来用而不是停留在“偶尔打开网页问一下”的工具阶段。现在半年过去经手的项目里我挑了 4 个比较有代表性的来复盘分别是数据看板开发、遗留系统重构、跨部门数据迁移、自动化测试落地。这篇文章会把实际过程摊开讲重点聊一个大家都很关心的话题AI 在真实工作里到底提升了多少效率哪些效率是真实的哪些只是错觉。1. 从“调用工具”到“协作共事”我先给 AI 定了三条合作规则1.1 为什么是“同事”而不是“工具”传统开发工具的特点是确定性很强你点一个按钮它就执行一个固定动作结果预期一目了然。AI 完全不同它更像一个知识面很广、但缺乏项目背景的新人。同一个问题你给 30 字描述和给 300 字背景它能给出两个质量差很远的结果。我一开始也犯过工具思维的错误把它当成搜索引擎用需求描述不到位生成出来的代码像教科书示例根本接不进现有系统。后来我换了个思路如果团队来了一个实习生我会怎么跟他配合我会先告诉他项目背景、关键术语、哪些模块碰不得、交付物长什么样。那我为什么不能对 AI 做同样的事把 AI 当成同事本质上是在改变我自己的工作方式。我不再期待它一次性给出完美答案而是把它当成一个需要逐步对齐、反复验收的协作对象。这个心理转变很重要它决定了后面所有项目的协作流程。1.2 我实际定下来的三条规则第一先对齐背景再干活。每次正式开始之前我都会把项目背景、数据来源、业务口径、技术约束写成一页背景说明作为提示词的开头部分。这就像给新同事做入职培训背景给得越完整后面返工越少。第二明确交付物和验收标准。说“帮我优化一下这个接口”和“帮我重构这个函数的错误处理逻辑要求保持入参兼容并输出变更说明文档”前者容易得到正确但没用的答案后者才对应岗位上的真实需求。我后来养成了一个习惯每次发起任务都顺手补一句“输出请用表格”或“请给出代码和对应的测试用例”。第三限制自主范围。涉及生产环境、真实数据、核心逻辑修改的环节AI 只能产出草案不能直接执行。哪怕它给出了完整指令我也要经过人工审查后才落地。这条规则看起来保守但正是它让我敢在后面的项目里放手用 AI。1.3 我常用的三种协作角色执行者、分析师、陪练是我平时切换最多的三个角色定位。执行者很好理解写 SQL、写配置、生成样板代码、整理文档。这类任务可验证性高AI 生成完我扫一眼就能判断对不对效率提升最直接。分析师角色用在读代码、归纳日志、梳理调用关系的时候。我试过把一个老模块几千行代码拆开让 AI 逐段解释它在干什么竟然比我对着 IDE 一个个追调用还要快。陪练角色是后来才发现的让 AI 扮演项目评审人对我的方案提反例、挑风险或者让我扮演甲方让 AI 模拟提问。好几次它一本正经问出来的问题恰恰是我自己漏掉的关键条件。同一个模型切换角色之后产出的质量完全不一样这个玩法非常推荐试一下。2. 项目复盘一某运营数据看板项目——交付速度提了但业务口径差点翻车2.1 项目背景与工期压力某运营团队需要一个实时业务看板统计新增用户、活跃用户、订单转化几个核心指标要求展示近 30 天趋势还要能按渠道过滤。给我的时间只有两周而我手头还有其他模块的维护任务没法完整投入两周。这类项目真正花时间的地方通常不在前端样式而在数据侧表结构复杂、口径不统一、多个数据源之间的字段关联容易出错。项目启动时我拿到了一份数据库表结构说明和一份运营指标定义文档文档写得很粗很多口径埋在过往邮件沟通里。我当时的判断是这个项目很适合用 AI 加速。因为数据指标的计算逻辑虽然多但大部分步骤可以描述成明确的规则而且 SQL 的执行结果能直接在库里验证AI 有没有做错跑一遍就知道。2.2 AI 在项目里实际承担了什么我让 AI 做了三件事根据表结构生成统计 SQL、生成图表配置对应的 JSON 结构、写接口联调时需要的模拟数据。第一件事最核心也最锻炼人。第一次给 AI 的任务描述是这样的有三张表用户表、订单表、登录记录表要实现一个统计接口按天返回新增用户数、活跃用户数、订单转化率要求支持渠道维度筛选。AI 很快就生成了 SQL语法没毛病逻辑也基本对。我看了一遍就接进联调环境了。结果第二天运营同事跑过来问为什么看板上的新增用户数比后台导出的数字少了一截我查了半天最后发现问题出在“新增用户”的口径上后台导出的统计口径是去掉测试账号之后再去重而我让 AI 生成的 SQL 只是简单统计了注册表当天创建的用户测试账号全被算进去了。2.3 翻车原因拆解口径缺失这个问题的根源不在 AI而在我的任务描述。我以为 AI 能理解“新增用户”这个常用词但在不同业务系统里同样的词可能对应不同的口径。这就像你让一个新同事“看一下今天的流量”他可能不知道你指的是 UV、PV还是 App 启动次数。我后来在复盘里把它归结为“口径缺失”背景信息里没有把口径定义、排除规则、时间边界写清楚。AI 是按字面理解任务的它不会知道你们系统里存在一批测试账号也不会知道“新增”要基于去重后的最终状态。这个教训价值很高。后面我再让 AI 生成任何涉及业务指标的代码或 SQL 之前都会先建一个“口径清单”放在提示词里哪个指标怎么定义、哪些数据需要排除、日期按哪个时区算。清单一开始只有几条后来越用越厚变成了团队里重复使用的基础资产。2.4 后续我改用的提示词模板后来我再做类似的数据统计任务会先让 AI 复述口径确认理解一致后才开始写 SQL。这个操作多加了一轮对话看起来变慢了实际上省掉了后面联调时的返工。我把模板固定了下来大致包含五个部分项目背景、指标口径、表结构说明、交付物格式、禁忌事项。模板写出来是这样的背景这是某运营看板项目。需要统计每天新增用户数。 指标口径新增用户 注册表当天创建的用户排除 is_test1 的测试账号 并且按 user_id 去重。日期统一按东八区自然日计算。 表结构user_table(user_id, channel, is_test, create_time) 交付物一份可执行的 MySQL 查询 SQL输出字段为 date, channel, new_user_cnt。 禁忌不要使用 SELECT *不要忽略空值不要假设 channel 字段非空。半年下来这个模板已经成了团队内部资料库的一部分。这个项目最终按时上线了但从“代码能跑”到“口径正确”之间确实要靠人来把关。AI 帮我省掉的是写代码和查语法的时间而“指标到底该怎么算”这件事永远需要懂业务的人给出最后一锤定音。3. 项目复盘二某遗留系统模块重构——AI 当“代码考古学家”3.1 一块没人敢动的老代码团队接了一个遗留系统模块的重构任务。这个模块有六年历史原开发早已离职文档只留下几篇残缺的说明代码里充满让人困惑的命名函数之间耦合严重连测试环境都是手动搭的。团队内部评估过好几轮结论是“能跑就别动”但不动又不行因为新业务需求必须在它上面扩展。这类任务最费时间的地方不是写新代码而是搞清楚旧代码到底做了什么。我一度对着一个 2000 行的文件发了半天呆函数之间互相调用中间还夹着历史遗留的临时补丁根本不敢下手。3.2 AI 做代码拆解和调用链梳理我决定让 AI 当一个“代码考古学家”来用。先把大文件拆成若干函数单元按顺序粘贴给 AI要求它逐段说明输入、输出、副作用、被调用的位置。AI 给出的解释很多是现场注释但它能一口气把几十个函数的逻辑串起来省掉了我来回跳转的时间。更值钱的是调用链梳理。我让 AI 用文本方式描述“哪些函数会改库表、哪些函数会调用外部接口、哪些逻辑前后矛盾”它把一段段碎片信息拼成了相对完整的全貌。比如它偶然发现某个函数会在特定条件下覆盖掉另一处写入的值这就解释了为什么以前线上偶尔出现数据被改乱的诡异现象。这里要强调一下我特意不让 AI 画流程图而是要求它输出文字清单和表格。因为流程图画得再好看也要人来判断对错文字清单可以直接逐条核对可检查性比图表更强。3.3 让 AI 产出重构行为守护测试重构最大的风险不是改不动而是改完之后没人能证明行为和原来一致。我让 AI 根据代码分析结果生成了一份“行为变化清单”里面列明重构前和重构后预期要保留的所有行为点再让它为每个行为点生成测试用例。比如有一个旧函数会根据状态值决定走 A 分支还是 B 分支AI 把两种状态下的返回值都写成断言补充了边界输入和空值情况。有了这些用例兜底重构时我心里踏实很多敢动手了。其实这个项目里最容易被忽略的价值是AI 没有“怕背锅”的心理。人会倾向于只列自己确认过的点AI 会把各种异常分支都铺开哪怕有些分支根本走不到。铺开之后我们人工过滤比从零开始想测试场景要全得多。3.4 这次效率为什么提升最明显对比其他项目重构场景的效率收益是最高的。原因很简单旧代码的知识密度高但对人来说获取成本也高。AI 读代码的速度是人类眼睛的几十倍而且不会累、不会跳行。它帮我跳过了一段非常痛苦的“阅读文档困境”。不过也不能把 AI 的代码解读当成完全准确。我踩过一个小坑AI 把某个不常走的异常分支解释成了主流程导致我一开始对模块行为的理解有些偏差。后来我改成“让 AI 标注出每个结论的置信度”对存疑的地方再人工核对原文问题就少了很多。4. 项目复盘三跨部门数据迁移——AI 能做的事很多但映射必须人审4.1 迁移项目的典型痛点第三个项目是 A 系统到 B 系统的数据迁移。表面上看起来就是“导数据”但实际操作要处理字段映射、历史数据清洗、双跑校验还时刻被跨部门沟通拖慢进度。业务方希望你快速看到结果技术方又要求结构完整双方来回开会成本极高。迁移项目里最多的体力活是读文档和填表格。旧系统里一个“客户状态”字段新系统被拆成了三个字段还带枚举值映射旧系统里另一张表的备注信息需要根据内容分成结构化数据。这些规则分散在不同的历史文档里人工整理不仅慢而且漏掉一条就是线上事故。4.2 AI 承担的三类工作第一类是把迁移文档整理成映射清单。我给 AI 一段原始说明让它按“旧字段、新字段、转换规则、特殊说明”输出成表格再把分散的补充说明合并进去。这一步很枯燥但 AI 做得相当稳毕竟它擅长从大段文字里提炼关键信息。第二类是生成测试数据和校验 SQL。拿到映射规则后我让 AI 构造少量覆盖正常值、空值、超长值、非法枚举的测试数据并生成用于核对新旧系统数据一致性的 SQL省掉了很多手工拼接的时间。第三类是日志归纳。迁移过程中会跑出大量异常日志一条条打开看根本看不过来。我把日志内容交给 AI让它按“缺字段、类型不匹配、关联失败、其他”分类汇总并给出每类的示例行。这样一来我能直接定位最集中的问题而不是在日志文件里翻个没完。4.3 一次真实告警状态字段映射遗漏这个项目不是没踩坑。最让我印象深刻的是一次晚间双跑校验失败迁移过去的历史数据里有一批“已完结”状态的数据无法被新系统识别。查到最后发现 AI 生成的映射清单里漏掉了状态字段进入终态前的过渡步骤。我复盘了一下原因迁移文档里描述状态转移用的是一段自然语言AI 按字面摘出了各状态的名字但没有结合状态机的流转逻辑去理解“终态标记”在数据里到底怎么体现。它摘录得很认真但缺了业务推理的那一步。从那之后凡是字段映射这一类关键逻辑我都要求人工至少过两遍第一遍由项目负责人逐条核对枚举值和状态流第二遍在测试环境里挑出典型数据跑通端到端流程。AI 适合做整理和生成不适合背责任。4.4 关键环节人工审批的边界很快我发现不是所有内容都要让人工审只需要在关键节点设置审批点。比如字段映射表、影响真实数据的脚本、以及数据回退方案这三类必须人工确认而生成模拟数据、归纳日志、把文档转成表格这些环节让 AI 直接跑就行。这个分工后来省了很多精力。以前大家习惯把 AI 的产出全盘信任或全盘怀疑这两个方向都极端。设置审批点之后团队里形成了一种共识低风险高重复的事让 AI 全自动中风险高价值的事让 AI 起草、人来定稿高风险低容错的事最终必须人工拍板。5. 项目复盘四自动化测试与发布检查清单——AI 把脏活累活变成了资产5.1 发布前手工检查有多痛第四个项目和测试相关。团队每次发版前都有一长串前置检查项核心接口是否可用、测试数据是否齐全、配置项是否生效、日志输出是否正常。以前这些检查全靠人工在测试环境里点来点去一个人至少花 40 分钟还很容易漏查。漏查的后果很直接数据对不上、接口报错、配置被跳过。这种问题几乎每个版本都会出现大家已经默认它是“发布的一部分”了这其实很不正常。我决定把这个工作拆给 AI 和脚本共同完成。5.2 让 AI 生成测试用例和校验脚本我的思路是把检查清单描述给 AI让 AI 把每个条目转成一个可执行的测试用例再让 AI 把这些用例组织成一个自动校验脚本。第一次做的时候我给了 AI 一个清单模板包含接口地址、预期状态码、关键字段、注意事项让 AI 补齐具体值。AI 生成的测试代码可以直接跑但也存在两个问题断言覆盖太浅、对异常路径考虑不全面。比如某个发布检查项是“订单查询接口能查到最新下单”AI 只写了一个状态码 200 的断言没有校验返回数据的时间是不是最新。后来我调整了提示词要求“每个检查项至少断言两个纬度状态码 业务结果字段”生成质量明显上了一个台阶。5.3 手工与 AI 辅助的效果对比我把改造前后的发布检查流程整理成了一张对比表放在团队内部文档里维度手工方式AI 生成 人工审查单次耗时40 分钟左右10 分钟左右覆盖范围依赖执行人经验有时漏项覆盖全部清单条目还能补充边界场景自动化程度需要人一步一步操作脚本一键执行输出结果归档维护成本每次靠人回忆用例作为资产沉淀在代码仓库风险点遗漏检查项断言可能写错需要人工审查实测下来最稳定的反而不是速度而是“不偷懒”。机器跑检查不会说“今天看过了应该没问题”它会老老实实把每条断言跑完失败就报警。这种确定性在发布流程里非常宝贵。5.4 哪些检查不能直接交给 AI当然不是所有检查都适合自动化。有一类检查需要实时连接真实库和外部依赖比如主数据一致性、跨服务计数对齐这类判断如果交给 AI 生成脚本又没有人复核很容易在错误条件下给出绿色结果。我的原则是能用真实数据核对的检查就一定要连真实数据AI 只负责生成脚本框架最终对业务结果的判断要人来确认。这次落地的复盘中我也意识到团队需要沉淀的不只是脚本本身还有“怎么描述检查项”的方法。把“检查订单接口”改成“检查订单查询接口要求返回最近 30 分钟内的新增订单数且关键字段不为空”AI 才能生成靠谱的断言。把检查项说清楚其实是测试工程的核心能力AI 只是把这个能力的价值放大了。6. 效率的真相半年后我总结出的判断标准6.1 真正省时的三类任务如果把半年来所有 AI 使用场景做个总结真正稳定提升效率的落在三类任务上样板化内容生产、信息归纳整理、低风险代码生成。样板化内容包括配置 JSON、接口骨架、数据模型定义、邮件通知模板等这类任务有明确范式AI 生成速度远超手写。信息归纳整理包括文档摘要、日志分类、调用链分析、解释陌生代码AI 的上下文理解和输出结构化能力很强比人翻文件快得多。低风险代码生成包括测试数据构造、单测用例、转换脚本这类任务可以通过运行结果快速验证错了也不影响生产。6.2 假省时看起来很快实际要返工有一类任务是典型的假省时核心算法设计、复杂业务决策、高风险的故障修复。让 AI 做这些经常能在一分钟内产出一份看起来很完整的方案但一落到真实约束里就会发现它漏了关键条件。比如在数据迁移项目里让 AI 直接给映射规则看起来很爽但漏掉状态机后返工的成本远超手工整理在数据看板项目里让 AI 直接写 SQL 也很爽但口径错误引发业务质疑后信任成本比改代码更高。省不省时不能只看首次生成时间还要算上校验和返工时间。6.3 用 AI 效率最高的人具备什么特征观察团队里使用 AI 效果差异明显的同事我发现效率高的人普遍有三个特征会拆任务、会说清背景、会验收。会拆任务指的是能把一个大问题拆成 AI 可执行的子问题而不是直接扔一句“帮我做一个系统”会说清背景指的是愿意在提示词里花时间写上下文而不是让 AI 猜会验收指的是拿到结果后会做最小验证而不是直接信任输出或直接推翻。这三个特征恰好也是软件工程的基本功AI 并没有改变它对人的要求只是把能力差距放大了。6.4 给团队的落地建议我不建议一开始就要求全员使用 AI也不建议定什么使用次数的考核指标。比较实际的做法是先找一两个试点项目让愿意尝试的人把提示词模板、验收清单、常见坑沉淀下来再逐步铺开。团队里真正能沉淀下来的资产是那些经过验证的提示词模板、口径清单、审查流程而不是某个人的灵光一现。把这些资产放进知识库后面新来的同事也能快速上手。半年下来我最深的感受是AI 落地最缺的不是模型能力而是围绕它的一套工作规范。7. 常见问题与避坑心得速查表7.1 AI 一本正经胡说八道怎么办AI 最大的风险不是拒绝回答而是用非常流畅的语言说出一个错误结论。我的处理办法是要求它给出推理过程和信息来源同时让它标注每个结论的置信度。遇到关键决策我会把它的输出拆成几个独立命题逐个回到原始资料里验证不能因为它写得好就当作事实。7.2 上下文窗口不够长怎么办代码文件太长、历史对话太多都会导致 AI 记不住前面的内容。我的处理思路是先把大文件拆成小块让 AI 对每个块做摘要再把摘要汇总成全局理解必要的时候用文件路径和函数名代替粘贴全文让它先给分析框架再针对具体片段深入。这种方法比盲目扩大上下文更稳定。7.3 怎么防止 AI 生成的代码带安全风险我会在提示词里直接写清安全约束比如禁止使用危险函数、禁止拼接 SQL、禁止硬编码密钥、参数必须走白名单校验。生成结果之后还要过一遍代码安全检查看输入校验、权限控制、数据脱敏三个维度。不要因为代码是 AI 写的就跳过 review反而是越顺利的生成越要警惕默认实现带来的漏洞。7.4 团队使用 AI 的三个底线我的底线很简单不直接在生产环境执行 AI 生成的命令不让 AI 的产出在没有人工审核的情况下进入核心数据链路不把涉及用户隐私的原始数据直接粘贴给外部 AI 工具。这三点落到制度上之后团队用 AI 的胆子反而更大了因为边界清楚了剩下的就是放心探索。复盘完这 4 个项目我个人最大的体会是AI 能提升多少效率很大程度上取决于你愿不愿意把它当成一个需要被管理的同事。你越能清晰描述任务越能严格验收结果它的产出就越稳定反过来如果你只是把它当成一个一键出结果的工具那翻车概率也不会低。最后再分享一个小技巧每次让 AI 干活之前多花 30 秒把“背景”和“不要做什么”写进提示词里这 30 秒往往能省掉后面 30 分钟的对账时间。效率的真相就是这样真正的杠杆不是 AI 本身而是那个能把需求讲清楚、把标准定下来的人。
