混沌随想 不止是10倍，人月神话下的AI现代开发
传统研发排期
对于一个代码量在1.5-2万多行的项目，传统开发模式，比如无大模型介入，无AI自动化，按《人月神话》时代的排期，需要多久。
让我们请教下 deekseek r1。
在传统编程模式下，人类手工产生的高质量代码可以在每日50-100行。追求速度牺牲质量下，可以200+行。其中包括理解需求、设计接口、设计数据库结构、测试等。
而传统编程因为沟通协作，人力的增加不能导致进度线性增加，这正是 Brooks 定律。
如果按这种进度进行排期，一个设计周全、优秀架构、高质量代码的1-2w项目人类手工编程可能会排期到达半年至一年。这还是理想状态不考虑人的其他不确定因素。
借助 AI 后的人效
如果我们借助高质量的现代大模型以及配套的 AI工具呢？
Airbib 团队最近发布了一篇博客展示了他们的结论。
一个预计需要 1.5 年的代码迁移项目，在像 Airbnb 这样的一流工程团队中，利用 LLM 仅用 6 周就完成了—快了 90%+。那大约是 50 万美元的研发费用节省。 Airbnb
笔者最近的经历也可以回答这个问题: 答案是不超过 10天。
一个大规模 AI 自动化数据补全项目，按持续迭代的业务需要将 etl 标签、加工成不同的任务批次，并分配成不同AI任务类型，设计通用的规则系统以拓展持续的业务标签转换成 AI 任务。
设计可扩展的 Agent 系统，其中AI 任务类型由大量的 Agents 组成，每个 Agent 由各种各样的系统的信息，以及特定的知识库召回组成，并调用大模型完成任务。设计和抽象共用的上下文服务，以及大模型调度机制。
AI任务通过前端接口调用，或者批量轮询任务组成。设计AI轮询列队，考虑分布式进程抢占，以及大模型网关限流。定时监控 AI任务的进度、异常，以及自动释放和恢复等。脱敏后的内部需求描述
面对这样的一个系统，如果按传统的迭代，手工设计、编码、测试、验证、迭代可能需要几个月甚至一年。
一旦利用 AI，比如 cursor + llm 等协作，上面的需求可以在 10 天内完成上线，代码量在1.5万+（不包括文档），开发人员为个位数——这不只是 10 倍。
AI 如何打破人月神话？
让我们分解传统研发编耗时最长的三个步骤: 设计 + 编码 + 测试。
设计
设计是一个将需求转换为详细代码方案的过程。包含整个系统的架构如何交互、表结构如何设计、代码模块如何分布、从完整的用户故事转为技术方案。
传统模式下，这部分通常有架构师/开发负责人先独自思考，再交开发团队成员分解细节，最后反复讨论，再优化迭代成最终方案。人类知识的局限造就了分工协作，也消耗了大量时间（Brooks 定律）。
AI 模式下，由一位全栈或者经验丰富的工程师，直接和 AI 进行对话探讨: 将产品需求翻译成技术需求，并把自己对需求的基本理解，方向告诉 AI，逐步引导 AI 形成详细的设计蓝图。人类负责不断 review 方案，再自然语言反馈，直到方案细节一览全余，毫无漏洞。由于 AI 的知识领域的宽度远远超过人类，这将导致在设计的全面上，比人类更优秀，比如通常顶级的大模型会考虑跨越前端、后台、数据库、设计模式、系统监控、性能压力、可维护性、可测试性等一系列问题。
对于一个已经明确需求的中型项目，人类工程师可以和 AI 探讨一个下午完成最终版本方案，期间无需要其他人再参与，最终版本可以和人类其他团队再讨论，发现不足，再反馈给 AI。
编码
我们继续先和另一个 AI 开始新的上下文探讨。由于设计阶段已经把产品需求转为了详细的设计，包括表结构，以及交互流程，所以编码阶段，我们不再和大模型讨论需求细节，而是着重如何把目前的技术方案转成可落地的代码体系。通常良好的技术方案已经包含一定的代码架构，但这些还不够详细，我们需要精确到目录结构、文件功能、以及接口参数、模块调用流程级别的颗粒度。
这一次讨论的目的是要形成接下来指导 AI IDE 的 Propmt，比如 cursor 等这类工具在 Agent 模式自动完成需求的提示词如何设计。这类提示词，会细化到详细的代码实现，你必须提前和另一个AI 完成讨论，100% 确定详细的细节，cursor 将只负责文件级别的自动化创建、编码。
在 curso agent 模式下，我们已经进入了 prompts is code 的时代——提示词即是“代码”，而代码已经是提示词编译后的目标产物。你最好保存这份提示词，以方便未来优化“编译结果”。
基于顶级大模型的 AI IDE 一次性可以生成几十个文件，数千甚至上万行代码。最新的 sonnet 3.7 max 可以覆盖 200k的上下文，这意味着数万行代码能直接被大模型的自注意力观察到。
当 AI 把设计方案全部转成最终对代码文件后，人类开始尝试把程序运行起来。当前阶段不要过度期待 AI 生成的几十个文件，几千行代码，能一次性 run 起来。人类后续的主要工作就是调试代码，并使其运行正常。
测试
从前面 run 的步骤开始，我们已经进入了测试流程，测试将会是目前 AI 研发模式下人的主要工作（未来也会被 AI自动化）。人类程序员将会逐步验证每个需求的细节点，并和 LLM 一起设计测试方案、测试数据、测试脚本。人类负责按需求执行这些测试，并进行验收，如果遇到任何问题，再反馈给 AI，进行局部修复调整，直到满足上线要求。
实际工作过程，笔者发现 AI 生成的代码通常质量非常高，这会进一步压缩传统测试时间。而笔者在完成如上需求到过程，费时最多的是和人类打交道，比如适应需求的变化，以及团队协作的调整。这类工作是目前 AI 无法替代的。
至此，我们已经介绍了一个超 1.5 万行完整的中等项目如何借助 AI 完成快速且生产力级别的上线。
AI研发时代对人才新的要求
过去，我们考察一个软件工程师通常有 letcode 各种难度的算法题目，有考察现场手写代码的技巧速度，以及各类“八股文”式的基础知识问答等。
Homebrew 作者的面试轶事不少人应该听过。
Homebrew是Mac上最好用的包管理器, 地位相当于Ubuntu的apt，而Max Howell是Homebrew的作者, 某天去google 面试, 面试官出了一道反转二叉树的题目, 让其在白板上手写，然而Max Howell没答上来, 最后, Howell 在推特上吐槽这件事情，引发很多 google 员工调侃: 虽然我们 90% 的同事在用你的工具，但不好意思，你无法在白板手写二叉树，按流程，我们拒绝录用。
反转二叉树应该是一个经典的算法（其实笔者应该也忘记了~~），当下，在软件领域，企业在考察一个人都时候，通常会流程上通过大量这类算法进行过滤，这也是当前求职者面试前会进行 letcode 刷题的来源。
如果以这些“考试”纬度考察 AI，将会秒杀大多数工程师，o3 模型在Codeforces 上的Elo 评分达到了2724 分(99.8th percentile)，全球排名Top 0.2%。和 AI 比 hard 算法编程，就像人力黄包车和汽车比竞赛。未来AI 的算法排名只会越来越高，并拉开和人类的差距。
同样，在软件编程领域，AI 的质量和速度越来越高，人类工程师更重要的技能是如何驾驭 AI，并应用 AI。
驾驭 AI 需要什么
这最终引向一个终极问题，怎么样才能成为驾驭 AI的人？
大模型问世后，提示工程成了一个热门话题了甚至专门的岗位。笔者也一直保持着关注和进行过分享，在长期从事相关工作后，很遗憾的是，驾驭 AI 的能力并没有特别的捷径。虽然我们有大量提示工程技巧，诸如 COT、TOT、few shot等，但这些并非是和 AI 共处的长期壁垒，而是一种基础技巧。在模型越来越聪明的趋势中，这种显示的技巧的越来越不重要。
要回答继续这个问题，可以先做一个思想实验。
想象你的手上有一群非常聪明的科研助手，他们有非常强的研究能力，并持续的在替你完成某个领域的科研课题。在一次进度汇报中，助手 A 因某个结论和助手 B的论文细节有冲突，而你作为项目导师需要为这个争论做一个有理有据的分析，并给出审查意见。
如果你并非这个领域的专家，请问你能为这群聪明的人做出判断吗。来自混沌随想的思想实验
如果把这群聪明的科研助手当做顶级模型，比如o3、o1、grok3、 r1等，答案显而易见，你无法深入其中细节进行审查。当前在软件领域也是类似，在面对复杂的项目下，人类的设计选择、代码细节审查非常重要。
我们必须要在和 AI 的反复探讨中才能深入方案细节，就如同科研导师必须和助手深入交流。笔者去年有某个 Agent 项目的例子，当时遇到一个可拔插的设计问题，如果我只是让 AI: “请为当前系统设计一个可拔插的 Agent架构”。那 AI 可能会选择“策略模式”、“依赖注入”、“抽象工厂”等各种策略，甚至不同的大模型会有不一样的设计。如果你对这些设计模式适合场景一无所知，根本无法对代码方案进行审查，给 AI 合适的反馈。
这有点想起了《javascript设计模式与开发实践》作者（也是笔者之前的导师）的一个形象比喻
当足球教练看到对方边后卫速度慢，中后卫身高矮时，自然会想到“下底传中”这种模式。 《javascript设计模式与开发实践》
我们要能够在某些领域和 AI 交流讨论，前提是你要有足够的判断能力——专业领域的审查在 AI 时代至关重要 。这些都是由大量的项目实践、思考等组成的经验。提示工程技巧不过是与AI协作的基础门槛，就像学会使用搜索引擎的关键词技巧一样。真正重要的是我们的专业深度和判断力。
换句话说，AI时代对工程师的要求不是降低了，而是转变了。传统开发模式中，我们80%的时间花在编码和调试上，20%的时间用于系统设计和架构思考。而在AI赋能的开发模式下，这个比例几乎完全颠倒过来了——我们需要花更多时间进行高层次的思考、评估和决策，而将繁琐的代码实现交给AI。
AI工具链正在构建一个新的软件开发栈。如果说传统开发栈是从操作系统到编程语言再到应用框架，那么AI时代的开发栈则是从大模型基座、AI IDE到提示工程框架。未来的软件工程师需要熟练掌握这个新栈。
对新入行者来说，好消息是AI大大降低了编程的入门门槛。你不再需要记住所有语法细节或者所有库函数的用法。但坏消息是，AI无法替代对问题本质的理解和系统性思维能力的培养。这意味着，即使AI可以帮你写代码，你仍然需要理解代码的工作原理，以便能够有效审查、调试和优化AI生成的代码。
在我看来，未来的顶尖工程师将会是那些能够：
1. 精确表达需求和设计意图的人
2. 快速评估AI提案优劣的人
3. 在AI生成的大量方案中找到最佳解决方案的人
4. 将AI视为协作伙伴而非仅仅是工具的人
对于工程团队来说，挑战则是如何重构传统的开发流程以适应AI时代。需求分析、系统设计、代码审查和测试验收等环节都需要重新定义。例如，代码审查可能更关注架构合理性和业务逻辑的正确性，而不是代码风格和实现细节。
随着AI能力的不断提升，技术行业的壁垒将从“如何编写代码”转向“如何驾驭AI创造价值”。这种转变类似于工业革命将体力劳动转向了机器操作和设计。而机器操作设计，必须要领域专业知识深度 × AI协作效率。这两者缺一不可：没有专业知识，无法审查和指导AI；没有AI协作能力，则无法释放生产力倍增效应。
在结束这个话题之前，我想再强调一个 X（推特） 上看到的观点
When elite universities uploaded all of their courses online for public consumption, we collectively realized that the limiting reagent for global intelligence is not access to information, it's motivation.
当精英大学将所有课程上传到网上供公众使用时，我们共同意识到，全球智慧的限制因素不是获取信息的渠道，而是动机。X
AI 时代motivation动机的力量会被更大倍数的放大，所有的知识通过 AI 都能快速获取，但获取知识的动机则每个人都不一样。
未来已来，但分布不均。在软件开发领域，AI革命已经开始，那些能够拥抱变化、快速适应并利用AI优势的工程师和团队，将在这场变革中脱颖而出。
文档信息
