AI 未取代程序员，却重塑开发协作
老 A 拆局第二篇：
AI Coding 真正改变的，绝非仅仅是编写代码。
而是软件开发的职责划分。
距离上一期已过了许久，近期忙于差旅，感谢仍关注的朋友们。
这两年来，关于 AI Coding 的探讨极易陷入两个极端。
一种观点认为：
程序员即将被 AI 取代。
另一种观点认为：
AI 生成的代码质量平平，顶多算是高级自动补全。
我认为这两种看法都过于片面。
更贴近现实的演变是：
AI 将让“编写代码”的成本日益降低。
但会让“界定问题、规划流程、核实结果”的价值愈发凸显。
代码生成的速度必将加快。
但软件能否顺利交付。
能否便于维护。
能否实现长期迭代。
归根结底还是取决于工程能力。
AI Agent 对开发工作的辅助已显而易见。
它能协助阅读陌生代码，生成样板代码，解释报错信息，补充测试用例，分担部分重复性工作。
熟练开发者若善用 Claude、Cursor、Codex 等工具，效率提升是切实可感的。
但另一方面同样真实。
AI 能迅速输出一段“看似可运行”的代码。
但这代码未必优秀。
可能边界覆盖不全。
可能异常处理薄弱。
可能充斥着重复逻辑。
可能短期可用，长期却难以维护。
更棘手的是：
许多 AI Coding 应用仍停留在“个人提效”层面。
对于团队协作、工程规范、系统一致性的提升，还远显不足。
因此，问题不在于 AI 能否编写代码。
它当然可以。
真正的关键在于：
代码生成的速度，并不等同于软件交付的效率。
当代码愈发容易生成，真正稀缺的资源反而发生了转变。
需求阐述。
系统边界。
测试验证。
架构限制。
工程治理。
这些因素，开始变得愈发关键。
我将 AI Coding 大致划分为四个阶段。
第一阶段：外部知识库
最初大家如何使用？
将代码复制到 ChatGPT。
让其解释、修改或生成片段。
再粘贴回 IDE。
这种方式门槛较低。
但上下文存在割裂。
项目结构、依赖关系、历史约束，它未必知晓。
因此常出现：
看似回答不错。
一旦放入项目，却无法编译。
第二阶段：IDE 智能助手
随后出现了 Copilot、Cursor 等形态。
AI 融入开发环境。
能查看当前文件。
能补全代码。
能基于局部上下文进行修改。
此阶段已显著提升效率。
但它仍偏向“被动”。
你问一句，它答一句。
你让它改一处，它改一处。
它未必真正理解整个系统。
第三阶段：工作流智能体
再往后，不再是让 AI 修改某个文件。
而是赋予它一个任务：
读取项目。
规划步骤。
修改代码。
运行测试。
根据错误继续修复。
此阶段的关键，已非“模型是否会写代码”。
而在于你是否赋予它：
角色。
边界。
规则。
工具权限。
验证标准。
第四阶段：自主软件工程师
理想状态下，AI 可依据标准需求文档。
端到端完成开发、测试、修复及交付。
但现实是：
一句话需求远远不够。
真正能驱动 AI 自主开发的，并非灵感。
而是清晰的 PRD。
明确的验收标准。
稳定的技术约束。
可运行的测试样例。
完整的工程上下文。
因此你会发现：
AI Coding 越深入，越不像聊天。
越像一套工程系统。
过去，大量开发时间耗费在编码实现上。
需求沟通、设计、测试、验证、文档等环节常被压缩。
但若越来越多代码由 AI 生成，开发者的工作重心将发生转移。
程序员不再仅仅是代码生产者。
将逐渐演变为三种角色的混合体。
1. 意图定义者
将模糊需求拆解为 AI 能理解、能执行、能验证的任务。
切勿只说：
“帮我做个登录。”
而需明确：
支持哪些登录方式？
失败场景有哪些？
安全边界在哪里？
验收标准是什么？
2. 规范设计者
定义目录结构、接口约束、错误处理、测试标准及交付边界。
AI 可以编写代码。
但谁来告知它何为“好代码”？
谁来告知它哪些区域不可变动？
谁来告知它历史包袱所在？
这正是工程师的价值所在。
3. 流程编排者
让 AI 按步骤执行工作。
而非让其自由发挥。
先理解需求。
再编写测试。
再实现功能。
再运行验证。
再依据结果修复。
最后由人工进行设计审查。
这才是较为稳健的 AI Coding。
因此，我不认为 AI 会消灭程序员。
但它将改变一个问题：
过去比拼的是谁更擅长写代码。
未来比拼的是谁更擅长定义问题、约束 AI、验证结果。
过去许多团队不愿编写测试。
觉得耗时。
觉得麻烦。
觉得收益不明显。
但 AI Coding 将让测试重新变得重要。
原因很简单：
当代码由 AI 生成。
人类更需要稳定机制来判断其是否符合预期。
否则只能依赖人工肉眼审查大量代码。
效率低下。
且不可靠。
一个更稳健的流程应为：
先定义测试场景
再生成单元测试
让测试先行失败
再让 AI 编写实现
用测试结果驱动修复
最后由人审查结构与边界
这其实并非新概念。
它回归了软件工程基本功：
先定义正确性，再追求实现速度。
设计模式也将重新变得重要。
并非为了炫技。
而是为了隔离变化。
人类编写稳定框架。
AI 编写可替换实现。
接口、策略、适配、模板方法等，这些将重新焕发价值。
因为它们能将 AI 生成的代码限制在可控边界内。
换言之：
AI 时代并非不需要架构。
反而更需要架构。
当前许多 AI Coding 的问题，本质在于缺乏约束。
用户给出模糊需求。
AI 生成一堆过程式代码。
看似完成了功能。
实则边界不清、重复代码多、异常处理弱。
这类做法，我更愿称之为：
Vibe Coding。
凭感觉写。
凭感觉改。
凭感觉觉得“差不多了”。
它适合快速原型。
但不适合长期系统。
更成熟的方向，是 Agent Engineering。
即把 AI 视为可编排的工程执行者。
赋予其角色。
赋予其上下文。
赋予其输出格式。
赋予其测试标准。
赋予其工具权限。
同时也赋予其边界。
未来 AI Coding 的竞争，不仅是模型能力的竞争。
更是工作流、上下文、评测、权限、成本和稳定性的竞争。
这也是我开发开源项目 SDC - Spec-Driven Coding 的原因。
它旨在解决的问题很直接：
不让 AI Coding 停留在一句话需求后的自由发挥。
而是将开发过程收敛为可追溯的闭环：
spec -> plan -> tasks -> apply -> check -> archive
在 SDC 中，需求将被拆解为场景、规则和验收标准。
任务将被切分为可验证的薄切片。
执行过程中将保留设计、测试、审查及归档证据。
其目的并非为了让 AI 生成更多代码。
而是为了让 AI 在更清晰的边界内写得更稳健。
若你也正尝试将 AI Coding 从个人提效工具，升级为团队可复用、可验证、可沉淀的工程流程。
不妨关注此项目：
AI Coding 的下一阶段，比拼的不仅是模型。
而是谁能将模型稳定地接入真实工作流。
最后总结四句话：
🔹AI 写代码，不等于软件能交付
🔹代码生成越快，需求和验证越重要
🔹程序员不会消失，但价值会迁移
🔹真正稀缺的，是工程判断力
我是老 A。
今后，我们继续拆解。
若你觉得此文有价值，欢迎关注 + 星标「老 A 拆局」。
每周我们将共同拆解技术、AI、支付与管理的底层逻辑。
也欢迎转发给你身边正在使用 AI Coding 的朋友。