8.1
深览指数
科技少数派··AI 生成
Vibe Coding 时代的角色与架构
本文认为，Vibe Coding 带来的快速产出会加速软件架构的腐化，而非提升效率。作者系统梳理了从问题定义、用户研究、原型设计到工程实现的完整软件研发流程，强调每个环节都需要人类深度思考，LLM 无法替代。文章的核心价值在于提供了可落地的工程管理方法，如模型管理、文档规范和约束机制，以对抗快速开发带来的代码劣化，并反驳了“人类无用论”。适合正在实践 AI 辅助编程、并关注工程可持续性的技术管理者与资深开发者阅读。原文 ↗
核心观点
- ▍Vibe Coding 的快速产出会加速架构腐化，它不是提效工具，省下的时间应被用于清理历史债务和加强架构设计。
- ▍在 AI 辅助时代，人类的核心价值在于提出好问题、把控设计质量、并承担最终责任，LLM 无法替代人类对真实世界的共情与理解。
- 01软件研发类似建楼，需求变更发生在基础层级会引发广泛的地动山摇，导致工程出现大量飞线、复制粘贴代码和逻辑打结，形成“屎山”。
- 02用户画像的构建必须基于真实的用户研究（问卷、访谈），LLM 会捏造看似完整但不可信的虚构画像，因为它没有真实生活经验。
- 03作者推荐使用 User Story 和 Job Story 工具来明确需求边界，并通过 Journey Map 规划用户流程，将用户诉求桥接到功能设计。
- 04原型设计不可跳过，可以利用 LLM 快速生成低保真原型，但需结合成熟的设计系统文档（如 Material Design、HIG）迭代修正。
- 05开发应引入多个厂商的模型以获得多元视角，并持续观察模型在团队自身任务上的实际表现，而非仅看跑分。
- 06作者提出了一套三层 Agent 管理架构（Cycle Manager Protocol），并建议通过量化规则（如 Linting）来约束 Agent 行为，比提示词更稳定。
- 07文档管理需有标号系统（如 TN、CS、RQ、DVRV），并将纠错动作前移，从自查到审查再到代码评审，层层把关。
反方 / 局限
- — 作者承认这套流程看似“反敏捷”，但指出敏捷开发本身要求问题空间先于方案空间，若跳过上游定义，敏捷会成为“屎山催化器”。
- — 作者指出，模型厂商可能对上线模型进行剪枝、量化等优化，导致其实际表现与跑分不符，且这种表现是动态变化的，需要持续维护。
Vibe CodingMaterial DesignApple HIGIBM Carbon Design SystemCycle Manager ProtocolLLMGemini FlashGLM 5.2少数派
32 分钟 · 3 卡片 · 7 资料
读原文 →