团队
在专注把事情真正做出来的过程中，结果背后的思考常常被忽视，甚至被遗忘。随着我们所面对的问题规模和复杂度不断增加，我们逐渐沉淀了一些值得记录与分享的经验。这些思考，来自工程、产品，以及组织层面一次次真实的取舍与决策。
接下来，我们将写下这些内容，把这样的思考展开。我们会分享我们是如何打磨产品，如何做决策，以及如何在规模、质量和速度之间取舍和平衡。希望这些内容，能让更多人更好地理解我们的工作方式，也帮助我们自身总结与审视我们长期坚持并且引以为傲的工程文化。
我目前担任Axon的全球首席产品及工程官。但在日常工作中，我的角色是MTS（Member of Technical Staff），这也是团队里很多同事的角色。
大多数时候，我的工作内容和大家并没有太大区别：写代码、看设计、参与技术讨论。Axon工程和产品团队中的其他负责人，也是如此。
我们一直坚信，负责制定方向的人，必须始终贴近一线工作。只有真正理解系统的细节，知道它在真实环境中是如何运转的，看清取舍发生在哪里、复杂性藏在哪儿，才有可能做出对长期真正有意义的决策。
在Axon，做Builder不是一个阶段，而是我们刻意选择、并希望长期保持的一种工作状态，甚至是一种生活方式。
这种理念，也直接塑造了我们的内部沟通方式。我们并不依赖大量精心包装的管理报告或PPT汇报，而是尽量通过“工作本身”来沟通。代码、数据看板、设计稿、系统的运行状态，本身就能说明问题。当沟通建立在真实运行的产物之上时，它更诚实，也能减少在传递过程中不可避免的信息失真。
我们的工程理念说起来并不复杂，但真正做到并不容易。
我们希望在同一时间，实现三件事：
我们并不认为这三者之间存在根本冲突。如果其中任何一件长期无法成立，通常不是方向错了，而是激励机制、组织结构，或者工程品味出了问题。
我们所负责的产品运行在非常大的规模之上，而我们的团队规模，往往比外界预期的要小得多。
这并不是偶然。
我们以多职能、技能相对均衡的团队方式运作。相比严格的角色划分和清晰到刻板的职责边界，我们更希望团队成员能随着问题的变化，在不同领域、技术和项目之间自然流动。
这样做的好处很直接：人更少，但决策更快；流程更轻，组织摩擦更低；更多精力被用在真正理解问题和解决问题本身。当然，这种模式对个人基本功和团队之间的信任都有极高要求，而这是我们选择这种工程文化所必须承担的代价。
我们不会把职责范围划分得非常死，几乎任何人都可以参与任何系统的工作。
这带来的直接结果是：团队不需要长期“守着”自己过去开发的系统，也不会被某个历史决策永久绑定。你把一件事做出来，把它打磨到符合标准，然后就可以放心交棒，继续向前。
系统的所有权和维护责任，并不属于某一个人或某一个小团队，而是由整个Axon工程团队共同承担。这种方式减少了长期系统中容易累积的隐形摩擦，也有助于避免信息孤岛的形成。
这一点可能和一些常见的认知不太一样：我们并不鼓励大量传统意义上的工程文档。
与其依赖文档去解释系统，我们更希望系统本身就足够直观。如果一个系统结构清晰、逻辑简洁、反模式少，它自然更容易被理解，也更容易持续演进。
很多时候，文档被用来弥补设计上的问题，而结果往往是文档很快过期、不完整，甚至没人再去看。与其不断修补文档，我们更倾向于从一开始就减少对文档的依赖。
这种选择降低了信息壁垒，也让共享责任成为可能，同时迫使我们在设计之初就保持更高的工程自律。
我们非常在意工程质量，也同样在意工程品味。
在一些关键问题上，当现有方案无法满足需求时，我们会选择自己构建高度优化的内部系统，深入到底，把性能和稳定性做到极致。我们最近开源的AxonCache，就是这样的一个例子。
与此同时，我们也刻意避免“不必要的自研”。在合适的地方，我们会毫不犹豫地使用成熟、稳定的基础设施和通用能力。这种取舍，是我们能够用相对精干的团队支撑大规模系统的重要原因。
我们在工程和产品层面都积极使用AI，但并不是把它当作噱头，而是把它当作真正的效率放大器。
在产品侧，AI被用于安全、产品智能和自动化；在工程侧，AI帮助我们调试问题、探索方向、处理重复性工作，也以“虚拟工程师”的形式参与设计和问题讨论。
我们对AI的潜力保持开放和期待，但同时也努力保持理性：在确实能带来价值的地方积极使用，对声量很大但实际收益有限的方向保持克制。
这个博客的目的其实很简单。
我们希望把一些在实践中形成的经验和判断记录下来，分享给那些同样用小团队、依靠高度信任来构建复杂系统的人。
有些文章会深入技术，有些会聚焦产品决策，也有一些会讨论组织层面的取舍。但所有内容，都会从 builder的视角出发——因为这正是我们每天工作的方式。