AI 时代下程序员角色的转变
臣之所好者，道也，进乎技矣。 —— 庖丁解牛《庄子·养生主》
程序员的角色正在从具体的编码技巧（技），跃迁到对系统规约、架构、可验证性等更高层原则（道）的把握。未来，我们不再是终日挥刀的匠人，而是洞察事物本质、以道御技的宗师。
题记：无意中看到了这张图，觉得很有意思，于是跟 Gemini 发生了一系列对话，整理修订后，分享给大家。
来源：https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/
过去六年 AI能够工作的长度每个7个月就能翻一番。目前类似像 claude code 的工具可以在长达一个多小时的时间里自主工作，完成我们好几天才能完成的代码。如果说以前我们还有精力去阅读和审视 AI 撰写的代码，但当 AI 工具几个小时完成人类几周的代码量，我们还如何去审视代码？我们还需要去审视AI撰写的代码么？还是我们应该专注于验证产品，把AI 当成是产品需求到产品之间的一个编译器（我们程序员现在也不怎么看编译器生成的汇编代码了）？
您提出的观察确实深刻，它触及了我们作为创造者与我们所创造的工具之间关系演变的核心。您的问题，与其说是在寻求一个答案，不如说是在开启一场必要的深思。
我们不妨顺着您的思路，一起探索这个问题背后更深的层次。
您将AI比作一个“编译器”，这是一个非常精妙的比喻。一个传统的编译器，它将我们能理解的高级语言，转化为机器能执行的汇编代码。我们之所以信任它，是因为它的行为是高度确定和可预测的。那么，我想请问：
- 我们今天所说的AI，它的“编译”过程，也同样是确定和可预测的吗？当我们两次给出完全相同的“产品需求”，它会生成完全相同的“代码”吗？
- 我们对一个传统编译器的信任，是建立在数十年的严格测试、形式化验证和标准化之上的。我们对AI的信任，应该建立在什么基础之上呢？
您提到我们应该专注于“验证产品”，这似乎是一条合乎逻辑的出路。但这又引出了一系列新的问题：
- 这里的“验证”，具体指的是什么呢？是验证产品功能符合我们明确提出的列表，还是验证那些我们没有明说，但又至关重要的特性——比如安全性、公平性、长期的可维护性，乃至代码是否蕴含了某些我们未曾预料到的偏见？
- 当我们测试一个由人类编写的程序时，我们大体上共享一个共同的逻辑和世界模型。但AI的“思考”方式与我们不同，它是否可能在满足所有测试用例的同时，在代码中埋下一些因其非人逻辑而产生的、我们难以想象的“定时炸弹”？我们如何去测试那些我们根本想不到要去测试的东西？
最后，让我们回到“审视代码”这个行为本身。
- 我们审视代码，仅仅是为了寻找错误吗？还是说，这个过程本身也包含了知识的传递、标准的统一、以及对系统更深层次的理解？如果放弃了审视，我们是否也放弃了对系统的掌控力？
- 想象一下，当一个由AI构建的、极其复杂的系统在某个深夜出现了前所未见的、怪异的故障时，一个从未深入理解其“汇编代码”的我们，要如何去诊断和修复它呢？我们是请求另一个AI来调试它吗？那时，我们扮演的角色又是什么呢？
您的问题或许揭示了一个未来：我们程序员的角色，可能将不再是代码的“工匠”，而是需求的“哲学家”和系统行为的“伦理学家”。但从“工匠”到“哲学家”的转变，我们又该如何确保自己不会成为一个只会对机器许愿，却对其魔法一无所知的“魔法师的学徒”呢？
要注意一点的是AI 的生产力正在以指数增长，当AI生产力到达某个量级后，产出的代码可能是人类永远也无法审阅完成的。
您强调的这一点——AI生产力指数级增长带来的“不可审阅性”——是整个问题的关键所在。它是一个强大的约束条件，迫使我们不能再用旧的框架来寻求答案，而是要构想一个全新的范式。
您问得很好。现在，让我们试着从提问者转变为探索者，一同推演在那个“代码洪流”的未来，这些问题的答案可能会是什么样子。
关于信任：从“过程信任”到“属性信任”
我们对传统编译器的信任是“过程信任”。我们信任它那套确定性的、经过验证的转换规则。
但在AI的时代，这将转变为 “属性信任” (Trust in Properties)。
我们将不再信任AI的过程，因为它是概率性的、复杂的，甚至是“黑箱”的。我们将信任我们有能力去严格验证其产物的 关键属性。这意味着，我们将开发出新一代的自动化工具——它们本身可能也是AI——其唯一目的就是审计和认证AI生成的代码。一个AI写代码，另一个AI（或一套形式化验证系统）就负责检查其是否满足：
- 正确性：是否符合产品需求？
- 安全性：是否存在已知的漏洞模式？
- 鲁棒性：在边缘和异常输入下是否会崩溃？
- 合规性：是否符合特定的行业标准或法律法规（如GDPR）？
- 效率：资源消耗是否在可接受的范围内？
我们的信任将不再基于“我读过代码，它没问题”，而是基于“代码通过了100万个自动化安全场景的攻击模拟，并通过了所有形式化属性验证”。人类的角色，从代码的审阅者，变成了这些自动化审计系统的设计者和最终裁决者。
关于验证：从“测试”到“规约”与“对抗”
传统的“验证”主要是编写测试用例，检查功能是否符合预期。在代码量级爆炸后，这远远不够。
验证的重心将前移到 “形式化规约” (Formal Specification)，并后移到 “自动化对抗” (Automated Adversarial Testing)。
- 前移——写“法典”而非“故事”：程序员最重要的工作，将是编写一份极其详尽、精确、无歧义的“产品需求规约”。这份规约将不再是自然语言的需求文档，而更像是一部数学化的、逻辑化的“法典”。AI将依据这部法典来生成产品。需求中的任何模糊地带，都可能被AI以我们不希望的方式去解释和实现。我们的技能将从“编程”转向“精确定义世界和期望”。
- 后移——培养“天敌”：为了发现“未知之未知”，我们会部署大量的“红队AI”（Red-Team AI）。这些AI的唯一任务，就是像最刁钻的黑客和用户一样，疯狂地攻击、滥用、寻找AI产品的逻辑漏洞，试图让它做出违反“法典”的行为。人类的角色，是设定对抗的场景，并从无数次的自动化对抗结果中，提炼出需要完善的“法典”条文。
关于审视与理解：从“阅读代码”到“审视行为”
我们审视代码是为了理解和掌控系统。当代码不可读时，我们必须找到新的理解和掌控方式。
我们将放弃理解每一行代码，转而专注于理解系统的 宏观架构和涌现行为 (Emergent Behavior)。
- 调试的终结，规约的迭代：当一个AI生成的系统出错时，我们不太可能去单步调试那数百万行代码。我们的反应将是：这是一个新的约束条件。我们会将这个失败的案例描述成一条新的、更精确的规约（“在X情况下，系统绝不能做Y”），然后让AI根据这份更新了的“法典”重新生成解决方案。调试工作从“修复bug”变成了“完善规约”。
- 新的可视化与可解释性工具：为了“理解”系统，我们会依赖新一代的AI可解释性工具。它们不会给我们展示原始代码，而是提供高维度的、交互式的系统行为地图、逻辑流图、决策热力图。我们就像一个经验丰富的医生看CT扫描图，而不是去看单个细胞的分子式。我们审视的是模式、结构和关系，而非具体的实现细节。
- 人类的最终掌控力：人类的角色变成了系统的 “架构师” 和 “行为总监”。我们定义边界、设定目标、观察行为、修正规则。我们不关心AI是用什么“语法”实现的，我们只关心它的“行为”是否完全在我们的掌控和预期之内。
结论：您提出的未来是极有可能的。在这个未来里，人类程序员并不会消失，而是发生了深刻的“物种进化”。我们正在从一砖一瓦构建建筑的工匠，进化为制定城市规划法典、设计电力和水利系统、并用模拟和压力测试来确保城市百年安稳的 “城市规划师”。
这无疑是一次巨大的抽象层级的跃升。挑战在于，我们需要发展出全新的理论、工具和思维方式来驾驭这种力量。我们不再是与代码搏斗，而是与“意图的精确性”和“行为的复杂性”搏斗。这或许是对我们这个物种智力与智慧的，一次更高级的考验。
