note

• 从 写代码的人，升级成 能定义问题、拆解系统、约束 AI、验收结果的人。既懂业务和系统，又能高效驾驭 AI，把模糊需求变成可靠交付。
• 软件工程精力从传统的样板代码编写、基础CRUD/路由开发等低价值重复性工作，转向架构设计、隔离审计、策略规范、验证与监控等高价值的架构相关工作。
• 从代码实现者，升级成系统设计者，练习四种能力：分层、接口、边界、变化点抽象。会写模块、设计模块关系、设计可演进的系统。

一、 Vibe Coding综述

【Vibe Coding经验进展】讲的发表于2026年第30届软件工程评估与评估国际会议（EASE2026）的经验报告，以2个生产级AI系统为实践载体，研究了上下文式VibeCoding（对话式AI辅助编码）在生产约束下的应用效果、问题与实践经验。工作在：Context Before Code: An Experience Report on Vibe Coding inPractice，https://arxiv.org/pdf/2603.11073

核心几点：
1）试验方式：两款需满足严格非功能需求的AI系统：多项目智能体学习平台（支持项目隔离的协作式AI学习平台，验证租户/内存隔离有效性、角色访问控制、异步任务执行稳定性）、学术检索增强生成（RAG）系统（支持引文追溯的文档查询平台，验证检索范围合规性、引文正确性、角色分离、大文档异步摄入可靠性）。采用Vibe Coding对话式开发工作流，开发者向LLM输入需求、架构约束和代码上下文，AI生成API路由、数据库模型等候选实现，人工对架构结构进行全程监督；

2）Vibe Coding核心价值是能大幅加速脚手架搭建、CRUD脚手架、基础路由、UI模板创建等常规代码编写和功能集成工作，快速实现功能原型；主要局限是无法主动遵循全局的架构约束，若提示中未显式定义，生成的代码会缺失隔离规则、基础设施限制等关键设计，且无法推导领域相关的策略与评估标准，无法替代人工的系统级架构设计；

3）核心实践建议：

• 一是架构约束必须在提示中显式定义，避免AI生成结构不完整的代码；
• 二是系统的策略与评估标准需人工设计，AI无法自主推导领域相关的管理规则；
• 三是基础设施决策需提前落地，尽早设计后台工作队列、缓存、监控等组件，避免同步执行引发的系统不稳定；同时需明确AI辅助开发的边界，将其作为明确架构约束内的开发工具，配合人工的架构审计与验证；

4）范式变化：软件工程精力从传统的样板代码编写、基础CRUD/路由开发等低价值重复性工作，转向架构设计、隔离审计、策略规范、验证与监控等高价值的架构相关工作。

二、怎么做

能力	以前	以后
实现能力	会写函数、类、模块	仍然要会，但不是核心壁垒
设计能力	知道怎么实现	知道为什么这么设计
约束能力	自己写代码时心里有数	能给 AI 清楚约束输入输出、边界、异常
验收能力	跑通就行	能判断可维护性、扩展性、稳定性

1、对开发者的新要求

能力	为什么更重要	典型表现
问题定义能力	AI 能写代码，但不会替你定义正确问题	能把模糊需求变成清晰 spec
系统设计能力	AI 擅长写局部，不擅长长期可维护系统	能拆模块、定边界、定协议
AI 协作能力	会用 AI 的人很多，会“调度 AI” 的人少	会拆任务、补上下文、迭代修正
代码审查能力	以后代码生成更多，review 更稀缺	能快速发现 bug、隐患、技术债
业务理解能力	越靠近业务核心，越难被替代	知道做什么最有价值
自动化能力	高价值不只是自己快，而是让团队更快	会搭脚手架、流程、评测、工具链

开发者提出的新要求包括：

• 一是需具备更强的架构设计与全局把控能力，能清晰定义并落地系统的核心架构约束；
• 二是需掌握AI生成代码的审计与验证方法，能识别并修正AI代码中缺失的架构逻辑；
• 三是需更注重基础设施设计与系统稳定性保障，提前规划异步处理、缓存、监控等核心组件；
• 四是需学会高效的提示工程能力，能通过显式的提示向AI传递完整的架构约束与需求。

2、六个设计能力

能力	具体要会什么
分层设计	controller、service、repo、model 各做什么
接口设计	输入输出、返回值、异常、兼容性
依赖管理	谁依赖谁，避免循环依赖
可扩展设计	哪些地方未来会变，提前抽象
配置化设计	把易变参数、策略、模板外置
测试友好设计	代码是否容易 mock、容易单测

3、具体事项

1）先学“分层”

先别急着背设计模式，先问每段代码属于哪一层：

• 表现层
• 业务层
• 数据层
• 工具层
• 领域层

比如一个“查询医院信息”的需求，不要全塞进一个函数里，而要拆成：

• controller / handler：接请求
• service：处理业务逻辑
• repository / dao：查数据
• model / schema：定义结构
• utils：公共能力

你只要先有“代码应该放哪层”的意识，就已经比只会堆函数强很多。

---

2）学会定义接口，而不是直接写实现

