最近不少人来问我说看到 Anthropic 在分享AI 自主开发复杂应用的工程实践既兴奋又犯嘀咕兴奋的是 AI 编程终于从写个函数补全进化到能自己吭哧吭哧把整个项目搭起来犯嘀咕的是这玩意儿到底是真能落地还是大厂秀肌肉的 demo。我干脆把自己这段时间用 Claude Code 跑真实项目、把一个需求从拆解到交付的全过程整理成文包括任务怎么拆、上下文怎么管、权限怎么配、模型怎么选、翻车了怎么救尽量把每个决策背后的为什么也讲清楚。这篇文章适合正在做 AI 应用开发、想引入 AI Agent 到研发流程里的团队也适合虽然还没上手但想搞明白这套玩法原理的开发者。先说结论AI 自主开发复杂应用这件事2025 年已经不是能不能的问题而是怎么组织工程流程的问题。它不像很多人想象的那么玄乎也没有宣传里那么全能。真正跑通之后你会发现它本质上是一套新的协作范式——把模型、工具、测试、人这四样东西按正确的顺序串起来。串得好一个人能顶一个小团队串不好模型就是一台昂贵的自动生成 bug 机器。1. 先搞清楚什么叫AI 自主开发而不是AI 帮你写代码很多人把 AI 编程理解成对话框里下个需求直接给你吐一个完整项目。这是对自主开发最大的误解。真实工程实践里AI 自主开发的准确含义是给定一个明确目标、一组可用工具和清晰的约束AI 能够自主完成计划、编码、验证、修复的循环并且在必要节点把决策权交还给人类。它不是取代开发者而是把开发者从键盘上的执行者变成目标定义者和质量把关人。1.1 从自动补全到 Agent到底变了什么2018 年到 2022 年的 AI 编程工具本质是超级联想输入法。你写一个函数名它帮你补函数体你写一行注释它帮你补一段逻辑。它的工作单位是代码片段决策权始终在你手里。2023 年到 2024 年的 Copilot Chat 类工具进化到结对程序员。你问它这个接口怎么设计它给你一段建议你说帮我 review 这段代码它输出意见。但它仍然是被动的——每次对话都由你发起它只对你提问的局部负责。2024 年底到 2025 年的 Agent 形态Claude Code、Codex CLI 这类工具是典型代表才是真正意义上的自主开发。它的工作单位变成了任务。你告诉它实现用户注册功能它自己会去读项目结构、找相关文件、设计数据表、写接口、补充测试、跑测试、看到失败再去修。它会调用工具会读文件、写文件、执行命令会自主决定先做什么后做什么。这个转变是根本性的从你说一句它做一步变成你说目标它走完整个循环。1.2 自主开发的边界不是无人值守而是人机分工我在实际项目中最重要的体会是AI 自主开发的正确姿势不是无人值守而是在关键节点有人守。最理想的流程是让 AI 在它擅长的领域全速前进在它不擅长的领域把问题清清楚楚地抛回给你。什么是 AI 擅长的广度遍历、模式识别、模板化实现、写测试用例、改错别字级别的 bug、把一个大需求切成可执行的步骤。什么是不擅长的产品方向的权衡、架构上的根本性取舍、涉及合规或安全边界的决策、以及项目里只有资深工程师才知道的隐性约束。所以我在每个项目里都会提前定义好AI 可以自主决定什么、必须停下来问什么。比如函数怎么命名、文件放哪个目录、测试怎么写——这是执行细节AI 自己定数据库表结构、对外 API 契约、是否引入新依赖——这是契约边界必须人审。有了这个边界AI 的自主性才不是风险而是效率。1.3 这套打法适合谁、适合什么项目先说适合谁。它最适合两类人一类是有一定工程经验的开发者想做自己 side project 或者小团队里身兼数职的全栈工程师另一类是团队里负责搭建研发基础设施的人想把 AI Agent 接进 CI/CD 流程。纯新手直接上手会有挫败感因为 AI 生成的代码一旦报错你还是得能看懂错误、判断它修得对不对。再说适合什么项目。从实际经验看边界清晰、可验证、有大量模板化内容的项目最受益内部工具、CRUD 管理系统、数据切片脚本、前端页面搭建、代码迁移重构。反过来需求高度模糊、评价标准主观、需要大量领域知识的项目比如一个推荐算法的核心策略、一套未知性能瓶颈的分布式系统优化AI 能做的只是辅助分析和出草案离自主还很远。2. 工程化落地的四个核心设计把 AI 从能写代码变成能开发应用关键不在模型本身而在你围绕模型搭的这套工程框架。我总结为四个核心设计任务拆解、上下文管理、工具与权限、反馈闭环。这四个设计任何一个缺位整个系统就会退化成高级自动补全。2.1 任务拆解把一句话需求变成可执行的子任务模型和人类一样一次只能专注有限的工作。你丢给它一句做一个电商后台它大概率会给你一个四不像。但如果拆成第一步设计订单表结构第二步写订单 CRUD 接口第三步做订单列表页面第四步写接口测试每一步的目标就清晰可验证了。我常用的拆解原则是一个子任务对应一个可验收的结果。所谓可验收就是 AI 自己或者工具链能判断做完了、做对了——测试通过、代码编译通过、页面能渲染。拆解粒度通常控制在 30 到 60 分钟能完成的工作量太大模型容易迷失太小交互成本太高。具体做法上我会先让 AI 读项目结构和需求说明输出一份开发计划也就是它打算怎么拆。这个计划本身就是很好的对齐工具——你会发现 AI 对需求理解的偏差在这个阶段就能暴露比等它写完代码再发现要省钱得多。计划确认后再进入执行阶段。2.2 上下文管理模型的内存是有上限的这是整个实践里最被低估的环节。模型不是鱼但它的记忆确实只有那么大——上下文窗口。Claude 的长上下文能力已经很强但你如果真把它当成无限内存来用结果就是对话进行到第 20 轮它开始忘记第 3 轮确定的技术方案文件读多了它开始把 A 模块的变量名套到 B 模块里。我的管理思路有三个第一只给必要上下文。启动任务时明确告诉模型要看哪些文件、不要全目录扫描。Claude Code 里可以通过路径约束和 ignore 规则控制它的读取范围别让它一上来就把整个 monorepo 塞进上下文。第二善用项目文档而非对话历史。凡是确定下来的决策、约束、规范都写进 CLAUDE.md 这种项目文档里而不是依赖对话上下文。模型每次干活前会先读这个文档比你在对话里反复强调靠谱得多。第三及时开新会话。一个子任务做完了就开新会话做下一个。新会话里用文字把已完成部分下一个目标关键约定讲清楚留给模型的内存就是干净且充足的。我见过太多人一个会话从早跑到晚最后模型开始答非所问就是因为上下文里堆了太多互不相关的中间过程。2.3 工具调用与权限模型给 AI 配一个受控的执行终端AI 自主开发之所以能成立是因为它不再只是输出文本而是能直接操作系统读写文件、执行命令、运行测试、甚至提交代码。这就带来一个关键问题——权限怎么给Claude Code 的权限模型我理解为三个层级plan只读探索、acceptEdits可以改文件但关键操作需确认、bypassPermissions完全自主执行。我的经验是默认用前两级跑通整个流程后再有选择地放开第三级并且配合 ignore 规则和命令白名单做兜底。比如我会把rm -rf、git push这种危险命令加入拦截名单把允许执行测试命令不允许执行部署命令写进配置。权限控制的哲学是给 AI 足够的自由度做执行层的事但把对外产生影响的动作全部留给人。换句话说改文件随便改推到生产必须经我的手。这套规则跑了一个多月基本没出过大乱子。2.4 反馈闭环测试就是 Agent 的眼睛AI 写代码最不靠谱的地方在于它经常自我感觉良好——它觉得自己写对了实际上编译都过不了。这时候如果没有人类和工具链给它反馈它就会在错误的方向上一路狂奔。所以反馈闭环是自主开发能不能成立的分水岭。闭环里最重要的工具是测试。我给 AI 定了一条硬性规则任何功能任务完成定义里必须包含相关测试通过。AI 写完代码自己跑测试跑挂了就自己看日志修修完再跑。这个过程里测试就成了它的眼睛不用你一步步盯。除了测试还有编译检查、lint 检查、类型检查。这些自动化的校验越完善AI 的自主性就可以放得越开。反过来说如果项目的测试基建很差AI 自主开发的体验也会很差——它飞不了多高就摔下来了因为没有任何东西能告诉它对错。3. 从零搭建一个可复制的开发闭环理论讲再多不如动手跑一遍。这一节我用一个实际例子带你完整走一遍流程目标是给内部运营团队做一个活动配置管理系统技术栈是前后端分离后端用 Python FastAPI前端用 React数据库用 PostgreSQL。这个例子足够典型既能覆盖 CRUD 和页面开发又有数据库设计和接口联调这种复杂环节。3.1 项目初始化CLAUDE.md 是给 AI 看的项目文档很多人初始化项目时只想着代码结构忽略了给 AI 写一份使用说明书。CLAUDE.md 就是这份说明书。它放在项目根目录AI 每次干活前都会自动读它作用相当于给一个新入职的工程师看团队 wiki。我的 CLAUDE.md 通常包含这几块内容# 项目说明 - 项目定位内部运营活动配置系统用户是运营团队日均操作量级低 - 技术栈FastAPI SQLAlchemy React Vite PostgreSQL # 关键约定 - 后端接口统一前缀 /api/v1 - 数据库表名使用 snake_case字段必须包含 created_at 和 updated_at - 前端组件统一用 TypeScript禁止使用 any - 所有新功能必须附带 pytest 测试 # 常用命令 - 启动后端uvicorn app.main:app --reload - 跑测试pytest - 启动前端npm run dev - 前端构建检查npm run build注意这里写的是关键约定而不是全部规范。只放那些一旦违反就要返工的高价值约束把细枝末节留给模型自己发挥。文档写得好AI 的产出会明显更贴合项目风格写不好或者不写它每次都会按自己脑子里的通用模板来风格跟你团队的代码完全不是一回事。3.2 提示词与任务说明书的写法项目初始化完之后每个功能任务我都会写一份简短的任务说明书。它不是那种套话提示词而是把这次任务的验收标准、约束、起始点都讲清楚。举一个我实际写过的例子任务实现活动列表页支持分页和按状态筛选 背景活动表 act_activity 已存在字段包括 id/title/status(1草稿 2进行中 3已结束)/start_time/end_time。 后端 /api/v1/activities 接口已实现支持 page、page_size、status 参数返回格式为 {total, items}。 要求 1. 在 pages/ActivityList.tsx 实现列表页使用 antd Table 组件 2. 表格列活动标题、状态用标签显示、开始时间、结束时间、操作列编辑按钮跳转到 /activity/edit/:id 3. 实现分页切换和状态筛选筛选变化后重置到第一页 4. 前端请求统一走 src/api/request.ts 里的封装的 axios 实例 5. 完成后运行 npm run build确保类型检查和构建通过 注意不要修改后端代码和数据库结构本任务只做前端页面。这个说明书的要点是给了起始状态表结构、接口已存在、给了验收标准构建通过、给了约束只做前端。写清楚这三样AI 的执行路径就非常明确几乎不会跑偏。你可能会觉得每次写说明书麻烦但比起AI 胡写一通你再返工这几分钟的投入回报率极高。3.3 跑通规划-实现-验证-修复循环我通常用如下方式启动任务。在 Claude Code 里输入任务说明书然后让它先输出开发计划计划确认后进入执行。以下是我这边的实际操作记录你可以对照参考。第一轮AI 输出计划读取src/api/request.ts确认请求封装方式、读取现有列表页参考风格、创建ActivityList.tsx、引入 antd Table、实现筛选和分页、运行构建。计划合理我确认执行。第二轮AI 开始写代码。它自动创建了ActivityList.tsx参考了项目里已有的另一个列表页的写法把请求参数拼好、渲染逻辑写好。期间它自己发现Activity类型还没定义于是主动在src/types/activity.ts新增了类型定义。到这里一切正常。第三轮运行npm run buildTypeScript 报了一个错分页组件的onChange参数类型不匹配。AI 自己读了报错信息修改了事件处理函数的签名重新构建通过。四轮交互一个包含分页、筛选、状态标签的列表页就完成了。这个流程里我只做了两件事写说明书、确认计划。剩下的事情——读代码、写代码、修 bug——全是 AI 自主完成的。而且注意它的验证方式不是我目测代码应该没错而是真正跑了构建命令拿到了编译器的反馈。3.4 用 Hooks 把 AI 接进现有工程流如果你希望 AI 不只是开发时用还能在 CI/CD 流程里自动帮你做某些事Claude Code 提供了 Hooks 机制。它可以在特定事件发生时自动执行脚本。我在项目里配置了两个最常用的第一个是PreToolUse钩子在 AI 执行特定命令前做校验。比如我写了一条规则当 AI 尝试执行git push或npm publish这类命令时直接拦截并提示发布类操作需要人工执行。这就是前面说的权限兜底的一种自动化实现。第二个是Stop钩子在 AI 完成一轮任务后自动运行一个脚本检查是否有未提交的改动、测试是否全过然后把结果汇总成一条消息通知到团队聊天工具。这样 AI 干活的时候你不需要一直盯着它每完成一个阶段你收到一条进度汇报就够了。Hook 的配置不复杂在项目根目录的配置里声明事件、命令和运行条件就行。真正难的是想清楚哪些节点需要介入——介入太多就成了人工指挥介入太少风险不可控。我的切分原则是一切读和执行都放权一切对外发布和不可逆操作都拦截。4. 关键参数与成本控制细节聊完流程说说更偏配置层面的东西。同一套流程参数配得好不好体验差别非常大。这一节把模型选择、采样参数、成本控制三个问题讲透。4.1 不同场景下如何选模型Anthropic 的模型家族里我日常用得最多的是三个Opus 级别负责最难的任务Sonnet 级别负责大多数日常开发任务Haiku 级别负责简单机械任务。到底怎么选我的经验是一张表任务类型推荐模型档位原因系统架构设计、复杂重构、跨模块影响分析最强档需要长程推理能力一次想清楚全局功能实现、写测试、修 bug中档速度和质量的平衡点最好格式化代码、批量改字段、写注释、生成 mock 数据轻量档任务简单贵模型纯属浪费真正落地时有个诀窍先用轻量模型快速试错再让强模型收尾。简单任务直接给最强模型响应慢、成本高收益却微乎其微。而复杂任务如果贪便宜用轻量模型大概率会陷入改来改去还是错的死循环。我踩过最惨的一次坑是用轻量模型做数据迁移脚本它反复生成、反复报错来回折腾了十几轮最后换了强模型一次就写对了——中间的 token 浪费早就超过了直接用好模型的成本。4.2 采样参数怎么调才不飘如果你直接调 API会接触到 temperature 这类采样参数。很多人误以为temperature 越高AI 越聪明实际上不是。temperature 控制的是输出的随机性——越高越发散、越天马行空越低越保守、越可预测。写代码是典型的低温度场景。我通常把 temperature 设在 0 到 0.3 之间。高于 0.5你就能看到模型开始创作明明用户需要标准的分页逻辑它非要给你加一个炫酷的动画效果或者在命名上发挥出让人摸不着头脑的想象力。另外一个容易被忽略的参数是max_tokens最大输出长度。复杂任务里如果一次输出的 token 上限太小模型会在代码写到一半时被硬生生切断然后它为了完成任务可能会用截断后的残缺思路继续执行结果就是产生一堆半成品代码。我的建议是给足输出预算宁可多花点 token 让它一次写完也不要让它写一半断掉再修复。4.3 成本控制缓存、批处理和上下文裁剪AI 自主开发的成本主要体现在 token 消耗上。一个常见的误区是只盯着生成代码的 token忽略了模型读文件、理解项目结构的消耗。实际上模型每次读一个大文件消耗的 token 可能比它生成的代码还多。成本控制我靠三板斧第一用好 prompt caching提示词缓存。如果你在多个会话里反复使用同一段系统提示词或项目说明开启缓存功能后这部分输入可以显著降低成本。Claude 对缓存有自动管理机制但前提是你把稳定不变的公共内容和每次变化的任务内容分开组织。CLAUDE.md 和系统指令适合放缓存区每次的任务说明书放实时区。第二控制文件读取范围。这是成本杀手锏。给 AI 的任务说明书里明确写只需要看 src/pages/ActivityList.tsx 和 src/api/request.ts它就不会把整个前端目录扫一遍。项目越大这个约束省的钱越可观。第三任务粒度合理减少无效返工。返工是最大的成本黑洞。一次任务如果因为理解偏差而重做相当于两倍的 token 加上你的时间。所以我在给任务时会刻意多写一句如果你不确定当前方案是否符合预期先输出方案再动手。这一句话能省掉大量跑偏后的返工成本。5. 踩坑实录与问题排查任何工具用多了都会遇到问题AI 自主开发尤其如此。这一节把我实际遇到的高频问题和排查思路整理出来最前面先讲一个很多人都会碰到、又最容易被误判的问题——连不上服务。5.1 连接服务失败的排查路径不少人在使用 Claude Code 或调用 API 时会遇到类似unable to connect to anthropic services、failed to connect to api.anthropic.com的报错。这个报错本身只说明客户端没能跟服务端建立连接但原因可能差得很远。我建议按下面的顺序逐层排查第一确认 API key 是否正确。检查环境变量ANTHROPIC_API_KEY是否设置key 是否有过期或被误改。这个原因占比出奇地高很多人换了新 key 没同步到环境变量里或者把 key 写进了会被版本管理忽略的文件导致运行时读不到。第二确认客户端版本和服务状态。Claude Code 这类工具迭代很快旧版本可能因为协议不兼容连不上新端点的服务。先升级到最新版再试。同时看一眼官方状态页如果对方服务正在维护或出现异常你这边怎么改配置都没用只能等恢复。第三确认网络环境能正常访问目标服务。这里说的是字面意思的连通性——运行环境的网络是不是稳定、能不能解析域名、有没有访问外部服务的权限。在服务器、容器、甚至某些偏内网的开发环境里这种问题很常见。你可以先用基础命令测试网络连通性如果能解析域名但请求超时多半是链路问题可以调整客户端的超时时间、请求重试次数等参数。排查时最忌讳的是上来就怀疑是不是 API 被限制了然后到处找偏方。绝大多数连接问题是 key、版本、网络配置这三类常规问题按顺序查一遍90% 的情况都能解决。剩下查不出原因的去官方社区或文档里找同款报错记录通常会有官方答复。5.2 模型越改越乱的常见信号自主开发过程中最让人血压升高的场景是让 AI 修一个 bug它修完 bug 引入了两个新 bug你再让它修那两个它又把原来的 bug 弄回来了。这种情况我称之为修改震荡本质上是因为模型对局部代码的改动缺乏全局认知。应对办法有两个。第一改一个任务就开一个会话。不要让修 bug和加功能在同一个会话里交叉进行。每个会话只赋予一个清晰目标改完即止。第二出现震荡时回退到最近的稳定版本重新开始。用 git 回退代码然后用现在代码是这个状态报错是这条请重新分析根因再修改的方式让 AI 从头推理而不是顺着它已经错乱的思路继续修补。这个操作看起来浪费实际上比让它继续打补丁快得多。我还会在任务说明书里加一句约束修改前先花 30 秒读一遍相关函数的完整上下文确保理解调用关系后再动手。这个约束能显著降低改坏旁边的概率。5.3 幻觉与过度设计怎么压制AI 在开发过程中经常出现两种自作主张一种是幻觉表现在引用了一个项目中根本不存在的函数、依赖或配置项另一种是过度设计表现在明明只要一个按钮它给你引入一个完整的状态管理方案。压制幻觉的核心是让 AI 给自己找证据。我会要求在任务说明书中写明所有关键引用必须来自真实文件接口是否存在于路由文件、组件是否存在于组件目录、依赖是否出现在 package.json。如果是让 AI 读文件后基于真实内容去写代码幻觉出现的概率会低非常多。反过来如果它凭记忆或推测去写幻觉几乎是必然的。抑制过度设计靠的是约束而不是劝告。与其说请保持简单不如写清楚禁止新增依赖禁止创建新目录只允许修改指定文件列表。明确的物理边界比抽象的保持简单有效得多因为 AI 对简单的理解跟人有差距但对只能改这几个文件的执行却非常精准。5.4 常见问题速查表把这一年多遇到的典型问题整理成一张速查表方便随时翻问题现象排查思路常用解法连接服务失败key 是否正确、版本是否最新、网络是否通、服务是否正常逐层检查升级客户端按官方文档配置修改引发新 bug上下文混乱、修改范围失控开新会话git 回退后重新让 AI 分析根因引用不存在的接口或依赖模型没有基于真实代码写明确要求所有引用需来自读过的文件代码风格跟项目不一致CLAUDE.md 缺失或约束不够补充项目约定给一两个范式示例反复提交但测试不通过反馈闭环缺失明确测试通过才是完成让它自己跑测试修改了 A 模块坏了 B 模块上下文过载、对全局依赖理解不足拆分子任务避免大而全的任务描述这张表里的每一条背后都是一次真实的踩坑。尤其是第一行开发环境里的网络问题往往最隐蔽排查时一定按顺序来不要跳步不要一开始就怀疑是服务端把你拒了。6. 我的几点实操心得文章最后分享几个碎片化但很实用的心得都是这段时间反复验证过的。第一个心得是把 AI 当成手艺很好但没有行业经验的 junior 工程师。它上手快、执行力强但你不给它边界它就给你踩边界你不给它验收标准它就按自己的理解交付。这套角色定位决定了你的所有工程手段——文档、权限、测试、审查——都围绕给它清楚边界和反馈来设计。第二个心得是保持小而频繁的提交。AI 完成一个原子任务你就让它提交一次代码提交信息写清楚做了什么。这样一旦某个改动出问题可以精准回退到上一个稳定点而不是面对一大坨没法拆分的变更。这个习惯在 AI 开发模式下比在人类开发模式下更重要因为 AI 的整体回退重来的成本远低于逐行修复。第三个心得是代码审查这个环节省不得。AI 生成的代码速度快但你在 merge 之前一定要亲自读一遍。重点看三样外部可见的接口契约是否符合预期、有没有引入非预期的依赖或副作用、敏感操作数据库写、外部请求是否符合安全约定。角度不是逐行找茬而是确认边界和契约。有了这层把关AI 自主开发带来的风险就能控制在可接受范围内。最后一个建议是从小项目开始建立信心。别一上来就让 AI 重写你的核心系统。先拿一个内部工具、一个脚本、一个低风险的页面模块练手跑通任务拆解-执行-验证-审查的完整循环再逐步扩大它负责的范围。我见过太多人第一次用就挑战最高难度项目结果被 AI 的错误搞得信心全无从此把 AI 编程打入冷宫——其实换个小项目体验会完全不同。AI 自主开发这门手艺本质上还是工程问题。模型在进步工具在完善但真正决定成败的还是你怎么设计流程、怎么定义边界、怎么建立反馈。把这些基本功做好AI 就是一支随时听你调度的开发团队做不好它只是另一个需要你反复擦屁股的实习生。