很多人用 Claude Code 的方式，还停留在「打开终端，问一句，复制粘贴答案」。单次问答能救急，但一旦落到真实项目上——多模块、有测试、要过 CI、还得跟同事的提交合到一起——这套用法很快就会露馅：上下文接不上、改完不知道有没有改坏、生成的东西没法review、同一个坑每次都要重新解释一遍。

这门课要补的，正是这段从「会用」到「能放进工程流程里用」的缺口。它不是提示词合集，讲的是把 Claude Code 当成工程流水线里的一个环节来配置、约束和验证。下面几节，按能力缺口来拆。

缺口一：上下文是怎么被组织和消耗的

多数人从没想过一个问题：Claude Code 每次回答时，到底「看到」了什么。项目说明文件、被读取的文件、历史对话、工具返回结果，这些东西谁先谁后、谁会被截断、哪些该写进持久化的项目上下文里，直接决定了它在你的仓库里是聪明还是犯傻。

这部分要能回答：一个中大型后端项目，应该把哪些约定放进项目级说明、哪些留在会话里、哪些干脆不该喂给它？为什么同一个任务，换一种喂上下文的方式，结果差距会很大？

缺口二：项目构建与代码改动的可控性

让它改代码不难，难的是改完你敢不敢合。课程围绕项目构建这条线，讲的是怎么把「生成」变成「可审查的改动」：改动范围怎么限定，涉及多文件时怎么保持一致性，接口、依赖、配置文件被牵动时怎么发现。

配套练习的典型形态是：给一个已有服务，要求加一个功能或改一处逻辑，然后逐条核对它动了哪些文件、有没有顺手改掉不该改的东西。做完这一轮，你会对「哪些任务可以放手、哪些必须盯着」形成自己的判断，而不是凭感觉。

缺口三：自动化测试这条安全绳

没有测试兜底，让工具大批量改代码就是赌博。这部分讲的是把测试接进工作流：怎么让它先读现有测试再动手，怎么让新增逻辑带上可运行的用例，怎么在测试失败时把失败信息回喂给它继续修，而不是推倒重来。

要能回答的问题很具体：一个没有测试覆盖的老模块，第一步该做什么？它写出来的测试，怎么判断是真在验证行为，还是只是把当前实现抄了一遍？

缺口四：持续集成与交付环节的接入

本地跑通不等于流水线跑通。CI 环境里没有你本地的缓存、环境和临时状态，权限、密钥、依赖版本都是另一套。课程把这条线拉通到持续集成与交付，关注的是它在自动化流程中的位置、边界和失败处理。

学完应能回答：哪些环节适合让它参与、哪些环节必须人工卡住？流水线报错时，怎么把日志有效交回给它定位，而不是反复空转？团队协作下，怎么让别人也能复现你这次的用法？

适合谁，以及怎么用这份材料

已经用 Claude Code 写过零散代码，但没把它放进正式项目流程的后端开发者。
手里有真实仓库、真实测试和 CI，想拿它提效又担心引入风险的人。
需要给团队定一套使用约定，却不知道从哪儿下手的负责人。

建议边看边在自己的项目上做对照练习：每学一个环节，就找一个当前项目里的真实任务试一次，记录它哪里靠谱、哪里需要人工兜底。这套材料更接近一本操作手册，跳着查比从头刷更划算。如果连基础的命令行工作流和测试框架都还不熟，先补那一层，再来会更顺。