在 .NET 项目中使用 Claude Code 时…

为 .NET 开发者设置和优化 Claude Code：并行会话、计划执行、验证、权限与格式化钩子、提示词、子代理和上下文节流。

适用场景

解决思路

1. 用 3-5 个 Claude 会话并行，而不是串行；每个会话用 git worktree 获得独立文件和零冲突。
2. 创建 worktree：git worktree add ../my-project-feature origin/main；git worktree add ../my-project-bugfix origin/main；git worktree add ../my-project-tests origin/main；然后在每个 worktree 启动 Claude：cd ../my-project-feature && claude，cd ../my-project-bugfix && claude，cd ../my-project-tests && claude。
3. 并行 .NET 工作流分配：feature worktree 构建新 endpoint + handler；bugfix worktree 修复失败 CI 测试；tests worktree 为已有功能写集成测试；analysis worktree 用 Roslyn MCP 只读研究、读日志、审架构。
4. 并行会话技巧：终端 tab 按任务命名；用 shell alias（如 alias zf='cd ../my-project-feature'）一键切换；开启终端通知，知道哪个会话需要输入。
5. 配置 .NET 自动格式化 hook：在 .claude/settings.json 的 hooks.PostToolUse 加 matcher 为 Write|Edit，command 为 dotnet format --include "$CLAUDE_FILE_PATH" --no-restore 2>/dev/null || true。
6. 格式化 hook 末尾使用 || true，确保失败（如非 C# 文件）不会阻塞 Claude 工作流。
7. 预允许安全 .NET 权限：在 .claude/settings.json 的 permissions.allow 中加入 Bash(dotnet build *)、Bash(dotnet test *)、Bash(dotnet run *)、Bash(dotnet ef *)、Bash(dotnet format *)、Bash(dotnet restore *)、Bash(dotnet pack *)、Bash(dotnet tool *)。
8. 把 .claude/settings.json 提交到 git，让团队共享无摩擦工作流。
9. 对任何非平凡任务先 plan then execute：在 plan mode 迭代到计划无懈可击，再切到 auto-accept 执行。
10. Plan Mode 操作：按 Shift+Tab 两次进入 plan mode；描述任务并给足上下文；迭代计划，质疑假设，问 what about edge cases?；计划稳固后切回普通模式；让 Claude 用 auto-accept 执行，通常 1-shot 实现。
11. 高级计划审查：让一个 Claude 写计划，再开第二个 Claude 会话以 staff engineer 身份审查，提示 Review this plan as a staff .NET engineer. Challenge every assumption. What could go wrong? What's missing? What would you do differently?。
12. 实现偏离计划时立即 STOP；不要硬推，切回 plan mode，理解变化，重新规划，再继续。
13. 验证闭环：在声明完成前总是让 Claude 运行 dotnet build、dotnet test、get_diagnostics、dotnet format --verify-no-changes；完整 7 阶段验证见 verify skill。
14. 通过修正复合知识：每次纠正后，在 MEMORY.md 记录一条泛化规则，避免同一错误复发；完整系统见 instinct-system skill。
15. 提示词—挑战：Grill me on these changes. Would this pass a staff .NET engineer's code review? Check for: N+1 queries, missing CancellationToken, exposed domain entities, missing validation, incorrect service lifetimes.。
16. 提示词—要求证明：Prove this works. Run the tests, show me the output. Then diff the API response between main and this branch.。
17. 提示词—平庸修复后重做：Knowing everything you know now, scrap this and implement the elegant solution. No hacks, no workarounds.。
18. 提示词—EF Core migration：Generate the migration, then show me the raw SQL it produces. I want to verify the migration before applying it.。
19. 子代理优先路由到工具包 10 个专家：dotnet-architect、code-reviewer、refactor-cleaner、test-engineer、security-auditor、build-error-resolver、ef-core-specialist、api-designer、performance-analyst、devops-engineer。
20. 使用子代理示例：Run the code-reviewer agent on my changes before I create the PR.；Have refactor-cleaner simplify the files I just modified.；Send the failing CI log to build-error-resolver.。
21. 为工具包未覆盖的工作流创建项目级子代理：在 .claude/agents/ 放 markdown 文件，包含角色、编号任务列表、必需报告格式（PASS with summary / FAIL with specifics）；每个 agent 只负责一个关注点。
22. 把子代理同时当作上下文隔离子室，按 Context Discipline 决定何时卸载、何时留在主上下文。
23. Token 经济：优先用 Roslyn MCP 查询；一次 Roslyn MCP 查询约 30-150 tokens，读文件约 500-2000+ tokens。
24. 理解类型时先用 MCP：例如理解 OrderService，用 find_symbol → get_public_api → find_references → get_type_hierarchy 四次调用约 310 tokens；读四个相关文件约 2900 tokens；然后只读将要修改的方法。
25. 完整文件读取只保留给即将编辑的文件。
26. 子代理卸载矩阵—卸载到子代理：探索不熟悉代码（>3 个文件）；研究需要文档或多个文件；输出冗长（测试运行、诊断、比较）；过程冗长但答案简洁。
27. 子代理卸载矩阵—留在主上下文：修改已读过的文件；快速查找（1-2 次 MCP 查询）；基于与用户进行中对话的工作。
28. 要求子代理返回压缩答案：Trace the auth flow from login to token validation. Return numbered steps with file:line references.；得到约 300 tokens 的发现，而非 15k tokens 原始文件。
29. 文件读取优先级：PRIORITY 1 将要修改的文件完整读取；PRIORITY 2 必须满足的契约只读接口、跳过实现；PRIORITY 3 参考模式先 get_public_api，不够再读；PRIORITY 4 一般上下文让子代理总结，绝不在主上下文读取。
30. 绝不读取：整个目录（用 get_project_graph）、仅作上下文的测试文件（用 get_test_coverage_map）、生成文件/migrations、除非需要的配置。
31. 复杂任务前做预算规划：理解 ~5k（MCP + 子代理）、计划 ~2k、实现 ~15k（读目标 + 写 + 迭代）、验证 ~3k，把窗口大部分留给对话。
32. 上下文警告信号：10+ 文件已读、50+ 轮交流、忘记早期细节、重读已经看过的文件。
33. 上下文恢复：用 5-10 行总结已知信息 → 剩余探索交给子代理 → 只用 MCP 查询 → 若仍退化建议新开会话。
34. 大型代码库（50+ projects）：get_project_graph → 缩小到 2-3 个相关项目 → 对关键类型 find_symbol → 对接口 get_public_api → 只读将要修改的文件 → 跨切面关注交给子代理。
35. Lazy Skill Loading：不要预先加载技能 just in case；15 个技能各约 300 tokens，会在开工前花掉约 4500 tokens；相关时会话开始加载 modern-csharp；ef-core、testing 等主题出现时再加载。
36. 复杂任务不要跳过 plan mode：不要直接让 Claude Refactor the Orders module to use DDD with aggregates and value objects；应进入 plan mode，规划哪些文件变化、聚合边界、值对象如何映射 EF Core、迁移策略。
37. 能并行时不要单会话串行：不要顺序 feature 20min → tests 15min → formatting 5min → docs 10min = 50min；应在三个 worktree 同时做 feature、tests、docs，墙钟约 20min。
38. 不要接受第一个解决方案：不要 Looks good, ship it；应问 Would a staff .NET engineer approve this? What about the service lifetime? Is this N+1 safe? Is there a more elegant way using C# 14 features?。
39. 不要因为窗口大就加载所有内容：不要读 Orders 模块 30 个文件、15 个测试文件、docker-compose.yml、每个 migration；应 MCP get_project_graph + find_symbol，读实际修改的 2-3 个文件，其余子代理总结，约 3k tokens。
40. 按 Decision Guide 执行：任务涉及 3+ 文件先 plan mode；简单 bug fix 直接修并用 dotnet test 验证；需要 build + test + review 用 3 个并行 worktrees；CI 持续因 format 失败加 PostToolUse format hook；厌倦权限提示预允许 dotnet * 命令；Claude 犯错让它更新 CLAUDE.md；代码 hacky 要求 elegant solution；想验证架构开第二会话当 staff reviewer；重复 PR 流程路由到 kit agents 或创建项目子代理；学新代码库通过 /config 用 Explanatory output style；需要类型 API 或位置用 get_public_api / find_symbol，不要读文件；需要修改文件则完整读取；探索不熟悉代码开子代理；已读 10+ 文件暂停并切 MCP + 子代理；上下文沉重或迟钝先总结已知、之后用子代理；大型代码库用 MCP-first、subagent-heavy、只读修改文件；新主题按需加载技能，不要提前。

适用边界 · 注意事项

• 不适用于非 Claude Code 环境或非 .NET/dotnet CLI 工作流；这些 hooks、permissions、MCP 工具、agents 依赖该生态。
• 简单单文件 bug 修复不需要 plan mode 或并行 worktree，直接修复并用 dotnet test 验证即可。
• 当项目无法使用 git worktree、MCP 或子代理时，不要强行套用并行/卸载策略；改用普通单会话和文件读取。