Vibe Coding 如何减少代码失控-CSDN博客

在Vibe Coding的时候，随着代码量的增大，我们对于代码的了解越来越少，最后可能一点都理不清了，想要真正弄懂代码要花大量时间。

我觉得Vibe Coding想减少让代码失控，有个前提是使用者自身就要会懂代码，会写代码。

当然，不是懂代码就没有这个失控感了，代码失控一直都是客观存在的事实，那我们到底要怎么解决这个问题。

我在X上看到一篇文章，我觉得说的比较好，这篇文章说的很多东西跟我的脑电波对上了，提的很多建议也是我自己本身就在使用的。下面就结合文章和我自己的实践来说一下。

要减少失控感，我们不需要一行一行去看代码，而是可以通过架构这种形式去限制代码的书写或者代码文件的存放位置，比如写spirng项目的时候，会习惯于分controller，service，mapper层，将入参DTO和出餐VO等等吧，都提炼出来放到一个单独的文件夹下。这其实也是限制，在传统开发中，这些是限制开发人员的，防止开发人员到处乱放文件，导致项目混乱。

对于AI也是同样的道理，我们要限制好这些文件的目录，命名等。

我们职责不是去一行一行读代码，而是去定义边界，验收结果。

下面是作者给出的项目目录建议：

project-root/
├── AGENTS.md
├── docs/
│   ├── architecture.md
│   ├── api-contract.md
│   ├── frontend-patterns.md
│   ├── backend-patterns.md
│   └── core-flows.md
├── Front/
│   ├── src/
│   │   ├── app/
│   │   ├── pages/
│   │   ├── features/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── services/
│   │   ├── models/
│   │   └── utils/
│   └── tests/
└── Back/
    ├── app/
    │   ├── api/
    │   ├── services/
    │   ├── repositories/
    │   ├── schemas/
    │   ├── models/
    │   ├── core/
    │   └── utils/
    └── tests/

下面是具体每个文档中的详细内容是什么：

architecture.md

# 系统架构

## 目标
- 系统解决什么问题

## 系统边界
- Front 负责什么
- Back 负责什么

## 核心模块
- Front 模块
- Back 模块

## 数据流
- 请求如何进入系统
- 数据如何返回给前端

## 外部依赖
- 数据库
- Redis
- 对象存储
- 第三方 API

## 关键约束
- 安全性
- 性能
- 幂等性
- 可观测性

api-contract.md

# API 契约

## 响应包结构
- success
- data
- error

## 错误格式
- code
- message
- details

## 分页结构
- page
- page_size
- total
- items

## 命名规范
- snake_case 或 camelCase

## 时间格式
- ISO 8601
- 时区策略

## 版本策略
- v1 / 向后兼容

frontend-patterns.md

# 前端模式与约定

## 分层设计
- pages
- features
- components
- hooks
- services

## 状态管理
- 本地状态
- 服务端状态

## 数据请求规则
- 谁可以发请求
- 谁不能直接发请求

## 界面约定
- 表单
- loading
- 错误处理
- 权限控制

## 命名与目录规则
- 文件命名
- 目录命名

backend-patterns.md

# 后端模式与约定

## 分层设计
- api/router
- service
- repository
- schema
- model

## 参数校验
- 参数校验在哪做

## 事务规则
- 事务在哪一层开启

## 错误处理
- 异常类型
- 错误码

## 日志与可观测性
- 日志规范
- tracing 规则

## 测试策略
- 单元测试
- 集成测试

core-flows.md

# 核心业务流程

## 登录流程
- 用户输入账号密码
- Front 调用登录接口
- Back 校验并签发 token
- Front 存储用户态并跳转

## 列表查询流程
- Front 发起查询
- Back 校验权限
- Back 查询并返回分页结构
- Front 渲染列表

## 提交流程
- Front 表单校验
- Back 业务校验
- Back 落库并记录审计日志
- Front 提示结果

AGENTS.md

# 项目协作规则

在开始编码前，必须先阅读以下文档：
- docs/architecture.md
- docs/frontend-patterns.md
- docs/backend-patterns.md
- docs/api-contract.md
- docs/core-flows.md

硬性规则：
- Front 只负责展示、路由、交互，不负责影响数据一致性的业务规则。
- Back 负责业务规则、数据一致性、持久化和审计能力。
- 不要把影响数据正确性的业务判断写进 React 组件。
- 不要把校验逻辑、持久化逻辑混入界面层代码。
- 不允许随意发明新的 API 响应结构。
- 前端所有网络请求必须放在约定的 services 或 query 层。
- 后端必须保持 router、service、repository 的职责分离。
- 如果项目定义了视图模型层，页面组件不要直接耦合后端原始响应。
- 必须遵守现有目录结构、命名规则和模块边界。

前端实现规则：
- 优先按功能组织代码，放在 `Front/src/features/` 下。
- 通用 UI 组件放在 `Front/src/components/`。
- 可复用的业务 hooks 放在 `Front/src/hooks/`。
- 接口访问统一放在 `Front/src/services/`。
- 页面层只负责组合，不要在页面里堆积过多数据处理逻辑。

后端实现规则：
- Router 只处理 HTTP 输入输出，不承载业务编排。
- Service 负责业务逻辑。
- Repository 负责数据访问。
- Schema 负责输入输出边界和数据校验。
- 任何写数据库的路径，都必须考虑事务、审计和异常处理。

完成前检查：
- 检查 loading、empty、error、permission 等状态是否完整。
- 确认 API 结构符合 `docs/api-contract.md`。
- 确认错误处理方式保持一致。
- 确认需要的日志、审计点、事务边界已经补齐。
- 避免重复造抽象，优先复用已有模式。

这一套自己补充完并不断完善，我觉得意义和价值是很大的，我之前做项目的时候发现，不同的项目，其实里面也有很多内容是相似的，比如返回结果的封装，异常的定义等等，我通过一种脚手架的方式实现，但现在来看其实没有什么必要，直接使用AI来做约束。

如果遇到什么坑，就把经验和总结放到md文件中，这样AI下次就不会犯这错了，系统也就趋于稳定。

最后我想要说一句：不要让AI的快速绕过你自己思考这条路。你的思考是必须的，是前提，细细思考过后再让AI帮我们解决问题。