十多年后端工程之后，我为什么开始独立构建 SaaS、AI 产品和海外网站
这不是一次从后端到前端的转行，而是把十多年系统工程经验延伸到需求判断、完整产品交付和真实市场验证。
10+ 年工程基础
后端与系统工程
能力边界扩展
对完整产品结果负责
本文核心观点
- 我没有离开后端，而是把系统工程能力延伸到了完整产品交付。
- RAG、Agent 和 MCP 解决不同层次的问题，真正的难点仍在权限、状态、评估与可靠性。
- 海外网站、SaaS 和公开构建，是验证需求并沉淀长期个人资产的三种方式。
过去十多年，我主要在企业级后端系统里工作。
Java、Spring Boot、微服务、高并发、数据一致性和系统稳定性，构成了我长期的技术基础。这些经历训练我关注系统边界、异常处理、性能、可维护性，以及复杂业务如何长期稳定运行。
但随着做过的项目越来越多，我也越来越清楚一件事：
技术实现正确，不代表产品就能被用户理解、被市场接受，或者被持续运营。
一个真正可以上线并产生价值的产品，不只有后端系统。它还涉及需求判断、产品定位、用户体验、页面表达、交付节奏、部署运营，以及上线之后的持续验证。
这也是我开始独立构建 SaaS、AI 产品和海外网站的原因。
这不是转向前端，而是开始对完整产品负责
我现在做的，不是从后端转向前端，也不是用新的技术标签覆盖过去十多年的积累。
真正发生的变化是：我不再只对系统中的某一层负责，而是开始对一个产品从问题定义到上线验证的完整结果负责。
过去在成熟团队中，产品、设计、前端、后端、测试和运维通常由不同角色协作完成。作为后端工程师，我更多关注业务模型、系统边界、数据一致性、性能和稳定性。
独立构建产品之后，这些问题依然重要，但还不够。我需要同时判断：
- 这个问题是否值得解决；
- 第一版应该做到什么程度；
- 用户如何理解和使用产品；
- 前后端如何围绕同一条业务流程协作；
- 产品如何部署、运营和持续迭代；
- 上线之后，应该根据什么证据决定继续、调整或者停止。
Next.js、React 和 TypeScript 对我来说，不是新的身份标签，而是完成产品交付所需要的工具。
后端经验也没有被替代。相反，当我开始独立构建 SaaS、AI 系统和海外网站时，过去对业务、架构和长期维护的理解，成为我控制产品复杂度的重要基础。
为什么开始独立构建完整产品
在组织分工明确的项目里，一名工程师可以把自己负责的部分做好，却未必有机会看到产品从想法到市场反馈的完整过程。
独立构建迫使我把技术判断放进更大的约束里：时间有限、预算有限、用户注意力有限，很多需求甚至还没有被验证。
这时，工程能力不只是“把功能做出来”，还包括决定什么暂时不做。一个边界清楚、能够上线并获得反馈的第一版，通常比一个功能很多却迟迟无法交付的系统更有价值。
我想建立的，正是这种从需求澄清、范围控制、架构设计、开发测试到部署验证的完整交付能力。
为什么选择 SaaS
SaaS 是工程能力与商业问题结合得非常紧密的一种产品形态。
一个可以持续使用的 SaaS，通常需要处理账号、权限、订阅、工作流、数据、后台运营、通知、审计以及第三方服务集成。这些看起来是不同功能，背后仍然是系统设计问题：
- 如何拆分业务边界；
- 如何让核心流程可以扩展；
- 如何保证数据可靠；
- 如何控制第一版的技术复杂度；
- 如何让产品快速上线后仍能继续迭代。
这与我过去长期积累的后端和架构经验是连贯的。
我也希望把反复出现的工程问题沉淀成可复用的能力，例如认证、权限、后台管理、计费、审计和通知模块。它们未来既可能成为自己的 SaaS 或模板产品，也可以帮助其他产品更快完成第一版。
为什么开始构建 AI 系统，而不只是调用模型
我对 AI 产品的兴趣，不在于给网站增加一个聊天框，也不在于把大模型 API 包装成一个看起来聪明的演示。
真正值得构建的 AI 产品，需要让模型进入具体业务流程，并且能够访问可信的数据、使用受控的工具、完成多步骤任务，同时让整个执行过程可以被观察、评估和干预。
从工程角度看，大模型只是系统中的一个推理组件。一个能够实际投入使用的 AI 系统，还需要解决几个不同层次的问题。
RAG：让模型基于正确的业务知识工作
RAG 并不只是“上传文档，然后让 AI 回答问题”。
完整的 RAG 链路通常涉及数据采集与更新、文档解析和切分、向量索引、关键词与向量的混合检索、结果重排、上下文组装、数据权限、来源引用，以及检索和回答质量评估。
如果检索到的内容不正确、已经过期或者不属于当前用户，模型生成得再流畅也没有意义。
因此，RAG 真正解决的不是让模型“知道更多”，而是让模型在特定业务场景中，能够基于正确、及时、具有权限边界的信息进行回答和判断。
Agent：让模型围绕目标推进任务
传统应用通常由代码预先规定每一步操作。
Agent 的不同之处在于，模型可以根据当前目标和执行结果，决定下一步调用什么工具、是否需要补充信息，以及什么时候停止或把控制权交还给用户。
但这不意味着所有 AI 功能都应该做成完全自主的 Agent。对于步骤明确、风险较高的业务，更适合使用确定性的工作流，让模型只负责其中需要理解和判断的环节。只有当任务路径难以提前穷举，而且模型确实需要根据环境动态选择行动时，Agent 才能体现价值。
这里真正重要的架构判断是：
哪些步骤由代码确定，哪些步骤交给模型判断，哪些操作必须经过人工确认。
Agent 能不能工作，不只取决于模型能力，还取决于工具定义、上下文与状态管理、退出条件、超时与重试、成本限制和失败恢复。
MCP：让 AI 以统一方式接入外部能力
当 Agent 需要访问文件、数据库、代码仓库、企业系统或者第三方服务时，每个系统都单独开发一套连接方式，会带来大量重复工作。
MCP 提供了一种标准化的协议边界，让 AI 应用能够发现并使用外部提供的 Resources、Tools 和 Prompts：Resources 提供上下文与数据，Tools 提供可执行的查询和操作，Prompts 提供可以复用的交互模板。
它解决的是 AI 应用与外部数据、工具之间的连接和能力发现问题，而不是替代 RAG、Agent 或业务工作流。
并不是每个 AI 项目都必须使用 MCP。对于少量、稳定的内部 API，直接进行工具集成可能更加简单。只有当系统需要连接多个数据源和工具，或者需要让能力被不同 AI 客户端复用时，MCP 的标准化价值才会更加明显。
真正的难点仍然在模型之外
如果把这些概念放在一起：
- RAG 解决模型依据什么信息回答；
- Agent 解决模型如何围绕目标推进任务；
- MCP 解决 AI 应用如何发现和接入外部资源与工具。
但一个 AI 系统能不能真正上线，还取决于模型之外的工程能力：身份认证与数据权限、Prompt Injection 和工具调用风险、执行状态、超时重试、幂等和失败恢复、高风险操作的人工确认、Token 与延迟成本，以及 Tracing、日志、测试集和 Evals。
这些问题与我过去做后端系统时关注的边界、状态、安全、稳定性和可观测性是连贯的。
因此，我开始构建 AI 产品，并不是因为后端经验已经过时。恰恰相反，是因为 AI 从演示走向真实业务之后，仍然需要成熟的系统工程能力。
目前我正在构建 AI Business Agent Console，用它探索知识库、Agent 工作流、MCP 工具接入、人工审批、执行日志和质量评估如何组成一套完整的 AI 业务系统。
它目前仍然处于 Building 阶段。我会记录真实的设计和开发过程，但不会把尚未完成的能力提前包装成成熟产品。
为什么还要做海外网站
海外网站是另一种重要的产品实验方式。
与功能复杂的 SaaS 相比，一个聚焦明确需求的网站，可以用更低的成本验证：用户是否真的在搜索这个问题、现有解决方案有什么不足、哪种表达更容易被理解，以及这个方向是否值得继续投入。
不是每一个想法都应该发展成大型产品。有些适合做成小工具，有些适合做内容站，有些可以继续发展为 SaaS，也有一些在完成初步研究后就应该放弃。
对我来说，决定不做同样是一种有效结果。
我希望通过持续构建海外网站和小型产品，建立一套更真实的判断方法：不依靠想象讨论市场，而是尽快把产品放到真实环境中接受验证。
为什么要公开记录这些过程
我建设 yuzhe.dev，不只是为了放置一份在线简历，也不只是为了海外接单。
它会成为我个人工作的公开入口：展示正在构建的产品、已经完成的案例、做过的技术决策，以及项目从想法走向上线的过程。
我理解的 Building in Public，不是每天展示自己有多忙，而是留下可以被验证的记录：为什么选择这个方向，第一版包含什么，哪些功能被主动删除，产品如何测试和部署，上线后得到什么反馈，最终决定继续、调整还是停止。
这些记录首先帮助我复盘，也让产品用户、潜在合作方和其他开发者更准确地理解我的能力和工作方式。
如果未来我制作 SaaS 模板、课程或者运营社群，它们也应该建立在这些真实实践之上。更合理的顺序是先持续构建和交付，反复解决真实问题，再把稳定、可复用的方法整理成产品或内容。
我正在推进的三条线
接下来一段时间，我会推进三个相互连接的方向。
第一条是完整产品交付。帮助 Founder 和个人创业者把想法整理成可以上线的 Web 应用、SaaS、管理系统或者 AI 功能，重点是控制第一版范围并尽快进入真实验证。
第二条是自己的产品与实验。我会继续探索海外网站、SaaS 产品和可复用模板。它们不一定都会成功，但每个项目都应该产生明确的判断和积累。
第三条是公开内容与长期资产。我会通过 Blog、X 和视频记录构建过程，内容围绕产品判断、系统设计、AI 工程、独立开发和海外验证，而不是泛泛重复技术资料。
这三条线最终会共同构成我的个人品牌，但这个品牌需要由持续交付和真实作品支撑。
我给自己设定的几条规则
- 优先完成可以上线验证的版本，不不断扩大功能范围；
- 明确区分 Live、Building 和 Experiment；
- 不使用虚构的客户、收入、流量和业务成果；
- 技术选择必须服务于交付、运营和长期维护；
- 不只记录成功，也记录被放弃的方向和判断依据；
- 模板、课程和社群必须建立在真实实践与可复用经验上。
这些规则可能会降低短期的宣传效果，但更有利于建立长期信任。
接下来
yuzhe.dev 会成为这些工作的统一入口。
目前，StudioOps Admin 和 AI Business Agent Console 还在构建中。后续的海外网站、SaaS 实验和模板产品，也会在达到相应阶段后公开展示。
我不会假设每个项目都会成功，也不会提前为尚未发生的结果写结论。
我更希望持续回答一个具体问题：
一个拥有多年工程经验的开发者，如何把技术能力延伸到产品、交付和市场验证，并最终形成可以长期经营的个人业务？
这篇文章，是这段公开记录的开始。
如果你也在构建 SaaS、AI 产品或海外网站，欢迎通过 X、微信或邮件与我交流。如果你正在考虑把一个产品想法做成可以上线的第一版，也可以先整理一份 Project Brief，我们再判断是否适合继续讨论。