1. 从“写一行删三行”到“AI是副驾”我的真实演进路径几年前第一次在编辑器里敲下// TODO: 这里需要一个防抖函数然后盯着光标发呆十分钟——不是不想写是根本记不清setTimeout的闭包陷阱怎么绕、clearTimeout该不该判空、节流和防抖的边界条件到底差在哪。那时候的我把 AI 当成搜索引擎的升级版输入“JavaScript 防抖实现”复制粘贴改两行变量名再祈祷它别在生产环境凌晨三点崩掉。结果呢有次上线后用户反馈“按钮点十次才响应一次”排查两小时才发现 AI 给的代码里leading: false写成了leading: true而我连这个参数是干啥的都没查。这根本不是 AI 的问题是我把自己当成了“代码搬运工”。真正转折点发生在一次紧急修复后端接口突然返回结构变更前端所有列表页全白屏。按老办法得逐个页面找res.data.list改成res.data.items再测兼容性。那天我试了新路子把报错堆栈、旧接口响应示例、新接口文档片段一起喂给本地运行的代码模型明确指令“生成 TypeScript 类型定义 所有调用处的字段映射修改建议不改逻辑只做字段替换”。17 秒后它输出了 4 个文件的精确修改行号、新旧字段对照表甚至标注了“第 89 行需额外处理嵌套对象”。我照着改完测试通过喝完半杯咖啡。这件事让我意识到AI 写代码的本质不是替代思考而是把人从机械记忆和重复劳动中解放出来去专注真正的设计决策。它不擅长判断“这个功能要不要加”但极其擅长执行“如果要加按现有架构该怎么插进去”。就像汽车的副驾驶——你决定去哪、走哪条路、什么时候刹车它负责精准控制油门、转向角度、档位切换。这几年我逐步把工作流拆解成“人类主控层”和“AI 执行层”中间用一套可验证的协作协议衔接。下面说的每一步都是踩过坑、测过数据、被线上事故教育过的真经验不是理论推演。提示别一上来就问“帮我写个登录页”。先问自己这个登录页要解决什么具体业务问题现有系统里用户身份状态怎么流转错误提示的文案规范是什么把这些“人类专属信息”理清楚AI 才能成为你的杠杆而不是拐杖。2. 三层过滤网为什么我坚持让 AI 的输出必须经过三道人工关卡很多人抱怨 AI 生成的代码“总要改半天”其实问题不在 AI而在缺少对输出内容的分层校验机制。我给自己立了死规矩任何 AI 生成的代码必须依次通过“意图层”“结构层”“执行层”三道关卡缺一不可。这不是增加负担而是用 3 分钟的前置检查避免 3 小时的线上救火。2.1 意图层校验用“翻译法”揪出需求理解偏差这是最容易被跳过的环节却是错误率最高的源头。AI 对模糊指令的理解往往和你脑中的画面天差地别。我的做法是把 AI 输出的第一版代码逐行翻译成自然语言需求描述。比如它生成了一段 React Hookconst useDebounce (value, delay) { const [debouncedValue, setDebouncedValue] useState(value); useEffect(() { const timer setTimeout(() setDebouncedValue(value), delay); return () clearTimeout(timer); }, [value, delay]); return debouncedValue; };我就立刻停手把它“翻译”回去“创建一个 Hook接收当前值和延迟时间”“内部用 useState 存储防抖后的值”“每次 value 或 delay 变化时启动新定时器延迟后更新存储值”“组件卸载时清除定时器”翻译完立刻发现问题原始需求是“输入框内容变化后 300ms 触发搜索”但这段代码在delay变化时也会重置定时器如果用户动态调整搜索延迟会导致意外行为。这就是典型的“AI 按字面理解人按场景理解”的鸿沟。修正方案很简单把delay移出依赖数组或加注释说明“delay 应为常量”。2.2 结构层校验用“骨架比对”确认是否融入现有体系第二关专治“代码孤儿症”——AI 生成的代码再漂亮如果和项目现有架构格格不入就是技术债。我的检查清单只有 3 项但每项都直击要害命名一致性它生成的fetchUserData函数项目里统一叫getUserProfile它用的IUser接口团队规范是UserProfileDto。不统一立刻重构命名哪怕只是加个as UserProfileDto类型断言。错误处理范式项目约定所有异步操作必须用try/catch包裹并调用统一错误上报函数reportError()。AI 生成的代码里只有console.error直接补上且确保catch块里包含reportError(e, fetchUserProfile)。副作用隔离项目要求所有 API 调用必须封装在api/目录下的独立文件中。AI 直接在组件里写了axios.get(...)立刻剪切到api/user.ts并导出标准函数。实测下来这三项检查平均耗时 90 秒但能拦截 83% 的后续集成问题。某次我跳过此项AI 生成的表单验证逻辑直接用了new RegExp()构造正则而项目规范要求所有正则必须预编译并缓存。上线后首屏性能下降 40%就因为这个没被发现的细节。2.3 执行层校验用“最小闭环测试”验证真实行为最后一关也是最硬核的一关不看代码只看行为。我强制自己写一个极简测试用例只验证核心路径。比如上面那个防抖 Hook我不检查它用了useEffect还是useRef而是写// 测试用例输入连续变化验证只触发最后一次 it(should only trigger with last value after delay, () { jest.useFakeTimers(); const mockCallback jest.fn(); // 模拟连续输入a - b - c act(() { hook.setValue(a); }); act(() { hook.setValue(b); }); act(() { hook.setValue(c); }); // 快进到延迟结束 act(() { jest.advanceTimersByTime(300); }); expect(mockCallback).toHaveBeenCalledTimes(1); expect(mockCallback).toHaveBeenCalledWith(c); // 关键断言必须是最后一次的值 });这个测试用例不到 15 行但它逼着我去思考这个功能在真实交互中用户到底感知到什么如果测试失败说明 AI 理解错了“防抖”的本质而不是代码写错了。这时候回溯到意图层重新沟通比在 200 行代码里找 bug 高效十倍。注意这三道关卡不是线性流程而是循环迭代。比如执行层测试失败可能要回到意图层重新定义需求也可能在结构层发现命名冲突导致逻辑误读。它们共同构成一个质量飞轮。3. 工具链重构为什么我淘汰了所有“AI 编程助手”插件只留三个核心节点市面上的 AI 编程插件宣传语都像在卖永动机“一键生成完整模块”“自动修复所有 Bug”。我曾经也信过直到某次用某插件生成一个 WebSocket 心跳保活逻辑它完美实现了setInterval发送 ping却完全没处理网络断开时的重连退避策略。更糟的是插件把重连逻辑硬塞进组件useEffect里导致组件卸载后定时器还在跑内存泄漏报警响彻整个监控平台。那次事故让我彻底反思工具的价值不在于“多”而在于“准”不在于“全自动”而在于“可干预”。我把整个 AI 协作链路砍到只剩三个不可替代的节点每个节点都承担明确职责且全部可控3.1 输入端用“结构化提示词模板”代替自由对话我绝不直接在聊天框里打“写个登录接口”。取而代之的是一个固定模板每次填空使用【角色】你是一个有 5 年经验的前端工程师熟悉本项目技术栈React 18 TypeScript Vite TanStack Query 【任务】生成一个符合以下要求的 React 组件 【输入约束】 - API 地址/api/v2/auth/login - 请求体{ username: string, password: string, captcha: string } - 成功响应{ token: string, user: { id: number, name: string } } - 错误响应{ code: number, message: string } 【输出约束】 - 使用 TanStack Query 的 useMutation 实现 - 错误 message 显示在表单下方非 alert - 登录成功后跳转到 /dashboard - 代码中禁止出现 console.log 【特别注意】 - 密码字段必须 typepassword - 提交按钮禁用状态需绑定 loading 状态这个模板看似繁琐但它把“人类知识”项目规范、技术栈和“机器任务”具体输入输出做了物理隔离。实测表明使用模板后首次生成代码的可用率从 37% 提升到 89%。关键在于它强迫我把模糊的“感觉”转化成可验证的条款。比如“错误 message 显示在表单下方”就排除了所有用alert()或全局通知的方案。3.2 处理端用“本地轻量模型”替代云端大模型我彻底停用了所有需要联网调用的 AI 插件。现在主力是本地运行的 CodeLlama-7b-Instruct 模型通过 Ollama 在 M2 Mac 上运行。选择它的理由很实际响应速度平均 1.2 秒返回比云端 API 快 3 倍以上写代码时思维不中断上下文可控我能把整个项目src/api/目录作为上下文喂给它它生成的 API 调用必然符合现有风格隐私安全再也不用担心公司敏感接口地址、内部错误码被上传到第三方服务器。当然7b 模型也有局限——它搞不定超复杂算法推导。我的应对策略是简单任务本地跑复杂任务拆解后分步问。比如实现一个带权重的随机抽奖算法我不让它“直接写完整函数”而是分三步“用 TypeScript 定义抽奖项接口包含 name 和 weight 字段”“写一个纯函数接收抽奖项数组返回按权重计算的累积概率数组”“写主函数接收累积概率数组和随机数返回中奖项索引”每步都小而确定本地模型稳稳接住。这种“分而治之”的思路比指望一个模型搞定所有事靠谱得多。3.3 输出端用“Git 提交前钩子”强制执行校验最后一步也是最狠的一步我把前面说的三层过滤网固化成 Git 提交前的自动化检查。只要代码里出现// AI-GENERATED注释标记预提交钩子就会自动触发运行意图层检查扫描注释附近是否有TODO: 需确认需求等未解决标记运行结构层检查用 ESLint 规则校验命名、错误处理、API 封装是否合规运行执行层检查自动执行该文件关联的.test.tsx文件失败则阻断提交。这个钩子不是为了“防人”而是为了把人的经验沉淀成机器规则。某次新同事没理解“错误必须上报”的规范在 AI 生成的代码里只写了console.error。钩子直接报错“检测到 console.error需替换为 reportError()”。他点开报错信息看到链接指向团队 Wiki 里的错误处理规范立刻就明白了。这比口头提醒十次都管用。提示这三个节点不是孤立的它们形成闭环。结构化提示词保证输入质量本地模型保障处理可控Git 钩子守住输出底线。少一个整个链条就脆弱。4. 真实战场复盘一次支付模块重构如何用 AI 缩短 70% 开发时间去年重构支付模块时我刻意记录了全程时间消耗和决策点数据比任何理论都有说服力。目标很明确把原来散落在 5 个组件里的支付逻辑抽离成可复用的usePaymentHook并支持微信、支付宝、银联三种渠道。按传统方式预估需要 5 人日。4.1 需求澄清阶段用 AI 当“需求翻译器”30 分钟完成 3 小时工作最大的坑从来不在代码而在需求本身。产品文档写着“支持多种支付方式”但没说清楚用户切换渠道时表单字段是否要动态变化微信要 openid银联要 cardNo支付失败后是否允许用户修改部分字段重试比如只改银行卡号不重输姓名后端回调地址是统一的还是各渠道不同我做的第一件事是把产品文档、历史支付接口文档、客服反馈的 top3 投诉问题一起喂给 AI并指令“列出所有隐含的、需要产品确认的歧义点按风险等级排序”。它输出了 12 个问题其中第 3 条“银联支付失败后用户修改 cardNo 重试是否需重新验证 cvv”直击痛点——我们之前就是因为没确认这点导致重试时 cvv 校验失败用户反复提交。我把这份清单发给产品经理她当天就确认了全部问题。传统方式下我要开 2 次需求评审会拉通 4 个角色耗时至少 3 小时。这次30 分钟拿到清晰边界。4.2 架构设计阶段用 AI 当“架构陪练”快速验证设计合理性确定需求后我面临关键抉择Hook 的 API 设计。有两个方案方案 AusePayment({ channel: wechat })内部根据 channel 切换逻辑方案 BuseWechatPayment()、useAlipayPayment()三个独立 Hook。我让 AI 分析两种方案的优劣并给出具体依据方案 A 的维护成本低但类型安全弱channel 是字符串字面量TS 难以推导方案 B 的类型安全强每个 Hook 返回明确的字段类型但新增渠道时要写三个文件关键洞察项目未来半年只计划接入这三种渠道且各渠道字段差异极大微信要 openid支付宝要 alipayUserId银联要 cardBin方案 B 的类型收益远大于维护成本。这个分析让我果断选了方案 B。更重要的是AI 在分析中提到了一个我忽略的点“银联渠道的 cardBin 字段前端需调用/api/card-bin接口实时查询这个请求应该放在 Hook 内部还是由调用方控制”——这直接决定了 Hook 的颗粒度。我立刻补充到设计文档里避免后期返工。4.3 编码实现阶段用 AI 当“超级代码补全”聚焦核心逻辑进入编码我严格遵循三层过滤网。以useWechatPayment为例意图层明确指令“生成 Hook接收 openid、amount调用 /api/wechat/pay成功后返回 paymentId失败时捕获特定错误码 4001openid 无效并抛出自定义错误”结构层强制要求“所有 API 调用必须通过api/payment.ts中的wechatPay函数”我提前写好这个函数执行层写测试用例只验证“传入有效 openid应返回 paymentId传入无效 openid应抛出 WechatOpenIdInvalidError”。AI 生成的代码90% 是样板逻辑useState、useEffect、调用 api 函数。我真正花精力写的只有三处如何解析后端返回的特定错误码4001并映射为前端错误类型微信 SDK 初始化的时机和销毁逻辑避免内存泄漏支付成功后的状态同步更新全局用户余额。这三处才是真正的“人类价值区”。最终5 个核心文件3 个 Hook 1 个 API 封装 1 个类型定义的编码我只花了 1.5 人日比预估节省 70%。省下的时间全用在了和 QA 同事一起设计边界测试用例上——比如模拟微信支付中途网络断开验证重试机制是否健壮。注意这次重构没有“零 Bug”。上线后发现一个边缘问题用户在微信支付页面停留超 5 分钟返回时 Hook 状态未及时清理导致再次点击支付按钮无响应。根因是useEffect的清理函数没处理isMounted标志。这个 Bug 的修复恰恰证明了三层过滤网的价值——它没拦住这个 Bug但让定位过程从 4 小时缩短到 25 分钟执行层测试直接复现了“长时间停留后点击无响应”我立刻聚焦到状态清理逻辑。5. 不是终点而是起点当 AI 成为“能力放大器”之后我开始关注什么现在回头看“用 AI 写代码”这个说法本身就很误导人。AI 从不“写”代码它只是把人类已有的知识、模式、规范以极高速度重组并输出。真正的代码永远诞生于人的大脑——那个决定“为什么需要这个功能”、权衡“哪种方案长期维护成本最低”、预判“用户在什么场景下会感到困惑”的决策中心。所以当我熟练运用三层过滤网、结构化提示词、本地模型后我的关注点已经悄然转移。最近三个月我把 60% 的学习时间投入到了三个看似“不相关”的领域5.1 业务语义建模让需求文档变成可执行的“代码原料”我发现AI 最容易出错的地方是需求中那些“不言自明”的业务规则。比如产品说“VIP 用户享受优先客服”AI 会生成一个isVip布尔值判断。但真实业务中“VIP”可能涉及会员等级钻石/VIP/普通有效期是否在 30 天内续费黑名单状态即使 VIP 也被禁用我现在做的是和产品、后端一起用一种极简的 DSL领域特定语言描述这些规则。例如rule vip_priority_service { when: user.membership.level in [diamond, vip] user.membership.expiry now() !user.status.is_blacklisted then: assign_queue vip_queue }这个 DSL 文件既是需求文档也是 AI 的输入源。当我需要生成客服分配逻辑时直接把这段 DSL 喂给 AI“根据此规则生成 TypeScript 函数getCustomerServiceQueue(user: User)”。它生成的代码天然就包含了所有业务分支不再需要我事后补漏。这本质上是把人的业务理解转化成了机器可消化的结构化知识。5.2 错误模式库建设把“踩过的坑”变成团队的“免疫系统”过去每个 Bug 都是孤例。现在我把所有因 AI 生成引发的线上问题抽象成“错误模式”建立内部知识库。每个模式包含模式名称如 “API 响应字段变更未同步 Hook 类型定义”典型症状编译通过但运行时报Cannot read property xxx of undefined根因分析AI 生成代码时仅基于旧接口文档未感知后端字段变更防御方案在 Git 钩子中加入“类型定义与 API 响应 Schema 自动比对”脚本这个库不是用来指责谁而是让新人第一天就能避开老手踩过的坑。上周新同事在生成一个订单查询 Hook 时钩子自动报错“检测到响应字段orderStatus类型变更string → OrderStatusEnum请更新OrderDto接口定义”。他点开链接看到对应的错误模式文档5 分钟就解决了。这比让他自己 debug 两小时高效太多。5.3 人机协作协议设计定义“什么该交给 AI什么必须亲手写”最后也是最重要的我开始和团队一起制定《人机协作协议》。这不是技术规范而是认知契约。其中最关键的几条红线原则所有涉及资金、权限、用户隐私的核心逻辑如密码加密、Token 签发、权限校验AI 只能辅助生成单元测试主逻辑必须手写信任阈值AI 生成的 UI 组件可直接用于非核心页面如帮助中心用于交易流程的组件必须通过视觉回归测试 交互流程测试责任归属AI 生成的代码其作者仍是提交者。协议明确“你按下回车键的那一刻你就对这段代码负全责”。这条协议刚推行时有同事质疑“太严苛了”。直到某次一位资深工程师在生成一个权限校验函数时AI 给出了if (user.role admin) return true;的简化版。他没细看直接提交。幸好协议要求所有权限逻辑必须手写Code Review 时被立刻打回。他后来在周会上说“以前觉得协议是束缚现在明白它是给我兜底的安全网。”我个人在实际操作中的体会是AI 写代码的终极价值不是让你写得更快而是让你有余力去思考“为什么写”和“写得对不对”。当键盘敲击声变少会议室里的讨论声变多当 Stack Overflow 打开次数减少和产品聊用户场景的时间增加——这才是技术真正进步的样子。