“用 AI 写了一年多的代码，我成了一块庞大的高速缓存。现在才明白：机器负责效率，而我必须负责思考”

100 万奖池的AI Hackathon

去年七月，公司搞了一场AI Hackathon。

老板直接拿出 100 万做奖池。不搞虚头巴脑的培训，不喊口号，目的只有一个：让大家开始真正用 AI。

其实在这之前，团队对 AI 的态度一直很保守。2024 年就有同事自费买 Cursor 在内部做分享，当时大家尝试的方向很直接也很简单：用 AI 写 Flutter 或 SwiftUI 这种声明式 UI，或者修一些普通bug。效果确实不错，但一旦进入真实复杂业务，处理复杂逻辑，AI 就开始“顾此失彼”。

那时候我们得出的结论很一致：AI可以用，但只适合做简单的体力活。

对我来说，这场Hackathon是一个转折点。

拿奖不是终点，是“肌肉记忆”的开始

当时我们的赛题，是复刻市面上一个很火的 AI 星座产品。我们并没有去搞什么高深的大模型训练或者复杂的智能体（Agent）开发。我们的目的非常粗暴且纯粹：就是把 AI 当作全职码农，看看纯靠它写代码，到底能顶到什么程度。

为了完成这个目标，我们强迫自己改变了过去多年的开发习惯。大家不再是一上来就建工程、敲代码，而是开始学着怎么给 AI “喂资料”。

我们的工作流完全变了：把竞品应用的每一个页面一张张截图，对着截图整理出详细的需求文档，把里面的交互逻辑和数据流向梳理清楚。最后，把这些图文资料和逻辑说明打包，分步喂给 AI，让它直接吐出代码，最后再串联起整个流程。

从一开始的半信半疑，到最后靠着这种“压榨式”的模式拿到二等奖，我的固有认知被彻底刷新了：AI 编程的门槛，其实已经不在于你懂不懂某种语言，而在于你拆解业务、清晰表达需求的能力。

获奖后的分享会上，我也只强调了这一个认知。

但在当时获奖后的分享会上，我还没意识到，这种极速的产生爽感的背后，藏着怎样的隐患。

失控的“神笔”与思维的冲击

刚比完赛的那段时间，Claude 模型也迎来了重磅更新（Sonnet 4.6 / Opus 4.6 的 Plan 模式）。那种感觉，就像你手里突然多了一根神笔。

它不再是那种需要你逐行检查、来回缝补的辅助工具，而是实打实地交付了一个完整的结果。那种出活的速度，简直就是秒杀。

那种感觉很直接，已经不仅是兴奋，更是一种思维的冲击，甚至是时代的冲击。

但很快，“隐患”开始暴露了。

随着迭代的推进，当工程逐渐庞大、业务越来越复杂的时候，问题开始显现。由于缺乏系统层的全局约束，代码的逻辑脉络变得越来越模糊。你对项目代码也渐渐变成了黑盒。在这种失控的边缘，AI 甚至开始“胡作非为”了，改了这边的 Bug，悄悄把那边的逻辑带偏；为了加一个新特效，它可能会把你原本稳定运行的底层结构给重写掉。

这就好比你请了一个能力极强、但毫无边界感的天才来干活。他干得又快又好，但一不留神就把你家房子给拆了。

这也是为什么网上流传着那么多 AI 程序员的段子，大家在对话框里排名最多的：“你到底懂不懂啊”、“你根本没理解我的意思”、“你是不是傻X”……

转变思路：给这位“天才”造一个笼子

如果确信 AI 在复杂环境里会“乱改代码”，那解决办法绝不是因噎废食不用它，而是「限制它的破坏半径」。

顺着这个思路，我自然而然地想到了 iOS 开发里一项用了多年的老手艺：组件化。

以前，我们大费周章地把项目组件化，主要是为了解决人和工程的问题——拆分代码让模块更清晰，方便多团队协同、多 App 间的复用，或者是为了按模块独立编译回归、推动架构演进。

用 LocalPods 把模块物理拆开，过去只是一种大型工程结构上的常规优化。但现在，这件事突然被赋予了全新的时代意义：给 AI 做隔离。

