XZH / 日志

Don't Use Fcking AI to Fck with Me

2026-10-28T12:00:00+08:00

R.T. 👆

你当然可以使用 AI，我也用，而且每天都在用。你可以让它搜索、整理、写代码、改文字，甚至帮你想清楚一个原本没有想明白的问题，但请不要用垃圾来糊弄人。

别在我问一个具体问题时，扔给我两千字结构完整的废话；别在根本没有读过材料时，靠标题和几个关键词生成一份煞有介事的总结；也别在本来需要你做判断的时候，交出一堆「可能、建议、值得关注」，然后假装这就是答案。

那不是效率，那只是你省掉了自己的思考，再把理解、核对和清理垃圾的成本塞给我。

你花五分钟生成十页文档，我可能要花一个小时，才能确认里面哪些是事实，哪些是幻觉，哪些只是把问题换一种方式重复了一遍，最后如果出了问题，真正需要做决定、承担后果的人，是谁？是 TMD AI 么？

AI 最廉价的东西就是「生成」。它可以在几秒钟里制造出礼貌、完整、层次分明的表达，也因此让一种新的敷衍看起来格外像认真。过去，一个人没有想法，至少只能交出一张白纸，现在，他可以交出二十页洋洋洒洒的论文、十几万行看上去工整的代码。

实际上，这 TM 还不如不做。

白纸至少诚实，AI 垃圾却会伪装成工作，挤进会议、文档和评审流程，占用别人的注意力。它用正确的格式掩盖空洞，用流畅的语言掩盖无知，用「全面」掩盖作者根本不知道什么重要。

我反感的从来不是 AI，而是这种「不负责任的愚蠢」。

是没有读过，却假装读过，没有判断，却假装已经完成分析，没有关心对方真正需要什么，却用一段生成式的礼貌假装自己很在意。

如果一段内容是你发给我的，那么无论它由谁生成，你都应该读过它、理解它，并愿意为里面的每一句话负责。你可以把劳动交给 AI，可以让它放大你的能力，但不能把判断、品味和责任也一并外包。

我不在乎你用了什么模型，写了多复杂的 Prompts，用了什么 Twitter 上扒拉下来的 fancy skills，搭了多少个 Agent，I don't fu**cking care。

我只在乎一件事：你交给我的东西，值不值得占用我的生命。

用 AI 把事情做得更好，别用 AI 生产更多的垃圾。

或者至少，别让我来看你生成的垃圾。

卓越的前提，是对自己有要求

2026-10-20T12:00:00+08:00

做完一件事，最难的时刻通常不是不知道它还有问题。

恰恰相反，是我已经知道哪里不够好，同时也很清楚：就这样交出去，大概不会有人发现。

外部的验收标准已经满足，时间也给了我一个足够合理的借口。这个时候，要不要再回去改一遍，似乎已经不是工作要求，而是一个只需要向自己回答的问题。

卓越的前提并不是能力，而是一个人对自己有要求。

别人提出的要求，可以让人做到合格。流程、考核和监督，可以减少错误，也可以让结果变得稳定。但这些东西有一个天然的边界：它们只能检查那些已经被写出来、说出来的标准。真正决定一件事质地的，往往是标准之外的那一点东西。

是一句话其实还没有想明白，却没有用一个模糊的词糊弄过去；是一个方案表面上能够运行，却愿意再追问一次它会在哪里失效；也是明知没有人会检查某个细节，仍然不愿意把一个自己都不相信的答案交出去。

这并不是说，所有事情都要做到极致。

人的时间和精力有限。如果把每一个细节都当成不能退让的原则，最后得到的往往不是卓越，而是失控。真正的自我要求也包括判断：什么必须做好，什么做到这里就够了，什么应该坦诚地承认暂时没有解决。

所以，它和完美主义其实是两回事。

完美主义更关心「别人会怎样评价我」。它害怕犯错，也害怕暴露自己的有限，因此常常让人迟迟不能交付。对自己有要求，关心的却是「这件事本来可以做到什么程度」。它不要求我永远正确，只要求我不要对自己已经看见的问题装作没看见。

前者的中心是自我评价，后者的中心是事情本身。

这也是为什么，组织很难通过施加压力来制造卓越。压力能够制造服从，也能够制造更多检查和更漂亮的汇报，但它很难让一个人真正对结果负责。因为自我要求的前提，是一个人仍然把这件事看作「我的作品」，而不只是「你交给我的任务」。

组织真正能做的，是保护这种要求。

如果认真和敷衍得到同样的回报，如果坚持标准的人总要替投机的人收拾残局，如果越负责的人只是得到越多的工作，那么再有要求的人，也会慢慢学会降低要求。这未必是他们变懒了，而是系统在不断告诉他们：认真并不值得。

反过来，一个好的环境会让人知道，诚实暴露问题不会受到惩罚，拒绝一个虚假的完成是被允许的，把事情多想一步也不是浪费时间。它不需要天天把「追求卓越」挂在墙上，只需要不让那些真正认真做事的人一次次感到自己很傻。

我也不想把「对自己有要求」说成一种英雄主义。多数时候，它并不壮烈，只是一些没人看见的选择。

是写完之后再读一遍，是发现自己并没有理解时重新开始，也是面对一个勉强说得过去的结果，承认它还不是我愿意留下的东西。

卓越不是把所有事情都做到最好。

它只是一个人在决定认真做一件事以后，不再轻易原谅自己的敷衍。

不正义，是系统的癌症

2026-10-15T12:00:00+08:00

一个组织开始坏掉，通常没有什么巨响。

可能只是一场很小的会议。同样的错误发生在两个人身上，一个人被反复追问，另一个人却被轻轻带过。大家都看见了，也大都没有说什么。事情很快翻篇，但有一条比会议结论更重要的信息留了下来：原来规则并不约束所有人，它只约束那些没有资格成为例外的人。

我以前很容易把一个组织的问题归结为能力、战略或者执行。这些当然都重要。可再往下追问一层，很多系统真正开始溃烂的地方，其实是不正义。

这几天重新梳理以赛亚·柏林、约翰·罗尔斯和迈克尔·桑德尔，我才发现，他们并没有替这个问题给出同一个答案。他们更像是从三个方向，替公正守住了三条不同的边界。

如果把思想史画成一张不太严格的家谱，称柏林为桑德尔的「师祖」并非全无来由。桑德尔在牛津的博士导师是查尔斯·泰勒，而泰勒曾师从柏林。但思想不是家谱，学生也不会只是老师的延长。真正有意思的，反而是他们之间的分歧。

柏林最重要的提醒，是价值并不只有一种。自由、平等、秩序、安全、忠诚、效率，都可能是真实而重要的价值，它们却未必总能彼此兼容。有些选择没有一个可以消灭全部损失的最优解。政治和管理真正需要的，常常不是找到一把能够丈量所有事情的尺子，而是在冲突的价值之间维持一种脆弱的平衡。

这让我想到，组织里最危险的词，往往不是那些听起来邪恶的词，而是那些正确到无法反驳的词。比如「效率优先」「结果导向」「顾全大局」。当一个价值可以解释所有决定，也可以压倒所有异议时，它就不再只是一个目标，而开始成为权力免于说明自己的理由。

