大家好，我是Tony Bai。
在 Copilot、Cursor、Claude Code等普及的这两年，编程似乎变得前所未有的轻松。
Tab 键一按，十行代码倾泻而出；回车一敲，整个函数自动补全；一个Prompt发出，一个项目的框架代码便完成了。那种多巴胺分泌的快感是真实的，效率提升的数据也是真实的。我们仿佛一夜之间都变成了“十倍工程师”。
但在这种虚幻的快感背后，一种隐秘的焦虑正在资深开发者群体中蔓延：离开 AI 提示词，你还能流畅地写出一个复杂的递归，或者手撸一个带有完整错误处理的 HTTP Client 吗？
最近，我在技术社区看到一段发人深省的论述，它像一盆冷水，浇在了在这个狂热的 AI 时代：
"AI is the fastest way to forget how to code and how to think."（AI 是让你忘掉如何编程、忘掉如何思考的最快方式。）
这句话听起来很刺耳，但很真实。
如果我们习惯了让 AI 替我们思考，我们的大脑正在经历一场无声的“认知肌肉萎缩”。在 AI 时代，写下每一行代码依然重要。这不是一种复古的情怀，而是关乎我们职业生存的“认知保留”。
警惕“GPS 效应”：你是在驾驶，还是在被运送？
心理学中有一个著名的“GPS 效应”：习惯了使用导航的人，海马体（负责空间记忆的脑区）活跃度会降低，久而久之，他们会逐渐丧失方向感，甚至在自家小区门口也会迷路。
编程也是一样。
学习和成长的本质，发生在“挣扎”的过程中。
当你为了设计一个类结构而绞尽脑汁，当你为了修复一个“竞态条件”而彻夜排查，你的大脑正在构建复杂的神经连接，正在建立对系统的“心智模型”。
如果你跳过了这个“挣扎”的过程，直接向 AI 索要答案：
AI 变成了“代笔者（Author）”：它替你构建了心智模型。
你变成了“消费者（Consumer）”：你只负责 Copy & Paste。
结果是：代码虽然跑通了，但你对系统组件之间的连接、潜在的边缘情况（Edge Cases）一无所知。你不再是代码的“作者”，你只是代码的“搬运工”。
一旦 AI 遇到它没见过的深水区，或者系统出现了一个隐蔽的 Bug，你会发现自己束手无策——因为你从未真正拥有过这段代码。
重构契约：把 AI 当做“磨刀石”，而非“枪手”
那么，我们要因噎废食，扔掉 AI 吗？当然不。
关键在于重构你与 AI 的协作契约。
核心原则只有一条：
Use AI as a Reviewer, a Rubber Duck, a Teacher. Not as an Author.（把它当作审查者、橡胶鸭、导师。绝不要把它当作代笔者。）
如果 AI 在替你思考，你在退步；如果 AI 在逼迫你思考得更深，你在进步。
以下是基于这个原则的 4 个深度思考工作流：
1. 解释意图，而非索要实现
不要直接丢一句“帮我写个鉴权中间件”。
试着这样做：你自己写出核心逻辑，然后对 AI 说：
“这是我写的鉴权逻辑。请解释我为什么在这里使用了 Context 传递用户信息？这种写法符合 Go 语言的惯用范式吗？有没有更好的风格？”
收益：强迫自己理清思路，利用 AI 验证你的设计直觉。
2. 索要权衡(trade off)，而非标准答案
不要问“在这个场景下我该用 Redis 还是 Memcached？”
试着这样做：
“我倾向于使用 Redis，因为我们需要持久化。但在这个高并发场景下，使用 Redis 会带来哪些潜在的性能瓶颈或运维风险？请列出 Trade-offs。”
收益：AI 不再是给你喂饭，而是在陪你进行架构评审。
3. 寻找盲区，挑战假设
当你写完一段代码，觉得完美无缺时，把它扔给 AI：
“这段代码在什么极端输入下会崩溃（Edge Cases）？我是否遗漏了某些并发安全问题？请像一个最挑剔的 Tech Lead 一样 Review 它。”
收益：利用 AI 广博的知识库，填补你的认知盲区。
4. 生成测试，而非生产代码
这是一个最高阶的玩法。你自己写业务代码，让 AI 写测试用例。
“这是我实现的订单状态机。请为它编写一套覆盖率 100% 的单元测试，特别是针对状态回滚的异常场景。”
收益：如果 AI 生成的测试跑通了，说明你的逻辑是自洽的；如果跑不通，或者 AI 根本理解不了你的代码，说明你没想清楚。
小结：不要温和地走进那个良夜
在 AI 时代，能够熟练调用 API 生成代码的人多如牛毛。
但能够独立构建复杂系统心智模型，并能驾驭 AI 进行深度架构推演的人，将变得极度稀缺。
Writing code matters.
写代码的过程，强迫你思考，强迫你大脑建立连接，强迫你理解系统是如何像齿轮一样咬合的。
请继续亲自写下那些核心的、关键的代码。
把 AI 当作你的磨刀石，让你的思维在与它的碰撞中变得更加锋利，而不是让它锈蚀你的大脑。
🎯 深度实战：构建“以人为本”的 AI 工作流
道理大家都懂，但在高压的项目交付期，我们很容易滑向“让 AI 全自动生成”的舒适区。
如何建立一套强制性的工作流，既利用 AI 的效率，又保留人类的深度思考？
如何在 Spec 文档中通过“伪代码”保留思考过程？
如何配置Claude Code，让它默认扮演 Reviewer 而不是 Coder？
如何利用SDD (Spec-Driven Development)迫使自己在 Coding 前先进行完整的思维推演？
如果你想掌握这套“不降智、反内卷”的高阶开发心法，欢迎关注我的极客时间专栏《AI原生开发工作流实战》。
在这个专栏里，我不教你如何偷懒，我教你如何进化。我们将一起探索，如何在 AI 的加持下，成为更强大的Software Engineer，而不是更快的Typist。
扫描下方卡片，开启你的认知升级之旅。
如果本文对你有所帮助，请帮忙点赞、推荐和转发！
点击下面标题，干货！
- 还在当“上下文搬运工”？我写了一门课，帮你重塑AI开发工作流
- 写作即思考：AI 时代，开发者为什么要警惕“思考外包”？
- Bug 激增 1.7 倍！AI 写代码：是速度的蜜糖，还是质量的砒霜？
- Go 的 AI 时代宣言：我们如何用“老”原则，解决“新”问题？
- 你的 Go 测试，还停留在“演员对台词”吗？
- 收藏级指南：Gopher AI入局路线图
- context：Go 语言的“天问”，你真的懂了吗？
