Claude-Code-Guide

很多企业现在已经过了“要不要用 AI”的阶段，真正的问题变成了：怎么让 AI 从一个局部工具，变成组织持续复利的一部分。 Anthropic 这份《Building AI agents for the enterprise》讲的核心不是某个产品功能，而是企业落地 AI agents 时的一条分水岭： 一边是把 AI 当成聊天框。员工问一句，它答一句；某个团队做一个 demo，短期看起来很酷，但很难进入真实生产流程。 另一边是把 AI 当成可以理解上下文、调用工具、执行多步骤任务的工作系统。它不只是回答问题，而是能参与员工工作、流程自动化和产品能力建设。 这篇文章我会从技术落地视角拆一下：企业为什么需要 agents，应该先改什么，怎么设计试点，以及哪些坑最容易让 AI 项目停在 demo 阶段。 1. Chatbot 和 Agent 的差别，不是界面，而是责任边界 很多企业的第一步都是上一个 chatbot：接 FAQ、查文档、总结会议、写邮件。 这当然有价值，但 chatbot 的工作方式通常是单轮的：用户提出问题，模型返回答案。它不负责拆解任务，也不负责调用系统，更不负责把结果落到某个业务流程里。 Agent 的边界更大。它需要能做几件事： 理解目标，而不是只理解一句 prompt 拆成多个步骤 在步骤之间保留状态 调用内部工具和数据源 根据中间结果调整路径 产出可以交付、审计、复用的结果 比如销售场景里，一个 chatbot 可以回答“这家公司是做什么的”。一个 agent 应该能从 CRM、会议记录、历史邮件、竞品库里拉数据，生成一份客户拜访 briefing，并标出风险、机会和下一步建议。 这就是差别。chatbot 是问答界面，agent 是工作流执行层。 2. 企业 AI 的第一件事：给模型组织上下文 通用模型默认不知道你的公司怎么工作。 它不知道销售团队怎么定义有效商机，不知道法务团队对合同条款的风险分级，不知道财务团队的科目口径，不知道市场团队的品牌语气。没有这些上下文，AI 只能产出“看起来还行”的通用内容，最后仍然需要人重新改一遍。 企业真正的效率来自把组织知识编码进去： 组织标准 ├─ 术语表 ├─ 品牌语气 ├─ 合规要求 ├─ 审批流程 ├─ 报表口径 ├─ 风险框架 └─ 工具连接方式 这个动作比选模型更重要。两个团队用同一个模型，结果差异可能非常大，原因不是模型能力不同，而是上下文质量不同。 ...

Anthropic 最近发了一篇文章，讲 Claude Code 怎么在大代码库里工作。它里面最有用的点不是某个 prompt 技巧，而是一个更工程化的判断：Claude Code 在大仓库里好不好用，很大程度取决于仓库本身有没有被整理成 agent 能导航的环境。 Claude Code 不是先把整个仓库做成一个中心化索引，再从索引里召回答案。它更像一个坐在你电脑前的开发者，会读文件、搜关键词、看目录、跟引用、跑命令。这个模式的好处是它看到的是本地最新代码，不太会被过期索引误导；坏处是你不能只丢一句“帮我改一下支付逻辑”，然后指望它在几十万行代码里自己精准落点。 在大代码库里用 Claude Code，重点是减少它的无效探索。 从相关目录启动 如果是 monorepo，不要每次都从仓库根目录启动。改某个服务，就先进入那个服务目录；改某个 package，就从 package 目录启动。 Claude Code 仍然可以向上读取父级 CLAUDE.md，但它的第一视角会更接近当前任务。搜索范围变小，读到的文件更相关，后面跑测试、lint、build 也更容易收窄。 可以把日常入口做成 alias： alias c-api='cd ~/repo/apps/api && claude' alias c-web='cd ~/repo/apps/web && claude' alias c-worker='cd ~/repo/services/worker && claude' 这种小动作比写一大段 prompt 更稳定。 写分层 CLAUDE.md 根目录的 CLAUDE.md 只放全局信息：系统大概怎么分层、关键目录负责什么、通用代码规范、绝对不能踩的坑。 不要把它写成百科全书。根文件每次都会进上下文，越长越容易把真正有用的信息挤掉。 更适合的结构是分层： repo/ CLAUDE.md # 全局架构、通用约定、关键禁忌 apps/web/CLAUDE.md # 前端启动、测试、路由、组件约定 apps/api/CLAUDE.md # API 测试、数据库迁移、错误处理约定 services/worker/CLAUDE.md # 队列、重试、部署前检查 子目录里的 CLAUDE.md 要写具体命令，比如： ...

