从原型到生产代码：技术方案必须回答的四个问题
第三天上午，学员已经有了 PRD 和可交互原型。很多人自然地认为下一步就是让 AI 开始写完整项目。我却要求大家先停下来，补一份技术方案。
校园项目最容易省略这一步，因为一个人可以边写边改；企业协作不能把关键设计都藏在某个人或某段对话里。
技术方案不是技术名词清单
“前端 React、后端 Java、数据库 MySQL”只是技术选型的一部分。真正的技术方案要让团队在开发前看到系统怎样协作、怎样上线、哪里可能失败。
我要求方案至少回答四个问题。
一、技术选型：为什么用这些技术
技术选型需要结合团队能力、现有资产、运行环境和项目周期，而不是追逐最新框架。
对于训练营项目，机房已经准备 Java、Node 和 MySQL，本地运行条件明确。AI 如果建议额外安装 Docker、对象存储、消息队列或复杂微服务，学生应该判断这些依赖是否真的必要。
好的选型说明会回答：
- 是否沿用团队熟悉的语言和框架？
- 项目规模是否需要这项复杂度？
- 开发、测试和部署环境是否支持？
- 出现问题时团队有没有能力维护？
- 有无更简单的替代方案？
二、系统架构：模块怎样协作
最基础的 Web 项目也要说明浏览器、前端、后端和数据库之间的关系。
后端常见分层可以是：Controller 接收请求，Service 处理业务，Repository 与数据库交互。分层不是为了套模板，而是让接口、业务规则和数据访问拥有清晰职责。
系统架构还应标出用户端、管理端、公共服务、认证方式和第三方接口。对于订单流程，要能够追踪一次请求从页面进入接口、修改数据库，再返回页面的完整路径。
业务规则必须落在可信边界
第四天下午的注册登录练习暴露了一个常见误区：页面上能完成计算，不代表业务已经被正确实现。价格、库存、权限、积分等关键规则如果只写在前端，用户绕过页面直接请求接口就可能改变结果，也无法让多个入口复用同一套判断。
更稳妥的边界是：前端负责采集输入和反馈状态，Controller 负责 HTTP 协议与参数，Service 承担可复用的业务规则，Repository 负责数据读写。并非每个小项目都必须机械地拆成三层，但技术方案必须回答“最终由谁对业务结果负责”。
接口要表达资源、动作与失败方式
GET 常用于读取资源，POST 常用于提交会产生状态变化或复杂处理的请求；具体选择要结合幂等性、缓存、安全和业务语义，而不是把“参数少就用 GET”当作口诀。路径也应表达资源关系，例如 /users、/orders/{id}，不要把所有接口都写成含糊的 /doSomething。
接口草案至少要写清请求字段、响应结构、状态码、权限与错误语义。前后端端口不同还要说明代理或 CORS 策略；涉及数据的功能则要说明持久化方案、事务边界与测试数据如何隔离。这些内容决定原型能否真正进入生产代码。
三、部署架构：代码在哪里运行
本地能访问不等于可以上线。部署方案需要说明：
- 前端构建产物由谁托管。
- 后端服务运行在哪个环境。
- 数据库如何创建、备份和升级。
- 域名、HTTPS 和反向代理怎样配置。
- 配置与密钥如何区分开发和生产环境。
- 代码提交后如何触发构建与发布。
即使课程项目暂时只在本地运行，也应该知道未来上线需要补齐什么，而不是等最后一天才发现前后端无法连通。
四、整体风险：哪些假设可能不成立
技术方案最有价值的部分之一，是提前暴露风险：
- 第三方服务是否需要实名、付费或申请权限？
- 学校网络是否能访问依赖的仓库和模型？
- Windows 机房环境能否运行计划中的工具？
- 数据库账号是否有建库和迁移权限？
- AI 生成的依赖版本是否兼容？
- 项目上线是否涉及备案、隐私和安全要求？
风险不一定要当场全部解决，但必须有人负责验证，并设置替代方案。
AI 生成技术方案后，人要删什么
AI 很容易给出一份“行业标准、面面俱到”的方案。课程里常见的情况是，它为练习项目增加云对象存储、容器集群、缓存、消息队列和复杂权限体系。
这时开发者要主动做减法：
- 删除没有业务需求支撑的服务。
- 把陌生技术替换为团队可维护的选项。
- 检查前端形态与课程要求是否一致。
- 明确数据库迁移和接口文档方式。
- 将每个关键风险转化为开发前验证任务。
技术方案的目标是降低交付风险，不是展示技术名词数量。
开发前评审清单
- 技术栈与现有环境兼容。
- 前端、后端、数据库和第三方边界清楚。
- 核心数据表和接口契约已有初步设计。
- 开发、测试、生产配置不会混用。
- 部署链路可以解释并有负责人。
- 风险有验证方式和替代方案。
- MVP 之外的技术复杂度已经删除。
讲师判断：技术方案要优先消灭未知，而不是证明自己专业
初学者容易把技术方案写成名词清单：微服务、容器、消息队列、缓存全部出现，却没有解释为何需要。我更关注三个问题：最大未知是什么，最早怎样验证，失败后走哪条替代路径。对于课程项目，一个能在单机可靠运行、结构清楚的单体应用，往往比无法解释的复杂架构更专业。
方案评审时可以做一次反向压力测试：假设数据库不可用、第三方接口超时、部署环境不支持某个版本，系统会在哪里失败？哪些问题可以通过脚手架实验提前确认？技术方案只有转化成验证任务和决策记录，才真正降低了后续开发风险。
课后练习
拿你的原型反向画一张系统架构图：每个页面需要哪些接口，每个接口读写哪些数据，代码最终运行在哪里。再列出三个最可能让项目延期的技术风险，并在写业务代码前逐一验证。