AI编程实战：从Prompt优化到代码审查，避开那些让你血压飙升的坑
1. 从“AI写代码真香”到“血压飙升”：一个程序员的真实心路
半年前，当我把第一行由AI生成的代码成功运行起来时，那种感觉，就像第一次用上了电动螺丝刀——效率的提升是肉眼可见的。我，一个在代码堆里摸爬滚打了快十年的老程序员，本以为找到了通往“准点下班”的捷径。从简单的工具函数、重复的业务逻辑，到复杂的算法实现，AI编程助手似乎无所不能。它就像一个不知疲倦、知识渊博的实习生，24小时待命，极大地解放了我的生产力。那段时间，我逢人就安利，感觉自己站在了技术浪潮的前沿。
然而，蜜月期总是短暂的。随着我对AI的依赖越来越深，我开始尝试让它处理更复杂、更模糊、甚至更“天马行空”的需求。很快，我就发现，这个“实习生”虽然博学，但有时候的“脑回路”清奇得让人哭笑不得。它不会像人类同事那样，在你提出一个离谱需求时翻个白眼说“这不可能”，而是会一本正经地、用极其复杂的逻辑，去尝试实现一个根本不该存在的功能。这半年里，我遇到的奇葩需求，足以写满一本《AI编程迷惑行为大赏》。今天，我就把这些让我血压飙升的瞬间分享出来，既是吐槽，也希望能给正在或打算深度使用AI编程的朋友们提个醒：AI是强大的工具，但绝不是万能许愿机。用好它的前提，是你要比它更清楚“什么是合理的需求”。
2. “需求描述”的灾难：当人类语言撞上机器逻辑
AI写代码的第一步，也是最重要的一步，就是“需求描述”，也就是我们常说的Prompt。很多人以为，只要把需求“说”出来就行，但恰恰是这一步，埋下了无数奇葩结果的种子。AI对自然语言的理解，是基于概率的“猜测”，而非真正的“理解”。这就导致，同样一句话，在不同语境、不同表述下，AI可能会产生截然不同的解读。
2.1 “我想要一个能自动修复所有Bug的脚本”
这是我遇到的最经典、也最让人无语的需求之一。提需求的产品经理可能只是随口一说，或者抱着“万一实现了呢”的心态。但AI可不会觉得这是玩笑。它真的会尝试去生成代码。
AI的“努力”与现实的荒诞：AI生成的代码，往往会走向几个极端方向。一种是生成一个超级复杂的、试图集成各种静态代码分析工具（如 ESLint, Pylint）和动态测试框架的脚本，其逻辑是“先扫描所有代码，匹配已知的Bug模式，然后尝试应用修复规则”。代码看起来非常“高级”，用了大量的设计模式和反射机制。但稍微有点经验的开发者一看就知道，这根本行不通。因为Bug的成因千奇百怪，一个拼写错误和一个并发死锁，怎么可能用同一套规则修复？另一种更离谱的，是生成一个无限循环，不断重启应用或重新部署，美其名曰“通过重启规避瞬时Bug”。这种代码要是真跑起来，服务器分分钟宕机。
注意：向AI提需求时，必须避免使用“所有”、“永远”、“绝对”这类绝对化和范围模糊的词汇。AI会字面理解并试图实现一个“完美”但不可行的方案。正确的做法是描述一个具体的、可衡量的子问题，例如：“请写一个Python脚本，使用
pylint扫描指定目录下的.py文件，并将所有E（错误）级别的提示输出到报告文件中。” 这样，AI生成的就是一个实用、可落地的工具脚本。
2.2 “把这个C语言文件读写操作，改成能自动理解内容并生成诗歌的”
这个需求混合了技术指令和创造性要求。用户可能有一个做文件操作的C语言代码片段，但他真正的需求是“处理文件中的文本并创作”。AI会困惑于优先级。
AI的缝合怪代码：我见过AI生成的代码，开头是标准的C语言文件打开、读取、关闭操作（fopen,fread,fclose），严谨得像个教科书示例。但紧接着，画风突变，它试图在C语言里调用一个根本不存在的“诗歌生成AI接口”，或者自己硬编码了一套基于简单替换的“诗歌生成规则”（比如把“的”换成“之”，随机插入“啊”、“哦”等感叹词），然后把原始文件内容拆散、重组，输出一段不伦不类、语法不通的文字。整个代码看起来就像给一辆汽车装上了翅膀，并指望它能飞——结构上似乎有道理，但根本原理上就错了。C语言擅长底层IO和性能，但自然语言处理和诗歌创作完全不是它的领域，强行缝合只会产生垃圾代码。
我的处理经验：遇到这种混合需求，必须手动进行“需求解耦”。我会先让AI分别完成两个独立任务：1. “用C语言实现安全的文件读取功能，将内容存储到缓冲区。” 2. “用Python写一个函数，接收一段文本字符串，尝试生成一首五言绝句风格的诗。” 然后，我再自己设计两个模块之间的数据传递方式（比如通过文件或网络）。AI擅长在明确的边界内完成任务，而不是做跨领域的“架构师”。
3. 对“智能”的过度期待：当AI被当成阿拉丁神灯
有些需求，本质上不是技术问题，而是对AI能力的科幻式想象。提出者往往对技术原理了解不深，认为AI“应该”能像人一样思考、推理甚至“悟道”。
3.1 “写一段代码，让我能预测明天哪只股票会涨停”
这是来自“python量化交易策略代码”搜索词背后的典型幻想。很多新手梦想着找到“圣杯”策略，一键致富。AI在接收到这个Prompt后，可能会做两件事：一是生成一段非常复杂的、包含数十个技术指标（MACD, RSI, 布林带等）计算和历史回测的代码，看起来非常专业、高大上；二是可能会在代码注释里“一本正经”地提醒：“股市有风险，投资需谨慎。本策略基于历史数据，不构成投资建议。” 这种代码最大的问题是，它给了使用者一种虚假的“科学性”和“安全感”，但其核心预测逻辑往往是过拟合的，或者基于无效的统计学假设，实盘使用大概率会亏损。
核心问题在于：AI生成的是“代码”，而不是“智慧”或“有效规律”。它可以把各种已知的量化分析方法组合起来，但它无法创造新的、有效的市场洞察。它生成的策略，很可能只是随机噪声的复杂拟合。我曾调试过一个AI生成的“拉格朗日乘数法代码”用于优化投资组合，代码数学上完全正确，但应用于股市这个混沌系统，其前提假设（如收益率分布稳定）根本不成立，结果毫无实用价值。
3.2 “开发一个AI Agent，让它能自动登录我的各个账号，并模仿我发帖互动”
这个需求触及了自动化、身份模仿和平台规则的灰色地带。AI可能会生成使用Selenium或Playwright进行网页自动化操作的脚本，并尝试集成一些NLP模型来生成回复。代码可能会包括处理验证码（建议调用第三方打码平台API）、模拟鼠标移动以绕过反爬机制、以及基于历史数据训练一个简单的语言模型来生成“像你”的文本。
这里潜藏着巨大的风险：
- 法律与合规风险：自动登录和发布可能违反几乎所有网站的用户协议，导致账号被封禁。
- 安全风险：脚本中需要硬编码或存储你的用户名和密码，这是极大的安全隐患。
- 道德风险：制造虚假的互动和人气，本质上是一种欺骗行为。
AI在生成这类代码时，不会考虑这些软性约束，它只关心“技术上如何实现”。作为开发者，我们必须主动踩下刹车。我的原则是：绝对不写也不协助生成用于欺诈、作弊或违反明确服务条款的自动化脚本。对于合理的自动化需求（如企业内部数据采集），也必须在代码中强调合规性，并采用安全的凭据管理方式（如环境变量、密钥管理服务）。
4. 环境与依赖的“黑洞”：AI给的代码跑不起来
这是最常遇到、也最消耗时间的“坑”。AI生成的代码片段本身看起来没问题，但当你满怀希望地复制粘贴进项目，运行npm install或pip install后，迎接你的往往是满屏飘红的错误信息。
4.1 “error: cannot find module @rollup/rollup-linux-x64-gnu”
这个具体的错误信息非常典型。AI在为一个Node.js项目生成构建配置时，可能会推荐或使用某个特定版本的Rollup插件。而@rollup/rollup-linux-x64-gnu这个包，很可能是一个平台特定的原生依赖。AI在生成package.json中的依赖声明时，可能只是从它的训练数据里复制了一个常见的、但未注明平台的包名。
问题根源：AI的训练数据是海量的代码片段，它知道rollup需要某些插件，但它不一定清楚这些插件在不同操作系统（Linux, Windows, macOS）下的细微差别，或者某些包已经废弃、改名或存在严重的版本冲突（即npm has a bug related可能指向的深层问题）。
我的排查与解决流程：
- 锁定环境：首先，我会仔细检查AI给出的全部依赖项和版本号。不再盲目复制整个
package.json，而是只提取核心逻辑代码。 - 手动安装核心库：我会自己运行
npm init -y初始化项目，然后手动安装最核心、版本声明最明确的库，比如npm install rollup@latest。 - 按需添加插件：根据AI代码中实际用到的Rollup插件功能，去Rollup官网或npm仓库查找官方推荐的、维护活跃的插件，并查看其安装说明。例如，如果代码里用了
@rollup/plugin-node-resolve，我就去查这个包的正确安装方式。 - 忽略平台特定错误：像
rollup-linux-x64-gnu这种错误，通常意味着AI混入了不需要你直接安装的底层依赖。解决方案往往是安装通用的rollup包即可，或者使用npm install --ignore-scripts来跳过可能失败的原生编译环节。
经验之谈：把AI生成的依赖列表当作“购物建议清单”，而不是“必须照单全收的处方”。你才是自己项目环境的最终负责人。对于任何依赖，尤其是原生依赖（名称中带-win32,-darwin,-linux,-gnu,-musl等字样的），务必去官方文档核实。
4.2 “Antigravity IDE Agent terminated due to error...”
这个错误信息看起来像来自某个特定的AI编程IDE或插件（如Antigravity IDE）。它反映的问题是：你给AI模型的Prompt（提示）可能触发了其安全或内容过滤机制，被判定为“invalid prompt: your prompt was flagged as potentially violating our usage p...”。
这意味着什么？这意味着你的需求描述（Prompt）中可能包含了一些被AI服务商认为敏感、有害或违反使用政策的内容。这不一定是你有意为之，可能是某些关键词的组合导致的误判。例如，如果你在Prompt中详细描述如何“绕过”某个系统、“破解”某个软件、或生成带有偏见性的内容，就很可能被标记。
如何处理：
- 审查你的Prompt：仔细检查你向AI提出的请求。去除任何可能涉及黑客技术、隐私侵犯、歧视性言论或违法活动的内容。用更中性、更技术化的语言重新表述。
- 分解复杂需求：不要在一个Prompt里塞进太多可能引发歧义的内容。将“写一个既能爬取用户数据又能自动发送营销邮件的脚本”拆分成“设计一个合规的数据采集方案”和“实现一个邮件发送模块”两个独立的、安全的请求。
- 理解AI的边界：当前的AI编程助手是工具，不是“超级黑客”。它们被设计用来协助合法、合规的开发工作。提出在伦理或法律上存疑的需求，不仅会被拒绝，还可能影响你的账号状态。
5. “代码正确但逻辑清奇”：当AI严格遵循了错误指示
有些时候，AI生成的代码语法完全正确，能通过编译甚至能运行，但产出的结果却与你的预期南辕北辙。这是因为AI完美地实现了一个“错误的需求”或采用了一种极其低效、古怪的实现路径。
5.1 “将纯文本（Plaintext）代码转换成图片”
用户可能想要将代码片段（如plaintext代码怎么转换成图片）生成漂亮的语法高亮图片用于分享。一个合理的思路是：利用现有库（如Python的Pygments进行语法高亮，再用PIL或Cairo渲染成图片）。
但AI可能会怎么做？我见过一种令人瞠目结舌的实现：AI生成了一段代码，先将文本字符串中的每个字符转换成其ASCII码，然后将这些ASCII码值作为像素的RGB颜色分量，生成一个像素图！比如字符‘A’（ASCII 65）可能对应像素(65, 65, 65)。最终你得到了一张全是灰色噪点的图片，完全无法辨认原始代码。AI的逻辑是：“你要求把文本‘转换’成图片，我找到了一个将数据映射为图像像素的数学转换方法。” 它严格遵循了“转换”的指令，但完全忽略了“人类可读”这个最根本的隐含需求。
正确的引导方式：必须把隐含需求显式化。Prompt应该这样写：“请用Python写一个函数，输入是一段Python代码字符串，输出是一张PNG格式的图片。要求图片背景为深色（如#282c34），代码有语法高亮（关键字亮色显示），使用等宽字体，并带有适当的边距。” 这样，AI就会去调用正确的图形和语法高亮库，而不是自己发明一种“密码学式”的转换。
5.2 “ConcurrentHashMap computeIfAbsent 的Bug”
这是一个非常具体的陷阱。Java的ConcurrentHashMap.computeIfAbsent方法在JDK早期版本中，如果映射函数（Function）内部又尝试修改同一个ConcurrentHashMap，可能会导致死锁。这是一个经典的并发编程坑。
AI的“教科书式”复现：如果你让AI“写一段使用ConcurrentHashMap.computeIfAbsent的代码”，它很可能会从训练数据中复制一段标准的、看起来正确的示例代码。但这段代码可能恰好就隐含了那个递归调用的死锁条件，而AI并不会主动提示你这个已知的Bug。更让人血压升高的是，当你根据错误栈去搜索时，会发现这个Bug（ConcurrentHashMap computeIfAbsent bug）在开发者社区里讨论得很热烈，但AI在生成代码时并没有把这个“常识”考虑进去。
教训：AI生成的代码，尤其是涉及并发、锁、原子操作等复杂领域的代码，绝不能直接信任并用于生产环境。你必须具备足够的知识去审查代码。对于这类已知的“坑”，最好的做法是在Prompt中主动规避：“请写一个线程安全的缓存类，使用ConcurrentHashMap，但注意避免在computeIfAbsent的映射函数中直接操作Map本身，以防止潜在的死锁问题。” 这样，AI才会生成更安全的实现，比如在函数内部使用局部变量进行计算。
6. 需求的自相矛盾与边界模糊
有些需求本身内部就是冲突的，或者其成功标准模糊不清，这让AI无所适从，只能生成一种“和稀泥”式的、试图满足所有矛盾点的复杂代码。
6.1 “我要一个无限循环，但又不能卡死程序”
这本身就是一个逻辑悖论。无限循环的定义就是永不结束，必然会占用CPU资源。但用户可能想要的是一个“事件循环”或“后台常驻进程”，在无事可做时应该休眠。
AI的折衷方案：AI可能会生成一个带有Thread.sleep(1)或time.sleep(0.001)的循环，并注释说“这样可以降低CPU占用”。但这只是降低了占用率，循环依然在无限执行，并没有解决“不卡死”的深层诉求——用户可能希望主线程还能响应其他操作。更糟糕的实现可能会尝试开一个守护线程跑死循环，但缺乏正确的线程管理和退出机制。
如何澄清需求：你需要和需求提出者（或者自己厘清）真正的意图。是想监听某个端口？还是轮询检查某个文件变化？或者是运行一个定时任务？然后给AI一个精确的指令：“请用Java写一个守护线程，它每隔5秒检查一次/tmp/flag.txt文件是否存在，如果存在则处理文件内容并删除该文件，然后继续等待；当收到中断信号时，该线程需要优雅地关闭。” 这样，AI就能生成基于ScheduledExecutorService的清晰、正确的代码。
6.2 “System Prompt与Function Calling的区别”
这是一个对AI自身工作机制的元问题。当用户提出这个问题时，他可能是在配置像CodeBuddy这样的AI编程助手，想知道system prompt（系统提示）和function cell（可能指函数调用或工具调用）该如何设置。
AI的“循环解释”：如果你直接拿这个问题去问一个代码生成AI，它可能会生成一段关于如何设置System Prompt和Function Calling的说明文本，而不是一段可执行的代码。或者，它可能会误解为你要写一个程序来解析这两种配置，从而生成一堆毫无用处的字符串处理逻辑。这是因为AI分不清你是在问一个“概念性问题”还是在请求一个“实现某项功能的代码”。
精准提问的技巧：对于这类元问题，不应该向代码生成AI提问，而应该向对话或解释型AI（如ChatGPT）提问。如果你确实需要代码，必须将需求具体化。例如：“假设我正在开发一个AI助手框架。请用Python定义两个类：SystemPrompt和FunctionCall。SystemPrompt类包含一个content字符串属性，用于设定助手的行为准则。FunctionCall类应包含name（函数名）、arguments（参数字典）等属性，并有一个execute()方法。再写一个简单的AIAssistant类，演示如何根据SystemPrompt的内容来决定是否调用某个FunctionCall。” 这样，AI就能生成有实际意义的示例代码。
7. 对“自动化测试”与“Bug发现”的误解
很多新手希望AI能彻底替代人工测试，提出诸如“如何更好的发现bug 培训”所隐含的诉求——希望有一套自动化方法能一劳永逸地发现所有缺陷。AI在这方面可以辅助，但不能主导。
7.1 “写一个能自动找到Android 5.1 WebView输入框弹起Bug的测试脚本”
这个需求非常具体（android5.1 webview输入框弹起bug的编号），指向一个已知的系统兼容性问题。用户可能想要一个自动化测试来复现或检测这个Bug。
AI的局限性：AI可以生成使用Appium或UiAutomator写的Android UI自动化测试脚本，模拟点击输入框、检查键盘弹起状态。它甚至可以生成对比截图进行断言。但是，AI无法知道这个Bug在Android 5.1上的具体表现是什么——是键盘根本不弹起？还是弹起后布局错乱？还是导致应用崩溃？这些具体的、需要经验判断的“预期结果”，必须由人来定义。
正确的合作模式：你应该自己先手动复现一遍这个Bug，明确其现象（例如：“在Android 5.1设备上，点击WebView内的输入框，键盘弹起后，整个WebView内容会上移，但视口未跟随滚动，导致输入框被键盘遮挡”）。然后，将这个具体的现象描述给AI：“请写一个Appium测试脚本，用于Android应用。步骤：1. 启动应用并进入含有WebView的页面。2. 定位WebView内的输入框并点击。3. 等待键盘弹起。4. 检查输入框底部相对于屏幕底部的位置，如果其坐标值大于键盘高度，则断言失败，提示‘疑似WebView输入框滚动Bug’。请使用明确的坐标计算逻辑。” 这样，AI才能生成有价值的、可执行的测试代码。
7.2 “Multica缺陷Bug修复小队”式的模糊请求
这听起来像是一个团队或项目的名称，但作为需求提给AI，则过于模糊。AI可能会将其理解为一个“团队协作修复Bug”的流程管理工具需求，从而生成一套包含Bug提交、分配、状态跟踪的简单Web应用代码，甚至包括用户角色（管理员、开发、测试）权限管理。这显然与提问者（可能只是想了解这个“小队”或寻找相关工具）的真实意图相去甚远。
关键点：AI需要明确、具体的指令。如果你想了解一个概念，就去问对话AI。如果你想要代码，就必须描述清楚这个软件需要具备哪些具体功能，例如：“开发一个简单的内部Bug管理面板前端，使用React，需要能显示Bug列表（ID、标题、状态、负责人），并且测试人员可以点击按钮将Bug状态从‘待处理’改为‘已修复’。” 模糊的需求只会得到跑偏的结果。
8. 工具链与环境的“想当然”
AI经常假设你拥有一个“标准”的、配置完善的开发环境，但现实往往骨感。
8.1 “在Anaconda Prompt里运行这段代码”
Anaconda Prompt只是一个在Windows上激活了特定Conda环境的命令行终端。AI生成的代码，如果是针对Linux/macOS的（例如包含#!/bin/bashshebang，或使用了wget、curl的特定参数），直接复制到Anaconda Prompt里运行大概率会报错。
我的实践：当AI给出命令行操作时，我会特别注意其平台相关性。对于包安装指令，我会将apt-get install（Debian/Ubuntu）转换为conda install或pip install。对于Shell脚本，我会评估其逻辑，然后用批处理（.bat）或PowerShell脚本重写，或者在Windows上直接使用Git Bash来运行。永远不要假设AI生成的命令是跨平台兼容的。
8.2 “Lightly在线编程官网”与“星露谷物语Python编程网站”
这些搜索词反映了一种需求：希望在不配置本地环境的情况下进行编程或学习。AI可能会推荐一些在线的IDE或代码托管平台。但是，如果你要求AI“写一个在Lightly上能运行的爬虫”，它生成的代码可能会缺少必要的依赖声明（因为在线环境可能预装了库，也可能没有），或者使用了无法在浏览器沙箱中运行的功能（如文件系统访问）。
环境声明的重要性：在向AI提需求时，如果目标环境特殊，一定要在Prompt中声明。例如：“请写一个用于浏览器环境的JavaScript代码，从当前网页中提取所有图片的URL，并避免使用Node.js特有的fs或http模块。” 或者“请写一个Python脚本，确保其只使用Python标准库，因为我要在一个纯净的在线编辑器中运行它。” 这能极大地提高生成代码的可用性。
9. 版本与兼容性的“时空错乱”
AI的训练数据混合了不同年代、不同版本的代码，它可能会给你一个“复古”的解决方案。
9.1 “SHA-2代码签名补丁”与老旧系统
这个需求通常出现在需要为旧版Windows（如Win7 SP1）打补丁以支持现代代码签名证书的场景。AI可能会从知识库中找到微软官方KB文档编号，甚至给出下载链接。但如果你让它“写一个脚本自动检测并安装此补丁”，它生成的PowerShell脚本可能会使用一些在新版本Windows PowerShell中才有，而旧系统上没有的cmdlet，导致脚本在目标机器上无法运行。
处理老版本兼容性：对于针对特定旧环境的需求，必须在Prompt中锁定技术栈的版本。“请写一个适用于Windows 7 SP1 默认PowerShell 2.0环境的脚本，检查系统是否已安装KB4474419补丁，如果未安装，则从微软官方服务器下载并静默安装。” 这样AI才会使用最基础的Get-Hotfix、Net.WebClient等兼容性好的命令。
9.2 “人狗大作战Python代码2023”与过时的库
AI生成的代码可能会引用一个2023年很流行但2024年已经停止维护的Python游戏库，或者使用了某个API的旧版本接口。当你按照它的指示pip install时，可能会发现库已不存在，或者安装后与新版本的Python解释器不兼容。
策略：对于时间敏感的项目，在Prompt中指定核心依赖的版本范围是一个好习惯。“请使用pygame库（版本>=2.5.0）编写一个简单的2D游戏‘人狗大作战’的演示，玩家控制一只狗躲避人类的追捕。” 同时，对于任何AI推荐的库，在正式集成前，花几分钟去PyPI或GitHub上查看其最新更新日期、维护状态和开源协议，这是一个必须养成的习惯。
10. 当AI“自由发挥”：脱离控制的“创新”
有时候，AI在理解了基本需求后，会尝试“锦上添花”，加入一些它认为更好、但完全多余甚至有害的功能。
10.1 “一键清理.bat代码”里的“高级”功能
用户可能只想要一个简单的批处理脚本，删除临时文件、清空回收站。但AI为了让它更“强大”，可能会加入以下“惊喜”：
- 强制结束进程：加入
taskkill /f /im命令来结束浏览器、办公软件等进程，可能导致数据丢失。 - 修改系统设置：自动修改电源选项、禁用系统还原点，美其名曰“优化系统”。
- 删除可能重要的日志文件：扩大清理范围到
C:\Windows\Logs，可能影响问题排查。
教训：对于系统级操作，尤其是批处理、Shell脚本，必须逐行审查AI生成的代码。明确禁止AI执行危险操作。Prompt可以这样写：“请写一个安全、保守的Windows批处理脚本，仅清理当前用户的Temp文件夹和浏览器缓存（已知路径），并在执行每一项删除前，用echo命令显示将要删除的内容。绝对不要包含强制结束进程、修改注册表或删除系统目录文件的命令。”
10.2 “AI一键脱装下载国外下载”背后的伦理雷区
这个搜索词本身可能指向一些涉及版权、隐私或伦理问题的工具（如AI换脸、去衣等）。即使你只是好奇地问AI“这是如何实现的”，它生成的解释性代码或原理描述，也可能会触及一些灰色地带的技术细节（如使用特定的人体分割模型、图像修复模型）。
必须坚守的底线：作为开发者，我们不仅要对自己写的代码负责，也要对自己探索的技术方向负责。我坚决避免生成、传播或深入研究任何用于侵犯个人隐私、制作虚假信息或违反法律法规的AI技术代码。当Prompt滑向这个边缘时，最好的做法是主动停止，并重新思考技术学习的正当用途。AI可以生成很多代码，但用它来做什么，决定权永远在人类手中。
回顾这半年的“血压飙升”之旅，我的核心体会是：AI编程助手是一个能力超强的“副驾驶”，但它没有“常识”，没有“品味”，也无法理解需求的“合理性”和“边界”。它的强大，建立在你清晰、准确、专业的指令之上。你的角色，从一个纯粹的“编码者”，转变成了一个“需求分析师”、“架构师”和“代码审查员”。你需要更善于拆解问题、定义边界、预判陷阱。那些奇葩需求，与其说是AI的错，不如说是我们人类自己模糊、矛盾、不切实际的想法的镜子。用好AI的关键，不在于学习多么复杂的Prompt技巧，而在于回归软件工程的基本功：把问题想清楚，把需求讲明白。当你能做到这一点时，AI才会从“血压飙升器”变成真正让你如虎添翼的神兵利器。