俊哥V-CSDN博客

原创 [思考记录]认知和思考

所以，如果不去结合应用方式和使用场景的思考、不随发展变化重新审视，会很难相对把一个技术用到极致，或做出高品质的产品。即便一个人拥有很好的认知和思考能力，如果不善于表达，那么其的想法就如同被禁锢在密闭的盒子里，难以传递并影响他人。但又不得不承认，那个阶段我们对此的认识和重视程度不够，思考也相对浅显，多数时候可能止于想过，达不到思考清楚并建立有效认知的程度。认知的高度和思考的深度，并没有绝对的上限，是一个持续不断的过程，需要不断去实践、积累、更新并提升。3.认知的高度、思考的深度，是一个持续不断的过程。

2025-01-20 19:06:46 482

原创 [备忘.产品实践]规范落地&配套的有效检查机制

还有就是，如果没有及时更新基础库的版本，也会导致已解决的Bug没有在产品的新版本上生效。这类问题，算是影响产品最终质量的一个因素，并且还会带来一些低价值的服务技术资源消耗（之前对打印问题的梳理中，就有这么一类原因导致的）。按照这个思路，和C一起做了初步的整理，主要的对接规范应该还是能找到自动检测方法。比如，基础系统中加强对于参数合规性的检测，在运行期通过报错或适宜的警告输出，让问题更容易在测试阶段发现。1、对接示例和要求，是“正向”去描述的要怎么做，但没有“反向”描述如何去做检查校验。

2025-01-13 14:32:04 260

原创 [备忘.OFD]OFD是什么、OFD与PDF格式文件的互转换

OFD是一种开放的固定版式文档格式，主要用于电子文档的存储和交换，特别适用于需要保持版式不变的文件，如电子发票、电子文档、电子图书等‌。它吸收了PDF的大部分优点，覆盖了布局文件的核心内容，同时抛弃了冗余复杂的特点，是我国电子文件自主布局的重要技术‌。

2025-01-06 17:46:27 871

原创 [备忘.产品]从打印问题的分析，去看程序设计上应考虑的一些方面

这样，能将技术支持人员的问题排查思路、工具和最佳实践封装起来，直接提供给用户和支持团队，从而提高问题的解决效率。比如，对于打印机和驱动的检测适配，单从程序上可能不太好解决，但通过《各种常见打印机的典型问题清单》也可以应对。这类提示，通常不是简单弹出给操作员看。最近继续对打印问题进行梳理，从程序实现角度整理了可能存在的异常状况，和导致这些状况的可能原因。明确的错误原因：当发生错误时，提供具体的错误信息，帮助用户理解问题所在，并给出可能的原因。但也要警惕，自动规则的严谨性和可靠性，否则还会带来新的问题。

2025-01-06 14:35:24 747

原创 [思考记录]潜在事项 | 功夫，在功夫之外

2、对打印过程链路的整理。由于打印过程的链路环节较多、涉及的影响因素也多，加上我们之前在程序实现上做得不足，导致在实际应用过程中，可能出现因打印类问题对实施资源消耗较多的情况。因此，这次梳理的目的是基于梳理结果对程序进行改进、提供辅助功能等，以减少问题发生、降低处理问题的资源消耗。这些好像都不直接作用于邮箱功能的日常使用，但很可能在后续正式应用中，对稳定运行起到重要的作用。比如汽车——汽车最基本的功能是运输和载人，但我们在选购或评价汽车时，似乎更多会从安全性、舒适性、操控性、外观，设置维保等方面去做考量。

2024-12-31 09:37:24 154

原创 [思考记录]重复犯错，快思考&慢思考

做决定时，我们往往会依赖于“快思考”。但由于缺乏深入的分析和验证，这个判断可能并不准确，甚至可能让我们重蹈过去的覆辙。慢思考，要求我们克制冲动，收集更多信息，运用逻辑和理性进行深入分析，以弥补快思考的不足。在昨天的分享交流中，卿老师提到了一个现象：有时在反思复盘后，会发现自己又犯了之前同样的问题。所以，在面对复杂问题时，理想的状态可能就是有意识去在快思考与慢思考之间切换——快思考为我们提供初步的直觉和判断，而慢思考则要求我们收集更多信息，并对这些判断进行深入的分析和验证，从而帮助做出更接近正确的判断。

