别自称'工匠程序员'

# 别自称手工匠人程序员 来源：https://purplesyringa.moe/blog/dont-call-yourself-an-artisanal-programmer/ 2026年9月13日 我一直想写点东西，却掉进了这个兔子洞，现在甚至开始怀疑自己是否成了某种宣传的受影响对象。 软件开发AI话语中常见一种二分法：一方是重视最终成果的“严肃”工程师，另一方是比起产品更注重编码体验的“手工匠人”程序员。这种分类并不准确地描述我以及可能的许多人，但我们姑且顺着这个思路谈谈。 我希望我的程序可靠可靠。耐心和细致是实现这一目标的两个关键要素。当从头开始设计程序并花费充足时间时，我*清楚*它们是正确的，任何错误都只是拼写错误所致。单元测试、LLM审查和形式化验证器能保证代码99%正确，但无法保证100%：既无法保证最优、可维护、可读性，也无法保证它不会因为未文档化的不合规行为而产生依赖或崩溃。我想要那100%。唯有深入理解代码才能接近这一目标，因此我拒绝使用LLM——它们将我与重要的底层细节隔绝开来，且无法从构建层面保证正确性。 ### 对比 这正是该二分法在我眼中的崩塌之处。按传统定义，我算是手工匠人程序员，因为我不使用LLM。但如果业界将“手工匠人程序员”的反面称为“软件工程师”，这岂不暗含我不是工程师的意思？这看似细微，却在潜意识层面产生影响。关怀、专注与精确是工程学的*核心*特征——那为何这个词却被越来越像管理者的人群所挪用？ *在我那个年代*（清嗓子），开发者讨厌不愿花时间处理技术债务的管理层，“快速行动打破常规”的态度被视为幼稚。如今开发者间的共识是：氛围编程（我宽泛使用这个术语）才是常态，投入时间做可靠性工作反而显得不严肃。究竟谁才是对的？ ### 术语重构 在我看来答案显而易见：盲目构建东西的人配不上软件工程师的称号。工程师应该清楚自己在做什么。让我们请教更了解此话题的人。 2021年，Hillel Wayne主持了跨界研究项目(https://www.hillelwayne.com/post/are-we-really-engineers/)，采访了多位从其他工程领域转向软件工程的人士。他的目标是回答：拥有双领域实际经验的人是否认为我们的工作属于工程学？答案是“肯定的”，但更让我感兴趣的是： > 不过，许多跨界者也附加了额外条件：软件工程是真正的工程学，但许多编写软件的人并未从事软件工程。这不是他们的问题，而是我们领域的问题：我们缺乏足够的词汇来描述这些开发者的工作。并非所有与电打交道的人都是电气工程师；很多人会是电工。这很正常。[...]但我们却混用“程序员”、“软件工程师”和“软件开发者”这些称谓。软件工程师与软件开发者有何区别？有人提议用“软件匠人”这个词。 最触动我的是，Wayne使用的称谓与当下流行定义完全相反。他将那些用心关注、如今被我们称为手工匠人程序员的人称为“工程师”，而将那些被我们贴上氛围编程标签的人称为“匠人”。至少对我而言，这更符合直觉！可以说，提示工程中的艺术性甚至高于手动编写代码。 “手工匠人”作为“氛围编程”的反义词在历史上确有其合理性，但争夺这一术语的结果，实际上是放任了“氛围编程是否属于工程学”的辩论。氛围编程成了显而易见的默认选择，手工编码反而成了异类。我们如何走到这一步的？ ### 论据转变 若你审视这种“常识”的转变，会发现它无处不在。“唯一”且“正确”的方法论发生了*根本性*改变。为何我们曾将PVS-Studio的文章视为宣传材料，如今却对自动化审查工具顶礼膜拜？我们是如何从强类型系统迅速跃迁到自由形式规范的？ 编程界从未发生过类似事件。诚然，关于类型系统或Web框架优劣的争论一直存在，公共意见也随时间演变，但情况截然不同。强类型系统的坚定支持者可能视PHP开发者为傻瓜，但仍承认他们是开发者。即便是漫画化的Rust狂热者也仍是Rust程序员。过去的争论基于哪个选项更可靠、易用或易学，而非是否需要关心可靠性或滥用问题。 这次不同——氛围编程不被视为*更好*的解决方案，而被描绘成唯一*理智*的解决方案，全然蔑视过往经验。不使用LLM的人不是软件工程师，只是手工匠人程序员。这是对身份认同的攻击。 ### 历史重演 重构术语并将自己塑造成理智方、贬低他人不值一提，这种手段在软件界尚属新战术。但我以前见过：这本质上是法西斯主义的惯用伎俩。 我记得不久前我们还在调侃“氛围编程者的反义词是软件工程师”，仅一个月后，突然所有人都能坦然自称手工匠人程序员，将“软件工程师”的称号留给“负责任的AI用户”。这个术语如迷因般迅速传播，似乎毫无自然缘由。 我不相信这是有组织的心理战，但确实认为我们应该更谨慎地选择自称，因为语言具有力量。真正的作曲家自称作曲家，而非手工匠人作曲家；AI作家必须标明AI作家身份；但“程序员”一词从未引发争论，这产生了切实的现实影响。 许多捍卫艺术家、憎恶AI的游戏玩家一旦涉及软件话题就180度转变：突然认为LLM代码可以接受，声称“反正人人都用LLM”，且代码无需AI免责声明。他们不是专家，因此修辞比事实更重要。而我们大多人并不擅长修辞！ ### 为何是我们？ 我们本应更早吸取教训，我认为至少有一个因素导致我们首先在所有职业中输掉这场战役。写这篇文章前，我曾困惑：需要教育、勤奋工作和复杂思维才能进行的手工编程被视为游戏，而仅凭口耳相传的方法将想法灌入文本框却被奉为正统？ 现在我想，这是由于软件社区泛滥的反智主义。 在Rust普及且人人知晓其用途前，最常见的反对理由是什么？说它像纯数学，不适用于实际用途。对Haskell的指责至今未变，尤其是关于单子（monads）的部分——而Rust已经证明单子很容易理解（`Result`、`Option`和`Future`就是单子！）。见鬼，甚至指针也被认为复杂，因为，天啊，*使用前居然需要学习*！我们渴望简单的解决方案，但真正含义是拒绝阅读，只想从StackOverflow复制粘贴代码——哦等等，时代变了，现在是Claude。我们看着那些必须在大学学习才能工作的职业，说“实际上，我们比他们更优秀，值得主宰世界”。如果这都不算反智，我不知道什么才算。 因此*当然*我们贬低教育、勤奋、思考和投入时间的价值——这些都很“觉醒”，而我们超越于此。/反讽 ### 今后何为？ 我们需要更有力地反击。目标不是颠倒黑白，宣称避免AI是编写软件的唯一正确方式——这行不通；目标是确保无AI编码在公共讨论中保持一席之地，且不被等同于娱乐性编程。 术语方面，凡使用AI时我将使用“AI辅助编码”，手动工作时则用“无AI软件工程”。这保留了AI使用说明，但翻转了编程与工程的对立，并去除了可能被解读为玩乐的“手工匠人”一词。我认为这是个良好的起点，欢迎更多建议。 更广泛地说，我们需要挑战“AI辅助编程是编写代码唯一理智方式”的假设。公众明白将AI生成的艺术用于任何目的都令人不适；我们需要让他们相信同样的原则适用于AI生成的代码。如果目击AI“艺术”的人即使不懂绘画也能感到被欺骗，那么这一原则同样适用于程序。 我们需要谈论我们在软件开发中投入的关怀，如何设计代码，面临的问题，以及我们协作方式的美妙之处。我们应该强调：充满漏洞的速通之所以有趣，是因为我们能看到漏洞源自可理解的人为错误；计算机艺术有多么酷；开发者打磨应用以改善用户体验时多么暖心。我们需要谈论——我明白这不是我们的*专长*——我们的人性。 在这个艰难时期请保持安全。