代码写到最后，面对的依然是手艺。

软件工程是个好词。它提醒我们，写代码不是搞艺术，是要交付、要维护、要协作的。工程手段——测试、规范、CI/CD、Code Review——做的都是同一件事：守住下限。

这是好事。有工程底线的团队，不会写出灾难。但他们也未必能写出好东西。工程流程可以保证你做到70分，但没人能靠流程达到90分。那是另一件事。

1

这件事，叫设计。

代码设计。架构设计。一个模块怎么切，一个抽象怎么建，一个接口暴露到什么粒度。这些东西很难被流程穷举。你没法在PRD里写清楚一个类的职责该怎么分配，也没法用lint规则拦住一个错误的抽象层次选择。

这需要判断力。而判断力，来自经验、审美，和一点说不清楚的东西。

就像建筑。施工方按图施工，保证房子不塌、不歪、不漏水。但房子长什么样，空间怎么流动，光从哪里进来——这是建筑师的事。工程保证下限，设计决定上限。

软件也一样。框架、中间件、流水线这些工程能力是施工标准。但核心模型的抽象、领域边界的划分、关键路径的取舍，是设计。是手艺。

2

所以软件这个东西，骨子里有个矛盾。

它既是大规模协作的工业品，又是高度依赖个体手艺的创作。你没法像拧螺丝一样拧出一段好代码，也没法靠流程审批出一个干净的设计。

这就带来一个常见困局：真正的好东西，往往出自少数人。但当这些人离开，东西就开始崩。

建筑不会这样。建筑一旦落成，结构就固定了。维护者拿着竣工图，知道承重墙在哪里，管线怎么走。软件不同。软件是活的，上线之后还在不断改建。今天加一个功能，明天拆一堵墙。如果最初的设计只存在于某个人的脑子里，没沉淀成可被理解的“图纸”——清晰的抽象、明确的边界、可执行的规范——那后来的每一次改动，都像是在承重墙上砸洞。

3

说这些不是要贬低工程。

恰恰相反，工程是让手艺能传下去的基础。没有施工标准，再好的设计也落不了地。伍重的悉尼歌剧院，贝壳顶方案惊艳世界，但结构上几乎无法实现。施工团队花了数年，才把它变成现实。手艺推高了上限，工程让它可能。

同样，软件里高手的直觉、经验、对复杂度的掌控，如果能通过工程手段“显影”出来——变成清晰的接口约定、模块化的边界、可被验证的架构约束——那这种手艺就不再只是个人脑子里的灵光一现，而是团队的共同资产。

4

所以也许，我们需要的是一种平衡。

在工程流程上，无情地标准化。构建、测试、部署，这些环节不需要个性。

在设计创作上，给手艺留出空间。承认有些决定，没法被流程替代。承认经验、审美甚至直觉，在软件里依然值钱。

最终，好的团队是这样：工程师们各自能写一手好代码，但他们的代码摆在一起，像一个人写的。而那个人，是一群人共同养护的手艺。