AI Coding 深度实践与架构洞察报告

核心主导：Jun

第一章：困境——从“嗑药般兴奋”到“生产力归零”

1.1 “Vibe Coding” 的蜜月期

Jun 作为一位有技术背景的产品经理，在项目 MVP 阶段利用 AI Coding 获得了极高的效率，他称之为 “Vibe Coding”——基于一个想法或感觉，通过不断与 AI 对话快速生成代码，验证想法。这个阶段，AI 展现了惊人的能力，尤其是在跨语言重构（如将 Flutter/Java 代码“翻译”为 Swift）和快速实现功能原型方面。

1.2 “生产力归零”之墙

然而，当项目从 MVP 转向正式产品，准备上架并长期维护时，Jun 遭遇了严峻的瓶颈：

• 熵增与混乱： 随着代码量和复杂度的增加，整个项目变得极其混乱。修复一个 Bug 常常会引发新的 Bug，增加新人手反而制造了更多混乱，最终导致 “生产力归零”。
• 知识天花板效应： Jun 发现 AI 的能力被他自身的知识上限锁死。当涉及复杂的 iOS 底层机制（如 `iOS 26` 的后台处理规范）时，由于自己不懂，无法向 AI 提出精准、正确的需求，导致 AI 使用“野路子”实现，造成了应用在长时间运行后崩溃。
• 信任危机： AI 生成了复杂的任务队列代码，但 Jun 缺乏足够的能力去审查和验证其正确性。这种“不知道对错”的状态导致了极度的不自信，不敢轻易合并代码。
• 架构师的“代码感”缺失： Jun 意识到，他和 AI 都缺乏资深架构师那种预判代码“坏味道”（Code Smell）的能力，无法预见当前的设计会在三个月后带来怎样的灾难。

第二章：激辩与洞察——AI Coding 的边界与新范式

2.1 两派观点的冲突

在讨论中，浮现出两种关于 AI Coding 的对立观点：

• oldhu (不可知论派)： 认为自然语言天生模糊，无法精确描述复杂逻辑。因此，AI 只应该被用来写 “原子化”的函数（功能单一、输入输出清晰、无副作用），一旦让 AI 介入架构或业务胶水层，项目必将走向灾难。
• spy (全能工具派)： 认为 AI 之所以写不对，只是因为你没描述清楚。只要能提供一份足够详尽、无懈可击的规格说明书 (Spec)，AI 可以完成 100% 的代码。

2.2 核心洞察：消除随机性

Sihao 指出：这两种观点殊途同归，核心在于 “如何消除从自然语言到代码之间巨大模糊空间所带来的随机性”。

AI 的工作过程是一个“熵减”过程。我们必须提供足够的 “锚点” 来框定 AI 的发挥空间，防止它“瞎猜”。这些锚点包括：

• UI/UX 设计图： 限制视觉和交互的随机性。
• 端到端 (E2E) 测试用例： 限制业务流程的随机性。
• API 契约 (Swagger/OpenAPI)： 限制数据结构的随机性。
• 清晰的架构和代码规范： 限制实现方式的随机性。

2.3 隐性知识的价值：Redis 案例

为什么没有经验的开发者无法有效驱动 AI？关键在于 隐性知识 (Implicit Knowledge)。

Wenjie 举例：当需要实现“防多端登录”时：

• 新手/小白： 只能模糊地告诉 AI “我要防多端登录”。AI 可能会给出一个简单的实现，但在并发场景下极易出错。
• 资深专家： 会直接告诉 AI：“用 Redis 实现一个单点登录队列，后来者挤掉前者。”——因为专家知道 Redis 是解决这类问题的最佳工具。

结论： 如果你连“Redis”这个词都不知道，你就无法给 AI 提供正确的、具有技术深度的上下文，AI 自然也推理不出稳健的方案。人的经验和知识，决定了 AI 能力的上限。

