核心观点 科学关注“什么规律成立，以及凭什么相信它”，工程关注“在给定目标和约束下，怎样把结果可靠地交付出来”。二者不是高低之分，而是目标、证据和完成标准不同；优秀工程会主动使用科学方法处理未知问题。
假设团队准备上线一个 AI 代码审查助手。
科学式问题可能是：
工程式问题则可能是：
前一组问题试图建立可重复验证的认识，后一组问题要在性能、成本、安全、体验和维护之间做出选择。它们可能使用相同的数据和实验，却服务于不同的完成标准。
科学研究通常从现象出发，提出假设，再通过观察或实验判断假设是否得到支持。
一个科学问题通常关心：
科学工作的产物不一定是一个立即可用的系统，也可能是一套模型、规律、数据或对不确定性的更准确描述。
“证明绝对正确”并不是所有科学研究的现实状态。许多结论是当前证据下最有解释力的认识，未来可能被新数据修正。科学的关键不是永不变化，而是结论能够接受公开检验。
工程从目标和现实条件出发，利用已有知识设计可运行的人造系统。它不仅要问“能不能做”，还要问“是否值得这样做、能否按时完成、失败是否可控”。
工程问题通常同时包含：
因此，工程方案很少只有一个。两个方案都可能正确，只是优化目标不同。
例如，小团队要在两周内验证一个内部流程，单体应用和托管数据库可能最合适；同一业务进入高并发、多团队长期协作后，模块边界、容量规划和故障隔离就会变得重要。方案没有改变物理规律，改变的是目标权重和约束条件。
科学往往从未知现象或理论冲突出发；工程从需要实现的功能或需要改善的结果出发。
科学结论需要经得起证据检验；工程结果需要达到验收指标，并能在真实环境中运行。
科学希望找到跨场景仍成立的规律。工程决策往往高度依赖具体环境，同一做法换一个团队、阶段或风险等级就可能不再合适。
科学实验会尽量控制变量，以识别因果关系；工程必须同时处理多个变量，并接受“足够好但并不完美”的解。
科学实验失败也可能提供新知识。工程失败如果影响资金、安全或用户权益，就必须提前设计隔离、降级和恢复机制。
所谓最佳实践，通常是某类团队在一组常见条件下反复验证后形成的高成功率做法。它是一份经验压缩包，不是脱离上下文的定律。
评估一项实践时，可以追问：
例如，微服务可以改善大型组织的独立部署与责任边界，也会引入网络故障、数据一致性、观测和运维成本。对一个尚未验证需求的小产品，先拆成十个服务可能不是“更专业”，而是提前支付尚未产生收益的复杂度成本。
正确做法不是拒绝最佳实践，而是理解它成立的条件，再决定采用、简化还是延后。
工程项目经常混合“已知如何实现”和“不确定是否可行”两类内容。如果不做区分，团队容易把研究任务当成普通排期，也可能把已有成熟解的问题反复实验。
可以把未知分成三类。
例如某 API 是否支持批量操作、某版本是否修复了安全漏洞。处理方式是查询可靠文档、源码或实际环境。
例如增加上下文是否真的提高代码审查质量。这类问题需要设计对照实验、定义指标并收集数据。
例如准确率提升 3%，但成本增加一倍，是否值得采用。它不能只靠实验回答，还需要业务目标、风险偏好和资源约束参与判断。
把未知分类后，团队才知道应该查资料、做实验，还是召开决策评审。
AI 系统不是普通的确定性函数。把模型用于软件工程时，需要把以下特征当成设计输入，而不是上线后才发现的异常。
同一输入可能得到不同结果。关键流程不能只测试一次成功样例，而应使用固定评估集、多次运行和明确阈值观察稳定性。
模型能够接收很长的上下文，不代表每条信息都会被同等重视。无关内容、重复规则和相互冲突的文档会稀释关键信号。
工程上应优先提供与当前任务相关的上下文，并让代码、规范和数据保持单一可信来源，而不是无差别地把所有资料塞给模型。
模型可能不了解最新版本，也无法凭空知道企业内部接口和实时状态。涉及版本、价格、法规、生产配置或线上代码时，应通过工具查询真实来源。
模型可能在证据不足时仍给出完整答案。因此，重要事实要能追溯到文档、代码、数据或实验结果，不能把语言流畅度当成可信度。
一次会话中的理解不会自动成为团队长期记忆。需求、决策、接口和操作历史需要由版本控制、文档、测试和可查询记录保存。
如果提示只要求“修复测试”，模型可能修改测试来让它通过；如果只要求“减少错误”，它可能隐藏错误提示。验收标准必须描述业务结果和不可违反的边界，而不只是表面指标。
工程不是凭经验拍脑袋。面对高不确定性时，最有效的做法往往是把大决策拆成可验证的小假设。
以“引入 AI 客服摘要能否降低处理时长”为例，可以这样推进：
科学方法帮助我们认识因果和边界，工程方法负责把这些认识转化为可靠系统。
面对架构、工具或 AI 方案选择时，可以使用下面的顺序。
用可观察结果描述成功，而不是先写技术名称。例如“把订单查询 P95 延迟降到 800ms 以下”，而不是“引入缓存”。
哪些条件绝不能违反：数据不能出境、必须兼容旧接口、两周内上线、只能使用现有数据库等。
区分事实未知、规律未知和决策未知，为每类未知选择查询、实验或评审方法。
至少比较收益、成本、风险、可逆性和长期维护负担。不要只比较功能数量。
信息不足时，先采用容易替换、影响范围小的方案，并设置重新评估的时间点。不可逆或高代价决策则需要更多证据。
提前写明何时算成功，出现什么情况必须停止，以及如何回滚。没有退出条件的试点很容易永久变成无人负责的生产系统。
保留当时的目标、约束、证据和取舍。未来环境变化时，团队才能判断是方案错了，还是原有条件已经改变。
科学问题帮助我们获得更可靠的认识，工程问题要求我们在不完整信息和现实约束中承担交付责任。科学追求可检验，工程追求可用、可控与可持续。
理解这个区别之后，我们就不会把某个框架、流程或 AI 工具当成普遍正确答案，也不会把“项目能运行”误认为工程已经完成。真正成熟的做法，是在未知处设计实验，在已知处遵循工程纪律，在取舍处明确责任，并让每个重要结论都拥有与风险相匹配的证据。