Arda Akgür
这篇文字并不讲述如何建造完美系统。我也不相信世界上存在完美系统。
这些是我多年来在搭建系统、写代码、教学生，以及观察正在运行的系统为何崩溃的过程中积累下来的原则。
对我而言，系统工程首先是解决问题，其次才是选择技术。
1. 系统中最重要的是稳定
你用什么基本逻辑搭建系统，系统开始运行之后，就不要不断改写那套逻辑。
参数可以改。可以做小优化。缺陷要修。但如果你在半路上不断改写核心规则，过不了多久你手里既没有最初的设计，也没有新的设计。
当真需要重大变更时，有时最正确的做法不是硬拧现有系统，而是启动一个新版本。
不要在比赛进行到一半时改规则。
2. 先建能工作的最简系统
不要从第一天起就为了百万用户、五年后的规模，以及尚未出现的问题去搭巨型架构。
那往往不是工程，而是 YouTube 式架构秀。
先建一个尽快解决今天问题、别人能看懂、而且真正能跑的系统。
若有一天你真遇到了规模问题，那是个好问题。说明系统已经活到了那一步。
需要 V2 时，你可以按另一种方式构建 V2。
3. 远离现状崇拜
大家都在用某种技术或架构，并不代表它适合你的问题。
“行业标准如此”本身并不是充分的技术理由。
先定义问题。再看什么最能解决这个问题。
若答案恰好是人人都在用的方法，就用它。若不是，不要害怕走不同的路。
忠于问题，而不是忠于工具。
4. 饿着或累崩时，别做重要决策
架构师最重要的工具不是电脑，而是自己的头脑。
饥饿和严重疲劳会毁掉决策质量。平时你会拒绝的方案，那时会显得“足够好”。你可能承担不必要的风险、容易烦躁，或只为收工而接受错误决定。
有时那种状态甚至会让人飘。你以为自己还能决策——判断力其实早已塌了。
那时你可以做例行工作：写代码、跑测试、查日志。但尽量不要做代价昂贵的架构决策。
若决策可以等到早晨，而你已经耗尽，就让它等到早晨。
饥饿与疲劳是你的敌人。
系统被设计之前，架构师自己必须处在可运作状态。
5. 代码变了，文档也必须变
每次有意义的代码更新，都要同步更新文档。
不要把文档当成完工之后的额外任务。代码与文档是同一次变更的两半。
现代 AI 工具让这件事比过去轻松得多。每次重要变更后，让 AI 审视改动与相关代码。生成描述系统当前状态的 Markdown，或更新已有文档。
尽量把文档以 `.md` 形式放在仓库里。Markdown 简单，版本控制好追，GitHub 上也便于直接阅读。
若后端变更影响前端，把相关 Markdown 分享给前端团队。
前端工程师应能在不先挖代码的情况下，理解端点如何工作、请求与响应结构、行为变化与注意点。
同样原则适用于团队之间、服务之间的变更。
AI 能加速文档，但正确性的责任仍属于做出变更的工程师。不要未经验证就接受 AI 写的文档。
代码更新了、文档却没更新，工作就还没做完。
文档是系统的记忆。
6. 先在脑中看见完成态
开始写代码之前，你应当能在脑子里看见系统的完成状态。
看不见就拿纸笔画。
不必是 ER 图。不必是 UML。不必符合任何人定的标准。
画方框、画箭头、旁边写笔记。怎么顺手怎么画。
重点不是图漂亮，而是你能看见整个系统。
若你试图用写代码去“发现”一个脑中还不存在的系统，你就会同时在设计和实现。
先看见。再动手。
7. 别忘了系统是为谁做的
不要轻视非技术管理者与用户的想法。
有时技术上看着奇怪的点子，其实是在用你从未想过的角度看问题。
他们的职责不是像你一样思考。
你的职责是理解他们想要什么，并尽可能把它变成可运行的系统。
听他们的梦想，并努力实现。结果有时会真正让你惊讶。
为将要使用系统的人而建——不是为你自己。
8. 架构师不能失控
每个严肃系统都需要失效安全机制。
必要时你应能用单个环境变量停掉系统。需要时要有受控的管理端点。要想好关闭关键部件的路径。
这些不该是穿透安全的秘密后门。它们应被授权、安全，并尽可能被记录。
无论系统多自主，架构师都绝不能变成自己系统的旁观者。
最终控制权必须留在架构师手里。
9. 先怀疑自己的错误
系统变慢时，别立刻怪硬件。
或许有你看不见的死锁。或许写了糟糕查询。或许有多余的网络调用。或许架构上的错误锁住了系统。
是的——硬件真的可能不够。
但先测量。
工程师必须能承认自己可能错。这没有什么可耻。
不能承认自己错的人，也修不好自己的错。
10. 培养学生
别让系统只活在你脑子里。
把系统教给你的学生。
若你明天不在，系统仍须能继续。让别人理解并改进它，不会削弱你的权威；恰恰证明你是好架构师。
只有一人能理解的系统并不强大，它很脆弱。
传递知识。
11. 与小而契合的团队共事
不要当独行架构师。也不要组建没必要的大团队。
与愿意学习、会倾听、会提问、仍保持学生精神的人共事。
批评很珍贵。初级工程师可能看见你漏掉的缺陷。听他们说。
但把持续反对当成工作风格的人，在建系统时很危险。每个决定反复争论，会迫使架构师不断改向，最终毁掉稳定性。
决定之前可以辩论。
决定之后，以团队执行。
你不必长期与用持续反对拖垮进度的人共事。
12. 要有创意，但保持简单
有经验的工程师看到好系统，应能说出“哇”。
而进入同一系统的好初级工程师，大约一周内也应大致明白发生了什么。
这两者并不矛盾。
真正的大师不是堆一百个服务，也不是发明谁都看不懂的抽象。
而是用出人意料地简单的系统，解决复杂问题。
复杂不是本事。
13. 别把每个新点子都塞进旧系统
新想法出现时，第一反应不该是往现有系统上硬加。
有时需要新服务。有时需要新应用。有时你真的需要 V2。
若试图永远扩展旧系统，最终你会在最初那个简单系统上堆满多年的决策与例外。
有时从零开始更便宜、更干净、也更正确。
变化并不总等于把当前系统做大。
14. 把人工智能当工具用
AI 能真正强化系统。
尤其是现代推理引擎，在构建阶段与运行时都非常强大。
它们能审代码、找边界情况、支持决策、理解自然语言，并处理经典算法吃力的模糊问题。
但别把一切都扔给 AI。
简单确定性方案够用就用它。推理真能增值就用 AI。两者更好就建混合系统。
给 AI 工作。别把系统上的权威交给它。
15. 别期望 AI 创造奇迹
AI 有多聪明，取决于使用它的人有多聪明。
问题描述错了，再强的模型也能很快给你错误答案。
你得知道自己要什么。你得足够理解问题才能评估答案。你得能看出它何时错了。
AI 不必代替你当工程师。
用得好，它扩大你的工程能力。
别期待奇迹。
16. 习性难改，屎就是臭
It is what it is.
别在每件事上寻找深刻含义。
有时 bug 只是 bug。烂代码就是烂代码。行不通的点子就是行不通。错误决定就是错误决定。
简单解释够用时，别用多余理论去打扮问题。
先看眼前的事实。
17. 别害怕模仿大师
当学生时，你不必发明一切。
我当学生时，为了学习曾从零重写像 ArrayList 这样的结构。目的不是发明新数据结构。
目的是亲手做大师做过的事，理解它如何工作，对照自己的方案，然后成长。
通过模仿学习不是抄袭。
先达到能做出大师所做之事的水平。试着理解他们为何那样做。然后质疑。再发展你自己的方法。
只因“要与众不同”而拒绝你还不懂的东西，不是创造力。
先学。再破。
结语
好的系统工程不是尽量多用技术的艺术。
它是理解问题，在脑中看见解法，尽可能简单地建造，保护能工作之物的稳定，并在需要时承认自己的错误。
好架构师首先了解自己的心智状态。饿着、累着、或无法清晰思考时不做重大决策，本身就是工程的一部分。
他们像保护代码一样保护系统的记忆。他们记录自己的变更，并把知识分享给继续建设系统的人。
他们掌控系统——但不崇拜它。
他们带领团队——但不压制学生。
他们使用人工智能——但不把思考外包给它。
他们向既往学习——但不向现状投降。
最重要的是：系统在跑，就试着理解它为何能跑；系统不跑，就试着理解它为何不跑。
其余都是工具。
Arda Akgür
ARC 系统原则
v0.1 Final