445 comments • Comments Link

模糊的需求一直是软件开发的瓶颈，而大语言模型（LLM）非但没有解决这个问题，反而在某种程度上放大了它。和人类开发者一样，LLM 也需要精确的指令来构建正确的产品；不同的是，人类团队通常会质疑模糊的需求，而 LLM 往往会欣然生成看起来合理但可能完全偏离目标的代码。

当面对模糊性时，LLM 的反应和人类开发者不同。对于"获取数据并交给用户"这样的含糊指令，人类会提出澄清性问题，而 LLM 更倾向于基于假设直接生成代码。这种行为在快速原型阶段可能有利，能让用户立刻看到具体成果并做出反馈；但在安全性、可维护性等终端用户不可见的关键问题上却很危险。

值得注意的是，较新的模型（如 ChatGPT 5.5）在收到模糊提示时开始主动提出澄清问题，询问数据来源、格式等要求。这是一种改进，但它仍然假定用户知道要回答哪些问题、哪些细节重要。

产品经理往往喜欢 LLM，因为这些工具不像人类开发者那样挑战模糊需求。程序员会追问边缘情况并要求明确性，但 LLM 接受模糊输入并生成看似令人信服的输出——问题只有在细致审查后才会显现。这造成了一种危险动态：糟糕的需求被转换成看起来合理但可能错误的实现。

问题的根源不仅在于需求是否明确。即便有良好的规格说明，LLM 仍可能给出模糊的解读。要靠这项技术替代对需求进行严密思考的承诺还远未实现。结果常常是一系列平庸的妥协，而非追求卓越的产品，因为技术本身无法在无人类引导的情况下弥合人类意图与实现之间的差距。

几十年前，Fred Brooks 在其 1986 年的论文《没有银弹》中就预见了这一模式。他描述了专家系统和自动化编程在窄领域内可能带来的初步前景，但在扩展时只能带来有限的生产力提升。当前对 LLM 的体验与他的预测非常吻合。

LLM 擅长从现有代码中复制模式，但要高效工作仍需要类似开发者的规格说明和任务拆解。当问题有大量训练数据支撑时，它们表现最佳。这意味着 LLM 最适用于已有解决方案的常见问题，而不擅长需要创造性思维的新挑战。

一个实际案例说明了 AI 辅助开发的潜力与局限。一位开发者使用 Claude 在几周内重建了一个 Hacker News 克隆，性能达到了生产版本的五分之一以内。但这过程需要对 AI 输出进行严格管理以防代码库变得不可读，最终成果仍缺失原始版本中大约一百个功能。

LLM 的价值在不同组织中差异很大。对于能为每个角色聘请专家的大公司来说，AI 带来的增益相对有限；但对小团队和独立开发者而言，能让一个人勉强担当多个角色，相较于完全没有能力来说，已是巨大的飞跃。

AI 对软件开发的最大影响可能并不是单纯加速编码，而是让组织能以更精简的方式运作、减少人员，从而缓解大型企业常见的角色错位和沟通问题。生产力提升更多来自组织结构的简化，而非单纯的编码速度提升。

当前用 AI 开发的方式更像瀑布式开发或自动补全，这两种模式都不是理想的协作方式。真正意义上的人机结对编程——人类与机器迭代并肩工作——仍然难以实现，但若能做到，有望同时提高速度与准确性。

实际使用 AI 编码助手的经验显示，其效用比炒作所宣称的要温和得多。开发者在最初用 AI 快速恢复对不熟悉语言的熟练度后，常会进入一个阶段：最后的 10% 工作往往占用 90% 的时间。整体提速 10%–20% 比较常见，虽然有价值，但远未达到革命性的程度。

