加载失败
讨论基于“Computer Says No”这个主题展开，核心在于用 LLM/AI 生成代码是否会把产品变成黑盒并侵蚀工程师对系统的理解。评论里有人把 LLM 输出的不可预测性与传统编译器（如 GCC/clang 处理 C 代码）做对比，认为后者虽然不可读但更可靠且便于专家排查。讨论还涉及效率与工艺的权衡：一方面 AI 可以加速实现、把时间释放给业务与利益相关者沟通；另一方面担心可维护性、边界条件处理和长期架构判断会被削弱。评论中给出具体实践建议，例如用 pseudocode 规定接口、以迭代方式引导模型，以及保持人类随时能接手的可读代码。
评论指出把编程任务交给 LLM 会产生“黑盒”抽象：模型有时根本不会输出可运行的代码，容易在边界情况出错，并倾向生成难以维护的“spaghetti code”，使人和模型都难以扩展或调试。与此对比，像 C 语言经由 GCC 或 clang 编译后的汇编虽然难以直接读懂，但更有确定性且失败率低，遇到问题时通常能找到专家排查。评论还强调自然语言本身不精确、不模块化，使用英语 prompt 描述复杂算法或精确样式会变得极度冗长，效率不如使用真正的编程语言或借助伪代码等中间表示。有人进一步预测，如果大量依赖 AI 产出代码，交互方式更可能演化为项目专用的 GUI 或更激进的脑机界面，而非仅靠逐句提示。
有评论强调“工艺”是与材料的关系——通过写代码、感受约束、重构和建模才能形成对系统的深刻认识。把“动手编码”的循环外包给代理，会削弱工程师解释难点、识别边界和发明更好架构的能力，长远看不利于可维护性和创新。个人经验补充称，晋升或协作导致脱离具体实现会让人对细节失去直观把握，这种丧失与把工作完全交给 AI 导致的认知脱节有相似之处。
部分评论认为 AI 工具能把开发者从机械编码中解放出来，让他们有更多时间关注业务影响、与利益相关者沟通并思考产品的边界问题，很多曾被认为复杂的功能因此变得更可行。有人指出在一般开发者层面，这种效率提升很明显——代码从未是主要瓶颈，业务才是限制因素。与此同时也有反对意见认为优秀工程师大量时间用于处理边界条件、写出可支持的代码风格并保护系统免受其他部分失败影响，而这些深层判断目前并不被 AI 完全覆盖，因此 AI 增强产能但不能完全替代专家级工程实践。
多条评论提出在工作中应避免让 AI 产物变成不可接手的黑盒，主张将 AI 当作“键盘扩展”（keyboard extension）以迭代方式使用，严格把控架构与接口，保持代码始终能被人类立即接手。具体做法包括用 pseudocode（伪代码）定义高层结构或合同，让模型填充样板实现，并在每步保持可读性与可维护性。还有评论建议利用 AI 帮助解释失败原因（让“computer says no”变成“computer says why”），从而把自动化和人类的调试理解环节结合起来。
black box（黑盒）: 指内部实现不可见或不可预测、只能通过输入/输出交互来理解的系统抽象；黑盒化会导致难以调试、验证和维护。
LLM（Large Language Model）: 一类用于自然语言理解与生成的深度学习模型（如用于代码或文本生成的 GPT 系列），擅长生成表面合理的输出但可能给出不可靠或不完整的实现。
pseudocode（伪代码）: 用接近日常语言或松散语法描述算法与接口的高层表示，常用作向模型传达结构性意图而不写完整实现的桥梁。