夜雨聆风“ 这篇文章回答的问题： 当 agentic coding 成为工程团队的默认工作方式后，哪些原有流程会失效？应该用什么替代？
这篇文章应该回答但没回答的问题： 在 AI 生成了大量代码之后，技术债务的积累速度如何？初级工程师在没有"写代码"这个学习路径的情况下如何成长？有多少尝试类似转型的团队失败了、为什么失败？
一、核心论点：瓶颈会转移，但不会消失
这篇文章的作者（Claude Code 团队的工程负责人）讲了一个很朴素的道理：工程带宽曾经是构建应用最昂贵的部分。瀑布流、敏捷开发——所有这些流程都是围绕"写代码很贵"这个前提设计的。
现在 agentic coding 把"写代码"这个瓶颈打掉了，但瓶颈没有消失——它转移到了验证、代码审查和安全上。
“ We can all generate a lot of code really fast now, but this also brings up new questions: Is this code correct? How is it maintained?
我们现在都能很快生成大量代码，但这也带来了新问题：这些代码正确吗？怎么维护？
这句话是全文最诚实的部分。也是唯一值得认真对待的部分。
二、四个流程变革：Before → After
2.1 规划：六个月路线图 → Just-in-Time
旧做法：花大量时间做前置规划，因为编码时间很贵。 新做法：JIT 规划——先做原型，让内部用户用起来，然后根据反馈行动。
作者自己的经历：加入 Claude Code 团队时写了一份不错的六个月路线图，但三个月后就过时了——因为 Claude Code 本身让开发速度变了。
2.2 上下文获取：找作者问 → 先问 Claude
旧做法：有问题找写代码的人。 新做法：先问 Claude，因为现在 PR 都是 AI 辅助的，"谁写的"已经不重要了。更重要的是：你到底想知道什么？是回归的根因？客户问题的答案？还是某个决策的上下文？
附带一个好例子：作者以前每天早上手动总结客户反馈，现在让 Claude 自动在后台跑。
2.3 代码审查：全面人审 → 信任但验证
旧做法：人审一切。 新做法：Claude 处理风格、lint、bug 检测、测试。人只审需要专业判断的部分——法律审查、安全敏感代码、产品品味。
“ What you need humans for today might look different with the next model.
今天需要人做的事，下一个模型出来后可能就不一样了。
2.4 团队构成：固定角色 → 角色模糊化
PM 现在写代码了。工程师也做设计和内容了。
作者招聘时看重两个画像：
有产品感的创造者——好奇心强、热爱解决实际问题的 dreamers 深度系统专家——比如构建 Claude Code on the Web 需要的 systems 背景
不看重什么？原始吞吐量——模型已经处理了。
| Before | After | |
|---|---|---|
| 规划 | 六个月产品路线图 | Just-in-Time 规划：做原型，内部用户试用，根据反馈行动 |
| 上下文获取 | 找写代码的人问 | 先问 Claude，然后问能不能自动化 |
| 代码审查 | 人工审查一切 | Claude 处理风格、bug、测试；人审需要专业判断的部分 |
| 团队构成 | 固定角色：工程师写代码、PM 规划、设计师设计 | 角色模糊：PM 做原型，工程师做设计和内容。招有产品感的创造者和深度系统专家 |
三、三个核心原则（不可协商）
疯狂 dogfood 自己的产品：每个团队成员（含跨职能合作者）都用 Claude Code 和 Claude Cowork 尽可能保持团队扁平：经理先从 IC 做起，先学会在团队里有效地产出代码 毫不犹豫地砍掉不再有效的流程：团队成员有明确的授权去质疑和杀死旧流程
四、三个应该追踪的指标
Onboarding ramp time 下降：工程师/设计师/PM 多快能开始有效产出？现在工程师第一周就能 ship 真实代码 PR cycle time 下降：能帮你发现 CI/CD 管道在哪里跟不上代码生成速度 Claude-assisted commits 上升：在 Claude Code 团队，过去四个月里作者没见过非 Claude 辅助的 commit
“ 作者特意提醒：不要把吞吐量和成功混淆。吞吐量是一个指标，但真正的指标是你衡量你在解决什么问题。
五、压力测试：这篇文章没告诉你的
三个最致命的假设
假设一："编码不再是瓶颈" —— 这只在特定类型的工作上成立。新功能原型、well-defined 的任务确实如此。但对于遗留系统维护、复杂架构决策、性能关键路径上的优化，AI 辅助的效果远没有这么乐观。Claude Code 团队做的是自己的产品（CLI 工具 + Web 应用），属于 AI 最擅长的领域。
假设二："JIT 规划比路线图好" —— 这假设团队足够小、足够对齐。在更大的组织中，JIT 规划可能导致方向不清和资源浪费。Claude Code 团队能 JIT 是因为他们有清晰的使命和极强的执行力文化。这不是方法论的成功，是团队的成功。
假设三："角色模糊化是好事" —— PM 能写代码 ≠ PM 应该写代码。专才的深度在许多领域仍然不可替代。模糊化可能在短期内提高速度，但长期可能导致"什么都能做但什么都不精"的团队。
利益相关分析
这篇文章发表在 Anthropic 的官方博客上。作者的身份是 Claude Code 团队的工程负责人。每个案例都在说"用 Claude Code 让我们更好了"。这不是独立研究，是产品营销 + 真实经验的混合体。
沉默的证据：
有多少团队尝试了类似转型但失败了？失败的原因是什么？ AI 生成的代码带来的技术债务积累速度如何？半年后回头看代码库质量如何？ 初级工程师如何在没有"手写代码"这个学习路径的情况下建立专业能力？ 安全事故？AI 生成代码引入的漏洞？
六、真正值得拿走的东西
这篇文章最有价值的不是"用 Claude Code"，而是它揭示的一个结构性规律：当你的核心瓶颈被移除后，次级瓶颈会立刻上位。
编码快了 → 验证、审查、安全成为新瓶颈。这跟经济学里的李比希最小定律（Liebig's Law of the Minimum）一样：植物的生长不取决于总量最多的养分，而取决于最稀缺的那个。
所以真正的行动建议不是"去买 Claude Code"，而是：
画出你的工程流程瓶颈图，标注每个步骤的时间占比 找到当前最慢的那个环节——如果编码已经不慢了，那是什么在拖后腿？ 那个环节能不能被自动化？如果不能，为什么？ 作者的最后一条建议是全文最好的：找到你最吵闹（noisiest）的流程，问它是否还在服务于它的目的。如果不是，砍掉它或自动化它
“ I asked one simple question: 'Why are we having this meeting again?' And just that one question made everyone realize it wasn't needed. So we canceled it.
我只问了一个简单的问题：'我们为什么还要开这个会？'就这一个问题让所有人意识到它不需要了。所以我们取消了它。
苏格拉底对话
学生：Anthropic 说他们团队 PM 都能写代码了，这听起来很酷，但靠谱吗？
老师：关键不在 PM 能不能写代码，而在 Claude Code 降低了"写代码"这件事的门槛到什么程度。如果 PM 用 Claude Code 写的是原型和内部工具——这些对质量要求没那么高——那确实可以。但你要注意作者的措辞："PMs code a lot now"，而不是 "PMs ship production code now"。这里面的差距很大。
学生：JIT 规划真的比六个月路线图好吗？
老师：这取决于你的产品处于什么阶段。Claude Code 是一个快速迭代的产品，市场需求和技术都在变化，六个月路线图确实会过时。但如果你在做的是一个需要长期架构演进的基础设施项目——比如数据库内核、编译器——六个月甚至一年的架构规划仍然是必要的。问题不是"JIT 好不好"，而是"你的产品需要什么级别的可预测性"。
学生：作者说过去四个月没见过非 Claude 辅助的 commit，这个数据可信吗？
老师：在一个 dogfood 文化极强的团队里，这是完全可信的。但要注意 survivorship bias——这是一个 AI 公司的 AI 产品团队。他们的日常工作就是让 AI coding 更好。他们遇到的问题、他们的技术栈、他们的团队文化，都跟一般工程团队不一样。这个数据点有参考价值，但不能直接推而广之。
学生：那这篇文章对我最大的价值是什么？
老师：不是具体的工具或流程，而是那个结构性洞察：瓶颈会转移。你现在工作中的瓶颈是什么？是编码？是测试？是部署？是需求沟通？找到它，然后问：AI 能帮我解决这个瓶颈吗？如果能，解决之后下一个瓶颈会出现在哪里？提前准备。这才是这篇文章真正想说的。
个性化洞察
洞察 1："瓶颈转移"框架可以直接用到你的工作流设计里
为什么跟你有关：你日常用 Claude Code 做 coding agent。编码已经不慢了，那你的新瓶颈在哪？可能是：prompt engineering 的质量、验证 AI 输出的正确性、跨文件改动的协调。
你可以怎么做：识别出这些次级瓶颈，针对性优化。比如给 Claude 更好的项目上下文（CLAUDE.md）、建立自动化的验证流程、用 subagent 处理跨文件改动。
洞察 2："问 Claude 而不是问作者"——这个习惯你现在就能建立
为什么跟你有关：你做全栈开发和系统架构，经常需要理解不熟悉的代码库。
你可以怎么做：遇到代码问题时，先让 Claude 分析整个上下文（文件结构、调用链、git blame），再决定是否需要找人。这比直接问"这个谁写的"效率高得多。
洞察 3：三个追踪指标值得在你自己的工作里用
为什么跟你有关：你在做自己的 AI 产品和技术自媒体，工作流效率直接影响产出。
你可以怎么做：特别是 PR cycle time 和 AI-assisted commits 的比例。前者帮你发现 CI/CD 瓶颈，后者帮你衡量 AI 辅助的渗透率。
洞察 4：招聘画像的变化值得注意
为什么跟你有关：你在做 AI 产品，未来可能组建团队。
你可以怎么做："有产品感的创造者" + "深度系统专家" > "高吞吐量的码农"。未来的竞争力不在"能写多少代码"，而在"能定义什么问题"和"能理解多深的系统"。
洞察 5："砍掉不再有效的流程"需要制度化的勇气
为什么跟你有关：你在个人项目和工作流中积累了大量自动化流程，有些可能已经过时。
你可以怎么做：考虑建立一个定期的"流程审计"——每季度问一次：我们还在做的哪些事情已经不再服务于它的目的了？
