三个月，一个人，300多个接口。
不是夸张，也不是标题党。我最近这个项目就是前端、后端、产品、运维全自己扛，平均每天只干两三个小时。AI写的代码占了90%以上，主力工具是Claude Code。
换做一年前，这个效率我想都不敢想。
下面这7条，是我这一路踩坑踩出来的真实体会。不整理论，只聊实操。
1. CLAUDE.md，早写早解脱
说实话，刚开始我也没把这当回事。觉得prompt写好就行了，搞什么配置文件。
后面发现不对。
Claude每次新对话都是白纸一张。你今天跟它讨论完数据库设计，明天开个新窗口让它写接口——它完全不知道你项目的技术栈是什么、目录怎么组织的、命名有什么规矩。你得重新解释一遍。一天重复三四次，你就烦了。
后来我在项目根目录放了CLAUDE.md，一口气写清楚：
- 技术栈和版本号（精确到版本，不然它会给你过时的API）
- 目录结构是怎么设计的，什么放哪里
- 命名规范，包括我自己那些不太常规的习惯
- 哪些文件绝对不能碰（配置文件、密钥相关、已经稳定的核心模块）
- 之前讨论过但被否掉的方案，以及否决原因
这个文件从几十行涨到快400行。每遇到一个新坑，我就往里加一条。
用久了你会发现，好的CLAUDE.md本质上就是你给AI外挂的一块长期记忆。写得越细，它就越像跟你合作了很久的搭档，而不是每次都从零开始的新人。
2. 先聊方案，别急着写代码
这是我最想强调的一条。因为我在这上面吃过亏。
早期用Claude Code的时候，我习惯上来就说“帮我实现用户认证系统”。它确实能给你一个跑得通的方案，测试也绿。但用了两周之后你才会发现——当初那个架构选择有问题，改一个地方要动十几处代码，牵一发动全身。
现在我的习惯变了：动手之前，先跟它聊清楚。
“这个需求有哪几种实现思路？分别的优劣是什么？你倾向哪个？为什么？”
这里顺便说一个我用了之后很受益的插件：superpowers。你提功能需求的时候，它会跟你做一轮头脑风暴，帮你把方案拆得更细。它给的分析不一定全对，但有一个核心价值——逼着你在写第一行代码之前把关键问题想清楚。很多时候它提到的点，你自己确实容易漏掉。
方案讨论透了再动手，代码质量和可维护性完全不一样。这不是慢，是把后面的返工时间省了。
3. 小块小块地喂，别一口气塞给它
一个项目逃不掉用户系统、权限管理、数据面板、报表导出这些大模块。
但相信我——千万别把整个模块一次性扔给Claude。它会给一个看起来特别完整、实际上这里缺一点那里错一点的实现。表面上省了时间，调试起来够你受的。
我现在拆得很细：
用户系统 → 先做数据库表结构设计 → 再做注册登录API → 然后是session管理逻辑 → 接着是密码重置流程 → 最后才是权限校验中间件
一小块一小块来。做完一块，验证通过，再做下一块。
这个节奏表面上慢，实际上是快的。因为你每一步都清楚自己在哪里，出问题能马上定位到具体环节，改了一处绝不会莫名其妙影响另一处。而且AI在小范围、单一任务上的质量明显比大模块整体输出高得多。
4. 报错信息，原封不动贴过去
“报了个错，帮我看看”——我早期经常这么干。
后来发现这是效率最低的求助方式。问题在哪呢？你自己先消化了一遍错误信息，然后再用自己的话转述给AI。就这一步“翻译”，关键信息已经丢了一半。类型到底是什么、堆栈里哪个环节出的事、触发条件是什么——这些细节你自己未必注意，但对AI定位问题至关重要。
现在我的做法很简单：直接贴原始材料。完整的错误堆栈、对应的代码片段、我已经试过什么、什么操作会触发。全给。
给足了这些，Claude解决bug的速度明显不一样。少给一样，它就靠猜，猜对了是你的运气，猜错了来回几轮才找到真正的根因。
5. 别跟一个模型死磕
我大部分时间确实在用Claude Code，质量很稳。但再好的模型也有盲区。
有时候一个问题Claude反复给你三个方案，每个都差那么一口气，绕来绕去就是出不来。这时候继续调prompt，只是在浪费时间。
我现在给自己定的规则很简单：一个模型给三次机会。三次搞不定，直接换Codex或者别的模型。你可能会发现换过去一下子就通了——不是Claude不行，是每个模型的知识结构和推理路径不一样，换个角度可能刚好打中。
还有个习惯我觉得很值：
- Claude写的代码，让Codex审一遍
- Codex写的代码，让Claude审一遍
两边的盲区不完全重叠。交叉看能抓到更多你自己也容易忽略的问题。这比找同事review快，而且半夜也能做。
6. 冷门库直接把文档喂给它
这块踩的坑太多了，单独拎出来说。
像Next.js、React、PostgreSQL这些大家都在用的东西，Claude的输出质量非常高，基本可以直接信任。训练数据里足够多。
但如果你用的是相对小众的库，或者某个框架刚出的新版本——注意了。它会给你看起来特别合理、但实际根本不存在的API。方法名叫得一本正经，参数排得有模有样，结果编译一跑全报错。
我后来学的乖是：遇到冷门库或新版本API，第一时间把官方文档贴给它。不是摘要，是完整文档。文档就是它的知识更新。
这条认知帮我省掉的时间，可能是这7条里最多的。
7. 把你的prompt当资产来管
这个意识是我做到第二个项目的时候才有的。
回头一看，第一个项目里那些好用的提示词结构、审查代码的角色设定、需求拆解的提问框架——都是当时反复试了好几次才摸索出来的。但那时候没想着记，第二个项目又要重新来一遍。
后来我开始有意识地记录：
- 什么类型的任务，用什么结构来描述最有效
- 代码审查时，给AI设定什么角色、什么标准，输出的质量最高
- 需求拆解时，用什么框架能让AI拆得最合理、最不容易漏
这些东西本质上是你的“软工具”。第一次摸索出来耗时，但记下来之后，下个项目直接复用。
你积累的prompt模式，就是你为自己造的轮子。而且这个轮子比任何开源库都更贴合你自己的代码风格和工作习惯。
这7条是我这三个月下来最深的体会。
如果你也在用AI辅助编程，或者刚开始尝试一个人用AI扛整个项目，希望这些经验能帮你少走点弯路。
发表于 昨天 21:14
|
查看: 4|
回复: 0
