今天下班和 mentor 聊完以后，我感觉有些话对我挺有价值的，也确实点到了我最近这段时间的状态，所以想认真整理一下。
这次聊完以后，我越来越确定一件事：之后做事情，不能再只是被动接需求、做实现，而是要更主动地去看业务、看链路、看规范，也看一件事情有没有长期维护的价值。
我现在一个很明显的问题：有点浮躁
我觉得我现在一个很明显的问题，就是有点浮躁。
现在每天做的事情，很多时候就是站点开发和维护，来一个新站点，就去写脚本、适配流程。做久了以后，就会觉得这件事很机械，很重复，也容易让人陷进去，只看到眼前这一点点事。
慢慢就会有一种感觉，好像每天都很忙，但成长感不强，反馈也不强，最后就容易把自己做成一个被动执行的人。
不能只停留在“怎么实现”
但其实最近我也做了一条我觉得挺重要的链路，就是 Cover Letter 这块。用户在我们的插件里通过 Agent 生成介绍信，然后再把这部分内容填充到海外申请页面里。
这个事情如果只从代码层面去看，好像就是写个 skill，把链路打通，把功能维护好，也就差不多了。但我现在越来越觉得，如果我只是这样看，那还是把眼界放小了。
我不能只是停留在“怎么实现”，而应该先去想：
- 为什么这么做
- 现在这么做有什么问题
- 这个链路对业务的价值到底在哪里
我觉得我以前的问题，就是太容易直接扎进实现里，一上来就想怎么做、怎么写、怎么接接口。
但其实“怎么实现”反而应该是最后一步。更前面的东西应该是先想清楚：为什么要做这件事，这件事当前的弊端是什么，做的过程中大概会遇到哪些问题，它和过去哪些问题相似，有没有可以复用的经验。
现在我自己其实还是比较死板，很多时候只能想到“这次遇到的问题是什么”，但还没有形成一套属于自己的方法论。这一点我觉得是我接下来很需要进步的地方。
先思考，不是空想，也不是拖延
所以我现在会觉得，之后再做事情，第一步应该是先思考。
但这个思考不是空想，也不是拖延，而是先把问题提出来，把需求捋清楚。尤其现在很多需求本来就是新的，这种情况下，其实更没必要为了赶时间就跳过理解，直接开始做。
因为认真把需求梳理清楚、把问题定义清楚，本身也花不了特别长时间，但这一步会直接决定后面事情做得顺不顺，值不值得做，做出来是不是对的。
要慢慢从技术执行走向业务视角
老师今天点醒我的另一个地方是，插件这个项目其实有很多可以主动维护、主动深入的地方。
不是说我现在做的脚本没有价值，而是我不能只把自己限定在“写脚本”这件事上。我要开始把自己从单纯技术执行的视角，慢慢往业务视角转。
不能老觉得公司赚不赚钱、项目做得怎么样和我关系不大。实际上，我既然在这个项目里，就应该把它当成自己参与的一部分，去想它哪里不合理，哪里可以优化，哪里值得长期维护，哪里能真正帮助业务。
项目里很多问题，其实值得主动往下钻
其实中间我也不是完全没有这方面的意识。比如一些数据格式的问题，前后端数据字段的统一，还有快照逻辑。
我现在越来越感觉，项目里很多页面的快照实现其实是比较混乱的，大家各写各的，没有特别统一的规范。这种地方如果一直放着，后面只会越来越乱。
以前可能会觉得，建立一套规范很麻烦，但现在有 AI，很多具体的体力活其实没有想象中那么难。页面本身很多都已经有快照逻辑了，真正缺的是统一的格式、统一的约束、统一的整理方式。
这个事情本身并不是做不到，关键还是看自己有没有主动维护的意识。
小团队更考验人主动补空白的能力
我现在也越来越明白，初创团队、小公司和大厂不一样。
大厂很多时候体系已经很成熟，任务拆好了，到你手里你把那一块做好就行；但小团队更考验人的是，你能不能自己发现问题、自己定义问题、自己把空白补起来。
如果只是一直等着别人安排，那最后就会一直停留在一个很被动的位置。
我觉得我身上确实还有一点以前做学习被动了解留下来的习惯，就是容易等安排，按需求做完就结束，不太会主动往前走。这一点我得改。
不能只顾着“找信息”，不去“消化信息”
还有一点我最近很有感触，就是不能只顾着“找信息”，不去“消化信息”。
之前我会觉得每周会议、大家在推进什么、别人在做什么，我也得赶紧知道，甚至有点想去“偷听”这些东西。
但现在我觉得重点可能不在“偷”，因为很多内容本来就在文档里，也有人持续维护。真正重要的是，我能不能把这些东西消化掉，理解进去，而不是看了一圈，好像知道很多，其实都只是停留在表面。
所以我现在更想做的事情，是先把项目结合 PRD、结合已有文档、结合过去的迭代，一个个去消化。
不是说一下子把整个项目全部吃透，而是慢慢去理解：之前为什么这么设计，遇到过哪些问题，现在还有哪些问题，这些问题之间有没有共性。
这样做，才算是真正进入这个项目，而不是一直浮在外围。
优化不是喊口号，而是把链路一段段拆开
老师今天其实也相当于给了我一个任务。就是 Cover Letter 这条链路，我做了一周，不能只是觉得“做完了”就算了，而是要把它完整地再捋一遍：
- 整个链路到底是怎么走的
- 中间有哪些 bug
- 真实使用的时候会出什么问题
- 每一步能不能更顺一点
- 每个接口有没有可以优化的地方
以前我做测试，可能也做，但没有老师看得那么细。老师那种方式其实是在提醒我，优化不是喊口号，不是这里改一下、那里改一下就算优化，而是每一步都拆开来看，看看有没有更合理的方案。
只有这样，优化才是有效的。
数据这块也是一样。不能只是会调接口、会传字段就完了，而是要去理解这些数据为什么这样设计，当前有哪些不合理，未来还能不能更清晰、复用性更高。
这些东西如果不去钻，就永远只是“会用”，但不会真正变成自己的理解。
能沉淀、能复用、能迁移的东西，才算自己的资产
另外一个让我比较有收获的点，是知识库和文档整理。
老师也夸了我这方面做得还不错，我自己回头看，也觉得这可能是我这段时间少数真正有沉淀的地方。虽然我很多东西确实还是做得比较散、比较浅，但知识库这块我一直是有感觉的。
甚至在这些概念还没那么明显的时候，我自己就已经在想怎么维护一套东西。以前写笔记的时候，我就倾向于用 Markdown，想把内容统一存放、统一管理。只是当时确实做得比较乱，一个项目一个笔记、一个事情一个文档，最后反而不好管理，越积越散。
但我现在反而觉得，这也说明这件事本身是值得我继续往下做的。因为知识库管理、项目文档整理、信息沉淀这些事情，本质上就是在帮我形成自己的闭环。
所谓闭环，我现在越来越觉得，就是你做过的东西能不能沉淀下来，能不能复用，能不能在别的地方再转起来。如果一套东西只能在当下用一下，用完就散了，那它就不算真正的资产。
只有能复用、能迁移、能不断迭代的东西，才算是自己的资产。
所以我也想后面把知识库管理这件事再总结一下，尽量做成一套自己能消化、能维护、能复用的体系。这个体系不一定多复杂，但至少它应该是闭环的。
包括项目管理也是一样，很多东西都应该尽量形成闭环，而不是停留在“我知道了”“我做过了”这种很松散的状态。
AI 不只是帮我做事，更应该帮我捋清思路
我现在还意识到一个问题，就是我对 AI 的使用，其实也还没有真正用到位。
一方面我知道应该多借助 AI 去帮我梳理问题、帮助表达，但另一方面我又有点懒，有时候脑子里有些想法，自己没有先整理清楚，就希望通过语音或者随便说一说把它带过去。
但其实很多时候，表达不清，本质上就是自己还没想清楚。
昨天不是也有一句话说得挺对的：你表达不好，就是你不知道自己想说什么。
我觉得我现在很多时候就是这种状态，脑子里明明有东西，但说不出来，一到真正要对别人表达的时候，就显得很乱。
接下来最该练的，是判断、理解和表达
所以我接下来最需要做的，可能不是再追求表面上的“做了很多”，而是先把自己的思路练清楚，把问题练清楚。
遇到事情，不是马上陷进“完了怎么办”，而是先去发现问题、了解问题、拆分问题、思考问题，然后再解决问题。
解决问题其实反而是最后的结果展示。在 AI 越来越强的情况下，最后那一步本身的重要性可能还在下降。真正更重要的，反而是上下文、判断、理解能力、思考能力。这些才是我不能丢的东西。
所以我觉得，我之后还是要更主动地和 AI 对话，不是为了依赖它，而是为了借这个过程把自己的思维捋清楚。
先把脑子里那些模糊的默认概念尽量说出来，再慢慢整理。慢慢来，别急。
最后想提醒自己的话
现在最重要的，一个是心态上要平稳，不要太浮躁；另一个是行动上要主动，不能总等着别人推着走。
既要稳，也要主动。
最后还是要回到那件事上：
- 多思考
- 多钻研
- 多沉淀
- 少一点浮在表面的聪明
- 少一点东一榔头西一棒子的状态
我觉得这次聊完以后，对我最大的提醒就是，我不能再只是被动地做事了。我要更踏实一点，也更主动一点。多想一步为什么，多问一步价值是什么，多沉淀一点属于自己的东西。
只有这样，项目经验才不会只是“做过”，而会慢慢变成我自己的能力和资产。
加油吧。