最近带了一个刚入行的同学A做一个小功能模块他把需求丢给我之后转头就让AI助手生成了一整段代码粘进项目里。编译没过他就把报错信息原样贴给AI来来回回跑了七八轮最后还是我过去看了十秒钟——变量名拼错导致类型推断崩了。这个场景我相信很多人都不陌生。AI编程已经从一个新鲜的“玩具”变成了日常开发流程里的默认配置甚至可以说悄悄“内化”成了我们这个行业的基础设施。但问题恰恰出在这里工具越强大使用者的基本功差异就越暴露得明显。会用AI的人半天顶过去一周不会用的人AI越好他的代码越烂。这篇文章想把我在实际工作里总结出来的5条生存法则系统地讲给小白开发者听。它不是教你“怎么让AI帮你把活干完”而是讲清楚“怎么跟AI协作才能让自己真的成长、代码真的可靠”。AI不是说不用而是要拿来当练兵场不能当养老院。1. 别再让AI当“代码生成器”让它当“结对编程的同事”1.1 你给AI的需求颗粒度决定了你代码的上限A同学一开始是这么用AI的——把一句话需求丢过去“写一个用户注册功能”。AI一口气生成几百行看着很完整实际上里面用了公司内部根本没引入的第三方库还顺手把权限校验写得过于粗糙。这种“只见森林不见树木”的回复恰恰是因为提问的颗粒度太粗了。我的建议是把AI当作一个坐在你旁边的资深同事它的代码产出质量取决于你给它看了多少项目上下文、约束条件、接口约定和验收标准。举个例子同样是“实现用户注册”我会这么拆给AI我当前用的语言版本和框架版本是什么比如Python 3.11 FastAPI我们项目里已有的用户表结构是什么主键、唯一索引、字段约束各是什么密码加密必须用项目已有的工具方法不要自行引入新库注册成功之后要发一封验证邮件邮件模板在哪个目录下错误要返回统一的JSON结构格式参照现有的异常处理器。你把这些信息一列AI回复的代码质量会从“看起来能用”变成“真的能跑、能合进项目”。这个差别不是玄学是因为编程里80%的坑都出在上下文不匹配上而不是语法写不出来。提示如果你自己都不知道项目的表结构长什么样那第一步应该是去翻项目里的模型定义文件把它读明白再让AI帮忙写代码。AI不能替你跳过理解这一步它只能帮你加速理解之后的执行环节。1.2 一个“需求翻译”模板让AI回复质量明显提升我在带人时会给一个很简单的提示词框架仿照“用户故事验收条件技术约束”三段式结构。小白开发者可以直接套用需求描述作为[角色]我希望[功能]以便[价值] 验收条件当[输入条件]时系统应该[输出表现] 技术约束项目使用[语言/框架/库]代码放在[模块路径]要求[风格/规范]加上这三段之后AI给出的东西就不再是“一个孤立的功能”而是“一个能嵌入现有体系的小模块”。你甚至可以让它先输出实现思路你确认了思路再让它写代码。其实说白了这就是需求分析能力和任务拆解能力。以前这项能力是老员工花好几年在评审会上练出来的现在AI把“动手写代码”这一步压缩得很小但需求拆解这条基本功反而被放得更大了。你在给AI写提示词的时候本质就是一次迷你版的技术方案评审。2. 让AI先写测试再写功能代码顺序一换麻烦减半2.1 为什么要反着来测试就是需求的“第二份说明书”很多人用AI写完一堆功能代码然后对着屏幕发呆——不敢改不敢删也不知道跑没跑对。这时候再想让AI补测试它往往会顺着现有实现去写验证你有bug它也发现不了测试就变成了摆设。我的习惯是倒过来。先让AI根据你给的验收条件写测试用例跑一遍让它们先失败然后让AI补实现代码去让测试通过。这不是什么新招就是教科书里的测试驱动开发TDD只是现在有了AI这个流程新手也能顺畅执行了。举例来说如果需求是“用户注册时邮箱不能重复”那么就让AI先写一个测试先创建一个用户再用同一个邮箱创建第二次断言第二次必须抛出重复错误。这个测试跑完会失败——因为功能还没写。接下来你让AI根据测试来补实现它就知道目标是什么了补出来的代码也会更聚焦。2.2 让AI补边界条件而不是补“能跑的路径”小白让AI写测试时有个通病只写正常路径。可有效测试的重点恰恰在异常路径上。AI在这一点上反而比人类有优势因为它在训练语料里见过各种千奇百怪的边界你只要明确跟它说“帮我补边界测试”它就能罗列出你可能没想到的极端情况。我个人经常让AI生成结合“正常输入、边界输入、非法输入”三类的测试矩阵比如空字符串、超长字符串、特殊字符、并发重复提交、数据库临时不可用等。让AI先把这些用例列成表格我再删掉不合业务逻辑的剩下的落到测试代码里。不要担心测试写太多会耽误时间。对新手来说有测试保护的代码就像练车时有教练坐在副驾你敢踩油门了敢于频繁重构了代码质量自然就上去了。没有测试的代码就像在急诊科让实习生直接主刀AI给你递什么器械你就用什么场面很容易失控。3. Debug时不喂“现场证据链”AI就是在给你算命3.1 错误信息、期望行为、已做尝试三条信息缺一不可有一次我远程帮一个网友看问题他问“为什么我的程序跑着跑着就崩了”我只能回问他崩溃日志在哪、哪个环节崩的、输入什么数据时崩的。但这来回一问就已经过了大半天了。把同样的场景放进AI里小白就更容易犯这个毛病。很多人把报错一贴就问“怎么办”AI给出的答案常常是“可能是A可能是B建议检查C”。这不是AI笨是它接收到的信息量只够它做模糊猜测。正确的Debug提问公式应该是完整错误信息 期望行为 实际行为 已经尝试过的排查手段 相关代码片段。这五样东西就像侦探来到案发现场需要的监控录像、目击证词、指纹采集和死者背景。你线索给得越全它破案越快。我举个例子让你感受一下两种问法的差别差我这边登录接口报500了怎么修好登录接口POST /login调用后在服务端抛了500完整堆栈是XXX。期望是用户输对密码后返回token实际是每次都报NullPointerException。我检查过前端传参是正常的数据库里这个用户也真实存在。我怀疑是密码校验那段拿到的user对象是null但不确定为什么。相关代码片段XXX。后者这样的信息量AI几乎可以直接帮你锁定问题根因甚至会教你怎么在原码里快速定位到那个可能为null的变量。这条法则本质是在逼着你自己先整理问题很多情况下你在“整理”的过程中就已经自己发现问题了。3.2 遇到AI幻觉时的“取证”技巧让它给证据而不是给答案AI调试还有一个大坑它会一本正经地编造一个不存在的函数名或者推荐一个并非理想的方案。小白没有足够经验时很容易被AI那种自信满满的语气唬住。我的破解方法很简单让AI每一步都给出依据。一旦AI给出了某个判断我会追问一句“你判断这里是并发问题依据是代码里哪一行能把相关片段原样贴出来分析吗”如果它引用的代码片段在你项目里根本不存在那就是幻觉这条建议可以直接扔了。另外如果你按AI的建议改了代码问题反而更多就马上回滚不要让“沉没成本”绑架你。改了一小时还不如没改这不是你的问题是在一开始就没建立验证节点。好的AI协作习惯是每次只采纳一个小修改改完立刻跑测试而不是一口气让它改十个地方。4. 用AI读懂源码和报错逻辑把理解力锁在自己脑子里4.1 让AI帮你解释代码而不是替你“跳过”代码从前小白看开源项目源码打开文件看三分钟就关掉了因为根本看不下去。现在AI可以帮你逐行解释这本来是个特别好的学习场景——但实际很多人用反了直接问AI“这个项目怎么用”然后照着文档复制粘贴完事项目内部发生了什么一概不知。我的建议是源码阅读时把AI当作“陪读翻译”碰到看不懂的函数把原代码贴给它让它用白话解释数据是怎么流动的、每行在干什么。但它解释完你一定要自己顺着代码路径走一遍在关键逻辑处大声说出来或者在注释里写下来“哦这个函数先把参数校验了再调service层最后把结果组装成DTO返回。”这个过程就是从“听懂了”到“真会了”的转变。我见过一个真实的反馈有位新手用AI看懂了一个项目的核心加密流程之后自己画了一张流程图虽然那几个小时很累但之后整个模块出问题他都能迅速判断是大包了还是序列化出错。这种能力的迁移是反复“让AI直接告诉他答案”的用法完全给不了的。4.2 报错也要“带上下文”地读不要让AI替你做归因当你遇到一个陌生报错时比如“TypeError: NoneType object is not iterable”不要急着贴给AI。先自己看三样东西报错指向的是哪一行那一行里哪个变量可能是None那个变量是从哪个函数返回的这三步走完你的问题就从“这个报错什么意思”变成了“为什么某某函数在这个分支下返回了None”后一个问题的含金量明显更高。我敢说走到这一步你已经离正确答案很近AI再帮你补充边界场景分析这个能力就真正长在你身上了。反过来讲如果你永远跳过这三步那就会陷入一天问AI一百次、离了AI一遍代码都跑不通的窘境。AI时代最残酷的真相可能是不该淘汰的是“会提问、会理解、会验证”的人该淘汰的是那些放弃理解的人。好在理解这个动作随时可以重新练起来。5. 第五法则善待AI但绝不交出“方向盘”5.1 用评审者的心态去接受AI的产出而不是当它的小助理最后这条法则对小白来说最难做到因为它反直觉。你可能觉得头顶有大佬兜底很爽但现实是生产环境下出事了没人帮你兜底。所以从一开始就要建立“我做签字复核AI负责起草”的协作边界。如果你完全看不懂AI提交上来的代码就不要让它们进入主分支。这是我对所有新人强调的铁律。看不懂就拆碎了去问AI直到每一块都懂了再往下走。要是项目紧急实在没时间懂那就在代码里标个TODO等任务结束之后专门安排时间回来复盘。欠下的技术债一定要记账不然迟早要连本带利地还。代码评审的时候你可以用这几个问题当检查清单这段逻辑在项目里是否已有现成实现重复造轮子了吗有没有引入新的依赖是否必要异常路径处理了吗如果有人传空值或极端数据会怎样可读性如何三个月后的你能一眼看懂它吗有没有敏感信息被硬编码AI生成的代码在“能跑”这个维度上越来越强但在“合理、安全、可维护”这个维度上还需要你作为评审者去把关。你越能提出深层的修改意见就越说明你真正掌控了这段代码。5.2 你的成长路径从“给AI打杂”到“给AI定方向”这一两年来我身边的初级开发者大致会经历三个阶段。第一个阶段是“人云亦云”AI说什么就是什么代码能现象跑通就觉得完工。第二个阶段开始出现“局部怀疑”在某些反复出错的坑里对AI的回答半信半疑愿意多检查一下了。第三个阶段是你开始给AI布置“高难度任务”的时候——比如让AI帮忙排查并发场景下的潜在竞态条件、设计一套多模块之间的接口协议——它已经变成你手里的工具而不是你的大脑。我特别想对刚入行或者想转行的朋友说别怕AI让你的工作贬值。它淘汰的一直都是“只会复制粘贴、不改一行代码、出了问题两眼一黑”的工作方式。留下来的是那些把AI当成一块高效磨刀石的人他们在一次次与AI的“拉扯”中把阅读能力、排错能力、设计能力和判断能力全给磨锋利了。6. 别忘了跟AI“对答案”让每一次交互都留痕6.1 用“继续追问”而不是“重新开始”来保持对话上下文我在实操中还有个体会很多小白把AI对话当成搜索引擎用问一个得到一个然后又开一个新对话重新问。这样做最大的损失是丢失了上下文AI没法连贯地帮你深入思考。比如你让AI帮你做了个菜单管理模块又发现在菜单权限上需要调整再问一个权限相关的孤立问题AI是不会自动记住前面方案的。我的做法是倾向用同一个会话窗口持续追问当然如果问题主题完全不同就另当别论。保持对话的“连续性”相当于一个项目一个文档后面再去参考或改动时AI总能站在原来的设计语境里帮你完善而不是每次都从一张白纸开始生成一个“看起来差不多但细节跟原设计不搭”的新方案。6.2 建立一个你自己的“AI交互笔记”记录哪些指挥有效、哪些无效最后再分享一个我觉得收益很大的习惯为自己的AI用法建一个笔记文档记录每次有效的提问模板和无效的提问方式。不一定多复杂可能就是几行字“今天让AI重构模块A的拆分类给了接口定义之后回复质量明显提升”“今天直接问加密方案AI给了三个选项但都和项目版本不匹配以后要先告诉它依赖版本”。积累两三个月你回头翻一翻就会发现自己对AI的指挥能力和判断力已经和刚入门时完全不一样了。这套笔记不是给别人看的它是你自己的“AI协作成长记录”。以前我们写开发日志记录代码的变化现在更值得写的是“你与AI协作方式的变化”。你的提问越精准、验证越娴熟、边界感越清晰AI在你手里能发挥出的作用就越超出预期。它可以是帮新手起步的脚手架但能不能变成你职业路上的加速器取决于你愿不愿意握住方向盘而不是坐在副驾上等它开。 
长河君 · 2026/10/22 8:28:49 · 阅读 1.2k AI编程协作生存法则：从需求拆解到代码评审的5个关键实践
最近带了一个刚入行的同学A做一个小功能模块他把需求丢给我之后转头就让AI助手生成了一整段代码粘进项目里。编译没过他就把报错信息原样贴给AI来来回回跑了七八轮最后还是我过去看了十秒钟——变量名拼错导致类型推断崩了。这个场景我相信很多人都不陌生。AI编程已经从一个新鲜的“玩具”变成了日常开发流程里的默认配置甚至可以说悄悄“内化”成了我们这个行业的基础设施。但问题恰恰出在这里工具越强大使用者的基本功差异就越暴露得明显。会用AI的人半天顶过去一周不会用的人AI越好他的代码越烂。这篇文章想把我在实际工作里总结出来的5条生存法则系统地讲给小白开发者听。它不是教你“怎么让AI帮你把活干完”而是讲清楚“怎么跟AI协作才能让自己真的成长、代码真的可靠”。AI不是说不用而是要拿来当练兵场不能当养老院。1. 别再让AI当“代码生成器”让它当“结对编程的同事”1.1 你给AI的需求颗粒度决定了你代码的上限A同学一开始是这么用AI的——把一句话需求丢过去“写一个用户注册功能”。AI一口气生成几百行看着很完整实际上里面用了公司内部根本没引入的第三方库还顺手把权限校验写得过于粗糙。这种“只见森林不见树木”的回复恰恰是因为提问的颗粒度太粗了。我的建议是把AI当作一个坐在你旁边的资深同事它的代码产出质量取决于你给它看了多少项目上下文、约束条件、接口约定和验收标准。举个例子同样是“实现用户注册”我会这么拆给AI我当前用的语言版本和框架版本是什么比如Python 3.11 FastAPI我们项目里已有的用户表结构是什么主键、唯一索引、字段约束各是什么密码加密必须用项目已有的工具方法不要自行引入新库注册成功之后要发一封验证邮件邮件模板在哪个目录下错误要返回统一的JSON结构格式参照现有的异常处理器。你把这些信息一列AI回复的代码质量会从“看起来能用”变成“真的能跑、能合进项目”。这个差别不是玄学是因为编程里80%的坑都出在上下文不匹配上而不是语法写不出来。提示如果你自己都不知道项目的表结构长什么样那第一步应该是去翻项目里的模型定义文件把它读明白再让AI帮忙写代码。AI不能替你跳过理解这一步它只能帮你加速理解之后的执行环节。1.2 一个“需求翻译”模板让AI回复质量明显提升我在带人时会给一个很简单的提示词框架仿照“用户故事验收条件技术约束”三段式结构。小白开发者可以直接套用需求描述作为[角色]我希望[功能]以便[价值] 验收条件当[输入条件]时系统应该[输出表现] 技术约束项目使用[语言/框架/库]代码放在[模块路径]要求[风格/规范]加上这三段之后AI给出的东西就不再是“一个孤立的功能”而是“一个能嵌入现有体系的小模块”。你甚至可以让它先输出实现思路你确认了思路再让它写代码。其实说白了这就是需求分析能力和任务拆解能力。以前这项能力是老员工花好几年在评审会上练出来的现在AI把“动手写代码”这一步压缩得很小但需求拆解这条基本功反而被放得更大了。你在给AI写提示词的时候本质就是一次迷你版的技术方案评审。2. 让AI先写测试再写功能代码顺序一换麻烦减半2.1 为什么要反着来测试就是需求的“第二份说明书”很多人用AI写完一堆功能代码然后对着屏幕发呆——不敢改不敢删也不知道跑没跑对。这时候再想让AI补测试它往往会顺着现有实现去写验证你有bug它也发现不了测试就变成了摆设。我的习惯是倒过来。先让AI根据你给的验收条件写测试用例跑一遍让它们先失败然后让AI补实现代码去让测试通过。这不是什么新招就是教科书里的测试驱动开发TDD只是现在有了AI这个流程新手也能顺畅执行了。举例来说如果需求是“用户注册时邮箱不能重复”那么就让AI先写一个测试先创建一个用户再用同一个邮箱创建第二次断言第二次必须抛出重复错误。这个测试跑完会失败——因为功能还没写。接下来你让AI根据测试来补实现它就知道目标是什么了补出来的代码也会更聚焦。2.2 让AI补边界条件而不是补“能跑的路径”小白让AI写测试时有个通病只写正常路径。可有效测试的重点恰恰在异常路径上。AI在这一点上反而比人类有优势因为它在训练语料里见过各种千奇百怪的边界你只要明确跟它说“帮我补边界测试”它就能罗列出你可能没想到的极端情况。我个人经常让AI生成结合“正常输入、边界输入、非法输入”三类的测试矩阵比如空字符串、超长字符串、特殊字符、并发重复提交、数据库临时不可用等。让AI先把这些用例列成表格我再删掉不合业务逻辑的剩下的落到测试代码里。不要担心测试写太多会耽误时间。对新手来说有测试保护的代码就像练车时有教练坐在副驾你敢踩油门了敢于频繁重构了代码质量自然就上去了。没有测试的代码就像在急诊科让实习生直接主刀AI给你递什么器械你就用什么场面很容易失控。3. Debug时不喂“现场证据链”AI就是在给你算命3.1 错误信息、期望行为、已做尝试三条信息缺一不可有一次我远程帮一个网友看问题他问“为什么我的程序跑着跑着就崩了”我只能回问他崩溃日志在哪、哪个环节崩的、输入什么数据时崩的。但这来回一问就已经过了大半天了。把同样的场景放进AI里小白就更容易犯这个毛病。很多人把报错一贴就问“怎么办”AI给出的答案常常是“可能是A可能是B建议检查C”。这不是AI笨是它接收到的信息量只够它做模糊猜测。正确的Debug提问公式应该是完整错误信息 期望行为 实际行为 已经尝试过的排查手段 相关代码片段。这五样东西就像侦探来到案发现场需要的监控录像、目击证词、指纹采集和死者背景。你线索给得越全它破案越快。我举个例子让你感受一下两种问法的差别差我这边登录接口报500了怎么修好登录接口POST /login调用后在服务端抛了500完整堆栈是XXX。期望是用户输对密码后返回token实际是每次都报NullPointerException。我检查过前端传参是正常的数据库里这个用户也真实存在。我怀疑是密码校验那段拿到的user对象是null但不确定为什么。相关代码片段XXX。后者这样的信息量AI几乎可以直接帮你锁定问题根因甚至会教你怎么在原码里快速定位到那个可能为null的变量。这条法则本质是在逼着你自己先整理问题很多情况下你在“整理”的过程中就已经自己发现问题了。3.2 遇到AI幻觉时的“取证”技巧让它给证据而不是给答案AI调试还有一个大坑它会一本正经地编造一个不存在的函数名或者推荐一个并非理想的方案。小白没有足够经验时很容易被AI那种自信满满的语气唬住。我的破解方法很简单让AI每一步都给出依据。一旦AI给出了某个判断我会追问一句“你判断这里是并发问题依据是代码里哪一行能把相关片段原样贴出来分析吗”如果它引用的代码片段在你项目里根本不存在那就是幻觉这条建议可以直接扔了。另外如果你按AI的建议改了代码问题反而更多就马上回滚不要让“沉没成本”绑架你。改了一小时还不如没改这不是你的问题是在一开始就没建立验证节点。好的AI协作习惯是每次只采纳一个小修改改完立刻跑测试而不是一口气让它改十个地方。4. 用AI读懂源码和报错逻辑把理解力锁在自己脑子里4.1 让AI帮你解释代码而不是替你“跳过”代码从前小白看开源项目源码打开文件看三分钟就关掉了因为根本看不下去。现在AI可以帮你逐行解释这本来是个特别好的学习场景——但实际很多人用反了直接问AI“这个项目怎么用”然后照着文档复制粘贴完事项目内部发生了什么一概不知。我的建议是源码阅读时把AI当作“陪读翻译”碰到看不懂的函数把原代码贴给它让它用白话解释数据是怎么流动的、每行在干什么。但它解释完你一定要自己顺着代码路径走一遍在关键逻辑处大声说出来或者在注释里写下来“哦这个函数先把参数校验了再调service层最后把结果组装成DTO返回。”这个过程就是从“听懂了”到“真会了”的转变。我见过一个真实的反馈有位新手用AI看懂了一个项目的核心加密流程之后自己画了一张流程图虽然那几个小时很累但之后整个模块出问题他都能迅速判断是大包了还是序列化出错。这种能力的迁移是反复“让AI直接告诉他答案”的用法完全给不了的。4.2 报错也要“带上下文”地读不要让AI替你做归因当你遇到一个陌生报错时比如“TypeError: NoneType object is not iterable”不要急着贴给AI。先自己看三样东西报错指向的是哪一行那一行里哪个变量可能是None那个变量是从哪个函数返回的这三步走完你的问题就从“这个报错什么意思”变成了“为什么某某函数在这个分支下返回了None”后一个问题的含金量明显更高。我敢说走到这一步你已经离正确答案很近AI再帮你补充边界场景分析这个能力就真正长在你身上了。反过来讲如果你永远跳过这三步那就会陷入一天问AI一百次、离了AI一遍代码都跑不通的窘境。AI时代最残酷的真相可能是不该淘汰的是“会提问、会理解、会验证”的人该淘汰的是那些放弃理解的人。好在理解这个动作随时可以重新练起来。5. 第五法则善待AI但绝不交出“方向盘”5.1 用评审者的心态去接受AI的产出而不是当它的小助理最后这条法则对小白来说最难做到因为它反直觉。你可能觉得头顶有大佬兜底很爽但现实是生产环境下出事了没人帮你兜底。所以从一开始就要建立“我做签字复核AI负责起草”的协作边界。如果你完全看不懂AI提交上来的代码就不要让它们进入主分支。这是我对所有新人强调的铁律。看不懂就拆碎了去问AI直到每一块都懂了再往下走。要是项目紧急实在没时间懂那就在代码里标个TODO等任务结束之后专门安排时间回来复盘。欠下的技术债一定要记账不然迟早要连本带利地还。代码评审的时候你可以用这几个问题当检查清单这段逻辑在项目里是否已有现成实现重复造轮子了吗有没有引入新的依赖是否必要异常路径处理了吗如果有人传空值或极端数据会怎样可读性如何三个月后的你能一眼看懂它吗有没有敏感信息被硬编码AI生成的代码在“能跑”这个维度上越来越强但在“合理、安全、可维护”这个维度上还需要你作为评审者去把关。你越能提出深层的修改意见就越说明你真正掌控了这段代码。5.2 你的成长路径从“给AI打杂”到“给AI定方向”这一两年来我身边的初级开发者大致会经历三个阶段。第一个阶段是“人云亦云”AI说什么就是什么代码能现象跑通就觉得完工。第二个阶段开始出现“局部怀疑”在某些反复出错的坑里对AI的回答半信半疑愿意多检查一下了。第三个阶段是你开始给AI布置“高难度任务”的时候——比如让AI帮忙排查并发场景下的潜在竞态条件、设计一套多模块之间的接口协议——它已经变成你手里的工具而不是你的大脑。我特别想对刚入行或者想转行的朋友说别怕AI让你的工作贬值。它淘汰的一直都是“只会复制粘贴、不改一行代码、出了问题两眼一黑”的工作方式。留下来的是那些把AI当成一块高效磨刀石的人他们在一次次与AI的“拉扯”中把阅读能力、排错能力、设计能力和判断能力全给磨锋利了。6. 别忘了跟AI“对答案”让每一次交互都留痕6.1 用“继续追问”而不是“重新开始”来保持对话上下文我在实操中还有个体会很多小白把AI对话当成搜索引擎用问一个得到一个然后又开一个新对话重新问。这样做最大的损失是丢失了上下文AI没法连贯地帮你深入思考。比如你让AI帮你做了个菜单管理模块又发现在菜单权限上需要调整再问一个权限相关的孤立问题AI是不会自动记住前面方案的。我的做法是倾向用同一个会话窗口持续追问当然如果问题主题完全不同就另当别论。保持对话的“连续性”相当于一个项目一个文档后面再去参考或改动时AI总能站在原来的设计语境里帮你完善而不是每次都从一张白纸开始生成一个“看起来差不多但细节跟原设计不搭”的新方案。6.2 建立一个你自己的“AI交互笔记”记录哪些指挥有效、哪些无效最后再分享一个我觉得收益很大的习惯为自己的AI用法建一个笔记文档记录每次有效的提问模板和无效的提问方式。不一定多复杂可能就是几行字“今天让AI重构模块A的拆分类给了接口定义之后回复质量明显提升”“今天直接问加密方案AI给了三个选项但都和项目版本不匹配以后要先告诉它依赖版本”。积累两三个月你回头翻一翻就会发现自己对AI的指挥能力和判断力已经和刚入门时完全不一样了。这套笔记不是给别人看的它是你自己的“AI协作成长记录”。以前我们写开发日志记录代码的变化现在更值得写的是“你与AI协作方式的变化”。你的提问越精准、验证越娴熟、边界感越清晰AI在你手里能发挥出的作用就越超出预期。它可以是帮新手起步的脚手架但能不能变成你职业路上的加速器取决于你愿不愿意握住方向盘而不是坐在副驾上等它开。