博大策略
作者 & 采访 | 王启隆
出品丨AI 科技大本营（ID：rgznai100）
三十年的软件工程江湖，像一条奔流不息的河。
有人淘金，有人摆渡，有人筑坝，而吴穹，是那个试图画出河流走向图的人。
1995 年，师从杨芙清院士和梅宏院士，吴穹正在北大参与“青鸟工程”，一个近乎理想主义的尝试——在中国建立一条真正的“软件工业生产线”。做学术研究时，他内心总有一个强烈的声音在催促：如何将这些抽象的理论“落地”？毕业前夕，他找到了当时在全球软件工程领域声名赫掣的 Rational 公司，毛遂自荐，最终竟促成了这家巨头在中国的第一个办事处。就这样，他几乎是以一己之力，将 Rational 及其方法论 RUP（Rational Unified Process）这本“圣经”引入了中国。
那是一个“引渡者”的黄金时代。UML 统一建模语言、RUP，这些来自海外的严谨范式，如同精确的图纸，被递到了一群最渴望规范与秩序的中国工程师手中。吴穹和他的同仁们，就像当年的普罗米修斯，将理性的火种带到东方。他亲手将 RUP 翻译成中文，免费提供给整个社区，无数 CTO 和 CIO 都曾感念，是 RUP 为他们野蛮生长的研发体系，注入了第一支标准化的疫苗。
故事本可以这样继续——一位成功的布道者，不断引进、翻译、推广着世界上最先进的理念。然而，河流的走向，远比地图复杂。
在美国 IBM 担任全球产品经理的三年，是他人生中的一次关键“离岸”。他负责的是一款名叫 ClearCase 的配置管理工具——用他后来的话说，那是“Git 的爷爷”。他深入到一个全球顶尖产品的肌理之中，从产品经理这个“Mini-CEO”的视角，体验着一套成熟的、源自西方的研发文化。他看到的不仅是技术和流程，更是土壤之下的文化根系。
2007 年，当他带着敏捷开发的浪潮再度回国，开始帮助华为、平安科技、招商银行等巨头导入新的管理实践时，他清晰地听到了“水土不服”的断裂声。
矛盾，如同水下的暗礁，开始浮现。
西方的敏捷，诞生于鼓励试错、崇尚自组织的土壤，而中国的企业文化，更像一部严整的交响乐，强调“偏管控型”的指挥体系，追求令行禁止的确定性。
“很多敏捷教练什么都不管，就强调“敏捷”是对的。” 吴穹回忆。但这种“拿来主义”的失效，让他猛然惊醒。他意识到，自己不能再做一个单纯的“引渡者”。照搬最佳实践，本质上是一种思想上的懒惰。真正的价值，在于回到第一性原理——“敏捷”究竟要解决什么问题？是沟通效率，是快速反馈，是价值流动。然后，再用这些原理，去重新设计一套真正适合中国这片土壤的“农具”。
这背后，是他坚守了近三十年的核心战场：软件，是充满不确定性的艺术；而工程，是冷冰冰的确定性。他的使命，就是在这两者之间，为这门艺术建立工程化的秩序，让高质量的交付变得可预测、可执行。
“这个能力，一直是我们国家很缺乏的”，他认为自己的价值，就是把这件事帮助更多的企业去落地。这是他从“理念的引进者”蜕变为“本土范式的开创者”的转折点。他不再满足于给出地图，而是要亲自勘探、绘制一幅属于中国人自己的软件工程地图。这幅地图，就是他后来参与创立的 Adapt 方法论。到了 2016 年，当他意识到仅靠顾问一人之力难以撬动上千人的组织时，他需要一个杠杆。于是，软件工程工具“知微”应运而生，将他的思想注入代码。
然而，就在这幅地图逐渐清晰之时，一场更大的风暴席卷而来。
AI，以一种近乎蛮横的姿态，冲进了软件工厂。比尔·盖茨那句“我们总是高估未来两年的变化，低估未来十年的变革”的箴言，正在被狂热的现实所验证。CEO 们在云端宣告要“All in”，要彻底颠覆；而一线的开发者，却在“AI 幻觉”和“上下文缺失”的泥潭中挣扎。
一个新的、更深刻的矛盾摆在了所有人面前。吴穹敏锐地捕捉到了其中的荒诞之处：AI 工具的宣传，出现了两个截然相反的化身。“如果这个东西对员工是摸魚神器，在老板那儿它就不会是提效神器。” 吴穹一语道破。生产力的变革，从未如此尖锐地触及生产关系的根基。工具就在那里，但员工为什么要用它为公司创造价值，而不是提前下班？
这不再是一个技术问题，而是一个直抵人心的管理问题、一个组织变革的系统工程。
当 AI 可以像员工一样“领取任务”，甚至可以被“管理”，当一个程序员不再是亲自耕种的农民，而是变成了拥有一个 AI 军团的“地主”，我们又该如何衡量他的价值？当软件的生产成本趋近于零，这张图景的终点，或许就是一座将灯光熄灭、人类仅负责少量关键决策的生产体系，让 AI 自主编码的“黑灯工厂”。
这条奔流了三十年的软件工程之河，正迎来一次史无前例的河道变迁，甚至可能是一场冲毁一切堤坝的洪水。在本场对话中，我们将与吴穹一同探讨：软件工程的旧范式将如何被颠覆？而我们，又该如何自处？
“必须有一套中国人自己的、本土的、接地气的方法论”
王启隆：吴博的职业生涯经历了从理念的引进者到一个本土范式的开创者的变化过程。有没有什么契机让您觉得单纯从海外引进可能不够了？有没有什么具体的项目或事件，让您顿悟到必须有一套中国人自己的、本土的、接地气的方法论，也就是本土范式？
吴穹：出国之前我服务国内企业，到美国这三年，算是深度参与到一个产品的整个研发过程中。因为那三年我是作为 ClearCase 的产品经理，我跟那边的客户、研发团队、销售团队等各种各样的团队打交道。产品经理其实是一个 Mini-CEO，相当于一个产品的全面负责人，所以我会跟很多人去打交道。
等到我 07 年回国的时候，一开始我们是把国外的像 Scrum这样的方法论拿回来落地。前几年我们也是抱着落地的想法，但过了一段时间就发现会水土不服。因为我这三段经历有两段在国内，一段在国外，所以我比较明确地看到两种文化、两种思路的不同。我们国内整体上还是一个偏管控型的文化，这没有对错，可能是文化不同。
比如你按这样的方式去管理华为，可能会成功；但用这个方式去管理 IBM 可能会不成功。用 IBM 的方式去管理华为，虽然华为学了一些 IBM 的东西，但也不代表它全盘照抄。实际上华为在落地 IPD 的时候，还是做了很多自己的管理变革和创新。
如果你去国外，没有那么多人会说我在用 IPD 管理。所以我觉得华为也经历了一个本土化的过程。我们的管理文化、实践、组织架构、管理方式，都跟西方公司有很大差别。当你把一个敏捷方法论落进来的时候，我们以前很多时候就是不管，就说这是对的。
王启隆：你自己去想解决方案。
吴穹：对。但是我们当时觉得这样不行，要把敏捷的核心思想和国内的本土实践相结合，给出一个很具体的指导，这样在国内才能更好地落地。大概是这么一个想法。
王启隆：我觉得是从单纯的去复制成功到去研究他的思路的一个过程。
吴穹：对，相对来讲是。就是所谓的马斯克现在比较推崇的第一性原理。敏捷也是有第一性原理的，但它的第一性原理可能被包装成了一个适合国外的实践，当别人在国外做这个敏捷实践时，就可以产生效果，因为它应用到了第一性原理。现在你把这个实践完全搬回国内，就会发现它不适用，因为它跟周围方方面面的东西不适配。所以你要回到敏捷的第一性原理，重新适配国内的情况，这样的一套实践在国内就更容易落地。
所以我们今年也出了一本新书叫《敏稳兼顾：数字化研发管理实战》，专门讲规模化敏捷怎么样在国内落地。我们有一个方法论框架叫 Adapt，也就是把我们这些年的思考做了一个总结。
“不会有通用 Agent，最终还是会分化成专用 Agent”
王启隆：时间延伸到现在，我们看到了 AI 带来的巨大变革。很多企业高管也对这个新变革感到非常兴奋。但一线的研发团队，包括正在看视频或读文章的读者，会觉得在实际应用中，AI 常常让人感觉到幻觉很多，令人困惑和挣扎。您作为常年连接国内外高层战略和一线实践的顾问，认为当前企业管理者在推动 AI 赋能研发这件事上，最容易陷入的认知误区是什么？
吴穹：应该是比尔·盖茨说的，我们总是高估未来两年的变化，低估未来十年的变革。所以我觉得现在我们就处于一个狂热期，目前有点过分高估 AI 在这两年能取得的变化。
我觉得现在最常见的误区就是太着急，过分乐观。All in 是没错的，方向上 AI 肯定会彻底改变软件工程的生产方式，五年、十年来看，这肯定是确定的。
但短期之内，它的困难在哪里？我们看到现在 AI 比较强的是什么？如果你做一件任务，大模型压缩的知识已经足够了。你让它在一个熟悉的领域，用它已经掌握的知识去做事，现在它的能力已经相对非常好了。
但软件开发不是这样。你让 AI 在广场上做任何事情，用的是公域知识。但实际上我们大多数的软件开发项目都有很多私域知识。它是一个独特的金融软件，或者就算它是一个电商系统，但由于前面的人已经写了五年、十年，虽然它在领域上是个电商，但你的实现方式其实也是私域知识。
所以，这个时候你让 AI 纯粹地去处理，你只是给它一堆代码。就算现在上下文越来越长，它可以把所有代码库、所有文档都读进去。但很多时候，我们之前做这些事情的决策过程都在大脑里，没有留存文档，或者留存的文档和代码对不上。私域知识的质量是不好的，这时候你让 AI 去处理这些信息，它可能就会遇到短板。
王启隆：是的，就是常说的上下文工程，上下文不足。给它的私域数据不足。有时候你只是给它一个提示词，但它需要的可能是一个客户的聊天记录，或者你整个工程的记录，才能把事情做好。
吴穹：对，所以你会发现几件事情。我自己从今年开始也在试用 Cursor，去一线体感，我要看看这个事情现在进展到什么程度。现在大家会发现，当然最近是日新月异，每天都在变，但至少到现在为止，代码补全是一个非常高效的场景。为什么呢？因为在代码补全的上下文下，你已经把要改什么、在哪改等上下文告诉它了。
“我要在这儿改”，这是一个非常重要的上下文。你敲几行字之后，你的意图也告诉了它。所以，它在这个非常精确的点上改东西的时候，效率就会高很多。所以大家会发现代码补全很高效。但如果你不是用代码补全，而是说“我想干一件事”，那你就得给它很多上下文。
对于一个老系统，很多时候问题不是技术债，而是缺乏历史信息或历史上下文。这时候你有两个选择，要不你就手写了，要不你就把历史信息补全，把那个债补上。但你补这个债的时候，会面临不确定性：补全了就真的能快吗？你不知道。或者说要补到什么程度？这个要试验。所以很多时候大家就会说，那算了，我接着手写吧。
当 AI 应用到我们私域时，不确定性会多很多。所以现在我们看到大多数团队给我们的数据，比如 10%、16%、20%，都在体感误差范围内。你说我快了，我一定会说我比以前快了，但你说有多大效果吗？不好说，大家觉得可能会有误差。
所以我觉得长期来讲，我相信 AI 一定会改变整个软件工程的工艺、工具、组织，这些全都会变。但短期之内大家不能太着急。我看到今年有一些组织，在一些 AI 编码的突破之后，从 CEO 开始就觉得要颠覆。那 CIO、CTO 只好说好，要颠覆。底下的同学就只好说，你们觉得要颠覆，那我就配合你们颠覆。
当然，这是每次技术浪潮都会有的。比如我们回头看面向对象、CMMI、Java，每次都是这样。这是一个我们叫技术成熟度曲线（Gartner Hype Cycle）的过程，好像也是一个不可避免的过程。但我们现在只能说，尽量让大家冷静一点。要积极拥抱，但在这个过程中，要意识到上下文的缺失是 AI 发挥作用的一个很重要的阻碍。所以我们现在看到 AI 表现比较好的都是纯绿地项目，比如新建一个网站，新建一个原型，都没有问题。
图源：2025 年人工智能技术成熟度曲线 | Gartner官网
王启隆：而对于已有旧项目的维护和修改……
吴穹：难度大很多。另外，现在大家都在谈 Agent。你回头想，任何一个工程生产线，都没有人卖通用的工程生产线。真正最后软件工程实现了，或者说更高度自动化了，它一定会有很多差异化的生产线。没有人说这是一个万用生产线，做任何机器——造车、造火车、造导弹——都可以用，因为这不 make sense博大策略，肯定是个浪费。
我明明要造车，为什么要用一个万用生产线？你一定会把它调制成一个造车的生产线，像特斯拉一样。里面有一定灵活度，可以造 A 类车，可以造 B 类车，但我不会用它来生产飞机，因为没有道理，不经济。
所以最后，我觉得 Agent 这个技术一定会越来越分化、越来越专业化。例如，未来会出现专攻特定行业的“金融 Agent”，或专攻特定任务的“测试 Agent”、“重构 Agent”。更进一步，我们甚至需要为这些 Agent 建立一套管理机制，比如如何注册、如何考核 KPI、如何调解它们之间的任务冲突。
不仅仅是 Agent 会专业化，我们使用的开发语言也会进一步专业化。从模式上讲，Vibe Coding 和 Spec Coding 都是一个抽象层次提升的过程。就像原来我们用汇编，后来用高级语言。下一步骤一定是自然语言编程，我可以用一个相对更灵活的自然语言，不需要关心那么多技术细节。
就像今天你写 C++，不会去看汇编代码。可能万分之一的场景，你可能会去看一下汇编代码，解决一个非常难的问题。但大多数时候你会忘记汇编那一层。所以可能五年、十年之后，也不排除三年之后，我们会说我用自然语言就可以了，不需要看生成的 JavaScript、Java，因为那一层JS、Java就成了新的汇编，我们不需要关心了。
实际上我们是面临一次抽象层次的提升，抽象到自然语言。但到这个级别你会发现，还是会出现新的东西，我们叫 DSL（领域特定语言）。因为没有道理一直用一个通用的自然语言。我一定会到某一个点发现，既然都在做 ERP，那为什么不发明一个专用于 ERP 的自然语言描述框架？所以从道理上讲，它一定会进入一个熵减的模式，我不需要用一个纯自然语言。
我会用一个更特定于这个领域的描述方式，配合特定领域的 Agent，来更精确、更准确地干好这件事。所以这一定会走向一个分化的过程：我们的描述会分化，我们的 Agent 也会分化，逐渐形成更专业化的生产线。我觉得这是大概率会发生的事情，只是这个过程大家要有耐心，不是一蹴而就的。在这个过程中如果过分着急，就会导致动作变形，会付出很多成本和时间。所以我觉得这是我们看到的误区，大家有点过分着急。
王启隆：我觉得吴博从逻辑上解释了为什么不会有通用 Agent，最终在实际生产中还是会分化成不同的专用 Agent。甚至于我们最基本的聊天机器人（Chatbot），它可能也不是纯自然语言，而是专门用于对话的、日常口语化的语言。这个观点很精彩。
“要把 Agent 当成员工去管理”
王启隆：您刚刚有提到您创立的爱捷软件（Agilean），在 AI 时代之前，它是如何发挥在软件工程上的作用的？AI 带来的变革之后，它又是如何调整自身定位的？面对现在国内那么多客户都想要智能化、AI 化转型，您和您的团队为他们解决的核心问题，和三五年前相比，发生了哪些根本变化？
吴穹：我们这一套 Adapt 的方法论，包括我们做的事情，可以总结为“人、事、流、数”四件事情。
“人”其实延伸到组织，就是用什么样的组织形态最合理。我们一直都说，生产力会推动生产关系的变革，但生产关系决定了生产力能否有效发挥。所以我们一直在做的事情就是理顺生产关系。原来很多是科层制的、职能化的组织。我们现在在帮助很多组织做敏捷转型，建立这些面向交付的敏捷团队。
我们最近举的一个例子，跟国家的军事改革很像，叫“兵种主建，战区主战”。因为现在大多数知识工作者都需要跨职能协作，单一职能是做不了事的。但我们很多管理会偏向于按职能管理，职能线管理是一个常见的管理结构。我们现在做的大多数事，就是在职能线上叠加交付型组织，也就是所谓的“战区”，用这样一套组织结构，让它交付得更快、更好。这块是我们这几年在做的事情，就是建立组织。
建立组织之后，第二步就是“事”。要让组织干活，就要明确它干什么。“事”可以认为是一个指令体系。最上层的组织收到客户的一个要求，然后我要把它拆解成几个指令发给不同的组织，有人要做交付，有人要做能力建设。
我希望有一个指令拆解的过程。这个指令拆解的过程就是我们说的“事”，我们把它叫任务体系。相当于我的组织体系建好后，要用任务体系把它落实。
有了任务体系之后，再下面就是“流”，有点像流程，或者我们现在更多地叫价值流。这件事分多少个状态？每个状态由谁负责？这就又回到了把事和人连起来，让事去找人。这个事到了这个阶段应该是谁负责，把这个工艺落实下来。有了“人、事、流”之后，我们就会产生很多“数”——有关人的数、有关事的数、有关流的数，我们可以更好地管理整个组织。这就是我们这么多年在干的事，即如何从这几个角度优化，让一个组织能够更高效地运作。
AI 来了之后，我最近看到一个截图，好像是阿里的 CTO 或 CIO 说的，他说要把 Agent 当人去管理。这也是我们一直以来的核心观点：我们未来认为组织会是所谓的 1+N 的组织，即由“1 位人类小队长”带领“N 个 AI 特工”协同工作。
因为马上大家要解决一个问题：今年大概是大家对 AI 最狂热的一年，明年怀疑就开始出来了。我们投了很多钱，也做了很多事，为什么没取得效果？因为让组织使用先进生产力这件事从来就不容易。有一个核心问题大家都在回避：员工为什么要用这个生产力？这个员工我真的用 AI 提升了 50%，那他是多干一倍的活呢？
还是把这个时间用于摸鱼？你怎么激励他把 AI 省下的时间真正用于做更多的事？这是一个生产关系问题，不是生产力问题。AI 有没有这个生产力是现在大家关心的问题。但实际上这个观察忘了一个点：就算它有这个能力，你的员工是会把这个能力给公司做贡献，还是用来早点下班？
你会注意到 AI 工具宣传中的一个悖论：它既被包装成给老板的“提效神器”，又被宣传为给员工的“摸鱼神器”。但这两者本质上是矛盾的，如果它对员工真是摸鱼神器，那在老板那儿就不可能是提效神器。
王启隆：经常有这样的广告。
吴穹：但这其实是矛盾的。如果这个东西对员工是摸鱼神器，在老板那儿它就不会是提效神器。如果对老板是提效神器，它就不会是摸鱼神器。所以现在大家只是在宣传上决定谁买单，你买单我就跟你说这个，他买单我就跟他说那个。但实际上……
王启隆：这个矛盾一直存在。
吴穹：这是一个非常深刻的变化：怎么让组织拥抱 AI？这件事情不容易，不是说你给了工具他就会用。
任何事情我们会有 1% 的尝鲜者、10% 的早期采纳者，他们愿意用 AI，但很多人属于那种“行吧、可以、还好了”的态度。所以让组织拥抱 AI 是一个系统工程，很不容易。
所以我们最近的一个想法是，未来要把 Agent 当成员工。当 Agent 成为员工之后，这个 1+N 里的“1”，任何一个人都是一个小队长或班长。那组织就要看这个班的效能。比如说未来一个人能带 5 个 Agent，那个人说他能带 50 个。公司觉得谁的效能更好？那肯定是带 50 个的效能更好。当然，这是建立在假设 Agent 的产量是一致的。
所以未来的考核体系、组织结构都会发生变化，来适应一个新的模式。原来我们是以人为工作中心的，未来可能是以 Agent 为工作中心。人的角色变成了带领 Agent 去工作。你的效能就不是你产出了多少，而是你带领了多少 Agent 产出了多少。这样的一套组织体系会更有利于发挥 AI 的价值。我们觉得未来整个方法论也会演进，这是一个非常重要的演进：我们怎么让组织在 AI 来临之后还能高效运作？这个地方会有非常多的创新需要做。
王启隆：您刚刚提到假设 Agent 的效能一致，这是基于什么样的假设？因为目前我们看到，AI 的表现依旧取决于我们给的上下文和提示词。可能有的人用 AI 比较厉害，他可以让一个 Agent 发挥出十个的效能。
吴穹：未来我们觉得整体的趋势是，短期之内最关键的不是让 AI 在一件通用任务上打 90 分，而是让它在一件简单的事情上打 99 分。在任务标准化、模型与提示词均被锁定的前提下，从统计上说，这些 Agent 的效能就相当于基本一致了。
为什么？因为通用的 90 分，总有 10% 的尾巴要人来收。这个收尾成本非常高，就像在软件工程的软件复用领域有一个原则：如果你复用时需要改 10% 的代码，成本基本上就跟重写差不多。
别觉得 AI 帮你干了 90% 你就赚了，修正那 10% 可能让你白忙一场。更别说只帮你干 50% 了，那很可能反而是生产力陷阱。
所以，下一步的重点就是让 AI 找到那些它能干到 99% 甚至 100% 的任务，让更多的小任务可以全自动完成。
那人做什么呢？就是进入“planning mode”：先把任务拆出来，确认每个小任务是对的，再分给其他的小 Agent 去做。然后，这些小 Agent 就可以日夜不停地把这些事做完。
这时候体现的就是你这个人的本事，因为你分任务分得好。人跟人的差距就出来了：
分得好的人，可以拆出很多小任务让 AI 自动执行，利用自己的睡觉时间，更高并发地完成事情。
如果分得不好，AI 做完了你还要改，最后你还是在干很多 review 的事情。
这就是为什么我们认为，未来更倾向于人类带领很多小 Agent 去工作。那时候，你的绩效，就是看你带的那些 Agent 干得好不好。
“AI 最重要的就是准确的数据，先把语言拉齐”
王启隆：我们再延伸聊一聊 AI 时代的 Agilean。您沉淀多年的 Adapt 方法论，其中一个核心理念是在谈效率和改进之前，先统一组织的管理信息架构，也就是把大家对需求、任务这些概念的理解先拉齐。在今天这个追求快的时代，为什么这种听起来有点慢的、先统一语言的工作反而变得更加重要了？
吴穹：因为现在大家都知道，AI 最重要的是数据，是准确的数据。我们现在在很多组织的大多数问题是，如果真正要做到智能化的软件开发，数据缺乏是非常严重的。
在很多组织里面，一个最基本的问题就是：到底什么是需求？什么是项目？我说的需求和你说的项目是不是一个东西？很多组织把任何一个需求都叫项目。在很多组织里，语言非常贫乏，所以什么都叫项目。然后就是 A 类项目、B 类项目、C 类项目，还有的组织叫“需求类项目”、“项目类需求”，各种奇奇怪怪的排列组合。
因为大家没有经过这个过程。我们在给别人做系统时，可能还做一点架构设计，做一点领域驱动设计（DDD）。但在我们自己的 IT 管理系统里，基本上大家都不做领域驱动设计。这样，你的概念就是混乱的，数据一定是混乱的，这时候 AI 就无从学习，无从智慧。所以反而要回到第一步：当你真正要开始重新构建一个线上化、数字化的研发管理系统时，反而需要把最基本的概念模型搞清楚。这就是我们说的管理信息架构。
王启隆：像 Adapt 框架，除了我们熟悉的研发角色，还扩展到 PMO、财务这样的角色。为什么一场成功的数字化转型，必须把这些看似外围的职能部门也深度卷入进来？他们能带来哪些研发部门自身不具备的关键价值？
吴穹：是这样，我们认为未来所有组织都会是科技型组织，这个趋势已经越来越明显。未来如果一个组织没有科技能力，很难想象它有竞争力。任何一个组织都是业务和科技的深度融合，科技能力都会成为每个组织必不可少的 DNA，同时也会成为一个巨大的成本中心。对组织来讲，科技的成本会成为一个非常大的部分。
这时候我们都会面临投资决策：我要做什么，不做什么？做了这个东西到底有什么收益？所以研发过程，就不仅仅是开发测试这个过程。从规划到立项，到中间不断调整投资决策，再到事后复盘，整个组织管理都要跟科技体系打通。我可以从 CFO 的视角看研发，可以从人力资源的角度看研发。这不仅仅是科技团队自己的管理问题，而是科技和周边的整个公司治理都需要打通。
这也是我们在 Adapt 里试图解决的问题。当然这个比较复杂，还在探索的路上。但我们觉得科技团队不能孤立地谈自己的管理问题，因为最后所有的管理都还是为整个公司治理服务的。
你只要把这条线打通，最后才能有效地管好开发团队。否则，开发团队也会受到公司其他部门的挑战和制约。
既不是定制开发，也不是盒装软件
王启隆：我们刚刚聊了 Adapt 方法论。顺着这个话题，聊一聊具体的工具。您有了 Adapt 这套管理思想之后，您的团队打造了“知微”这个工具平台。您曾将它比作一个科技组织的“财务系统”，那它具体是如何将您在 Adapt 方法论中的那些理念，比如分层的需求体系、多维的组织架构，变成一个管理者看得懂、用得上的数字化工具的？
吴穹：刚才我们聊了很多博大策略，已经充分体会到每个组织的差异性非常大。我们谈了组织结构，可以看到每个组织在每个阶段的组织结构都有它的道理。你很难说这就是最好的。每个组织在不同规模、不同阶段，都会采用不同的组织结构，所以我们认为组织是柔性的。
其实在大公司都待过的人知道，组织重组（re-org）是每年都会发生的。这并非是简单地否定过去、肯定现在，而是为了适应当前阶段的需要。今年的架构适用于今年的挑战，明年则可能需要另一套方案。
所以我们认为组织应该是柔性的。这种柔性也体现在企业的“管理信息架构”上，它往往是历史路径依赖的结果。比如，同一个概念，在这家公司叫“需求”，在那家叫“产品需求”，在另一家又可能叫“业务需求”。哪个最合理？其实没有定论，只要内部统一、沟通成本最低，它就是有效的。因此，每个公司的管理信息架构不仅各不相同，而且是动态变化的——今天加一层，明天减一层。流程和角色同样如此。
我们在咨询中发现，尽管管理原理相通，但具体到每个组织的“人、事、流、数”（人员、事务、流程、数据）时，却千差万别。这就导致了大多数标准化盒装软件无法满足企业的实际需要。客户买来软件后，往往会发现这里不匹配、那里不适用，最后只能削足适履，因为软件本身是固化的。
现在业界基本上就两种实践。一种是我找一帮人来定制开发，严格按照我的想法来做。这种实践，我们也看到它大概率的最后结果。因为厂商没有任何管理经验，你说什么我就干什么，你说的不对我也照着做，因为我也不知道对不对。所以很多这种定制开发型的管理系统，可能一开始用的时候大家就会觉得不好用，就不断乱改，改到三五年改不动了就推倒重来。这是一种情况。
另外一种就是买盒装软件。虽然不适合我的需求，但我对付着用。但这样很多时候落地效果也不好。
所以我们做知微的理想，就是把它打造成一个可配置的零代码平台。它就像一件‘高级定制’的西装，既有成熟的方法论支撑，又能真正根据你的情况量体裁衣，而不是生硬的定制开发或僵化的盒装软件。简单来说，知微是一款能深度嵌入客户现有流程、可灵活配置的柔性研发管理平台。
“AI 加速技术债？用好了，技术债反而会减少”
王启隆：知微是根据已知情况去解决问题。那面对未知问题呢？比如今年行业热议的新词“AI 加速的技术债”。以前就有技术债的问题，但 AI 在提升效率的同时，也用更快的速度制造了更多隐形风险。知微这样的平台，能不能帮助管理者看穿这些 AI 带来的表面效率提升，提前发现这些新型的管理风险？
吴穹：没有 AI，你的技术债也在累积。只不过有了 AI，如果管理不好，它累积的速度会更快。
其实还是用传统的度量体系，我们可以从交付效率、交付速度、缺陷修复时间、上线修复时间、代码重复度等各种各样的方面，去感知质量情况。AI 来了之后，你只是要去更加小心，因为它产出代码的速度更快了。如果你过分强调某个指标，因为原来还是手写代码，这个恶化的速度是有限的。如果你过分强调效率或者代码行数等指标，那他用 AI 生产低质代码时，技术债的累积会更快。
这是一个我们需要小心的副作用。但这并非是 AI 自身的问题，而是我们如何引导和协作的问题。事实上，如果使用得当，AI 反而能帮助我们减少技术债。
王启隆：有没有什么 AI 时代诞生的新问题？
吴穹：我们现在看到的 AI 时代的新问题，通过观察，更多是由于领导过分激进的绩效目标，导致大家热议“氛围编程”（Vibe Coding）。你会看到业界有几种观点，其实都对。有人说，作为一个程序员，如果你抵抗氛围编程，早晚会被淘汰。这个是对的，但是要放在五年、十年的范围来看。一个程序员肯定要不断去尝试，我跟 AI 协作的边界在哪里？AI 一定可以帮我提效，同时它不能增加我的质量问题，它应该帮我减少技术债。
前一段时间我尝试用 AI 编码时，发现现在 AI 做单元测试的能力已经非常强，所以你可以让它帮你生成很多单元测试代码。因为开发人员原来就不愿意写单测，这确实像健身一样，是一件正确但不容易坚持的事情，是一个额外的成本。
现在你让 AI 帮你写单测，对 AI 来讲是个自闭环。你写完的代码，你自己写的单测都跑不过，这个事交代不过去。所以对 AI 来讲，这是一个初步的自闭环。一旦 AI 把这个跑过了，我前一段时间自己写代码的时候，它的单测我是不看的。只有当它绕进去了，绕了几个循环都繞不出来，我可能会看一看，为什么你自己写的代码，自己写的单测过不了？
大多数时候，现在单测是可以自闭环的。它的作用是什么呢？这些非常高效的单测，变成了一些我们在工业生产里叫“夹具”的东西。比如你这个东西要这么高，每次生产完我拿夹具一测，它就一定是这么高。下次你这个零件如果高了，那个夹具就测不过去。那我们会发现什么？如果它改到了不该改的代码，我一看这个单测怎么会报错呢？这个单测不应该报错。我都不管你改得对不对，首先你就不应该改到这个代码。这就像我在代码库里布了很多铃铛一样，只要哪个地方被改到了，它的铃铛一响，我就会判断：不应该改到这儿。
那我就知道一定出了问题。所以，和 AI 的有效协作其实可以帮我们减少技术债。而且 AI 的算法能力、具体的代码编写能力其实还是不错的，肯定比我们中游或初级程序员写得好。所以用好了 AI，技术债反而会减少，按理说是这样。
王启隆：那大公司也用 Vibe Coding 吗？目前 Vibe Coding 还是在很多个人开发者那里，可能是玩票性质的。比如用 Vibe Coding 写个原型（Prototype），但实际代码还是自己编。那大公司，我们刚才也谈到，他们有很多庞大的、需要维护的老项目。这种情况下，对您服务的这些大企业、大公司来说，氛围编程的作用大吗？
吴穹：我们尝试定义一下什么是氛围编程。因为大家对这个定义都不一样。我的定义是，它实际上是一个抽象层级的提升。让我忘记 Java、JavaScript，在一个更高的抽象层面上，我只要给它指令，说我想要一个什么，我想在这个地方加一个什么，我可以不关心细节。
所以回到我们一开始谈的话题，当我在一个绿地项目里，相对容易做这个事情。我最近的实验就是绿地项目。
但一旦你生成了代码，当你在改第二个动作时，它其实就不是绿地项目了。只不过它是一个技术债稍微小一点，上下文丢失稍微小一点的项目。但实际上我最近在做实验的时候发现，为了真正保持这种氛围编程，你的开发模式就会出现变化。不是像以前大家习惯的，我把代码写出来就好了，其实不是的。
所以，我们可以将“氛围编程”理解为两个层次。
在原型探索或概念验证阶段，它可以是纯粹的自然语言“动嘴”编程，让我们忘记底层代码细节，快速实现想法。
但要将其应用于真正可持续交付的严肃项目中，就必须进入第二阶段，即“动嘴+动手+动测试”的模式。你必须在生成代码的同时，产出完整的文档、设计决策和测试用例，以确保上下文的完整性，避免后续的维护灾难。
因为现在很多大家展示的例子都是一下子就完成一件事，只有第一步，到了第二步的效果就会打折扣。所以到底怎么做这件事，在大公司里我觉得会更难，会面临前面说的上下文缺失问题。如果你真的把抽象层次完全提高到不看代码，我觉得会更有难度。
“知微会逐渐中台化，大模型也是它的用户”
王启隆：我们把话题回到知微这个工具。在 AI 和 AI Agent 越来越普及的趋势下，知微这样的管理工具最终的形态会是什么样？它会成为人类管理者指挥“1+N”模式的核心入口吗？
吴穹：我们觉得知微这种工具未来会逐渐中台化。未来我们已经在做 API 的能力。
首先，我们一直认为 IDE 会是一个主入口。现在我们会发现，像 IDE、CLI 这种开发人员常用的方式会成为主流，未来界面会越来越少。因为界面严格来讲是当我们需要精确控制时才去做的事情，它需要人做很多具体的选择。
当 AI 能力提升，它不光改善我们的编程，也会改善我们的工具使用。很多时候我不需要自己再去选很多东西，它可以根据我的工作上下文知道我刚才干了什么，然后来帮我做很多事情。
所以未来像知微这种工具，大模型也是它的用户。大模型可以直接调用它去更新一些信息。包括 Agent，未来人可以通过大模型用它，Agent 可能就直接用 API 接口来应用它。它会更多地变成一个数据管理的后台。这些后台数据累积进去之后，又会变成大模型的一些输入，大模型可以用它来做预警、预测、推荐。
所以未来它会更像一个组织的“流程资产中心”。这个组织整个加工的过程都在里面记录下来。未来我可以问它，我之前有没有做过类似的需求？之前类似的需求是谁做的？
做了多久？类似这些信息你都可以从它里面拿到结果。所以界面还会有，偶尔你还是会看一下，但更多场景你是通过大模型、通过 IDE 去跟它打交道，它来做数据的累计。
王启隆：很多像您一样经验丰富的技术专家都提到，AI 的出现重新点燃了他们对技术的热情。我记得 2023 年 ChatGPT 刚出来的时候，《敏捷宣言》的发起人 Kent Beck 好像说过一句很经典的话，叫 AI 取代了我 90% 的技能，然后放大了剩下的 10%。在行业深耕近 30 年后，当前 AI 浪潮中最让您个人感到兴奋或出乎意料的一点是什么？它是否改变了您对软件工程这门手艺的原有看法？
吴穹：这次 AI 的变革，说大一点，可以认为它颠覆了原来的冯·诺依曼架构。原来我们是 CPU，后来是 GPU。GPU 也是一种相对确定性的计算。
那么 LLM（大语言模型）来了，我们可以将它理解为一种全新的“概率引擎”。和传统 CPU 的确定性计算（确定的输入一定产生确定的输出）不同，LLM 在收到指令和上下文后，会给出一个基于概率的、最合理的结果。正是这种从唯一正确到合理可能的特性， 极大地拓展了我们软件的能力边界。
这个变化会引起两方面的变革：我们以前所有的软件形态都被颠覆了。因为原来所有的软件形态都是基于确定性输入、产生确定性输出的场景。但很多时候，比如我让你给我写一个旅游攻略，我需要确定性输出吗？不是这样的。
王启隆：可以是图文的、纯文字的，甚至是视频的。
吴穹：你想，我找五个旅行规划师，他们会给我五个不一样的攻略，我还希望它们不一样。如果五个人给我五个一样的攻略，我反而觉得不对了。所以在很多时候，人类要的东西是不确定的。
那原来是怎么解决的呢？原来是一个人找了一个顾问，顾问利用工具收集了很多确定性的信息，然后由他把不确定性的结果提供给你，这里面有一个人工的过程。现在大模型把中间的人去掉了，它代替了你的旅行顾问，用 API 收集确定性的信息，然后根据它的偏好和知识，给了你一个每次不一样的旅行攻略。这时候你觉得挺好，因为大差不差就行，只是个参考。
所以可以认为，原来我们的边界在这儿，我们的软件是在服务那个旅行顾问。现在我们往前推了，有了大模型之后，我们的软件直接服务用户了。用户给我一个模糊的输入，我可以给他一个模糊的输出。所以软件的边界和形态已经发生变化。
想象一下整个软件开发过程。当我们的加工目标变了，生产工艺也一定会变。
举个例子，原来我测试一个网站，就是看搜机票能不能搜出来，搜火车票能不能搜出来。现在怎么测？一个大模型给了一份攻略，我怎么测这份攻略是不是满足要求？
你可以想象，软件的边界发生了巨大变化：它从一个确定性的软件，变成了一个能给出不确定结果的软件。
因此，我们的测试过程、整个质量过程都变了。类似的事情，其实在推荐算法出现时就已经变得有些不确定，但大模型是把这件事推得更远了。因为推荐算法在软件行业的应用范围还比较少，但大模型来了之后，应用范围会广得多。
所以我们觉得，整个行业我们做的事情、做事的方法，全都会被颠覆。这就是你说的那个兴奋的点。因为每一次这种巨大变革，都意味着巨大的挑战和机会。我们之所以兴奋，就是因为这对程序员来讲又是一个黄金时代——所有的东西都会被推倒重来，乱世出英雄。
对年轻工程师的建议：“1+N”模式下的新能力
王启隆：回到之前聊到的，您说未来可能是一个专家带多个 AI Agent 的“1+N”模式。如果这是未来趋势，那它对今天成千上万的年轻工程师的职业发展意味着什么？企业又该如何调整自己的人才培养体系？包括您的团队顾问，以前要懂管理、懂敏捷，那现在是不是要更懂 AI？新时代的人需要掌握什么样的新能力？
吴穹：关于“1+N”模式对人才的影响，我们最近的观点有了一些变化。
之前我们判断，未来组织会有点像“钻石型”，即少数资深员工带着很多 Agent，初级成员会越来越少。但现在我们觉得未必，因为之前没太考虑成本因素。如果考虑到成本，一个被 AI 武装的年轻人，会快速追平中层程序员的能力。最近我听到很多 CTO 讲，原来培训一个人需要 6 到 12 个月，现在一个热爱学习的年轻人，在 AI 的帮助下可能三个月就很成熟了，而且他们更愿意主动拥抱新时代的生产力。
所以，未来一个非常重要的能力，就是对 AI 的了解和沟通协同能力。
你要把 AI 在某种程度上当成一个人，学会怎么跟它有效沟通，而不是说一句话它不懂，你就懒得理它了。你反而要不断去想：它为什么会迷茫？为什么听不懂我的话？我怎么能跟它协同得更好？这对人的沟通能力、同理心和对 AI 的理解都提出了更高的要求。
因为 AI 不会主动告诉你它的局限，它只会给一个答案。所以当它做得不对时，你要能反思：我是不是少说了什么？或者有什么上下文是它看不到的？这样你才知道怎么给它更好的提示词。
这对年轻程序员来讲，反而是一个红利。一方面，他们可以更快地在组织内赶上来；另一方面，AI 对“一人公司”也更友好了，因为整个公司的结构都会受到 AI 的挑战。
未来，人与人之间的生产率差异会变得更大。我们原来常说，优秀的软件工程师是普通人的十倍，未来可能就是百倍的差距。这时传统的雇佣关系就面临一个问题：就算这个人有 100 倍的能力，你愿意给他 100 倍的钱吗？大多数组织是做不到的。
但如果你自己变成一家公司，这事就容易了。作为百倍效率的工程师，你可以把成本压得很低，按单计价。大公司可能会发现，把工作外包给你比自己养人还便宜。
这背后挑战的是“公司的最佳组织形式”。按照科斯原理，公司的存在是因为交易成本。以前把事外包给你，签合同、定价都很复杂，成本高。但未来 AI 来了，公司之间的交易成本可能会大幅下降，这就会促使更多工作被外包给高产能的个人或小团队。原来大公司的结构可能也会因此发生变化。
所以，在这个新时代，无论是新程序员、老程序员还是管理者，你都必须去拥抱 AI。因为它绝对是一个现象级的大事件，是一次会颠覆我们整个行业和社会的巨大变革。
敏捷已死？不，AI 时代更需回归其本源
王启隆：谈到公司的本质需要重新思考，公司的结构会产生变化，那这对我们上个时代经常聊的“敏捷”会不会也带来影响？这种科技与业务部门协作关系的改变，会不会最终实现您多年倡导的两者真正无缝融合的“业务敏捷”？还是说，会像某些业界大佬说的那样，敏捷已死？
吴穹：我们先回到第一性原理：什么是敏捷？敏捷最开始呼唤的是按照符合软件本质的管理方式去管理软件，它其实是一次回归。它反抗的是按照工业化的、确定性的方式（就像管建筑一样）去管软件。它最开始的本源是说：你不能那么管我，因为我和盖楼不一样。
王启隆：之前我，我记得这个故事最开始其实是程序员和产品经理的“战争”。
吴穹：或者和项目经理。所以它严格来讲是一个对合理管理的呼喊，问题在于，后来敏捷这件事被异化了，很多组织把它搞得形式化、玄学化。所以不是敏捷已死，而是“这个经被念歪了”。
回到敏捷组织的本质——它就是一个面向业务、快速交付、灵活调整的组织。在 AI 时代，你更需要这样的组织。
我们最近就在思考，AI 时代可能都不能再按照传统的职能去划分部门了。传统时代，职能是强组织架构，交付反而是弱组织架构，我们希望“兵种主建，战区主战”。这套逻辑在稳定时代是可行的，但现在，连“兵种”本身都在变。
举个例子，过去我们有前端开发部和后端开发部。前端觉得后端不懂自己的专业，后端也觉得前端不专业，互相之间存在“鄙视链”。在这种结构下，当 CTO 想推行“全栈”时，就会遇到巨大的组织阻力。
所以在 AI 时代，我们反而可能要按照“交付线”去组织——我不管你们是什么职能，你们的目标就是把业务给我干好。当然，组织也需要稳定性，可以按系统来维持。但核心是要弱化职能，因为在这个时代，职能的边界正在快速消失。如果我们过度强化它，反而会减慢组织拥抱新事物的速度。
这正是我们想强调的：AI 时代来了，你的组织、角色、流程、制度，所有这些东西，都需要去做适配性的变革。
“我懂但可以不关心，和你压根不懂，是两码事”
王启隆：我们刚刚谈到敏捷的回归。从更宏观的视角看，您认为 AI 正在如何重塑软件工程这门手艺本身？是让它更趋近于一门可以被精确计算的科学，还是在解放了重复劳动后，让它回归艺术性的、更有创造力的本源？
吴穹：从道理上讲，为什么现在 AI 能提效？因为我们在软件开发过程中已经开始重复了。原来我们是 Don't Repeat Yourself (DRY)，现在大家开始 Repeat Myself，做的很多东西其实是 CRUD，开始重复。所以从道理上讲，引入 AI 之后，确实能够解放我们的重复劳动。每一次抽象层次的提升，都让我们更加不关注细节，更加宏观。
所以在产品经理和程序员的战争中，虽然现在大家都比较看好产品经理，但我持不同观点。
我看好有企业家精神或产品思维的高级程序员或架构师。
为什么呢？这有点像老生常谈，是文科生学理容易，还是理科生学文容易？在相当长的一段时间里，我可以不关心那些技术细节，但在需要的时候，我有能力去关心。
因为 AI 把我的注意力解放出来了，所以我可以多关心业务、产品和用户。但在 1% 的场景下，我可以去帮 AI 搞定那个代码。但如果我是个产品经理，你就不具备深入底层的能力。很多时候，我能够不关心那些细节，原因在于我懂那些细节。我懂，但是可以不关心，和你压根不懂，那是两码事。
因为我怎么写提示词、怎么给上下文，都取决于我知道“干活的那个人”需要什么。如果你不知道，你大概率只能说第一句话：“给我弄个网站”。等它出来了，你再说第二句话，想在这个网站上改什么，你就挂了。
我反而觉得，纯粹的产品经理角色在未来会面临更大的挑战。 因为有能力的程序员，在被 AI Agent 解放了大量编码工作后，是能够向上兼容去做产品经理的事的。但反过来，如果完全不懂技术细节，很多时候就难以做出最精准的判断。 我懂，但是可以不关心，和你压根不懂，那是两码事。
你看业界的实际案例，马斯克、扎克伯格、比尔·盖茨都是有编程能力的程序员，他们最终成为了顶尖的产品缔造者。 这说明，具备技术底色，对于理解和创造产品有着根本性的优势。
他们做成了产品经理。真正只懂产品、不懂技术细节的，我觉得还是很难成功。因为很多时候你不了解背后的具体原理，就很难做成一件事。
王启隆：对于这些渴望在 AI 时代有所作为的程序员，您有哪些建议？
吴穹：对程序员来说，一定要放下对 AI 的戒备和抵制。因为它从某种程度上影响了程序员的身份认同：我就是写程序的，结果你把我写程序的事干了。但你要这么想，原来你是种地的，现在你变地主了，你应该很高兴才对。拖拉机来了，你是恨拖拉机抢了你种地的事，还是应该用拖拉机变成一个农场主？所以这是一个心理角色的转换，我觉得这是第一点。
我现在看到很多程序员还是会嗤之以鼻，觉得“这也不可能”。那我觉得你就会死得很惨。因为趋势肯定是他能做到，只是一个过程，在这个过程中你要学会怎么跟它共舞。
所以这是一个心理角色的转换，我觉得这是第一点。而正是这种看似“危险”的身份颠覆，恰恰开启了前所未有的机遇。我们之所以兴奋，就是因为这对程序员来讲又是一个黄金时代——所有的东西都会被推倒重来，乱世出英雄。
第二，在这个时代，因为你要跟 AI 协作，你就要跟 AI 沟通。原来程序员的工作，是跟机器沟通就够了，不用跟人沟通。跟机器沟通的技巧会掩盖跟人沟通能力的不足。大家都知道程序员很难沟通，但以后你没这个借口了。所以与人沟通、与团队协作的能力，是未来非常重要的一个技能，需要补强。
第三是对业务的理解。我觉得这是一个非常好的时代。程序员不要因为 AI 抢了你的编程工作而悲伤，而应该认为你现在可以拥有一个程序员大军，而且你又掌握了跟他们合作的密码，你可以干更大的事，应该为此欢欣鼓舞。
程序员现在创业比以前更容易了。所以要保持市场的敏感度、热情和观察。因为所有的软件都会被重构，你可以想象这是一个什么级别的商机。而且我们又是全球少数掌握这种技能的人。所以，拥抱和享受这个时代，这是我对程序员的建议。
终极图景：我们将迎来“黑灯的软件工厂”
王启隆：在软件工程领域深耕三十余载，您最希望留下的思想和成就是什么？
吴穹：我们一直以来面临的是一个独特的科技组织管理问题，这也是我一直在研究的领域。所以我希望能够留下的是，关于科技组织到底怎么有效管理的答案。这是我一直研究的领域，也希望能够在这方面有所建树。
像德鲁克，他研究过科技组织的管理，但他毕竟年代比较早，自己经历的科技组织比较少，所以他更多是从理论上觉得科技组织要这么管，但缺少实操。我觉得我们的好处是，这些年我们一直跟科技组织在一起，又比较了解中国的现状。所以我们希望能够为中国打造一套适合我们的科技组织管理方法论。
同时现在 AI 来了，又要加一个新因素，就是适合 AI 时代下科技组织的管理方法论。因为原来我们是管理人，现在我们要管理人和 Agent。Agent 对我们来讲也是一个管理对象，所以整个管理方法论也会出现巨大变化。
王启隆：最后一个轻松点的问题。我们今天聊了很多 3 到 5 年或是 5 到 10 年的变革。那么再往后，更遥远的未来，如果用一句话来描绘您心中 AI 软件工程的终极图景，会是一个什么样的、可能会比较科幻的画面呢？
吴穹：现在大家也都在试图探索软件的未来。前几天我看到有同学写了一个“未来软件是用后即弃”的观点。但我觉得有挑战，因为软件很重要的一个使命是产生数据。如果你是个计算型的 function，可以是用后即弃的。但如果你产生了数据，你的目标就不是用后即弃了，你要持续存在。
但整体来讲，大家一直在讨论程序员到底会不会失业的问题。大家一直在思考，未来 AI 来了，是不是就自动编码了，程序员这个职业就消失了？大家经常会拿翻译和程序员来做比喻。但我一直觉得这个判断是有问题的。
软件不会被用后即弃，因为它是管理数据的，它会有很长的生命周期。当软件一旦存在长生命周期，就会不可避免地形成很多领域知识。一旦形成了这些领域知识，就会有人知道怎么在这个领域里更有效地工作。我们想象一下，现在工业自动化已经做了这么长时间，我们确实有很多黑灯工厂，但我们的制造业都消失了吗？没有。我们的制造业在研究什么？怎么建生产线、调试生产线、布置生产线，怎么样让生产线效率更高。
所以不用太担心这个问题。我们面临的未来，实际上是一些“黑灯的软件工厂”。可能不是用人去写代码，而是用 Agent 写代码、写文档、做测试。但人在此基础上，去指挥、规划，产生更多价值。再看一个例子，半导体（Semiconductor）。这也是个高度自动化的生产，现在还有没有人自己去焊二极管？这个工作已经被完全自动化了。
但是我们整个半导体行业没有未来吗？人家赚得盆满钵满，最有未来了。所以我觉得，我们没法预测，就像半导体行业预测不到今天他们搭了个台子，AI 涌现出来了。我们也预测不到当软件生产效率十倍、百倍提升之后我们会做什么。
这就像晶体管给我们带来了计算机，计算机带来了软件，软件带来了 AI。那软件生产力的极大提升会给我们带来什么？是不是星际旅行？是不是可控核聚变？是不是智能医药？有可能。我们原来因为软件供给不足，导致很多事情被 hold 住了。
你现在看不到所有的需求，是因为那些问题你还解决不了。但当你的软件成本下降到一定程度之后，就像人工智能算法，40 年没有变化，只是在 40 年后有了足够多的算力砸进去，这个算法就 OK 了。软件会不会也是这样？当我们有了足够的产能之后，就会去解决一些原来根本觉得解决不了的问题，从而产生新的需求。
所以我认为把软件行业和翻译行业对比是不科学的。软件这个行业它是存续的，会有独特的领域知识。而翻译，虽然在法律、文学等专业领域同样存在很高的壁垒，但在绝大多数通用场景下，处理的仍是公域知识。而软件，尤其是企业级软件，几乎天生就是私域知识的集合体，生命周期很长，这构成了本质区别。
但大多数翻译也是公域知识。而软件是一个长生命周期的东西，我个人更看重它会像制造业、像半导体行业一样。我们现在处于一个产能飞跃的前期，不用太担心产能飞跃之后就没有需求了。可能因为我们还有很多更高阶的问题等待解决，当你有了大量的软件生产能力之后，就有可能产生更多的需求。我更偏向这种乐观的看法。
王启隆：您这其实是相当于解释了 AI for Science 为什么现在如此值得期待。因为它的进展可能是涌现出来的，不可预测的。
方道配资官网提示：文章来自网络，不代表本站观点。
沪深京行情 实时轮播
热点资讯
