5.3 一人软件工程全生命周期

一人版本的软件工程

传统软件工程有完整的生命周期：需求分析 → 设计 → 编码 → 测试 → 部署 → 运维。我们在第 4 章把每个环节都拆解了，看到了它们各自的"翻译损耗"。

现在来回答一个实际问题：当你一个人做产品时，这些环节应该怎么调整？

不需要全套照搬传统软件工程的流程——那是给几十人以上团队设计的，你用不上，也跑不动。但你也不能完全没有流程——一个人做事太容易陷入"想一出是一出"的混乱状态，今天做一个功能做到一半被另一个想法打断，两个都做不完。

我们需要一个"一人版本"的软件工程——轻量到一个人能跑完，但完整到不会遗漏关键步骤。

第零步：意图确认（5 分钟）

在动任何代码之前，先做一件事：把你的想法用自然语言写出来，然后让 AI 复述给你听。

"我想做一个帮助独立开发者管理订阅收入的工具。用户可以记录每笔收入，按月查看汇总，设置汇率自动换算。"

让 AI 复述："所以你想要的工具核心功能是：记录收入和支出、按月统计报表、支持多币种自动换算、最好能显示利润趋势。对吗？"

这个过程的作用是"校准"——当你听到 AI 复述的内容和你脑子里想的不一致时，你立刻就知道自己的表达哪里不准确。这比直接让 AI 生成代码，等发现不对再改，要快得多。

这一步 5 分钟就够。不要跳过它。跳过它的后果通常是：AI 生成了一大段代码，你看完发现"方向不对"——浪费的时间是 5 分钟的几十倍。

第一步：快速验证原型（1 小时）

意图确认后，不要让 AI 写完整的应用代码——先做一个验证原型。验证原型的目的是回答一个问题："这个想法可行吗？"用 AI 生成一个"看起来像那么回事"的原型。不需要完整的后端，不需要数据库，不需要登录系统。一个假数据的单页就够了。

这个原型给用户看，或者给你自己看，目的是判断"这个方向对不对"。通常会有 30%~50% 的方向性修正——你看完原型会意识到"哦，原来这个功能不是核心，那个才是"。这一步就是第 4 章说的"低成本试错"——方向偏了重来，成本只是一小时。

而且验证原型还有一个隐藏的好处：它迫使你把"想法"变成"东西"。很多人在"想"的阶段觉得自己的想法已经很完善了，但一旦做出来摆在面前，才发现很多"想当然"的假设是错的。这个"想法→实物"的心理转变，是创造中最关键的一步——它把模糊变成具体。

第二步：核心骨架（1~2 天）

原型验证通过后，进入"核心骨架"阶段。AI 生成应用的基本框架：

• 项目结构（文件目录、配置文件）
• 数据库设计与迁移脚本
• 核心 API 和前端路由
• 用户认证基础

在这个阶段，不要追求"功能完整"——追求"基础稳固"。数据库设计错了，后面的所有功能都要跟着改。路由设计错了，前端的功能拆分会很别扭。

这里有一个判断标准：如果 AI 生成的东西让你觉得"这个结构我看不懂"——停，让 AI 解释清楚再继续。骨架阶段的理解深度，决定了后续迭代的顺畅度。你不需要记住每段代码，但需要理解"数据库里的 users 表和 subscriptions 表是什么关系"这种级别的结构知识。如果你连这个都不清楚，后面往上叠功能只会越来越混乱。

第三步：核心功能迭代（3~5 天）

骨架搭好后，逐个实现核心功能。这个阶段的工作模式是：

1. 告诉 AI 下一个要做的功能
2. AI 生成，你跑起来测试
3. 提出修改意见，AI 调整
4. 确认后进入下一个功能

注意每次只做一个功能的修改——不要同时对 AI 说"帮我加搜索功能和数据导出功能还顺便改一下导航栏的颜色"。一次做一件事。因为一旦出了问题，你才能明确知道"是加这个功能引入的 bug"。

