宝软数字 · 内部文化 · 2026年11月8日
在宝软数字，有一句话每个新入职的工程师都会在第一天听到："你今天写的每一行代码，都是明天别人要读的文章。"这不是一句挂在墙上的口号，而是我们从无数次深夜排查Bug、无数次因技术债务而拖慢迭代速度的痛苦教训中提炼出来的核心信念。在AI工具日益普及的今天，很多人开始质疑"工程师文化"是否还重要——毕竟AI可以自动生成代码了。但我们的回答恰恰相反：正因为AI让写代码的门槛降到了历史最低，对代码质量的追求、对工程匠心的坚持，才成为所有技术组织最稀缺也最有价值的核心竞争力。
软件工程铁律：代码被阅读的次数远远超过被编写的次数。一段代码的生命周期中，90%的时间是在被阅读、理解和修改，只有10%的时间是在被最初编写。但大多数工程师的错误是——写的时候只考虑"怎么让机器正确执行"，而完全忽略了"怎么让下一个人（包括一年后的自己）快速理解"。
在宝软数字，我们对代码可读性有三条硬标准：第一，函数不超过30行——超过就拆，没有任何借口；第二，变量名必须自解释——我们禁止a、tmp、data这样的万能变量名，每一个名字都必须在第一次出现时就让读者知道它的业务含义；第三，任何复杂逻辑必须附带解释"为什么这样做"的注释——我们不需要"这段代码是干什么的"注释（如果代码需要注释才能看懂，先重构代码），但我们必须知道"为什么当时选择了方案A而不是方案B"。
好的代码像一篇优美的散文——从头读下来行云流水，每个段落只讲一件事，段与段之间的逻辑关系清晰可见。差的代码像一个被打乱的拼图——每个碎片本身可能不错，但拼在一起毫无逻辑可言。
许多公司的代码审查（Code Review）沦为形式主义——审查者快速扫一眼，留一句"LGTM"（Looks Good To Me），点击通过。这不仅浪费了审查者的时间，更浪费了整个团队最宝贵的学习机会。
在宝软数字，代码审查被赋予了完全不同的意义：它不是质量控制的一个环节，而是团队知识传播和标准共识化的核心机制。每个人的每一次Pull Request（合并请求）必须经过至少一位同事的审查，且审查者被要求"至少找出一个可以改进的地方"——哪怕这个改进很小。这不是刁难，而是刻意设计的学习触发器：当你不得不找出改进点时，你必须真正理解这段代码要做什么、想了什么、有没有更好的写法。这个过程本身就是最有效的在职培训。
更重要的一个规则是：审查意见永远针对代码，不针对人。我们禁止在审查中说"你这样写不对"，而是说"如果把这个逻辑提取成一个独立函数，这段代码的可测试性和可复用性会更好，你觉得呢？"语法的差异背后是文化假设的根本不同——前者假设写代码的人"犯了错"，后者假设写代码的人"可能有更好的选择"。
宝软数字的工程师团队在工具使用上有一个明确的原则：AI工具是能力放大器，不是思考替代器。我们鼓励团队使用AI辅助编码——它可以让一个重复性任务的完成速度提升5到10倍——但禁止不经审查就直接提交AI生成的代码。
这条规则的深层逻辑是：当你让AI帮你生成了一段代码，而你没有逐行理解它的逻辑时，你实际上是把对这段代码的"所有权"外包给了AI。代码进了仓库，但理解留在了外面。三个月后当这段代码出问题时，没有人真正知道它是怎么工作的——这就是技术债务的完美配方。
AI可以帮你写代码，但不能帮你理解代码。前者是效率工具，后者是能力积累。我们选择短期效率稍慢但长期能力不断积累的路径——因为我们的信条是"今日之工，明日之基"。
凡是做过几年技术的人，都见识过一种工程师类型——他们沉迷于技术本身的复杂度，喜欢在项目中使用最新、最酷的技术栈，即使项目本身并不需要。我们内部把这种倾向称为"技术自嗨"——它的驱动力不是为用户创造价值，而是满足工程师自己的技术好奇心。
在宝软数字，所有技术选型必须回答三个问题：第一，这个方案解决了用户的什么真实问题？第二，有没有更简单的方案能达到同样效果？第三，六个月后新加入的同事能在多短时间内理解和维护这套方案？第三个问题是我们的"技术自嗨检测器"——如果答案是"需要很长时间"，那么无论这个方案技术上多优雅，它都不是一个好的工程选择。
传统工程管理中有一个根深蒂固的恶习：出了问题先找"谁干的"，然后追责。这种文化导致的最直接后果就是没人愿意承认错误，所有问题都变成"不知道怎么回事"——而掩盖问题恰恰是阻止改进的最大障碍。
宝软数字对Bug的态度是工程文化中最重要的一条：每一个Bug都是系统反馈，告诉我们"这里有盲区"。我们不做"追责复盘"——出了线上问题，团队第一时间做的事情永远是：修好它（止损），然后问"为什么我们的测试没覆盖这个场景？我们的代码审查为什么没发现？我们的设计假设出了什么问题？"所有问题都指向系统层面，不指向个人。
这种文化带来的实际效果远比"以人为本"这句口号深刻：当工程师不害怕承认错误时，错误被发现的平均时间从"好几天"缩短到了"几分钟"。因为当事人第一时间就会在群里说："我刚才的一个改动触发了问题，已经回滚了，现在正在排查根因。"没有恐惧，就没有隐瞒；没有隐瞒，就没有小问题拖成大事故。
技术团队最怕的事情之一就是"核心人员离职"——他带走了对系统的理解，留下一堆没人看得懂的代码。传统的应对方式是"要求写文档"，但文档最大的问题是它永远是过时的——代码每天都在变，文档写了两个月后就变成了一份"历史遗迹"。
我们的解决方案不是要求更多文档，而是把知识传承变成一种日常习惯而非临时任务。具体做法包括：每次代码审查都是知识传递的机会（审查者必须理解代码才能提出意见）；每两周的技术分享会不要求准备PPT——找一个最近写的模块，打开代码直接讲设计思路和踩过的坑；所有架构决策必须写入ADRs记录，说明"当时我们面临什么选择、选了哪个、为什么"——这份记录的价值不在于当前团队的文档化，而在于一年后有人问"当时为什么这么设计"时，答案已经在那里等着了。
Code is Craft——代码是手艺，不是工业品。这个理念在AI时代听起来可能有点"过时"，但恰恰因为AI大幅降低了"写出能跑的代码"的门槛，"写出十年后仍然清晰、健壮、易维护的代码"的能力变得前所未有的珍贵。这种能力不是学一个框架或掌握一个工具就能获得的，它是日复一日对细节的死磕、对质量不妥协的坚持中慢慢长出来的。这就是宝软数字工程师文化的内核——和所有真正的手艺一样，它无法速成，但一旦内化，就没人能拿得走。