2024-12-24 14:13:24 193

原创 [工具]GitHub Copilot 直接提供免费额度了

GitHub Copilot 直接提供免费额度——每个月享 2000个代码提示完成额度（每个工作日大约80个），以及 50个聊天请求。后台是访问 GPT-4o 和 Claude 3.5 Sonnet 模型。插件支持VS Code、VS 2022、JetBrains、...这下 Cursor 都不用买，就可以使唤编程小助手了。

2024-12-19 19:55:18 1130

原创 [思考记录]“老技术”也在变化

在技术领域，变化是常态。就像邮箱通讯录的解决方案一样，随着技术的发展和应用场景的变化（如移动设备的普及和多设备间同步需求），CardDAV作为一种更为开放和灵活的标准应运而生（2011年），并逐步取代了老的标准。这也从侧面提醒我们，需要保持学习的态度，不断关注行业动态和技术发展，以便及时掌握最新的技术和解决方案。尤其是，随着AI技术逐步渗透到各个领域，我们更需要保持开放心态，不断更新认知，以适应新的变化。但在了解该方案的原理后，产生了两点疑问：一是，安全性方面可能存在隐患，因为直接暴露了一个关键服务；

2024-12-12 11:54:09 145

原创 [思考记录.AI编程]对.AI.编程.的看法-202412

后续大概是因为，这样生成的网页体积很大（上传慢、浏览打开慢），以及不知道怎么做一些炫酷的动态效果，就改为直接去扒喜欢的网站，然后魔改成自己的想要的效果。对于编程，我的一个直观感觉，它是一种“翻译”的过程——将我们的想法，翻译成机器能够理解和执行的过程。>>编程语言数据指：语法结构（关键字、标识符、运算符、语句结构等）、语义信息（变量的声明和使用、函数的定义和调用、类型的声明和转换等）、编程代码对应的注释及文档等（包括编程范式和最佳实践）、跨语言映射关系。3、技术的发展，使得生成质量得到了极其大的提升。

2024-12-03 18:45:00 306

原创 [思考记录]技术思维&产品思维

3、技术这条路上，即便拥有再好的过往履历和壁垒，如果在创新上停滞不前，也可能面临倾覆的风险。时代在变，技术在更替，更需要我们以发展和动态的眼光去看待事务、并审视已经存在的东西。在模块化思维下，各模块可能更关注自身功能的强大，而忽视了整体解决方案的完整性及易用性。而新兴项目则更像是做产品，从整体视角去看待问题，除了技术外，更注重产品应该做成什么样、如何融合新技术和资源来提供良好的用户体验。1、灵活搭配虽然提供了更多选择，但对于大多数使用者来说，我们可能只是需要一套常用的邮件服务方案，而非自行搭配各种模块。

2024-11-29 13:54:31 315

原创 [反思记录]直觉，还是应更相信原理

因为邮件服务的核心职责是邮件的传输、路由和存储，而邮箱地址的显示名通常都是邮件客户端处理的——发件人的显示名是来自配置邮箱账号时填写的昵称/帐号名（不同邮件客户端的叫法不同），而收件人的显示名是来自邮件客户端的通讯簿或历史记录等。可就是感觉不太对——这么简单的功能，为什么不直接提供成配置，而需要通过正则表达式等方式匹配替换邮件内容中的发件人信息？这样的处理方式会做额外的查询，加上替换处理，不是无谓的开销么？就这个例子，算是从原理上推断，发现了疑问，避免掉走更多的弯路。有时做事还是应多想，别懒 *_*

2024-11-20 14:43:55 168

原创 [备忘.邮件知识]Mailing List（邮件列表）、Group（组）、Public Shared Mailboxes（公共共享邮箱）

邮件列表是互联网上的一种重要工具，用于各种群体之间的信息交流和信息发布。它允许用户向一个特定的地址发送邮件，该邮件会自动转发给列表中的所有订户。

2024-11-19 18:18:19 522