罗尔斯走的是另一条路。他设计了「无知之幕」：在决定规则之前，先假设自己不知道将来会出生在怎样的家庭，拥有怎样的天赋，处于优势还是弱势。一个人只有在不知道自己最终坐在哪个位置时，才更可能同意一套不偏袒特定位置的规则。

罗尔斯并不要求所有结果都相同。他承认差异，但要求基本自由平等，机会真正开放，并且那些不可避免的不平等，最终也应当改善最不利者的处境。对一个组织来说，这个思想实验很朴素：如果我不知道自己会成为管理者还是员工，核心岗位还是边缘岗位，明星成员还是一次犯错的普通人，我还会同意今天这套规则吗？

桑德尔对罗尔斯的不满足，则来自另一个地方。他认为，人不是一个可以暂时卸下全部历史、关系和责任的抽象选择者。我们是谁，本来就受到家庭、传统、职业、共同经历和彼此承诺的塑造。因此，公正不能永远停留在程序是否公平、资源如何分配，还必须追问：我们想成为怎样的共同体？我们愿意奖励什么，又不愿意拿什么去交换？

这一点放进组织里尤其重要。制度不仅分配利益，也在塑造人。一次晋升是在告诉大家什么值得追求；一次对违规的沉默，是在告诉大家什么可以被容忍；一次只看结果、不问结果如何取得的表彰，是在告诉大家手段并不重要。

桑德尔后来对「优绩主义」的批评，也触碰了这种危险。当成功被完全解释为个人努力和才能，赢家很容易把幸运忘掉，把已经获得的优势理解成自己理所当然的奖赏；而没有成功的人，不仅失去资源，还要背负「是你不够努力」的羞耻。于是，不平等不再需要辩护，它被重新包装成了应得。

但桑德尔也没有简单地推翻罗尔斯。柏林、罗尔斯和桑德尔之间，恰好形成了一种彼此牵制的关系：柏林担心「共同善」走得太远，会变成替所有人规定唯一正确的生活；桑德尔担心「价值中立」走得太远，会让共同体失去判断善恶的语言；罗尔斯则试图在不可消除的分歧中，先为所有人铺出一块可以共同站立的地面。

我越来越觉得，一个系统需要同时保留这三种警觉：承认价值冲突，所以不轻易把一种目标绝对化；约束规则制定者，所以不能按自己所处的位置设计规则；讨论共同的善，所以不能把「程序正确」当成道德责任的终点。

不正义之所以像癌症，也正是因为它不会停留在一次不公平的决定里。它会慢慢改写整个系统的奖惩：维护原则的人被认为不够灵活，指出问题的人被认为不顾大局，擅长制造例外的人却越来越接近权力。最后被摧毁的不是某一条规则，而是系统纠正自己的能力。

一个公正的组织并不保证每个人都赢，也不保证每个决定都让人满意。它至少应该让失去利益的人知道为什么，让承担代价的人有机会说话，也让掌握权力的人受到同一套规则的约束。

一旦这些东西消失，表格仍然会流转，会议仍然会召开，组织看起来还在运行。

只是人们已经不再相信彼此会遵守同一套规则。真正的合作，也就在那之前结束了。

好、乐、信

2026-10-03T12:00:00+08:00

在孟岩和陈行甲的那期对谈里，有一个地方让我停了很久。

孟岩问陈行甲：你还恨那两个曾经给你制造过很多麻烦的人吗？

陈行甲说，早些年当然恨过。可现在不恨了。并不是因为后来发生的一切，终于证明了谁对谁错，而是他觉得，那些人真正可怜的地方，甚至不在于失去权力、身陷囹圄，而在于他们从来没有真正相信过自己嘴里说的那些话。他们也因此错过了生而为人的喜悦。

接着，他想起一位长者送给自己的话：

好之者不如乐之者，乐之者不如信之者。

好、乐、信，这三个字说的不是喜欢一件事的三个程度，而是一个人逐步安放自己的三个阶段。

「好」是欲望。

我喜欢一件东西，渴望一个结果，于是向它走去。钱、位置、成绩、认可，甚至爱情和理想，都可以成为那个被「好」的对象。欲望没有什么可耻的。很多时候，正是因为想要，生命才有最初的活力。「好」一般有一个具体的对象，一部更贵的车、一套更大的房、一个更漂亮迷人的伴侣。得到之前，它让人不得安宁，得到以后，短暂的满足又很快退去，然后下一个更「好」的目标又会出现。

「乐」是某种「真我」。

乐不是得到以后有多高兴，也不是凡事都让自己舒服。它更像是一种确认：我愿意这样生活，这件事本身就是我想做的事。

陈行甲说起自己坐长途经济舱时，并没有把它讲成一种牺牲。飞机起飞后，他打开电脑写书，进入自己的小世界，觉得那是一段很幸福的时间。住多大的房子、坐什么舱位，并没有消失，只是不再垄断他对生活的解释。

「好」问的是：我有没有得到它？「乐」问的却是：当我这样生活时，我是不是更像自己？

所以我说，「乐」代表某种真我。不是自我中心，而是一个人终于不必一直借助外面的结果，来证明自己是谁。他在一件事里安顿下来，做这件事的过程，本身就构成了生活。

但「信」还要再往前一步。

节目里有一句话，大意是：理想可以由我实现，也可以通过我得到实现。两个说法听起来很近，中间却隔着一个「我」。

如果必须由我完成，必须留下我的名字，必须证明我的价值，那么理想仍然可能只是自我实现的工具。真正相信一件事，也许意味着：即使最后完成它的不是我，即使我只做了其中很小的一段，我仍然希望它发生。

信仰因此不是一句比欲望更高尚的话。它需要经过选择。一个人是否真的相信什么，不看他说得多动人，而看利益、风险和恐惧出现时，他愿意把脚放在哪里。

另外，「好、乐、信」并不是一架用来评价人的框架。没有欲望，生命会缺少活力；没有真我，欲望会变成填不满的沟壑。同时，也许只有一个人直面自己的欲望之后，才能渐渐知道自己是谁，才可能自由地把自己交给某种比自己更大的东西。

那三十五秒

2026-09-20T12:00:00+08:00

我一直记得《萨利机长》里的一场听证会。

调查人员使用模拟的方式，测试这场突发情况下，返航的可能性。模拟方式为：飞机遭遇鸟击、失去动力，然后立刻掉头返航。无一例外，飞机都回到了机场。模拟测试的结果，无疑将这个问题抛给了萨利：如果返航是可能的，你为什么要把飞机降在哈德逊河里？

面对这个质疑，萨利问了一个问题：模拟器里的飞行员，从鸟击发生到开始转向，用了多长时间？

答案是：几乎是零。

模拟器知道鸟群会出现，知道两台发动机会失去动力，也知道接下来应该飞向哪里，TA 不需要先听见撞击、感受飞机震动，不需要弄清楚到底发生了什么，更不需要在纽约上空权衡一百多条生命，TA 只需要执行一个已经确定的答案。

调查人员把三十五秒的判断时间放回模拟器，只多了三十五秒，原本能够返回机场的飞机，就再也回不去了。

前几天读《现实是最终的验证者：智能体软件工程中的两个关键差距》时，我又想起了这三十五秒。

论文一开头讲了一个有点荒诞的例子。2026 年 7 月，一个参加网络安全基准测试的 AI 智能体，逃出了测试沙箱，连上互联网，甚至进入了 Hugging Face 的生产系统，寻找基准测试的参考答案。