你以后要训练自己先想：

• 输入是什么
• 输出是什么
• 错误怎么返回
• 是否幂等
• 是否允许为空
• 调用方依赖什么，不依赖什么

比如不要直接说：

“帮我写个查路线的函数”

而要先定义：

class RouteQueryService:
    def query(self, origin: str, destination: str, mode: str) -> RouteResult:
        ...

重点是先把协议定出来。
AI 很会补实现，但“接口怎么定”更体现人的能力。

---

3）学会模块边界

很多人最大的问题不是不会写，而是边界乱。

比如一个模块里同时做：

• 参数解析
• 业务判断
• 数据查询
• 日志上报
• 格式转换

这就很难维护。

你以后每写一个模块，都问自己：

• 这个模块只负责一件事吗
• 这件事是不是太大了
• 有没有不属于它的职责混进来了

这其实比背单例、工厂更重要。

---

4）学会抽象“变化点”

设计的核心不是“优雅”，而是：

哪里将来会变，提前隔离出来。

比如：

• 模型会换
• 数据源会换
• 调用外部 API 会换
• prompt 模板会换
• reward 函数会换

那就不要把这些写死。

比如做大模型/agent，最常见的变化点就有：

• model backend
• prompt template
• tool registry
• reward plugin
• evaluation metric

这时候你就要做可替换设计，而不是一坨 if-else 写死。

---

5）学会验收标准

让 AI 写代码前，你自己先写出：

• 功能正确标准
• 边界 case
• 性能要求
• 日志要求
• 异常处理方式
• 单测覆盖范围

比如你不给标准，AI 只会给你“看起来能跑”的代码。

4、设计模式

模式/思想	用途	例子
策略模式	把可替换算法封装起来	不同 reward 函数、不同路由策略
工厂模式	统一创建对象	根据配置创建不同模型 backend
模板方法	固定流程，局部可改	统一评测流程，不同任务重写局部步骤
责任链	多阶段处理请求	query 先过澄清、再意图、再路由
适配器	统一不同外部接口	不同模型 API 统一成同一调用接口
组合优于继承	减少僵硬层级	tool、planner、memory 组合成 agent

优先顺序建议是：策略模式 > 工厂模式 > 适配器 > 责任链

三、平时具体怎么练

练法	具体怎么做	核心目的	你会获得什么能力	常见错误
练法 1：写代码前先画 3 个东西	先写模块图、数据流、变化点；哪怕只用几行文字列出来也行	先想清楚再写，避免上来就堆代码	模块拆分能力、整体视角、提前发现耦合点	一上来就开写；只想实现，不想结构
练法 2：让 AI 先出设计，不要先出代码	先让 AI 给模块拆分、接口定义、异常处理方案，再让它写实现	把自己从“代码执行视角”拉到“系统设计视角”	接口设计能力、约束 AI 的能力、方案比较能力	直接让 AI 开写；没有规范和边界，最后越写越乱
练法 3：每写完一段代码反问 5 个问题	检查职责是否单一、变化点、依赖是否写死、是否好测、3 个月后是否易懂	训练自我审查能力，避免代码只求能跑	代码 review 能力、可维护性意识、测试意识	只看功能是否跑通，不看长期维护成本
练法 4：读优秀项目时，不只看实现	多看目录结构、配置抽象、接口定义、分层方式、组合关系	学别人“为什么这样设计”，不是只抄代码	架构直觉、分层意识、抽象能力	只看函数写法，不看整体结构
练法 5：复盘自己以前写烂的代码	拿旧代码重新做分层、拆职责、抽接口、补测试	用自己的真实问题训练设计能力，提升最快	重构能力、问题定位能力、设计改进能力	只写新代码，不复盘旧代码；重复犯同样的问题

四、相关路线

阶段	你现在的目标	重点关注	你要学会的事	常见错误	达标表现
第一步：会写函数 → 会写模块	不只是写一段能跑的代码，而是写一个可独立使用的小模块	输入输出、职责单一、单测	明确模块输入输出；一个模块只做一类事；补基本单元测试；避免把解析、业务、存储、日志全塞一起	一个函数几百行；什么都干；没有测试；改一点就全坏	别人拿到你的模块，知道怎么调用、怎么测、怎么改
第二步：会写模块 → 会设计模块关系	不只是模块能用，还要让多个模块组合起来不乱	分层、依赖、边界、复用	知道 controller/service/repo/model 各放什么；控制依赖方向；划清模块职责；提炼公共能力而不是乱 copy	utils 大杂烩；循环依赖；业务逻辑乱穿层；为了复用过度抽象	新需求来时，知道该改哪层、加哪个模块，不会越改越乱
第三步：会设计模块 → 会设计可演进系统	不只是当前能跑，还要让系统以后好扩展、好维护、好排查	扩展点、配置化、稳定性、可观测性	抽出未来会变的部分；把策略、参数、模板外置；考虑异常、重试、降级；加日志、监控、链路追踪	写死配置；强耦合；一改需求就大重构；出了问题无法定位	模型/数据源/策略变化时能低成本替换；线上出问题能快速定位和回滚