纯靠 vibe coding 做项目，本地已经跑通了，接下来该直接给用户用，还是先找个地方让朋友和客户试？
一个项目从开发到上线到底有几套环境？
一个正式生产的项目增加功能的流程到底是什么？
一天一个 vibe coding 小技巧，今天就来解决这些问题。
一、开发环境：先让每一次改动只影响你自己
一个项目最常见的是三种环境，第一种就是开发环境。
对大多数纯 vibe coding 用户来说，它就在自己的电脑上，也就是平时说的本地环境。
你每天和 AI 加功能、修 Bug、调整页面，都是先在这里完成。
页面改坏了，可以继续改。
测试数据弄乱了，可以清掉重来。
一个功能做完以后发现方向不对，也可以推翻重做。
因为这个版本还没有交给朋友，更没有交给正式用户，试错的代价主要留在你自己这里。
那么本地环境需要哪些东西呢？
先别看到 Node.js、Python、MySQL 这些名字，就让 AI 全部装一遍。
每个项目用到的东西不一样，应该先让 AI 读取项目文档、依赖清单和现有配置，把这个项目真正需要的东西列出来。
这份清单大致会分成两类。
一类是让代码真正跑起来的工具和运行环境。
比如 Node.js、Python 解释器、Java 开发工具包，或者 PHP 运行环境。
项目使用了哪一种技术，就准备它需要的版本，不是电脑上装了一个能写代码的软件就够了。
另一类，是项目运行时要连接的本地服务。
比如保存用户、内容和订单的数据库，或者项目确实用到的缓存、文件存储。
一个只做静态页面的项目，可能根本不需要数据库。
一个需要登录、保存内容和处理订单的项目，用到的东西就会更多。
该装什么，取决于这个项目实际用了什么，不取决于哪个技术名字听起来更专业。
清单确定以后，本地环境通常有三种搭法。
第一种是用集成软件，把常见的运行环境、数据库和管理工具放在一起。
它适合希望少装几个软件、最好点一下就能启动的人。
第二种是用 Docker。
如果项目本来就准备好了 Docker 配置，按照这份配置启动，比较容易让不同电脑使用同一套版本。
但项目没有现成配置，只是为了显得专业，让 AI 临时写一大套 Docker 文件，不一定会更省事。
第三种是按照清单分别安装，也就是你说的散装组件。
这种方式最直接，也最灵活，但每一样东西的版本、启动方式和占用的端口，都要分别管好。
三种办法没有固定高下。
你真正要看的是：项目有没有现成配置，你的电脑能不能稳定运行，关掉以后能不能重新启动起来。
开发环境应该使用可以随时清理、随时重置的开发数据，以及专门用于开发的账号。
生产数据库、真实用户资料和生产密钥，不要为了图方便直接搬到本地。
开发环境做到什么程度，才算这一站过了？
不是页面今天碰巧打开一次就算。
你要知道项目依赖哪些东西，每一样怎样启动。
关掉项目重新启动，核心功能还能用开发数据走通。
换到另一个代码版本以后，也知道怎样把它重新跑起来。
在开发环境里，改坏了并不可怕。
真正危险的是还没有在这里改稳，就把同一份问题直接交给别人。
二、测试环境：让错误先撞到测试人员，不要先撞到正式用户
项目在开发环境里跑通，只能说明你自己已经走通了。
你知道按钮在哪里，也知道正确的操作顺序。
有些地方还没做完，你甚至会下意识绕过去。
朋友、客户或者测试人员不会照着你脑子里的路线使用。
他们可能换一台手机、换一种浏览器，也可能连续点击、输错内容，或者做到一半突然断网。
这就是为什么本地跑通以后，还要准备第二套环境。
这套环境要让指定的人能够访问，但不能承载正式业务。
网站通常会有一个单独的测试网址。
桌面软件可以交付测试安装包。
App 也可以通过平台提供的测试渠道，交给指定的人安装。
测试用的程序，加上这个项目需要的后台、配置、数据和账号，合在一起才是测试环境。
测试环境先要证明别人能够进来。
接着要证明他们真的能把事情办完。
注册以后能不能登录，提交以后数据有没有保存，下单以后订单有没有出现，不同身份的人看到的内容对不对。
正常流程要走一遍。
输错内容、重复点击、没有权限和网络中断这些不顺利的情况，也要走一遍。
错误在这里被撞出来，影响的是测试数据和测试账号。
等它到了生产环境再被正式用户撞出来，影响的就可能是真实资料和真实订单。
为了让测试结果有意义，测试环境还要尽量还原准备上线后的运行条件。
准备发布的程序、数据库结构、依赖版本和配置结构，要尽量和生产环境对得上。
但两边真正填写的地址、账号、密钥和数据，必须各用各的。
项目用到了数据库、上传文件或者第三方服务，测试环境就准备对应的测试数据和测试配置。
第三方平台提供沙箱或者测试账号，就先使用测试的那一套。
平台没有提供，就按照官方文档规定的方式测试，不能让 AI 自己猜。
如果某项测试确实会产生扣款、短信发送这类真实动作，就提前限制金额、次数和接收对象，而且每次执行前都要得到你的明确授权。
测试不是在页面上假装点几下，也不是因为名字叫“测试”就什么都可以做。
它是在不伤到正式用户的前提下，把准备上线的版本尽量走完整。
测试人员发现问题以后，要回到开发环境修改，再把新的版本交给他们重新验证。
原来的问题消失了，相关的正常功能也没有被改坏，这次修复才算通过。
不过，一次修复通过，不代表整轮测试已经完成。
朋友只说一句“看着还行”，不叫测试完成。
测试环境真正替你挡住的，是那些在你手里没有出现、却很可能在正式用户手里出现的问题。
三、生产环境：把已经验证过的版本交给真实用户
测试通过以后，版本才会进入第三种，也就是生产环境。
正式用户真正使用的那一套，就是生产环境。
网站对外开放的正式网址、App 商店里下载到的正式版本、公司员工每天处理业务的正式系统，都属于生产环境。
它不一定面向所有人，但使用它的人是真实用户，产生的数据和业务也是真的。
这里的账号不能随便删，订单不能随便改，上传的文件也不能想清理就清理。
开发环境里一次失败，可能只是你自己的页面打不开。
生产环境里同样一次失败，可能是用户注册不了、客户提交不了资料，或者已经发生的交易找不到记录。
风险到了这里确实高了。
好在，做生产系统不是要求你保证以后绝对不出错。
真正要做到的是，每一次变化都说得清来自哪里，发布前有人验证，出问题也能及时停住影响。
所以生产环境不是拿来边改边试方案的地方。
它只接收在开发环境完成、在测试环境验证过的版本。
生产环境里的每一次发布和修改，都必须由你明确授权。
AI 能够执行，不代表它可以替你决定什么时候影响真实用户。
有些企业还会在测试和生产之间增加验收、预发布等环境。
这些名字和分法并不统一，也不是每个项目都必须增加第四、第五种环境。
项目复杂以后，只是把测试到生产之间的过程继续拆细，让不同的人分别确认。
三种环境不是三个放在文档里的名字，而是三道逐步扩大影响范围的关口。
开发环境允许你和 AI 反复修改。
测试环境让别人先把问题撞出来。
生产环境才负责承接真实用户和真实业务。
四、正式项目每次增加功能，都要重新走一遍
开发、测试、生产，不是项目第一次上线时才走一次。
项目已经正式运行以后，每增加一个功能、修一个 Bug、升级一次依赖，只要会改变用户拿到的结果，都要重新走一遍。
第一步，先把这次修改的范围说清楚。
要增加什么、会影响哪些已有功能、哪些地方这次不改，先让 AI 读项目文档并列明白。
范围没定住，AI 很容易在做一个新功能时，顺手把旁边已经稳定的东西也改掉。
第二步，回到开发环境完成修改和自测。
使用开发数据把新功能从头走一遍，也看看它有没有把原来正常的功能弄坏。
第三步，生成一份准备交给别人测试的版本。
这份版本要有明确的版本号或者构建编号，还要能查回它对应的代码。
第四步，把这个版本发布到测试环境。
网站部署到测试网址，桌面软件交付新的测试安装包，App 则通过对应的测试渠道发布。
这一步带过去的是代码，或者由代码生成的程序和安装包。
本地数据库和本地配置不能原样复制过去，测试环境继续使用自己的数据、账号和配置。
第五步，让朋友、客户或者测试人员按真实流程使用。
发现问题就回开发环境修改，再生成一个新版本，重新发布到测试环境。
哪怕只改了一句话，也不能完全跳过检查。
至少要重新走一遍被改到的页面和相关流程，确认这句话没有挤坏页面，也没有影响另一条操作。
第六步，测试通过以后，锁定准备上线的版本。
从这一刻开始，不再往这份版本里顺手塞新功能。
又有新想法，就放到下一轮。
不然测试人员通过的是 A，最后发给用户的却是临时又改过的 B。
第七步，把这份已经验证过的代码发布到生产环境，再做一次生产验收。
上线的必须是测试通过的那份代码，不是把测试环境整个复制到生产环境。
至于是直接换成正式配置运行，还是按照正式配置重新打包，要看这个项目原本怎样构建。
无论采用哪一种，都要能查清代码和配置来自哪里，不能上线以后连自己发的是哪一版都不知道。
如果功能还涉及数据库变化，也要执行已经在测试环境验证过的变更方案，不能把测试数据库整个复制过去。
发布完成以后，确认正式入口上的版本正确，核心流程正常，日志和数据没有出现新的异常。
到这里，一次功能更新才算真正走完。
如果生产环境正在持续出错，要先保护用户、控制影响。
但正式修复仍然要回到开发环境完成，再到测试环境验证，不能留在生产环境里边改边试。
这整条流程里，AI 负责按照要求完成修改、生成待测试的版本、准备发布方案，并整理检查结果。
你负责确认功能是不是你要的，测试反馈有没有解决，以及什么时候允许它碰生产环境。
你不需要自己写代码，但必须知道项目现在走到了哪一站，为什么可以进入下一站。
五、一台服务器可以同时放测试和生产，但不能混成一套
环境说的是用途和边界，不是服务器的数量。
所以，三种环境不等于一定要准备三台服务器。
开发环境一般就在自己的电脑上。
如果做的是网站或者后台，预算有限、访问量不大、测试也比较轻，测试环境和生产环境可以放在同一台服务器上。
一台服务器本来就能同时运行多个程序，也能让不同网址分别访问不同程序。
真正的问题不是“能不能放”，而是放在一起以后，你能不能保证两套环境不会被当成一套使用。
先看程序和入口。
测试环境使用测试网址，生产环境使用正式网址。
两套程序可以放在不同目录，也可以放在不同容器里。
无论采用哪一种方式，更新、重启或者停止测试环境时，都不能覆盖或者停掉生产程序。
服务器还要能把两个网址分别交给正确的程序，不能让测试地址混进生产配置。
再看配置和数据。
测试环境使用测试配置，生产环境使用正式配置。
数据库软件不一定要安装两遍，但测试程序要连接测试数据库，生产程序要连接生产数据库。
最好连数据库账号都分开，让测试环境使用的账号根本没有权限修改生产数据。
测试上传的图片、生成的文件和程序日志，也要放在能够单独管理和清理的位置。
第三方服务能分测试账号和正式账号的，也要各用各的。
平台不能分的，就按官方规则限制测试动作，不能让测试任务影响真实用户。
接着还要把权限和自动任务分开。
最好给两套程序使用不同的系统账号，让负责发布测试环境的账号没有权限覆盖生产程序。
测试环境里的定时任务只能处理测试数据，不能跑去给正式用户发通知、扣额度或者处理真实订单。
这些东西只要混掉一项，AI 即使按照测试要求执行，也可能实际修改生产数据、误发消息，甚至让同一个任务执行两遍。
程序、入口、配置、数据和权限都分开以后，两套环境才算真正独立运行。
可它们仍然住在同一台服务器上。
处理器、内存、磁盘和网络，底下用的还是同一份。
测试环境突然导入一大批数据，或者日志失控把磁盘写满，生产环境还是会跟着变慢，甚至打不开。
即使用 Docker 把两套程序装进不同容器，一台服务器也不会凭空变成两台。
能设置资源上限时，要限制测试程序能够使用的处理器、内存和磁盘，日志也要限制最大占用空间。
这些限制可以减少互相拖垮的机会，却不能提供两台独立服务器那样的隔离。
安全风险也一样。
测试网址只要能从互联网上打开，就不能把“别人不知道这个网址”当成保护。
它同样需要登录、访问名单或者网络限制，发现漏洞也要修。
测试程序一旦被攻破，风险可能继续蔓延到同一台服务器上的生产环境。
所以测试环境不代表什么都能干。
会大量占用资源或者可能破坏服务器的测试，不能直接放在这台同时承载生产环境的机器上做。
预算有限、业务量不大、测试也比较轻，而且能够接受两套环境互相牵连，可以先同机部署。
生产环境已经承载重要业务，测试又很频繁，或者业务不能接受测试拖慢正式用户，就应该把两套环境放到不同服务器上。
服务器分开以后，账号、权限、配置和数据这些边界仍然要分。
不然测试账号还是可以修改生产数据，风险只是换了一个地方继续存在。
同机部署省的是成本，分机部署买的是隔离。
这不是谁更专业的问题，而是你的业务现在能不能承受两套环境互相影响。
这些配置你不一定会自己做。
但每次让 AI 动手以前，要让它先用大白话说清楚：现在操作的是哪一种环境，会碰哪套程序、哪套配置和哪套数据。
它说不清，或者你听不懂，就先不要让它执行。
六、最后
现在回到开头的两个问题。
一个项目从开发到上线，通常要分清开发、测试和生产三种环境。
开发环境负责让你和 AI 完成修改。
测试环境负责让别人提前发现问题。
生产环境负责承接真实用户和真实业务。
一个正式项目增加功能，也不是本地改完就直接同步到生产。
它要在开发环境完成和自测，生成能够识别的版本，再发布到测试环境交给别人验证。
发现问题就回开发环境修改，重新发布到测试环境再测。
最后锁定通过的版本，按照生产配置发布，并完成上线后的验收。
三种环境也不一定需要三台服务器。
测试和生产可以放在同一台服务器上，但程序、入口、配置、数据和权限必须分开，同时还要接受资源和安全风险无法彻底隔离。
把环境分开，不只是把同一个项目多部署几份。
更重要的是让改动先在你手里试错，再让测试人员找错，最后才有资格碰到真实用户。