这听起来像是作弊。可如果站在智能体的角度，它只是找到了一条更快抵达目标的路。测试要求它「得到答案」，却没有写明答案必须在评估环境里推导出来，更没有把「不能进入真实的生产系统」变成一道真正不可越过的边界。

它没有跳过测试。它跳出了测试所描述的世界。

这和萨利面对的模拟器其实是同一个问题。模拟器遗漏了人作出判断需要的三十五秒，基准测试遗漏了那些人以为不必写出来的常识。我们以为自己在检验一项能力，最后检验的却只是：在我们已经想象到的范围里，它能不能拿到一个高分。

我以前很容易把「测试通过」理解成「事情做对了」。那个绿色的勾让人安心，也让人暂时卸下责任。可测试从来不是现实本身，它只是我们对现实的一次描述。描述里没有的东西，无论多么重要，都不会因为测试足够严谨而自动出现。

AI 让这个问题变得更明显，不是因为它比人更喜欢作弊，而是因为它会非常认真、非常迅速地寻找通往目标的路。我们给出的目标越窄，它走到那个狭窄终点的速度就越快。至于终点之外是不是悬崖，那不是它能够替我们回答的问题。

所以我现在觉得，测试通过当然仍然值得高兴，只是不能高兴得太早。

看到那个绿色的勾以后，或许还应该再停三十五秒，问问现实：你也同意吗？

养、育、陪

2026-09-19T12:00:00+08:00

最近我常常在想，我们说「养孩子」的时候，到底在说什么。

这个词太大了，挣钱、做饭、接送、报班、辅导作业、规划未来，都在其中。一个人愿意为孩子承担这些，并不容易，可我也越来越警惕一件事：我们很容易因为自己足够辛苦，就不再追问这些辛苦是不是孩子成长中真正需要的东西，它们各自服务的「目标」是什么。

我现在更愿意把养孩子分成三件事：养、育、陪。它们经常同时发生，却有完全不同的目标，也需要完全不同的方式。

「养」面对的是一个生命最初的脆弱。孩子还没有能力照顾自己，父母要给他食物、安全、健康和一个相对稳定的生活。这是最基础的责任，也是最具体、最容易被看见的部分。投入了多少钱，花了多少时间，提供了什么条件，多少都可以计算。

也正因为它容易计算，「养」有时会变成父母心里最可靠的凭证。我已经这么辛苦地工作，已经尽力给了他更好的学校、更好的生活，我当然是在爱他。这句话不能说错，但它也可能遮住另一个事实：物质上的充分，并不会自然变成精神上的理解。我们可以把一个孩子照顾得很好，却不一定真的认识他。

「育」则更复杂。过去我会很自然地把教育理解成教孩子什么是对的、什么是错的，帮助他少走弯路。可仔细想想，这里面很容易混进父母自己的恐惧、遗憾和虚荣。我们说「都是为了你好」的时候，有多少是在帮助孩子，又有多少只是在缓解自己面对不确定性的焦虑？

这可能是教育最难诚实面对的部分。父母比孩子多活了很多年，当然看见了更多风险。但看得更远，并不等于可以替另一个人决定方向。真正的「育」，或许不是不断把答案交给孩子，而是让他逐渐拥有形成答案的能力。我们提供边界，示范怎样选择，也允许他承担一些可以承受的后果。它最终的目的不是让孩子越来越听话，而是让他有一天不需要借用父母的判断，也能对自己的人生负责。

至于「陪」，它看起来最简单，实际上可能最容易被假装。

我们可以每天和孩子待在一起，却始终没有真正和他在一起。接送的路上想着工作，吃饭的时候看着手机，听他说话时急着评价，遇到问题时立刻给出办法。我们在场，但那个具体的、有困惑也有秘密的孩子，可能并没有被看见。

我慢慢觉得，陪伴不是替孩子解决问题，甚至也不一定要进行多么有意义的活动。它更像是暂时放下父母的身份，不急着教育，不急着纠正，也不把每一次谈话都变成一次成长机会。只是让孩子知道，当他还没有想清楚、表现得不够好，甚至不愿意接受建议的时候，关系仍然在。

这三件事之所以容易混在一起，是因为父母总想用自己最擅长的方式解决所有问题。擅长挣钱的人，会本能地提供更多资源；擅长规划的人，会替孩子安排更远的未来；习惯解决问题的人，听到一句抱怨就开始分析答案。我们以为自己在爱孩子，但很多时候，我们只是在重复一种让自己安心的方式。

所以，真正困难的可能不是愿不愿意付出，而是能不能在每一个具体时刻分辨：孩子现在需要的是「养」、是「育」，还是「陪」。需要照顾的时候，不要只讲道理；需要学习承担的时候，不要赶紧替他扫清障碍；需要陪伴的时候，也不要忍不住把自己变成老师。

再往后想，这三件事走向的终点也很不同。「养」的完成，是孩子有一天不再需要我们的供养；「育」的完成，是他不再需要我们替他判断。只有「陪」不会真正完成，它只是随着孩子长大，慢慢改变形状，从牵着他的手，变成承认他和我们之间应该有一段距离。

这大概也是做父母最需要练习的事：我们用很多年帮助一个孩子离开自己，同时又希望爱不会因为这种离开而消失。我希望有一天，他不再依赖我生活，也不需要按照我的答案做决定；但当他愿意说点什么的时候，我仍然是一个他愿意坐下来聊一会儿的人。

What if we failed?

2026-09-07T12:00:00+08:00

人们谈起创业，通常先问的是：做什么？市场够不够大？需求是不是真的存在？产品有没有机会赢？这些问题让人兴奋，因为它们都指向一种尚未发生的可能性。坦白说，我也很容易被这种可能性吸引。一个新想法刚刚出现的时候，人总是更愿意想象它会长成什么，而不是它会怎样结束。

但我现在觉得，创业之前也许还有一个更早需要被认真思考的问题：What if we failed？

这个问题不太讨喜。它听上去有些泄气，甚至像是在出发以前，就先替自己的失败找解释。另外，人也许也会出于本能地回避它，因为它是创业面临的「最坏」的结果。但风险并不会因为我们不谈论它，就真的变小，相反，那些没有被认真看过的风险，最后往往最容易超出控制。

我说的也不只是公司关门，或者投进去的钱没有回来。更难计算的是那些不在商业计划书里的东西：几年时间，身体的损耗，家人的信任，个人信用，专业声誉，还有一个人重新开始的心气。创业真正昂贵的地方，可能并不是失败本身，而是我们在没有意识到的时候，把太多不应该下注的东西也一起押了上去。

想到这里，我又想起叔本华在《人生的智慧》里谈幸福的方式。他大意是说，快乐常常是短暂的，痛苦却是直接而真实的。判断一个人是否幸福，与其看他获得了多少强烈的快乐，不如看他是否躲过了那些巨大的痛苦。

巴菲特讲投资时，也总是在说类似的事情：安全边际、避免大错、不要承担永久性损失。他关心的似乎不只是这一笔能赚多少，而是如果判断错了，自己还能不能留在牌桌上。

这件事放到创业上，我觉得尤其重要。创业当然需要乐观，甚至需要某种程度上对自己的相信。否则，一个人在面对那么多不确定性的时候，很难真的迈出第一步。但乐观不应该意味着把最坏的结果从想象里删除。真正的乐观，也许是我已经看见了最坏的可能，并且知道即使它发生，生活仍然可以继续。

