非技术用户正在发布专业软件

原始标题: Non-Technical Users Are Shipping Professional Software

发布日期: 2026-03-16 | 来源频道: @ycombinator

📝 深度摘要

1. 讨论背景与核心主题

本期节目由 Y Combinator 主办，嘉宾是 Emergent 平台的联合创始人 Makund 和 Madhav Jar 兄弟。Emergent 于 2024 年夏季进入 YC 孵化，是有史以来 YC 增长最快的公司之一——上线 8 个月内，用户通过该平台构建了超过 700 万个应用程序。平台目前覆盖全球 190 多个国家，其中 80% 的用户是非技术背景，没有任何编程经验。

本视频试图回答的核心元问题是：在 AI 时代，技术壁垒如何被彻底瓦解，以及这将如何重塑软件工程的本质和创业的门槛。通过 Emergent 的实战案例，深入探讨了非技术用户如何能够构建生产级软件，以及这一趋势对整个 SaaS 行业、开发者生态和未来工作方式的深远影响。

2. 核心干货概览 (Startup Key Takeaways)

3. 深度战术拆解：YC 方法论实战 (Tactical Deep Dive)

痛点再定义 (The Problem)

初创公司在 AI 编码工具领域普遍面临一个根本性悖论：用户可以快速构建原型，但无法将原型转化为生产级应用。当时主流的 Lovable、Bolt 等平台都将焦点放在前端原型开发上，而忽略了软件工程中真正消耗时间的环节——测试、部署、安全审查、运维监控等。这种"80% 工作完成，最后 20% 却需要 80% 精力"的困境，导致大量应用停留在概念阶段，无法真正服务于商业用户。

更深层的问题在于，技术栈选择的路径依赖。许多团队在早期为了快速上线，选择了 Node.js 全栈框架，当后期需要引入后台任务队列、异步处理（如视频转码）等高级功能时，架构改造成本极高。更关键的是，非技术用户根本无法理解 API Key 的概念，他们甚至不知道什么是 JSON，不知道如何调试代码——一个简单的"代码差异"界面就足以让他们感到恐惧和退缩。

与此同时，软件定价的巨大鸿沟同样构成痛点。构建一个定制化的企业软件，传统开发团队报价可能高达 50 万美元，而中小企业主根本无法负担这笔费用。他们只能依赖邮件、WhatsApp 和 Excel 表格来管理业务，效率低下且无法规模化。

核心策略推导 (The Solution)

Emergent 的核心策略可以从三个维度理解：

第一，从第一性原理重新定义"全栈”。创始人 Makund 曾在 Google 任职，后在印度创办了 Danzo（一家超级本地化的即时商务公司），管理着 300 名工程师的团队。他深刻认识到，软件测试是快速交付的最大瓶颈。基于这一洞察，团队最初申请 YC 时提交的创意是"自动化软件测试"。但在构建测试智能体的过程中，他们发现一个关键真理——如果你能解决验证（verification）问题，你就能自动化整个软件工程流程。验证回路是让智能体能够长时间稳定运行的核心，这成为 Emergent 架构的基石。

第二，自研基础设施而非外包。当时主流做法是使用第三方沙箱提供商来运行编码智能体，但 Emergent 选择从零构建自己的 Kubernetes 容器化基础设施。这一决策的核心逻辑是：如果智能体在构建时和部署时使用完全相同的 infrastructure，那么在部署阶段遇到的问题将大幅减少。此外，自有基础设施允许团队向智能体提供极速反馈——“智能体的能力取决于你提供反馈的质量”，这是创始人在访谈中反复强调的观点。

第三，打造多智能体协作架构与长期记忆系统。Emergent 是最早一批采用多智能体编排（multi-agent orchestration）的团队。当主流还在讨论单智能体时，他们已经实现了主智能体负责主流程、子智能体负责专项任务（测试、设计搜索、API 集成）的分布式架构。更关键的是，跨会话长期记忆机制——如果三周前一个智能体在日历集成上遇到困难并成功解决，今天它将不再重复同样的错误。这些"技能"并非人工预设，而是通过分析历史轨迹自动生成，经由 CI/CD 流程验证后加入长期记忆系统。这本质上是一种持续学习（continual learning）能力的工程化实现。

