换句话说，与其说 AI 给程序员的工作带来迷茫，不如说是过去 10 年的程序员行业过于畸形。

你能想象一个工地要求搬砖工应聘需要一边倒立一边算微积分一边搬砖的么？

我看到的程序员行业就是这样的。

首先，能不能先定义：“继续把前端这条路往深处挖”深挖的到底是什么？
以及，“深挖”在你的实际工作中有什么功效？

如果“深挖”对你目前的工作没有意义，那么和四种茴字有什么区别？
如果“深挖”对你目前的工作有意义，那说明你的工作内容一定是非常极致的，这也就代表在互联网一定没有多少训练语料。大语言模型也就一定不擅长。

所以，无论怎么看，你纠结的点和 AI 有什么关系？

@Shaozzzzzz 如果是 0.5 毫米，不是厘米的话，尽量别动了，细小污渍清除的风险收益比不划算。
而且漆点是去除难度最大的，因为时间长了之后会和清漆完全相容，跑泥下不去的。

车顶很容易积攒很难去除的污垢，攒多了之后去汽美抛个光可能是更舒适、更划算的选择。

@andrewTeller 我的快六年。目前比较明显的感觉就是压力克数降低（变软）。然后回弹速度下降（没有一开始那么清脆了）

然后常用的按键和不常用的按键，手感开始有了细微差别。比如功能键区，和 SDF 、JKL 相比，手感有可以查觉的区别。

Niz 静电容，劣势是相比机械键盘，手感衰退会比较快。

所以目前有个替代品种出现，磁轴。打算等大厂跟进后买一把试一试

我个人理解，有三个维度：

1 、上下文供给
影响 vibe coding 效率，最大需要解决的问题就是如何最高效率的提供上下文（也就是既有信息）
目前商用产品上能解决到整个 workspace 都是上下文（类似 cursor 、Copilot 等）
还有文档、知识库等的读取。

2 、需求阐述技巧
比如如果这个对话出现事实错误，就不要试图纠正，而是重新开启一个对话等等。

3 、接入更多能力
比如 MCP ，来拓展 AI 的功能边界。


至于说实际实践，其实每个企业都不一样，因为每个企业的上下文环境，保密要求等都不同。

恰恰不是，如果是 AI 生成、审核，就不会有这些问题了。

出现的问题普遍在于：
1 、大公司团队单打独斗，各扫门前雪。
2 、产品线过于冗长，导致开发、维护产品需要考虑的上下文超过人脑极限。
3 、出现过于弱智的问题上到生产环境（比如没有 trycatch ）

以上这些恰恰是目前的统计学 AI 所擅长的。
1 、有远超人脑范围的上下文解析与兼顾能力。
2 、产出虽有波动，但水平稳定。
3 、没有指责问题。

这种乌烟瘴气的东西发在技术相关节点就不合适了吧……
@livid

@exnes 国产的话，绿田就有，好像叫闪耀？

弱酸性，比较安全。
但是正洗不管用什么洗车液，还是要带手套。

@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 、代码合并逻辑。

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