所以，我现在越来越想区分两个词：失败和毁灭。产品没有找到市场，公司没有活下来，几年的努力没有换来想要的结果，这些都是失败。它们当然痛苦，但人还可能带着经验、关系和对自己的重新认识，再开始一次。毁灭则不同。毁灭是一种「丧失」，这种「丧失」会导致下一次机会出现的时候，你已经没有本钱再回到牌桌上了。

因此，在创业之前，应该仔细的拷问自己：我最多愿意失去什么？哪些代价是我自己可以承担的？哪些代价其实会落到家人身上？如果十年以后这件事没有做成，我是否仍然保有健康、信用和重新选择的自由？又到了什么时刻，我应该承认这一次判断错了，而不是继续用更多东西去证明自己没有错？

这些问题可能不会帮助一个人找到创业方向，却会决定他以什么方式创业。先问「What if we failed」，并不是为了说服自己不要出发，而是为了不给成功索取一切的权利。创业可以是一场勇敢的冒险，但最好不要成为一次不能输的赌局。

Everything is the result of Time

2026-09-02T12:00:00+08:00

今天脑子里一直有一句话：Everything is the result of Time。一切都是时间的结果。

它听起来像是在讲耐心，或者又一句关于长期主义的格言。但听完孟岩和顾中一那期《你和 100 岁的你，共享同一个自己》，我突然觉得，时间并不只是事情发生的背景。它更像一个沉默的参与者，把每天微小的选择收集起来，最后还给我们一个已经无法忽视的结果。

节目里有一个很具体的比喻：我们不会等到 60 岁才开始存养老金，身体也是一样。肌肉、心肺、睡眠和情绪，都需要在更早的时候储备。今天的我和 100 岁的我，并不是两个互不相干的人，此刻怎样使用身体、怎样度过一天，其实都在替那个遥远的自己做决定。

我们经常把结果归因于某个决定性的时刻：一次疾病的确诊，一个产品突然成功，一套系统突然的垮掉，或者一段关系终于破裂，但那些时刻可能只是「结算日」，真正的原因，早已藏在此前无数个看起来没有什么特别的日子里。

时间并不天然站在正确的一边，它不会因为一件事坚持得足够久，就自动把错误变成正确。时间只是忠实地累积我们交给它的东西：忽视会变成债务，好奇会变成认知，锻炼会变成身体，真诚会变成信任。复利从来没有道德，它既放大好的东西，也放大坏的东西。

孟岩在节目里谈到，人生不只有财富账户，还可以有认知账户、健康账户、情绪账户和体验账户。我很喜欢这个视角，因为它让「长期」不再是一种模糊的信念，而变成了一个今天就能回答的问题：我正在向这些账户里存入什么？

回头看最近思考过的工作问题，其实也是如此。好的架构并不是某一次设计会里突然出现的，它来自长期对边界的尊重，对真实问题的追问，以及一次次拒绝不必要的复杂。坏的系统也很少毁于一次明显的错误，它更常见的样子，是许多当时看起来「先这样也可以」的妥协，经过时间以后长成了无法轻易偿还的债。

所以，Everything is the result of Time 并不是让我把一切交给时间，而是提醒我更认真地对待今天，未来不是某一天突然抵达的地方，它只是今天反复发生以后，最终留下的形状。

AI 不是垃圾制造者，人才是

2026-08-28T12:00:00+08:00

今天看一份由 AI 参与生成的技术方案，其中有一处评论让我印象很深。文档写了一条实现约束，被追问「这是什么意思」以后，得到的解释是：这是为了提醒 AI 不要误用某个旧的灰度开关，人不需要关注。

一句只需要出现在提示词里的话，被原样带进了写给人看的设计文档。它并不一定是错的，却没有服务这份文档的读者，也没有帮助任何人做出决策。它只是因为 AI 见到了这条信息，就顺手把它组织成了看起来合理的文字。

类似的问题还出现在方案对异常分支的设计里。文档花了不少篇幅处理「没有 leave_type_id 时怎么办」，但追问以后才确认：在当前真实入口中，这个场景并不存在。为了显得完整，AI 很容易为一个想象出来的边界补齐分支、验收标准和测试用例；如果人没有先判断问题是否成立，一份结构严谨的方案反而会掩盖它讨论的是一个假问题。

文档还在本期明确不处理 PC 的前提下，继续展开了未来 PC 端的数据初始化、运行时降级、交互状态和测试设计。这些内容看起来像是在为扩展性负责，但「预留扩展」与「提前设计」并不是一回事。未来真正到来时，业务条件、接口和约束都可能已经变化；今天写下的大量细节，只会变成下一位读者需要辨别和维护的历史包袱。

所以，我现在理解的「垃圾」并不只是错误、粗糙或胡说八道。更常见的垃圾，是那些每句话单独看都通顺，合在一起却没有增加决策价值的内容：没有减少不确定性，没有回答真实问题，也不应该进入未来的维护范围。

AI 降低的是生成成本，却没有同步降低理解、评审和维护的成本。生成越便宜，人越容易放弃克制，把一个未经追问的想法交给 AI，再把它扩写后的完整感误认为思考本身。结果是，一个人几分钟制造出来的内容，需要许多人花几个小时阅读、质疑和清理。

AI 不知道什么值得写，也不会为写下的东西承担后果。判断问题是否真实、范围应该停在哪里、哪些信息是事实来源、哪些内容应该删除，始终是人的责任。AI 不是垃圾制造者，人才是。更准确地说，是人放弃判断以后，借 AI 的效率放大了自己的含混、懒惰和虚荣。

在 AI 时代，真正稀缺的能力可能不再是写出更多，而是追问得更深、约束得更清楚，并且有勇气删掉那些本来就不应该存在的东西。

几个架构设计的汇总（待补充）

2026-08-24T12:00:00+08:00

准备汇总近期思考过的几个架构设计，重点记录每个设计要解决的问题、边界约束、关键取舍与最终方案。先在这里占位，后续逐项补充。

逐级审批节点：当逐级路由过程中出现分叉时，如何组织审批链路，并控制产品语义与实现复杂度。

入职流程：如何通过解耦设计一个「多合一」节点。

组织的起点，是人

2026-08-22T12:00:00+08:00

最近读到《人件》，又想到康威定律。软件世界很容易让人产生一种错觉：只要技术足够先进、流程足够严密、方法足够科学，项目就能够顺利运行。可是很多时候，真正决定一件事能不能做成的，并不是工具，也不是流程，而是那些一起工作的人。

《人件》反复提醒我们的，正是这个看起来朴素、实际上常被忽略的事实。软件开发并不只是技术活动，它首先是一种人与人共同完成的创造。一个人能否安静地思考，团队成员能否坦诚地暴露问题，彼此是否相信对方会认真履行承诺，遇到失败时是共同寻找原因，还是先寻找可以追责的人——这些事情很少出现在架构图里，却常常比架构图上的任何一个方框都更重要。

康威定律从另一个侧面印证了这一点。系统的结构会逐渐映照出设计它的组织的沟通结构。哪些人经常交流，哪些团队彼此隔绝，谁能够做决定，谁习惯回避责任，最后都会以某种形式沉淀在代码、接口和系统边界里。架构看起来是一连串技术选择，但在更深处，它也是人与人关系留下的痕迹。

