非工程师如何判断代码可靠性？从白盒到黑盒的验证方式转变

补充观点，原文说的不是不关注质量，只是保障质量的方式和以前不一样，以前更多通过白盒看代码保证质量，现在则更多是黑盒通过验证 https://t.co/L1jMi43QfM

补充观点，原文说的不是不关注质量，只是保障质量的方式和以前不一样，以前更多通过白盒看代码保证质量，现在则更多是黑盒通过验证 x.com/dotey/status/2… 宝玉 @dotey 我觉得我们的观点并没有那么大的分歧 第一，这个问题问的是“非工程师”怎么判断代码靠不靠谱。让一个看不懂代码的人去审查“事实、思考、推理是否完备”，这个标准他执行不了。执行不了的标准等于没有标准。他真正能做的，是从外部验证行为：功能、性能、安全。 第二，即使是“工程师”这么做，我觉得也是没有问题的。因为保证正确性是“目的”，我们可以有多种手段，既可以靠读推理过程读出来的，也可以靠验证验出来的。 软件工程一直如此：编译器的输出我们不逐行审，第三方库我们不通读源码，靠的都是接口契约加测试。推理看起来再完备，跑不过测试也是错的。 第三，“没有完整准确的信息就不该行动”，这在现实工程里不存在。再好的人类团队也做不到信息完备才动手，靠的是小步迭代、快速验证、出错可回滚。我说的“拆成小模块”正是为此：模块越小，信息越容易完整，验证越容易充分。 第四，AI 检索信息快，不等于结论对。它完全可以给出一个论证严密、引用齐全但就是错的方案。所以越是 AI 时代，越不能以“它的思考看起来合理”为准，相对来说以结果为准还更靠谱一些。 “验收只能覆盖你想得到的场景”，这一点我是认同的，跟我原文的观点也不冲突：验收标准本身要想清楚，涉及安全、钱和数据的关键路径，拿不准就找专业的人。 🔗 View Quoted Tweet 💬 1 🔄 0 ❤️ 1 👀 2269 📊 1 ⚡