从工程师到独立开发者：一次产品实践的起点
从公司离职以后，我突然拥有了大量可以自己支配的时间。
这可能是工作以来，少有的一段不需要围绕公司项目、会议和交付安排生活的时期。
不过，离职后的这段时间，我并没有真正闲下来。
重新按照自己的问题去学习
离职后的第一个月，我开始学习 AI Agent 相关的基础知识，并尝试搭建了一套本地企业知识库 RAG 系统。
从文档解析、文本切分、向量化和检索，到让大模型基于企业资料回答问题，我把一套最基础的流程完整走了一遍。
这次尝试并没有立即变成一个可以商业化的产品，也没有解决多么复杂的问题，但它让我重新感受到了一种久违的状态：
不是因为公司的安排，也不是为了完成某个版本，而是因为自己想弄明白一件事情，所以主动去学习、设计和实现。
过去在公司里，我也经常学习新技术、解决新问题，但大多数时候，学习都有明确的业务目标和交付期限。离开原来的工作环境以后，我第一次重新拥有了一段可以按照自己节奏探索的时间。
这种感觉很好。
两次没有结果的面试
学习 AI Agent 的同时，我也在继续寻找新的工作机会。
期间，我面试了两家公司。一家公司在做 AI Agent，另一家公司则来自一个我此前接触不多的行业。
为了这两次面试，我做了不少准备。我重新整理了过去参与过的项目，复习了后端架构、数据库、缓存、消息队列等内容，也针对不同公司的业务方向进行了专门准备。
最终，两次面试都没有拿到 Offer。
刚知道结果时，多少还是会有些失落。但冷静下来以后，我发现这两个机会其实都不是自己真正心仪的选择。
一个岗位的工作节奏与我现阶段对生活的期望并不一致，另一个岗位则需要长期异地工作，意味着需要在家庭和工作之间做出较大的妥协。
所以，没有拿到 Offer 未必完全是一件坏事。
有些事情在当下看起来像是错过，过一段时间再回头看，也可能只是把人推向了一条原本不会主动选择的路。
离开熟悉的职业路径
如果顺利进入下一家公司，我大概会继续做自己熟悉的事情：
进入一个已经存在的团队，理解现有业务和系统，处理不断出现的问题，然后完成一个又一个版本。
这是一条相对确定的道路，也是我过去十多年一直在做的事情。
但当新的工作机会没有按预期出现时，我开始认真思考另一个问题：
既然现在拥有一段完整的时间，为什么不尝试做一些以前一直想做，却始终没有真正开始的事情？
比如，做一款自己的产品。
过去十多年，我参与过不少企业软件项目。
我做过业务系统，设计过数据库和接口，也负责过系统架构、部署和长期维护。随着工作经验的积累，我开始参与越来越多的技术选型、需求讨论和交付决策。
但是，这些工作大多发生在一个已经确定的组织、产品和业务框架中。
真正从一个问题出发，自己理解业务、定义产品范围、决定功能优先级、选择技术方案，并最终独立完成一款可以交付的产品，对我来说还是第一次。
这件事情没有确定的结果，也没有一条可以直接照着执行的标准路径。
但它足够具体，也足够值得尝试。
从真实问题开始
我能够接触到一个真实的业务场景，也有潜在用户愿意参与产品验证。
这成为我决定开始行动的重要原因。
相比从一个抽象的想法出发，我更希望面对一个真实存在的问题。因为真实业务不会只停留在功能列表里，它会涉及实际的工作流程、角色协作、数据流转、异常处理和使用习惯。
只有进入真实使用环境，才能知道一个功能究竟有没有价值，一个流程是否足够顺畅，以及之前做出的技术和产品判断是否正确。
产品完成最小版本后，就可以交给真实用户使用，并根据反馈继续调整。
这让我第一次觉得，独立完成一款产品并不是一个遥远的设想，而是一件可以真正开始推进的事情。
先完成一个可以使用的版本
2026 年 7 月 1 日，我决定暂停主动寻找新的工作，把主要时间投入这次产品实践。
在随后几天里，我进一步整理了业务需求和开发范围。到 7 月 6 日，我开始正式进入产品设计和开发阶段。
现阶段，我更愿意把自己定义为一名独立开发者。
自己了解业务，自己整理需求，自己设计产品，也自己完成后端服务、Web 应用和移动端开发，并负责部署、维护和后续迭代。
这意味着，我不再只关注某一个技术模块。
除了写代码，我还需要考虑：
- 产品最先解决什么问题；
- 哪些功能必须进入第一个版本；
- 哪些需求应该暂时放弃；
- Web 端和移动端如何划分职责；
- 数据模型如何支持业务持续演进；
- 系统如何部署、监控、备份和升级；
- 产品完成后，如何让真实用户尽快开始使用。
第一阶段，我不准备追求一个功能庞大、设计完整的系统。
我更希望先打通最核心的业务流程，完成一个真正能够使用的版本。
如果它能够解决问题，就继续向下迭代；如果方向不对，也应该尽早发现并调整。
对独立开发者来说，时间和精力都是有限的。与其一开始就设计一个宏大的系统，不如先完成一个最小但完整的闭环。
从需求到设计，从前后端开发到移动端，从部署上线到用户反馈，每一个环节都真正走一遍。
从工程实现走向产品交付
过去做企业软件时，我更多关注的是如何把需求稳定地实现出来。
而这一次，我需要同时站在工程、产品和使用者的角度思考问题。
技术先进并不代表产品有效，架构完整也不代表用户愿意使用。
一个真正能够落地的产品，需要在很多事情之间不断取舍：
工程质量与开发速度、长期设计与当前需求、通用能力与具体场景、功能完整度与交付时间。
这些取舍没有唯一正确的答案。
很多决定只有在真实开发和使用以后，才能知道是否合适。
这也是我想在 Forge Notes 中持续记录的内容。
我不会公开具体的业务细节，也不会把每一次开发进度都写成流水账。但一些具有通用价值的技术选择、架构思考、工程方法和产品经验，值得被整理下来。
它们既是对这次产品实践的记录，也是对自己过去十多年软件开发经验的一次重新梳理。
一段意外获得的时间
现在回头看，两次没有结果的面试，反而让我获得了一段原本不会拥有的时间。
如果当时顺利进入下一家公司，我大概不会暂停熟悉的职业路径，也未必会真正开始做一款自己的产品。
所以，我愿意把这段时间看成一种命运的馈赠。
它没有直接给我一个答案，只是暂时拿走了原本最熟悉的选项，让我不得不重新思考接下来应该走向哪里。
我不知道这款产品最终会发展成什么样。
它可能成为一项可以长期经营的业务，也可能只是一次完整的独立开发实践。
但无论结果如何，我都希望完整经历一次从问题发现、需求整理、产品设计、技术实现到部署交付的全过程。
不再让它永远停留在想法、文档和计划里。
先把它真正做出来。
这就是这次独立产品实践的起点。