原创 [反思记录]在这次技术验证中踩的坑：理想化、AI误用、...

因为要参考的资料都是大篇英文，所以偷懒直接问AI，跟着AI给出的步骤来无脑操作。这次验证的算是个老牌项目，功能单一，主打性能和稳定性，更多的功能扩展要配合其他开源项目或插件来实现。所以过程中，配置和联调是比较耗精力和时间的，特别是在对相应知识不熟悉的情况下，就更需要耐心和一点点运气了。回头看，整个过程中并没有遇到明显的技术难题或资料缺失，主要是需要补充一些相关知识，然后就是操作上确实还是略繁琐。后来查了下，还真有，并且人气较高的还是国人的一个项目（提供了封装打包，但功能更完善和简单的版本则需付费）。

2024-11-14 14:22:57 288

原创 [思考记录]思维局限，以为懂了

以资源体系的设计为例，那时自认为已经“懂了”，对相关的概念、作用关系、组成及实现等都有一定的了解，算是“合上书都能回答”的程度。比如，对派生关系的设计、插件操作的定义，以及它与资源操作之间的异同等，这些都是当时没去考虑和思考的。这些方式，其实可以帮助去深入理解和看清问题，有助于跳出原有的思维局限，进行更为深入和全面的思考。回想当时自己在做这块的时候，思考大多停留在“了解并认可”这一层，一旦初步理解并认同了“合理性”，就很少再去深入深究（较少去进一步去思考为什么，极少去做反向思考和做本质探究、模型抽象等）。

2024-11-05 14:11:18 147

原创 [思考记录]做事别忘最初目的

这次重新来找转换工具的时候，突然意识自己的关注点已经偏离了最初的需求——我只是要查找邮件内容，但却一直将思路和精力放到了将.ost转换为.pst文件这个实现手段上。3、尝试思考问题本源在解决问题之前，去探究问题的本源和背景信息，有助于打开思路并发现更多解决问题的可能性，也有助于判断解决方案的可行性和有效性。就像ost/pst文件，其实MS公开了其存储格式的定义，并且知道是没有做特别加密处理的，由此可以推断出能够查看内容应该是不难的，那么存在现成开源项目的可能性也很高。

2024-10-28 16:00:17 123

原创 [思考记录]技术，是真的了解么？

但这次重新再看的时候，发现自己在一些基本概念上的认知可能是存在偏差的，对某些概念的理解也并不清晰。比如，会将“FTP”与“FTP服务器”混淆，并没有将它们弄明白，想和用的时候都是模糊的。现在看来，自己所谓的“了解”，可能只是基于会使用这项技术，以及它确实比较常见，因“熟悉”而产生的错觉。3、有必要加强对技术适用性的考量一项技术即使被广泛采用，也并不意味着它就是最好的选择。要想做好产品或做出好的功能，有必要去了解技术的原理，明确我们的应用场景，然后通过分析比较找到更适合我们的技术路线。

2024-10-24 15:11:35 154

原创 [记录]积极面对

反而，如果我们能与用户保持透明和坦诚、能快速采取措施来解决问题、能去积极改进提升品质，相信这份态度对方是能感受到的。所以更应该以积极正向的态度和实际行动来争取用户对我们的信任，而不是一味的担忧害怕。经过分析，基本明确是几个特殊因素叠加导致了这个现象，而其中一个关键因素就是我们产品的程序上存在一处逻辑漏洞。交流该问题时，X透露出一个担忧——产品正式版推出后，我们一直拍着胸脯给大家宣传，咱的系统挂了都不会影响到业务系统正常运行，但实际却又发生了这次意外。而一旦发生了，用户对我们产品可靠性的信心可能一下就没了。

2024-10-01 09:37:00 188

原创 [思考记录]心存敬畏，别太随意

复杂问题通常涉及的因素比较多，解决的方式也多样，需要经过深入思考和分析才能更好地去理解并找到更适合的方案。如果只是简单找到一种方案就动手，很可能只是看到表面或局部的问题，而忽略了潜在的风险和挑战，影响最终效果。或者基于方案进行推敲，审视每个环节并思考其背后的逻辑和假设、可能存在的问题和限制，从而帮助发现方案中的潜在问题或不足，进而做出改进和优化。所以，需要去把握度的问题。毕竟多思考再动手是有诸多好处的，除了有助于提高解决问题的效果及效率，也能帮助去训练思维和打开视野，为后续做近似的事情累积形成“经验”。