规则很简单：拆得越细，职责越单一，AI 的理解成本越低，生成的代码也就越稳定。比如开发一个“知识问答模块”，每一层都可以单独剥离出来，打包交给 AI 去实现。

在实际的 iOS 工程实践中，我们完全可以利用 LocalPods 来构建这层物理隔离。将一个庞大的单体项目打散，通过 组件化 清晰地划分出目录边界，比如剥离出独立的网络层、存储层和 UI 层。每一层都是一个独立的、可被 AI 单独操作的“沙箱”。

有了这层物理隔离，最大的好处是兜底——至少能保证，就算 AI 把当前这个沙箱改得天翻地覆，也绝对不会误伤到工程里的其他代码。

这种顺应 AI 特性的架构思路，和最近去圈子里特别火的新范式 「Harness Engineering」有相似之处——我觉得译作‘驭卫工程’更合适，因为有驾驭和守卫的双重含义。它的核心理念其实极其朴实：AI 的下限取决于模型，但上限取决于约束。想要 AI 跑得稳，就得用代码为它配置好受控的运行环境。在未来的开发流中，这种“造笼子”的设计能力，甚至比模型本身的参数规模更重要。

中国开发者的“西天取经路”

给 AI 造一个完美的“笼子”，在工程上是一场硬仗。但讽刺的是，作为中国开发者，我们要面临的第一场硬仗，其实是怎么把这只“神兽”先请进门。

Claude 封禁中国区的严苛程度，懂的都懂。

这一年为了用上顶级的 Claude，感觉快把自己变成了一个“赛博黄牛”。

找海外朋友代付、折腾原生节点、防连坐封号……前前后后花了几千块，好不容易开通的号常常活不过两周。

官方路走不通，只能开始折腾各种第三方代理，比如 Cursor、反重力（Antigravity）等 IDE 插件。但真实的感受是：它们基本都不是纯血版。

目前很多第三方代理的 Claude Code 大多是逆向出来的，失去了很多官方原生的独有能力。

想要完整的体验，只能老实去调付费 API，但也是真的烧Token。

既然这么折腾，为什么不放弃claude？

因为用过绝对的生产力之后，你知道差距在哪，就再也回不去了。

在真实的开发场景里，特别是做复杂的工程拆解时，Opus 的思考模式（Plan Mode）绝对是目前地表最强的“架构师”。当你把需求扔给它，它能极快地理清模块边界，给出精准的拆分方案；而配上 Sonnet 原生 Subagent 的并发处理能力，那种多线程同时写代码的震撼，真的令人头皮发麻。

但 API 确实贵，地主家也没有余粮。经过无数次测试和踩坑，我摸索出了一套兼顾代码质量与钱包厚度的“混合编排”的最佳实践：

用 Opus 挂帅，主导架构决策和模块设计；用 Sonnet 作为 Subagent，根据 Opus 的规划，并行生成各个独立沙箱里的业务代码。

日常平替，写普通业务代码薅 Cursor/反重力的免费额度，或用 Codex 兜底；如果是接点简单的外包、写写过渡代码，国内的 Minimax、DeepSeek 其实也完全够用，绝对是高性价比的干活利器。

问了一年，我发现脑子里什么都没留下

那段时间，每天把这些工具用到起飞，觉得自己简直像个无情且高效的代码流水线厂长。

直到最近几天，有几次我打开电脑，想找之前跟 AI 碰撞出来的一个灵感或架构思路，结果找不到了。

不是文件丢了，而是我发现，我只留下了 AI 给我的“最终答案”，却丢掉了得出答案的过程。以前我们手写代码、死磕 Bug，虽然进度慢，但整个系统的脉络、上下文的拉扯，都会转化为一种只可意会不可言传的默会知识，深深长在脑子里。

但在面对 AI 时，那个专注推演的状态、那一瞬间闪过的直觉逻辑，因为缺乏了亲身咀嚼的阻力，再也无法形成记忆留存。我拿到了所有的显性结果，却丢失了最重要的默会直觉。

