本文整理自Youtube 博主 Lenyy 对 Claude Code 和 Cowork 的产品负责人 Cat Wu 的访谈，由有道龙虾总结和发布。

如果你还在用半年、一年为单位规划 AI 产品，可能已经慢了。

Anthropic 的 Claude Code 和 Co-work 团队，现在很多产品功能的周期已经从过去的 6 个月，压缩到 1 个月、1 周，甚至有时候是 1 天。

这不是因为他们找到了某个神奇流程，也不只是因为他们能用最前沿的模型。更核心的变化是：AI 正在把“写代码”这件事变便宜，把真正贵的东西推到台前。

那就是：判断该写什么，为什么写，写成什么样。

这也是 Cat Woo 在这次访谈里反复强调的主线。她是 Anthropic 负责 Claude Code 和 Co-work 的产品负责人，和 Boris 一起站在 AI 原生产品构建的最前线。她看到的变化很直接：PM 的角色没有消失，但它正在被重新定义。

PM 的工作，不再是守着路线图开会

Cat Woo 对自己和 Boris 的分工有一个很有意思的描述。

Boris 更像技术负责人和产品愿景提出者，能看到 3 个月、6 个月之后产品该长成什么样，甚至是“AGI pilled”版本的产品该是什么样。

而她的工作，是把今天和那个愿景之间的路铺出来：

  • 哪些功能先做，哪些后做
  • 营销、销售、财务、容量、文档这些团队是否已经对齐
  • 功能准备好时，还有没有阻碍发布的东西
  • 团队是不是在朝同一个方向划船

但她也说，这条边界其实很模糊。他们大概 80% 是“心智同步”的，剩下 20% 里，有些事她更在意就由她推进，有些事 Boris 更在意就由 Boris 推进。

这很像 AI 时代产品团队的缩影：角色边界在变淡，真正重要的是谁能把事情向前推。

AI 原生产品的第一条规则：把想法尽快交到用户手里

在 AI 之前，技术变化没那么快。产品团队可以做 6 到 12 个月的规划，和其他团队慢慢对齐路线图。因为代码贵，开发慢，每一次启动都要慎重。

但现在不一样了。

AI 加速了工程，模型能力也在快速变化。Cat Woo 说，很多功能的时间线已经从 6 个月变成 1 个月，有时是一周，甚至一天。

这对 PM 的要求变了。

过去重要的是：多季度路线图、跨团队排期、复杂依赖管理。

现在更重要的是：

  • 怎样最快把东西发出去
  • 怎样让工程师或 PM 的想法，在一周内到用户手里
  • 怎样定义产品里最关键的任务，让它们开箱即用
  • 怎样减少每一次发布前的摩擦

她认为，AI 原生产品里最优秀的 PM，擅长缩短“想法到用户”的距离。

不是每件事都要等到完美。Claude Code 的很多功能都会以 research preview 的方式发布，明确告诉用户：这是早期功能，是一个正在验证的想法，未来不一定长期支持。

这样做的好处是，团队不需要背上太重的承诺，可以先让真实用户反馈告诉他们，方向是不是对的。

快，不等于乱：目标必须非常清楚

AI 产品之所以难做，很大一部分原因是模型太通用了。

大模型什么都能做一点，于是产品团队很容易陷入模糊：到底为谁做？解决什么问题？最重要的使用场景是什么？

Cat Woo 说，优秀 PM 的第一件事就是把目标钉牢。

比如不是笼统地说“减少权限提示”，而是说：我们的核心用户是企业里的专业开发者，这个功能要解决的是他们被太多权限弹窗打断的问题，目标是让他们在安全前提下接近“零权限提示”。

这个目标一清楚，很多方案就会自然被排除。

快节奏团队不是不需要产品定义，恰恰相反，它需要更清楚、更短、更能指导行动的定义。

他们仍然会写 PRD，但不再是所有功能都写厚厚一份。对于特别模糊的功能，他们会写一页纸，说明：

  • 目标是什么
  • 什么样的使用体验才算“好用到让人惊喜”
  • 现在有哪些失败模式必须修掉
  • 哪些项目因为涉及重基础设施，确实需要几个月周期

同时，团队每周会做指标回顾，让所有人理解业务目标、趋势和背后的驱动因素。他们还维护一套团队原则，写清楚核心用户是谁、为什么是这些用户、哪些取舍是可以接受的。