第三章：破局之道——回归结构化软件工程

3.1 架构先行：“脚手架”理论

当前阶段，纯粹的“Vibe Coding”或全自动的“AI Yolo”模式并不可行。业界正在形成的共识是混合模式：

必须由资深的工程师首先搭建好项目的 “脚手架”（英文常称为 Structure 或 Scaffolding）。这包括定义项目的目录结构、核心模块、编码规范、技术选型和基础设计。

这个“脚手架”为 AI 的代码生成提供了强有力的约束和清晰的生长环境。AI 在这个阶段的角色，更像一个需要明确指导的“超级实习生”，而不是一个全能的架构师。

3.2 架构变革：从分层架构到领域驱动设计 (DDD)

Jun 发现，传统的 MVC 分层架构（如所有 API 接口在一个目录，所有服务在另一个目录）对 AI 并不友好。当修改一个功能时，AI 需要在多个目录下横跳，极易因超出上下文窗口（Context Window）而产生幻觉或改错文件。

Sihao 建议： AI Coding 时代的架构，应更倾向于 领域驱动设计 (DDD) 的思想，按业务领域来组织代码。

• 按业务领域切分： 建立如 /modules/calendar、/modules/transcription 这样的目录。
• 高内聚： 每个业务模块内，包含其独立的 API、Service、Model 和测试。
• 收益： 当需要修改“日历”功能时，只需将 /modules/calendar 目录喂给 AI。AI 的注意力被 物理隔离 在一个高内聚的上下文中，准确率和效率将大幅提升。

3.3 “四屏工作法”：结构化的 AI 协作流程

为了解决 AI 协作中的混乱问题，Jun 总结并实践了一套高强度的 AI 协作流程：

1. 屏幕 1 (设计/辩论屏)： 绝不直接让 AI 写代码。先与 LLM 深度探讨技术方案，反复推敲，直到方案无懈可击。
2. 屏幕 2 (文档生成屏)： 将辩论后的最终方案，转化为详尽的规格说明书 (Spec)。
3. 屏幕 3 (执行屏)： 将清晰的 Spec 喂给 IDE 中的 AI (如 Cursor/Cloud Code) 进行代码生成。
4. 屏幕 4 (评审/测试屏)： 运行生成的代码，并让另一个 AI 扮演“Code Review”的角色，对照 Spec 检查代码实现，同时进行严格的测试和日志监控。

第四章：人的角色进化与未来展望

4.1 人的价值回归：从“码农”到“架构师”与“决策者”

AI 并没有让工程师贬值，而是将他们的角色向上推：

• 架构师： 负责定义系统的边界、规范和“脚手架”。
• 决策者： 进行关键的技术取舍（例如，为了降低复杂度，果断放弃对旧版本的兼容）。
• 审美与品味： AI 生成的 UI 可能趋同于“苹果冷淡风”，缺乏创意。人的审美和对产品调性的把控，变得尤为重要。
• 严格的审查者： 对 AI 生成的每一行代码负责，进行严格的 Code Review。

4.2 工程师会被取代吗？

短期来看，答案是否定的。讨论中的共识是：

“AI 不会干掉工程师，但会用 AI 的工程师会干掉不会用的。”

目前的 AI 极大地提升了个体的生产力，尤其是有经验的开发者。一个资深工程师 + AI，可以完成过去一个小团队的工作。但那个起决定性作用的、具备“代码感”和架构能力的“1”，仍然是不可或缺的人。

4.3 对未来的预判

随着大模型能力、工具链和记忆存储方式的不断进步，AI 在软件工程中的角色会越来越重。大型企业中那些规则清晰、框架统一的项目，理论上会更容易被 AI 深度赋能。然而，“代码即真理” (Code is Truth) 的本质不会改变——最终，清晰、完备、无歧义的逻辑表达，仍然要体现在代码本身，而驾驭这一切的，始终是具备深度思考和工程素养的人。