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

大语言模型下的软件开发困境在2026年2月16日的思考中上一篇文章《战术龙卷风》结尾提到认为大语言模型LLMs能解决所有代码阅读和调试问题的想法是不负责任的。因为理解和维护源代码一直是程序员的工作也是维护软件系统的方式而且我们要对大语言模型的输出负责。组织决策与新限制然而如果我们向组织领导说明风险和权衡后他们仍愿意承担风险该怎么办这种情况并不少见公司尤其是科技初创公司常为提高生产力、抢占市场先机、吸引投资者等做出短期妥协。若组织要求利用大语言模型减少编码时间这就成了新限制。我们可以思考此时良好的工程实践该是咋样的。我们可以像不阅读汇编代码等那样不再阅读大语言模型生成的代码高级语言源代码就相当于另一种机器代码。大语言模型输出特性与应对阅读Thoughtworks的研讨会报告后发现大语言模型的输出不确定且生成代码速度比阅读速度快得多所以不能指望有效审查、理解和批准每一处代码改动。但这不意味着不严谨而是要把严谨性转移到其他方面。不过这不是个人或团队能决定的必须是组织层面的决策这不仅因为风险管理和责任问题还因为阿姆达尔定律Amdahl’s law。现有工作模式的局限如果只是提高代码生成速度而不重新调整工作的组织结构和流程就不会有实际的生产力提升。不能让一些开发人员产出质量不佳的大量代码却期望其他人阅读、理解和批准。如果工作单元不变就无法充分利用智能代理。若每个工程师能承担多项任务让智能代理在非工作时间运行产品负责人也无法提供足够工作让小团队忙起来。新开发流程的要求相反我们需要减少人工干预降低协调成本、摩擦、官僚作风和把关环节。需要有几乎无限的需求供应让工程师扮演准产品设计师的角色负责整个工作流程并有权自主决策。由于返工成本几乎为零不必费力防止错误工作发生。严谨性的体现那么严谨性该体现在哪里呢和Thoughtworks的报告类似首先想到的是规范和提示语不同和测试和测试驱动开发不同。若推行这样的开发流程会把标准化的Markdown规范作为软件项目的新知识单元。产品负责人和工程师先在规范和测试用例上协作以执行业务规则这些应和实现代码一起存入项目仓库。还需进行自动化的拉取请求检查不仅验证测试是否通过还要验证代码是否符合规范。团队要理解、审查并对规范负责而非具体实现代码。