AI 编码重塑我思维的 9 种方式
了解 AI 辅助编码如何从 9 个方面重塑开发思维：集成测试、架构、模块，以及管理认知负荷的策略。
本页目录
几个月来，我一直让自己参与的所有软件 100% 由 AI 协助编写。 我曾在 Twitter 上分享过这件事，随后很多人要求了解更多细节。
大家一直在询问它改变我编码思维的九种方式。下面逐项拆解。
1. 花更多时间思考集成测试
今天早上就发生了这样的事。我在维护一个用于教学的 CLI 工具，并想让 AI 智能体帮忙更新。
我意识到测试主要依靠人工 QA。原因是它高度依赖 Git，所以我以为必须使用 GitHub 才能正确测试。
事实证明我错了，完全可以在本地测试。
我的做法是：
- 添加端到端测试套件，描述测试应覆盖的全部用户故事
- 构建创建临时 Git 环境的工具，让 AI 能正确测试一切
- AI 每次修改后自动运行完整测试套件
提高测试边界能捕获更多 bug，也能更安心地让 AI 智能体自动运行代码。
想继续深入： 加入“面向真正工程师的 AI 编码”候补名单
2. 通过 Pre-commit Hook、CI 和强类型制造摩擦非常有价值
反馈循环非常重要，它能让智能体获得真实世界中哪些有效、哪些无效的实际上下文。
AI 做出的每一项修改都应触发 pre-commit Hook、CI 和类型检查，让 bug 立即暴露。反馈越及时，智能体就越能作出好决策。
3. AI 没有 UI 品味——要极其激进地做原型
你经常能看到 AI 一次性生成漂亮 UI 的演示，但它不擅长迭代已有的 brownfield UI。
在确定 PRD 之前：
让 LLM 为 UI 修改提供五种不同方案，把它们放到一次性路由中进行查看；不要触碰真实代码，先迭代原型。确定喜欢的方案后，再让 AI 正式实现。
4. AI 没有软件架构品味
糟糕代码库有许多大接口的浅模块，优秀代码库则拥有少量简单接口的大模块。
深模块与浅模块：
- 深模块： 小接口，大量实现
- 浅模块： 大接口，少量实现
深模块对这套方法非常重要。它们更易测试，AI 也更容易处理，你不必理解每个实现细节。
5. 拥有简单接口的深灰盒模块才是王道
模块足够深时，就能轻松围绕边界测试，而不必担心内部实现。
把代码库拆成大模块，在边界处测试，然后把实现交给 AI。我称它们为“灰盒模块”，因为你可以查看内部，但原则上不需要这么做。只要在正确边界测试，就能忽略内部内容。
6. 使用 Effect.ts 进行依赖注入
Effect 有一个一等概念叫作 services ——封装应用中常见任务的可复用组件。
它们是拥有简单接口的复杂深模块。如果你使用 TypeScript 构建后端，我强烈推荐 Effect 。它让这种模式变得极其直接，对我使用 AI 智能体的工作帮助巨大。
7. 更多元编程
我一直在思考如何让智能体自动运行，也就是定义自己的流程，弄清楚自己究竟在做什么。
构建功能很简单：
- 添加测试
- 构建功能
- 运行测试和类型检查
- 提交
但其他事情呢？ Issue 分诊、清理待办、任务排序——这些都可以委派给 AI，或自动化其中的重复劳动，同时保留控制权。
8. 警惕文档腐化
很多人会在仓库中堆满 Markdown 文档。LLM 每次搜索内容时，都可能找到已经过时的文档。
最终就会出现“文档腐化”：代码库和文档发生偏离，LLM 不知道该相信哪一个。更好的方式是让 AI 在探索阶段自行生成文档，这些文档按需生成，不会过时。
9. 跟上变化需要更高的认知负荷
确实如此。但深灰盒模块让你可以信任测试，只做粗略查看而不必理解每个细节，因此能缓解负担。
这样做之后，我明显感到认知负荷降低了。我也基本不并行运行智能体，因为构建的内容不需要多个智能体并行。但如果同时运行四五个项目，情况可能会很棘手。
AI 就这样重塑了我的思维：更多思考测试、模块形状和自身流程，对文档保持怀疑，并降低认知负荷。
AI 编码如何重塑了你的思维？现在相比过去，你更关注什么？