1. 从“skills”这个词说起它到底指什么“skills”这个词单独拎出来看信息量其实非常低。它可以是简历上的一栏可以是招聘网站上的筛选标签也可以是某个培训课程的卖点。但正因为它的含义足够宽泛反而成了一个特别值得拆解的对象——因为每个人、每个团队、每个阶段对“skills”的理解都不一样而这种理解上的偏差往往就是实际做事时踩坑的根源。我做了十多年一线项目带过新人也做过技术评审发现一个很普遍的现象很多人把“skills”等同于“会用什么工具”。比如简历上写“掌握某某框架”“熟悉某某平台”面试的时候也能说出几个专业术语但真到了项目里让他独立拆解一个需求、判断一个方案能不能落地、预估一个任务的工作量就卡住了。这说明什么说明他拥有的只是工具层面的技能而不是解决问题的能力。所以这篇内容我想聊的“skills”不是那种挂在嘴边的空泛概念而是从实际做事的角度把技能拆成几个可以观察、可以训练、可以验证的层次。不管你是刚入行的新手还是带团队的中坚力量这套拆解方式都能帮你更清楚地知道自己缺什么、该补什么、怎么补。具体来说我会围绕以下几个问题展开技能到底分几层每层的核心要求是什么为什么很多人学了很多但用不出来在实际项目中哪些技能是真正拉开差距的以及最关键的——怎么用一套可操作的方法把“不会”变成“会”把“会一点”变成“能扛事”。这篇文章适合几类人看一是正在整理自己技能体系、准备换工作或晋升的人二是带团队、需要评估成员能力并制定培养计划的人三是单纯觉得自己“学了很多但没什么长进”、想找到突破口的人。我会尽量用大白话和实际案例来讲不堆术语不搞虚的。2. 技能的分层逻辑为什么“会”和“能用”之间差了一条河2.1 第一层知道是什么——信息层这是最浅的一层。你知道某个概念、某个工具、某个方法的名字能说出它的基本定义甚至能背出几个关键参数。比如你知道“版本控制”是用来管理代码变更的“单元测试”是用来验证单个函数正确性的“需求评审”是为了在开发前对齐理解。这一层的特点是获取成本极低但遗忘速度极快。你看一篇文章、刷一个短视频、听一场分享就能获得大量这类信息。但如果你不往下走这些信息就只是谈资过两周就忘干净了。我见过不少人在这一层就停住了误以为自己已经“掌握”了。举个例子某次内部讨论有人提到“我们可以用缓存来提升性能”听起来很对但当我问“缓存什么数据、缓存多久、失效策略是什么、缓存击穿怎么处理”的时候他就答不上来了。这就是典型的只停留在信息层。注意信息层不是没用它是入口。但如果你把入口当终点后面所有的技能都无从谈起。2.2 第二层知道怎么做——操作层到了这一层你不仅知道概念还能动手做出来。比如你知道版本控制的概念还能熟练执行提交、分支、合并、回滚这些操作你知道单元测试的概念还能写出覆盖主要逻辑的测试用例并跑通。操作层的核心是重复练习。没有捷径就是动手。看十遍教程不如自己从头做一遍。这一层的典型特征是有参考就能做没参考就卡壳。比如你跟着文档能搭出一个项目骨架但让你从零设计一个模块你就不知道从哪下手了。这一层最容易出现的问题是“照着抄会了换个场景就废了”。原因在于操作层的技能往往是和具体工具、具体步骤绑定的一旦工具换了、需求变了你就需要重新学。所以操作层之上还有一层更关键的东西。2.3 第三层知道为什么这么做——原理层这一层是拉开差距的地方。你不仅会操作还理解背后的原理和权衡。比如你知道为什么要做单元测试——不是为了完成指标而是为了在修改代码时能快速发现回归问题你知道为什么要做需求评审——不是为了走流程而是为了在成本最低的阶段发现理解偏差。原理层的核心是追问和复盘。每做完一件事问自己几个问题为什么用这个方案而不是那个如果换个条件这个方案还成立吗当时如果选了另一条路结果会怎样我个人的经验是原理层的积累主要来自两个途径一是主动深挖遇到不懂的机制就去查资料、做实验直到能用自己的话讲清楚二是被动踩坑出了问题之后认真复盘找到根因而不是改完就过。后者往往印象更深但代价也更大。所以聪明人会从别人的坑里学原理而不是非得自己踩一遍。2.4 第四层知道什么场景用什么——决策层这是最高一层也是真正意义上的“专家”和“熟手”的分水岭。到了这一层你面对一个模糊的需求能快速判断出应该用什么方法、投入多少资源、可能遇到什么风险、备选方案是什么。决策层的核心是模式识别。你见过足够多的场景做过足够多的权衡所以能在信息不完整的情况下做出大概率正确的判断。这种能力很难通过看书或听课获得必须在真实项目中反复磨练。举个例子同样一个功能新手可能会直接选最熟悉的技术栈熟手会考虑团队的技术储备和维护成本而决策层的人会进一步考虑这个功能未来会不会扩展、当前阶段是否值得投入、有没有更轻量的替代方案。这三种思考方式的差距就是技能层级的差距。层级核心特征典型表现提升方式信息层知道概念能说出名词和定义阅读、听课操作层能动手做有参考能完成重复练习原理层理解为什么能解释权衡和取舍追问、复盘决策层判断用什么模糊场景下能决策真实项目磨练3. 实际项目中真正拉开差距的几个技能点3.1 把模糊需求拆成可执行任务的能力这是我在带新人的时候最看重的一点。很多人拿到一个需求第一反应是“这个怎么做”然后就开始想技术方案。但更有经验的人会先问这个需求要解决什么问题用户是谁核心场景是什么边界在哪里哪些是必须做的哪些是可以砍的这个拆解过程本身就是一项核心技能。它要求你既能站在用户角度理解问题又能站在实现角度评估成本还要能在两者之间找到平衡。我见过太多项目技术方案做得很漂亮但做出来的东西没人用根因就是需求拆解阶段出了问题。具体怎么练我的建议是每次拿到需求先别急着想怎么做而是用一句话把需求重新写一遍然后列出三个必须满足的条件和三个可以妥协的点。如果你写不出来说明你还没理解清楚这时候去问、去确认比闷头做要高效得多。3.2 预估工作量和风险的能力预估这件事新手和老手的差距非常明显。新手往往只考虑“顺利情况下的时间”忽略调试、联调、返工、沟通这些隐性成本。老手则会留出缓冲并且能识别出哪些环节风险最高。我自己的习惯是把任务拆到半天以内的粒度然后对每个子任务做三档预估——乐观、正常、悲观。最后取正常值加总再整体加20%的缓冲。如果某个子任务的悲观值和乐观值差距超过三倍那它就是高风险项需要提前想办法降低不确定性。这个习惯看起来简单但坚持下来能大幅提升预估准确率。更重要的是它逼着你去识别风险而不是等到出问题了才手忙脚乱。3.3 清晰表达和同步信息的能力这项技能经常被低估。很多人觉得“我把活干好就行了”但实际上在团队协作中表达和同步的成本往往比干活本身还高。一个表达不清的会议可能浪费五个人各一小时一份写得含糊的文档可能让下游的人反复来问。清晰表达的核心是换位思考。你在写文档、发消息、开会的时候要时刻想着对方需要知道什么、已经知道什么、可能误解什么。我自己的做法是重要的信息至少用两种方式表达——文字加图示或者口头加书面确认。这样能大幅降低理解偏差。3.4 持续学习和快速上手新东西的能力这一条听起来很虚但实际项目中非常具体。技术栈在变工具在变需求也在变没有人能靠一套技能吃一辈子。真正拉开差距的不是你现在会什么而是你学新东西的速度。快速上手的关键是建立知识框架。面对一个新领域先花时间搞清楚它的整体结构、核心概念、常见模式然后再深入细节。这比一上来就抠细节要高效得多。我通常会用“三遍法”第一遍快速浏览建立全局印象第二遍重点突破搞懂核心机制第三遍动手实践在做的过程中补细节。4. 一套可落地的技能提升方法4.1 建立个人技能清单第一步是把自己现有的技能梳理清楚。不要笼统地写“会编程”“会设计”而是具体到能做什么、做到什么程度。比如“能用某语言独立完成一个包含增删改查的接口服务”“能独立完成一个页面的布局和交互”“能组织一次十人以内的需求评审”。梳理的时候按前面说的四个层级来标注哪些是信息层只知道概念哪些是操作层能照着做哪些是原理层能解释为什么哪些是决策层能判断用什么。这样你就能清楚地看到自己的技能分布知道哪些地方需要补。4.2 针对薄弱环节做刻意练习技能提升的关键不是“多学”而是“有针对性地练”。如果你发现自己大部分技能都停留在操作层那就需要刻意去追问原理。具体做法是每完成一个任务写一段复盘回答三个问题——做了什么、为什么这么做、如果重来会怎么改。如果你发现自己原理层的东西不少但决策层很弱那就需要主动去承担更模糊、更复杂的任务。哪怕一开始做得不好也比一直做熟悉的事情强。决策能力只能在决策中练出来。4.3 用输出倒逼输入这是我个人觉得最有效的方法。当你尝试把学到的东西讲给别人听、写成文档、做成分享的时候你会发现自己以为懂的地方其实没懂。这种“输出倒逼输入”的机制能帮你快速发现知识盲区。具体形式可以灵活写技术笔记、做内部分享、在社区回答问题、甚至只是给同事讲一遍。关键是用自己的话重新组织而不是照搬原文。这个过程本身就是深度加工能大幅提升留存率。4.4 找反馈和对照自己练容易陷入盲区所以需要外部反馈。找比你更有经验的人看你的产出请他指出问题或者找同水平的人互相 review在讨论中发现彼此的不足。反馈越具体越好不要问“你觉得怎么样”而是问“这个方案在什么情况下会出问题”“如果让你改你会先改哪里”。5. 常见问题和避坑指南5.1 学了很多但用不出来怎么办这是最常见的问题。根因通常是学的时候只停留在信息层没有动手做也没有追问原理。解决办法很简单——以用代学。找一个真实的小项目哪怕很简单从头到尾做一遍。做的过程中遇到问题就去查、去问、去试。做完之后复盘把关键决策点记下来。这样一轮下来比看十篇文章都管用。5.2 不知道自己该学什么怎么办先别急着学新东西先把手头的事情做到极致。你现在做的任务有没有更高效的解法有没有你没注意到的风险有没有可以自动化的部分把这些想清楚你就知道自己该学什么了。技能提升不是漫无目的地收集知识而是围绕当前问题做针对性补强。5.3 感觉进步很慢怎么办进步慢通常有两个原因一是练得不够二是练的方式不对。如果是前者增加练习量如果是后者检查自己是不是一直在做已经会的事情。真正的进步发生在“稍微超出当前能力”的区域太简单或太难都不行。找到那个边界然后反复练。5.4 怎么判断自己到了什么水平一个简单的判断标准能不能独立负责一个完整的事情并对结果负责。如果你需要别人告诉你每一步怎么做那你还在操作层如果你能自己拆解任务、设计方案、预估风险、推进落地那你已经到了原理层和决策层之间。再往上就是能在模糊和不确定中做出判断并带着别人一起把事情做成。常见问题根因解决方向学了很多用不出来停留在信息层以用代学做完整项目不知道学什么脱离实际问题从当前任务中找缺口进步慢练习方式不对在能力边缘刻意练习不清楚自己水平缺乏评估标准看能否独立负责完整事情6. 我个人的一些实操体会带过不少新人之后我发现一个规律那些成长快的人往往不是最聪明的而是最愿意动手、最愿意复盘、最愿意问为什么的。他们可能一开始基础一般但每做一件事都能吸收到东西半年下来就能明显看出差距。另一个体会是技能提升不是线性的。有时候你感觉卡住了怎么练都没进步这时候别急可能是到了平台期。换个角度、换个项目、或者干脆休息几天回来之后往往会有突破。我自己的经验是每次觉得“怎么都做不好”的时候过一段时间回头看其实已经比之前强了不少只是当时身在其中感觉不到。还有一点很重要别把技能当成标签。会什么不重要能用它解决什么问题才重要。我见过简历上写满各种技术名词的人实际做事一塌糊涂也见过简历很朴素但什么问题都能搞定的人。前者是在收集标签后者是在积累能力。这两条路越往后差距越大。最后分享一个我一直在用的小方法每个月花半小时写下这个月做的最有挑战的一件事然后回答三个问题——当时是怎么想的、结果怎么样、如果重来会怎么改。不用写很长几百字就行。坚持一年下来你会对自己有非常清晰的认识也会知道下一步该往哪走。
1. 从“skills”这个词说起它到底指什么“skills”这个词单独拎出来看信息量其实非常低。它可以是简历上的一栏可以是招聘网站上的筛选标签也可以是某个培训课程的卖点。但正因为它的含义足够宽泛反而成了一个特别值得拆解的对象——因为每个人、每个团队、每个阶段对“skills”的理解都不一样而这种理解上的偏差往往就是实际做事时踩坑的根源。我做了十多年一线项目带过新人也做过技术评审发现一个很普遍的现象很多人把“skills”等同于“会用什么工具”。比如简历上写“掌握某某框架”“熟悉某某平台”面试的时候也能说出几个专业术语但真到了项目里让他独立拆解一个需求、判断一个方案能不能落地、预估一个任务的工作量就卡住了。这说明什么说明他拥有的只是工具层面的技能而不是解决问题的能力。所以这篇内容我想聊的“skills”不是那种挂在嘴边的空泛概念而是从实际做事的角度把技能拆成几个可以观察、可以训练、可以验证的层次。不管你是刚入行的新手还是带团队的中坚力量这套拆解方式都能帮你更清楚地知道自己缺什么、该补什么、怎么补。具体来说我会围绕以下几个问题展开技能到底分几层每层的核心要求是什么为什么很多人学了很多但用不出来在实际项目中哪些技能是真正拉开差距的以及最关键的——怎么用一套可操作的方法把“不会”变成“会”把“会一点”变成“能扛事”。这篇文章适合几类人看一是正在整理自己技能体系、准备换工作或晋升的人二是带团队、需要评估成员能力并制定培养计划的人三是单纯觉得自己“学了很多但没什么长进”、想找到突破口的人。我会尽量用大白话和实际案例来讲不堆术语不搞虚的。2. 技能的分层逻辑为什么“会”和“能用”之间差了一条河2.1 第一层知道是什么——信息层这是最浅的一层。你知道某个概念、某个工具、某个方法的名字能说出它的基本定义甚至能背出几个关键参数。比如你知道“版本控制”是用来管理代码变更的“单元测试”是用来验证单个函数正确性的“需求评审”是为了在开发前对齐理解。这一层的特点是获取成本极低但遗忘速度极快。你看一篇文章、刷一个短视频、听一场分享就能获得大量这类信息。但如果你不往下走这些信息就只是谈资过两周就忘干净了。我见过不少人在这一层就停住了误以为自己已经“掌握”了。举个例子某次内部讨论有人提到“我们可以用缓存来提升性能”听起来很对但当我问“缓存什么数据、缓存多久、失效策略是什么、缓存击穿怎么处理”的时候他就答不上来了。这就是典型的只停留在信息层。注意信息层不是没用它是入口。但如果你把入口当终点后面所有的技能都无从谈起。2.2 第二层知道怎么做——操作层到了这一层你不仅知道概念还能动手做出来。比如你知道版本控制的概念还能熟练执行提交、分支、合并、回滚这些操作你知道单元测试的概念还能写出覆盖主要逻辑的测试用例并跑通。操作层的核心是重复练习。没有捷径就是动手。看十遍教程不如自己从头做一遍。这一层的典型特征是有参考就能做没参考就卡壳。比如你跟着文档能搭出一个项目骨架但让你从零设计一个模块你就不知道从哪下手了。这一层最容易出现的问题是“照着抄会了换个场景就废了”。原因在于操作层的技能往往是和具体工具、具体步骤绑定的一旦工具换了、需求变了你就需要重新学。所以操作层之上还有一层更关键的东西。2.3 第三层知道为什么这么做——原理层这一层是拉开差距的地方。你不仅会操作还理解背后的原理和权衡。比如你知道为什么要做单元测试——不是为了完成指标而是为了在修改代码时能快速发现回归问题你知道为什么要做需求评审——不是为了走流程而是为了在成本最低的阶段发现理解偏差。原理层的核心是追问和复盘。每做完一件事问自己几个问题为什么用这个方案而不是那个如果换个条件这个方案还成立吗当时如果选了另一条路结果会怎样我个人的经验是原理层的积累主要来自两个途径一是主动深挖遇到不懂的机制就去查资料、做实验直到能用自己的话讲清楚二是被动踩坑出了问题之后认真复盘找到根因而不是改完就过。后者往往印象更深但代价也更大。所以聪明人会从别人的坑里学原理而不是非得自己踩一遍。2.4 第四层知道什么场景用什么——决策层这是最高一层也是真正意义上的“专家”和“熟手”的分水岭。到了这一层你面对一个模糊的需求能快速判断出应该用什么方法、投入多少资源、可能遇到什么风险、备选方案是什么。决策层的核心是模式识别。你见过足够多的场景做过足够多的权衡所以能在信息不完整的情况下做出大概率正确的判断。这种能力很难通过看书或听课获得必须在真实项目中反复磨练。举个例子同样一个功能新手可能会直接选最熟悉的技术栈熟手会考虑团队的技术储备和维护成本而决策层的人会进一步考虑这个功能未来会不会扩展、当前阶段是否值得投入、有没有更轻量的替代方案。这三种思考方式的差距就是技能层级的差距。层级核心特征典型表现提升方式信息层知道概念能说出名词和定义阅读、听课操作层能动手做有参考能完成重复练习原理层理解为什么能解释权衡和取舍追问、复盘决策层判断用什么模糊场景下能决策真实项目磨练3. 实际项目中真正拉开差距的几个技能点3.1 把模糊需求拆成可执行任务的能力这是我在带新人的时候最看重的一点。很多人拿到一个需求第一反应是“这个怎么做”然后就开始想技术方案。但更有经验的人会先问这个需求要解决什么问题用户是谁核心场景是什么边界在哪里哪些是必须做的哪些是可以砍的这个拆解过程本身就是一项核心技能。它要求你既能站在用户角度理解问题又能站在实现角度评估成本还要能在两者之间找到平衡。我见过太多项目技术方案做得很漂亮但做出来的东西没人用根因就是需求拆解阶段出了问题。具体怎么练我的建议是每次拿到需求先别急着想怎么做而是用一句话把需求重新写一遍然后列出三个必须满足的条件和三个可以妥协的点。如果你写不出来说明你还没理解清楚这时候去问、去确认比闷头做要高效得多。3.2 预估工作量和风险的能力预估这件事新手和老手的差距非常明显。新手往往只考虑“顺利情况下的时间”忽略调试、联调、返工、沟通这些隐性成本。老手则会留出缓冲并且能识别出哪些环节风险最高。我自己的习惯是把任务拆到半天以内的粒度然后对每个子任务做三档预估——乐观、正常、悲观。最后取正常值加总再整体加20%的缓冲。如果某个子任务的悲观值和乐观值差距超过三倍那它就是高风险项需要提前想办法降低不确定性。这个习惯看起来简单但坚持下来能大幅提升预估准确率。更重要的是它逼着你去识别风险而不是等到出问题了才手忙脚乱。3.3 清晰表达和同步信息的能力这项技能经常被低估。很多人觉得“我把活干好就行了”但实际上在团队协作中表达和同步的成本往往比干活本身还高。一个表达不清的会议可能浪费五个人各一小时一份写得含糊的文档可能让下游的人反复来问。清晰表达的核心是换位思考。你在写文档、发消息、开会的时候要时刻想着对方需要知道什么、已经知道什么、可能误解什么。我自己的做法是重要的信息至少用两种方式表达——文字加图示或者口头加书面确认。这样能大幅降低理解偏差。3.4 持续学习和快速上手新东西的能力这一条听起来很虚但实际项目中非常具体。技术栈在变工具在变需求也在变没有人能靠一套技能吃一辈子。真正拉开差距的不是你现在会什么而是你学新东西的速度。快速上手的关键是建立知识框架。面对一个新领域先花时间搞清楚它的整体结构、核心概念、常见模式然后再深入细节。这比一上来就抠细节要高效得多。我通常会用“三遍法”第一遍快速浏览建立全局印象第二遍重点突破搞懂核心机制第三遍动手实践在做的过程中补细节。4. 一套可落地的技能提升方法4.1 建立个人技能清单第一步是把自己现有的技能梳理清楚。不要笼统地写“会编程”“会设计”而是具体到能做什么、做到什么程度。比如“能用某语言独立完成一个包含增删改查的接口服务”“能独立完成一个页面的布局和交互”“能组织一次十人以内的需求评审”。梳理的时候按前面说的四个层级来标注哪些是信息层只知道概念哪些是操作层能照着做哪些是原理层能解释为什么哪些是决策层能判断用什么。这样你就能清楚地看到自己的技能分布知道哪些地方需要补。4.2 针对薄弱环节做刻意练习技能提升的关键不是“多学”而是“有针对性地练”。如果你发现自己大部分技能都停留在操作层那就需要刻意去追问原理。具体做法是每完成一个任务写一段复盘回答三个问题——做了什么、为什么这么做、如果重来会怎么改。如果你发现自己原理层的东西不少但决策层很弱那就需要主动去承担更模糊、更复杂的任务。哪怕一开始做得不好也比一直做熟悉的事情强。决策能力只能在决策中练出来。4.3 用输出倒逼输入这是我个人觉得最有效的方法。当你尝试把学到的东西讲给别人听、写成文档、做成分享的时候你会发现自己以为懂的地方其实没懂。这种“输出倒逼输入”的机制能帮你快速发现知识盲区。具体形式可以灵活写技术笔记、做内部分享、在社区回答问题、甚至只是给同事讲一遍。关键是用自己的话重新组织而不是照搬原文。这个过程本身就是深度加工能大幅提升留存率。4.4 找反馈和对照自己练容易陷入盲区所以需要外部反馈。找比你更有经验的人看你的产出请他指出问题或者找同水平的人互相 review在讨论中发现彼此的不足。反馈越具体越好不要问“你觉得怎么样”而是问“这个方案在什么情况下会出问题”“如果让你改你会先改哪里”。5. 常见问题和避坑指南5.1 学了很多但用不出来怎么办这是最常见的问题。根因通常是学的时候只停留在信息层没有动手做也没有追问原理。解决办法很简单——以用代学。找一个真实的小项目哪怕很简单从头到尾做一遍。做的过程中遇到问题就去查、去问、去试。做完之后复盘把关键决策点记下来。这样一轮下来比看十篇文章都管用。5.2 不知道自己该学什么怎么办先别急着学新东西先把手头的事情做到极致。你现在做的任务有没有更高效的解法有没有你没注意到的风险有没有可以自动化的部分把这些想清楚你就知道自己该学什么了。技能提升不是漫无目的地收集知识而是围绕当前问题做针对性补强。5.3 感觉进步很慢怎么办进步慢通常有两个原因一是练得不够二是练的方式不对。如果是前者增加练习量如果是后者检查自己是不是一直在做已经会的事情。真正的进步发生在“稍微超出当前能力”的区域太简单或太难都不行。找到那个边界然后反复练。5.4 怎么判断自己到了什么水平一个简单的判断标准能不能独立负责一个完整的事情并对结果负责。如果你需要别人告诉你每一步怎么做那你还在操作层如果你能自己拆解任务、设计方案、预估风险、推进落地那你已经到了原理层和决策层之间。再往上就是能在模糊和不确定中做出判断并带着别人一起把事情做成。常见问题根因解决方向学了很多用不出来停留在信息层以用代学做完整项目不知道学什么脱离实际问题从当前任务中找缺口进步慢练习方式不对在能力边缘刻意练习不清楚自己水平缺乏评估标准看能否独立负责完整事情6. 我个人的一些实操体会带过不少新人之后我发现一个规律那些成长快的人往往不是最聪明的而是最愿意动手、最愿意复盘、最愿意问为什么的。他们可能一开始基础一般但每做一件事都能吸收到东西半年下来就能明显看出差距。另一个体会是技能提升不是线性的。有时候你感觉卡住了怎么练都没进步这时候别急可能是到了平台期。换个角度、换个项目、或者干脆休息几天回来之后往往会有突破。我自己的经验是每次觉得“怎么都做不好”的时候过一段时间回头看其实已经比之前强了不少只是当时身在其中感觉不到。还有一点很重要别把技能当成标签。会什么不重要能用它解决什么问题才重要。我见过简历上写满各种技术名词的人实际做事一塌糊涂也见过简历很朴素但什么问题都能搞定的人。前者是在收集标签后者是在积累能力。这两条路越往后差距越大。最后分享一个我一直在用的小方法每个月花半小时写下这个月做的最有挑战的一件事然后回答三个问题——当时是怎么想的、结果怎么样、如果重来会怎么改。不用写很长几百字就行。坚持一年下来你会对自己有非常清晰的认识也会知道下一步该往哪走。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