实战步骤 SOP (Implementation)

以下是 Emergent 在产品和工程层面的具体执行步骤：

产品层面：

• 话术差异化：明确传递"构建真正的应用"（Build Real Apps）而非"快速原型"的价值主张。在营销中直接对比其他平台的常见错误，让目标用户感知到专业性
• 模糊需求澄清机制：智能体在开始构建前，会主动向用户提问以确认需求理解正确。这一设计极大降低了需求错配的风险
• API Key 抽象化：非技术用户无需理解 OpenAI API Key 的概念，平台提供 Emergent LLM Key，用户可以即插即用
• 渐进式复杂度暴露：即使后台拥有强大的 VS Code 编辑器，也对非技术用户完全隐藏。避免任何可能引发焦虑的技术元素出现在用户界面
• 版本控制与功能开关：即使不连接 GitHub，平台也内置版本管理。每个应用有主要负责人，特性请求需要经过审批流程后才能发布

工程层面：

• 技术栈选择：采用 Python 后端服务器 + React 前端服务器的架构，而非当时流行的 Node.js 全栈。这一选择基于对未来的预判——用户业务规模扩大后必然需要后台任务队列、异步处理（如视频转码）等能力
• 多智能体架构：主智能体处理核心业务流程，子智能体并行处理测试、API 搜索、设计搜索等专项任务
• 验证回路构建：构建自定义的 fine-tuned verification layers，用于判断任务是否真正完成。这是比单纯依赖模型本身更可靠的控制层
• 基础设施一体化：构建时环境与部署时环境完全一致，消除"在我的机器上能运行"的生产困境
• Agent Experience 监控：内部引入"智能体体验"（Agent Experience）指标，衡量智能体在平台上的运行状态和反馈质量

增长层面：

• 网红营销引擎：在产品上线初期，大量投入 TikTok 和 Instagram 网红合作，快速获取注意力
• 全员客服制度：公司只有 12 人时，即保持一人始终轮值客服；现在依然坚持全员每周至少与客户对话一到两次
• 全球化客服能力：上线前五天，创始人亲自处理客服工单，大量用户使用法语、德语等不同语言，借助 AI 翻译实现无障碍沟通

细节支撑

案例一：Asana 内部替代品的诞生。Emergent 团队一位 QA 工程师出于好奇，用自然指令"克隆 Jira"作为首个提示语，随后不断迭代，最终构建出完整的内部项目管理系统。该系统完全适配团队独特的工作流程——团队每天发布三次（早、中、晚），这种高频发布节奏是标准 SaaS 工具无法满足的。同时，他们每月节省了约 3000-4000 美元的订阅费用。更重要的是，这个系统是 100% 由 AI 智能体构建，团队成员可以随时用自然语言添加新功能。

案例二：挪威律师 CRM。一位之前将公司出售给私募股权基金的挪威用户，深刻体会到律师在电子表格上挣扎的痛苦，于是用 Emergent 构建了一个律师专用的 CRM 系统。他将自己定义为"商业开发者"——没有编程背景，却构建了完整的商业应用。

案例三：阿拉斯加临床心理学家与马术教练的结合。一位住在阿拉斯加的临床心理学家同时也是马术教练，她希望在心理学和马术两个领域之间建立一座桥梁——市场上根本不存在这样的应用程序。她曾咨询 Nova Scotia 的开发团队，报价高得离谱。最终她发现 Emergent，仅用几周时间就构建并上线了名为 Equine 的应用，目前已有数百名用户。

4. 技术护城河与工程实践 (Technical Moats & Engineering)

AI/ML 策略应用

关于"80% 的 App 会消失"这一预言的技术逻辑：当前 AI 模型的能力正在以惊人的速度进化。SWE-bench 基准测试的成绩从几乎为零到快速饱和，模型的"任务 horizon"（任务视野/执行长度）正在指数级增长。4.5 版本可以处理约 4 小时的任务，4.6 版本已经延长到 10 小时。这意味着单一应用的复杂度上限正在被不断突破。

