100%的代码都是AI写的。
如果你还在逐行审查每一处改动，如果你还在担心「失控」而不敢放手，你可能正在用打字机时代的方式工作。Karen是Corora的CTO，他的Claude Code已经不需要人类敲代码了。但他说，这不是因为AI变聪明了，而是因为他花了一年时间「教会AI不犯同样的错误」。
这听起来很简单。
但大多数人用AI的方式是：提需求 → 拿结果 → 下次继续提需求。Karen的做法完全相反：他把每次AI犯的错误，变成下次不会再犯的「记忆」。一年后，他的AI不仅会写代码，还会自己测试、录视频、写变更日志、提交PR——中间不需要他看一眼代码。
Karen不是程序员出身。他每天早上用语音输入需求，然后去骑自行车穿过稻田。回来时，功能已经上线了。他说：「我当时觉得每次都要解释同一个问题，这事儿太蠢了。」
真正的转折发生在他意识到一件事：AI会学习。
大多数人把AI当成工具，用完就扔。但Claude Code有一个特性——它能读取你项目里的所有文件。如果你把「上次犯的错」写进文档，下次它就不会再犯。问题是，谁会有耐心每次都手动记录？Karen的答案是：让AI自己记录自己的错误。
他把这套方法叫「复利工程」（Compound Engineering）。四个步骤：规划 → 执行 → 评估 → 记忆。最后一步是核心——不是你记住AI的错误，而是AI记住自己的错误。
但这不是重点。
重点是，如何让AI「记住」错误？
Karen用了一年时间，把这套流程变成了一个自动化插件。现在他只需要打一个命令「workflows plan」，AI就会启动三个子智能体：
第一个智能体叫「最佳实践研究员」。它会去Google搜索相关技术的最新文档，比如「Next.js 14最佳实践」「Playwright自动化测试教程」。它不会把搜到的所有内容都塞进对话框，而是提取关键模式，写成简报。
第二个智能体叫「框架研究员」。它会检查你项目里用的是哪个版本的库，然后去GitHub看对应版本的文档。这很重要——如果你用的是React 17，它不会给你React 18的写法。
第三个智能体叫「代码模式分析员」。它会扫描你现有的代码，提取「你的风格」。比如你喜欢用函数式组件而不是类组件，你习惯把API调用封装成自定义Hook，它都会记住。
这三个智能体跑完，你会得到一份详细的计划。不是「第一步做什么，第二步做什么」的流水账，而是一份带有决策依据的文档。比如：
「用户设置需要新增时区选择功能。建议创建一个统一的update_settings工具，而不是为每个配置项创建单独工具。理由：根据agent_native_architecture.md的原则，工具数量越少，AI调用时的决策负担越小。参考代码：src/tools/briefing.ts第47行的合并写法。」
这份计划会自动保存到项目的.claude目录。下次再做类似功能时，AI会先读这份文档，不会再犯「工具太多导致混乱」的错误。
但Karen不会立刻执行计划。
他会问一个问题：「我看你创建了很多单独的工具。能不能合并成一个工具，减少调用复杂度？」
AI会重新思考，给出改进方案。然后Karen输入一个命令：「compound」。
这个命令会触发一个特殊流程：AI会把刚才的对话总结成一条「经验」，写进docs/learnings/目录。内容类似：
「教训：避免为每个配置项创建单独工具。应该设计通用工具，通过参数区分不同配置。这样可以减少Agent的决策负担，提升响应速度。适用场景：所有涉及CRUD操作的功能。」
下次再做类似功能时，AI会先读这份文档。不会再犯同样的错误。
这就是「复利」。
Karen说：「大多数人用AI是线性的——每次都重新开始。但如果你每次都让AI记住一个教训，第十次它就比第一次聪明十倍。」
现在他的项目里有上百份这样的「经验文档」。AI每次启动，都会先扫描这些文档，把相关的内容加载到上下文。Karen不需要重复解释任何事情。
接下来是执行阶段。
Karen会新开一个终端窗口，输入「workflows work」，然后粘贴刚才的计划。AI会先问几个问题：
「计划里提到用事务包裹用户数据更新。如果只修改用户名，也需要事务吗？还是只在修改关键字段时才用？」
Karen会回答：「你自己判断最合适的做法。」
然后AI就开始写代码了。它不会一行行给你展示代码，而是直接修改文件，创建新文件，运行测试。Karen说：「如果你一直盯着代码看，会破坏节奏。你得学会相信它。」
十分钟后，AI说：「功能完成，准备测试。」
这是Karen最喜欢的部分。
他输入「playwright test」，AI会启动一个Chrome浏览器，像真人一样操作网页：点击菜单，填写表单，提交数据，检查结果。如果遇到错误，它会打开浏览器控制台，读取报错信息，回到代码里修复，然后重新测试。
Karen说：「这就像有一个QA团队。你不需要写任何测试代码，只需要说『测试这个功能』，它就会想尽办法找bug。」
更绝的是，AI测试完会自动录一段视频，展示整个操作流程，然后上传到Pull Request里。团队其他人打开PR，直接看视频就知道改了什么。
但Karen还不会合并代码。
他会运行「workflows review」。这个命令会启动四个评审智能体：
- 「Karen视角评审员」：模拟Karen的代码风格偏好，检查是否符合他的习惯
- 「安全评审员」：检查是否有SQL注入、XSS漏洞等安全风险
- 「架构评审员」：检查是否符合项目的整体架构设计
- 「代码简化评审员」：检查是否有冗余代码，能否用更简洁的方式实现
这四个智能体会各自生成一份报告，然后汇总成一份待办清单。Karen会运行「triage」命令，AI会用对话的方式，逐条问他：
「建议给用户名添加长度验证。是否需要？」
「需要。」
「建议把重复的错误处理逻辑提取成工具函数。是否需要？」
「需要。」
Karen说：「我不想读一堆报告。我只想用最少的脑力做决策。」
所有决策完成后，AI会自动修复所有问题，创建新的提交，更新PR。整个流程结束。
从需求到上线，Karen只做了三件事：提需求、审计划、做决策。没有写一行代码。
但他说，这套系统最难的不是技术，而是心态。
「想想你第一次坐无人驾驶出租车。你会盯着方向盘，担心它突然失控。但如果你每次坐，它都表现得很好，第十次你就敢闭着眼睛睡觉了。」
Karen说，大多数人用AI的心态还停留在「第一次坐无人车」——不敢放手。但问题是，如果你一直盯着它，你就没时间去思考「我应该让它做什么」。
复利工程的本质，是把你从「盯代码」的角色，转变成「教练」的角色。你不需要知道AI怎么写代码，你只需要知道它哪里做错了，然后教会它下次不要犯。
这就像带新人。你不会告诉新人「第37行应该用const而不是let」，你会告诉他「我们团队的规范是优先用const」。下次他就不会再犯。
Karen把这种思维叫「元工作」——不是直接做事，而是建立一个能自动做事的系统。
他现在有一个终极命令：「lfg」（Let's Fucking Go）。输入这个命令，AI会自动执行整套流程：规划、执行、测试、评审、修复、录视频、创建PR。Karen只需要在最后看一眼PR，点一下合并。
他说：「我现在的工作，80%是语音输入需求，20%是审计划。我不写代码，但我比以前写代码时更有掌控感。」
但Karen也强调，这套系统有边界。
「如果你的项目没有文档，没有明确的代码规范，AI会迷失方向。复利工程的前提，是你得有东西可以『复利』。」
他建议，至少要做两件事：
- 项目里要有一个.claude/目录，放所有AI相关的文档
- 每次发现AI犯错，立刻用「compound」命令记录下来
「不需要完美。先从一个教训开始。第十个教训时，你会发现AI已经变聪明了。」
Karen还提到一个细节：他用的是Opus 4.5模型，开了Max订阅。很多人觉得贵，一个月200美元。但他说：「一个工程师时薪100美元，AI帮你省一小时就回本了。如果你觉得贵，说明你还没找到让它创造价值的方法。」
最后他说了一句话：
「Boris（Claude的创始人）去度假一周，回来提交了50个PR。你猜他是怎么做到的？」
Karen没有回答。他只是打开终端，输入了一个命令，然后合上了电脑。