@Shaozzzzzz 能摸到么？

如果能摸到，充分洗车后，用碱性的喷剂喷一下，然后新毛巾，或者确定干净的毛巾稍微用点力试试。
充分洗车、新毛巾是怕有沙砾磨出划痕。

摸不到，说明污渍时间有点太长，或者不是你说的这种，需要多洗几次车，多晒晒。（说白了就是靠时间）

@azhangbing
@x86
雕虫小技，谬赞了，互相学习

@burnings0506 是指螺丝锈迹淋水导致车牌下面的锈渍，还是车牌螺丝下面的车漆？
如果是锈渍，抛光可能是效果最好的选择。

如果是车牌螺丝下面的车漆，我个人认为是一开始上牌的时候应该就顶穿了，这还挺常见的。

很多情况下，车管所和车企有两套螺丝，部分车的前牌照后牌照的螺丝不一样长。如果用了车管所的螺丝，或者用错了前后螺丝，都容易顶穿漆面。

然后就要看，如果是铝盖 or 塑料前保，可以不管。
如果是钢盖，就要看锈蚀程度，需要咨询 4S 店

因为设计图的元素关系和 UI 代码结构不是一比一对应的。
网页与 native 应用的 UI 代码结构又不一样。

这就导致设计图和代码实现之间的统计学最优解不太明显。

@xxyang 玻璃上的吗？

1 、杜绝使用任何“镀膜”、“镀晶”、“防雨”玻璃水、雨刮器。
2 、换掉雨刮器或者雨刮胶条。
3 、用 soft99 或类似产品去油膜。

油膜水雾以及跳雨刮，本质上就是挡风玻璃的摩擦力、亲水性不一致。

@Lmorning “小辫子”指的是有布条的毛巾。特点是表面积大，所以吸水强，吸水速度快。干毛巾也有很强的吸水性能。（普通的毛巾干了之后会很硬，吸水很慢）

其他的可以看我的历史洗车帖

基于目前的大语言模型的上下文长度限制，目前对于软件工程的架构设计而言，属于一个非常尴尬的地位。

如果彻底向 AI 效率妥协（尽量压缩上下文），那么人对于程序的理解难度会上升，代码可读性会下降。
这会导致人工干预时的判断力与正确率下降。导致无法正确合理的拆解工作，也会增大提供上下文描述的错误概率。

如果向人类可读性妥协，那么会削弱 AI 的视野能力（因为上下文的效率更低）。导致 AI 生成的代码的全局性欠佳。
Agent 模式能一定程度的解决此问题，但不能精确、彻底解决。


至于说分工方式。过去青睐于层级分工，或者说分层开发，是因为人的能力问题（不可能寄希望于一个人同时精通 UI/UX 、前端开发、后端算法、以及数据库访问，乃至库表设计）。

目前的代码结构也是针对此来定义的。也就是“康威定律”所描述的那样。
但我认为，如果 LLM 的上下文能力没有再一次的飞跃的话，距离全面的垂直开发，还有一定的距离。

所以在不了解大模型的基本逻辑的前提下，过分的依赖大模型的输出内容，是非常可怕的。

大语言模型的基本逻辑其实非常简单粗暴，就是根据你的输入，以及他自己的输出，一次一个“token”（你可以理解为单词）的迭代最大概率的续写。
大语言模型不懂任何“真理、定理”。他只是根据训练的语料，加上现有的上下文信息去预测续写而已。

所以他得到的不是“正解”，而是最大概率解。

如果讨论“全程负责 or 流水线作业”的话，服务业其实体验更好的是全程负责制。
因为服务业主打“定制、非标品”，流水线随着信息的传导，损失比例会很大。
楼主应该体会过，同样一个诉求，不同岗位的几个人反复问好几次的经历吧？这就是流水线作业导致信息损失的最简单体现。

至于说是要体验，还是要效率，那是消费者抉择的问题。


如果讨论技术，nginx 和 web 容器完成的是不同的任务，没法比较……