那一刻，我意识到一个很严肃的问题：我一直在高频地“用 AI 产出”，但没有一样东西真正内化成了我自己的护城河。

这一年里，我每天往对话框里扔进大量的 Prompt。我得到了完美的架构方案、稳健的代码片段、详尽的业务分析文档；甚至不再局限于“对话”，把 AI 嵌入了自动化工作流，搭建了专属的智能体（Agent），写了能自动抓取并深度解析外文的 Skill，构建了每日 AI 行业讯息的自动汇总链路。

看起来产出了极大的价值。不可否认，在跟着 AI 狂奔的这一年里，我的认知和眼界的的确确被大幅拓宽了。但每当深夜关上电脑，闭上眼睛复盘的时候，内心涌上的却是一阵深深的迷茫与空虚。

这种感觉，不再是原地踏步，而更像是把自己变成了一块庞大的高速缓存。

每天坐在电脑前，都在快速吞吐着大量的需求、精妙的逻辑和复杂的架构，大脑跟着高速运转。但这中间，偏偏缺少了一个“持久化”的过程。那些知识和灵感在我脑子里飞速流转了一圈，却没有真正写入我的“硬盘”。

没有笔记，没有归档，没有那种死磕到底后刻骨铭心的沉淀。我的认知被大模型的算力拖拽着狂奔，脚下却始终踩不到实地。这种没有“抓手”的悬浮感，让我感到莫名的恐慌。

工具在疯狂进化，而作为使用者的我，思维却在不知不觉中被“外包”了。如果在 AI 时代，我只是充当一个负责分发需求、搬运代码的“中间件”，那我随时可以被替换。我只是从一个传统的“敲代码打工人”，变成了一个更高级的“AI 操作员”，而不再是一个真正的“思考者”。

结语：机器负责效率，人负责思考

这种深深的“空心化”焦虑，让我不得不强行踩下刹车。

我跟 AI 深入沟通了一次，探讨自己到底该如何破局，普通开发者在这个生产力大爆炸时代到底该怎么破局。绕了一大圈，它给的解法一点也不高深，还是那句老话：输出倒逼输入。

AI 确实帮我省下了 80% 写代码的时间。但如果多出来的时间，只是让我去接更多的需求、填更多的坑，那效率再高又有什么用？我不该用来接着搬下一块砖。而应该把脑子里模糊的直觉，沉淀为带有个人印记的思考。

所以先迈出第一步，从写点东西开始。我要把折腾 AI 工具的踩坑记录、对架构的推演、工作和生活中的思考，一字一句地写下来。同时，我也开始重新捡起 GitHub 做开源，逼着自己坚持一个老码农该有的 KPI。

为了逼迫自己真正去思考，而不是再次陷入“一键生成”的陷阱，我做的第一件事，是给自己专门写了一个公众号协作写作的 Skill。

在这个工作流里，我明确剥夺了 AI “独立生成文章”的权力。它只能做个辅助提问和梳理结构的“编辑”，而我必须作为“作者”，提供最真实的经历、困惑和判断。因为我深知：没有真实细节的 AI 文章，读者一眼就能看穿；而那种默会知识的沉淀，只能来源于亲身经历。

在复盘这段时间经历的过程中，我慢慢想通了另一件事：AI 时代的自救，绝不仅仅是多写两篇文章那么简单，而是必须重塑自己的定位。

我必须从一个只负责分发需求、搬运代码的“操作员”，变成那个统筹全局、制定规则的“造笼人”。

AI 确实可以极快的吐出上百行完美无缺的代码，但真实的业务场景从来不是完美的。它没法替你去权衡利弊，更没法替你为最终的线上结果兜底。

折腾了一年多的 AI，花了不少钱，踩了无数坑，我学到的最重要的一课其实不是什么复杂的提示词工程、AI工作流，而是一句非常朴素的废话：

永远不要让工具的效率，掩盖了思想的懒惰。

以上，如果你也正在经历这种“高速缓存”式的焦虑，欢迎关注「张在想Oops」⭐。我会持续分享折腾 AI 的真实踩坑之路。