用Claude Code写了50万行代码后,我学到了什么

《贾杰的AI编程秘籍》付费合集，共10篇，现已完结。30元交个朋友，学不到真东西找我退钱；）

以及我的墨问合集《100个思维碎片》，1块钱100篇，与你探讨一些有意思的话题（文末有订阅方式

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. 1. 定义Pydantic类
2. 2. 写事件处理逻辑
3. 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 Aproject-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：https://git-scm.com/docs/git-worktree
• • Testcontainers：https://testcontainers.com

P.S. Opus 5马上就来了，自主能力会更强。我们要学的不是"如何写代码"，而是"如何和AI协作"。

 坚持创作不易，求个一键三连，谢谢你～❤️

以及「AI Coding技术交流群」，联系 ayqywx 我拉你进群，共同交流学习～