2026年：大语言模型冲击下，软件开发严谨性该何去何从？

大语言模型下的软件开发困境

在2026年2月16日的思考中，上一篇文章《战术龙卷风》结尾提到，认为大语言模型（LLMs）能解决所有代码阅读和调试问题的想法是不负责任的。因为理解和维护源代码一直是程序员的工作，也是维护软件系统的方式，而且我们要对大语言模型的输出负责。

组织决策与新限制

然而，如果我们向组织领导说明风险和权衡后，他们仍愿意承担风险，该怎么办？这种情况并不少见，公司尤其是科技初创公司，常为提高生产力、抢占市场先机、吸引投资者等做出短期妥协。若组织要求利用大语言模型减少编码时间，这就成了新限制。我们可以思考此时良好的工程实践该是咋样的。我们可以像不阅读汇编代码等那样，不再阅读大语言模型生成的代码，高级语言源代码就相当于另一种机器代码。

大语言模型输出特性与应对

阅读Thoughtworks的研讨会报告后发现，大语言模型的输出不确定，且生成代码速度比阅读速度快得多，所以不能指望有效审查、理解和批准每一处代码改动。但这不意味着不严谨，而是要把严谨性转移到其他方面。不过，这不是个人或团队能决定的，必须是组织层面的决策，这不仅因为风险管理和责任问题，还因为阿姆达尔定律（Amdahl’s law）。

现有工作模式的局限

如果只是提高代码生成速度，而不重新调整工作的组织结构和流程，就不会有实际的生产力提升。不能让一些开发人员产出质量不佳的大量代码，却期望其他人阅读、理解和批准。如果工作单元不变，就无法充分利用智能代理。若每个工程师能承担多项任务，让智能代理在非工作时间运行，产品负责人也无法提供足够工作让小团队忙起来。

新开发流程的要求

相反，我们需要减少人工干预，降低协调成本、摩擦、官僚作风和把关环节。需要有几乎无限的需求供应，让工程师扮演准产品设计师的角色，负责整个工作流程并有权自主决策。由于返工成本几乎为零，不必费力防止错误工作发生。

严谨性的体现

那么严谨性该体现在哪里呢？和Thoughtworks的报告类似，首先想到的是规范（和提示语不同）和测试（和测试驱动开发不同）。若推行这样的开发流程，会把标准化的Markdown规范作为软件项目的新知识单元。产品负责人和工程师先在规范和测试用例上协作以执行业务规则，这些应和实现代码一起存入项目仓库。还需进行自动化的拉取请求检查，不仅验证测试是否通过，还要验证代码是否符合规范。团队要理解、审查并对规范负责，而非具体实现代码。