Claude for Financial Services 是 Anthropic 提供的一套金融行业 Claude Agent、Skill 和插件参考库。它面向的不是某一个单点任务，而是金融团队每天都会遇到的材料整理、模型搭建、分析初稿和检查流程。 它适合经常和 Excel、PDF、财报、电话会 transcript、PPT 模板、市场数据、内部资料打交道的人。比如投行、企业融资、PE、二级研究、资管、财富管理、基金运营、财务运营，以及 onboarding / KYC 支持团队。 这类工作的共同点是输入材料多、格式要求高、人工重复步骤多。Claude 在这里承担的是起草和整理角色：先把资料读进去，按金融工作流生成一版可审核的输出，再交给专业人员判断、修改和批准。 适用谁 如果你经常需要产出 pitch book、估值模型、研究笔记、IC memo、对账说明或 KYC 审查结果，这个项目就比较对口。 投行和 PE 团队可以用它处理 pitch、估值、交易材料和投资备忘录；二级研究和资管团队可以用它整理财报、电话会、filings 和模型更新；基金运营和财务团队可以用它辅助对账、月结和 LP statement 审核；KYC 或 onboarding 团队可以用它做文件检查和缺口整理。 它不要求所有人都写代码。个人试用时，可以把它当作 Claude Code 或 Cowork 插件来用；企业落地时，也可以把同一套 Agent 接到内部系统、数据源和审批流里。 能做什么 项目里有两类能力。 一类是完整 Agent，适合跑一段端到端工作流。比如从公司资料出发生成 pitch deck 草稿，或者从财报和电话会出发起草 earnings note。 另一类是垂直插件和 slash command，适合处理更具体的任务，比如 /comps、/dcf、/lbo、/earnings、/ic-memo。这些命令更像是金融分析里的单项工具，用的时候给它材料和目标，它按对应方法产出初稿。 可以重点看四个代表 Agent。 Pitch Agent Pitch Agent 适合投行、PE 和企业融资团队准备 pitch 材料。 它可以基于公司资料、财务数据、行业信息和模板，辅助完成可比公司分析、precedent transactions、LBO、估值区间和 pitch deck 草稿。对 deal team 来说，它更像一个能先把材料铺好的分析师助手，最终版本仍然需要 banker 或项目组审核。 ...

日常用 Claude Code / Codex时，我会先配几条 alias，跳过频繁的权限确认。 配置 alias ccd="claude --dangerously-skip-permissions" alias codex="codex --ask-for-approval never --sandbox danger-full-access"

andrej-karpathy-skills Andrej Karpathy 曾是 OpenAI 早期成员，也在 Tesla 负责过 AI 相关工作，对大模型和工程实践都有很深的理解。这个 skill 很像是把他对 AI 编码的思考，整理成一套更可复用的行为规则：先理解问题，再动手修改；优先选择简单方案，避免过度设计；只改真正需要改的部分，尽量减少对现有系统的扰动。 GitHub：https://github.com/forrestchang/andrej-karpathy-skills everything-claude-code 这个仓库把自己定义为一个面向 Claude Code、Codex、Cursor、OpenCode 等工具的“agent harness performance optimization system”，覆盖 skills、memory、security、hooks、rules 和 research-first development, 将这些能力整合成一个完整的系统。 作者本人长期在 Claude Code 和自动化系统方向实践，这套配置是作者真实开发中持续打磨出来的一套 AI coding workflow。 总结：非常全面，如果在做开发时不知道装什么，那就选择这个吧。个人会觉得有些heavy了，会选择Manual Installation，挑一些我自己用到的部份。 GitHub：https://github.com/affaan-m/everything-claude-code superpowers Superpowers 不是单个 skill，更像是一套给 coding agent 用的软件开发方法论。它从 agent 启动时就开始接管流程：先确认你到底要做什么，再把需求拆成可读的设计说明；设计确认后，继续拆成足够细的执行计划；真正写代码时，用 TDD、代码评审、验证和分支收尾约束 agent，不让它凭感觉一路改下去。 它的核心价值不是多装几个命令，而是让 coding agent 形成固定工作流。比如新功能先 brainstorming，再 writing-plans；实现阶段走 test-driven-development；复杂任务交给 subagent-driven-development 或 executing-plans；做完后用 requesting-code-review 和 verification-before-completion 检查，最后用 finishing-a-development-branch 收尾。 GitHub：https://github.com/obra/superpowers 基础流程 brainstorming：需求还不清楚时用，先确认目标、边界、取舍和备选方案。 using-git-worktrees：方案确认后用，给任务开独立 worktree，避免污染当前工作区。 writing-plans：把已确认的方案拆成具体任务，每一步要有文件路径、操作说明和验证方式。 subagent-driven-development：按计划派发子 agent 执行任务，适合步骤多、上下文容易混乱的开发。 executing-plans：按计划分批执行，适合需要人工检查点的任务。 test-driven-development：实现功能或修 bug 前用，强制走 red、green、refactor。 requesting-code-review：阶段完成后用，先 review 再继续推进。 finishing-a-development-branch：整条开发分支完成后用，做最终验证、合并或 PR 决策、清理 worktree。 Skills Library 分类 Testing ...