软件工程基础比LLM更重要
Software Engineering fundamentals matter more
面对agentic engineering的喧嚣，我深感软件工程师的核心价值并未动摇。尽管LLM和agent harnesses能预测代码，但它们缺乏真正的推理能力，无法处理复杂的系统架构。真正的挑战在于如何让代码可调试、可维护且分层清晰，这需要深思熟虑的架构设计，而非简单的指令跟随。在Open weight模型让个人电脑也能运行大模型的今天，我们更需要关注如何管理认知负荷，做出恰当的权衡。无论工具如何进化，精心打磨软件接口的工艺，才是我们作为工匠的立身之本。
LLM并不具备真正的推理能力，它们只是在预测，本质上是将人类知识压缩后的模型。
HN 评论区
235- Alien1Being
用生成式代码写出来的项目，目录结构、接口设计和整体状态管理通常都是一团糟，哪怕是用最好的前沿模型也不例外。但真正让我头疼的是，模型经常替我做一些我在提示词里根本没指定的假设。比如哪些错误状态是“糟了，赶紧跑路”，哪些是“虽然有问题但还能忍”。有时候它会问，但更多时候它直接拍板，而且往往拍错了。如果我没有一套完善的测试用例和可靠的类型检查器来验证最终产物，那整个循环过程对我就毫无用处，我最后还是得逐行审查它生成的代码，还得靠我多年的架构经验来确保我们不会堆出一堆垃圾。
- brabel
> 知道 LLM 并不具备“推理”能力是有帮助的。它们只是在预测……
语义上，预测确实是训练目标。但推理能力可以是——而且非常有理由认为确实是——这种训练目标的涌现属性。
- mortalapeman
“它们在根本上无法始终如一地防止提示注入攻击。‘对齐工作’、安全护栏和沙箱虽然能增加防线，抵御最坏情况，但根本性的缺口依然存在”……
它们似乎在许多基础最佳实践方面做得非常好，甚至比人类还好，但更准确地说——如果你带着具体指令去运行和审计——它们在这方面确实很出色。
我的意思是，这正是它们最擅长的：以机械的方式应用“模糊启发式规则”。如果你能简洁地描述问题、模式、风格和规则，LLM 就能非常机械地、有条理地逐一处理。
我甚至看不出这有什么争议——不用纠结“它们的推理意味着什么”——我们都可以同意，它们的合成推理在狭窄范围内相当不错，而且它们是被“编译器”训练出来的，在识别常见模式方面极其擅长。
如果你给它足够的 token 作为支撑……它们的表现会非常出色。
设计架构很难，但针对系统中所有“已知已知”的部分反复打磨，尤其是用来识别问题……它们在这方面相当不错。