व्यावहारिक परियोजना (Capstone Project): उत्पाद विकास का पूर्ण जीवन चक्र
📚 सीरीज नेविगेशन: पिछला लेख [47 Voice 语音模式] ने वॉयस इनपुट के साथ हाथ से टाइप करने की आवश्यकता को कम किया। यह लेख इस ट्यूटोरियल श्रृंखला का अंतिम स्नातक प्रोजेक्ट (graduation project) है—हम कोई नई सुविधा नहीं सीखेंगे, बल्कि एक वास्तविक परियोजना (जो लेख 39 की तुलना में बड़ी है और इसके लिए कई सत्रों की आवश्यकता होती है) के साथ, CLAUDE.md, अनुमतियां, MCP, उप-एजेंट (subagents), चेकपॉइंट, और git जैसे सभी कौशल घटकों को एक साथ ट्रिगर करेंगे। यह एक पूर्ण विकास चक्र को पूर्ण करेगा।
यदि आप Claude Code के साथ पूरे किए गए प्रोजेक्ट्स की समीक्षा करते हैं, तो एक बात स्पष्ट हो जाएगी: वास्तविक दक्षता केवल एक लाइन को ठीक करने वाले प्राथमिक कार्यों में नहीं है, बल्कि उन मध्यम स्तर की परियोजनाओं में है जिनमें 3 से 5 सत्र शामिल होते हैं और एआई की विविध सुविधाओं का उपयोग किया जाता है।
विशिष्ट उदाहरण: स्क्रैच से एक आंतरिक विकास उपकरण बनाने में 4 सत्र (लगभग ढाई घंटे) लगे, जिसके दौरान दस्तावेज़ देखने के लिए एक MCP सर्वर का उपयोग किया गया, सुरक्षा समीक्षा के लिए एक उप-एजेंट (subagent) को नियुक्त किया गया, और एक गलत कोडिंग संशोधन को पुनर्स्थापित करने के लिए चेकपॉइंट का उपयोग किया गया। अंतिम git इतिहास में 7 सुसंगत कमिट शामिल थे, जिनमें से प्रत्येक स्पष्ट और सार्थक था। यह एआई क्षमताओं के कुशल एकीकरण को दर्शाता है।
सरल शब्दों में, यह व्यक्तिगत कौशल को समझने और उन्हें वास्तविक परियोजना विकास में लागू करने के बीच का अंतर है। लेख 39 में एक न्यूनतम व्यावहारिक अभ्यास शामिल था—एकल सत्र, एकल स्क्रिप्ट, और पूरी तरह से स्थानीय स्तर पर। इस लेख में हम दायरे का विस्तार करेंगे: परियोजना अधिक जटिल है, इसके लिए सत्रों के पार निरंतरता, बाहरी संसाधनों के साथ एकीकरण, और सुरक्षा पुनर्प्राप्ति की आवश्यकता है। पिछले लेखों ने आपको व्यक्तिगत उपकरणों के उपयोग की जानकारी दी, और यह लेख एक संगीत कंडक्टर की तरह इन सभी उपकरणों को एक पूर्ण प्रवाह में संयोजित करने के बारे में है।
एनालॉजी: एक पूर्ण सिम्फनी के प्रदर्शन के लिए ऑर्केस्ट्रा का संचालन करना। आपने वायलिन, ड्रम, और विविध संगीत उपकरणों का अभ्यास किया है—और व्यक्तिगत रूप से उन पर महारत हासिल की है। लेकिन व्यक्तिगत रूप से उपकरणों को बजाने और एक संगीत सिम्फनी तैयार करने में बहुत अंतर है: आपको यह जानना होगा कि प्रत्येक भाग कब शुरू होना चाहिए, किसका नेतृत्व होगा, और गति कैसे सुसंगत रहेगी। इस परियोजना में, आप कंडक्टर हैं—और CLAUDE.md, अनुमतियां, MCP, उप-एजेंट, चेकपॉइंट, और git आपके संगीत उपकरण हैं। हम इन सभी को एक सुसंगत जीवन चक्र में जोड़ेंगे।
इस लेख को पढ़ने के बाद, आपको मिलेगा:
- स्क्रैच से उत्पाद रिलीज तक मध्यम परियोजनाओं के लिए एक व्यापक कार्यप्रवाह मानचित्र, जो यह स्पष्ट करता है कि प्रत्येक कौशल घटक कहाँ प्रयुक्त होता है
- सत्रों के पार निरंतरता की रणनीति: कैसे
--resume, SPEC फ़ाइलें, और चेकपॉइंट का उपयोग करके कार्य को कई दिनों / सत्रों में विभाजित किया जाए - प्रत्येक महत्वपूर्ण चरण के लिए कमांड और उनके अपेक्षित आउटपुट विवरण
- एक संपूर्ण अभ्यास परियोजना (एक स्थानीय कमांड लाइन कार्य सूची उपकरण, जिसमें डेटाबेस, परीक्षण और प्रलेखन शामिल है), जो CLAUDE.md → अनुमतियां → MCP → उप-एजेंट → चेकपॉइंट → git को जोड़ती है
- "सरल परीक्षण बनाम वास्तविक परियोजना विकास" की तुलनात्मक सूची, त्रुटियों की पहचान के साथ
01 先看全景：一个中等项目，功能在哪一步登场
开始之前，先把整支曲子的「总谱」摊开看一眼。一个中等项目从零到交付，骨架还是那几步，但每一步都比第 39 篇重，而且会拉进新的声部。
这张图把一趟中等实战画成一条带回路的流水线：六个环节依次接棒，而那条虚线是关键——真实项目一个会话干不完，验证完一轮会回到「规划」开下一个会话，把功能一块块啃下来。第 39 篇那条单向直线，这里弯成了一个能转好几圈的环。
跟第 39 篇最大的不同，就两点，先记死：
- सत्रों के पार निरंतरता (Cross-session continuation): 一会话上下文塞满了就该收尾（第 19 篇讲过工作台塞满会变蠢），换个干净会话接着干。所以「怎么把活儿安全地交接到下一个会话」本身就是一门功夫。
- 它要调动新声部。 单脚本用不上 MCP、subagent，但中等项目里它们是常态——查外部文档、隔离掉脏活、找个新鲜模型挑刺。
官方最佳实践那句话，正好是这一篇总纲：
一旦你对一个 Claude 有效，通过并行会话、非交互模式和扇出模式来增加你的输出。
说白了就是：摸清一套有效的打法之后，就靠并行跑多个会话、用非交互批量执行、用扇出派分身同时推进，把产出放大——而不是每次都从零试。这一篇就是在实战中把这几招一件件用起来。
下面每一节，我都会在开头标清「这一棒对应前面哪一篇学过的东西」，让你边走边把零件对上号。地图记牢了，剩下的就是看每个声部什么时候进场。
💡 一句话总结：中等项目的骨架仍是「立项 → 规划 → 接外部 → 分活 → 容错 → 交付」，但比小任务多了两样——要跨会话接力、要调动 MCP / subagent 这些新声部；那条回到「规划」的虚线，是真实项目的常态。
02 立项：定项目、写 CLAUDE.md、把权限基线配好
第一棒——立项。对应第 12 / 18 篇（CLAUDE.md）、第 20 篇（权限）。这一棒在小任务里只是「写三五行 CLAUDE.md」，到了中等项目，得把「项目规矩」和「权限基线」一起立起来，因为后面好几个会话都要吃这套地基。
我们这一篇要做的项目：一个命令行的任务清单工具（todo-cli）——能加任务、列任务、标记完成，数据存在本地一个 JSON 文件里，再配上测试和一份 README。它比第 39 篇那个单文件脚本大：多个文件、有持久化、有测试、要跨会话分步做，但依然只用 Python 标准库，谁都能跑。
第一步：建项目骨架、纳入 git
mkdir todo-cli && cd todo-cli && git init为什么开工第一件事就是 git init？因为它是你整趟项目最硬的那张后悔药。检查点（第 37 篇）能倒带 Claude 的编辑，但它和 git 是两套东西、各管一段。一个干净的初始提交，是你无论后面怎么折腾都能逃回去的原点——这条第 39 篇讲过，项目越大越要守。
第二步：在项目根启动，写一份够用的 CLAUDE.md
claude进去后让它生成 CLAUDE.md（中等项目更推荐先手动指明几条核心规矩，比 /init 扫全库更准，因为这会儿还没什么代码可扫）：
帮我在项目根目录建一个 CLAUDE.md，写清这几条：
1. 这是个纯 Python 标准库的命令行工具，不要引入任何第三方依赖
2. 数据持久化到项目根的 todos.json，所有读写都走这一个文件
3. 每加一个功能都要配 unittest 测试，改完跑 python3 -m unittest 验证
4. 提交信息用中文，前缀用 feat: / fix: / docs:预期：Claude 先把内容给你看、再请求批准写文件（第 20 篇的权限机制）。批准后多出一个 CLAUDE.md，把这四条规矩钉死。注意——它现在只有十来行。官方那句红线值得再贴一遍：
保持简洁。对于每一行，问自己：「删除这个会导致 Claude 犯错吗？」如果不会，删除它。
这四条全是 Claude 猜不出来、又会反复用到的规矩，所以留着。后面三四个会话，它每次开工都自动加载这份说明，你不用每个会话都复读「别引第三方库、改完跑测试」。
第三步：把权限基线配好——这是中等项目比小任务多出来的关键一步
小任务你可以一处一处批准。但中等项目要跑好几个会话、改十几个文件，官方在最佳实践里直接点破了这个问题：「在第十次批准后，你不是真的在审查，你只是点击通过。」 所以开工就该把权限基线定好。三条路，看场景挑：
| 许可模式 | विन्यास तरीका | 适合的场景 |
|---|---|---|
| श्वेतसूची (Whitelist) | /permissions 把你确定安全的命令加进去（如 python3 -m unittest、git status） | 项目里反复跑的安全命令，免得每次都问 |
| plan mode（计划模式） | Shift+Tab 切，或 claude --permission-mode plan 启动 | 不熟的改动、要先审方案再动手时 |
| auto mode（自动模式） | claude --permission-mode auto，分类器只拦危险操作 | 信任任务大方向、不想点过每一步时 |
做这个 todo-cli 时一套实用的配法：python3 -m unittest、git diff、git status 这几条反复跑的，第一时间用 /permissions 加进允许列表；涉及多文件的功能改动一律先 Shift+Tab 切 plan mode 审方案。这套基线立好，后面几个会话的批准噪音直接少一大半——头一回做中等项目时要是没配，光「要不要跑测试」这一个问题就能批二十多次，烦到差点关掉确认（那才是真危险）。
⚠️ 权限放松是把双刃剑——auto mode 和「全部接受」省心，但你交出的是「事中拦截」那道窗口。第 20、21 篇专门讲过这个权衡：越是放手，越要靠后面的验证和检查点兜底。
💡 一句话总结：中等项目的立项 = git init 留原点 + 写一份十来行的 CLAUDE.md 定规矩 + 用
/permissions、plan mode、auto mode 配好权限基线；权限基线这一步，是项目变大后比小任务多出来、最该花两分钟做的事。
03 规划：先探索出一份 SPEC，再跨会话分步实现
地基打好，第二棒——规划。对应第 16 篇（探索）、第 20 篇（plan mode）、第 19 篇（上下文管理）。中等项目和小任务在这一棒分野最大：小任务一句话说清就能动手，中等项目得先沉淀出一份「规格说明（SPEC）」，再照着它分会话啃。
为什么中等项目一定要先出 SPEC？ 因为功能一多，你脑子里那点模糊想法根本撑不住一趟实现——做到一半发现边界没想清、字段对不上，回头返工。官方最佳实践给了个特别好用的招：让 Claude 反过来采访你。
第一步：让它采访你，逼出一份 SPEC
进 plan mode（Shift+Tab），把这段话甩给它：
我想做一个命令行任务清单工具 todo-cli，数据存本地 JSON。
用 AskUserQuestion 工具详细采访我：技术实现、命令行接口怎么设计、
边界情况（比如空清单、重复任务、文件损坏）、有哪些权衡。
别问显而易见的，挖那些我可能没想到的硬骨头。
问完把完整规格写进 SPEC.md。预期：Claude 会一条条问你——「任务要不要带优先级？」「todos.json 不存在时是报错还是自动建？」「标记完成是删掉还是留着打勾？」这些全是你自己拍脑袋时漏掉的。问够了，它写出一份 SPEC.md，把命令、字段、边界、验收标准全列清。官方点破了 SPEC 的价值：
最有用的规范是自包含的：它们命名涉及的文件和接口，说明什么在范围之外，并以端到端验证步骤结束。
做这个工具时，它常会问到一个你压根没想的点：「两条任务文字一模一样，算不算重复、要不要去重？」 被这么一问才意识到这是个真要拍板的设计决策。花十分钟被它采访，省掉的是后面「做到一半推翻重来」的两小时——这笔账太划算了。
第二步：把大活儿切成「一个会话一块」
SPEC 出来了，别想着一个会话从头干到尾。中等项目的功能一多，单会话上下文很快就塞满，塞满了 Claude 就开始「忘事、犯错」（第 19 篇讲透了）。正确的打法是照 SPEC 切块，一个会话啃一块：
会话 1：搭骨架——文件结构、todos.json 读写、add 命令 + 测试
会话 2：list 和 done 命令 + 测试
会话 3：边界处理（文件损坏、空清单）+ 补全测试
会话 4：写 README、整体过一遍、交付第三步：会话之间怎么安全接力
这是中等项目独有的功夫。一个会话干完一块，怎么把活儿交给下一个会话？两个抓手：
/clear收尾，--resume接力。 干完一块、要换不相关的下一块时，/clear重置上下文（官方反复强调「不相关任务之间频繁/clear」）；想接着之前那条线干，用claude --resume从列表里挑回那个会话。- SPEC.md 当「交接班的备忘录」。 每个会话开头让它先读一眼
SPEC.md和git log，几秒钟就接上了上一棒的进度——这就是为什么 SPEC 要落成文件，而不只是聊在对话里：对话会随会话清掉，文件不会。
给你一句能直接抄的「接力开场白」，每个新会话第一句就甩这个：
先读 SPEC.md 和 git log 看我们做到哪了，别改任何代码，
告诉我下一块该做什么、有没有遗留的坑。做 todo-cli 时偷个懒很容易翻车——第二个会话没让它读 SPEC，凭记忆直接说「接着做 list 命令」，结果它把第一个会话已经定好的 JSON 字段名又改了一套，两个会话的数据格式对不上，白折腾。所以雷打不动的做法是：新会话第一句永远是「先读 SPEC 和 git log」，让它自己接上进度，比口头复述准得多。
官方那句话点得很实在：
Claude Code 在本地保存对话，所以当任务跨越多个会话时，你不必重新解释 context。
也就是说：历史记录保存在本地，但是，重新加载长历史会挤占上下文窗口（如लेख 19 所示）。因此，SPEC.md 文件的使用是恢复上下文更具令牌效率的方式。
💡 一句话总结：中等项目规划 = 先让 Claude 采访你逼出一份 SPEC.md，再照它把大活儿切成「一个会话一块」；会话间用
/clear收尾、--resume接力，SPEC 文件当交接班备忘录——对话会清掉，文件不会。
04 接外部：用 MCP 把它够不着的东西接进来
骨架开始动工，很快会撞到第三棒——接外部。对应第 22 篇（MCP）。这一棒在第 39 篇那个纯本地小脚本里完全用不上，但中等项目几乎绕不开：你总会需要它查个外部文档、读个数据库、开个 PR。
什么时候该想起 MCP？ 官方的判断特别铺素：
当您发现自己从另一个工具复制数据到聊天中时，请连接一个服务器。
做 todo-cli 时常撞上的真实场景是：写测试时拿不准 unittest 里某个断言方法的准确用法，第一反应是去浏览器搜，搜完再复制回来贴给它——这就是该上 MCP 的信号。与其手动倒腾，不如让它自己去查。
类比：给一台只有本地硬盘的电脑插上网线。 没联网时，电脑只能读自己硬盘里那点东西，要外面的资料你得拿 U 盘一趟趟拷。插上网线，它自己就能去取了。Claude 默认就是那台「没联网」的电脑——只摸得到你本地的文件和命令；MCP 就是那根网线，接一次，外部那些它本来够不着的东西，它自己就能去拿。区别只在网线那头连的是什么：连文档站、连数据库、还是连 GitHub。
这里我们接一个最适合练手的：官方文档 MCP server。它是托管的 HTTP server，不用登录、不用任何配置，专门拿来练手最稳。
第一步：加 server（在终端，不是在 claude 会话里）
claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcp注意： 这个 server 是远程托管服务，加它需要联网；国内访问 code.claude.com 如果不通，先开「魔法上网」再试。
预期：打印一行确认，类似 Added HTTP MCP server claude-code-docs ...。
第二步：确认连上了
claude mcp list预期：列表里 claude-code-docs 旁边标着 ✓ Connected。看到这个绿勾 = 真连上了；要是 ✗ Failed to connect，多半是网络，开魔法上网再试。
第三步：在会话里点名让它走这个 server 查
用 claude-code-docs server 查一下 Claude Code 的 subagent 是怎么定义的，
配置文件放哪、有哪些字段。预期：Claude 第一次调这个 server 会停下来问你要不要批准（第 22 篇说的「工具首次调用要批准」）——批准它。然后它返回 subagent 的说明，而且输出里那个工具调用旁边会标着 claude-code-docs。看到这个标记 = 答案是真从文档查来的，不是模型记忆里编的。
中等项目里 MCP 的真实用法远不止查文档。常见的还有这几路，体会一下「接上之后能干嘛」：
| वांछ存资源 | 哪个 MCP 服务 | 一鸣惊人（接上之后能干嘛） |
|---|---|---|
| 项目的 issue / PR | GitHub MCP | 「把 issue #12 描述的功能实现了，再开个 PR」 |
| 公司数据库 | PostgreSQL 等 MCP | 「查本月新增的任务条数」（生产库一律先用只读账号） |
| 设计稿 | Figma MCP | 「按这版设计调整命令行的输出格式」 |
但接 server 前那句安全警告，项目越大越不能忘（第 21、22 篇讲过）：
在连接每个服务器之前，请验证您信任该服务器。获取外部内容的服务器可能会使您面临提示注入风险。
MCP server 是第三方代码，Anthropic 不替你审计。优先用官方目录和大厂官方 server，给数据库一律先用只读账号——这是把风险摁到最低最实在的一招。还有官方那句提醒：每个连上的 server 都吃一点上下文窗口，所以这个练手的 docs server 用完，记得 claude mcp remove claude-code-docs 拆掉，把空间腾出来。
💡 一句话总结：中等项目几乎绕不开 MCP——发现自己在「从别处复制数据贴给它」时，就该接个 server；练手用免登录的官方文档 server 最稳，真实项目接 GitHub / 数据库 / Figma，但接前先验信任、数据库用只读、不用的及时拆。
05 分活：派 subagent 干脏活，再找个新鲜模型挑刺
项目代码越堆越多，第四棒登场——分活。对应第 23 篇（subagent）、第 29 篇（agent teams）。这一棒小任务用不上，但中等项目里它是保住主对话不被塞爆、保住代码质量的两员大将。
用 subagent 探索，别让一堆文件灌满主对话
todo-cli 做到第三个会话，文件多了起来，假设你想搞清「现在的 todos.json 读写逻辑散落在哪几处」。别直接在主对话里让它一个个翻文件读——那会把一堆文件内容灌进你的主上下文，正经活儿的空间就被挤没了（第 19 篇讲的工作台塞满变蠢）。正确做法是派个 subagent 去翻：
派一个 subagent 去摸清 todos.json 的所有读写都发生在哪些函数里，
只把「哪些文件、哪些函数、各自干啥」的清单报给我，别贴文件全文。预期：subagent 在它自己的独立上下文里翻文件，翻完只把一份摘要清单递回主对话。官方说得很直接：
由于 context 是你的基本约束，subagents 是可用的最强大的工具之一……它们在单独的 context windows 中运行并报告摘要。
类比：派个实习生去档案室查资料。 你要的是「查到什么」，不是让他把整柜子档案搬到你办公桌上。subagent 就是这个实习生——他在档案室（独立上下文）里翻得天翻地覆，回来只给你一页要点，你的桌面（主上下文）干干净净。
找个新鲜模型给代码挑刺——「不让作者给自己打分」
功能写完了，别让刚写完代码的那个 Claude 自己审自己——它会偏袒自己刚写的东西。中等项目里必做的一步，是开一个新鲜上下文专门挑刺。官方把道理讲透了：
在新鲜的 subagent context 中运行的审查者只看到差异和你给它的标准，而不是产生更改的推理，所以它按自己的条件评估结果。
最省事的是跑官方捆绑的 /code-review 命令，它会在新鲜子代理里审当前 diff、把缺陷报回来：
/code-review或者你自己写审查提示，点名「审什么、按什么标准、什么算缺陷」：
用 subagent 对照 SPEC.md 审一遍刚才的改动：每条要求是否实现、
列出的边界情况有没有测试、有没有动到范围外的代码。
只报影响正确性的问题，别报风格偏好。做 todo-cli 时，审查 subagent 常能揪出一个主会话也没注意的 bug：todos.json 损坏时以为已经处理了，其实只 catch 了文件不存在、没 catch 内容不是合法 JSON 的情况。这就是「新鲜模型」的价值——它不带「刚写的应该没问题」这层滤镜。不过官方也提醒一句别走偏：
告诉审查者只标记影响正确性或陈述要求的缺陷，将其余的视为可选。
实验性提醒：Agent teams（智能体团队，第 29 篇）是这一棒的「自动化加强版」，可能随版本变化。它能让多个会话带着共享任务清单自动协作——比如一个写代码、一个持续审查。中等项目你先用「手动开个 subagent 挑刺」就够；等活儿大到一个人盯不过来，再上 agent team 让它自己跑这个循环。
💡 一句话总结：项目变大后两员大将——探索脏活派 subagent（独立上下文翻文件、只递摘要，主对话不被灌满）；代码质量靠新鲜模型挑刺（
/code-review或自定义审查提示，不让作者给自己打分）；再大就上 agent team（实验性）。
06 容错：改崩了别硬补，干净地倒带回去
项目一大，「改崩」就成了家常便饭，第五棒就是专治这个——容错。对应第 37 篇（检查点）。这一棒第 39 篇点过，但中等项目里它的分量重得多：改动越复杂、越容易偏，而你已经回不到「一眼能看完所有 diff」的小任务状态了。
先说新手最容易犯的错：对着已经改乱的代码，再让它「在这基础上修一下」。
千万别这么干。在一个已经偏了的状态上反复打补丁，越补越乱——它每次都带着上一版的错误上下文，窟窿越捅越大。正确处理是：先干净地退回到一个已知正确的点，再带着「这次该怎么说清楚」重开。 退回有两档：
| 撤回档位 | 用什么 | 退到哪 | 适合 |
|---|---|---|---|
| 轻档：撤刚才的编辑 | 检查点，/rewind 或连按两次 Esc | Claude 改这一批文件之前 | 改岔一两处、刚发现就想撤 |
| 重档：回到某个干净提交 | git，git restore .（撤工作区未暂存改动）或 git reset --hard <SHA>（回到某个 commit） | 你之前 commit 过的某个稳定点 | 方向整个偏了、想从某节点重来 |
轻档最常用：敲 /rewind 打开倒带菜单，能只回代码、只回对话、或两者都回。官方对它的定位很清楚，有一点中等项目力尤其要记牢——检查点只跟踪 Claude 在本会话里做的更改，不跟踪 bash 命令改的文件，更不是 git 的替代品。
这就是为什么中等项目要勤 commit。检查点只管 Claude 在本会话里的编辑；可这项目跨好几个会话、中间还跑过测试、装过东西——这些检查点管不着，只有 git 管得着。做 todo-cli 时很容易栽这么一个跟头：第三个会话让它重构 JSON 读写，它一口气改了三个文件、还顺手「优化」了没让动的 add 逻辑，方向全偏。幸好每完成一块就 commit 了一次，git reset --hard 回到上一个稳定提交，三十秒回到原点——要是只指望检查点，跨会话那部分根本理不清。
退回去之后别急着原样重说一遍。先想想这次为什么偏了——十有八九是指令漏了关键约束（第 15 篇讲的「话说清」）。重开时补一句「只重构读写那两个函数、绝对别动 add」，第二次就顺了。退回不是失败，是止损。
💡 一句话总结：项目大了「改崩」是常态——第一反应永远是「干净退回」，不是在烂摊子上硬补；轻档用
/rewind撤编辑、重档用 git 回稳定提交；检查点只管本会话的编辑、不是 git 替代品，所以中等项目要勤 commit 留退路。
07 动手：把一个真项目从零串到交付
光看地图不算会，得真上手把整支曲子合奏一遍。下面给你一个能原样照着跑的完整流程——做完那个 todo-cli 的前两块（搭骨架 + add/list），全程把前面六棒串起来。只用 Python 标准库，有 python3 就行（Mac / Linux 自带，Windows 装了 Python 即可）。
第一步：立项（对应 02 节）
mkdir todo-cli && cd todo-cli && git init && claude进会话后写 CLAUDE.md：
建一个 CLAUDE.md：纯 Python 标准库别引第三方依赖；数据存项目根的 todos.json；
每个功能配 unittest，改完跑 python3 -m unittest 验证；提交信息用中文带 feat:/fix: 前缀。预期：它给你看内容、请求批准、写出十来行的 CLAUDE.md。批准后顺手把测试命令加进允许列表：在会话里敲 /permissions，把 Bash(python3 -m unittest*) 加到 allow。预期：允许列表里出现 Bash(python3 -m unittest*) 一行 = 加进去了。
第二步：规划（对应 03 节）
切 plan mode（Shift+Tab），让它先出方案别动手：
我要做 todo-cli：todo.py 提供 add「文字」加任务、list 列出所有任务（带编号和完成状态），
数据存 todos.json。先告诉我文件结构和你打算怎么实现，等我说「开始」再动手。预期：它回一份计划——todo.py 含读写 todos.json 的函数、add / list 两个子命令（用 argparse），外加一个 test_todo.py。它停在这儿等你拍板。
第三步：动手 + 审 diff（对应 02 节权限）
方案可以，开始吧。先实现 add 和 list，再写对应的 unittest。预期：Claude 开始建 todo.py 和 test_todo.py，每改一处把 diff 摆给你批准。扫一眼确认三件事：① 真在实现 add/list（符合方案）；② 没引第三方库（CLAUDE.md 的规矩）；③ 没乱动别的。对得上就批。
第四步：验证——亲手跑，别信「我改好了」（对应全篇铁律）
先跑测试（这条已在允许列表里，不会再问你）：
python3 -m unittest预期输出：
...
----------------------------------------------------------------------
Ran 3 tests in 0.00s
OK再亲手跑一遍真实功能：
python3 todo.py add "写第48篇教程"
python3 todo.py add "跑通动手环节"
python3 todo.py list预期输出（编号 + 未完成标记，具体符号看它实现，大致如此）：
[1] [ ] 写第48篇教程
[2] [ ] 跑通动手环节看到测试 OK、list 列出刚加的两条 = 这一块真的成了。「它说改好了」是假设，你跑出来对了才是事实——这条第 39 篇讲过，项目越大越要守。
第五步：找新鲜模型挑刺（对应 05 节）
/code-review预期：它在新鲜子代理里审刚才的 diff，把发现报回来（比如「todos.json 不存在时没处理」）。只修影响正确性的，风格偏好先放着。
第六步：交付（对应 06 节 + git）
我改了哪些文件？给个改动概览。然后用一句话描述这次改动、提交它。预期：它跑 git status / git diff 给你看范围，再拟一条提交信息（如 feat: 实现 todo-cli 的 add 和 list 命令）、请求批准执行 git commit——这又是第 20 篇那道权限闸：它动你的 git 历史前照样先问你。
第七步：守住 push 这条红线
到这儿这一块就交付了。但有一条边界任何项目都不能含糊：
本地
commit可以放手让它代劳，但git push（推到远程）这一步，钥匙必须攥在你自己手里。
把成果推上 GitHub 之类的远程前，务必你自己心里有数、亲自把关——这是第 43 篇「Git 工作流」细讲的。本地提交它先给你确认、放手没问题；推远程那一下，自己来。
跑通这七步，你就把「立项 → 规划 → 动手 → 验证 → 挑刺 → 交付 → 守红线」在一个真项目上亲手合奏了一遍。接着照同样的节奏做 done 命令、补边界处理，就是完整的 todo-cli——整套打法一模一样，无非多转几圈那个回路。
💡 一句话总结：动手就是把六棒在真项目上跑一遍——立项配规矩和权限 → plan mode 出方案 → 审 diff 动手 → 亲手跑测试和功能验证 →
/code-review挑刺 → 看范围后 commit；记死最后一条红线——本地 commit 放手，push 远程自己把关。
08 一组对照：玩具练习 vs 真实项目，差距在哪
同样是「让 Claude 干活」，玩具练习和真实中等项目走出来天差地别——差的全在那几个「摊子一大才暴露」的地方。我把最常见的坑并排列出来，对着自查：
| 环节 | ❌ 玩具练习的随意打法 | ✅ 真实项目该有的打法 |
|---|---|---|
| 规矩 | 写三行 CLAUDE.md 就够 | 立项就把规矩 + 权限基线一起配好，管住后面所有会话 |
| 规划 | 一句话说需求直接干 | 先让它采访你逼出 SPEC.md，照它切块分会话 |
| 会话 | 一个会话从头干到尾，塞爆也不管 | 一块一个会话，/clear 收尾、--resume 接力、SPEC 当交接备忘录 |
| 外部 | 数据靠手动复制粘贴 | 该接 MCP 就接，但先验信任、数据库只读 |
| 质量 | 让写代码的自己审自己 | 派新鲜模型挑刺（/code-review），不让作者给自己打分 |
| 容错 | 改崩了就在烂摊子上硬补 | 干净退回（/rewind / git），勤 commit 留退路 |
| 交付 | 改完晾着，或不看范围乱提交 | 看范围 → 拟提交信息 → commit；push 自己把关 |
这张表的精髓就一句：玩具练习能省的步，真实项目一步都省不得——因为摊子一大，省掉的每一步都会在后面加倍还回来。 刚从「玩具」迈到「真实项目」那阵子，很容易把小任务那套随意打法原样搬过来，结果一个会话塞爆了硬撑、改崩了硬补、改完没审就提交，连环踩坑，那个本该两小时的活儿干了大半天。从这里就能认下一个理：项目越大，流程越要稳——流程不是拖慢你的镣铐，是让你能放心把摊子铺大的骨架。
还有个常被问的：「中等项目每步都这么讲究，不嫌慢？」 恰恰相反——正是因为讲究，你才敢把活儿交得更大、跑得更远。省掉规划和验证，看着快，实则把时间挪到了后面的返工里。
💡 一句话总结：玩具 vs 真实项目的差距，全在「摊子大了还省不省那几步」；规矩、规划、会话接力、外部信任、新鲜挑刺、容错退路、push 把关——这七处真实项目一步都省不得，省掉的会在后面加倍还回来。
09 सारांश
这一篇是整套教程的毕业设计——没教任何新功能，只带你当一回指挥，把前 47 篇学的零件在一个中等项目上合奏成一支完整的曲子。
把整支曲子的「总谱」串起来回顾，你会看清每个声部在哪一棒进场：
| 步骤 | 这一棒干什么 | 调动的声部（前篇） | 一句话关键点 |
|---|---|---|---|
| 立项 | 定项目 + 写 CLAUDE.md + 配权限基线 | 12 / 18 / 20 | 规矩和权限基线一次配好，管住后面所有会话 |
| 规划 | 采访出 SPEC、切块分会话 | 16 / 19 / 20 | 对话会清掉，SPEC 落成文件才能跨会话交接 |
| 接外部 | MCP 连文档 / 数据库 / GitHub | 22 | 「在复制粘贴数据」就是该接 server 的信号 |
| 分活 | subagent 探索 + 新鲜模型挑刺 | 23 / 29 | 隔离脏活护主上下文，别让作者给自己打分 |
| 容错 | 改崩了干净退回 | 37 | /rewind 撤编辑、git 回稳定提交，勤 commit |
| 交付 | 验证 → commit → push 把关 | 43 / 44 | 本地 commit 放手，push 远程自己捏着 |
你现在应该能： 拿到一个「帮我从零做个 XX 工具 / 服务」的中等需求，不再只会单会话怼一个小脚本——心里有这张总谱，知道立项就把规矩和权限配好、规划阶段逼出一份 SPEC、把大活儿切成几个会话接力着干，知道什么时候该接 MCP、什么时候该派 subagent 挑刺、改崩了怎么干净退回，最后干干净净交付、守住 push 那条红线。这一趟跑顺了，前 47 篇学的所有零件才算真正活了过来，能拧成一股绳替你干一件正经事。
整套教程的「实战」部分到这儿就圆满了——从第 39 篇的最小一趟，到这一篇的中等项目全流程，你已经把乐器和指挥都摸了一遍。
下一篇 49「最佳实践」——这一篇带你走通了「怎么做」，下一篇换个高度聊「怎么做得更好」：把官方和实战里踩出来的那些经验，浓缩成一份能反复翻的实践清单。想想看——同样跑完这趟流程，为什么有人三句话搞定、有人来回返工五轮？ 差距往往就藏在那些「说出来不起眼、做到了差很多」的习惯里，下一篇一条条给你拆开。