文章主要讨论了LLM（大型语言模型）在集成开发环境（IDE）中的应用，以及这种应用如何改变软件开发的方式。文章的核心要点包括：

1. IDE是开发者的超级入口，LLM为IDE的商业化带来新机遇。LLM能够提供更具差异化的用户体验，使得非技术背景的用户也能够更好地进行程序编写。

2. IDE是探索LLM复杂推理能力的最好场景。LLM的能力边界逐步从代码补全渗透到代码重构、测试、Debug和分析等高价值环节。

3. 软件开发将迎来“Excel时刻”，而IDE则是巨变的关键入口。LLM将使得各行业的非技术人群能为自己的工作编写小程序，调用LLM功能、Code Agents就像在Excel里使用公式一样简单。

4. 轻量程序的开发流程再革新，对需求描述和测试的AI Agents市场将涌现，而IDE有望成为Agents的分发平台。

对于普通程序员来说，这些变化带来了许多启示和机会：

1. 提升技能：理解并掌握LLM的使用，将有助于提升编程效率，也是未来编程的重要技能。

2. 创新机会：LLM在IDE中的应用还处于初级阶段，有很多创新的可能性。程序员可以尝试开发新的LLM-based服务、Code Agents等，提供更个性化、更高效的编程工具。

3. 数据安全和合规性：随着LLM的广泛应用，数据安全和合规性问题日益突出。程序员需要对此有深入理解，以便在开发过程中避免相关问题。

4. 新的就业机会：随着LLM在IDE中的应用，将会出现新的就业机会，如LLM模型的训练、优化，以及基于LLM的软件开发等。

5. 提高编程效率：LLM的应用可以大大提高编程效率，减少编程过程中的重复劳动，使程序员可以更多地关注创新和解决复杂问题。

看主体代码，主流程，折叠没有用的代码，忽略注释

转换一个思维，而不是选择一个工具。 分享一个思维，而不是分享一个工具。

主动 own 事情。

主动推动事情发展 把握 + 影响 + 方向，不只是被动接受

多写文档，记录工作细节。

今天收到一个同事的询问，是一个已经交接出去的工作的细节。如果要解答，必须翻遍整个系统的代码。但是之前做这个工作的时候，已经梳理过一次了。便找了下文档，发现当时记录过，几篇文档的内容闭环了，刚好可以解答该同事的疑问，节省了很多时间。

即使是自己亲手完成的工作，过了一年半载后也基本会忘干净。 对于每一项工作，要有一个类似「One Page」的文档。从该文档出发，可以把所有关联的散落文档都串联起来。 工作文档格式不限。但除了「背景、方案、任务分解」，我建议包含以下内容： 所有的 Merge Request 链接汇总 方案讨论历史记录与对比，放在附录里 监控大盘链接、或者常用的 metrics 链接 涉及到的云平台链接、或者配置项名称、或者配置参数取值与说明 踩过的坑、梳理出来的一些细节

一个一个问题来解决 1，销售额下滑，看下这个品牌不行了，还是别的原因，如果是品牌不行，那换？或者弄一些营销手段。如果是别的原因，比如比淘宝零售价高，那就想办法解决别的问题； 2，比淘宝零售价高，看下总部给货价钱的原因，还是淘宝搞活动，自己是不是也搞活动之类的； 3，士气低落，想办法提高士气，比如增加提成之类的

感觉上面说的也是很肤浅的想法，让我问下gpt，看他怎么说

1. 写好质量高的内容：写出引人入胜、有价值的内容是吸引读者的首要条件。写出让人们感兴趣的主题，采用吸引眼球的标题，以及掌握关键词优化技巧是至关重要的。

2. 增加阅读次数：分享博客内容到不同的渠道可以帮助获得更多的阅读量。这包括在社交媒体平台上分享、通过搜索引擎优化、以及在其他博客中留下评论等。

3. 长期持续性：博客需要长期坚持，即使没有收入或回报，也需要坚持积累自己的读者群体。

4. 多元化内容：除了文章以外，可以尝试添加图片、视频、音频和其他多媒体元素来丰富博客内容。这样可以吸引更广泛的受众，并有望获得更高的转化率。

5. 建立社群：建立自己的社群，以建立与读者之间的联系和互动，通过留言框，邮件列表、社交媒体等来建立联系。

6. 成为专家：成为该领域的专家，创造出的内容将更具有影响力，并有助于在网络上建立自己的品牌。

