:: Dotnet Fantasy ::

不应被这些技术名词的“花架子”唬住，而应看到背后的思想——理解它们为什么而生、解决什么问题、适用与不适用的场景，或者实现手段有哪些参考。毕竟，从结果来评判解决问题方式的优劣，“用小成本且可靠有效解决”会要比“用了高大上的理念和技术解决”更好。即使不了解这些名词，也不影响我们规划行程。但了解之后，可能会感叹——哦，原来我们之前走了“自由行+局部跟团”的混搭模式。记录提醒——对于解决方案或思路和理念类的技术名词，尤其需要保持警醒，先理解“为什么而生”以及“什么场景用”，而不是想着“怎么用”甚至“必须用”。

昨天听金老师讲解了他初步整理的大模型宏观概念关系图，受益不少。图上不仅是涵盖了诸多概念，更厉害的应该在于把概念之间的关系进行了描述，更直观展现了概念是如何与其他概念相互作用的。帮助从整体的角度去理解，以及透过概念之间的联系去看到各个概念所处的位置、相互影响和作用关系。如果把“概念”比作“个体生物”，那么每个概念就像生态系统中一个独特的物种。而“概念关系图”就像是这些生物共同生活的“生态环境”，在这个生态环境中，生物之间是存在各种联系的。

发现问题->请教AI->形成自己的理解和问题->AI->尝试落地实践。但手欠，去试着问了下AI，发现它的分析总结比我透彻。|-挑战AI的回答：拿到AI的分析后，试着反驳或补充，比如“如果情况变了，这个还成立吗？|-设定独立思考时间：在请教AI前，给自己15-30分钟先想一想，强迫自己尝试解决问题。|-保持独立：先自己思考，再用AI验证和扩展，最后通过实践消化成自己的东西。|-先自己思考，再用AI：确保你有自己的基础，而不是被动接受AI的答案。|-保持批判性：别把AI的回答当“标准答案”，要学会质疑和调整。

停留在“编码者”的工作方式已经属于过去式，而未来或许要转变为“问题解决者”和“创新者”。这就需要将关注点从单一功能的实现中跳出来，比如：去关心和思考产品整体、去理解整个系统的架构、结合业务知识和用户体验等，提出更有价值的解决方案和思路。又或者，基于AI工具思考探索新的工作流程、框架设计，以及其他新的可能性。这样，无疑也会提升个人的价值并带来更大的工作成就感。

尝试用 xAI-Grok 去了解DS开源周的信息，有那么点被Grok的输出惊艳到。“请你以技术编辑的角色，重点参考官方文档，介绍DeepSeek开源周的内容，写一篇技术分享文章。”，得到的文字看起来很是舒服，内容靠谱、结构清晰，并且还没什么“机器味”。不禁想到以前，要写这么一篇相对严谨靠谱的技术文章，还是不容易的，特别是要花不少功夫核对相关信息的准确性、严密性。而现在，借助AI工具，只需要想好主题，甚至都不需要先读原始资料就能搞定。内心中不由再次感慨，技术和时代在变。

AI就从研究背景、技术核心、成果与争议、研究本质等方面进行了整理归纳，并给出最后概括性总结——通过高效利用现有基座模型、精细化数据筛选及动态推理控制技术，探索低成本优化模型的可行性，但未颠覆基础模型训练的高资源依赖特性，并且附上了相应的来源参考。比如借助AI在线搜索，以前可能需要向相关专家了解，或者查阅较多资料来得到的信息，现在则变得相对容易。通用大模型的学识渊博，什么都知道，但它也做不到百分百的正确（多个不同类的通用/专用模型结合各自工具，相互去验证和纠偏，是否是进一步提升结果质量的方式？

目前的DS-R1联网搜索，它本质上是什么呢？        大模型本身的预训练数据中并不包含最新的联网信息，并且大模型并不能直接联网搜索。那么，DeepSeek-R1 的联网版是个什么呢？从当前的理解看，其本质上应该算是一种“搜索智能体”（解决信息搜索场景的 AI Agent）：1.大模型作为“大脑”提供认知能力（如语言理解、策略生成、分析推理）2.搜索智能体通过工具调用（如联网搜索、数据库查询的等）扩大模型的知识边界，以及解决数据滞后问题。结合起来，就实现了时效性更强的智能交互。

以前在使用某些AI大模型时，为了获得相对更好的输出，一种方式是在提示词上下功夫——除了交代任务背景，甚至建议对复杂任务预设处理步骤、提供模板案例等。夸张点说就是，做个功能页面，将所需方法及其主体逻辑都描述出来（近乎去写出伪代码）。这显然还是比较费事（但也有研究说，部分模型仅通过添加"请逐步思考"等引导语也可显著提升输出质量）。而在使用 Deepseek-R1 或 ChatGPT-o 时，似乎并不推荐这样用了。

其核心，其实是从思维上去转变，从“完成任务”转变为去“解决问题”，从传统的“执行者”角色转变为“思考者”和“问题解决者”。年前和队友们一起交流了“认知和思考”的话题。小范围交流后，初步形成一个共识——带着思考做事情。通过这样的方式，习惯于去思考“为什么”、“该怎么”、“这样就对么”等，从而尝试摆脱机械性做事。这，是接下来要去思考和交流的又一个话题。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如何排查问题？1、先审视下问题现象是否明确了。不止是问题的表现，还包括出现的环境和条件等。2、各线索是否都真实可靠？只有确保了“事实”是客观真实的，我们才能避免被误导或走入误区。3、不急于凭感觉尝试各种解决办法，而是先有思路。比如先快速整理出排查问题的关键要素，然后根据线索分析可能的原因和影响因素，再去有目的和有计划地去逐个排查验证。4、质疑的态度。遇到解释不通地方，除了可能是认知不足，也可能是信息有误。5、找找身边的“高手”。遇到卡点和疑惑，找合适的人帮助是条捷径。

这种处理方式其实遵循了“迭代与试错”的模式。这一模式还有很多应用，典型的就有暴力破解密码（用大量已知密码的集合进行穷举试错）、手机万能遥控器App去匹配到要控制的电器设备类型。这种模式的优势就在于，它极大地简化了用户解决问题的过程，不需要使用者对问题有深入的理解或专业知识，只需通过手工简单的尝试（甚至是程序自动做了）就能够获得有效结果。

这个“技术欠账”是指在这个项目的初期，会有意无意偏向快速实现，想先做出来、用起来，进而在实现过程中做出了一些临时的妥协。典型如，原本应该设计成灵活动态的逻辑，我们却先写成了死代码，这无疑牺牲了灵活性和功能的完整性；还有一些本应进行单独判断检查和细化处理的逻辑，选择了暂时搁置或简化，这些其实是对系统的稳定性和功能完整性的破坏。还有就是，当时认为不关键的一些小问题会选择跳过而没有进行更多的思考，这些其实都有可能为未来的隐患。而更为重要的是，我们不能被一时的短期成效所迷惑，而忽视了所欠下的债务。