30年架构师的AI生存指南：为什么停止编码就会失去架构判断力

🎯 核心观点：动手编码是架构师的生存技能

Dennis Doomen（微软MVP、30年架构师、开源项目创作者）的观点直截了当：

"如果你不深入代码，就无法做出优秀的架构决策。"

在AI Coding飞速发展的当下，工程师的价值正从"如何实现"转向"解决什么问题"。但Dennis强调：停止编码的那天，就是失去架构判断力的开始。

---

👨‍💻 为什么是"动手型架构师"？

唯一有效的软件开发方式

Dennis称自己为"动手型架构师"或"编码型架构师"：

"作为架构负责人，同时保持动手实践，这是团队中唯一有效的软件开发方式。"

原因有三：

1. 实践经验验证设想

   • 架构师必须清楚自己在做什么，并通过实践不断验证
   • 观察方案在实际中的表现，即使只是修复缺陷也能学到大量经验

2. 发现教条化问题

   • 许多团队只是机械复制项目结构，不理解底层设计思想
   • 不深入代码库，很难发现这种"教条化"做法削弱了优化能力

3. 持续迭代改进

   • 架构包含假设，需要在实现中验证
   • 设计→实现→反思→调整，与敏捷开发高度相似

52岁仍在编码的原因

Dennis现年52岁，从事软件开发近30年，几乎无法想象自己停止编码：

"如果停止编写代码，不再亲自构建并上线生产系统，就会逐渐失去这些经验。"

---

🧠 AI时代的代码质量掌控

AI协作的真实案例

Dennis分享了他用Copilot开发.NET HTTP Mock库的经历：

1. 需求阶段：将GitHub issue分配给Copilot
2. 代码生成：AI生成了高质量的开源项目，实现了所有需求
3. 规范遵循：自动遵循了他的编码规范
4. 持续迭代：通过评论补充需求（断言方法、多版本支持等）
5. 人机协作：部分功能由AI生成，部分由他完成
6. 渐进优化：接受"够好"的代码，后续逐步重构

关键洞察：

"只要功能正确、测试通过，就可以接受，而不必立即优化。"

测试成为"安全网"

在AI时代，测试质量就是系统的"安全网"：

• 如果将实现过程视为黑箱，那么只要测试足够可靠，就可以信任系统行为
• 无论代码由人还是AI生成，测试是质量的最终保障
• 如何设计测试、测试什么内容，变得愈发重要

团队实践： 有些团队甚至会先编写测试和规范，再基于此生成实现。

---

⚖️ 复杂性与技术债务管理

软件工程的核心挑战

"软件工程的核心，无论过去还是未来，都是在已有系统与不断增长的复杂性之间维持平衡。"

复杂性累积的本质：

• 对过去决策缺乏理解却机械遵循
• 时间会放大这一问题，甚至决定系统成败

DRY原则的务实态度

Dennis对"避免重复"（DRY）原则持务实态度：

"在某些情况下，我会有意识地复制代码，以降低耦合。但这必须是经过权衡的决策，而非盲目复制或完全避免复制。"

抽象与务实的平衡

许多10-15年经验的开发者容易过度依赖设计模式：

• 为了"未来可能支持多种数据库"设计复杂抽象，即使当前并无需求
• 引用开闭原则或单一职责原则为过度设计辩护
• 这些抽象往往只是为"未来的可能性"做准备，而非现实需求

Dennis的观点： 不同数据库在语义上的差异，使这种抽象往往难以真正成立。

---

📝 决策记录：代码无法体现的"为什么"

提交记录的价值

代码本身往往无法体现决策背后的动机，而这些信息极易丢失：

"无论是提交记录还是代码评审说明，都应尽量记录决策意图，而不仅是技术细节。"

实践建议：

• 不仅说明"做了什么"，更要说明"为什么这么做"
• 使用AI自动生成提交说明，然后适当调整
• 高质量的历史记录对后续理解系统至关重要

架构决策记录（ADR）

对于非简单决策，应记录：

• 决策背景
• 备选方案及其优缺点
• 参与决策的人

价值： 当新成员加入或有人质疑方案时，可以清晰还原决策背景，避免重复讨论或错误推翻原有设计。

路径依赖的风险

记录决策确实可能导致"路径依赖"——团队过于坚持过去选择而忽视环境变化。Dennis的平衡策略：

"如果环境发生变化，应重新评估；如果没有变化，就不应轻易否定过去的决定。"

---

🎓 培养下一代工程师

与过去并无本质变化的方法

从真实代码库入手：

• 修复缺陷
• 完成小规模改进
• 逐步接触较大范围代码以理解系统
• 同时，鼓励他们不断提问

代码评审中的表情符号系统

Dennis在代码评审中使用表情符号传达反馈意图：

这种方法帮助初级开发者理解评论的重要程度。

AI辅助学习

如果开发者在某个问题上卡住：

"即使我知道答案，也可能会建议他们先借助AI工具进行探索，然后将结果作为讨论基础。"

优势： 提高效率，促进更深入的理解。

架构层面的"仍需人类判断"

AI目前难以完全胜任的问题：

• 抽象设计
• 依赖反转原则的应用
• 整体视角的判断

"只要系统仍需维护，我们就必须持续关注耦合、内聚等核心设计问题。"

---

🔓 开源的价值：在AI时代的重新审视

开源的成就感和协作体验

Dennis开发了多个.NET开源项目，包括被微软采用的FluentAssertions：

开源的回报：

• 看到他人使用项目并从中受益的成就感
• 社区提交修复或改进的协作体验
• 获得反馈、经验和新视角

开源使用规范

选择开源库时评估维度：

核心原则：

"开源代码在某种程度上也可能成为你的'自有代码'。关键不是简单判断'能不能用'，而是充分理解其风险与成本。"

AI对开源商业模式的影响

随着AI可以快速复现开源项目的部分功能，"开源+付费扩展"的商业模式面临挑战。Dennis的观点：

"很多人低估了构建高质量库的复杂度，即使借助AI，开发成熟工具仍需要大量时间与经验。因此，在大多数情况下，使用开源依然是更高效的选择。"

---

🚀 AI工具使用的实践智慧

实验环境的重要性

Patrick（主持人）分享：

"这种快速变化也带来了一定的焦虑，如果没有实验环境，很容易落后。"

教训案例：

• 完全依赖AI开发时，上下文被压缩导致理解丢失
• 甚至在主分支上直接提交了实验性代码

谨慎与审查

Dennis使用AI的经验教训：

"我曾使用AI工具修改代码，并频繁提交以便随时回滚。但后来发现某些修改被意外覆盖，甚至开始怀疑是自己操作失误。通过查看Git记录，才发现是AI在某次修改中撤销了我之前的更改。"

建议：

• 良好的分支管理
• 严格的代码审查
• 不要"确认测试通过"就盲目提交

工具选择的自由探索

不要强制统一AI工具。

原因：

• 工具变化极快
• 强制统一限制探索空间
• 合理方式：允许团队自由选择，跟踪使用情况并定期评估

成本与效率的真实计算

一些团队担心Copilot成本：

"但如果从效率角度看，这类投入通常可以在极短时间内收回，甚至带来数倍收益。"

使用AI的两极分化

过度依赖AI却缺乏判断能力：

• 无法验证生成代码是否正确
• 提交代码时不理解实现逻辑，只确认"测试通过"

刻意避免使用AI：

• 担心削弱自身学习能力
• 宁愿查阅资料、反复试错

Dennis的建议：

"可以使用AI，但必须确保代码质量达到团队标准，即使你不完全遵循某种方法论，也应具备相应的设计质量。"