然而，这并不意味着 AI 公司将取代一切。访谈中明确指出，编程只是整个软件生命周期的约 20%。将一个应用真正推向生产环境——涉及部署、安全、监控、客户支持、合规、用户增长、分销等——才是真正困难的环节。Emergent 的护城河正在于此：他们不是在与模型竞争，而是在模型之上构建了一层完整的"软件工程自动化"能力。

Agent Swarms 与长程任务：团队正在实验"智能体群"架构，多个智能体可以在单一任务上协作更长时间。未来的目标是实现"24 小时运行的智能体"和"数百个智能体协同完成单一任务"。为实现这一目标，他们正在构建"监督智能体"（overseer agent）架构——在多个智能体协作时，有一个并行运行的监督智能体监控整体任务进度，确保轨迹不会脱轨。

自定义 Fine-tuning 的使用场景：虽然不打算直接与基础模型竞争，但 Emergent 在特定层面进行微调——特别是验证层（verification layer）。任务的完成质量需要专门的验证模型来判断，这比单纯依赖模型自身的判断更为可靠。

工程化决策逻辑

自研基础设施的决策依据：当时很多团队选择第三方沙箱服务来运行编码智能体，但 Emergent 团队判断这对长期发展不利。核心逻辑链条是——

• 如果构建环境和部署环境不同，部署阶段会出现大量难以复现的问题
• 智能体的能力取决于反馈的质量和速度
• 自有基础设施可以实现毫秒级的反馈循环，这是外包方案无法达到的
• Kubernetes 容器化方案确保了弹性扩展能力

技术栈选择的前瞻性：选择 Python + React 而非当时更流行的 Node.js 全栈，是基于对未来复杂度的预判。团队预见到用户会需要后台任务处理、异步队列、大规模数据操作等能力，而这些在 Node.js 架构中不如 Python 生态成熟。

模型选择与组合策略：访谈中明确指出，不同模型有不同的擅长领域——Opus 是"工作马"，Codex 在后端调试上表现出色，Gemini 在前端表现更好。Emergent 的架构允许他们根据任务类型动态选择最适合的模型，充分利用每个模型的"长板"。未来他们预期这些模型会趋于"commoditized"（商品化），但在能力趋同之前，充分利用差异化优势是当前策略。

记忆系统的工程实现：跨会话学习的工程实现并非简单的数据存储，而是经过精心设计的流程——

• 收集智能体在历史会话中生成的轨迹
• 自动识别并提取可复用的"技能"
• 将技能提交给 CI/CD 流程进行验证
• 验证通过后加入长期记忆系统
• 未来的会话可以调用这些技能，无需重复学习

这使得平台上的智能体不仅服务于当前用户，还能够从全球用户的经验中持续进化。

5. 反直觉洞察与避坑指南 (Non-obvious Insights)

创业非共识

洞察一：网站不转化往往不是因为 UI 难看。这是访谈中最具冲击力的反直觉观点之一。创始人在对话中指出，大多数初创公司过度关注设计美观度，但实际上功能和设计之间存在巨大的权衡取舍。当一个平台过度优化设计时，功能往往会被削弱；反之亦然。真正的转化率提升来自于降低用户的认知负担——让非技术用户不需要理解什么是 JSON、什么是 API Key、什么是代码差异。一个"看起来简单"的界面背后，可能是复杂的工程挑战。

洞察二：第二梯队入场反而是优势。在 Lovable、Bolt 等竞品已经占据市场注意力的背景下，Emergent 选择以"第二梯队"身份入场。但团队判断，每一代新模型的发布都意味着一次重新定义产品边界的机会。当他们开始时，GPT-4 是主流，核心问题是 JSON 解析；到了 Opus 时代，机会变成了"超长程任务"和"多智能体协作"。第二梯队的真正优势在于：可以学习竞品什么不work，同时从完全不同的起点重新想象整个市场。

