在一个AI编写3/4代码的时代，软件开发的核心正在从打字转向判断。一位产品经理的坦白。

我的朋友最近完成了五个项目。他没有写过一行代码。他认为自己仍然是一名开发者，但如果你问他具体做什么，他会犹豫。他和AI交谈，AI去整理思路、写PRD、写代码、测试、部署。他坐在那里，阅读AI的产出，偶尔点头，偶尔摇头，然后说出他的想法。他的角色从生产者变成了验收者。从敲击键盘的人，变成了对话的人。

这听起来像是未来，但未来已经在这里，安静得令人不安。

谷歌的新代码中有75%由AI生成。Meta希望到今年上半年让大部分工程师的大部分代码也做到这一点。整个行业在去年的一份调查中显示，97%的开发者已经在使用AI工具。所有这些数字都在讲述同一个故事：写代码这件事，正在变成一种可以由机器完成的工作。

但这不完全是关于代码的。

如果你观察一名开发者在2026年的一天，你会看到一种奇怪的新景象。她打开一个对话窗口，而不是代码编辑器。她写下：“我们需要一个用户注册功能，支持邮箱和手机号两种方式，要考虑到国际手机号的格式差异，以及GDPR的合规要求。”

AI回复了一段文字，不是一个确定的答案，而是一系列澄清问题：你对验证码的发送频率有什么限制？是否需要支持社交登录作为备选？我们现有的用户数据中，有多少来自欧盟？她回答了这些问题。AI生成了一份PRD。她审阅、提出修改建议。AI生成代码。

她几乎没有触碰键盘上的字母键，除了打出这些描述需求的句子。她的大多数时间花在阅读、思考和判断上。她不是在“编程”，她是在驾驭一个黑色的盒子，这个盒子比她拥有更快的打字速度和更完整的语法知识，但缺乏她的直觉和权衡能力。

这就像驾驶一艘现代轮船。船长不再直接转动舵轮，他给自动驾驶系统下达指令，系统执行。但船长仍然需要知道风向、洋流、航道和暗礁。

我是一名产品经理。这意味着在理论上，我从来就不是那个写代码的人。我的工作是找出正确的问题，而不是解决问题本身。但在AI时代之前，产品经理和开发者之间有一道清晰的墙：我描述我想要什么，他们告诉我技术上的可能性、成本和约束，然后我们交易。我负责“做什么”，他们负责“怎么做”。

那道墙正在消失。

现在，我打开一个AI窗口，描述一个功能。AI问我几个澄清问题。然后它告诉我技术上的可能性、成本和约束——基于它训练过程中吸收的无数个类似场景。它甚至给出预估的工作量和潜在风险。接着它开始写代码。我不再需要把需求文档交给另一个人类，等待评估和排期。整个过程压缩到一个对话界面里。

这听起来像是我取代了开发者。但事实恰恰相反：我变成了半个开发者。不是为了写代码，而是为了判断AI生成的代码。

我发现自己在学习新的技能：如何分辨一个OAuth 2.0实现是否正确，如何识别潜在的session fixation漏洞，如何评估一个NoSQL数据模型在规模增长后的性能表现。我不会写这些代码，但我需要能读它们，能看出它们哪里不对。

一个有趣的事情发生了：产品经理和开发者正在从两个人变成同一个人的两种技能。

纽约市一家大型金融公司的技术主管告诉我，他们最担心的事情不是AI写错代码——这种事情在代码审查中总能被发现——而是开发团队失去了对代码的“手感”。

“手感”是一种很难量化的东西。它来自于亲自敲代码的无数个小时：理解一段复杂的逻辑结构为什么会让人觉得“舒服”或“别扭”，知道什么时候应该把一个长函数拆成几个小函数，直觉上判断一个错误日志指向的问题根源。这不是可以写在规范里的知识，它存在于指尖和肌肉记忆中。

当AI承担了绝大多数编码工作时，这种手感正在退行。就像用自动对焦相机的人逐渐忘记了如何手动对焦，虽然你可能永远不需要手动对焦，但失去了那项技能意味着你对“图像为何清晰”这个问题的理解变浅了。

我的五个项目完成后，我发现一个令人不安的真相：我不确定自己是否还能从头写一个中等复杂度的程序。不是因为AI做不到——它当然能做到——而是因为我自己可能做不到了。我的大脑适应了新的工作模式：描述需求、审核产出、提出修改。它卸载了编码细节，就像计算器卸载了心算能力。