这些东西的目的不是增加流程，而是让更多人不必等 PM 点头，也能自己做判断。

Anthropic 为什么能发得这么快？不是模型一个原因

外界常常把 Anthropic 的发布速度归因于“他们有最强模型”。Cat Woo 承认，内部使用模型确实提高了发货速度，但这不是主要原因。

她认为，更关键的是团队预期和流程设计。

他们刻意保持低流程，想移除一切阻挡发布的东西。每个人都应该感觉自己有能力把一个想法从脑子里推到现实世界里，最好一周内完成，有时一天内完成。

一个具体例子是 Claude Code 的 launch room。

当工程师觉得某个功能已经准备好，并且团队内部已经 dogfood 过，就会把它发到一个常设发布频道。文档负责人、产品营销、开发者关系团队会立刻介入，最快第二天就能把文档和公告准备好。

这个流程的关键不是审批，而是降低摩擦。

PM 在这里的作用也很清楚：不是挡在门口当门神，而是搭好通道，让更多人可以顺畅发布。

未来还需要 PM 吗？需要，但不是旧版本的 PM

访谈里有一个很现实的问题：既然工程师现在能借助 AI 快速做产品，PM 会不会变少？

Cat Woo 的答案不是简单的“会”或“不会”。她认为角色正在融合。

PM 会做一些工程工作，工程师会做一些 PM 工作，设计师会做产品判断，也会写前端代码。

这意味着公司可以有两种选择：

  • 招更多有产品品味的工程师
  • 或者保留工程规模，同时招更多 PM 来帮助引导方向

Claude Code 团队更偏向前一种。他们很重视有产品品味的工程师，因为这样能减少沟通和交接成本。团队里很多工程师可以从 Twitter 上看到用户反馈，自己判断问题，自己把功能做出来，几乎不需要 PM 介入。

但这并不意味着 PM 不重要。

恰恰相反，产品品味变得更稀缺。

当代码越来越便宜，真正贵的是决定写什么。

面对成千上万条 GitHub issue，用户什么都想要。你要判断哪些值得做，怎么做才对，什么体验会让人觉得顺手、惊喜、可信。这种能力可以来自工程、设计、产品任何背景，但它本身很难得。

工程背景在眼下仍然有优势，因为你能判断一个东西到底难不难。如果某个功能一小时能做出来，就别开三次会辩论，直接试。如果某个功能涉及很重的架构成本，就要更慎重。

但 Cat Woo 也提醒，未来几个月需要什么技能都可能变化。模型能力增长太快，最重要的是第一性原理：看清技术地形怎么变，团队眼下真正缺什么，然后低 ego 地补上那个空缺。

人类暂时还最擅长什么？常识、判断和关系感

访谈里还聊到一个更大的问题：在越来越强的 AI 面前，人类大脑接下来还在哪些地方有用？

Cat Woo 的答案很朴素：常识。

一次产品发布有上千个移动零件。很多东西很小，但都可能出问题。模型还不总是知道：

  • 谁是关键 stakeholder
  • 这些人彼此是什么关系
  • 每个人偏好什么沟通方式
  • 哪个场合适合说什么
  • 怎么让大家持续站在同一边

这些带有默会知识和 EQ 的判断，现在仍然非常有价值。

她也提到，在 Anthropic 这种高速环境里，团队很看重能“带着笑面对混乱”的人。

因为问题永远很多，风险永远很多。如果每件事都把你压垮，你很快会 burnout。她喜欢那种看到难题会说“这很难，但我很兴奋，我会尽力做好”的人。

这种心态听起来轻松，其实很难。她说有些周日晚上出现一个 P0，周一上午又来一个 P0，周一下午再来一个 P0000。你会突然觉得，周日那个问题好像也没那么可怕。

所以只能学会残酷排序：什么最重要，什么可以放掉。某些功能没那么 polished，只要不阻塞核心使用场景，就可以先发。用户反馈来了，下个版本修。

快速发布的代价：产品一致性会下降

角色融合、快速试错当然有代价。

Cat Woo 说得很直接：他们牺牲了一部分产品一致性。

过去代码贵，团队会仔细规划整个产品套件。每个产品解决什么场景、彼此怎么衔接、用户路径怎么设计，都会提前想清楚。通常一个场景对应一个产品。

