👀 最新、最有用的AI编程姿势，总来自「知识药丸」
《贾杰的AI编程秘籍》付费合集，共10篇，现已完结。30元交个朋友，学不到真东西找我退钱；）
以及我的墨问合集《100个思维碎片》，1块钱100篇，与你探讨一些有意思的话题（文末有订阅方式
写在前面
今天在Reddit上看到一篇神文。
作者用Claude Code在90天内写了50万行代码，然后把踩过的坑、总结的经验毫无保留地分享了出来。
我花了一个下午仔细研读，发现这些技巧不仅适用于Claude Code，对整个AI辅助编程都有启发。所以决定写篇学习笔记，用自己的理解把这些精华提炼出来。
有价值的东西，也分享给你。
Monorepo：上下文就是一切
第一条建议就把我震住了。
用Monorepo。
作者说这是最关键的。为什么？
因为Claude需要上下文。
你想啊，如果前端一个repo、后端一个repo、微服务又是一堆repo，Claude每次切换都要重新理解架构。这就像让一个人在三个房间之间跑来跑去找东西——效率低到爆炸。
但Monorepo不一样。
把同一个应用的所有代码放一起，Claude能一眼看到全局。前端调了什么API？后端返回什么数据？数据库Schema长啥样？全都在视野里。
这不是什么新鲜概念（Meta就是Monorepo），但应用到AI编程上，意义完全不同——上下文管理变成了头等大事。
当然，作者也提醒了：Monorepo是指"同一个应用的不同部分"。如果你有5个毫不相关的项目，该分还是得分。
模块化路由：给Claude画地图
第二个技巧更绝。
按功能拆分路由文件。
什么意思？就是别把所有API都塞在一个routes.py里，而是这样：
routes/ ├── app_routes.py # 应用相关 ├── workflow_routes.py # 工作流相关 ├── oauth_routes.py # 认证相关
为什么？
因为Claude需要明确的边界。
你告诉它"去workflow_routes.py里加个接口"，它就知道该动哪个文件。如果你只说"加个工作流接口"，它就得在几千行代码里猜位置——猜错了，代码污染；猜对了，也浪费时间。
这让我想起《代码大全》里的一句话：好的代码应该让人一眼看出"这段代码该在哪"。
对人是这样，对AI更是。
老技术栈：别追新
这条建议有点反直觉。
用React、FastAPI、Python这些老牌技术。
为什么不用最新最酷的框架？
作者的解释很简单：LLM训练数据里，这些技术的代码样本最多。
这意味着什么？
意味着Claude写React时就像老司机开车，闭着眼都不会出事故。但你让它写2023年才出的新框架？那就是新手上路，磕磕绊绊。
我自己试过。
让Claude写React组件，一次过。让它写某个小众框架的代码？改三遍。
所以结论是：在AI的世界里，稳定 > 新潮。
SKILL文件：操作手册的艺术
这个技巧最精妙。
作者创建了多个SKILL文件，每个文件教Claude如何实现一个"模块"。
比如implementing_handler.skill：
- • Handler文件放哪
- • 类怎么写
- • 在哪里注册
比如implementing_tests.skill：
- • 测试文件放哪
- • Mock怎么用
- • 覆盖哪些场景
这和普通的CLAUDE.md有什么区别？
粒度。
CLAUDE.md是全局说明书，SKILL文件是局部操作手册。就像宜家家具的总体安装指南和"第3步：拧这颗螺丝"的区别。
为什么需要这么细？
因为当代码高度模块化后，新增功能不只是写代码，还要在多个"注册点"把它串起来。
比如你加了个新的Socket事件处理器，得去：
- 1. 定义Pydantic类
- 2. 写事件处理逻辑
- 3. 在事件注册表里登记
如果不告诉Claude这些，它只会完成第2步，然后你的功能根本跑不起来。
SKILL文件就是把这些隐性知识显性化。
文件顶部注释：导航指南针
这招超简单。
每个文件顶部写一行注释说明功能。
# workflow_routes.py # 工作流相关的所有API路由
就这么简单。
但作用巨大。
Claude在新会话里打开项目，看到这些注释就知道该找哪个文件。否则它得挨个翻，浪费token、浪费时间。
这就像图书馆的索引卡片——没有的话你只能一本本翻书。
作者在CLAUDE.md里写了："每次创建文件都加顶部注释"。现在Claude养成习惯，自动就加。
习惯的力量。
MCP数据库访问：给Claude装双眼睛
这个功能有点黑科技。
给Claude配置MCP，让它能只读访问数据库。
什么意思？
就是Claude能自己跑SQL查数据。
比如API返回空数组，你怀疑是查询有问题。以前你得自己去数据库查，然后把结果贴给Claude。现在？Claude自己执行：
SELECT * FROM workflows WHERE user_id = 123;
然后告诉你："数据确实是空的，问题不在查询，在插入逻辑"。
这是自主Debug能力的质变。
就像给了Claude一双眼睛，让它能"看到"系统真实状态，而不是只能听你描述。
当然，一定要设置成只读权限。
不然Claude万一来一句DROP TABLE，你就凉了。
先规划后实施：磨刀不误砍柴工
这是血泪教训。
花几分钟规划，然后让Claude端到端实现。
什么是规划？
就是和Claude一起写个简单的Markdown设计文档：
- • 功能要做什么
- • 需要哪些API
- • 数据库存什么
- • 前端展示什么
把这些讨论清楚，然后才开始写代码。
为什么？
因为如果你直接说"做个用户管理"，Claude会按它的理解去实现。等你发现不对劲，已经几千行代码了。
改？改不动了。
但如果先规划好，Claude就能按你的思路精准实现。
这就像盖房子——你得先画图纸，不能边盖边想。
规划好后，开启Bypass模式，Claude就能自己创建文件、写代码、写测试，全程自主。
你只需要最后review。
测试驱动开发：质量防线
这个必须强调。
每个功能都写单元测试。
作者的做法：
- • 用Testcontainers在PR时启动临时数据库
- • 跑所有测试
- • 不通过不准合并
为什么这么重要？
因为AI写的代码不是100%可靠。
边缘情况可能漏掉，重构可能改坏逻辑。但测试会立刻发现这些问题。
而且测试还能约束Claude的行为。
它知道每次改动都要过测试，就会更谨慎，不敢乱来。
当然，写高质量测试本身也难。所以作者专门写了个implementing_tests.skill来指导Claude。
测试不是负担，是保险。
tmux日志监控：实时反馈
这招很技术。
在tmux里同时跑前后端，让Claude能随时看日志。
布局大概是这样：
┌─────────────┬─────────────┐ │ Frontend │ Backend │ │ Logs... │ Logs... │ └─────────────┴─────────────┘
然后告诉Claude："出问题就用tmux capture-pane读日志"。
这样Claude能自己看报错信息，针对性修复。
而不是瞎猜。
这就像给了Claude一个"监控大屏"——系统哪里出问题，一眼就看到。
多Worktree并行：终极玩法
如果前面都掌握了，可以试试这个。
用多个Git Worktree，让多个Claude实例并行工作。
什么意思？
就是同时开3-4个项目副本，每个开发不同功能。
project/ # feature A project-wt2/ # feature B project-wt3/ # feature C
听起来很酷。
但风险极高。
如果你对代码掌控不够，很容易冲突。所以作者建议：只有代码高度模块化、影响范围清晰时，才尝试。
分身术是有代价的。
最关键的一点：Review
说了这么多技巧，但有个前提。
你必须认真Review每一行代码。
这不是"Vibe Coding"。
这是"Vibe Reviewing"。
什么标准？
- • 函数级理解：每个函数在哪、干什么
- • 逻辑级审查：实现是否合理、边界情况
- • 架构级把控：是否符合整体设计
做不到？
那生成再多代码也是垃圾。
作者每天工作12+小时，至少一半时间在review。正因为这种高强度审查，才能保证50万行代码的质量。
AI是加速器，不是替代品。
我的思考
读完这篇文章，我意识到一件事。
AI编程不是"提需求等输出"。
而是一门需要技巧和经验的艺术。
核心是什么？
上下文管理 + 明确边界 + 质量把控。
Monorepo解决上下文问题。
模块化路由划清边界。
测试和Review保证质量。
SKILL文件、文件注释、MCP这些都是在降低AI的理解成本，让它能更精准地执行。
这让我想起《人月神话》里的一句话：没有银弹。
AI不是银弹。
但如果你知道怎么用，它能让你的生产力提升10倍。
前提是：你得保持对代码的绝对掌控。
参考资料
- • 原文：What I learned from writing 500k+ lines with Claude Code
- • Git Worktree：git-scm.com/docs/git-wo…
- • Testcontainers：testcontainers.com
P.S. Opus 5马上就来了，自主能力会更强。我们要学的不是"如何写代码"，而是"如何和AI协作"。
坚持创作不易，求个一键三连，谢谢你～❤️
以及「AI Coding技术交流群」，联系 ayqywx 我拉你进群，共同交流学习～