这是进步吗？当然是。但这也是有代价的进步。

产品的本质没有改变。用户不关心代码是谁写的，他们只关心软件能否解决他们的问题。从那个角度来说，一切都是老样子。

但从另一个角度来说，一切都在变化。当代码的生产变得廉价和高效时，什么变得稀缺？

答案是：判断。

在AI可以生成任意多种解决方案的世界里，从多个看似合理的方案中选择正确的一个，成为了最有价值的能力。这需要产品经理具备比以往任何时候都更深刻的技术理解力——不是为了自己写代码，而是为了判断AI写的代码是否足够好。

这还需要另一种更难培养的能力：知道什么时候该相信AI，什么时候该怀疑它。

在我的第二个项目中，AI生成了一个相当优雅的计费模块，正确处理了各种订阅场景和按比例退款的复杂计算。测试全部通过。代码风格无可挑剔。我差点就按下了确认。但一个微小的细节让我停下来：它在处理夏令时转换时的一个假设，虽然导致了所有测试通过——因为测试用例没有覆盖那个特定的时区组合——但在实际生产环境中可能会让某些跨国用户的账单出现错误。

AI没有做错什么。它基于常见的模式写了代码。但没有一个模式是完美的。没有人告诉它这个特殊要求。这个判断必须来自我。

这就是产品经理的新技能：在看见之前就想象出失败。

我的一名工程师朋友，仍坚持在AI辅助下亲手写每一行关键代码。他不是一个守旧的人，他每天使用codex来加速编码。但他拒绝让AI成为主要作者。“我需要知道每一行代码为什么在这里，”他说。“如果我失去了这个理解，我就不再是工程师，而是一个AI的接线员。”

我没有反驳他。因为在他的语境下，他是对的。他维护的是一个每天处理数千万美元交易的核心系统。一个微小的错误可能导致巨大的损失。在那个世界里，代码的可追溯性和完全理解是刚需。

但在我的五个项目中，语境不同。它们是在原型和MVP级别的产品，需要快速迭代和灵活试错。在这个语境下，AI的主导地位不仅是可行的，而且是最优解。我可以在一周内将一个想法变成可演示的软件，用户给我反馈，我再让AI修改。整个循环的速度前所未有。

这揭示了一个关键的分化：AI写代码的比例不应该是统一的一个数字，而应该取决于问题的性质和风险等级。低风险、高速度需要的场景，AI可以走到前面。高风险、要求绝对正确性的场景，人类仍应保有最终的控制。

我房间的墙上贴着一张我小时候的照片，大约八岁，弯着腰坐在一台苹果Ⅱ电脑前，手指悬在键盘上。那是我的第一行BASIC代码。我记得“10 PRINT ‘HELLO’”的魔力，记得我如何一遍又一遍地敲入那些行号，记得第一次让计算机按照我的命令行事时的惊叹。

三十年后，我仍然在“让计算机按照我的命令行事”。但命令的形式变了。我不再一行一行地打字，在一层又一层的抽象之上。我对着一个窗口说话，它理解我的意图，然后把意图变成代码。

那八岁的我会认为这是一个奇迹。今天的我只觉得这是工作日的开始。

但有时候，在项目交付的间隙，我会想起那些行号，想起手指在键盘上飞驰的感觉，想起在凌晨三点终于让一段代码工作时的狂喜。那些感受正在从日常工作中淡出，被另一类感受取代：设计出正确方案的满足感，成功预见潜在问题的警惕心，以及看到AI产出的成果与自己想象一致时的优雅确认。

这些都是不同的东西。说不上更好或更糟，只是不同。

也许这才是真正的变化：软件开发正在从一个手工艺变成一种策展活动。我们不再精心雕琢每一行代码，我们从AI生成的可能性中挑选和组合，然后放入我们的判断、责任和想象力。

那些八岁时学会的东西——逻辑、顺序、精确性、从错误中学习的耐心——仍然在这里。只是形式发生了变化。就像手写变成了打字，打字变成了对话。下一代的孩子们将从小学习如何与AI对话，而不是如何写代码。他们会觉得我们的浪漫怀旧有些古怪。

他们会是错的吗？不。只是我们注定成为那种总是谈论“过去的好时光”的人。这是一个古老的模式。

而现在，我可以告诉AI来为我写这篇评论的结语。但这一次，我选择自己敲下最后一个句号。