现在 AI 变化太快，团队要测试的想法太多，有些功能会重叠。有时内部也不确定哪个 form factor 更好，就把两个都拿出去，让外部用户告诉他们答案。

这对新用户不太友好。用户可能不知道要完成某件事，最佳路径到底是哪条。功能太多，大家也会觉得追不上，每天都要刷 Twitter 才知道最新能力。

所以他们后来做了 /powerup 这样的功能，帮助用户理解 Claude Code 里最值得掌握的能力。

这也很有意思。团队原本不喜欢做强 onboarding，因为他们希望产品直觉到不需要教程。但功能越来越多，用户真的需要一个内置引导，告诉他们：100 个功能里，最该先学的 10 个是什么。

Anthropic 的成功，靠两个东西：使命和聚焦

主持人提到，Anthropic 起步时并不占优势，资金、分发、先发位置都不如对手。但后来增长非常快，甚至被提到 ARR 达到 110 亿美元级别，而且仍在高速增长。

Cat Woo 认为，最关键的两个原因是使命和聚焦。

第一是统一使命。

Anthropic 招的人，真的在意把安全的 AGI 带给全人类。这个使命不是挂在墙上的口号，而是会进入具体决策。

当两个优先级冲突时，他们会问：哪个对 Anthropic 的使命更重要？一旦决定，大家就会站到同一边。

第二是聚焦。

她特别区分了使命和聚焦。使命意味着，团队愿意为了公司整体目标，牺牲自己产品线的局部目标。她甚至说，如果 Claude Code 失败了，但 Anthropic 成功了，她会非常开心。

这句话很重。

它说明团队不是在为某个产品的小胜利服务，而是在为公司更大的目标服务。这种共识让跨组织决策更快，也让大家更愿意做困难取舍。

Claude Code、Desktop、Mobile、Co-work 分别适合什么？

Cat Woo 也解释了几个产品的使用场景。

Claude Code CLI 是最强的入口。新功能往往先落到 CLI 上，所以它适合一次性编码任务，或者同时启动少量编码任务。

Claude Code Desktop 更适合前端工作。比如做 Web App 时，可以把预览面板开在右侧，一边和 Claude 对话，一边实时看应用长什么样。它也更适合不习惯终端的人，因为图形界面比命令行友好得多。

Desktop 还有一个作用：控制台。你可以看到 CLI、Desktop、Web、Mobile 上启动的所有 session。

Web 和 Mobile 的价值在于“路上也能开工”。不必打开笔记本，也不必为了等 agent 跑完而抱着电脑连手机热点。走路、出门、摸草的时候，也能把任务派出去。

Co-work 则是非代码工作的入口。

如果输出是代码，用 Claude Code。如果输出不是代码，比如清 Slack、清邮件、做客户会议 deck、写功能目标文档、写发布计划，就用 Co-work。

Co-work 的正确打开方式：先喂足上下文

Cat Woo 说，想用好 Co-work，第一件事是连接数据源。

她会连接 Google Calendar、Slack、Gmail、Google Drive。因为 Co-work 只有拿到足够上下文，才能做出真正贴合你的输出。

她举了一个例子：Code with Claude 大会前，她需要准备一个关于 Claude Code 如何从 assistant 演进成 agent 的演讲。她把 PMM 的建议、自己不满意的初稿、想讲的叙事都交给 Co-work。

Co-work 花了一个小时，去看 Twitter 上发布过什么，去常设发布频道找功能，去 Claude Code announce channel 找内部成功案例和 demo，最后合成了一个 20 页 deck。

她早上醒来看到成品，觉得已经相当不错。虽然还需要改，比如她喜欢极简文字，初稿有点太啰嗦，但它已经大幅节省了时间。

更关键的是，因为它能接触到 Anthropic 的设计模板和设计系统，做出来的东西看起来像设计师做的，不只是内容正确，视觉也像公司自己的东西。

她给出的提示词并不复杂，大意是：

给我做一份 Code with Claude 大会用的 slide deck。这是 PMM 建议覆盖的内容，这是我自己做但不满意的草稿，这是另一个手动版本。先给我一个详细大纲，也要注意不要和更重要的 keynote 重叠太多。

