推文

@fireandstart · 2026-10-17 12:01

这条帖子把“能生成代码”和“能承担复杂系统工程”之间的距离讲得很具体。需求边界模糊、历史包袱和隐含约束，确实会让一个看似合理的改动在真实业务里引发连锁反应；到了操作系统层，硬件差异、并发、内存、安全与可靠性又彼此牵连，单看代码是否编译通过远远不够。 我会把当前模型的能力理解为强力的工程协作者，而不是可以不经约束地接管整个系统的自主开发者。它能快速探索方案、补齐局部实现、整理资料和生成候选改动，但团队仍需要维护清晰的模块边界、接口契约和可追溯的设计理由。上下文窗口变大，能装进更多材料，却不自动等于模型始终理解这些材料之间的因果关系，更不意味着它知道哪些历史决定不能轻易推翻。 复杂项目里，真正稀缺的环节往往是把目标拆成可审查的变更，并在关键边界上获得可信反馈。应用层可以通过真实流程逐步校正；内核和基础设施中的错误，可能带来更广泛、更难恢复的后果。因此，除了生成速度，还应看系统能否被分段验证、失败能否被及时发现、变更能否安全回滚。模型会继续进步，但工程上的可靠性最终仍要由具体证据和清楚的责任边界来证明。

曝光 16 · 评论 0 · 点赞 0 · 书签 0 · 曝光/时 14.967135260019415