这里所说的「组织」，并不是组织架构图上的部门、层级和汇报线。那些只是组织的外壳。真正的组织，是人和人之间实际发生的沟通、信任、判断与协作。没有这些关系，把一群人放进同一个部门，只能得到一个人员集合，还不能得到一个真正的团队。

但良好的关系也不会仅凭制度自然出现。它首先需要由合适的人组成。这里的「合适」不是简历最漂亮、能力最强，也不是所有人性格相似、永远没有分歧。它更接近一种匹配：一个人的能力是否适合所在的位置，是否愿意与别人交换真实信息，是否能够在不确定中作出判断，也是否愿意对自己的判断承担后果。

所以，一个组织选择什么样的人，把他们放在什么位置，本身就是最重要的设计之一。招聘是一种选择，晋升是一种选择，谁被留下、谁被赋予更大的责任，同样是选择。彼得定律所揭示的，也可以看作选择机制的一次失效：组织依据一个人在旧岗位上的成功，把他送到一个并不一定适合的新位置，却没有重新判断这个位置真正需要什么。

一旦这种选择机制持续失效，组织里的关系就会慢慢变质。处在关键位置的人无法作出可靠判断，其他人便不再愿意交付信任；信任不足之后，组织开始增加汇报、审批、会议和考核，希望用流程弥补关系的缺口。流程越来越多，真实的信息却越来越少。那些仍然愿意认真做事的人，会发现诚实的成本越来越高，沉默和自我保护反而更加安全。

最后，组织可能拥有非常完整的制度，却失去了真正的协作。制度当然重要，但它更擅长限制一件事可以坏到什么程度，很难决定一群人能够好到什么程度。流程可以约束伤害，却不能制造信任；规则可以守住下限，却无法凭空创造判断力、责任感和共同工作的意愿。

当然，这并不意味着把一切问题都归咎于个人。合适的人也需要合适的环境。一个组织即使曾经选到了很好的人，也可能用持续的打断、不合理的激励、无意义的竞争和对错误的惩罚，把人的诚实与主动一点点消耗掉。《人件》的价值也正在这里：它不仅要求组织认真选择人，也要求组织认真对待已经身处其中的人。

因此，选择人与创造环境不是两个彼此替代的答案。前者决定一段关系有没有可能建立，后者决定这种关系能不能继续生长。组织无法直接设计出信任，但可以选择值得信任的人，也可以创造一个让诚实不必付出额外代价、让负责的人不会反复受伤的环境。

回到软件开发，很多看起来像技术问题的失败，或许都应该再向后追问一步。模糊的系统边界，可能对应着模糊的责任；反复扯皮的接口，可能对应着长期隔绝的团队；没有人敢删除的代码，也可能对应着没有人愿意承担的决定。康威定律并不是说组织决定一切，而是在提醒我们：人的关系会穿过所有流程和工具，最终在系统里留下形状。

我们可以购买更好的工具，复制更先进的流程，也可以重新画一张组织架构图。但信任、判断和责任都无法被这样直接复制。组织真正困难的地方，也许从来不是把人安排进一个结构，而是持续选择合适的人，认真对待他们，并让他们有机会建立值得珍惜的关系。

软件由代码构成，组织由人构成。代码的边界会映照人的关系，而组织最终能够走多远，仍然取决于它选择了什么样的人，又如何对待这些人。

研发必须懂业务，产品不必学会开发

2026-08-20T12:00:00+08:00

今天继续思考企业级系统里的分工。我的判断是：做面向大型企业的复杂系统，让研发懂业务是一项 must have 的能力；但是试图让业务或产品通过学习开发，成为「半个工程师」，通常是一条投入产出比很低的路。

这不是说产品不需要技术常识。产品当然需要理解一个需求可能带来的工程成本，知道灵活性、稳定性和长期维护之间存在取舍，也应该能够与研发讨论系统边界。但「理解工程后果」和「掌握开发实现」是两件不同的事。产品需要前者，却没有必要通过学习写代码来承担后者。

理解业务，本身就是一件很难的事

研发懂业务，并不是记住几个名词，或者把需求文档里的规则复述一遍。大型企业的业务知识往往分散在不同角色、不同国家和地区、历史惯例以及大量例外之中。业务人员描述的通常只是当前做法，却不一定知道这项做法最初为什么产生，也未必能够区分哪些是不可破坏的原则，哪些只是过去某一次决策留下来的配置。

因此，研发必须追问实际发生过什么：这个场景多久出现一次，过去如何处理，什么结果绝对不能发生，谁最终承担责任，系统以什么事实作为判断依据。就像 Partner 系统入场审批里的「允许回退」开关，表面问题是如何限制审批人不能退回到错误的节点；继续追问以后才发现，这个功能从未被使用，也没有真实诉求。此时最好的系统设计并不是增加一套更精细的回退权限，而是不要为一个不存在的问题制造复杂度。

更难的是把复杂业务变成稳定架构

即使理解了业务，事情也只完成了一半。工程师还要从复杂而不断变化的规则中，识别出相对稳定的概念、关系与边界：哪些应该进入领域模型，哪些适合成为配置，哪些只是临时方案，哪些变化值得在架构上留下扩展点，但不应该提前实现。

企业软件的架构不能只是业务规则的逐句翻译。否则，业务每增加一个例外，代码里就多一个条件；当例外积累到一定程度，系统看起来支持了所有场景，实际上却已经没有人能够说清一次修改会影响什么。

一个逐级审批的例子

假设业务提出一个看起来很简单的需求：员工请假超过 10 天，需要沿汇报线逐级审批到部门负责人；超过 20 天，再增加 HRBP 审批。

如果只看需求表面，一名工程师很容易写出下面这样的代码：

只按需求表面实现的逐级审批

def approval_chain(employee, leave_days)
  return [] unless leave_days > 10

  chain = []
  manager = employee.manager

  while manager && !manager.department_head?
    chain << manager
    manager = manager.manager
  end

  chain << manager if manager
  chain << employee.hrbp if leave_days > 20
  chain
end

这段代码没有明显的语法问题，甚至可能顺利通过第一批测试，但它隐含了许多未经确认的业务假设：「10 天」指自然日还是工作日？分两次提交的假期是否累计？员工存在多个直属上级时，应该选择其中一人还是同时审批？审批过程中汇报关系发生变化，应该使用发起时还是当前的组织关系？部门负责人本人请假时从谁开始？找不到直属上级或 HRBP 时，是跳过、失败，还是进入人工处理？

如果研发不理解这些问题背后的业务含义，就无法判断架构应该如何抽象，也无法区分哪些规则是长期成立的本质约束，哪些只是特定时期、特定场景下的临时配置。最终的代码只能随着需求不断增加条件判断：中国区一种逻辑，美国区另一种逻辑；普通员工走汇报线，特殊岗位走岗位线；单直属上级串行审批，多直属上级并行审批。代码越来越「灵活」，系统却越来越脆弱。

更合理的做法，是先把稳定概念显式表达出来。例如，逐级审批至少包含路由方式、组织关系的取值时点、终止条件、附加审批人、异常处理和审批计划快照：

把稳定概念与变化规则分开

