又一次进行更为细致的检查, 结果察觉到, 该函数在数据尚未全然完成加载的这个时候, 就已经被实施调用操作了。
原来是异步逻辑没理清，AI生成的代码执行顺序有问题。
行，那再改。
改完，测试，上线。
然后，用户说虚拟筛选任务一直卡在“处理中”。
我整个人都懵了。
仔细深入地、逐细微之处进行了一番排查, 结果发现, 问题的严重程度有所加剧, 具体表现为: 该项目存在用Node.js以及Flask这两套后端程序同时处于运行状态的情况。
为什么会这样？
因为早期为了快速迭代，AI生成代码的时候用了不同的技术栈。
一开始没觉得有问题，反正都能跑起来就行。
直到虚拟筛选任务一直卡在 状态，进度始终是0%。
我仔细一查才发现：
明明任务状态已然更新, 然而用户那里却查询不到, 原因在于所查的是另一个不同的数据库。
为什么会掉进这些坑？
早期为了快，我当时的想法是：
结果就是：前期快 ≠ 可以不管技术债。
债务迟早要还，而且是连本带利地还。
我学到的教训
问题：
解决方案：
划重点：前期快不是借口，技术债迟早要还，而且会连本带利。
坑2：测试全部通过，用户那边就崩溃
能用，微信就崩，怎么办？
我做的有个项目需要调用用户的摄像头功能。
我测试的时候，让AI跑自动化测试：全部pass ，一路通畅
我自己在浏览器测试：正常运行，很完美
然后就直接上线了。
第二天，用户反馈：”摄像头打不开。”
我一看，用户用的是微信内置浏览器。
我把各种浏览器都测了一遍：
问题出在哪？
原本, 微信浏览器并不支持, :{ exact: “” }这样一种用以精确调用后置摄像头的方式。
而我之前只在测试过，以为所有浏览器的行为都是一样的。
AI所进行的自动化测试, 更难以让人信赖, 它运行的是标准的浏览器环, 境完全无法涵盖真实的场景。
解决方案
写了个降级策略：
尝试着去进行这样的操作, 先试着对那后面装备的那个摄像头做调用的尝试操作, 该操作对应的精确要求是处于一种空的状态, 当遭遇错误的时候, 也就是出现那种失败的情况时, 就要采取另外的操作, 把调用的设备切换到前面安置的摄像头那里去, 而这种切换操作所针对的对象是用户。
还加了浏览器检测，提前警告用户当前浏览器可能不兼容。
我学到的教训
问题：
解决方案：
划重点：AI跑测试全pass ≠ 真实环境没问题。
坑3：成本失控
一个我和运营的2人团队，服务器2000/月，怎么省？
上线第二周，我收到一封阿里云账单通知。
打开一看：本月账单 ¥1847。
我懵了。
之前测试环境每月也就几百块，怎么突然飙到快2000？
赶紧去看账单明细：
最崩溃的是：这才10个真实用户。
如果100个用户，岂不是要2万/月？（夸张说法）
我决定拆分模块看看怎么省钱：
节约方案 1：存储优化
我打开服务器，du -sh * 看了一圈。
发现：
用户只看180MB的内容，我却存了3.4GB的中间文件。
解决方案：
写了个cron脚本，每周日凌晨3点跑。
第一次跑完：2.9GB → 1.7GB。
省了几百一年。
节约方案 2：API费用
医药靶点项目第一个月API费用好几千。
我去看调用日志，发现每次请求都是全量上下文。
没用 。
这就像每次对话都要从头介绍一遍自己，能不贵吗？
启用 后，成本直接降了接近90%。
节约方案 3：模型选择
不是所有任务都需要 最高的模型。
我重新梳理了一遍：
历经一个月时间, API费用由原本的2000元降至400元, 如此一来才发觉, 实际上要是从拆分场景这个方面来进行分析, 会发现在太多的情况之下都能够做到向下降低配置从而节省资金。花少量的钱完成重大的事情并非是单纯地省钱, 而是要把资金运用精准地投放于关键之处获得成效。
我的教训
问题：
解决方案：
坑4：推广碰壁
发了链接就被封，咋推广？
项目上线后的第三天, 我兴冲冲赶去垂直社区发送帖子, 对帖子给出点赞举动, 针对评论再去点赞、评论, 对那些好赞的评论也进行操作, 怀揣试探性发出了一个不包含广告的表达技术沟通的帖子, 而后静静坐等kama值。
结果在两小时之内, 该帖子直接被系统给删除了, 账号被永久封禁了, 一个新增用户都没有拿到, 白白损失了一个号。
更尴尬的：AI 信任危机
存在一件事, 致使我尤为纠结, 原本计划录制一期视频, 用以分享自身运用AI落地产品的整个过程, 然而却始终卡在一个要点上, 即究竟要不要向外界坦诚该项目在全程均借助AI进行辅助开发。
说实话, 担心外界会认为由AI生成的代码缺乏可靠性, 进而对产品稳定性产生质疑；要是隐瞒不说明, 却又感觉这样做不够诚恳。
后来在经过一番思考之后, 终于完全明白了, 用户只会因为产品能否解决他们自己本身所存在的问题, 进而为之支付费用, 而根本就不会去关心你的开发工具究竟是什么样的。
对外进行宣传时应有的正确思路是, 不要直接表明项目是借助AI来完成编写的, 而是转变为去描述基于现代化的智能开发工具, 能够快速地迭代并落地产品方案, 在整个过程中要把重点聚焦于产品的核心价值, 将开发手段予以弱化, 把宣传的重心放置在产品价值上面, 而非开发的方式。
我的教训：推广不是发广告，是先让别人信任你。
坑5：人机协作的本质
在2026四月的时候, 我参与了一回vibe会议, 会上有9个项目进行了分享, 其中存在着几个核心洞察, 这使得我对人机协作进行重新思考。
案例1：多AI分工 > 万能AI
Slock的创办者讲述了他们的合作方式: 有8个人工智能同事, 每个都各尽其责。
不是一个万能AI，而是：
工单化协作：AI直接修代码、跑测试、提PR，人只负责决策。
核心理念： > 中央化。
这让我意识到：不要指望一个AI什么都能干。
案例2：记忆层 > 工具层
那创始人讲说出的一番话语, 使得我脑海之中留下了极为深刻的印象, 其内容是, 并非是安装了工具, 而是构建起了关系。
工具会换（ → → Codex），但记忆不能丢。
他们用做向量存储 + Cron Jobs定期归档。
投资记忆系统，不是投资工具。
案例3：人负责战略，AI负责执行
我们自己的实践也验证了这一点。
架构决策：人工主导。
代码实现：AI执行。
人退到目标层，AI在执行层。
我们的AI家族
现在有5个AI小伙伴：
金毛管家, 处于 24h 待命状态, 决策以及投资研报方面由小付（Code）负责, 其作本地开发, 是本地主力开发人员还要另外负责 SEO, （Code + 飞书桥）负责项目专属架构与业务迭代 , 狸狸（14B）进行本地部署, 属于客服和 faq 数据专员, 还在开展知识训练工作, 等待厚积薄发 , 小五（Codex）刚加入, 是由于工信部发的通知而新加的成员, 作为新加入的成员还处于磨合阶段, 当前已接受了运营市场和推广物料的工作。
每一个AI都划分出清晰明确的职责, 彼此之间不会相互超越权限, 从理论层面来看是非常完善的, 然而, 在真实的落地实施过程当中, 却仍然踩到了严重的大坑。
下面接着说案例：
坑 6：多AI协作的分支拉取规则失控
我们5个AI小伙伴各司其职，听起来很美好。
但第一次真正协作的时候，差点翻车。
境况是, 金毛管理人士于云端对文档作出修改, 小付在本地针对前端予以更改, Cici在另外一台机器那儿对后端进行改动。
问题：没约定谁拉哪个分支。
结果：
让人最为崩溃的是, 有三个人, 各自修改的是同一个文件里不同的位置, 然而到了最后合并的时候, 却全都乱掉了。
为什么会这样？
因为我们一开始只说了”谁负责什么模块”，但没约定：
解决方案：
制定了AI协作规范：
能推的只有金毛管家, 其为最终决策者, 其他AI仅能推dev分支, 也就是开发分支, 提交之前必须进行git pull, 目的是避免覆盖, 提交信息格式要统一, 即要写明改了什么。
当前, 每当开展协作之前, 具备金毛特征的管家会率先做出检查行为: “究竟是谁在对什么进行修改? 此种修改是否已然完毕? 我是否能够执行pull操作了呢? ”。
坑7：清理包误清空线上分支
另有一回更惨的情况是, 那时小付在清理本地项目之际, 意外地把.git目录给误删了。
场景：本地磁盘快满了，小付想清理一下 。
结果手抖，执行了：
rm -rf .git
瞬间懵了：整个Git历史没了。
更惨的是：线上服务也挂了（因为部署脚本依赖Git信息）。
用户访问网站：404。
绝望时刻：
我本人都慌得绝望了：
最后怎么救回来的？
还好金毛管家有个习惯：每次重要改动后，立刻推到远程仓库。
虽然最新的几个丢了，但上还有前一天的备份。
紧急操作：
先从拉取最新的备份分支开始, 手动去恢复那丢失的改动, 还好仅仅只改了三个文件, 之后重新进行部署上线, 最终用户那边恢复到正常状态。
用时： 4-5小时（冷汗直流）。
教训：没备份的代码 = 随时会消失的代码。备份 > 一切。
从那以后，我们约定：
我的教训
Vibe 降低了启动门槛，但没有降低成功门槛。
问题：
（1）指望一个万能AI
（2）过度依赖AI做战略决策
（3）换工具就清零记忆
解决方案：
（1）明确分工，每个AI负责什么
（2）建立记忆系统（不是换工具就清零）
（3）人定战略，AI执行
反思：1到N比0到1难在哪
上篇讲述了从0到1的四个阶段, 分别是上瘾期, 碰壁期, 解法期, 以及更大的坑。下篇介绍了我所发现的从1到N的五个深坑, 即便花费了将近一万字, 也难以详尽表述其中的万分之一。
为什么1到N更难？
0到1的时候：
AI能帮你写代码，能跑就算成功，没用户就没压力。
1到N的时候：
AI没办法帮你进行决策, 没办法帮你管理团队，当然也没办法帮你开展推广, 不能够提醒你预先去控制成本。
核心差异：
从0到1呈现的是“能不能做出来”层面的问题, 其中AI能够予以解决, 而从1到N所展现的是“能不能活下去”方面的问题, 在这方面AI无法解决。
那种情况如此为难, 我们是不是就不开展这项事情并停止作为? 尽管这般, 肯定不对, 察觉到问题是要去处理问题。
也许更现实的做法是：
一人进行OPC, 务必要“E”起来, 在碰到问题时, 别一个人去死磕, 否则就厚着脸皮冲着大佬去请教, 否则就寻觅技术/推广搭档, 或是涉足加速器去换资源。
当然，产品方面，但如果你愿意，可以和我交流～
最终，给予那些想要持续去做的人若干Tips, 1.技术方面: 接纳早期阶段的杂乱无序情形却不要欠下太多的债务。
0-1阶段：直接改，快速迭代，完成大于完美，先验证市场。
有用户后：上版本管理（dev + ）
重点在于按一定周期偿付账款, 切不可待到出现严重问题才着手重新构建, 重新构建属于正常情况, 传统行业与信息技术、互联网产品领域均存在诸多重新构建的实例, 不要妄图一下子达成太大目标, 持续处于修正漏洞的状态, 却无人进行推广。
2. 测试：人工 + AI结合
用AI写出单元测试用例, 然后运行测试。由人工去跑核心流程, 像是冒烟主流程, 并且至少要尝试3个浏览器或者设备。
Agent全pass ≠ 真实环境没问题
3. 成本：定期审计，自动化清理
每一个月查看一回存储方面的费用, 以及API费用, 去进行识别, 识别的内容是中间文件与最终产物之间的区别。
小钱办大事 = 钱花在刀刃上
4. 协作：找搭子/搭档
某个人单独完成技术以及推广还有商业化这一系列工作难度极大, 需要寻觅具备互补能力的搭档也就是技术方面与推广方面的搭档。
不要死磕，有些事真的需要两个人
5. 推广：先提供价值
回答问题之后分享产品, 通常是察觉到有需求, 而后去做产品, 经历与竞品的激烈竞争, 最终产品得以成功。
