这份笔记本周早些时候分享给了团队，也发布在这里。和我共事过的人很快会知道，我处理几乎所有问题的方法都是：理解已有信息，收集缺失信息，定义问题，定义清楚简单的解法，定义目标，然后带着紧迫感行动。过程中常会学到新信息，于是回头重新定义第三到第五步并重复。这个流程是迭代的，复杂问题可能要多试很多次。

2026年9月19日

和我共事的人很快会了解到，我处理几乎所有问题的方法都是：

1. 理清现有信息
2. 补齐缺失信息
3. 界定问题
4. 定出清晰简单的解决思路
5. 确立目标
6. 紧迫行动去达成目标

过程中常会有新信息，这就得回去重做第3到5步并重复。这流程是迭代式的，复杂问题可能要试很多次，看起来反复，但只要有新数据就得更新预判，这种折腾是健康的。

我几乎把这套步骤用于每个问题和产品（产品就是为用户解决问题的），多数日子都会用很多遍。

我有时会指出别人漏了步骤或执行差，也期望他们同样反馈我。我尽量实时给反馈好让团队学快些。最常见的失败是没清晰界定问题（3），以及没定出清晰简单的思路（4），导致计划复杂、成败标准模糊。计划是自己做的时，缺乏清晰很难自知，所以找他人反馈更重要。

如果这套元流程本身有错，我也乐意改。

所以我喜欢犯错，这是我的最爱，因为它帮我更清楚地界定问题、找对解法、更快学习、解决问题。

讨论对这篇个人问题解决框架的博客以批评为主：多数人认为它把管理者的个人方法论变成团队标准、用「紧迫」充当流程，少数人则认为它和亚马逊的文档决策流程一样有效。分歧集中在流程该被复制，还是必须为不同人的工作方式留出空间。

认为影响力越大越该克制，而不是轻率

• 到一定影响力层级后需要放慢、更有条理，不能随口抛出一套东西让别人跟。（较多人） > 抱歉，但当你达到一定影响力层级，就需要慢下来、更有条理，不能这么轻率。（@verdverm）

认为这是管理者在让团队变成自己的小号

• 要求别人遵循个人万能框架，否则给「反馈」，是最招人烦的管理方式；资深工程师脑中本就有系统模型，管理者的工作是组合强弱项，而不是复制自己。（较多人） > 你的任务不是制造自己的小号，而是了解每个人的弱点和强项，把工作切成弱点影响最小、强项成倍放大的块。（@atoav）

认为把紧迫设为标准流程等于没有优先级

• 如果一切都紧急，就没有什么真正紧急；这类人往往让同事对请求默认按下暂停，也是倦怠的来源。（较多人） > 如果一切都是紧急的，那就什么都不是紧急的。（@infamia）

认为步骤顺序和归类有硬伤

• 先定义问题再定义目标被指作弊；前五步只是「动手前先搞清楚状况」的越来越正式的说法，第六步是「然后快点做」。（较多人） > 步骤 1 到 5 是用越来越正式的方式说「先搞清楚发生了什么再动手」，然后第 6 步是「赶紧做」。（@Imanari）

认为自称常犯错却拿不出一个实例，更像自我表扬

• 在 Claude 相关争议正热时写「被证明错了」，全文没有一个具体案例；抽象地喜欢犯错谁都会。（较多人） > 大家都喜欢抽象地犯错，这篇读起来更像自我祝贺，而不是真诚反思。（@serjester）

支持：这跟亚马逊的文档决策流程一样有效

• 写透决策文档、反复迭代再承诺方向，优于他见过的所有替代方案；他给受指导者同样的反馈，因此认为批评站不住脚。（少数人） > 在承诺方向和计划前做出充分知情的决策并迭代决策文档，比我职业生涯中见过的任何替代方案都好。（@otterley）

少数人认为批评过火，他是科学家，继续做好工作

• 这类声音主张不必把博客当成管理宣言来审判。（少数人） > 鲍里斯是科学家，这句话就够了。继续做好工作。（@animalfarm）

有价值的补充

• Claude Code 被高频用户批评为最不一致、bug 最多的软件之一：composer 里能用鼠标移动光标，AskUserQuestion 里不行；子代理继承主代理模型名，四个子代理工具似乎都没搞对；用量限制恢复后代理行为时好时坏。也有人质疑为何把它跑在 JS 运行时，而不是 Go、BubbleTea 这类原生方案。
• 有听众发现 Boris 的演讲和写作越来越像 Claude Code，不是 LLM 代笔，而是长期与大量 agent 交互后人的语感被磨平；这种语感渐渐被当成「不可靠叙述者」的信号，评论者担心自己的声音也在同化。
• 「我常常犯错」被指直接出自《如何赢得朋友和影响他人》。
• 有人反过来分享自己「常常是对的」：即使决策快速正确也会得罪人，因为人们有拖延偏误，委员会和会议喜欢把事情无限期推后。
• 七步框架被戏称为可以立刻做成一个 agentic harness；也有人补上第八步「反思那个目标」。