AI Engineering 的变化速度比软件领域几乎任何其他方向都更快。
就在一年前，大家还在讨论 Prompt Engineering。几个月后，Retrieval-Augmented Generation (RAG) 成了所有问题的解决方案！
接着出现了 AI agents。然后是 multi-agent systems。然后是 MCP。然后是 Claude Code。然后是 autonomous coding。
在场有几个人指出，每一周都会带来另一个 framework、另一个 model、另一个 abstraction layer，或者另一个 best practice。
而我们大多数人都在努力跟上。工程师更关注的问题是：如何让 agents 持续工作数小时而不丢失 context、不烧掉 token、不过度偏离任务，并构建能够独立工作的 agents？
我确信的一点是，接下来的时代确实不只是写 prompts。
因为如今已经不再只是构建可扩展的 systems；而是要构建让 AI agents 可以连续工作数小时、彼此协作、管理自己的 memory、保持在预算内，并交付 production-ready code 的环境。
这正是本文要讲的内容。
我关于 How to Become an AI Engineer in 2026 的文章解释了要学习什么才能成为一名 AI Engineer（如果你还没读过，链接如下）：
2026 年如何成为 AI Engineer：从 Python 到 LLMOps 的完整学习路线图
这篇文章解释了如何构建你在 Claude Code 中每天真正会用到的 AI production stack。
这篇文章是那份 roadmap 的实战对应版本，提供 production AI engineering principles 以及可直接在 Claude Code 中动手的示例。我把它简化成了 四个关键组件，便于清晰理解。
让我们开始吧！
组件 1：Context & Memory Architecture
1. CLAUDE.md
把它想象成项目的 standing memory。Claude Code 在仓库中开始工作时会自动加载这个文件，因此它是存放关于项目 始终成立 的信息的理想位置。
README.md是写给人类用户看的，用来解释项目是什么以及如何安装或使用；而CLAUDE.md则是为 AI agent 优化的，里面包含压缩后的规则、命令和代码风格偏好，并会在每个 session 加载。
因此，之后的每一次 session 一开始就已经具备这些上下文。
它包含什么？
Build commands
Testing commands
Repository structure
Coding conventions
Naming standards
Preferred libraries
Architecture decisions
Team practices
Deployment commands
Important constraints
所有你不想在每次 session 里反复解释的内容，都应该放进这里！
一个实用的规则是：尽量控制在大约 200 行 以内。
一旦超过这个长度，就把与 workflow 相关的说明移到 skills 中，让它们只在 被调用时 才加载，而不是让 CLAUDE.md 变成一个杂物抽屉，在每一轮交互里都消耗你的 token。
我的一位同事给过我一个简单规则，我此后一直沿用：
如果它下个月仍然成立，就把它放进 CLAUDE.md。
CLAUDE.md 示例：
# Project: AI Support Platform
## Build
npm install
npm run dev
## Testing
npm test
## Linting
npm run lint
## Code Style
- TypeScript only
- Prettier formatting required
## Architecture
Backend
- FastAPI
Frontend
- Next.js
Database
- PostgreSQL
Vector Database
- pgvector
Never edit files under:
generated/
什么时候应该使用 Skills？
这是我们很多人一开始都会问的常见问题。
答案很直接：用 CLAUDE.md 存放 Claude 应该始终知道的信息。用 Skills 存放可复用的 workflows，例如：
Releases
Database migrations
Code reviews
Deployment
Incident response
Performance profiling
2. progress.md
它是用于那些 超出 单次 session 生命周期的工作的外部状态。CLAUDE.md 用来放关于项目始终成立的内容。当 Claude 按顺序处理一组任务时，它也需要一个 tracker，就像我们一样！
progress.md(或者你给 tracker 起的任何名字) 是用来记录某个具体工作当前 此刻 成立的内容
它包含什么？
What’s done
What’s blocked
What decision was made
Why the decision was made
把它当作一份发给一个对这段对话没有记忆的 Claude 版本的 hand-off note。
对于 Authentication，它可以包含这样的部分：
# Current Goal
Implement Authentication
## Completed
- OAuth
- Login UI
- User model
## In Progress
- Refresh tokens
## Blockers
Redis deployment issue
## Decisions
Using JWT instead of session cookies
Reason:
Stateless deployment
3. /compact
这是有意进行的 context pruning。当我连着刷 Greek mythology 的 YouTube 视频时，我现在真的会去 summarizethis tab 里整理一下，这样就不用把所有内容一股脑塞进脑子里。
同样地，随着 session 变长，context 会被 tool outputs、file reads 和那些已经不再重要的 dead ends 填满。
你只需要运行 /compact
它会 压缩 那段历史，让 session 可以继续运行，而不会撞上 context 上限，也不会把过时的噪音带入后续每一个决策。
我以前经常用这个，但有一天我的同伴指出了一个很有用的边界情况：
如果你准备在同一个 terminal 里让 Claude 执行一个完全无关的任务，而你不希望它继承之前对话的任何内容，因为那样实际上可能会伤害下一个任务呢？
比如你花了三个小时构建一个 RAG system。紧接着，你决定去处理个人博客。
Claude 还应该记得那个 RAG project 的所有内容吗？
不应该。
他建议我在这类真正无关的任务之间运行 /clear，而不是把一个任务的 context 硬带到下一个任务里。
/clear 比起对一个本来就不需要那么多历史的 session 做 compact，要 便宜 得多。
组件 2：Opus 4.8 and Dynamic Multi-Agent Workflows
当我们在房间里投票，问大家在需要对一个庞大而陌生的 codebase、**** architecture decisions、cross-file refactors，或者任何早期判断错误会在后续不断放大的任务上，最常用什么工具时，大多数人的手都指向了同一个答案：
是 Claude Code 里基于 parallel workflows using 类似**claude-opus-4-8.** 的模型。
另外：如果你的团队可以使用 Claude Fable 5，它在长周期任务上是更强的选择，但在围绕它构建 workflow 之前，最好先确认当前可用性。
这里有两种 orchestration model：subagents 和 dynamic workflows：
1. Subagent
Subagent 是一个独立的 Claude 实例，拥有自己的 context window，通过 Task tool 启动，用来隔离一块工作，例如探索目录、运行测试套件，或从主对话中研究某种做法。
因此，它带着一个干净的 context 进入工作：自己的 system prompt、delegation message、相关的 CLAUDE.md files，以及别的什么都没有。
Root Orchestrator
│
├── Backend Agent
├── Frontend Agent
├── Test Agent
├── Documentation Agent
└── Dependency Agent
Note：它 不会inherit 父级对话历史，这正是重点；它只做 一件事，并 返回一个干净的结果。
2. Dynamic workflows
当 subagents 被动态创建时，它们会变得很强大。可以把它理解为 orchestrator 在运行过程中临时生成工作，而不是你事先把每一个分支都 scripting 好。
你让 orchestrator 来决定：
需要多少个 agents
每个 agent 应该做什么
它们什么时候运行
它们什么时候停止
Dynamic workflows 允许一个 orchestrating agent 为仓库范围的任务生成一整棵 subagents 树，而不需要你手工指定每个分支。
Root Agent
┌──────────┼──────────┐
Backend Frontend Payments
│ │ │
Test Agent Test Agent Test Agent
│ │ │
Results Returned to Root
在 Claude 中，subagents 最多可以嵌套到 五层 深。这种模式对大型 repository 的扩展性要好得多。
示例架构：
每个 subagent 都会得到一套狭窄、只读受限的 tool set，没有
Edit或Write,，所以真正提交更改的只有 parent agent。
组件 3：Token Financial Management and Effort Control
房间里很多团队都承认，他们在这方面遇到了困难。每个团队都在努力完成任务，同时避免烧掉成千上万不必要的 token。
Effort 是一个独立于 model choice 的调节项
Claude Code 提供 五 个 effort level：
Low
Medium
High
xHigh
Max
它们控制的是模型在行动前会进行 多少 reasoning，而不受你选择的模型本身影响。
在同一个任务上，更高的 effort 可能意味着大约是较低设置 7 倍 的 token 开销，因此这个调节项和 model-selection 决策一样重要。
工作分配模式
Role-Effort
对于 root orchestrator：high
因为它在做那些会决定下游正确性的决策。
执行型 subagents：low / medium
任务范围窄、定义明确（例如运行这个测试、应用这个修改、重命名这个符号），不需要深度 reasoning；它们需要的是可靠且低成本地执行。
一次性的深度分析：ultrathink
这是一个 single-prompt keyword。对于单个困难问题，在不永久提高 session 保存的 effort level 的情况下，可以使用它。
我们中的一位工程师告诉大家，
opusplan是一个 model alias，它在 planning 阶段运行 Opus，并在执行阶段 自动切换 到 Sonnet。
当你希望在 plan 上获得最高等级的判断，但又不想为机械执行部分支付 Opus 的费用时，它就很有用。
ultracode 结合了 xhigh effort 和针对任务使用多-agent workflows 的持续权限。
它很强大，因此更适合真正需要这么高自治度的任务，而不是默认就把它当成常规选项。
条件验证 > 全量验证
很多 agentic scaffolding 会在每一步之后都跑一遍完整验证，例如重新阅读 diff、重新跑完整测试套件、在每一步之后重新检查假设，不管那一步有多 trivial！
Single File Changed
↓
No Shared State?
↓
Skip Full Verification
把它替换成 conditional verification，例如只在步骤触及了共享状态、crossed 了模块边界，或者 subagent 自己的 confidence signal 较低时，才触发昂贵检查，这样可以在不放弃真正重要的安全网的前提下，减少相当一部分重复的 token 开销。
Authentication Modified
↓
Shared State Changed
↓
Run Full Verification
只有在你 确实需要 时才跳过 full verification。
一个成本感知型 workflow 示例（effort + verification）
New Task
│
Does it require architectural reasoning?
│
┌──┴───────────────┐
│ │
Yes No
│ │
High Effort Low/Medium Effort
│ │
Create Plan Execute Directly
│ │
Delegate Work Complete Task
│ │
Need Verification?
│
┌──┴───────────────┐
│ │
Yes No
│ │
Run Checks Finish
组件 4：Ambient Execution and Safety Navigation
我们 meetup 上讨论的另一个有趣功能是 /remote-control。
它把一个正在运行的 本地 Claude Code session 连接到 Claude mobileapp 或浏览器，这样你就可以通过手机监控并引导一个长任务。
你的 session 会一直在你自己的机器上运行。
Note：mobile 和 web 界面只是那个本地 session 的一个窗口，不是把它迁移到 cloud file system access (workflow below)
Your Laptop
├── Repository
├── File System
├── MCP Servers
├── Claude Code Session
└── Local Environment
▲
│
Phone / Browser
(View + Control)
Automated PR handling
我们都提到过的、最有用的 production integrations 是 Claude Code 的官方 GitHub Action。
通过 @claude mention 触发，在每次 PR push 时自动 review，并在 inline comments 上按 confidence 评分，这样低信号噪音会在到达人工之前就被 filtered 掉；而且当 issue 被打上标签时，还可以让 Claude 自动修复。
正如你可能意识到的，这意味着这个 agent 已经参与到你团队的 actual review pipeline, 中了，同时也意味着 Claude 现在在你的 repo 上拥有 write permission。
所以我的建议是：有意识地限定 GitHub App 的权限，而不是默认就授予宽泛访问。
示例 workflow #1
Developer
↓
Push Branch
↓
Pull Request
↓
Claude Reviews
↓
Inline Suggestions
↓
Developer Fixes
↓
Human Review
示例 workflow #2
Issue
↓
Label Added
↓
Claude Starts Working
↓
Creates Branch
↓
Implements Fix
↓
Pull Request Created
无论如何，通过尽早发现常规问题，人工 reviewers 可以把更多时间放在 architecture、design decisions 和 business logic 上。
避免 false-positive injection flags
Claude Code (就像任何带有 tool access 的 agentic system 一样) 会运行 safety checks，检测那些看起来像是在尝试覆盖模型行为的 prompt-injection patterns 和 instructions。
但它们有时也会误触这些检查！
解决办法
用你自己的话说明你想让它做什么，以及为什么要这样做，而不是把 prompts 组织得看起来像 system-level overrides、adversarial framings 或者嵌套的 ignore previous instructionspatterns。
即使你的意图完全正当，这种措辞模式也正是 safety layer 设计用来捕获的对象。
在 CLAUDE.md 和你的 prompts 中使用清晰、直接的任务描述，本身也是更好的 engineering practice。
入门参考结构
现在你已经了解了这四个组件，可以把下面这个当作起点。
按照下面的步骤开始构建每个组件，并根据你自己的 repo 调整 effort level 和 subagent 边界！
Step 1
Create CLAUDE.md
↓
Step 2
Add progress.md
↓
Step 3
Create agents
↓
Step 4
Add Skills
↓
Step 5
Add GitHub workflow
↓
Production ready repository
GitHub Repository link:
https://github.com/moonpiee/The-2026-AI-Engineering-Production-Starter-Stack-with-Claude-Code/
我一直在看到的常见错误
Engineers 把 Claude Code 当成 ChatGPT，而不是一个 engineering environment。
把所有内容都塞进
CLAUDE.md每个任务都用 maximum effort 运行
从不使用
/clear跳过
progress.md给每个 subagent 都开放 writeaccess
在每个微小改动后都运行 expensive verification
对并不受益于并行化的工作使用 multiple agents。
Frequently Asked Questions
这些是我在学习阶段整理出来的问题，应该能帮助你形成扎实的理解。
为什么 CLAUDE.md 要用 Markdown 写？
Markdown 对人和 AI 都很容易阅读，因此非常适合存放项目规则、命令和 conventions。所以这是双赢的。
README.md 和 CLAUDE.md 有什么区别？
README.md 是给人类解释项目的。CLAUDE.md 是告诉 Claude Code 如何 在项目上工作。
CLAUDE.md 应该多大？
保持简洁（大约 200 行 左右）。把与 workflow 相关的说明移到 Skills 中。
一个 repository 可以有多个 CLAUDE.md 文件吗？
可以。大型 repository 可以使用 nestedCLAUDE.md 文件，为不同目录提供专属说明。
什么时候该用 Skills，而不是 CLAUDE.md？
CLAUDE.md 用于永久性的项目规则，Skills 用于可复用的 workflows，例如 deployments、releases 或 debugging。
/compact 和 /clear 的区别？
用 /compact 来总结当前 session 并继续工作。用 /clear 来以全新的 context 开始一个完全不同的新任务。
应该创建多少个 subagent？
只创建完成独立任务所需的数量。记住，更多的 agents 并不总是意味着更好的结果！
每个项目都需要多个 agent 吗？
不需要。小项目通常用单个 agent 就能很好地工作。只有在工作可以并行化时才使用多个 agents。
更高的 effort 总是带来更好的结果吗？
不会。规划和架构用更高 effort，日常实现用更低 effort，以节省 token。
Claude Code 能取代 code review 吗？
不能。它会通过捕捉常见问题来 加速 review，但对于 architecture 和 business logic，human reviewers 仍然是必需的 __。
随着 Claude Code 演进，这些 workflow 还会适用吗？
会。commands 和 models 可能会变化，但我提到的核心原则，比如 memory、task decomposition、verification 和 automation，仍然有价值。
Claude Code 比 Cursor、GitHub Copilot 或 Codex 更好吗？
每个工具显然都有各自的优点。本文中的 workflows persistent memory、context engineering 和 orchestration，也可以适配到许多 AI coding assistant 上。
最后的想法
未来几年里的 AI engineers，不一定会是那些在用最新 model 或最新 framework 的人。
他们会是那些知道如何 design 出让 AI 能高效工作的环境的人：具备 persistent memory、specialized agents、clear context、cost-aware reasoning 和能够 scale 到单次 chat session 之外的 production workflows 的 repositories。
Claude Code 是这种未来的一种实现。
无论你是在构建 internal copilots、enterprise RAG systems、AI agents，还是 developer tooling，底层原则都保持不变：
给 AI 正确的 context。
把工作拆成专门化的 tasks。
把 reasoning 花在该花的地方。
进行智能验证。
把 AI 当作另一位工程师，而不仅仅是 autocomplete。
Commands、Models 和 Features 会持续演进，但这些 engineering principles 会长久得多。
祝你构建顺利 ❤️