我花了45分钟搭建后端… 在写任何代码之前

Source: Dev.to

上周，我启动了一个新的 FastAPI 服务。
45 分钟后……我仍然没有写一行业务逻辑代码。
这并不是因为编码很难——而是因为 代码周边的一切都出了问题。

• 缺少 .env 键
• Docker 只能半路工作
• 数据库迁移不同步
• 一个内部服务悄悄地出错

如果你构建过不止一个后端，你一定有这种体会。

我们没有编码问题

我们面对的是 伪装成工程的搭建问题。
我们的大部分时间并不是在写逻辑，而是花在：

• 重新配置环境
• 修复看不见的依赖
• 调试我们之前已经调试过的东西

“上下文缺口”

Copilot 之类的工具可以帮助你更快写代码，但后端工作并不是在文件层面上进行的。它发生在 工作区层面。你的工具并不知道：

• 你的架构
• 正在运行的服务
• 你的约定
• 你的依赖

于是你得到的往往是：

• 更快的代码
• 同样破碎的系统

我尝试了不同的做法

我厌倦了这种循环，于是开始实验一个新想法：如果工作区能够理解系统本身会怎样？ 不仅是语法或文件，而是 实际的后端状态。

发生了什么变化

1. 不再盲目调试

• 缺失 .env → 立即检测
• 服务故障 → 运行前标记
• 依赖问题 → 早期可见

2. 符合架构的脚手架

• 干净的结构
• 生产就绪的配置
• 强制执行约定

3. 变更影响感知

重构前：“这将影响 3 个模块和 2 个端点。”

4. 带上下文的调试

不再把日志复制粘贴到 AI 中。系统已经理解错误所在。

我们忽视的转变

我们不再只是写代码，而是在管理系统。可是我们的工具仍停留在 “写这个函数” 的层面，而不是 “理解这个系统”。

好奇其他人是怎么处理的

你后端搭建中最让人沮丧的是什么？

• 样板代码？
• 调试？
• 环境问题？

欢迎分享真实的工作流。

https://www.workspai.com/