这句话的意思是，有时候避免麻烦、避免冲突、避免得罪他人等，比直接面对并解决问题更聪明。有时候，我们需要权衡得失，然后选择回避一些不必要的争斗，以避免可能的麻烦、危险和失败。这种回避可能表示对自己和他人都更具智慧的决策。

youtube上面内容质量蛮高，还可以锻炼英语

任务分解

不必读的书类

那么作为一名工程师，或者技术管理者，如何去利用有限的时间去培养这些思维和能力呢？

一是定目标的时候都尽可能量化。不要只是想着要 improve，enable，想想你具体 improve 了多少，enable 了什么。

二是动手搭一些简单的 dashboards去追踪你的目标指标。这样你就能随时观测你离你的目标有多少，从趋势上知道你做那些事对你的目标有最大的帮助。

三是保持一颗好奇心，看到设定好的数据有任何不是很理所当然的波动或者变化的时候，试着打破沙锅问到底，试试自己能不能去解读这些波动和变化。并且勤于动手去写一些简单的 SQL，知道数据的来龙去脉，知道每个数据的波动，其上游和下游可能受影响的数据还可能有哪些。

另外，如果组里有一名数据分析师或者数据科学家，不要觉得只是各做各的事，尝试着更紧密的合作和沟通，学习一些简单的技巧和思路，加上你对系统的实现有很好的了解，等你能够熟练运用一些简单的数据技能的时候，就会发现对彼此的工作都会有很大的帮助。

最后的结果就是组里不论任何大小决定，都用数据说话，决策过程也变得很透明。

老实说，IBM PC架构(后来的Wintel)如此成功，是因为IBM允许任何人为之开发产品，而不是因为IBM拥有天才的市场营销人员。

开放太重要了

90%以上的小伙伴第一个想到的渠道就是企查查和天眼查。嗯，如果只能想到这里，那么这篇文章就可以结束了。让我们再进一步思考一下，这些网站上的信息又是从哪里获取到的呢？

全国企业信用信息公示系统：http://www.gsxt.gov.cn/index.html 中国裁判文书的官网：http://wenshu.court.gov.cn/ 中国执行信息公开网：http://zxgk.court.gov.cn/

给我印象最深的，是第一次听他在公司做报告的时候引用的 Peter Drucker 的一句话：“If you can’t measure it, you can’t improve it.” 这句话在后来的工作中多次的被印证，而很多时候，及时有效的一个数据分析，可以帮我们找到正确的方向，做改进最省力的办法，以及时刻帮助我们了解项目或者产品的好坏。

首先就是对各种 bug，incident，或者系统漏洞处理的优先级排序。以前我遇到别人报了一个问题，第一反应就是凭直觉去判断这个问题是因为什么，好不好修，怎么修，以及引发的可能性会不会很大。现在每遇到一个问题，第一件事就是去 “measure it”，这个问题影响到的人可能有多少，给公司带来的损失是多少。每个小时每天新的影响有多大等等。每个 bug report 上都有这样的 SQL query 和数据，然后团队就根据切实的数据去决定哪些问题是急事，哪些可以稍微放一放。这样一来团队始终都可以做到把问题控制在最小，而且对于略推后的问题心里也十分有底会有多大的影响。

工具/内存延时测试工具

“对于那些在生活中的角色是在事情的顶部（on top of things）的人来说，电子邮件是一个很好的东西。但对我来说不是；我的角色是在事情的底部（on the bottom of things）。我所做的工作需要长时间的学习和不间断的专注。”

而半个多世纪后，与美国总统相比，我们对于掌控事情的痴迷，只能说有过之无不及。不只是在游泳池边，我们在马桶上，枕头边，甚至课堂上，工作中，通过手机和 app，我们无时不刻都“在事情的顶部。” 我们需要掌控着么多信息吗？俄乌战争、台海危机、谁在推特污蔑诽谤、邻居群里又在团购什么东西。总总这些，耗尽了我们宝贵的精力，却只凭添了我们的烦恼。 有时候我在想，如果没有手机多好，我和现实中的人一定会更亲近，而这才是对于我最珍贵的事情。更别谈我们只有呆在”事情的底部“，心无旁骛，才能学习和创造，才能增加我们的财富 - 我们的能力。

原文：关于学习的85%法则 “如果你总是成功，就很难知道要改进什么。如果你经常失败，你就不会学到什么是有效的。只有当我们拥有成功和失败的混合体时，我们才能在好的和坏的策略之间形成对比。” 当你学习一项技能时，85%的成功率是最佳状态。如果错误太多，你应该降低难度，减缓进度。同样的，如果对你太容易，正确率太高，你应该提高难度，加快进度。