最终效果不能保证一样。
AI Coding 交互涉及到太多的业务处理。

1 、如何拆解问题。
2 、项目代码中的上下文搜罗能力。
3 、调用大模型的成本考虑（如何压缩上下文大小、压缩大模型交互次数）
4 、生成结果的成本控制（如何抉择多输出代码，从而辅助更精准的合并，还是尽量简洁的输出答案，节约输出成本）
5 、代码合并逻辑。

这些跟模型都没有直接关系。

首先，先明确定义。我理解楼主表达的“未来属于 PHP”，是未来的编程语言 PHP 一定站大头。

然后就是问题所在了：楼主的论据并不是论点的充要条件。
总结起来，楼主的论据无非是：PHP 语法稳定、社区友好、没有破坏式更新。但这并不能证明，未来是 PHP 的。
反之，只能说明 PHP 是一个不错的新手语言。仅此而已。

按照楼主的逻辑，统治世界的交通工具应该是带辅助轮的 16 寸童车 or 儿童三轮车 or 平衡车。
统治世界的主食应该是奶粉。
毕竟他们友好、稳定、安全。

那些需要驾照才能驾驶的汽车、火车、飞机、轮船都是邪修。毕竟这些交通工具一点都不“社区友善”，几十年间也经常“breaking change”


新手友好与极致生产力之间，没多少因果逻辑，更多的其实是鱼与熊掌。
更何况，在目前 AI Coding 的时间节点下，楼主的发言更显行为艺术。

复杂的角度不同。

业务系统的复杂，是庞大的数据抽象与合理的业务流程梳理。
游戏系统的复杂，在于其低延时，高稳定的要求。

所以游戏往往偏向于小儿精的软件技术团队（占比更多的是游戏内容从业者）。

不太懂这个“AI-led espionage campaign”的概念是什么。
难道是：Q：F22 的隐形涂料的原料配比是多少？ A：保密

先说弄 NAS 是要实现什么功能，然后才能有效的推荐。

所以你确实记住了吗？

1 、“最佳实践”是有场景的。一个设计，只有在这个场景内是“最佳实践”。举个简单的例子，现在给你一份抖音源代码，作为个人你也没有财力让他“正常”跑起来。

2 、你说需要“仓库地址”。往往这也就意味着，这是一个开源代码。开源代码往往都不是“最佳实践”。

3 、从某种角度上讲，目前的大语言模型本身，已经具有了一定的“最佳实践”能力。只不过对于大语言模型而言，“最佳实践”的定义是统计学上的，是模糊的。楼主貌似对于“最佳实践”的定义是“知名”。

颇有点鲁迅的错别字是通假字的意味。

btw:信创项目大干快上，2020 年才开始推行，至今 5 年之内想实现全产业链的技术完备也不太现实。

再加上信创供应链的竞争不够充分，所以短时间内，想实现和业界流行框架一致的积淀与体验，着实是有点空中楼阁。

再说了，微信、支付宝、阿里云、华为的文档难道就很好了？

只了解 ARM 环境。

麒麟还可以。金仓只有部分兼容模式比较稳定，最不稳定的是 sqlServer 兼容模式。
中间件方面，东方通个人感觉比宝蓝德更完备一些。毕竟宝蓝德的核心用户只有中国移动。

报表只用过润乾，导出模式不如报表中心模式成熟。

至于说文档方面，没有发现有楼主说的这种情况。宣传物料确实偏老，但是技术文档都是最新的。

ps：当然，不要指望从官网可以得到最新的技术文档。要找你的对接人要。

@catamaran 以我目前的经历，还没发现过两种招聘“流派”融合的很好的企业。

更多的是对大厂模式的盲目崇拜东施效颦，打着实用派的名号，实际用理论派的考题。

但可悲的是，大厂的招聘，从来不已实战力作为第一评判标准。
更多的是满足当地政府的应届生就业需求，以及对竞争对手的人才垄断式打压。