Vibe Coding 一个产品上线之后，我发现了天花板
Vibe Coding 一个产品上线之后，我发现了天花板
Stitch 那个项目之后，我开始大面积用 AI 干活。
"遇到问题才用"变成了把 AI 嵌进日常。写方案先让 AI 拆一轮、评审前列一个风险清单、做 demo 不再开 Axure 而是用 Claude Code 生成页面。这个阶段最直接的变化是：以前接一个需求要想"UI 排不排得上、研发有没有时间"，现在先想"这件事 AI 能不能帮我先出一版"。工作流的起点变了。
但真正让我验证"一个人+AI 的产能到底能到多少"的，是一个完整的项目：ai123.com。
一个完全靠 vibe coding 上线的产品
2026 年中，我做了一个决定：搭一个 AI 产品工具聚合平台。
做这个决定基于一个很实际的判断：AI 工具在爆发，但市场上缺少一个够用的聚合入口。如果能把这个做起来，对业务是正向的拓展。
我用 AI 把这个产品从 0 到 1 做了出来，然后上线了。
一整行代码都没用我写。
全部是 AI 生成的。从页面结构、交互逻辑到部署配置、SEO 和 Analytics 接入——以前做一个产品，你要搞定产品定义、UI 设计、前端开发、后端、部署、域名、分析，每个环节都要等不同的人。现在一个人，两个月，全部走完。
那个兴奋感是真实的，是"我能做到的事变多了"带来的。
然后我撞到了天花板
产品上线了。但问题开始浮现。
同一个问题出现在好几个项目里。
AI 开始"忘"东西了。在长对话里，前面的指令它会丢掉。你明明在开头说清楚了"这个项目用 Next.js，样式用 Tailwind，API 路由按这个结构走"，写到第三个页面的时候它开始给你生成不同的东西。
一开始我以为是我没说清楚。重新组织了 prompt，把关键信息放在开头，加粗，反复强调。好了一点，但问题没消失。
我花了一些时间排查。Prompt 是对的，指令是清楚的。
我后来在文档里翻到一个概念：Lost in the Middle。
核心意思是：Transformer 的 attention 机制对长上下文中间位置的信息天然不敏感。这是数学决定的——信息放在中间，就是容易被"看"弱。
同一时间我在搭 MatchInfluence，Agent 之间的信息传递也出现了类似的问题。Strategy Agent 生成的方案传到 Sourcing Agent 时，关键约束会丢失。同样的底层机制在多个场景里反复出现。
知道这个原理之后，问题没有消失，但我终于理解了为什么。
想通之后，我没再琢磨怎么绕过它了。Transformer 的 attention 机制就是这么设计的，数学上就是这样。
稳定是可以被设计的
Lost in the Middle 让我想通了一件事：
AI 的核心问题是不够稳定。
同样的需求，用不同的对话窗口问 AI，给你不同的方案。同样的 prompt，在不同的上下文长度下，输出质量不一样。这就是概率分布在波动。
理解到这一点之后，我对 AI 的态度变了。
以前我的问题是"怎么让 AI 更聪明"。后来的问题变成了"怎么让 AI 稳定地输出"。
我开始学 Context Engineering。信息分层、关键信息放开头和结尾、预算管理，本质上是在给 AI 划一个它处理得过来的上下文边界。
我也开始明白一件事：稳定需要被设计出来。靠 prompt 技巧不够，靠换模型也不够——你需要一套机制来保证 AI 在你不盯着它的时候，也能稳定工作。
这把我带到了下一个阶段：从"怎么用 AI"走到了"怎么把 AI 组织成一个可靠的系统"。
这就是后面的故事了：怎么把经验写成 skill、怎么用 agent 兜底、怎么搭 multi-agent 系统。
那一刻我才看清：这件事是系统性的。它不局限于某一个项目。
第 4 篇预告：
量产之后，下一个问题是重复。每次写 prompt 都是从零开始、每次让 AI 理解我的业务上下文都要重新解释一遍。我开始把高频动作写成可复用的 skill，从 spec-analyze 到 spec-sdd 到 project-knowledge 到 Creator-Studio。这个过程很痛苦，因为它逼我把"凭感觉知道怎么做"翻译成明确的规则。但也正是这个过程，让我开始理解一件事：写 skill 的本质，是把判断力产品化。