最近我在收拾自己那台常开的云服务器时突然冒出个念头能不能做个“云资源开关”一键把不需要的实例全部停掉省点成本、省点心。说实话项目一开始我心里特别有数——就是一次接口调用加一个按钮撑死一个下午的事。结果我打开AI辅助编码工具翻出那天的对话记录再看自己都乐了我只说了句“帮我做一个管理云资源的开关工具”等它跑完出来的是一整套云平台用户注册、权限角色、审计日志、费用报表、资源组隔离全齐了。我当时第一反应是我是来换灯泡的你把我家整栋楼的弱电系统重新布了一遍线。后来冷静下来把这件事从头到尾复盘了一遍发现它特别有代表性。今天就把这段经历掰开揉碎了讲一讲AI为什么会这样“过度创作”以及咱们怎么把它拉回正轨让它老老实实把那个“开关”做出来。1. 需求明明很简单问题到底出在哪1.1 云资源开关到底是个什么场景先把这个需求本身说清楚不然很多人会觉得“这有什么好讲的”。云资源开关本质上就是给云上的计算资源装一个远程电源键。常见场景是你有一台或几台云主机定期跑点脚本或者做个临时验证真正持续使用的时间每天只有一两个小时其他时候机器开着就是在烧钱。GPU实例更是这样按量付费的显卡机器一小时几十块钱忘记关机睡一觉账单能让你清醒一整天。我当时的情况是手里有一台常年运行的云主机跑一些定时任务还有一台按需启动的GPU实例用来验证一些深度学习模型。问题很明显GPU实例不是每天都得开但每次手动去网页控制台点“启动”等状态变绿再去登录服务器跑命令用完又得记得回来关。这种操作低频、机械、容易忘。我要的“云资源开关”就是能在一个地方看到这台实例现在是开机还是关机点一下按钮能启动再点一下能停止最好有个清晰的状态提示。这个需求有几个天然特点使用人只有我自己不需要多人协作操作对象就那一两个实例不需要批量管理调用频率极低一天最多一两次根本谈不上性能整个过程不需要给其他人看界面丑一点没关系能点就行。用一句话总结我要的是一个“自家用的电灯开关”不是“整栋楼的智能照明系统”。1.2 一句话需求导致的“AI脑补”问题就出在我给AI描述需求的方式上。我当时在对话框里写的大意是我想做一个云资源开关用来管理我的云服务器可以一键启动、停止最好有前端页面。这句话在人类听来意图挺明确重点在“开关”。但AI不是人类它会把这句模糊指令拆成自己能理解的“语义树”然后顺着最可能的路径一路生成下去。结果就是——“管理”被解读成“需要一个资源管理体系”“云服务器”被扩展成“各种云产品都要接入”“前端页面”被理解成“要搭建一个完整的前端应用”。等你回过神来它已经给你设计好了数据库表、登录页、路由结构、操作日志模块甚至连“数据导出报表”都安排在菜单里了。我把当时的输出和自己的真实需求做了个对比差别非常直观我的真实需求AI第一版生成的内容查看2台实例状态资源列表页支持筛选、搜索、分页启动/停止按钮实例生命周期管理含批量操作、定时任务自己用无权限概念用户注册、登录、JWT鉴权、角色权限不关心历史记录审计日志、操作回放、变更记录一个简单网页足够React前端工程npm构建路由、状态管理一应俱全这个表格列出来之后我自己都看笑了。AI不是不想帮你它是太想帮你了帮到直接把“换灯泡”干成了“重新设计全屋电路”。所以第一步不是怪AI而是弄清楚AI为什么会产生这种倾向才能对症下药。2. AI为什么偏爱“造平台”2.1 训练数据里的“大厂基因”大模型生成内容时本质上是在它的训练数据里寻找“最典型”的映射关系。而在海量技术博客、开源项目、云厂商文档里面出现频率最高的不是“个人小工具”而是“企业级系统”和“平台化方案”。你问它“怎么做饭”它看过最多的菜谱是米其林餐厅后厨的标准化流程自然容易给你一套带摆盘设计的完整晚宴方案而不是一碗蛋炒饭的做法。这个现象在AI辅助编程里尤其明显。模型学习到的“云资源管理”这个主题绝大概率关联着各种云厂商的官方控制台、OpenStack这类开源云平台、公司内部的资源治理系统……这些样本个个又大又全AI从中提炼出的“典型答案”自然就是一套大而全的云平台。它不知道你只有两台机器也不知道你的需求只需要十分钟搞定它只是按照概率给出一个“看起来最像正解”的结构。2.2 “可扩展性”在这里是种过度设计AI生成的这套“云平台”里最让我哭笑不得的是它给每个资源都加了一堆扩展字段资源组、项目标签、环境类型、负责人、描述信息、自定义元数据。它甚至在数据库设计里预留了一个“策略表”说是方便以后做细粒度授权。从架构角度看这些设计不能说错它们遵守了“可扩展性”和“未来可能的需求”。但软件工程里有个原则叫YAGNIYou arent gonna need it你不会用到它。一个个人使用的云资源开关最需要的是什么是可读、可改、依赖最少、一眼能看懂。AI把代码拆成十几个模块引入抽象基类、工厂模式、配置中心式设计的时候它其实是在给一个不存在的“未来团队”写代码。问题是这个团队只有我一个人未来两周后我大概率已经忘了当时的设计意图。凡是你不打算用的功能都是在给维护埋雷哪怕它是AI生成、不要你手敲也要花时间去辨别和删除。2.3 AI不会主动喊停这里也是我最想强调的一点大模型本质上没有“需求边界确认”的机制。人类搭档听到“帮我做个小工具”时通常会追问一句“你用的人多不多要不要考虑权限”AI不会你输入“帮我管理云资源”它就默认你是要“管理系统”。它不是坏是缺少边界感。更关键的是AI的生成过程是逐字逐词延续的它每多生成一个模块后续内容就会沿着这条路径继续加码。也就是说一旦它开始设计用户登录模块后面的资源列表、权限控制、审计日志就会顺着这套逻辑长出来越铺越远像一个接龙游戏停不下来。这时候如果人不介入做决策输出就会越来越偏离你本来的意图。指望AI自己说“我觉得你不需要登录功能”起码在当前这个阶段是不现实的它更倾向把“用户管理”当成一个完备系统的默认组件。3. 怎么把AI拉回正轨范围控制的实操方案3.1 先写“不做清单”比“要做清单”更重要折腾完第一版之后我从头调整了和AI沟通的方式。我最大的体会是给AI提需求光写“要做什么”不够一定要写“不做什么”。“不做清单”能直接压缩它的想象空间效果立竿见影。我后来重新写了一遍需求结构是这样的目标做一个云资源开关只针对我名下的2台云主机。 功能启动、停止、查询运行状态就这三件事。 使用人只有我自己。 不做清单不做多用户、不做登录注册、不做权限控制、不做审计日志、不做费用统计、不做资源分组、不做定时任务、不做前端框架、不做移动端适配。这套提示词发出去之后AI生成的方案明显收敛了代码量大概只有第一版的三分之一。它开始老老实实围绕“获取实例列表”“启动”“停止”“状态查询”这几个函数展开不再自己加戏。“不做清单”之所以有效是因为它把模型的生成空间从“广义的云管理”逼到了“狭义的开关操作”相当于你在给它划跑道。3.2 让AI先出方案别让它直接写代码很多人在用AI编程工具时有个习惯上来就让它“给我写一个完整项目代码”。这其实是最容易失控的方式。我现在给自己定的规矩是先让AI出方案方案通过了再说代码的事。第一轮我会让它只输出实现选项并且明确要求它先说明每种方案的适用场景、代码量和维护成本。比如我要做云资源开关AI给出了这么几个选项方案A命令行工具用Python加云厂商SDK跑一条命令就能启停不需要界面开发工作量约0.5天。方案B轻量Web服务用FastAPI加一个单HTML页面浏览器里点按钮操作需要本地起服务开发工作量约1天。方案C完整管理平台带数据库、前端工程、用户认证可以多人使用开发工作量约5天以上。它甚至还会补充一句“如果你只有自己用推荐方案B如果你不介意命令行方案A更加轻量。”这个过程里AI的角色从“默认决策者”变回了“参谋”真正的决策权在我手上。方案一旦由人拍板后面的代码生成就比较可控了因为你已经明确了“只要A或B”AI再想往平台方向跑也跑不了多远。3.3 迭代式开发一次只问一件事方案确认后我原本想让它直接把方案B的代码全部生成出来但实战告诉我最好还是拆开做。一次只让AI完成一个小任务验收通过后再进入下一个能省掉大量返工。我的节奏是这样第一步让AI写一个函数用云厂商SDK获取当前账号下的云主机列表只需要返回实例ID和状态。拿到代码后我看一眼API调用是否合理跑一下确认返回数据没问题。第二步让AI写启动和停止的函数同样先单独验证。第三步让它写一个状态轮询逻辑确保实例真正进入running或stopped而不是只发了指令。第四步才让它把这些串起来做一个最简单的网页按钮。这种小步快跑的节奏有几个好处每一个环节出问题了你能立刻定位到可能是哪段代码的锅AI每一次生成的任务范围都很窄它不容易“顺手”增加额外模块你每步都能看到实际效果心里不慌。这也是我后来做任何AI辅助开发项目都坚持的方式再复杂的事也拆成适合单次对话的小请求。3.4 从AI的“云平台”里抢救核心部件第一版虽然跑偏了但它生成的东西里也不是全无价值。我在删代码的时候发现有些模块即使“过度”了单独拿出来还是能用的。比如它封装好的云厂商SDK客户端做了初始化、异常捕获、日志输出这部分是通用的它写的实例列表拉取函数字段解析比较完整状态轮询那段逻辑虽然只存在于某个角落但稍加修改就能复用。我最后恢复出来的核心结构非常简单my_switch/ ├── main.py # FastAPI应用提供网页和接口 ├── provider.py # 云厂商SDK封装启停和状态查询 ├── templates/ │ └── index.html # 单页面按钮 └── requirements.txt这是我砍完之后的骨架。把用户表、登录、审计、计费那些全删了之后整个项目肉眼可见地清爽起来。这里也分享一个经验AI生成的代码不要因为“是AI写的”就全盘照收也不要因为它跑偏了就全盘否定。把它当成一个“思路很活跃但不太清楚你底线的同事”有用的模块挑出来没用的果断删掉。4. 实操中大家最容易踩的坑4.1 AI默认给你加“鉴权全家桶”只要你在需求里提到“网页”“管理”这类词AI十有八九会自动给你加一整套鉴权逻辑用户表、密码哈希、token签发、token刷新、登录拦截中间件甚至会引入一个数据库来存用户信息。我见过最夸张的一次AI在生成页面时还设计了“忘记密码”的邮件找回流程。问题是我的服务根本没有公网入口只是绑定了127.0.0.1在本地跑谁来访问都只可能是我自己这堆登录逻辑完全用不上反而徒增复杂度。正确做法是在需求里提前说明访问范围。我现在的写法是“服务只监听127.0.0.1不需要用户认证不需要数据库。”如果考虑到以后可能要在内网其他机器上访问我会写成“服务监听内网IP访问控制通过防火墙或安全组限制不在应用层做登录系统”。把鉴权这事主动决策掉不要留给AI去猜。当然反过来也成立如果你的服务真的会暴露在公网那AI给你加的鉴权就不算多余了你需要的是认真检查它的实现是否可靠。4.2 前端比后端复杂十倍第一版AI给我生成前端的时候直接搬出了一个React工程里面包含package.json、src目录、components、router、store状态管理、环境变量配置甚至还有一套css变量设计系统。我需要先npm install装一堆依赖再执行构建才能在浏览器里看到页面。而我的实际需求不过是两个按钮加一行状态文字。后来我把前端要求改成“用原生HTML加JavaScript做成一个单文件页面由后端直接返回”整个复杂度一下就降下来了。我个人用下来觉得个人工具和小团队内部工具的界面在300行原生HTML以内能解决的事情真不必上框架。如果你确实需要复杂交互和组件化开发那可以选框架否则就让它保持简单。4.3 云厂商的“开关”不是秒开这大概是AI生成的代码里最让我头疼的一个坑。云计算平台的启动和停止操作是异步的你调用API发出StartInstances请求服务端立刻返回成功但此时实例还处于starting状态可能要几十秒甚至几分钟后才会真正变成running。AI在第一版代码里只调用了接口就返回“操作成功”前端按钮立刻显示成功可实际上实例还在慢吞吞地启动。这时如果你急着去连接服务器大概率会碰壁。我后来在代码里加了一段状态轮询思路是发出启停指令后每隔5秒查一次实例状态直到状态变成目标状态或超过指定超时时间抛出异常。核心逻辑大致是这样import time def wait_for_state(provider, instance_id, desired_state, timeout120): start time.time() while True: state provider.get_instance_state(instance_id) if state desired_state: return True if time.time() - start timeout: raise TimeoutError(f实例达到 {desired_state} 状态超时) time.sleep(5)这个细节虽然不是复杂技术但在体验上差别很大。没有它你的开关就是个“假开关”有了它你才敢放心地离开页面不用反复刷新。另外要提醒一句AI不会主动告诉你“按量付费实例停止后存储盘可能还会产生费用”这种关乎账单的问题需要自己对平台计费规则有认知不能指望代码替你避开。4.4 别把API密钥写进页面在最开始让AI生成前端页面时它为了演示方便一度把访问密钥直接写在了前端JavaScript变量里。这种操作在真正的生产环境里是致命的。前端代码用户可见密钥一旦泄露等于把云资源的管理权限拱手送人。正确的结构是密钥永远只存在于后端环境变量或本地配置文件中前端页面只向后端接口发请求后端拿到请求后带着密钥去调用云厂商API。也就是说调用云厂商API这件事只能由后端完成前端永远不直接跟云厂商API打交道。# provider.py 内部读取环境变量 import os access_key os.environ[CLOUD_ACCESS_KEY] secret_key os.environ[CLOUD_SECRET_KEY]这个原则不管项目大小都应该遵守。哪怕是个人小工具也尽早把密钥放在环境变量里不要硬编码在代码文件中更不要出现在前端页面上。密钥泄露带来的风险是实实在在的万一被扫描到你的云资源可能会被人拿去挖矿或者产生巨额账单。5. 这次折腾最终收成一套“够用就好”的云资源开关5.1 最终落地形态折腾了这么一圈最后真正跑起来的方案反而是最初级的一个FastAPI后端加一个单HTML页面。后端暴露三个接口分别用于获取实例列表、启动指定实例、停止指定实例前端页面就两个按钮点击后轮询状态把结果显示在页面上。整个项目代码加起来不到300行依赖只有云厂商SDK和FastAPI。展开来看大概是这样的流程打开页面看到实例卡片显示当前状态是running点一下“停止”按钮后端调用停止接口然后不断查询状态页面上的状态从running变成stopping最后变成stopped下次要用了点“启动”按钮状态从stopped到starting再到running。整个过程中的日志会记录在控制台里方便排查问题。启动服务的方式也简单在项目目录跑一下pip install -r requirements.txt export CLOUD_ACCESS_KEY你的密钥 export CLOUD_SECRET_KEY你的密钥 uvicorn main:app --host 127.0.0.1 --port 8080浏览器打开http://127.0.0.1:8080就能看到那个“云资源开关”了。没有数据库没有用户系统没有权限配置没有几十个依赖的node_modules它就安静地做着“开关”该做的事。我甚至开始怀疑我花在“跟AI斗智斗勇”上的时间可能比直接手写还多但经历了这一趟反而收获了不少判断力。5.2 AI辅助开发边界感比提示词更重要从这次经历里我得到的最重要结论不是“AI会过度设计”也不是“提示词要怎么写”而是“你自己心里要有清楚的边界”。AI再聪明它也只是在响应你的模糊和清晰你越清楚自己要什么、不要什么它的输出就越可用。我后来给自己立了几条规矩挺有效的第一每次需求先写一句话版本的目标和验收标准比如“能让两台实例一键启停启动逻辑必须等状态变running”。第二在需求里明确写出“不做清单”宁可多写几条也不要让AI自己脑补。第三一次对话只让AI处理一个小模块验证通过再进入下一个。第四生成代码后逐段过一遍凡是看不懂为什么要存在的代码先让AI解释解释完发现确实没用就删。这几条平移到其他项目的AI辅助开发上一样适用。最后再分享一个小技巧如果你发现AI已经给你生成了一大堆用不上的东西别急着手动删先把问题发给AI“这段代码解决了什么问题如果我的需求里不需要它我应该怎么移除”AI能自己解释往往能帮你更安全地拆掉那些多余部分。这和拆装修一个道理知道哪里是承重墙才知道哪里能砸。我在这次折腾里学到的最实际的经验就是AI工具越来越强大但它不会替你判断“够用就好”。那个决定“我是只要一个开关还是想要一整个平台”的人终究得是你自己。