总体上，讨论揭示了 AI 真正能力与膨胀期望之间的张力。 LLM 在某些方面确实能加速开发，尤其是对定义明确的问题和缺乏专业角色的小团队。但这项技术更多是放大了需求明确性和组织功能障碍的问题，而非解决它们。 AI 最成功的应用通常需要经验丰富的开发者提供严格监督和领域专业知识，把工具当作倍增器而非替代判断的人。更广泛的组织影响——通过简化结构来减少大型企业固有的错位——可能最终比单纯提升编码速度更为重要。 • Vague requirements have always been the bottleneck in software development, and LLMs amplify this problem rather than solving it. Just as human developers need detailed specifications to build the right thing, LLMs require equally precise instructions. The difference is that human teams typically push back on ambiguous requirements, while LLMs will happily generate plausible-looking code that misses the mark entirely.

• LLMs differ from human developers in their response to ambiguity. When faced with a vague request like "get data and give it to the user," a human developer would ask clarifying questions, while an LLM will simply produce code based on assumptions. This can be beneficial for rapid prototyping where users can immediately see and react to something tangible, but it's dangerous for critical under-the-hood concerns like security and durability that aren't visible to end users.

• Some newer LLMs like ChatGPT 5.5 have started asking clarifying questions when given vague prompts, requesting specifics about data sources, formats, and other requirements. This represents an improvement, though it still requires users to know what questions to answer and what details matter.

• Product people often love LLMs precisely because these tools don't challenge vague requirements the way human developers do. While a programmer would probe edge cases and demand clarity, an LLM accepts ambiguous inputs and produces outputs that look convincing until examined closely. This creates a dangerous dynamic where poor requirements get transformed into plausible-looking but potentially wrong implementations.

• The fundamental problem extends beyond just requirement clarity. Even with good specifications, LLMs still produce vague interpretations of problems. The promise that this technology would eliminate the need for precise thinking hasn't materialized. Everything becomes a mediocre compromise rather than an exceptional product, because the technology can't bridge the gap between human intent and implementation without human guidance.

• This pattern was predicted decades ago by Fred Brooks in his 1986 essay "No Silver Bullets," which described how expert systems and automatic programming would show initial promise in narrow domains but deliver only modest productivity gains as they expanded. The current experience with LLMs closely matches his predictions.

• LLMs excel at reproducing patterns from existing code but require developer-like specification and task breakdown to do so effectively. They work best when there's abundant training data for the problem at hand. This means they're most useful for well-understood problems with existing solutions, not for novel challenges requiring creative problem-solving.

• A practical example demonstrates both the potential and limitations of AI-assisted development. One developer recreated a Hacker News clone in weeks rather than years using Claude, achieving performance within a factor of five of production. However, this required careful management of the AI's output to prevent the codebase from becoming an unreadable mess, and the result still lacked around a hundred features present in the original.

• The value of LLMs varies dramatically based on organizational context. For large companies that can already hire specialists for every role, AI provides relatively inconsequential benefits. But for small teams and independent developers, being able to do a mediocre job at five different roles represents a huge leap over having no capability in those areas at all.

• AI's greatest impact may come not from speeding up development itself, but from enabling organizations to run leaner with fewer people, thereby reducing the misalignment and communication problems that plague large corporations. The productivity gains come from organizational simplification rather than raw coding speed.

• The current approach to AI in software development resembles either waterfall methodology or autocomplete, neither of which represents an optimal pairing experience. True pair programming with AI, where the human and machine collaborate iteratively, remains elusive but would likely improve both speed and accuracy.

• Real-world experience with AI coding assistants suggests more modest benefits than the hype implies. After initial productivity gains from using AI to get back up to speed in an unfamiliar language, developers often find themselves in a phase where the last 10% of work takes 90% of the time. Overall speedups of 10-20% are common, which, while valuable, falls short of revolutionary claims.

The discussion reveals a tension between AI's genuine capabilities and the inflated expectations surrounding it. There's broad agreement that LLMs can accelerate certain aspects of development, particularly for well-defined problems and for small teams lacking specialized roles. However, the technology amplifies existing challenges around requirements clarity and organizational dysfunction rather than solving them. The most successful uses of AI appear to involve experienced developers who can provide tight oversight and domain expertise, treating the tool as a force multiplier rather than a replacement for human judgment. The broader organizational impact may ultimately matter more than raw coding speed, with AI enabling leaner structures that reduce the misalignment inherent in large enterprises.