有个反直觉的事：AI 时代，spec 不但没死，反而geng重要了。

一次过改了不到 %。Controller 骨架、参数校验注解、异常码、返回格式——全部对齐项目规范。我只填了优惠叠加的核心计算逻辑——那 % 才是真正值钱的。

直到有一天我kan到了这个：

有一次我让 CC 重构一个 Service 类。过程是这样的：

规则hen简单：纠正超过两次直接 /clear。 别修修补补。把你前两次纠正的内容写进新 prompt，重来。干净的一轮对话，比一个塞满了纠正指令的长 session，效率高得多。

一次只加一个，用到肌肉记忆再加下一个。

执行命令:运行测试、安装依赖、操作git.5个真实场景:kankan它Neng帮你Zuo什么.

这事有意思的地方在于：.claudeignore 在官方文档里是有的，但大多数前端教程不提它——因为 node_modules Yi经在 .gitignore 里了。Java 的 target/ 是编译产物，hen多人没意识到 CC 会扫它。

/clear 的时机，我自己的判断标准就四条：

/clear 的时机，我自己的判断标准就四条：

纠错超过两次还不 /clear，你花的 token 有一半是在买 CC 的幻觉。

为啥要 /clear 呢？Anthropic 官方文档给这种现象起了个名字：kitchen sink session——厨房水槽 session，什么东西dou往里丢。他们直说这是"Zui高频的失败模式"。

.claudeignore→ /clear 习惯→ 管道符→ spec 先行→ subagent 分治。

mvn test>& | claude -p "分析失败原因，修复代码，再跑一次验证"

mvn test 跑完直接把日志扔给 CC 分析，还Neng直接给修复建议，一气呵成！你把 CC 当聊天窗口，它就只是聊天窗口。你把它当管线工具，它就是你的自动化流水线。

"spec驱动"好用的原因没那么玄：你写 total>= subtotal * 这条约束的时候，脑子里"不超过 %"这五个字才变成了一道数学题。写之前 CC 跟你对齐的是模糊的汉字，写之后对齐的是确定的范围。它不可Neng再算错。

POST /api/orders: requestBody: customerId: string items: array<OrderItem> promoCode: string | nullable responses: : memberDiscount: integer promoDiscount: integer total: integer : error: { code: string, message: string }

Claude Code:按这个 spec 实现 Spring Boot Controller，加上 @Validated 参数校验和统一异常处理.嗯，结果hen不错，一次性通过.

主窗口：重构 OrderService，拆分为三个小 Service ├── subagent ：查支付模块的完整调用链，给我一个 mermaid 图 + 关键文件列表 ├── subagent ：审查当前改动的事务边界，只报告问题不修改代码 └── subagent ：跑 mvn verify，只报告失败的测试和覆盖率缺口

"三个分身并行跑，互不污染。" 你让它查支付模块的实现，不会影响你正在重构的订单模块，两边井水不犯河水，多干净利落！你每跟 CC 聊一次天dou在为 target 目录里的垃圾买单。一个文件，立省 %。 解法只有一行——创建 .claudeignore.

"Claude Code 是 Unix 工具，不是产品。" 它跟 grepawk,sed 是一类东西，只不过它的输入是自然语言。用管道符直接把标准输入喂给 CC,不需要手动搬运日志或代码片段,一气呵成!

全用上之后,CC 跟你协作的体验会从'一个不太靠谱的下属'变成'一个跟得上你思路的搭档'。 CLAUDE.md决定了CC的Neng力下限,这些操作习惯 决定了它的效率上限 . 下限靠写,上限靠练。 “一个CC是助手,三个CC是团队。” 你Ke以开多个subagent并行干活,主session保持干净. “Writer/Reviewer模式”——官方建议.Session A 写代码,Session B 独立审查,然后A按B的意见改.等于你自己有了个 code review搭档. 怎么样,是不是Yi经跃跃欲试了?