半年前我做了一个决定不再把 AI 当作搜索引擎的升级版而是把它当成一个刚入职的同事。起因是一次数据清洗任务——几万行日志重复、缺失、格式不一人工处理怎么也得一个下午。我抱着试试看的心态让 AI 写了个 Python 脚本虽然第一次翻车了但那次经历让我开始认真研究 AI 工程实践。之后半年我陆续在 4 个真实项目里用了 AI写脚本、搭 Agent、做代码审查、私有化部署模型。如果你也用 AI 干过活但总觉得好像也没那么神这篇复盘应该对你有用。我会把每个项目的背景、做法、踩过的坑和最后怎么调整的都摊开讲聊聊 AI 提效这件事的真相。1. 数据清洗项目提示词的边界感决定了返工次数第一个项目是处理一份采集来的日志数据。大概 3 万多行里面有重复记录、字段缺失、日期格式不一致还有一些明显越界的异常值。以前遇到这种事我的流程是写一个 Python 脚本先看 100 行样例再写去重逻辑、缺失值处理、格式统一最后跑一遍看输出。这活儿难度不大但很费时间尤其是反复调试边界条件的过程很消磨耐心。1.1 第一次让 AI 写脚本看起来能跑是最贵的错觉我第一次给的提示词现在回想起来太天真了。原话大概是用 Python 写一个清洗脚本读取 data.log删除重复行填充缺失值输出到 clean.log。AI 十几秒就给我生成了一段 60 行的代码有 pandas 读取、drop_duplicates、fillna、to_csv结构完整一眼看过去像是能用的样子。我第一反应是AI 写代码确实快。结果一跑就出事。它把缺失值全部填成了 0。可这份日志里的缺失分好几种有的字段是没有采集到有的值是超时无结果有的是权限不足看不到。这三种情况要是统一填 0后面做聚合统计时会把超时当成数值为 0整个分析结论都会歪掉。我花了将近 40 分钟排查才意识到问题出在提示词根本没交代字段语义。这段经历让我明白一个特别简单的道理AI 是字面理解的机器它在执行层面很强但不会自动补充你没说的背景知识。就像你跟一个新同事说把表理一下他如果不问清楚字段含义就动手最后你俩都得返工。1.2 把约束写进上下文之后时间从 2 小时缩到 40 分钟第二次我换了一种写法。我先把数据字典整理出来包括每个字段的含义、缺失值有哪几种、各自代表什么、日期格式有哪几种、异常值的判断标准。然后把需求改成请先给出处理方案再写代码。要求缺失值按字段分别处理采集缺失保留空值超时填 -1权限不足填 -2日期统一转成 ISO 格式重复记录按 id 加时间戳去重。这次 AI 的输出就正常多了。它不仅给了方案还主动加了一个校验函数用来检查清洗前后数据量是否一致。我把脚本跑通后又让它补了错误率统计整个流程从一个下午变成从沟通到跑通约 40 分钟。返工成本大幅下降。这里有个值得注意的操作我刻意让 AI 先给方案、再写代码这个顺序不能反。因为一旦代码生成出来人就会有已经完成的错觉很容易跳过约束确认直接跑数这才是返工的第一大原因。1.3 这个项目的真实提效点不是写代码而是把需求说清楚如果只看写脚本这一步AI 大概只帮我省了 15 分钟敲代码的时间。但把整个项目拉通看真正省时间的是另一件事——我被迫把需求文档化了。以前我可能直接闷头写代码遇到边界情况边写边想现在为了让 AI 理解我必须先把字段语义、缺失策略、异常规则理顺。这些梳理结果不止对 AI 有用后来我自己调试和给别人交接时也都在用。对比项第一次第二次提示词内容只给任务目标数据字典加约束加方案要求输出形态直接写代码先方案后代码缺失值处理统一填 0分字段策略返工次数2 次0 次总耗时约 2 小时约 40 分钟所以第一个项目的效率真相是AI 把执行成本压到很低但前提是需求输入足够清晰。你把时间花在说清楚上它就能把时间从写代码里省回来。反过来你输入含糊它输出天花乱坠最后的耗时只会更久。2. 多 Agent 文档流水线分工越细越考验数据契约第二个项目来自一个日常烦心事每周要把十几个渠道的行业资讯整理成周报。这个活本身不复杂但重复性很高。我当时的想法是既然 AI 已经能写脚本、写文案那干脆搭一个多 Agent 协作的流程一个 Agent 负责抓取资讯一个负责去重分类一个负责写周报摘要。这就是网上常说的多 AI 协作、Agent 搭建。我当时觉得这才是把 AI 当同事用的正确姿势。2.1 我理想中的AI 同事开会实际跑成了事故现场第一版方案我规划得很理想。抓取 Agent 返回原始内容去重 Agent 负责去重摘要 Agent 写最终周报。三个 Agent 各干各的并行跑我想着这怎么也能把每周 2 小时的活压缩到 20 分钟。结果第一版上线后事故现场是这样的抓取 Agent 返回的内容格式不一致有的带标题有的只有正文有的 HTML 标签没清理干净。去重 Agent 接到这些脏数据把不同日期的两条相似新闻当成重复删掉了。摘要 Agent 更惨输入里混着乱码和截断文本最后产出的周报质量完全没法看。最让我崩溃的是出错方式很隐蔽——每个 Agent 都成功执行了没有任何报错但最终结果就是不能用。你很难定位问题发生在哪个环节。我当时开玩笑说这不像是团队协作更像是三个各说各话的人开了一个无效会议。2.2 救场的关键给 Agent 传参定 JSON 契约冷静下来之后我把问题拆了一轮。我发现三个 Agent 单拎出来表现都不差问题出在衔接处。信息在传递过程中丢失了格式语义和上下文。我突然想到这不就是后端开发里最常见的接口对接问题吗A 部门交付的数据结构不稳定B 部门再聪明也会瞎。多 Agent 协作的难点根本不在模型智商而在数据契约。于是我做了一个调整所有 Agent 之间统一用固定 JSON 结构传参。抓取 Agent 输出必须包含 url、title、publish_date、content、source 这五个字段去重 Agent 输出必须包含 action、reason、original_json摘要 Agent 的输入必须包含一个经过 schema 校验的 JSON 数组。任何不符合 schema 的输出都触发一次重试。为了保证格式稳定我还在每个 Agent 的提示词里直接贴了 JSON 示例而不是只写请以 JSON 格式输出。这一点很重要——给例子比给描述可靠得多。改完之后整条流水线从跑 20 分钟错一堆变成跑 8 分钟偶尔重试一两条周报真的能用了。2.3 Agent 的稳定性靠什么角色模糊是最大的坑除了数据契约还有一个调整作用极大角色提示词。一开始我写的角色是你是一名资深的行业分析师、你是一名优秀的编辑。后来我发现这种身份描述越华丽输出越飘。模型擅长顺着角色暗示发挥结果就是摘要 Agent 老爱加自己的观点和形容词这恰恰是周报最忌讳的。我把角色提示词改成纯功能描述你的任务是从输入 JSON 数组中提取 title、publish_date、source并按时间顺序去重。不要改写不要总结输出 JSON 数组。改完之后稳定性立刻上来了。工程化的 Agent 提示词功能描述永远优先于身份设定。2.4 搭建成本 vs 长期收益账要拉长看这个项目的效率账是这样的搭建大概花了两天半维护成本是每周 20 分钟。如果只看单周效率是负的但放到半年维度它帮我省掉的重复劳动非常可观。我后来一直提醒自己评价 Agent 项目不能看首周至少看一个月。这里还有一个额外收获之前每次整理周报都靠手工复制粘贴和肉眼去重出错率不低偶尔会把重要信息漏掉。现在有了统一的数据契约历史周报也变成结构化数据了后续想做月度趋势分析直接跑脚本就行。这个数据资产是计划外的红利。3. AI 代码审查项目从鸡肋工具到高危点哨兵第三个项目是给团队接 AI 代码审查。当时团队代码评审压力不小PR 多的时候每个人一天要花一小时看代码而且看久了容易走神正好把最该注意的高风险点漏过去。我试着把 AI 接进 review 流程最开始的想法很简单让 AI 提意见人再过滤。3.1 第一版通用审查为什么被同事嫌弃第一版我用的方式比较粗暴直接把 PR diff 丢给通用模型让它审查代码提改进建议。结果反馈一片差评。AI 提的意见集中在函数命名应该更清晰、建议拆分成更小的函数、这行代码缺少注释。这些意见不能说错但基本没有参考价值还偶尔出现误报——把本来正确的边界判断说成 bug把刻意为之的写法说成代码坏味道。更麻烦的是同事开始无条件信任 AI 的意见在 review 里逐条回复AI 说这里不对进一步浪费时间。我第一次意识到AI review 的负面效应不是能力不够而是噪音太多。当可信度被噪音消耗掉之后它偶尔说出的正确意见也没人听了。3.2 把审查范围收敛到 4 类风险点之后后来我做了一次比较大的调整。我们团队过去一年线上出的问题不少都集中在几个地方SQL 注入、硬编码密钥、异常被静默吞掉、越权调用。我整理了一份清单把 AI 的审查范围严格限制在这四类还加了一条硬性规则如果问题不在清单里不要评论。我在提示词里反复强调宁可漏判不要误报。这个调整效果立竿见影。AI 的评论从每页都有几十条变成一个 PR 平均只有几条而且每条都值得看。最典型的一次它在一个改动不大的 PR 里发现了一段硬编码的 MySQL 连接串。那个 PR 的改动看着人畜无害如果不是 AI 盯着谁都注意不到。团队从那以后开始把 AI review 当成一个只盯高危点的同事。我还专门测过误报率。收敛之后AI 标记的问题里大约八成是真问题这个水平已经足够进入人工确认流程了。3.3 顺带试了 AI 生成单元测试有用但需要约束做审查的同时我也试了试让 AI 生成单元测试。第一版生成的测试很脆经常断言具体字符串、绑定实现细节稍微改个内部逻辑就全红维护成本比手写还高。后来我把要求改成关注行为层面的边界条件和异常分支不绑定实现细节生成的质量才上来。这一块帮我省的时间不少。以前我写完功能代码补单测大概要占整个开发时间的三成。现在 AI 生成的测试覆盖正常路径和大部分边界路径我再补异常场景就快多了。不过注意AI 生成的测试得人工跑一遍绝对不能直接合进流水线当门禁不然脆弱的测试只会让团队更烦。3.4 团队信任 AI 审查的三个前提这次项目让我积累了一套判断标准。想让团队愿意用 AI review至少得满足三点。第一规则收敛到高风险点宁缺毋滥第二AI 的告警保留人工确认环节不能直接自动阻塞第三定期把团队新踩的坑补充进规则让 AI 跟着团队经验一起迭代。效率账也很清楚以前我 review 一个大 PR 要 30 到 40 分钟现在 AI 预筛后一般 15 到 20 分钟结束关键是我不太会漏掉最致命的问题。这个项目是四个项目里收益最稳定、最容易被团队接受的。4. 私有化模型部署项目效率藏在少返工里不在跑得快里第四个项目的背景是内部文档摘要。这些文档有一套保密要求不能发到外部 API。我选了个开源模型7B 参数级别在一台闲置 GPU 服务器上做私有化部署。这一步算是我第一次真正独立做 AI 模型部署收获和教训都不少。4.1 为什么要部署一个本地模型当时有几套方案可以选。方案一直接用外部大模型效果好但数据合规上过不去方案二人工做摘要最稳但太慢方案三本地部署一个开源模型效果差一点但数据不出内网。我最后选了方案三。很多人觉得本地部署是为了快其实大部分时候本地小模型并不比外部大模型快真正省下来的是合规沟通和等待审批的时间。这个选择本身就是一种效率策略。4.2 部署不难稳定输出才难部署过程本身比我想象的顺利。我用现成的推理框架下好权重做量化封装成一个本地 HTTP 接口。大概两天就通了第一次调用通的时候我还挺兴奋——终于有自己的模型服务了。但接下来一周我都在跟输出不稳定性搏斗。同一个问题它有时候回答很详细有时候只给几个字有时候一本正经地胡说八道。一开始我以为是小模型能力不够后来排查发现是我没注意推理参数温度太高采样随机性太大。把温度从默认值降到 0.1 左右输出质量立刻稳定了一截。另一个坑是流式输出。看起来流式体验更顺滑但对自动处理流程来说它会让末尾截断的概率变高导致 JSON 解析失败。后来我统一改成非流式请求并且要求在回复里固定输出 JSON 格式失败率从差不多 10% 降到 1% 以下。参数初始配置调整后效果温度默认偏高0.1输出稳定输出方式流式非流式JSON 解析失败率下降输出格式自由文本固定 JSON下游处理不再报错4.3 小模型的能力边界该让它干什么不该让它干什么私有化部署最怕的是期望错位。7B 模型写长篇文章、做复杂推理肯定不如大模型。我一开始什么都想让它干摘要、改写、问答、信息抽取结果经常不满意。后来我把场景压缩到三件事文档摘要、关键词提取、文本分类。这三个任务足够简单小模型能稳定胜任。我把这个边界写成了硬性要求每次调用只能做清单里的任务超过范围直接拒绝。这看起来像自我设限但实际效果是——它不会乱来我可以放心把业务交给它跑。模型能力边界划清楚之后维护成本低了很多。4.4 接入日常流程前的脏活清单部署完之后还有一堆脏活接口封装、并发控制、请求日志、超时重试。这些听着和 AI 没关系但恰好是把 AI 当同事用的前提。同事靠不靠谱不只看能力还要看响应是否稳定、出错有没有日志、出问题能不能回滚。模型服务也一样。我列一个清单凡是接到业务流程里的 AI 服务这几项不能省第一统一 API 封装调用方不直接感知模型细节第二并发控制防止突发请求把 GPU 打满第三每个请求都有 trace 日志出错能查到上下文第四超时和重试机制保证单个请求失败不会拖垮整条链路。这些脏活看着不起眼但少了任意一项AI 服务就不具备被纳入日常流程的资格。这一轮的效率账是长线账一次调用省掉一个人读文档摘要的 20 分钟一天跑几十次一个月下来省的时间足够抵消部署和调优的投入。所以我一直觉得私有化部署的效率不在跑得快而在少返工——模型能力够用就行关键是稳定、可观测、可控。5. 半年复盘的四个真相效率不是 AI 给的是流程给的四个项目跑完我对AI 提效的态度从兴奋变成了平常心。这里总结四条规律也是我之后继续用 AI 的原则。5.1 真相一AI 省执行时间不省思考时间四个项目的共同点很明显需求越清晰AI 发挥越稳目标越含糊越容易带人绕远路。我自己整理需求的时间一点没少甚至比以前更多但换来的是执行层面的时间大幅压缩。最划算的姿势永远是你来定边界和标准AI 来填细节和初稿。想靠 AI 偷思考的懒迟早会在返工里还回去。5.2 真相二稳定性压倒一切格式化约束比模型选型更重要输出不稳定的 AI效率是负的。为了让 AI 稳定我花了大量精力在格式化约束、JSON schema、规则清单、温度参数这些看起来特别不性感的细节上。事实证明给 AI 立规矩、给例子比换一个更大的模型管用得多。稳定意味着可预期可预期才是协作的基础。5.3 真相三AI 只有在闭环里才可靠单点 AI 能力再强放在不可控的流程里也容易翻车。我后来把所有 AI 功能都放进同一个结构输入有 schema 校验输出有格式校验中间有重试机制末端有人工复核。这个闭环让 AI 的容错率高很多。AI 可以犯错但闭环兜住错误最终产出才是稳的。这也是为什么有人用 AI 效率翻倍有人用 AI 越用越乱——差的不是模型是流程。5.4 真相四当同事用的是流程设计能力最重要的一点AI 之所以能当同事不是因为它聪明而是因为你愿意把它设计进一个明确的岗位里给它职责、边界、协作接口和复核环节。这需要的不是提示词技巧而是拆解任务、定义接口、设计容错的工程能力。能力越强AI 越能打流程越糙AI 越添乱。最后分享一个我一直保留的小习惯我会给每个和 AI 协作的项目建一个交接文档文件夹里面包含背景说明、约束清单、历史失败案例和成功案例。每次开始新任务我先把这些喂给 AI相当于给新同事做入职培训。这个小习惯看起来麻烦但长期下来能避免大量重复踩坑。如果你也想把 AI 当同事用我建议你从一个小而明确的项目开始先把边界、格式、复核机制定好别一上来就追求全自动。效率的真相不是我一开始以为的AI 帮我干活而是我用流程让 AI 能干成活。
半年前我做了一个决定不再把 AI 当作搜索引擎的升级版而是把它当成一个刚入职的同事。起因是一次数据清洗任务——几万行日志重复、缺失、格式不一人工处理怎么也得一个下午。我抱着试试看的心态让 AI 写了个 Python 脚本虽然第一次翻车了但那次经历让我开始认真研究 AI 工程实践。之后半年我陆续在 4 个真实项目里用了 AI写脚本、搭 Agent、做代码审查、私有化部署模型。如果你也用 AI 干过活但总觉得好像也没那么神这篇复盘应该对你有用。我会把每个项目的背景、做法、踩过的坑和最后怎么调整的都摊开讲聊聊 AI 提效这件事的真相。1. 数据清洗项目提示词的边界感决定了返工次数第一个项目是处理一份采集来的日志数据。大概 3 万多行里面有重复记录、字段缺失、日期格式不一致还有一些明显越界的异常值。以前遇到这种事我的流程是写一个 Python 脚本先看 100 行样例再写去重逻辑、缺失值处理、格式统一最后跑一遍看输出。这活儿难度不大但很费时间尤其是反复调试边界条件的过程很消磨耐心。1.1 第一次让 AI 写脚本看起来能跑是最贵的错觉我第一次给的提示词现在回想起来太天真了。原话大概是用 Python 写一个清洗脚本读取 data.log删除重复行填充缺失值输出到 clean.log。AI 十几秒就给我生成了一段 60 行的代码有 pandas 读取、drop_duplicates、fillna、to_csv结构完整一眼看过去像是能用的样子。我第一反应是AI 写代码确实快。结果一跑就出事。它把缺失值全部填成了 0。可这份日志里的缺失分好几种有的字段是没有采集到有的值是超时无结果有的是权限不足看不到。这三种情况要是统一填 0后面做聚合统计时会把超时当成数值为 0整个分析结论都会歪掉。我花了将近 40 分钟排查才意识到问题出在提示词根本没交代字段语义。这段经历让我明白一个特别简单的道理AI 是字面理解的机器它在执行层面很强但不会自动补充你没说的背景知识。就像你跟一个新同事说把表理一下他如果不问清楚字段含义就动手最后你俩都得返工。1.2 把约束写进上下文之后时间从 2 小时缩到 40 分钟第二次我换了一种写法。我先把数据字典整理出来包括每个字段的含义、缺失值有哪几种、各自代表什么、日期格式有哪几种、异常值的判断标准。然后把需求改成请先给出处理方案再写代码。要求缺失值按字段分别处理采集缺失保留空值超时填 -1权限不足填 -2日期统一转成 ISO 格式重复记录按 id 加时间戳去重。这次 AI 的输出就正常多了。它不仅给了方案还主动加了一个校验函数用来检查清洗前后数据量是否一致。我把脚本跑通后又让它补了错误率统计整个流程从一个下午变成从沟通到跑通约 40 分钟。返工成本大幅下降。这里有个值得注意的操作我刻意让 AI 先给方案、再写代码这个顺序不能反。因为一旦代码生成出来人就会有已经完成的错觉很容易跳过约束确认直接跑数这才是返工的第一大原因。1.3 这个项目的真实提效点不是写代码而是把需求说清楚如果只看写脚本这一步AI 大概只帮我省了 15 分钟敲代码的时间。但把整个项目拉通看真正省时间的是另一件事——我被迫把需求文档化了。以前我可能直接闷头写代码遇到边界情况边写边想现在为了让 AI 理解我必须先把字段语义、缺失策略、异常规则理顺。这些梳理结果不止对 AI 有用后来我自己调试和给别人交接时也都在用。对比项第一次第二次提示词内容只给任务目标数据字典加约束加方案要求输出形态直接写代码先方案后代码缺失值处理统一填 0分字段策略返工次数2 次0 次总耗时约 2 小时约 40 分钟所以第一个项目的效率真相是AI 把执行成本压到很低但前提是需求输入足够清晰。你把时间花在说清楚上它就能把时间从写代码里省回来。反过来你输入含糊它输出天花乱坠最后的耗时只会更久。2. 多 Agent 文档流水线分工越细越考验数据契约第二个项目来自一个日常烦心事每周要把十几个渠道的行业资讯整理成周报。这个活本身不复杂但重复性很高。我当时的想法是既然 AI 已经能写脚本、写文案那干脆搭一个多 Agent 协作的流程一个 Agent 负责抓取资讯一个负责去重分类一个负责写周报摘要。这就是网上常说的多 AI 协作、Agent 搭建。我当时觉得这才是把 AI 当同事用的正确姿势。2.1 我理想中的AI 同事开会实际跑成了事故现场第一版方案我规划得很理想。抓取 Agent 返回原始内容去重 Agent 负责去重摘要 Agent 写最终周报。三个 Agent 各干各的并行跑我想着这怎么也能把每周 2 小时的活压缩到 20 分钟。结果第一版上线后事故现场是这样的抓取 Agent 返回的内容格式不一致有的带标题有的只有正文有的 HTML 标签没清理干净。去重 Agent 接到这些脏数据把不同日期的两条相似新闻当成重复删掉了。摘要 Agent 更惨输入里混着乱码和截断文本最后产出的周报质量完全没法看。最让我崩溃的是出错方式很隐蔽——每个 Agent 都成功执行了没有任何报错但最终结果就是不能用。你很难定位问题发生在哪个环节。我当时开玩笑说这不像是团队协作更像是三个各说各话的人开了一个无效会议。2.2 救场的关键给 Agent 传参定 JSON 契约冷静下来之后我把问题拆了一轮。我发现三个 Agent 单拎出来表现都不差问题出在衔接处。信息在传递过程中丢失了格式语义和上下文。我突然想到这不就是后端开发里最常见的接口对接问题吗A 部门交付的数据结构不稳定B 部门再聪明也会瞎。多 Agent 协作的难点根本不在模型智商而在数据契约。于是我做了一个调整所有 Agent 之间统一用固定 JSON 结构传参。抓取 Agent 输出必须包含 url、title、publish_date、content、source 这五个字段去重 Agent 输出必须包含 action、reason、original_json摘要 Agent 的输入必须包含一个经过 schema 校验的 JSON 数组。任何不符合 schema 的输出都触发一次重试。为了保证格式稳定我还在每个 Agent 的提示词里直接贴了 JSON 示例而不是只写请以 JSON 格式输出。这一点很重要——给例子比给描述可靠得多。改完之后整条流水线从跑 20 分钟错一堆变成跑 8 分钟偶尔重试一两条周报真的能用了。2.3 Agent 的稳定性靠什么角色模糊是最大的坑除了数据契约还有一个调整作用极大角色提示词。一开始我写的角色是你是一名资深的行业分析师、你是一名优秀的编辑。后来我发现这种身份描述越华丽输出越飘。模型擅长顺着角色暗示发挥结果就是摘要 Agent 老爱加自己的观点和形容词这恰恰是周报最忌讳的。我把角色提示词改成纯功能描述你的任务是从输入 JSON 数组中提取 title、publish_date、source并按时间顺序去重。不要改写不要总结输出 JSON 数组。改完之后稳定性立刻上来了。工程化的 Agent 提示词功能描述永远优先于身份设定。2.4 搭建成本 vs 长期收益账要拉长看这个项目的效率账是这样的搭建大概花了两天半维护成本是每周 20 分钟。如果只看单周效率是负的但放到半年维度它帮我省掉的重复劳动非常可观。我后来一直提醒自己评价 Agent 项目不能看首周至少看一个月。这里还有一个额外收获之前每次整理周报都靠手工复制粘贴和肉眼去重出错率不低偶尔会把重要信息漏掉。现在有了统一的数据契约历史周报也变成结构化数据了后续想做月度趋势分析直接跑脚本就行。这个数据资产是计划外的红利。3. AI 代码审查项目从鸡肋工具到高危点哨兵第三个项目是给团队接 AI 代码审查。当时团队代码评审压力不小PR 多的时候每个人一天要花一小时看代码而且看久了容易走神正好把最该注意的高风险点漏过去。我试着把 AI 接进 review 流程最开始的想法很简单让 AI 提意见人再过滤。3.1 第一版通用审查为什么被同事嫌弃第一版我用的方式比较粗暴直接把 PR diff 丢给通用模型让它审查代码提改进建议。结果反馈一片差评。AI 提的意见集中在函数命名应该更清晰、建议拆分成更小的函数、这行代码缺少注释。这些意见不能说错但基本没有参考价值还偶尔出现误报——把本来正确的边界判断说成 bug把刻意为之的写法说成代码坏味道。更麻烦的是同事开始无条件信任 AI 的意见在 review 里逐条回复AI 说这里不对进一步浪费时间。我第一次意识到AI review 的负面效应不是能力不够而是噪音太多。当可信度被噪音消耗掉之后它偶尔说出的正确意见也没人听了。3.2 把审查范围收敛到 4 类风险点之后后来我做了一次比较大的调整。我们团队过去一年线上出的问题不少都集中在几个地方SQL 注入、硬编码密钥、异常被静默吞掉、越权调用。我整理了一份清单把 AI 的审查范围严格限制在这四类还加了一条硬性规则如果问题不在清单里不要评论。我在提示词里反复强调宁可漏判不要误报。这个调整效果立竿见影。AI 的评论从每页都有几十条变成一个 PR 平均只有几条而且每条都值得看。最典型的一次它在一个改动不大的 PR 里发现了一段硬编码的 MySQL 连接串。那个 PR 的改动看着人畜无害如果不是 AI 盯着谁都注意不到。团队从那以后开始把 AI review 当成一个只盯高危点的同事。我还专门测过误报率。收敛之后AI 标记的问题里大约八成是真问题这个水平已经足够进入人工确认流程了。3.3 顺带试了 AI 生成单元测试有用但需要约束做审查的同时我也试了试让 AI 生成单元测试。第一版生成的测试很脆经常断言具体字符串、绑定实现细节稍微改个内部逻辑就全红维护成本比手写还高。后来我把要求改成关注行为层面的边界条件和异常分支不绑定实现细节生成的质量才上来。这一块帮我省的时间不少。以前我写完功能代码补单测大概要占整个开发时间的三成。现在 AI 生成的测试覆盖正常路径和大部分边界路径我再补异常场景就快多了。不过注意AI 生成的测试得人工跑一遍绝对不能直接合进流水线当门禁不然脆弱的测试只会让团队更烦。3.4 团队信任 AI 审查的三个前提这次项目让我积累了一套判断标准。想让团队愿意用 AI review至少得满足三点。第一规则收敛到高风险点宁缺毋滥第二AI 的告警保留人工确认环节不能直接自动阻塞第三定期把团队新踩的坑补充进规则让 AI 跟着团队经验一起迭代。效率账也很清楚以前我 review 一个大 PR 要 30 到 40 分钟现在 AI 预筛后一般 15 到 20 分钟结束关键是我不太会漏掉最致命的问题。这个项目是四个项目里收益最稳定、最容易被团队接受的。4. 私有化模型部署项目效率藏在少返工里不在跑得快里第四个项目的背景是内部文档摘要。这些文档有一套保密要求不能发到外部 API。我选了个开源模型7B 参数级别在一台闲置 GPU 服务器上做私有化部署。这一步算是我第一次真正独立做 AI 模型部署收获和教训都不少。4.1 为什么要部署一个本地模型当时有几套方案可以选。方案一直接用外部大模型效果好但数据合规上过不去方案二人工做摘要最稳但太慢方案三本地部署一个开源模型效果差一点但数据不出内网。我最后选了方案三。很多人觉得本地部署是为了快其实大部分时候本地小模型并不比外部大模型快真正省下来的是合规沟通和等待审批的时间。这个选择本身就是一种效率策略。4.2 部署不难稳定输出才难部署过程本身比我想象的顺利。我用现成的推理框架下好权重做量化封装成一个本地 HTTP 接口。大概两天就通了第一次调用通的时候我还挺兴奋——终于有自己的模型服务了。但接下来一周我都在跟输出不稳定性搏斗。同一个问题它有时候回答很详细有时候只给几个字有时候一本正经地胡说八道。一开始我以为是小模型能力不够后来排查发现是我没注意推理参数温度太高采样随机性太大。把温度从默认值降到 0.1 左右输出质量立刻稳定了一截。另一个坑是流式输出。看起来流式体验更顺滑但对自动处理流程来说它会让末尾截断的概率变高导致 JSON 解析失败。后来我统一改成非流式请求并且要求在回复里固定输出 JSON 格式失败率从差不多 10% 降到 1% 以下。参数初始配置调整后效果温度默认偏高0.1输出稳定输出方式流式非流式JSON 解析失败率下降输出格式自由文本固定 JSON下游处理不再报错4.3 小模型的能力边界该让它干什么不该让它干什么私有化部署最怕的是期望错位。7B 模型写长篇文章、做复杂推理肯定不如大模型。我一开始什么都想让它干摘要、改写、问答、信息抽取结果经常不满意。后来我把场景压缩到三件事文档摘要、关键词提取、文本分类。这三个任务足够简单小模型能稳定胜任。我把这个边界写成了硬性要求每次调用只能做清单里的任务超过范围直接拒绝。这看起来像自我设限但实际效果是——它不会乱来我可以放心把业务交给它跑。模型能力边界划清楚之后维护成本低了很多。4.4 接入日常流程前的脏活清单部署完之后还有一堆脏活接口封装、并发控制、请求日志、超时重试。这些听着和 AI 没关系但恰好是把 AI 当同事用的前提。同事靠不靠谱不只看能力还要看响应是否稳定、出错有没有日志、出问题能不能回滚。模型服务也一样。我列一个清单凡是接到业务流程里的 AI 服务这几项不能省第一统一 API 封装调用方不直接感知模型细节第二并发控制防止突发请求把 GPU 打满第三每个请求都有 trace 日志出错能查到上下文第四超时和重试机制保证单个请求失败不会拖垮整条链路。这些脏活看着不起眼但少了任意一项AI 服务就不具备被纳入日常流程的资格。这一轮的效率账是长线账一次调用省掉一个人读文档摘要的 20 分钟一天跑几十次一个月下来省的时间足够抵消部署和调优的投入。所以我一直觉得私有化部署的效率不在跑得快而在少返工——模型能力够用就行关键是稳定、可观测、可控。5. 半年复盘的四个真相效率不是 AI 给的是流程给的四个项目跑完我对AI 提效的态度从兴奋变成了平常心。这里总结四条规律也是我之后继续用 AI 的原则。5.1 真相一AI 省执行时间不省思考时间四个项目的共同点很明显需求越清晰AI 发挥越稳目标越含糊越容易带人绕远路。我自己整理需求的时间一点没少甚至比以前更多但换来的是执行层面的时间大幅压缩。最划算的姿势永远是你来定边界和标准AI 来填细节和初稿。想靠 AI 偷思考的懒迟早会在返工里还回去。5.2 真相二稳定性压倒一切格式化约束比模型选型更重要输出不稳定的 AI效率是负的。为了让 AI 稳定我花了大量精力在格式化约束、JSON schema、规则清单、温度参数这些看起来特别不性感的细节上。事实证明给 AI 立规矩、给例子比换一个更大的模型管用得多。稳定意味着可预期可预期才是协作的基础。5.3 真相三AI 只有在闭环里才可靠单点 AI 能力再强放在不可控的流程里也容易翻车。我后来把所有 AI 功能都放进同一个结构输入有 schema 校验输出有格式校验中间有重试机制末端有人工复核。这个闭环让 AI 的容错率高很多。AI 可以犯错但闭环兜住错误最终产出才是稳的。这也是为什么有人用 AI 效率翻倍有人用 AI 越用越乱——差的不是模型是流程。5.4 真相四当同事用的是流程设计能力最重要的一点AI 之所以能当同事不是因为它聪明而是因为你愿意把它设计进一个明确的岗位里给它职责、边界、协作接口和复核环节。这需要的不是提示词技巧而是拆解任务、定义接口、设计容错的工程能力。能力越强AI 越能打流程越糙AI 越添乱。最后分享一个我一直保留的小习惯我会给每个和 AI 协作的项目建一个交接文档文件夹里面包含背景说明、约束清单、历史失败案例和成功案例。每次开始新任务我先把这些喂给 AI相当于给新同事做入职培训。这个小习惯看起来麻烦但长期下来能避免大量重复踩坑。如果你也想把 AI 当同事用我建议你从一个小而明确的项目开始先把边界、格式、复核机制定好别一上来就追求全自动。效率的真相不是我一开始以为的AI 帮我干活而是我用流程让 AI 能干成活。