Claude 先读材料，产出大纲和不同思路。她作为 PM 再做最终判断：哪些要放进最终版本，哪些 demo 最有说服力。然后 Co-work 再继续生成完整 deck。

这正好说明 AI 时代 PM 的角色：AI 很适合发散、检索、综合、生成候选方案；PM 仍然要决定最终产品里该留下什么。

个性化工作软件会大量出现

Cat Woo 说，Claude Code 给 Anthropic 内部解锁了一件事：让每个人都更容易做自己的小工具。

以前你想做一个贴合自己流程的内部工具，成本很高。现在很多人会直接用 Claude Code 做一个小 Web App，解决自己反复遇到的问题。

比如 Cloud Code 销售团队里有人经常要做客户 deck。于是他做了一个工具，里面有几套经过验证的 Claude Code 标准 deck，比如 101、201、mastering Claude Code。

然后工具会根据客户上下文自动定制：从 Salesforce、Gong、会议笔记里拉信息，判断客户用的是 Bedrock、Claude Code for Enterprise 还是 Console，关注的是代码审查、安全控制，还是 HIPAA 合规。然后自动增删对应 slides。

过去这种定制可能要 20 到 30 分钟，很多人嫌麻烦就直接用通用 deck。现在几秒钟能得到一个客户专属版本。

这就是 AI 时代很实际的生产力变化：不是所有东西都变成通用 SaaS，而是每个人都能给自己的工作缝一个刚好合身的小工具。

Slack 仍然是很多公司的操作系统

访谈里还有一个有趣的小观察：Anthropic 很依赖 Slack。

Cat Woo 说 Slack 基本是公司的 core OS。实时更新、团队协作、内部 bot、自定义 workflow 都在里面发生。

很多人吐槽 Slack，但它在“让所有人获得实时更新”这件事上确实做得很好。更重要的是，它非常 hackable，团队可以做很多 Slack bot，把自己的流程接进去。

在 AI 工具爆发的时代，Slack 这种通讯基础设施反而显得更稳。因为 Agent 可以越来越强，但组织里仍然需要一个地方承载上下文、反馈、发布、讨论和协作。

Token 花费会上升，但浪费仍然可耻

主持人问到一个最近常被讨论的话题：AI token 成本会不会超过员工工资？

Cat Woo 没给具体数字，但她确认了一个趋势：模型越强，人们越愿意把任务交给它，知识工作者在 Claude Code 和 Co-work 里的时间会变多，token 成本也会随着模型升级和产品能力提升而上升。

目前看，token 成本仍然远低于平均工程师薪资，但占比在增加。

Anthropic 内部可以使用很多 token，但不是毫无限制。团队也相信大家理解模型服务成本，会负责任地使用。浪费 token 是被 frowned upon 的。

这其实也反映了未来组织里的新常识：AI 使用不是免费午餐，但只要它带来的杠杆足够大，成本就是值得的。关键是别把昂贵推理用在没价值的事上。

AI PM 最稀缺的能力：刚好“AGI pilled”

Cat Woo 认为，AI 公司现在最看重的 PM 能力，是能定义一个月后产品该长什么样。

这很难，因为模型能力一个月后会变成什么样，用户行为会怎么变，都不确定。

最好的 PM 能从用户“滥用”现有产品边界的方式里看到模式，设定方向，持续执行。如果模型能力比预期更强或更弱，也能及时调整路径。

她用了一个非常妙的说法：要做“刚刚好 AGI pilled”的人。

如果你太相信未来超强模型，就会觉得产品很简单，直接给一个文本框就好了。模型足够聪明，自己知道加工具、接集成、问澄清问题、完成任务。

为这种超级模型做产品其实不难。

难的是为当前模型做产品：

  • 怎么激发它的最大能力
  • 怎么引导用户走上 golden path
  • 怎么让用户用它的强项，绕开或补上它的弱点
  • 哪些地方该靠产品 harness，哪些地方该等模型进化

这种判断非常稀缺。

怎么培养这种能力？天天用，追问模型为什么失败

Cat Woo 的建议很直接：大量使用模型。

当模型做出奇怪行为，不要只是骂它。要问它为什么这么做。

比如模型做了一个前端改动，跑了测试，却没有真正打开 UI 验证。你可以问它为什么。它可能会说：系统提示里有模糊点；它没意识到前端验证是任务的一部分；它把验证交给了子 agent，但没检查子 agent 的结果。