2024-09-23 12:56:44 199

原创 [备忘]测算.net中对象所占用的内存

但对复杂对象是不好用的。因为该方法只方法适用于测量简单的值类型和结构体类型的大小。对于引用类型的对象，它只会返回指针的大小。需要递归遍历对象的属性，并累加大小‌。比如：二进制序列化、Json序列化等。以下是二进制序列化的示例代码（值得提一下的是，出于安全考虑MS已经在.NET 9.0废弃了。.net 基础库中应该是没有直接提供计算某个对象所占内存的方法。示意代码如下（AI生成），完全实现其实会更复杂一些。《使用 .NET 对象分配工具分析内存使用情况》第2、3种方法可能更多是定量估算，视需要使用吧。

2024-09-20 14:29:09 605

原创 [思考记录]关于“不同的意见”

人会犯错是在所难免的，相较于陷入所谓的羞耻感或被否认的负面心态，更加积极地去修正和改进才能不断成长和进步，把事情做得更好。减少无谓的“情绪”和争论，而更能瞄定要解决的问题，会更加专注于解决和最终的效果。产生这个变化，可能是源于自己认可的一些观点，这些观念逐渐渗透并影响着我自身的思维方式和行为方式。3、每个人的思维方式和经验背景都各不相同，他人的意见往往能够为自己提供新的视角和思路。2、形成自己的思想，对他人的观点辨别要有识别。1、有效的沟通是为了促进问题的解决与目标的达成，而非为了争个输赢、分个高下。

2024-09-17 17:54:18 305

原创 [思考记录]#保持平常心#合作#

在推进事情的时候，其实内心有那么些“完美主义”，不想犯错——希望一开始就找到最佳方案，推出功能后就能立竿见影。所以，保持一颗平常心，循序渐进地推进工作，勇于尝试、敢于犯错，并从中不断学习和积累经验。但在实践中学会向他人求助，利用团队的资源，能够更快地找到问题的解决方案，推动事情向前发展。正如前一点提到的“术业有专攻，互补共赢”，也是强调的相互协作能够实现共赢。1、术业有专攻，互补共赢。每个人都有自己的长处和短处，面对自己不擅长或感到困难的问题时，最明智的做法是寻求那些在此方面擅长的人来帮助解决。

2024-09-13 14:57:53 166

原创 [思考记录]化繁为简

很多时候，相比一步到位的“完美”，采用循序渐进来一步步迈向“正确”可能是更为经济和有效的办法。毕竟前者对能力的要求和代价的投入，很可能是几何级数式的差距，不是我们能去轻易做到的。所以先定义适合的边界范围，得到当前切实可到达的目标，这也有助于逐步去接近“正解”。所以这个时候要去注意区分，哪些是满足功能需求的必要部分，哪些是技术实现上的细节，进而“简化”得到要验证的最关键、最基本的功能。当然，随着项目的推进，技术细节也将变得尤为重要，它们也是保障功能最终可用性的关键。这也是对“化繁为简”的运用。

2024-09-03 14:18:18 181

原创 [思考记录]严谨、讲因果

上周清理罗列了一些程序上的问题，后续又进一步对其中的每一项再次进行了推敲整理。通过整理，帮助逐步还原了某些问题的“真面目”，也让思路更为清晰了。不只去看到每种方式的优势，更要反向去看到会引入的问题，并且尽可能找出相关因素并整理考量。因为办法通常不止一种，虽然当时的选择会导致现在看到的问题，但并不意味着没有其他更为有效的解决途径。对清单中所列的问题，过于依赖表象现象，缺乏因果分析和质疑精神，导致把一些表象相关的东西当成了事实。在开始整理前，没有先充分理解每个问题，使得后续的工作建立在不稳定的基础上。

2024-08-26 09:03:04 220

原创 [备忘.经验总结]目的明确但目标不明确的事如何做？利用AI获取前人的智慧和经验