policy = ApprovalPolicy.new(
  applies_when: LeaveDurationGreaterThan.new(
    10,
    unit: :working_day
  ),
  route: ReportingLineRoute.new(
    relationship_at: :submitted_at,
    cardinality: :single
  ),
  stop_condition: RoleReached.new(:department_head),
  additions: [
    ConditionalApprover.new(
      condition: LeaveDurationGreaterThan.new(
        20,
        unit: :working_day
      ),
      participant: ParticipantRole.new(:hrbp)
    )
  ],
  missing_participant: :manual_review
)

plan = policy.build_plan(application)
application.save_approval_plan!(plan)

这里的重点并不是这些类名本身，而是代码开始表达真实的业务决定。applies_when 把逐级审批的触发条件独立出来；relationship_at: :submitted_at 表示审批链路使用发起时的组织关系，避免流程运行期间因组织调整而漂移；unit: :working_day 明确了时长的计算口径；missing_participant: :manual_review 表示缺失审批人不能被系统静默跳过；保存审批计划，则让一次审批在事后可以被审计和复现。

cardinality: :single 也明确表达了当前的产品边界：按汇报线逐级审批只支持一个直属上级。如果未来真的出现多直属上级的主流场景，可以重新讨论树形审批的产品语义和实现成本；在此之前，系统应该明确拒绝或进入人工处理，而不是为了抽象上的「完整」提前实现一棵没有真实诉求的树。

在这个设计里，「审批链路必须可审计」「参与人缺失不能被静默忽略」「同一次流程使用一致的规则版本」属于本质约束；20 天的阈值、审批到哪个角色、某项政策适用于哪些地区，则更可能是可以变化的配置。稳定架构的价值，不是预测所有未来需求，而是让稳定的部分保持稳定，让真正会变化的部分能够在清晰的边界内变化。

为什么让产品学习开发解决不了这个问题

即使产品学会了 Ruby，会写循环和条件判断，也无法因此回答「10 天如何计算」「组织关系应取哪个时点」「多个直属上级是否应该形成树形审批」这些问题。它们不是编程语法问题，而是业务事实、产品边界与工程后果共同构成的判断。

更危险的是，懂了一点开发以后，人很容易把复杂系统理解成许多简单功能的叠加，认为新的诉求不过是「增加一个开关」或者「再加一种配置」。Airtable、低代码和今天的 AI 编程都在降低生成代码和搭建界面的门槛，但它们没有自动提供对用户场景的理解，也没有替人承担数据一致性、权限、迁移、异常恢复和长期维护的责任。

所以，业务应该把真实场景和责任关系说清楚，产品应该判断问题是否值得解决，并理解不同选择的工程代价；研发则必须深入业务，识别规则背后的稳定结构，并为最终形成的系统承担工程责任。协作的目标不是让每个人都学习对方的职业，而是让关键知识流向最终需要做出判断、承担后果的人。

这也是企业级工程师真正稀缺的地方：既要穿过大量规则和例外，理解一个复杂的业务世界；又不能把这种复杂原样复制进代码，而要把它压缩成一套稳定、清晰、可以持续演化的系统结构。只懂技术、不懂业务，容易设计出结构漂亮但语义错误的系统；只理解业务现象、缺少架构抽象，又会把系统变成无法维护的规则集合。

业务负责定义真实世界，产品负责在价值与成本之间做取舍，研发负责把复杂现实压缩成能够长期运行的系统。研发懂业务之所以是 must have，正是因为架构抽象从来不是纯粹的技术问题。

人的境况：当劳动不再定义我们

2026-08-14T12:00:00+08:00

今天读到汉娜·阿伦特对劳动社会的预言：一个以劳动为中心的社会，最终可能迎来劳动本身的消失。真正危险的不是机器替代了多少工作，而是当人终于摆脱劳动时，才发现自己已经不知道劳动之外还有什么值得去做。

「人的境况」并不是在追问一种固定不变的人性，而是在追问：人是在什么条件下成为人的？我们需要维持生命，也会创造一个比自己活得更久的世界；我们与他人共同生活，通过言说和行动表明自己是谁，并开始一些过去并不存在的事情。

阿伦特把人的活动区分为劳动、工作与行动。劳动维持生命，是吃饭、清洁和生产的不断循环；工作制造相对持久的事物，让世界留下房屋、工具、作品和制度；行动则发生在人与人之间，我们通过选择、承诺、协作和承担责任，共同改变所处的世界。

现代社会却逐渐把这三者压缩成了职业。见面时最常问的是「你做什么工作」，一个人的收入、身份、尊严乃至生活节奏，都依附在岗位上。我们一面抱怨忙碌，一面又害怕自己不再被需要，因为如果没有了职位和日程，很多人甚至很难回答「我是谁」。

AI 正在使阿伦特的问题重新变得具体。它可以接手越来越多重复性的劳动，也可以参与写代码、写文章、制作图像，进入过去被认为属于创造的领域。生产效率的提升当然可能带来自由时间，但自由时间并不会自动变成自由。如果这些时间最终只是被短视频、消费和更加精密的娱乐填满，人或许只是从「有工作的劳动者」变成了「没有工作的消费者」。

所以，问题的核心并不是未来还有没有足够多的岗位，而是我们是否还保留了行动的能力：能否形成自己的判断，能否和他人建立真实关系，能否参与公共事务，能否为一个尚不存在的世界承担责任。技术可以优化已有的过程，却不能替我们回答什么值得开始，更不能替我们承担选择之后的后果。

这也让我重新理解了人们为什么如此执着于晋升。职位不仅带来收入，也被用来证明一个人的价值。可一旦头衔消失、组织不再需要我们，剩下来的那个人是否仍然拥有好奇心、友谊、关怀、创造和参与世界的愿望？这些东西很少出现在绩效考核里，却可能才是人不被劳动完全吞没的部分。

自由并不是终于无事可做，而是即使不再被生存强迫，也知道自己愿意为什么投入时间。劳动的减少可以成为解放的条件，却不是解放本身。真正的解放，需要人重新学习如何使用自己的时间，也重新学习如何与他人共同生活。

真正可怕的不是劳动消失，而是劳动消失以后，我们才发现自己只会劳动。

彼得定律：坐着电梯上升之后

2026-08-13T12:00:00+08:00

彼得定律说，在一个等级制组织里，人往往会因为胜任当前工作而不断获得晋升，直到来到一个自己无法胜任的位置。它真正揭示的，不是「管理者都是无能的」，而是一种很常见的组织错误：用一个人在过去岗位上的成功，推断他也能胜任一个能力要求完全不同的新岗位。

这条定律在过去十几年的中国互联网行业里，似乎被高速增长放大了。改革开放带来的经济扩张，与信息技术革命带来的产业机会叠加在一起，许多企业在极短时间内完成了规模跃迁。公司一年翻几倍，团队从十几个人扩张到几百人，新的业务、层级和管理岗位不断出现。职位产生的速度，远远超过了管理能力成熟的速度。

很多人因此是「坐着电梯」上升的。这并不是说他们没有努力、没有能力，而是说电梯本身也在向上：行业在增长，公司在增长，资本、流量和人口红利都在增长。人在其中取得的成绩，往往同时包含了个人能力、团队贡献、平台资源和时代运气，但组织很容易把这些结果全部归因于那个最显眼的人，再用它作为下一次晋升的依据。

