Toby! (@TobyAtLarge) “（好担心自己变成杠精😂） 先说结论：观察方向对，但论证粗糙，外推过度，借鉴意义有” — TopicDigg

（好担心自己变成杠精😂） 先说结论：观察方向对，但论证粗糙，外推过度，借鉴意义有限。本文展现出了作者她这个背景和level不应该呈现出的稚嫩感。 几个核心问题： 1. "代码几乎免费"是演讲修辞，不是事实。 代码确实便宜了很多，但"优秀代码"——考虑到架构设计、边界条件、测试覆盖——仍然有成本。这个区分不是挑字眼，而是直接决定了你能不能真的"随便试错、三个 PR 并行上"。Fiona 自己也承认"维护成本不会跟着归零"，说明她心里清楚，只是演讲里为了冲击力把话说满了。 2. Source of truth 不止一层。 她说"代码是唯一的 source of truth"，这过于绝对。实际工程至少有三层：需求（为什么做）→ 设计（怎么做）→ 代码（做出来了）。需求文档才是最初的 source of truth。代码是执行结果，经常处在折中状态——来自业务限制、时间压力、技术债的折中。如果没有需求文档做参照，你连"这个折中是刻意的还是 bug"都分不清。 3. 三个"未解问题"暴露了思考深度不够（疑菜）。 - "跨平台团队还有没有意义"——她的前提就是大家都在用 Claude Code 写代码，设计师能写、PM 能写、工程师能写。既然如此，答案不是显而易见吗？iOS 和 Android 的分队已经没有必要了。把一个自己前提里已经蕴含了答案的问题当成"未解难题"，很奇怪。 - "自动评审推多远"——答案很清楚：bottom line 是不能让 bug 到用户那里。 - "角色模糊后公平感怎么设计"——这个问题的框架就错了。作为一个企业，你最应该关心的是交付的产品质量和代码质量，而不是内部团队对"谁的代码贡献更多"的公平感。PM 提交的 PR 和工程师提交的 PR，在 review 标准上不该有任何区别。产品是用户喜闻乐见的，所谓的"公平感"不应该是个问题。 4. JIT planning = 没有规划 她说不做半年路线图，"什么时候需要再做什么"。这很夸张。说白了就是对一个正经严肃的 toB/toC 产品不做规划。 任何产品都有核心路线、大方向和目标。"先发 PR、少开会"直接导致 feature 失控。而且讽刺的是，从用户端观察，Claude Code 的发布节奏看起来是有规划、有节制的——并不像她描述的那种勃勃生机万物竞发的野蛮生长式的运作方式。 5. 整体判断：特殊环境里的个人经验，包装成了普适方法论。 Anthropic 是一个极端特殊的环境：AI-native 产品、极高人才密度、公司本身就是最好的 dogfooding 场景。在这种环境里一年的实验，外推到"所有工程团队都该这样"——折扣要打得很大。