我经常是错的

对该框架价值的看法

• 有些人认为这套六步流程是完全合理、相当标准的问题解决循环，类似于 OODA、PDCA、Polya 的《如何解题》或亚马逊风格的决策文档。
• 支持者表示，把自己的思考方式明确写下来可以减少对预期的困惑，并改善决策，尤其是在配合书面理由说明时。
• 少数人发现，在“偏向行动”的环境中它很有激励作用：先理解情境，然后果断执行。

对语气、谦逊与原创性的批评

• 许多人把这套框架描述为泛泛而谈、“初中水平”，或是披着洞见外衣的硅谷套话。
• 标题“我经常是错的”被广泛解读为谦逊式炫耀；评论者指出，文中缺少自己出错的具体例子，也缺少实践中改变决策的证据。
• 有些人对这种以自我为中心的表述（“我的框架”、“我的方法”）以及将其对外发布而不是作为内部指导感到反感。

领导力、权力关系与反馈文化

• 对“要求”他人遵循个人框架，并在他们不遵循时给予“反馈”的做法，存在强烈反对。
• 有几位认为，好的领导会根据个人优势进行调整，而不是制造一批克隆体；框架应该是工具，而不是执行机制。
• 也有人回应说，每位领导都在隐含地施加某种流程；将其显性化可能会有帮助。
• 还有人担心，心理安全和“诚实反馈”被默认存在，而不是被真正建立起来，尤其当这些反馈来自资深 IC 时，其影响仍然很大。

紧迫性、优先级与问题定义

• “带着紧迫感行动”受到猛烈批评，被认为会导致倦怠、草率工作，以及总觉得一切都在着火的感觉。
• 支持者将其解读为“思考完成后要快速执行”，或者作为对大公司僵化迟缓的一种纠偏。
• 多位评论者指出步骤顺序有问题：目标定义出现得太晚，信息收集先于清晰的问题定义，且对迭代/实验的强调不足。

Claude Code 与产品质量外溢

• 一个很大的分支讨论把 Claude Code 的现状当作案例：许多人把它描述为有 bug、不一致、缓慢，而且实现方式古怪（例如 React/JS 的选择、侧边栏里的终端 UX）。
• GitHub issue 数量、长期存在的 bug（比如消息丢失）以及自动关闭 issue，被引用为流程没有交付高质量产品的证据。
• 也有人反驳说，庞大的用户规模和广泛的功能表面解释了许多问题，而且并非所有未解决 issue 都能证实是 bug。

LLM、文化与沟通

• 有些人担心大量内部使用 agent 会把人的声音“磨平”，使沟通听起来像 LLM 输出，并削弱人与人之间的协作。
• 另一些人指出，所有人的思维本来就某种程度上是“有缺陷的叙述者”；LLM 可能只是让这一点更明显。