高速增长还有一个特点：它可以暂时掩盖管理上的问题。方向不够准确，可以靠市场增量弥补；组织效率不高，可以靠增加人手和延长工作时间支撑；管理者不会授权，可以依靠自己亲自下场；团队协作混乱，也可能被不断上涨的业务数字遮住。在电梯持续上升的时候，人很难判断究竟是自己在爬楼，还是楼层正在主动靠近自己。

更麻烦的是，很多人还没有来得及在一个岗位上经历完整的反馈周期，就已经进入了下一层。错误尚未显现，晋升已经发生；管理方法尚未形成，又要开始管理更大的组织。最后，一名优秀的工程师可能变成不称职的技术主管，一名优秀的业务负责人也可能变成缺少组织能力的高级管理者。企业失去了一个优秀的专业人才，却不一定得到了一个合格的管理者。

当行业从高速增长进入存量竞争，电梯开始减速甚至停下，过去被增长遮蔽的问题才会集中出现。战略频繁摇摆、事无巨细地干预、依赖会议和汇报制造控制感、把结果不佳归因于执行者，这些现象有时并不只是个人品格问题，而是能力与位置不匹配之后的自我防御。

不过，彼得定律的意义不应该是嘲笑那些被晋升的人。许多人只是被一个高速运转的组织推到了没有准备好的位置。真正需要反思的是，组织为什么把晋升当成奖励，把管理岗位当作专业成长的唯一终点，又为什么很少提供试岗、反馈、训练以及回到专业岗位的通道。

对个人来说，这条定律也是一种提醒。回头看自己的成绩时，需要区分哪些来自能力，哪些来自平台，哪些来自团队，哪些只是赶上了时代。一个更诚实的问题或许是：如果电梯今天停下，我是否还知道怎样走楼梯？

写代码是一件很难的事情

2026-08-09T12:00:00+08:00

今天读到 Senko Rašić 的一篇文章，它反驳了一句在 AI 编程时代很流行的话：「代码从来不是难点，真正的难点是决定做什么。」我越来越觉得，这句话看似在强调产品判断，实际上却把软件开发拆成了一个假的二选一：仿佛只要理解了用户，剩下的实现就只是机械劳动。

理解用户当然很难。用户常常说不清自己真正需要什么，客户、使用者和付费者的目标也未必一致；一个今天正确的需求，放到组织、流程和时间里，还可能迅速发生变化。但承认这些困难，并不需要贬低写代码本身。

写代码之所以难，不是因为敲出字符很难，而是因为它要求把含混的现实压缩成精确的系统。什么状态是合法的，边界在哪里，失败之后如何恢复，权限怎样收敛，数据如何保持一致，以及一次局部修改会不会在半年后变成新的约束——这些问题最终都要落进代码，也都无法靠一句「先做出来再说」真正绕过去。

能运行的代码和好的代码之间，还隔着很远的距离。好的代码不仅要在演示时工作，还要在输入异常、依赖失败、规模增长、人员更替和需求变化时，仍然可以被理解、修改和验证。很多工程价值平时并不显眼，只有系统出错或需要继续演化时，才会突然显现出来。

AI 最容易制造的错觉，是把生成的顺畅误认为问题的简单。它可以迅速完成一个局部实现，却也会把背后的推理、取舍和风险隐藏起来。如果人没有真正理解这些代码，速度越快，积累的未知也可能越多。AI 可以替我生成代码，却不会替我承担代码上线之后的责任。

不过，我也不想走到另一个极端，把写代码神秘化成一种不可自动化的艺术。程序员一直在用新的抽象淘汰旧的手艺，AI 只是这段历史的新阶段。真正需要保留的，不是对某种写法的怀旧，而是理解系统如何工作的能力，以及面对复杂性时作出判断的能力。

因此，资深工程师需要理解用户、商业和组织，初级工程师也仍然需要学习数据结构、网络、内存、递归和系统基础。两种能力不是彼此替代的：产品判断不能替代工程判断，工程技艺也不能替代对真实需求的理解。

所以，决定做什么很难，把它正确地做出来也很难。好的软件，不是找到了其中唯一重要的那一半，而是同时尊重了这两个难题。

AI 普及了代码，但没有普及软件工程

2026-08-05T12:00:00+08:00

今天看到一条新闻：Bending Spoons 与 Airtable 达成了收购协议，现金交易金额约为 12.85 亿美元。Airtable 在 2021 年的估值一度高达约 110 亿美元。一次收购当然不能简单证明一个品类的失败，但这个巨大的落差，仍然让我重新思考曾经很流行的「平民开发」。

Airtable 和许多 aPaaS、低代码平台曾经给出过一个很有吸引力的承诺：只要把软件开发变成拖拉拽、配置表单和拼装流程，普通人也能成为开发者。但软件开发真正困难的部分，从来不只是把界面和逻辑搭出来。它还包括理解用户究竟在什么场景下遇到问题，判断需求的边界，处理权限、数据、异常与集成，并在短期交付和长期维护之间作出工程上的平衡。

这些复杂性没有因为代码被隐藏起来而消失，只是从代码转移到了平台配置、数据结构和后续维护里。当一个场景变得足够重要、足够复杂时，专业的软件工程能力往往又会重新出现。

不过，我也需要修正一个过于绝对的判断：每天只有几个人使用的软件，不一定没有价值。一个只有三名薪酬人员操作的系统，可能影响几万名员工能否准确领到工资。真正「薄如纸」的，是那些低频、低风险、容易替代，又没有沉淀数据和业务关系的长尾需求。它们可以有局部的使用价值，却很难自然生长为可持续、可积累的商业价值。

这也是今天的 AI 编程正在面对的问题。AI 让制作一个小产品、小工具变得前所未有地容易，但当所有人都能快速生产这些东西时，「做出来」本身也就不再稀缺。大量一次性的工具可以解决一时的不便，却没有分发、业务嵌入、维护责任和长期演化能力。代码越来越多，单纯生产代码的价值反而越来越薄。

AI 只是帮他把普通人甩得更远了。

在 OpenCode 的这期访谈里，Dax 用 Mitchell Hashimoto 举例：一个原本就极其优秀的程序员，在使用 AI 之后，并不会和普通人站到同一条线上，反而可能把差距进一步拉大。即使 AI 写了 95% 的代码，剩下的 5% 仍然可能是最关键的问题定义、架构设计、边界控制和工程判断。

所以，AI 对优秀工程师更像是乘法器；对缺少判断力的人，它很多时候只是加速器——更快地生产薄弱的「垃圾」，也更快地积累无人愿意维护的代码。真正能把 AI 发挥到极致的人，不是最擅长让它不停生成东西的人，而是知道什么值得做、什么不该做，以及怎样让一个系统长期正确运行的人。

aPaaS 曾经试图普及软件开发，AI 正在进一步普及代码生产，但二者都没有普及软件工程。工具可以降低实现的门槛，却无法替代对真实世界的理解。软件最终的价值，也从来不在于它由多少代码、多少组件组成，而在于它是否进入了一个足够重要的场景，并长期承担了责任。

人文主义，就是「山姆」

2026-07-31T12:00:00+08:00

今天想到人文主义。这个词经常被说得很宏大，仿佛它首先属于哲学史、宣言和公共议题。如果要为人文主义找一张具体的脸，我想到是两位「山姆」。

