Anthropic 这周给出一份不太舒服的判断：写代码已不再是软件研发的瓶颈。当 AI 把开发实现压缩到几小时，传统公司真正被卡住的，反而是为更慢节奏设计的审批、评审、合规流程。
值得关心的不是「AI 多会写代码」，而是一份实操手册：六个研发阶段（计划、设计、开发实现、测试、部署、维护）应如何系统性改造。我们读后认为，这是给企业管理者的提醒，不只是给程序员的工具书。
这是什么
传统软件研发被分成六个阶段，每阶段靠文档、工单、审批记录传递。它的隐含假设是「写代码最慢、最贵、最容易错」，所以围绕它设计了各种控制点。
AI 原生模式打破这一假设，做了三件事：
其一，每阶段结束时把对应产物（需求文档 intent.md、设计文档 spec.md、计划文档 plan.md）写入版本控制（即代码仓库），下一阶段直接读取启动，交接不再靠人催。
其二，AI 嵌入每个环节。计划由 Claude 汇总原始素材；测试以持续评估方式贯穿过程，不再是阶段边界的一次性检查；部署由多层智能体做专项审查。
其三，人的注意力被重新分配。AI 执行时由 hooks 机制（即自动化策略校验钩子）立即触发治理要求，人只需审核智能体标出的节点。
行业怎么看
手册在工程师圈里有较高认可。一位 AI 应用公司技术负责人告诉我们：「版本控制驱动的工作流、把意图作为机器可读产物写入仓库，这些我们内部早就在做，但没人系统整理过。」
反对意见同样存在。一位金融科技公司总架构师提出两点保留：手册默认企业有「成熟的产品负责人」能写出有判断力的意图文档 — 国内多数公司这种岗位极少，更多是项目经理转述需求；手册几乎没讨论受监管场景下 AI 的可解释性，监管问「为什么这段代码这样写」，AI 给不出审计级答案，这在金融、医疗等行业比手册讨论的更难。
更隐性风险是手册默认企业接受「代码产量暴涨」。一位头部互联网公司前安全负责人提醒，若安全人员配比不调整，AI 写代码越快，未经充分审查就上线的代码就越多。手册里其实也提到了，但没给企业配比如何重设的答案。
对普通人的影响
对企业 IT：如果公司已用 AI 写代码，第一件值得检查的不是 AI 能力，而是审批、会议、跨团队交接的节奏。这些流程按「人写代码」的速度校准过，AI 让产出翻倍时，这里会变成新瓶颈。
对个人职场：开发者的工作重心从「写」转向「定」。把意图、判断、约束写清楚，会比敲代码本身更值钱。手握产品决策权的人是受益方，纯执行者是需要提前准备的信号。
对消费市场：短期产品迭代会变快，但用户用的 App、企业内部系统，其研发流程大概率还没 AI 化 — 你作为用户感受到的更新节奏，不会跟 AI 写代码速度同步。