目的明确但目标不明确”的情况在日常生活中和工作中都可能出现，它意味着虽然我们明确了最终想要达成的愿景或方向（即目的），但在如何量化成功、规划具体步骤以达成这一愿景（即目标）上却显得模糊不清。为每个细化后的目标设定详细的执行计划，包括任务清单、责任分配、时间节点及所需资源，确保计划的可执行性与灵活性。对于不再适用或难以达成的目标，果断进行调整，保持策略的灵活性与适应性，确保始终朝着既定目的稳步前行。2.细化目的尝试将大目的分解成更小、更具体的部分，这样有助于更清楚地看到实现目的的不同路径。

2024-08-19 09:19:03 208

原创 [备忘.经验总结]一个补丁包的“迭代”——向着“低风险、易操作”前进

历经四次实际项目中的升级实践（观察升级的整个过程），结合实操人的意见反馈和对升级效果的观察回顾，我们陆续对程序做了相应完善并对两份文档“升级检查表”和“升级详细步骤”做了精简和优化，基本达成了我们的预期。固化的操作，能让程序自动做的，少让人来处理。实现代价不高的情况下，这样能让操作简单，也能避免错漏。通过直接观察真实的升级过程，不仅验证了补丁包的实际效果，还发现了潜在问题，这比“纸上谈兵”要更直接和有效。比如，采用服务控制台方式来操作，这样可以消除学习成本，同时也减少因操作不熟悉而导致的错误。

2024-08-12 15:26:20 209

原创 [备忘]VS2022 打开.net fx4的项目

3.将子目录 \1.0.3\build\.NETFramework\v4.0 复制到 C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework 目录下。因为VS2022最低支持.NET Framework 4.8，‌而4.8以下版本的项目（如.NET Framework 4.0、‌4.5等），‌由于版本过低而无法被VS2022直接打开。（也可以直接下载 .nupkg 包，将其扩展名改为.zip，‌然后解压）

2024-08-05 15:13:13 448

原创 [笔记.AI]AI Agent理解（LLM & AI Agent）

AI Agent是指一种自主系统，能够感知环境并采取行动以实现特定目标。AI Agents通常具有一定的智能，能够进行决策、学习和适应环境变化。它们可以在各种应用场景中发挥作用，如自动驾驶、智能家居控制、虚拟助手等。

2024-07-14 11:00:00 717

原创 [备忘.AI]AI Agent

AI Agent 拥有记忆，能够去做规划（具体包括了：根据记忆的经验、行动规划、迭代改进），并利用所具备的工具行动。从而能够自主完成给定的目标。查了下来源，原始图应该是源自 Lilian Weng 的博客文章。备注：因为最初看到收录这个图片的文章不是一手信息，所以专门又。另一个图（来源未知），加上了感知（多模态?看看这个过程，是有点像我们人类的行为模式。

2024-07-08 15:04:29 373

原创 [思考记录.产品改进]假如异常日志可以自动上报

然而要想做到这些，还是有不少挑战。其中一个要点则是日志的内容——除了通常的程序执行或命令调用的报错信息，更有意义的应该还是针对性的一些内容。比如，运行过程中的重启及重新安装等非常规操作、特定接口调用的错误及超时等异常状况、发生频率超出正常范围的重连及出错、结合业务特点的一些情况等。因为反馈问题往往在发生之后，如果在这个时候能快速方便地拿到有用信息是件很舒服的事情，而在获取日志这块，我们目前的体验应该是不太好的。这种方式相对于主动分析优化去提升程序的稳定性而言，应该是相辅相成的，属于目的一致的两种方法。

2024-07-01 15:22:57 170

原创 [思考记录]未来已近 - AI带来的变化，以及简单思考

不由地感叹，（略夸张点的说法）这AI大模型估计比写文字的人都更能理解所写的内容。而现在，OpenAI用“大力出奇迹”的方式训练大语言模型，取得了大家都看得见的“巨大突破”，并且还在快速演进。3、对未来，想象不出来，跟着时代走着吧。假如AI替代了大部分的工作，来满足我们生存和生活的需要，那时我们的日常又会是怎么样的呢？1、利用AI的能力：积极尝试、会提问（让AI准确理解你的意图）、想象力（发现场景并将AI与之相结合）、......而想要拥有良好的鉴别能力，除了知识面，思考和思维方式应该都是很重要的因素；