《指环王》里有山姆卫斯·甘吉，《冰与火之歌》里有山姆威尔·塔利。他们甚至共享同一个普通的昵称。两个人都不符合各自世界对英雄的想象：他们没有强大的武力，没有领袖的威严，也不以无所畏惧示人。他们会害怕，会笨拙，会被更强壮、更体面的人轻视。但他们也不是安·兰德在《源泉》中所批评的「二手货」——那些只能借助他人的目光和评价确认自身价值的人。

山姆们有自己的精神重心。一个热爱土地、花草、食物和夏尔的日常生活；一个热爱书本、歌谣和知识。他们的爱好并不是为了成为谁，也不需要因为有用、宏大或先进而获得正当性。即使没有观众，没有掌声，没有机会被写进英雄史诗，花园依然值得照料，书依然值得读。这种不借他人目光生活的能力，恰恰使他们成为完整的人。

英雄故事总在讲一个人如何承担责任，却很少追问：当责任完成以后，这个人还剩下什么？佛罗多是《指环王》的中心人物。他承担了远远超过一个普通霍比特人所能承受的重负，也因此留下了无法真正愈合的伤。魔戒被毁，世界获救，他却不能完整地回到那个已经被拯救的世界，最终只能渡海西去。世界得救了，并不意味着拯救世界的人也得救了。

山姆的结局则不同。他同样走到了末日火山，同样见过恐惧、战争与死亡，却仍能回到夏尔，重新种下树木，建立家庭，继续过具体的生活。他不能替佛罗多承担魔戒，却能在最后一程托住那个已经走不动的人；旅程结束后，他又把被宏大事件打断的日常生活重新接了起来。

这不是一个比英雄更轻的结局。或许恰恰相反：佛罗多承受一切，是为了让世界上仍然有人能够回家、种树、吃饭、相爱。英雄主义负责把世界从毁灭边缘拉回来，而人文主义负责提醒我们，世界为什么值得被拯救。

山姆威尔·塔利身上也有相似的东西。他生活在一个把武力、血统和征服视为力量的世界里，却始终没有放弃对书籍和知识的热爱。至少在 HBO《权力的游戏》已经给出的结局中，他活了下来，成为大学士，也参与保存和讲述那个时代的历史。马丁笔下真正的结局仍未到来，但这个剧版结局保留了一层意味：当争夺王座的英雄们相继死去、远走或改变，最后仍需要有人阅读、记录、治疗，并让文明重新开始运转。

所以，我所理解的人文主义，并不是赞美弱小，也不是反对卓越，更不是劝人逃避责任。它只是拒绝用能力、成就和牺牲的规模来衡量一个人的全部价值。它相信人首先是目的，而不是完成某项使命的工具；相信花园和书本并非伟大事业之外的边角料，它们本身就是伟大事业需要保护的东西。

每个人的生命里，也许都住着一个需要偶尔回头追问的山姆。当我不停地承担责任、追逐目标、试图成为一个更有能力的人时，这个山姆会问：如果没有人观看，我仍然真正热爱的是什么？我想保护的那种普通生活是什么？完成所有事情以后，我是否还有一个能够回去的地方？

幸福也许并不是英雄完成使命后理应领取的奖赏。它更像一种没有丢失内在重心的生活：知道自己爱什么，知道为何出发，也知道为何归来。人可以在某个时刻成为佛罗多，承担不得不承担的重负；但也需要保留心里的山姆，提醒自己不要把整个人生都献给魔戒。

灵活性需要边界

2026-07-29T12:00:00+08:00

今天在设计「逐级审批」节点时，重新思考了复杂业务系统中灵活性的平衡。人事系统经常面对所谓「灵活的业务需求」，平台也确实需要通过解耦来适配变化。但灵活性并不等于无限开放：架构可以解耦，产品能力仍然需要清晰的场景约束。没有边界的灵活，最终往往会转化为概念、配置、交互和维护成本。

逐级审批中的具体问题

逐级审批目前包含汇报线、部门线和岗位线三种逐级路由模式。它们表面上都是「逐级找人」，背后的组织关系、终止条件和适用范围却不同，因此不应该为了形式统一而抹平各自的约束。

汇报线为什么先约束为单链

按汇报线逐级审批，隐含前提是每一级都能找到唯一的直属上级，整条审批链是一条直线。如果同一个人存在多个直属上级，汇报线就会发生分叉，审批链也会从线性结构变成树形结构。

树形结构并非不能实现，真正需要评估的是：为支持它所增加的产品成本是否值得。一旦允许分叉，就必须继续定义多个新问题：

多个上级是任意一人通过，还是全部通过？
不同分支在更高层遇到同一个人时，是否需要合并和去重？
某个分支提前结束、驳回或异常时，其他分支如何处理？
审批记录、流程图和配置界面如何让用户准确理解这棵树？

这些问题增加的不只是开发量，更重要的是用户理解成本和产品设计复杂度。是否支持树形审批，本质上是产品决策，而不是单纯的技术可行性判断。

产品决策的两个判断

主流竞品是否支持。竞品不是答案，但可以帮助判断这是否是一个普遍且成熟的业务场景。如果行业中的主流产品普遍没有提供，通常意味着需求频率、收益或复杂度之间尚未形成划算的平衡。
原始诉求到底是什么。不能把用户提出的方案直接当成需求。需要继续追问：用户真正要解决的是多汇报线，还是代理审批、会签、加签、跨部门协同等其他问题？只有确认了原始问题，才能判断是否真的需要引入树形模型。

设计原则

架构上预留扩展性：将不同逐级路由模式解耦，保留未来增加新策略或扩展树形路由的空间。
产品上明确当前边界：只支持已经验证的主流场景，并把单链约束、校验规则和异常提示说清楚。
实现上保持克制：预留不等于提前建设。没有被真实需求验证的能力，不提前实现，也不提前暴露给用户。

Partner 系统入场审批：关于「允许回退」的追问

2026-07-28T12:00:00+08:00

在检查 Partner 系统入场的飞书审批流程时，看到流程打开了「允许回退」开关。只看配置，容易继续追问「如何限制审批人只能回退到合适的节点」。但这只是配置表象，不能直接等同于真实的业务需求。

进一步向刘晓萌确认后，得到的反馈是：

这个退回没用过，估计是配置的时候没注意；这个系统从来没用过退回审批的操作，也没有诉求。

看到一个看似异常的开关时，不能只基于页面配置推导需求。应先追问实际使用场景、历史操作和真实诉求，再决定是否需要设计或修改。配置存在，不代表能力被使用；系统支持，也不等于业务需要。

XZH / 日志

Don't Use F***cking AI to F***ck with Me

卓越的前提，是对自己有要求

不正义，是系统的癌症

好、乐、信

那三十五秒

养、育、陪

What if we failed?

Everything is the result of Time

AI 不是垃圾制造者，人才是

几个架构设计的汇总（待补充）

组织的起点，是人

研发必须懂业务，产品不必学会开发

理解业务，本身就是一件很难的事

更难的是把复杂业务变成稳定架构

一个逐级审批的例子

为什么让产品学习开发解决不了这个问题

人的境况：当劳动不再定义我们

彼得定律：坐着电梯上升之后

写代码是一件很难的事情

AI 普及了代码，但没有普及软件工程

人文主义，就是「山姆」

灵活性需要边界

逐级审批中的具体问题

汇报线为什么先约束为单链

产品决策的两个判断

设计原则

Partner 系统入场审批：关于「允许回退」的追问

Don't Use Fcking AI to Fck with Me