梳理一下使用ai-ide要注意的点

今天让ai-ide写代码的时候突然发现意图无法对齐了改了好几版这里突然意识到一个点我们写让ai写代码通常分为两种情况1.从0说明情况2.在已有的数据流转结构中写代码这边要着重讲的是第二点在已有的接口的数据流转结构中这个其实如果只是给ai一两句话让他去改代码ai很难改好对于第二点我们要分析好已有的结构然后说在原有的流转逻辑里数据要做到什么程度这样就不会出现ai乱改多改无法对齐意图的问题——在已有代码中用“三明治沟通法”精准修改改了好几版AI还是没理解我的意思。问题出在哪不是AI变笨了是我们的沟通方式错了。一、今天踩了一个坑今天让AI-IDE写代码的时候改了好几版意图始终对不齐。改到第三版时我突然意识到一个问题——我们让AI写代码其实分为两种完全不同的情况从0到1空白项目从零说明需求让AI生成新代码在已有结构中修改现有项目、既有数据流转链路让AI改代码第一种情况AI表现通常不错。真正让人头疼的是第二种。二、为什么一到改老代码AI就“犯糊涂”在场景二里我们习惯性地丢给AI一两句话“把用户ID改成手机号登录。”然后AI可能把你一个好好的函数改成了200行把前端逻辑“顺手”搬到了后端改了A文件顺带重构了B、C、D文件引入了你项目里根本没用的第三方库这不是AI变笨了而是存在三条“鸿沟”鸿沟一上下文缺失AI看不到你项目的完整结构。它不知道userInfo是在哪个环节被转换过、被谁消费。你脑子里有一张完整的数据流地图但AI手里只有你那一两句话。鸿沟二隐含约束没传达你的项目用message.error报错AI用了console.log。你的团队约定用camelCaseAI写了snake_case。这些“常识”你知道但AI不知道。鸿沟三AI有“过度优化”倾向AI看到“修改”这个词默认理解为“优化”或“重构”。它的默认模式是做加法而不是做精准替换。你以为的AI实际理解的“在B环节加个字段”“整个链路重新设计”“沿用现有风格”“用我最擅长的风格”“只改这一个文件”“顺带优化一下相关文件”三、解法“三明治沟通法”经过反复踩坑我总结了一套“三明治沟通法”能极大减少AI乱改、多改的问题。 第一层上层面包锁定修改边界 —— 防“多改”AI最容易犯的错是“好心办坏事”——为了加一个小功能给你重构整个模块。核心技巧用“只修改”、“不要动”、“保持”这些词画出一个物理围栏。❌ 错误说法✅ 正确说法“把用户ID改成手机号登录。”“只修改src/utils/auth.ts中的login方法其他文件保持不动。仅将入参的userId字段替换为phone但不要改动接口返回值的处理逻辑。”“在订单数据里加个折扣字段。”“只改动Service 层的formatOrder函数不改动API 层和 Store 层。”可直接复用的关键词只修改/仅修改其他文件保持不动不要改动/禁止修改沿用现有的 第二层中间肉饼喂入现有流转结构 —— 防“乱改”不要指望AI记得你项目里3个月前的代码。你需要把“数据从哪里来、到哪里去”这个路径给它标清楚。数据流描述模板直接复制使用当前数据流转链路是 [数据来源] → [处理层] → [存储层] → [展示层] - 来源APIxxx接口返回结构为 { ... } - 处理在 [具体函数名] 中做格式化 - 存储存入 [Store/State] - 展示页面通过 [变量名] 直接使用示例“当前数据流转链路是API(/order/detail)→Service层(formatOrder)→Store(Pinia)→页面渲染。目前API返回的items数组里没有折扣字段。请在Service层的formatOrder函数中根据totalPrice和payPrice计算出一个discountRate挂载到返回对象的顶层供页面直接{{ order.discountRate }}使用。”这样AI就知道该在哪个环节插一脚而不是去改API请求头或数据库连接。 第三层下层面包给出约束条件 —— 防“跑偏”AI对“好”的理解和你的项目规范可能完全不同。你需要把“坏样子”和“边界情况”也交代清楚。必须明确的四类约束类别示例语法/框架约束“沿用现有的 Options API 写法不要使用 setup 语法糖。”错误处理约束“沿用现有的message.error不要引入新的 toast 库。”边界情况约束“如果payPrice为空直接返回0不要抛异常。”代码风格约束“变量命名沿用 camelCase不要用 snake_case。”完整示例“请沿用该项目现有的 Options API 写法。错误处理沿用现有的message.error。如果payPrice为空返回0不抛异常。使用lodash的get方法安全取值。”四、三明治法完整示例把三层叠在一起看一个完整的正确示范任务在订单详情页增加折扣率显示。修改范围只修改src/service/order.ts中的formatOrder函数其他文件不动。当前数据流API(/order/detail)→Service层(formatOrder)→Store→页面渲染。具体需求API返回的items数组没有折扣字段。请在formatOrder中根据totalPrice和payPrice计算discountRate payPrice / totalPrice挂载到返回对象的顶层。约束条件沿用项目现有的 CommonJS 语法沿用现有的logger.error记录异常如果totalPrice为 0discountRate返回null不抛异常用_.isNil做空值判断项目已引入 lodash输出要求只输出formatOrder函数的完整代码保留原有注释。五、已经改乱了怎么办急救方案如果你已经和AI对话了好几轮代码越改越乱急救三步走第一步停止当前对话对话越长AI的上下文越混乱。继续对话只会越来越偏。第二步开新会话重新建立干净的上下文不要延续之前的对话历史。第三步用急救模板重新发起直接复制这个模板【任务】在现有逻辑中插入/修改 [功能名称] 【现有代码上下文】贴出关键接口/类型定义 typescript // 粘贴核心的类型定义或接口结构【当前流转路径】[数据来源] → [处理层] → [存储层] → [展示层]【具体需求】在 [具体环节] 做 [具体操作]【硬性约束】只修改 [具体文件/函数]其他不动不准改 [A] 层逻辑不准改 [B] 的数据结构使用 [指定工具] 处理 [边界情况]【输出要求】只输出需要修改的那个函数保留原有注释不要输出其他文件。--- ## 六、一句话总结 **把AI当成一个“执行力极强但方向感极差的新人”。** 你的任务不是“下指令”而是 **“画地图”** —— 把“当前位置”现有代码和“目的地”改后效果中间的路标 函数名、变量名、文件路径、数据流向都标清楚。 **地图画得越细AI跑得越稳。** ## 七、加餐我的提示词自查清单 每次给AI发指令前拿这个清单过一遍 - [ ] 有没有明确 **只改哪个文件/哪个函数** - [ ] 有没有说清楚 **数据从哪里来、到哪里去** - [ ] 有没有告诉 AI **不改什么** - [ ] 有没有说明 **框架/语法风格** 约束 - [ ] 有没有说明 **错误处理和边界情况** 怎么处理 - [ ] 有没有指定 **输出格式**只输出代码 / 带解释 / 只输出修改部分 ## 写在最后 踩了无数次坑才明白**AI不缺写代码的能力缺的是你脑子里那张数据流图。** 我们的任务就是把这张图用文字“画”给AI看。 如果你也有被AI“乱改代码”的经历欢迎在评论区分享你的翻车故事我们一起完善这份避坑指南。 *完*