每完成一个功能后，跑一下现有功能，确保没被改坏。你不需要自动化测试，手动跑一遍就够——这个"跑一遍确认没坏"的过程只要两三分钟，但它能大幅减少"改了这个功能发现上一个功能坏了"的挫败感。

第四步：安全与边界检查（半天）

在所有核心功能做完之后，专门花时间处理安全和边界情况。这是一个"单独拿出来"的步骤，不是穿插在其他环节中的——因为人在做功能开发的时候，注意力集中在"让功能跑起来"上，很少主动想"用户用奇怪方式使用这个功能会怎样"。

针对你的产品问自己几个问题：

• 用户输入：用户在文本框里输入超长文本、特殊字符、HTML 代码会怎样？
• 权限：用户 A 能不能通过修改 URL 看到用户 B 的数据？
• 网络：用户在网络不稳定时操作，数据会丢失吗？
• 并发：用户快速点击提交按钮两次，会不会生成两笔订单？

这些边界情况你不需要全部处理——一人公司的 MVP 可以容忍一些"小瑕疵"（比如页面加载慢、输入超长没提示）。但你必须处理那些"有实际损失风险"的问题——数据丢失、用户隐私泄露、多扣用户的钱。

一个实用的方法：把你想到的安全问题列表发给 AI，"请检查我的代码是否存在以下安全风险：……"，然后让 AI 逐一验证并修复。你不需要是安全专家，但你需要知道自己产品的"风险点"在哪。

第五步：上线（半天到一天）

部署上线。这一步在 5.6 节会有详细的操作指引，这里只提一句：把你的部署过程也当作一个"和 AI 的对话"来完成。

"我要把应用部署到 Vercel，使用 PostgreSQL 数据库，域名是 myapp.com，帮我生成部署配置和指导步骤"——AI 会给你详细的步骤。你跟着走一遍，遇到报错直接贴给 AI 让它分析。

第一部署通常比较痛苦（因为很多意外情况），但之后的每次部署会越来越快。而且重要的是：一人公司不需要"零宕机部署"——你可以在凌晨发公告说"系统升级中，预计 1 小时"。

单人版本和团队版本的关键差异

总结一下，单人软件工程和团队软件工程的核心差异：

• 文档：团队需要文档来对齐所有人。一个人不需要——但你需要一个"TODO 清单"，否则你会忘。最简单的做法：在项目根目录放一个 TODO.md，把想到的事随时写进去。
• 测试：团队需要自动化测试来保证质量。一个人初期不需要——手动测试核心功能即可。但当你开始有付费用户后，自动化测试会变成必须。
• 代码审查：团队需要别人 review 代码。一个人没人 review——但你可以让 AI review。"请检查这段代码是否有性能问题或安全隐患"——这不是完美的替代（AI 也会漏），但聊胜于无。
• 分工：团队按角色分工。一个人按时间分工——上午做产品，下午写代码，晚上处理用户反馈。你需要规划自己的时间，不需要规划别人的。

从 MVP 到持续迭代

MVP 上线之后，工作流程会进入一个不同的节奏：维持 + 迭代。

维持是指：用户在使用中会遇到问题，你需要修 bug。迭代是指：用户会提需求，你需要决定哪些做、哪些不做。

在维持+迭代阶段，时间分配大概是：每周 30% 时间修 bug 和处理用户反馈，50% 时间做新功能，20% 时间做技术维护和优化。

这里有一个重要的决策原则：新功能的优先级永远低于用户反馈的处理。 一个人最大的问题不是"做不出新功能"，而是"用户反馈了你没改"。用户提了一个 bug，你花了五分钟确认是 bug，然后你说"下周修"——这个"下周"在用户那里传递的信号是"这个产品可能没人维护了"。当你的产品只有你一个人在维护时，响应速度是你最大的竞争优势之一。

很多一人公司创业者贪心地同时推进五六个新功能，结果一个都没做完，用户反馈的 bug 也没修。最后陷入了"功能半成品多 + bug 积累多 + 用户不满"的恶性循环。相反，保持"每个其实做一两个关键修复 + 一两个新功能"的节奏。慢就是快。