2024-06-18 14:16:24 316

原创 [备忘.经验总结]没有一劳永逸的完美方案 —— “银弹”？那是没有的

最近在考虑某客户端程序支持灰度升级的事。最开始其实有一股冲动想要实现出来早点发挥作用，但经过梳理后，逐步意识到其可能带来的实际效果并不如最初设想的那么大，同时还会带来一些新的问题要去面对和解决。整理回顾这个事情，有两个要点可以记录：1、完美方案并不存在。正如涛哥例会上常提到的，事物都有其两面性，我们往往要在利弊之间做出权衡和选择。2、做事情别忘记初衷，不是盲目追求某种方案。我们不是要去做“灰度升级”本身，而是要解决我们所面临的问题。并且灰度升级也只是解决问题的一个可能选择而已。

2024-06-05 14:17:58 183

原创 [备忘.经验总结]特例问题&通用问题，分而治之

问题尽可能去弄清原因，避免盲目处理。比如这次如果不回顾，可能会把特例问题当成通用问题来处理，至少会让我们程序更复杂，违背了简单原则。特例&通用问题分别去采用不同的方式处理，有哪些好处？1)减少副作用和不必要的改动，成本风险也会相对更低。2)针对性更强、具有更高的灵活性。可以根据实际情况进行调整

2024-05-27 14:09:26 183

原创 [反思.产品问题]保持严谨

在新版本的网页组件中，我们对打印命令增加了打印机状态的检测能力，遇到脱机、缺纸及缺墨等异常状况会给出提示并取消本次打印。试用过程中，小伙伴反馈了一个程序“误判”——当打印机“墨粉不足”时，短时间内其实还能打印出看上去比较清晰的内容，但我们的程序却直接禁止打印。我们采用的是严格策略，一旦检测到状态不符合就禁止打印。我们对个别状态的含义其实是存在误解的，但过程中我们并没有对各种已知状态的含义做充分的理解和验证。这也在提醒，想要做出好的效果，在过程中应先保持严谨的态度，然后是求精的精神以及持续的改进和优化。

2024-05-20 10:43:47 177

原创 [思考记录]问题也是发现和改进自身的契机

遇到问题除了解决，也有必要去进一步思考背后存在的问题。比如这次产品升级后被迫回退，虽然遇到的问题给我们带来了一些曲折和困扰，但也为我们提供了一个宝贵的契机，让我们从中发现了自身工作中存在的问题和可改进的方向。所以别轻易放过，珍惜和善待。

2024-05-13 14:40:48 188

原创 [反思]不轻易下判断

提醒自己——面对问题时应保持谨慎的态度，不要轻易下判断。只有经过充分的思考和分析，我们才能做出更为准确和合理的判断和决策。经验虽然可以提供一定的参考，但并不能忽略当前的变化而盲目应用或简单照搬。对问题只做初步理解，没有进行信息梳理和分析推演，很容易忽略掉重要细节和问题，从而导致判断偏差。

2024-04-28 14:11:59 222

原创 [备忘.打印设置问题]A5纸张打印问题（同一台打印机上 A4 和 A5）

1、我们有个文档打印程序，当涉及到既要打印 A4 又要打印 A5 时，A5 的内容打印效果不符合预期（只打印了部分内容出来）；>>猜测是让打印机判断是否要对打印内容做"旋转"——要打印的内容方向与进纸如果是一致的则直接打印输出，否则要做旋转。2、该打印机只有一个纸盒，人工根据要打印的文档格式来放合适的纸（A4固定纵向放纸，A5固定横向放纸）；3、“打印命令参数”的纸张和方向应与内容一致（内容是纵就“纵向”，内容是横就“横向”）；2、操作系统的打印机设置：“A5 + 长边进纸” or “自定义A5横”；

2024-04-25 19:16:52 1235

Visual Basic 6 Client Websocket Control 1.11 BETA

空空如也