最近临时在帮朋友做一些外包，基本上代码都是 AI 写的，我想如果不是有 AI, 我大概不会帮这个忙，因为即使这些活不难，我还是要写很多代码。但现在，我可以一个人同时做 2-3 个项目。
在这个过程中，更加让我确定了对于程序员来说，软件开发的范式已经彻底彻底改变了。生成代码再也不是程序员「应该」做的事情，而是应该被放手给 AI 做的事。
这也让我对判断一个程序员的能力从代码能力转变成了使用 AI 的能力，我想，如果我现在要为团队招程序员，我会在面试时着重了解这个人如何使用 AI 完成一个需求。
对于程序员来说，「使用 AI 的能力」包含很多维度，这些维度综合起来，才决定 AI 是否真正能成为程序员的杠杆：
软件是为解决用户的需求而生的，对业务充分理解，才能给 AI 足够的业务场景上下文，才能让 AI 写出覆盖边界条件的代码。
对业务的理解同时决定了程序员是否可以做好数据库建模。在接我朋友的外包项目时，我发现我人工干预最多的就是数据库建模。只要我思考好建模，AI 就能基于这个数据库模型编写任何接口。
如果能让 AI 限定在特定的技术栈中，你会发现 AI 更能稳定发挥，更可控。让 AI 「带着镣铐跳舞」。无论用什么技术栈，重点都是给 AI 一条稳定的轨道。比如我在所有项目的 AGENT.md 中都会列出非常细节的选型，例如 CC Mate 的 https://github.com/djyde/ccmate/blob/main/CLAUDE.md
当 AI 知道技术栈后，通过 context7 这样的 MCP, 它能在生成代码时，找到对应的文档作为上下文，生成出更不容易出错的代码。换句话说，确定好技术栈，让 AI 成为这个技术栈的专家为你编写代码。
因此，在这个层面，程序员的「使用 AI 的能力」意味着，这个程序员知道什么样的场景适合什么样的技术栈，也侧面反映了这个程序员对技术社区是否保持敏锐的嗅觉。这是我认为 AI 时代程序员的一种硬实力。
在《代码之外》听友线下见面会中，有听友提问，在 vibe coding 的时候，AI 只能做些一次性的软件，多次迭代后就会变成灾难。我的回答是，这是因为没有给 AI 提供一个你设计好的工程架构，让他在这个架构中行动。在这个新的时代，程序员应该以架构师的角度来工作。
我在 AI coding 一个项目前，我的脑海里会大概有一个工程架构的设计，比如，通用工具应该被统一放到一个什么文件，前端页面应该如何组织，接口应该遵循什么样的规范，错误处理应该怎么做等等。只要架构设计好，写在 AGENT.md 中，AI 自然会按照你的设计去做，而不是让 AI 天马行空地发挥。
不仅是在启动这个项目前要做好架构的思考，在维护的过程中，你指挥 AI 完成一个新的需求时，就应该思考完成这个需求的时候，将会有什么代码被写在哪一个地方。这个场景也适合使用各个 AI coding agent 的 Plan Mode 来完成，当 AI 告诉你它将要如何行动时，适当二次确认它要如何组织新的代码。
做到以上三个理解，我相信程序员可以游刃有余地使用 AI. 但我曾经在很多场合接触一些在一线写代码的程序员，发现他们对 AI 的接受程度是如此地低。很大程度上，我认为是一个缺乏以上三个理解的程序员，很难对 AI 建立信任关系，合作关系。
和我合作的一位程序员，在共同完成一个需求的时候，我在他旁边观察了一下他如何使用 AI, 结果只是非常浅地使用 auto complete. 我问他，为什么不尝试让 AI 完整地完成这个需求，他表示他认为 AI 不能胜任这个任务。
我说：
满足了这两个条件，你只需要把接口文档给 AI, 然后告诉 AI 这次的需求，再告诉 AI 一点提示，大概是在哪个文件中修改。以现在旗舰模型的能力，AI 大概率能一次性完成。
他将信将疑，我直接在他电脑上给他演示这个操作，果然，AI 直接完美地完成了这个需求，不到 2 分钟。
而同时我也在思考，到底 AI 时代是否还需要程序员，或说需要怎样的程序员，好像渐渐有了答案。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。