洞察三：全员客服不是浪费时间，而是最关键的产品开发活动。12 人团队保持一人始终轮值客服，创始人上线前五天亲自处理所有客服工单——这在"唯快不破"的创业早期看似"低效"，但实际上客服对话是需求金矿。通过直接倾听全球用户（法国用户、德国用户、阿拉斯加用户、挪威用户），团队能够跨越地理和文化边界，真正理解不同市场用户的真实痛点。

洞察四：软件工程岗位不是在减少，而是在增加。尽管外界担忧 AI 将取代程序员，但 YC 内部观察到的趋势相反——工具越强大，人们的想法越多，想做的工作也越多。这是一种"杰文斯悖论"：效率的提升并没有导致工作的减少，而是导致了需求的暴增。每个人（PM、设计师、工程师）的工作边界正在模糊化，一个曾经的 PM 现在可以自己写代码，一个设计师可以直接构建原型。

“死亡之谷"预警

技术陷阱一：架构选择的路径依赖。访谈中特别警告：如果从一开始就选择了只适合原型开发的架构（比如过度依赖前端框架、缺乏后台任务处理能力），后期想要扩展到生产级应用将面临"几乎不可能"的架构改造。除非从第一天起就解决了软件开发生命周期中的所有问题，否则从"简单用户界面"出发去"逐步增加能力"是极其困难的。很多团队在早期为了快速验证市场，选择了"先用起来再说"的架构，结果陷入了难以脱身的技术债务。

技术陷阱二：智能体的上下文窗口瓶颈。很多” vibe coding"平台在应用复杂度增加时会遇到一个临界点——模型的上下文窗口耗尽，导致智能体无法处理更复杂的任务。Emergent 通过多智能体架构和长期记忆系统提前规避了这一问题，但大多数团队直到用户开始抱怨"应用变得不稳定"时才会意识到这个问题。

增长幻觉一：错把"原型用户"当成"真实用户"。很多平台声称拥有大量用户，但这些用户可能只是在"玩"原型，并没有真正将应用用于商业运营。区分指标是：用户是否真的在构建"生产级应用"？他们是否愿意为平台付费？他们的应用是否有真实用户？Emergent 的一个关键判断标准是——用户是否在构建能真正运行其业务的应用程序。

增长幻觉二：忽视非技术用户的特殊需求。为技术用户设计产品是直观的，因为产品经理本身可能就是技术用户。但非技术用户的需求是隐性且反直觉的——他们不知道自己想要什么功能，不知道什么是"好的"用户体验，甚至不知道如何表达自己的困惑。一个简单的"代码差异"展示可能就会让一个非技术用户永久流失。访谈中提到，团队内部一位相当技术的 PM 在看到 JSON 时也会说"别给我看这个"——这说明技术恐惧的阈值比预期低得多。

6. 金句 (Golden Quotes)

• “如果你能解决验证（verification）问题，你就能自动化整个软件工程流程。验证回路是让智能体能够长时间稳定运行的核心。”
• “智能体的能力取决于你提供反馈的质量和速度——没有好的反馈循环，就没有好的智能体。”
• “编程只是整个软件生命周期的约 20%，将应用推向生产才是真正困难的部分。”
• “我们不是在和模型竞争——模型会越来越商品化，真正重要的是你与用户需求的距离有多近。”
• “除非从第一天起就解决了软件开发生命周期中的所有问题，否则从’简单用户界面’出发去’逐步增加能力’是极其困难的。你会做出很难逆转的架构选择。”
• “一个 QA 工程师出于好奇用’克隆 Jira’作为首个提示语，最终构建出完全适配我们工作流程的内部系统——这代表了’个人软件’的未来。”
• “工具越强大，人们的想法越多，想做的工作也越多——软件工程岗位不是在减少，而是在增加。”
• “人们不是只需要钱，他们是想要掌控自己想法的表达——没有什么比亲自用自然语言构建应用更好的方式了。”
• “在有限软件的世界里，那个结合临床心理学和马术的应用永远不会诞生；在无限软件的世界里，它可以诞生，700 万个其他应用也是如此。”
• “如果你有某种兴趣代理，你想创业，你想掌控自己的生活——AI 正在大规模赋能这一点。这才是真正被忽视的叙事。”

📺 视频原片

视频ID: 8SVocWnDHwE