凌晨两点，Slack弹出消息。不是bug，是Claude Code（Anthropic推出的AI编程助手）告诉我迁移完成了——原本需要6人团队、3个冲刺周期的项目，我一个人，18天。
这不是炫技。我想聊的是：为什么大多数工程师用AI工具，只发挥了20%的功力。
问题不在工具，在"开箱即用"的思维惯性
作者的身份很有意思：资深软件工程经理，不是一线码农。这个细节决定了整个实验的走向。
他提出的概念叫"AI-first model"（AI优先模式）——不是"AI辅助开发"，而是把软件开发生命周期（SDLC）的每个阶段都塞进Claude Code的功能集里跑。听起来激进，但他说这恰恰是管理技能的平移。
「The skills that made me effective at leading engineering teams — providing clear context, delegating with specificity, reviewing rigorously, building repeatable processes — turned out to be exactly the skills that make Claude Code most effective.」
翻译一下：会带团队的人，天生就会"用"AI。而那些习惯手写代码的工程师，反而容易卡壳——他们的本能是"自己做"，而不是"搭系统、下指令"。
这让我想起一个残酷的对比：管理者多年不碰代码，看似是劣势；但在AI时代，这成了先发优势。他们早就被迫学会了"不亲自干活，但确保活干对"。
第一层地基：CLAUDE.md，你的项目记忆库
大多数人跳过这一步，直接开干。作者说这是"single highest-leverage thing"（单一最高杠杆配置）。
Claude Code每次启动会话都会读取CLAUDE.md文件。作者搭了一个多级继承体系：
• 根目录：架构全景、技术栈、核心设计原则
• 服务目录：服务边界、API契约、依赖关系
• 模块目录：实现细节、测试策略、常见陷阱
每一层继承父级。Claude Code打开任意仓库时，自动拿到完整的上下文栈——从最宏观的架构视角，到最具体的服务规范。
效果很直接：不用每次重新探索代码库，不用重复回答问过的问题，不会做出与架构矛盾的假设。免费、即时、复利增长。
这里有个反直觉的点：写这些文档的时间，被很多人视为"额外负担"。但作者算的是另一笔账——AI每次"重新理解"你的代码，消耗的是token（算力成本）和你的心力（注意力成本）。一次性写好，永久复用。
第二层：17个记忆文件，把纠错变成资产
Claude Code有持久化记忆系统——跨会话保留的文件。作者建了17个，按类型组织：
• 技术决策记录（为什么选这个方案）
• 反馈记忆（每次纠正AI的指令）
• 模式库（可复用的代码模板）
• 待办追踪（当前状态、阻塞项、下一步）
「The feedback memories are the most powerful.」作者特别强调。每次他纠正Claude——"不要amend commits，会破坏CI和MR审查"、"提交前必须修复所有测试失败，哪怕是看起来之前就有的"、"复制应用配置时不要覆盖现有值"——这些都被写进记忆文件。
下一次，同样的错误不会出现。
这本质上是在训练一个永不遗忘的实习生。人类团队需要反复叮嘱的事，AI只需要说一次。而且你可以精确控制"哪些经验值得保留"，不像人类员工离职时带走的是模糊的手感。
第三层：工作流设计，把AI塞进DevOps流水线
作者没有透露具体迁移了什么产品，但给出了规模感：涉及多个服务、数据库迁移、API重构、测试覆盖。典型的"需要协调会、排期、依赖管理"的麻烦项目。
他的解法是把Claude Code嵌入现有工具链：
• 用GitLab MR（合并请求）做代码审查节点，Claude生成描述和变更摘要
• 用CI/CD流水线做质量门禁，Claude负责修复失败测试
• 用结构化日志追踪决策过程，方便回溯"为什么当时这么选"
关键点：AI不是替代现有流程，而是压缩流程中的"等待时间"和"沟通损耗"。不需要等同事有空评审，不需要开会同步上下文，不需要解释"第三行为什么这样改"。
作者提到一个细节：他会让Claude先生成"planning artifact"（规划产物）——一份包含风险评估、回滚策略、验证清单的文档。这不是给AI看的，是给他自己看的。确保"让AI干"和"自己干"之间，有明确的验收标准。
第四层：人机分工的边界，比想象中更靠后
最颠覆的部分是作者对"AI能做什么"的判断。
他没有把AI限制在"写样板代码"或"补全函数"。整个迁移中，Claude负责：架构设计讨论、生成实现方案、编写生产代码、创建测试、调试失败、重构优化、文档更新。
人类保留的角色：目标设定、质量验收、异常处理、最终决策。
这个分工比例，和传统"AI辅助编程"的想象完全不同。不是"人写框架AI填细节"，而是"人定方向AI执行全程"，只在关键节点介入。
作者解释这背后的信任建立过程：从低风险任务开始，逐步验证AI在复杂场景的表现，积累成功案例后扩大授权范围。这和带新员工的逻辑一模一样——先给封闭问题，再给开放问题，最后给战略问题。
区别在于，AI的学习曲线是即时反馈的。你今天纠正的错误，明天就不会重现。人类员工需要几周才能建立的默契，AI用几个小时。
第五层：隐性成本的重新计算
作者没有回避这个模式的代价。
upfront成本（前期投入）很高：写CLAUDE.md、建记忆文件、设计工作流、调试AI行为。他估计第一周80%时间花在"配置"而非"编码"上。
但第二周开始，复利效应显现。同样的指令不需要重复，同样的错误不需要再纠，同样的模式可以复刻到下一个模块。
他算了一笔账：传统团队模式下，6个工程师3个冲刺（假设2周一冲刺），总人天是6×30=180人天。他的solo模式，18天完成，相当于压缩了90%的日历时间。
当然，这个对比有前提：项目类型适合单人深度工作，没有外部依赖阻塞，作者本人有完整的架构上下文。不是万能公式，但提供了一个重新评估"团队规模vs个体效率"的锚点。
为什么这事值得科技从业者认真看
作者的身份标签——"Senior Software Engineering Manager"——不是装饰。整个实验的底层假设是：管理技能在AI时代发生了价值重估。
具体技能映射：
• 提供清晰上下文 → 写CLAUDE.md和prompt
• 精确委派任务 → 设计AI工作流和验收标准
• 严格代码审查 → 反馈记忆和持续调优
• 建立可重复流程 → 配置继承体系和工具链
这些能力原本服务于"协调人类团队"，现在直接作用于"配置AI系统"。中间层的管理成本——沟通、同步、进度追踪——被压缩到接近零。
这对25-40岁的科技从业者意味着什么？
如果你还在一线写代码，可能需要刻意练习"不写代码"的能力——定义问题、拆解任务、验收结果。这不是退居二线，而是前置技能。
如果你已经在管理岗，优势在于你早已习惯"通过他人/他物完成工作"。AI只是新的"他物"，而且比人类员工更听话、更快反馈、不会离职。
作者最后埋了一个值得玩味的点：他说这种模式"不是关于Claude Code，而是关于orchestration"（编排）。工具会迭代，但"把复杂目标拆解为可执行单元、建立反馈闭环、持续优化系统"的能力，会越来越值钱。
换句话说，AI时代的核心竞争力，可能是"当一个好的甲方"——清楚自己要什么，能准确表达，会验收成果。这听起来像讽刺，但想想多少项目死在"需求不清、反复返工"上，就知道这技能有多稀缺。
至于那个凌晨两点的完成通知？作者没说有没有庆祝。我猜他设置了下一个CLAUDE.md，准备教AI怎么写项目复盘。
热门跟贴