★ FEATURED ARTICLE 1. 代码生成量是个伪指标我踩过的第一个坑刚接触 AI 编程工具那阵子我跟大多数人一样盯着一个数字看今天生成了多少行代码。编辑器里那个统计面板一刷新几百行下去心里特别踏实觉得效率起飞了。直到有一次我复盘一个两周的功能迭代发现 AI 帮我写了大概四千多行代码但真正合进主干的不到三分之一剩下的要么被我自己删了要么在 review 阶段被同事打回来重写。那一刻我才意识到代码生成量这个指标本质上是在衡量AI 有多能说而不是我有多能干。这个坑的根源在于代码生成是 AI 最容易被观测到的输出而提效是一个端到端的结果。中间隔着理解需求、设计方案、验证逻辑、集成测试、处理边界、维护可读性这一长串环节。生成只是第一环而且往往是成本最低的一环。你让 AI 生成一个函数它几秒钟就吐出来了但你要花十分钟去确认它有没有处理空值、有没有考虑并发、命名是否符合团队规范、依赖的库版本对不对。这十分钟才是真实成本而它不会出现在生成行数里。我后来给自己定了个规矩评估 AI 编程提效先看它帮我省掉了多少确认成本而不是省掉了多少打字成本。打字本来就快一个熟练工程师一天敲不了几千行有效代码瓶颈从来不在手上。瓶颈在脑子里——想清楚要做什么、怎么做、做完对不对。AI 如果只帮你打字那提效非常有限如果它能帮你把想清楚这一步变快那才是真提效。提示如果你现在还在用AI 今天帮我写了多少行来跟团队汇报提效建议尽快换指标。这个数字在管理层眼里看着漂亮但一旦进入真实交付周期它会迅速露馅反而损害你对 AI 工具的信任度。那到底该看什么我摸索下来有几个维度比生成量靠谱得多首次可运行率AI 生成的代码第一次跑就通过的比例、返工轮次一段逻辑平均要跟 AI 来回几轮才能用、上下文切换次数你在 AI 和文档、AI 和终端之间来回跳的频率、review 通过率AI 产出直接过 code review 的比例。这几个指标都指向同一个东西AI 的输出离可直接用有多远。距离越短提效越真。这里有个反直觉的结论有时候 AI 生成得越少提效反而越高。比如你让它只补一个关键的正则、只写一段类型定义、只解释一个报错它输出十几行但你省下了半小时查文档的时间。反过来你让它帮我实现整个模块它输出五百行你花两小时 debug净亏。所以我现在用 AI 编程越来越倾向于小切口、高频次而不是大包大揽。2. 从 Token 消耗看 AI 编程的真实成本结构聊提效绕不开成本而 AI 编程的成本结构和传统认知完全不一样。很多人以为成本就是订阅费一个月固定多少钱用多少都行。但只要你稍微深入一点就会发现真正的成本藏在Token 消耗里而且这个消耗跟你想象的分布完全不同。先解释一下 Token 是什么。你可以把它理解成 AI 的计费颗粒度一段文字被切成若干 Token输入给模型的叫输入 Token模型吐出来的叫输出 Token。通常输出 Token 比输入 Token 贵好几倍。关键在于AI 编程场景下输入 Token 往往远大于输出 Token。为什么因为你要让 AI 理解你的代码就得把相关文件、上下文、历史对话都塞进去。一个中等规模的项目你让它改一个函数它可能要读进去几千甚至上万 Token 的上下文最后只输出几十行代码。我实测过一个典型场景让 AI 帮我重构一个约 300 行的工具类。我把整个文件贴进去加上需求描述输入大概 4000 Token输出 200 Token 左右。按常见定价输出贵、输入便宜但输入量大最后两边成本差不多打平。这意味着什么意味着AI 编程的成本大头不在它写了多少而在你喂了它多少。你喂的上下文越精准单位成本越低你无脑把整个仓库塞进去成本飙升且效果未必好。这就引出一个实操层面的关键技巧上下文裁剪。我现在的习惯是让 AI 改代码之前先想清楚它真正需要看到哪些文件。通常一个函数改动只需要它看到这个函数所在的文件、相关的类型定义、以及一两个调用示例就够了。把无关的模块、测试文件、配置文件排除掉输入 Token 能砍掉一大半而且模型注意力更集中输出质量反而更高。上下文策略输入 Token 量级输出质量适用场景整个仓库全塞极高容易迷失重点几乎不推荐相关文件 类型定义中等稳定日常改函数、加功能单文件 精准需求低高小切口修改、补逻辑只贴报错 相关片段极低高排错、解释另一个容易被忽略的点是对话历史累积。你跟 AI 聊得越久历史越长每一轮请求都会把之前的对话重新算进输入 Token。聊到几十轮之后单次请求的输入成本可能是第一轮的十几倍。所以我的做法是一个任务聊完就开新会话不要把不相关的任务堆在同一个对话里。这既省钱又避免旧上下文干扰新任务。注意不同工具的 Token 计费口径不一样有的把系统提示词也算进去有的对缓存命中打折。别只看单价要看实际账单。我建议每周拉一次用量明细看看钱花在哪类操作上通常会发现闲聊式提问和大上下文重构是两大吞金兽。还有个更隐蔽的成本Token 失效与重试。你在用 AI 编程工具时偶尔会遇到请求失败、会话中断、需要重新登录的情况。每次重来之前的上下文就白喂了得重新贴一遍。这种损耗在统计里看不见但真实发生。我的应对是把重要的上下文比如项目结构说明、关键类型定义存成一个本地片段文件需要时一键粘贴而不是每次手动找。这个习惯帮我省下了大量重复劳动。3. Agent 与 HarnessAI 编程工具链里最容易混淆的两个概念现在 AI 编程工具满天飞Agent和Harness这两个词出现频率极高但我发现很多人把它们混着用甚至以为是一回事。这两个概念搞不清楚你在选工具、搭流程的时候就会走弯路。我用大白话拆一下。Agent中文一般叫智能体核心特征是自主决策。你给它一个目标它自己决定分几步走、每步用什么工具、遇到问题怎么调整。比如你说帮我把这个 bug 修了Agent 会自己去读代码、定位问题、改代码、跑测试、根据测试结果再改这一串动作是它自己串起来的不需要你一步步指挥。Agent 的关键在于循环——感知、决策、行动、再感知直到目标达成或放弃。Harness直译是挽具、框架在 AI 编程语境里它指的是承载和驱动模型的工程外壳。模型本身是个黑盒只会根据输入吐输出。Harness 负责的是怎么把代码上下文组织好喂给模型、怎么解析模型的输出、怎么把输出变成实际的文件修改、怎么调用工具、怎么管理会话和状态。你可以把 Harness 理解成模型的操作系统它不负责思考负责让思考落地。打个比方模型是发动机Harness 是底盘和传动系统Agent 是驾驶员。发动机再强没有底盘传动车动不了没有驾驶员车不知道往哪开。三者配合才是一辆能跑的车。很多工具宣传时把这三个混在一起说导致用户以为买了Agent就万事大吉其实底层 Harness 的工程质量才是决定体验的关键。为什么这个区分对提效重要因为提效瓶颈经常出在 Harness 层而不是模型层。模型能力这几年提升很快但很多工具用起来还是别扭问题往往在于 Harness 做得糙上下文组织得乱、文件修改容易冲突、工具调用不稳定、状态管理一塌糊涂。你换个更强的模型体验可能只提升一点点但 Harness 做得好同样的模型用起来顺畅得多。维度AgentHarness核心职责决策与规划执行与承载关注点做什么、按什么顺序做怎么把决策变成实际动作失败表现方向跑偏、绕圈子动作失败、上下文丢失、文件冲突优化方向提示词、任务拆解、工具集上下文管理、解析鲁棒性、状态持久化用户感知它聪不聪明它顺不顺手我自己的经验是选 AI 编程工具时先看 Harness 再看 Agent。Harness 稳不稳决定了你每天用起来是顺滑还是糟心。一个 Harness 扎实的工具哪怕 Agent 能力一般你手动指挥也能高效干活反过来Harness 拉胯Agent 再花哨也白搭因为它连你的代码都读不准、改不对。具体怎么判断 Harness 好不好看几个细节它怎么处理大文件是整文件重写还是精准 diff、它怎么管理多文件修改会不会互相覆盖、它怎么记住项目结构每次都要重新解释还是能持久化、它怎么处理失败报错清晰还是直接崩。这些细节平时不起眼但日积月累决定了你的真实效率。4. 多 AI 协作别把鸡蛋放一个篮子里但也别开成菜市场现在很多人手里同时用着好几个 AI 编程工具有的是不同厂商的有的是同一厂商的不同模式。多 AI 协作听起来很美实际用起来很容易变成菜市场——这个问一句那个问一句最后自己都乱了。我踩过这个坑后来总结出一套分工逻辑。核心原则是按任务类型分工而不是按心情分工。我现在的做法是把 AI 编程任务分成几类每类固定用某个工具。比如代码补全和行内建议用一个响应快的复杂逻辑设计和重构用一个推理强的报错排查和文档查询用一个上下文理解好的批量机械修改用一个擅长精准 diff 的。固定下来之后我就不用每次纠结这个该问谁直接按类型走效率稳定很多。为什么不能所有任务都用一个工具因为不同工具在 Harness 层的设计取向不同。有的偏向快速补全上下文窗口小但响应快有的偏向深度推理上下文大但慢。你让一个快工具去做深度重构它上下文不够容易断片你让一个慢工具去做行内补全它每次都要想半天体验极差。工具的能力边界和任务的需求要匹配这是多 AI 协作的第一原则。第二个原则是不要让多个 AI 同时改同一份代码。这是血泪教训。我曾经让两个工具分别优化同一个模块的不同部分结果两边都基于旧版本改合并的时候冲突一大堆比我自己改还慢。正确做法是串行一个工具改完、你确认、提交再让下一个工具基于新版本改。或者干脆分文件不同 AI 负责不同文件物理隔离避免冲突。提示如果你用版本控制多 AI 协作时务必勤提交。每完成一个小改动就 commit 一次这样即使某个 AI 改坏了你也能快速回滚不会连累其他改动。第三个原则是保留一个主脑。多个 AI 可以干活但决策权要收在一个地方。我通常把最复杂的架构决策留给自己或者固定用一个推理最强的工具做总设计其他工具只负责执行它拆出来的子任务。这样保证整体方向一致不会出现几个 AI 各干各的、最后拼不起来的情况。还有个实操细节跨工具传递上下文要标准化。不同工具的输入格式、上下文组织方式不一样你从 A 工具复制一段对话到 B 工具经常丢信息。我的做法是维护一份项目上下文摘要用纯文本写清楚项目结构、关键约定、当前任务需要切换工具时直接贴这份摘要而不是复制聊天记录。这份摘要我一般控制在几百字够用又不冗余。5. 异步编程与并发场景下AI 到底能帮多少异步编程是 AI 编程里一个特别能体现提效真伪的场景。同步代码 AI 写得又快又对但一涉及异步、并发、竞态AI 的输出质量就参差不齐了。我专门拿几个异步场景测过结论是AI 在异步编程上能帮你省掉大量样板代码但在正确性上你必须自己把关。先说它能帮什么。异步编程最烦的是样板回调嵌套、Promise 链、async/await 的 try-catch 包裹、超时处理、取消逻辑。这些模式高度重复AI 写得非常熟练。你给它一个同步函数让它转成异步版本它几秒钟就能给你一个结构清晰的版本连错误处理都帮你补上。这部分提效是实打实的我估计能省掉一半以上的打字时间。但问题出在正确性上。异步代码的 bug 往往不是语法错误而是逻辑错误竞态条件、死锁、资源泄漏、顺序依赖。AI 生成的异步代码语法上通常没问题跑起来也不报错但在高并发或者边界情况下可能出问题。比如它可能忘了加锁、可能把 await 放错位置、可能在错误处理里吞掉了异常。这些 bug 不会在简单测试里暴露上线后才炸。我踩过的一个典型坑让 AI 写一个带缓存的异步数据获取函数。它写出来的版本逻辑很漂亮但没处理缓存击穿——多个并发请求同时发现缓存失效会同时去打后端。这个 bug 在低并发下完全看不出来压测的时候才发现后端被打爆。AI 不是不知道这个概念而是它默认按最直接能跑通的方式写不会主动帮你考虑并发边界。所以我的做法是AI 写异步代码我负责补并发防护。具体来说AI 产出之后我会专门检查几个点有没有共享状态需要加锁、有没有可能重复请求、超时和取消有没有处理、异常会不会被吞、资源有没有正确释放。这几个点检查一遍基本能拦住大部分异步坑。异步场景AI 能帮的你必须自己做的同步转异步结构转换、错误包裹确认 await 位置正确并发请求写并发代码框架加限流、去重、防击穿超时取消写超时逻辑确认取消能真正中断错误处理写 try-catch确认异常不被吞、能上报资源管理写释放逻辑确认异常路径也释放还有个经验让 AI 解释它写的异步代码。生成完之后我会让它逐行解释这段代码在并发下的行为它解释的过程中经常自己发现漏洞或者让我发现我没想到的点。这个让它自证的习惯帮我拦下了不少异步 bug。6. 我用来判断AI 编程是否真提效的一套土办法说了这么多最后落到一个实际问题怎么判断 AI 编程对你到底有没有提效我不用那些花哨的指标就用一套土办法简单但管用。第一个办法同一任务对比计时。挑一个中等复杂度的任务比如给某个接口加参数校验你先用传统方式做一遍记录时间再用 AI 辅助做一遍记录时间。注意AI 辅助的时间要算上你写提示词、检查输出、返工的时间不能只算生成那几秒。我做过几次这样的对比发现简单任务 AI 提效明显复杂任务提效有限甚至为负。这个结论让我调整了策略简单重复的活大胆交给 AI复杂设计自己来。第二个办法看返工率。统计一段时间内AI 生成的代码有多少比例需要你修改才能用。如果返工率超过一半说明你给 AI 的任务类型不对或者提示词质量不行。我一开始返工率很高后来发现是因为我总让 AI 做它不擅长的架构设计。调整任务类型后返工率降下来了。第三个办法看你的心流。这个有点主观但很真实。用 AI 的时候你是感觉顺畅、思路连贯还是频繁被打断、要不停切换注意力如果 AI 让你频繁跳出心流去检查、去纠正那它就是在拖后腿哪怕它生成了很多代码。提效的终极标准是让你更专注而不是让你更忙。第四个办法看长期维护成本。AI 生成的代码三个月后你还看得懂吗还能改吗如果 AI 写的东西你当时没细看后来变成黑盒那这个提效是借来的迟早要还。我现在要求自己AI 生成的每一段代码我都要能解释清楚它在干什么。解释不了的要么重写要么删掉。注意别被工具的营销话术带偏。很多工具宣传提效 10 倍那是特定场景下的峰值数据不是你的日常。真实提效通常是 20% 到 50%而且高度依赖任务类型和使用习惯。接受这个现实你才能理性地用 AI而不是被它牵着走。这套土办法用下来我现在的策略很清晰把 AI 当放大器而不是替代品。它放大我的产出但方向和判断还是我来。简单活、样板活、查资料活大胆交给它设计活、判断活、兜底活自己扛。这样用下来提效是真实的而且可持续。7. 一个具体案例从生成 800 行到净省 3 小时的转变讲个我自己的真实案例把前面这些点串起来。有一次我要给一个内部工具加批量导入功能需求是读一个表格文件校验每行数据合法的入库非法的收集错误报告。我第一反应是让 AI帮我实现整个批量导入模块。它很给力生成了大概 800 行代码包含读取、校验、入库、错误收集、日志、进度条看起来面面俱到。结果呢我花了整整一个下午 debug。问题一堆它用的表格库版本跟我项目里的不一致校验规则它自己编了一套跟业务要求对不上入库逻辑没考虑事务中途失败会留脏数据错误报告格式跟现有系统不兼容。800 行代码我最后删了大概 500 行重写了 300 行。净亏。第二次做类似功能我换了策略。我不让它写整个模块而是把任务拆成小块每块单独让 AI 做而且每块我都先想清楚接口和约束。具体拆成读文件我指定库和版本让它只写读取部分、校验规则我把规则写成清单让它逐条实现、入库我指定用事务让它写带事务的批量插入、错误收集我给它现有错误格式让它对齐。每块生成后我立刻检查、测试、确认再进入下一块。这次总共 AI 生成大概 400 行我修改了不到 50 行整个功能从开始到跑通用了大概两小时比我预估的手写时间省了三个小时左右。关键差别在哪第一次我把想清楚的责任也交给了 AI第二次我自己扛了想清楚只让 AI 扛写出来。AI 擅长写不擅长替你想清楚业务约束和系统集成。把这两件事分开提效就真实了。这个案例让我固化了一个工作流先自己拆任务、定接口、写约束再让 AI 逐块实现每块即时验证。这个流程比一句话让 AI 写整个模块慢在前期但快在后期总体净赚。而且产出的代码可维护性好得多因为每一块都是我确认过的。做法AI 生成量我的修改量总耗时可维护性一句话写整模块800 行500 行一下午差拆块 定约束400 行50 行两小时好所以回到标题那句话AI 编程有没有提效不能只看生成了多少代码。生成 800 行可能净亏生成 400 行可能净赚。真正的指标是端到端的时间、返工率、可维护性以及你自己的心流状态。把 AI 放在它擅长的位置把判断和设计留给自己提效才是真的。这个道理我用了大半年才想明白希望你能少走点弯路。
阅读完成 · 觉得有帮助？
