用 Claude Code 的 agent 做编码、营销、大型系统规划的一份硬核实践手册。核心只有三件事：把上下文当稀缺资源经营、让规格（spec）成为单一事实源、用编排而非堆叠把大问题拆小——这样新功能与大改动来临时，系统才不会塌。
# 不是 "帮我把这个做好" —— 而是: › 先进 plan mode：读 @SPEC.md 和 @src/，列出要改的文件、 接口签名、风险与回滚策略，先别动手。 › 把"调研 OAuth vs SAML 抽象层"分给一个 subagent， 只把结论拉回主线。 › 实现后，另起一个 subagent 对抗式审查 diff vs spec。
Claude Code 是一个能读整个代码库、制定计划、独立执行工具的 agentic CLI。在主循环之上，它给了你一套可组合的原语。最贵的错误，是用错粒度——什么都自己扛，或什么都丢出去。
有独立 context、独立 system prompt、可限制工具与权限的"专业工人"。结果以摘要回到主线。
用脚本编排 N 个 subagent（fan-out / pipeline），控制流是确定的循环与分支，可后台跑、可恢复。
只读代码、研究、给方案，不编辑。你审阅、编辑方案后再批准执行。大改动的安全带。
每个 session 都加载的项目级约定：构建命令、非标准规范、架构、踩坑点。团队共享。
把重复的多步骤工作流封装成可手动或自动触发的指令集，免得每次粘贴。
Hook 在生命周期事件上跑 shell（提交前查密钥、编辑后 lint）；MCP 连接 Jira/Slack/数据库等外部系统。
核心逻辑、要与你来回讨论、小改动——别外包，留在主 context 里做。
一次性的调研/搜索/独立审查。隔离上下文，只把结论拉回主线。
少量独立任务同时发（如 3 个方案、几处审查），一次性 fan-out 收齐。
大规模、可重复、要确定控制流（批迁移/审计）——写成可恢复的编排脚本。
每多塞进 1000 个无关 token，质量就掉一点。高手的做法不是"把所有东西告诉它"，而是只放该放的，把探索外包出去，主线只留结论。CLAUDE.md 也一样——它是约定清单，不是百科全书。
# Build - npm test — Jest；watch: npm run test:watch - npm run build — bundles ES modules # Code Style（只写"非标准"的） - 具名导出，不用 default export - 错误必须 try-catch 或 .catch()，不准吞 # Architecture - API handlers 在 src/api/handlers/ - DB 查询走 src/db/ facade # Gotchas（救命的踩坑点） - 新代码不准用 CommonJS - Redis 连接不在 cleanup 关会泄漏 - IMPORTANT: deploy 前先跑 migration
# Project Info This is a web app. We use Node, React, PG. Follow best practices for code quality. Use TypeScript. Test everything. Keep code DRY and well-structured. Documentation should be clear. ... 又 100 行通用建议 ... # 问题： · 全是 Claude 已经知道的常识 · 没有一条是"这个项目特有"的 · 白白占满 context、稀释真正的规则
把"搜索 / 读很多文件 / 审计"这种烧 context 的活 fan-out 给 subagent，它们各自在独立上下文里干完，只把结论送回——你的主线永远清爽。
大型系统真正的难点不是"写出来"，而是"新功能来了不塌"。把需求、接口契约、验收清单写进一份活的 SPEC.md，让 Claude 和人对着同一份事实源工作。每一步都被 spec 约束，改动就有了回流的锚点。
编码、营销、规划，底层都是"规划→并行→验证"，但编排重心不同。
大改动前一定进 plan mode：读代码、列改动点、给接口签名、评估风险。+5 分钟规划省 -30 分钟返工。
50 个组件迁移：用 workflow 并行多个 subagent，各自在隔离 worktree 改一个模块、各自出 PR，最后汇总审查。
让 3 个 subagent 各写一个落地页/邮件版本（技术向 / 转化向 / 极简向），再让一个评委 subagent 按清晰度·转化·品牌打分排名。
3 篇文章 × 5 种语言 = 15 个独立任务，用 workflow 一次铺开；再用一个 subagent 统一审品牌用词与语调一致性。
"设计支持 100M 用户的推荐系统"：让多个 subagent 各自独立给一套架构（中心化 / 去中心化 / 混合），评委按延迟·成本·失效模式打分，再综合成 ADR。
选定方案落成架构决策记录：为什么选它、成本、失效模式与缓解、还不确定的点与验证计划（先 A/B 10% 流量）。
默认用 pipeline（无屏障流水线）；只有当下一步真的需要"上一阶段的全部结果"时，才用屏障。
批处理：迁移、审计。任务彼此独立，最后合并。
有依赖的多阶段。墙钟 = 最慢单链，不浪费空转。
设计评审、多版本对比。独立生成，独立打分。
独立的怀疑者去推翻结论，挡住似是而非的发现。
未知规模的发现（bug/边界）。简单计数会漏掉长尾。
最后一个 agent 专问"还缺什么"，强制交付完整。
点右上角复制。把 @file 换成你的文件、方括号换成你的参数。
点开每一条看纠正方法；勾掉你已经避开的。