follow problems, not trends. 先把问题弄明白，代码只是把答案写下来。
程序是问题的解法。
现在你有一个明确的问题，它的解法可以压缩成一段可重复的动作。
你的程序 = 需求 →（抽象/分解）→ 可执行的步骤 → 稳定的结果
它不必伟大，也不必通用，只要稳定地把麻烦变成平静，就是好程序。
程序/服务是商品
不会写程序的人，通过购买软件或订阅服务来租用别人的解决方案。
供应方卖的不是代码，卖的是可持续的可靠性与持续维护。
Vibe Coding：更多人能开始自己写
Vibe Coding 指的是：
- 用自然语言描述意图，模型给出可运行的原型；
- 通过来回对话，把「模糊的感觉（vibe）」收敛成「明确的行为（code）」。
门槛被抬走了：
- 初学者不用先学语法，再学框架，最后才写功能；
- 现在可以先「把问题讲清楚」，让模型给出「能跑的草稿」，再逐步打磨。
这意味着越来越多的人将第一次「自己写程序」来解决自己的小问题
小规模问题，绕开了很多规模带来的难点
当问题规模很小（一个人的流程、少量数据、有限并发）时：
- 架构复杂度：不需要微服务/消息总线/分布式一致性；
- SRE 难题：不需要 5 个 9；不需要监控；
- 协作/治理：没有跨十个团队的接口协议；
- 成本约束：用一台小机器就够了。
在这个尺度上，过去必须由工程师团队解决的门槛，显著降低。
比如说发博客文章这件事，Quaily 作为一个内容平台，需要向几千作者提供服务时，就需要通过合理的架构来解决数据规模上涨带来的问题。但如果自己做独立站点，只处理自己的文章，数量很少，甚至都不需要建立索引。
工具类利空，授课/知识付费利好
对工具类程序/服务显然是利空。如果核心价值是「把若干常见步骤串起来」，那么用户可能用 Vibe Coding 半天就复刻一个够用版。甚至，直接在 AI 对话框里就把事情解决了。
于是同质化功能的溢价被压缩，长尾需求被用户自助满足（比如图片处理）。
对授课/知识付费/方法论反而是利好。因为「把问题讲清楚」和「把需求说准」变得更重要。
好老师会教你如何描述问题、如何验证结果、如何迭代。这直接提升 Vibe Coding 的产出质量。
规模，依然是难点：Vibe Coding 不能替代软件工程
当问题跨过玩具规模，需要对外提供服务了：
- 数据规模：TB/PB 级别数据、软件质量控制、权限隔离
- 流量规模：缓存、降级熔断、成本优化
- 组织规模：向后兼容、变更管理、安全合规
- 可靠性：SLA、灾备演习
这些都不是“几段提示词”能一蹴而就的。不具备计算机工程能力的人，目前无法仅凭 Vibe Coding 搞定大规模系统。
什么时候 Vibe Coding 不构成威胁？
如果一个程序/业务的商业价值与规模效应、网络效应、分发、合规壁垒、数据壁垒、品牌与信任强相关，或者其价值本来就与技术无关（比如渠道、供给侧资源、IP），那么 Vibe Coding 难以替代：
举些栗子：
- 规模相关：广告平台、支付网络、物流网络、搜索/推荐系统
- 技术无关：独家版权、强渠道、强供给关系、特许经营、监管牌照
Vibe Coding 解决的是把意图落地为小而美的可运行草台方案，不是万能钥匙。
给产品与团队的一点策略
- 做不会被轻易复刻的东西：把护城河放在数据、网络效应、品牌，而不是某个按钮后面的三行代码。
- 把描述问题的能力产品化：让用户在产品里自然地把问题说清楚，就更接近用户最真实的需求。
- 把工程能力留给真正需要规模的地方：小问题用 Vibe Coding 快速落地，大问题继续用工程师。
写给第一次写程序的人
第一次写程序，不需要想架构有多优雅，先想我今天能把什么问题彻底解决。
把问题讲清楚，跑起来，验证结果。
这就足够好。