这种追问能暴露出模型被什么误导，然后你才能修 harness、改提示、补流程。

她还建议找到 5 个真正会评价模型的人。

不是所有反馈都一样有价值。有些人能准确说出一个模型或 harness 为什么好、哪里差、具体失败模式是什么。找到这样的小圈子，可以大幅提高反馈质量。

第三件事是做 eval。

不一定要一上来做几百个 eval。10 个高质量 eval 就很有用，因为它们能帮助团队明确目标，量化进展，看到缺口。

她认为 eval 被低估了，更多 PM 和工程师都应该参与。

Claude 的“性格”不是装饰，是能力的一部分

访谈里还聊到 Claude 的 character。

Cat Woo 特别提到 Amanda，负责塑造 Claude 的性格。她认为这项工作很难，因为不像代码那样容易验证。你需要对 Claude 应该成为什么样有强烈判断，还要能说清楚什么算成功，什么不算。

Claude 受欢迎，不只是因为它会做题、会写代码，也因为人们喜欢它的工作方式。

它轻松、有趣、低 ego、愿意承认错误，也有行动倾向。你指出它做错了，它会真诚地说“谢谢提醒，我来修”。你面对一个巨大任务不知从何开始，它会积极拆步骤，并问要不要先帮你动手。

一个好的 AI coworker，不应该只会顺着用户说。它要积极、能行动，也能给真诚反馈。

这就是为什么“性格”不是表面包装，而会影响用户是否愿意和它长期协作。

模型越强，产品越要删东西

新模型出来后，团队经常要回头看以前做过的功能。

很多功能其实是给旧模型加的拐杖。模型不够强时，产品要在旁边提醒它、约束它、帮它记住步骤。模型变强后，这些拐杖就可以拆掉。

一个典型例子是 to-do list。

早期 Claude Code 做大型重构时，可能需要改 20 个 call site，但改了 5 个就停。团队于是加了 to-do list，让它像人类一样列出所有要改的点，一个个完成。

后来 Opus 4 以及之后的模型变强了，不再需要反复提醒。模型会自然使用列表，也会自然完成所有事项。to-do list 还对用户可见性有帮助，但已经不再是模型完成任务的必要条件。

Cat Woo 说，每次新模型发布，他们都会重新读系统提示，问自己：这段提醒还需要吗？如果不需要，就删掉。

这很符合那句流行说法：模型会把你的 harness 当早餐吃掉。

但新模型不只是让产品变简单，也会打开新功能。比如代码审查，团队试过几次，早期模型准确率不够高，只能做简单版本。到新一代 Opus 和 Sonnet 后，他们才觉得代码审查已经可靠到能成为合并 PR 前的重要检查。

所以一个重要策略是：提前做那些“现在还不完全可行”的原型。等新模型来了，把它换进去，看缺口是不是被补上了。

Claude Code 和 Co-work 的长期方向：从一个任务，到上百个 agent

Cat Woo 用 building blocks 来解释愿景。

最基本的 building block 是单个任务成功。你给一个清楚的任务描述，它能稳定产出可合并、可分享、可交付的结果。

当单个任务成功率提高，用户就会开始同时跑多个任务。2025 年底 multi-coding 已经成为趋势，之后只会更明显。

再往后，用户可能同时跑 50 个 Claude，甚至上百个 Claude。

那时本地机器可能不够用了，任务会更多跑在远端。产品要解决的新问题就变成：

  • 怎么管理这些远程 agent
  • 人类该看哪些任务
  • agent 怎么验证自己的工作
  • 用户如何快速相信“完成了”真的符合需求
  • 如果某个任务没做好，如何把反馈沉淀下来，让未来不再犯同样错误

这是从“AI 帮你做一个任务”，走向“AI 帮你管理一大片任务网络”的过程。

给普通人的建议：别只玩 demo，去自动化真实工作

很多人现在还停留在“玩 AI”的阶段。随手做个小应用，觉得很酷，然后再也不用。

Cat Woo 不太建议这样。

她更鼓励大家做每天真的会用的东西。因为只有真实使用，才会产生真实杠杆。

她的建议非常实用：

  • 找出你工作里反复手动做的事
  • 用 Claude Code、Co-work 或其他 AI 工具自动化它
  • 不要停在 90% 或 95% 成功率
  • 把它打磨到接近 100%，直到你真的能依赖它
  • 然后把省下来的时间用于更重要、更有创造性的工作

