开发工具与技术栈的选择

这篇小册想讨论的是 技术栈选择。 技术栈选择 的重点是把产品做成可维护、可部署、可排障的系统，不是追逐最流行的框架。 读这篇的人通常是需要快速交付并长期维护产品的独立开发者，所以先不要急着打开代码编辑器，也不要让 AI 直接替你“做完整方案”。更重要的是先把问题、约束、材料和判断标准想清楚。

为什么要先做这一步？因为独立开发最稀缺的不是工具， 而是判断力。你一个人做产品时，需求、设计、开发、运营和客服都会压到同一个人身上。如果 产品形态 没有写清楚，后面每一步都会变成返工。

这里采用“用维护成本约束技术选择”作为思考原则。 它的意思是：先看哪些材料真的能支持判断，再决定是否扩大投入。材料可以是页面截图、字段表、配置截图、命令输出、错误日志、订单状态、发布链接、客服记录或政策来源。

先建立边界。 今天你只需要围绕 产品形态、核心页面、数据结构、部署路径、日志和回滚 做判断，不需要把所有周边问题一起解决。比如字段没定清楚，就不要急着做复杂后台；状态没跑通，就不要先做完整会员系统；还没有上线，就不要先纠结高级监控。

你可以按这个顺序理解： 先确认产品是内容站、目录站、SaaS 还是工具；列出前端、数据、认证、支付、部署、监控模块；为每个模块只选一个默认方案；用假数据跑通列表、详情和提交路径；写下构建、预览、部署和回滚命令。它不是强制流程，而是一条避免漏掉关键判断的线索。读完之后，最好能让别人打开你的记录，看到你为什么这么判断。

建议你从 技术选型表 开始。 先建一个文件，标题就写「技术栈选择 - 技术选型表」。文件里放四块内容：当前判断、证据来源、暂不处理的部分、下一步触发条件。这四块比漂亮排版更重要。

如果你是小白， 最容易卡在 核心页面。处理方法是把它写成一句普通话：我现在要确认什么？我手上有什么证据？我缺什么材料？我今天能完成的最小动作是什么？只要这四个问题能回答，就可以继续推进。

一个可以代入的例子是： 把产品拆成首页、列表页、详情页、提交入口和后台审核。 这一步不要追求完整，先让它可见。你可以用 Notion、飞书表格、Excel、纸笔或仓库里的 Markdown 文件记录，工具不重要，关键是能被复用。

第二个判断是： 用一张表写清楚每类数据的字段、状态和来源。 这里要特别注意，不要只写结论。比如“功能应该没问题”不是证据，“页面截图、构建通过记录、错误状态截图和下一步待办都保存到了同一个文档”才是证据。

第三个判断是： 选择一个最小部署方案，并跑通本地构建和线上访问。 这一步通常会暴露取舍：哪些应该手动，哪些需要产品化，哪些暂时不值得做。把“不做什么”写下来，能帮你避免后面被新想法拖走。

第四个判断是： 补上错误日志、备份和回滚步骤，避免上线后不知道从哪里查。 想完后不要马上开新任务，先复盘一次。复盘只问三件事：这一步证明了什么？还有什么没有证明？下一步如果失败，应该缩小范围还是换方向？

建议沉淀的材料包括： 技术选型表、实体字段表、页面路径图、上线检查表。这些材料不只是给自己看，也可以作为后续让 AI 继续工作的上下文。你把材料写得越具体，AI 越容易帮你生成页面、代码、检查清单或下一步任务。

这件事最需要警惕的是： 最容易犯的错是过早复杂化：还没有用户和订单，就先做微服务、自建权限系统、多环境运维和复杂后台。 所以不要把“我看懂了”当成终点。真正有价值的是：你能解释取舍，知道哪些证据还不够，也知道下一步为什么值得做或不值得做。

AI 可以参与这件事， 但不能替你做判断。更合适的用法是：让 AI 帮你把草稿整理成表格，把步骤改成 checklist，把风险转成测试项，把输出改成可以直接执行的任务。关键决策仍然要由你根据产品目标和真实约束来定。

最后可以形成一个阶段性沉淀： 一份技术选型表和上线检查表。它不一定漂亮，但应该能被复用，能指导下一步行动，也能让别人快速理解你现在想到哪里、还差什么。