From aa98cee2a837af5d4d804c768d2280dc313a56eb Mon Sep 17 00:00:00 2001 From: eltrac Date: Wed, 29 Jul 2026 13:36:00 +0800 Subject: =?UTF-8?q?[edit/typo]=20=E6=80=8E=20->=20=E5=9C=A8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/article/engineering-perspective.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/article/engineering-perspective.md b/content/article/engineering-perspective.md index a4e5cf71..591b6c41 100644 --- a/content/article/engineering-perspective.md +++ b/content/article/engineering-perspective.md @@ -90,7 +90,7 @@ Brooks 给“自动化”打了引号，因为编程不可能是自动化的。 > > 只要任务的概念部分是眼下最消耗时间的（我也这么相信），那么无论在仅仅是表达这种概念的部分上费多少时间精力，都不能产生巨大的生产力提升。 -也就是说，无论怎写代码上费多少心思，都无法影响软件在需求和设计阶段所耗费的时间，而这些时间才是真正的瓶颈。在真实软件开发中，人们可能花费数日甚至数周敲定一个所有人都挑不出毛病的方案，即便他们使用了 LLM 辅助设计。如果软件有明确的客户，那么在与客户的沟通上会出现更复杂的问题，LLM 对此唯一有用的帮助，就是快速生成原型产品（Prototype）并多次迭代，以确认用户的需求，或者验证技术方案的可行性。 +也就是说，无论在写代码上费多少心思，都无法影响软件在需求和设计阶段所耗费的时间，而这些时间才是真正的瓶颈。在真实软件开发中，人们可能花费数日甚至数周敲定一个所有人都挑不出毛病的方案，即便他们使用了 LLM 辅助设计。如果软件有明确的客户，那么在与客户的沟通上会出现更复杂的问题，LLM 对此唯一有用的帮助，就是快速生成原型产品（Prototype）并多次迭代，以确认用户的需求，或者验证技术方案的可行性。 Brooks 认为为数不多有可能直击软件工程的自发性问题的东西有几个： -- cgit v1.2.3