她说，如果一个自动化不能 100% 工作，它其实还不算真正的自动化。

最后 5% 到 10% 往往最花时间，而且构建自动化本身可能比你手动做还慢。但只要这是你反复做的事，投入就值得。

她自己也承认，在让 Co-work 帮她实现 Gmail inbox zero 这件事上，她还没完全成功，过程很费时间。

这点很真实。AI 自动化不是按一下按钮就永远完美，它需要反馈、偏好、修正和耐心。

简单设置通常更好

Cat Woo 也提醒另一类人：不要沉迷配置。

有些人完全不做自动化，这是一个极端。另一个极端是把所有时间都花在自定义 workflow、加技能、加 MCP、优化工具链上，结果忘了自己原本要做什么。

她不是反对 hackability。相反，Claude Code 和 Co-work 都希望产品足够可定制。

但定制要服务于目标。如果你的 setup 很酷，却没有帮你发产品、做功能、解决问题，那它就变成了另一种拖延。

她的判断很干脆：简单设置往往效果更好。

从聊天式 AI 到行动式 AI，这是很多人的分水岭

访谈最后提到一个现象：有些人早年试过 ChatGPT 或 Claude，觉得“也就那样”，后来就对 AI 失去兴趣。另一群人则通过 AI 编程看到了完全不同的世界。

Cat Woo 认为，大变化在于：2024 年那一代产品主要是 chat-based，而 Claude Code 这一代产品是 action-based。

真正让人眼睛亮起来的时刻，不是 AI 告诉你该怎么做，而是它真的替你做了。

它能改代码、跑测试、填表单、生成 deck、总结会议、查上下文、启动任务。那一刻，AI 不再只是一个会说话的工具，而像一个能行动的同事。

Cat Woo 的几条私人答案，也很能解释她的工作方式

闪电问答里，她推荐了几本书：

  • 《How Asia Works》，关于经济发展和长期成功经济体背后的政策选择
  • 《The Technology Trap》，关于工业革命、计算机革命等技术变迁如何影响劳动者
  • 《The Paper Menagerie》，一本关于成长、AI、自我发现的短篇小说集

她喜欢《Drive to Survive》和《Free Solo》。前者是对单一工程目标的极致追求，后者是 Alex Honnold 无保护攀登 El Capitan。她自己也是攀岩者，所以更知道那种成就有多疯狂。

她最近最改变生活的产品是 Waymo。原因不是酷炫，而是非常具体：车等她时她不会有愧疚感；坐车时可以安心开工作电话，不担心司机听到，也不觉得打扰别人。她愿意为这种体验付 Uber 或 Lyft 的两倍价格。

她的人生 motto 是：Just do things.

如果你知道自己在优化什么，也理解约束，就能推导出大致正确的行动，然后去做。做错了就道歉，修正，继续。

她说“jobs are fake”，意思不是工作不重要，而是角色边界并没有那么神圣。PM、设计、工程、销售、运营，这些边界很多时候只是组织为了方便管理画出来的线。真正重要的是问题在那里，你能不能跨过边界把它解决掉。

最后：AI 时代的产品力，像是在移动靶上开枪

这场访谈最有价值的地方，不是告诉你 Claude Code 或 Co-work 又做了什么功能，而是让你看到 AI 原生产品团队的工作方式已经变了。

节奏更快，角色更混，反馈更近，原型更多，产品也更不稳定。

但越是在这种环境里，越能看出一些东西不会过时：

  • 清楚定义目标
  • 判断什么值得做
  • 理解用户真正的痛点
  • 快速把东西交到用户手里
  • 认真听失败案例
  • 低 ego 地补团队缺口
  • 把重复工作自动化到真的可依赖
  • 不沉迷工具，而是用工具做事

代码会越来越便宜，模型会越来越强，很多今天需要产品设计补上的地方，明天可能会被模型吃掉。

可也正因为这样，知道该往哪里走的人会更值钱。

未来的 PM，不一定是写最多 PRD 的人，也不一定是开最多会的人。

更像是那个能在混乱里看清方向、把模糊变成可执行目标、让团队更快靠近用户的人。

说白了，就是 Cat Woo 那句话：先想清楚，然后 just do things。