1. 为什么拿“简版 Dify”当测试题需求裁剪先于代码1.1 Dify 这个平台到底在解决什么问题先交代背景。我给自己的题目不是“复刻 Dify”而是“用 Claude Code 做全链路开发一个人一周能不能交付一个简化版 Dify”。这里说的简版不是把 Dify 的 UI 抄一遍而是把它的核心价值抽出来让一个不会写太多代码的人也能通过可视化的方式编排大模型应用。Dify 本质上是一个 LLM 应用开发平台。它的核心能力可以拆成三条线第一条是工作流编排把 LLM 调用、提示词模板、条件分支、分类器这些节点拖到画布上连成一条可执行的链路第二条是知识库/RAG让用户上传文档自动切片、向量化在问答时先检索相关知识再交给大模型回答第三条是应用发布把编排好的工作流发布成一个聊天界面或 API供外部系统调用。这三条线每一条单拎出来都不简单。工作流引擎要处理节点调度、上下文传递、分支跳转知识库涉及文本解析、切片策略、向量嵌入、相似度检索发布层要处理会话管理、流式输出、API 鉴权。正常的团队排期这三块至少得两三个月。一个人一周做完听起来确实有点夸张。但这里有个关键判断简版不等于缩小版而是“删掉非核心后的最小闭环”。我不需要做多租户权限不需要插件市场不需要细粒度的运行监控和团队协作。我要的只是一个能跑通完整路径的模型创建应用、画工作流、传文档、聊一次天、调一次 API。这样才能把“一个人一周”从口号变成可执行的计划。1.2 我的一周版本画下的功能边界动手写代码之前我先把“要做什么”和“不做什么”写成了清单。这个过程比写代码本身更重要因为在 Claude Code 这种 AI 辅助开发模式下范围失控的代价比人工开发时代更高——AI 不会主动质疑需求你让它做什么它就会做什么范围越大上下文越乱最后的代码质量越难保证。我的一周版本保留了下面这些能力工作流支持开始节点、大模型节点、提示词节点、条件分支节点、知识库检索节点节点之间可以连线支持顺序执行和简单分支。画布前端有一个可拖拽的节点编辑器后端保存的是 JSON 格式的图结构。知识库支持上传 txt、md、pdf 文件自动切片并向量化查询时做相似度检索。应用发布一个对话测试页和一个简单的 API 接口外部程序可以往这个接口发消息拿回复。同时我明确砍掉了这些东西多租户和用户权限体系、插件生态、工作流并发与重试机制、向量数据库的分布式部署、Prompt 在线调试的高级功能、应用市场的计费结算。这些功能不是说没用而是在“一个人一周交付”这个约束下它们属于“锦上添花”而非“生存底线”。1.3 范围控制对“AI 全链路开发”有多关键我见过很多人用 Claude Code 觉得“失控”代码越写越乱改一个功能带崩三个模块。根子往往不在工具而在需求本身没想清楚就开始让 AI 干活。打个比方Claude Code 就像一个执行力很强但缺少产品判断力的新同事。它能把任务做得很快但不会主动替你做产品决策。你告诉它“做一个工作流引擎”它可以给你列出十几种节点类型、几十个参数但如果你告诉它“做一个只支持五种节点、用 JSON 存储图结构、执行时按拓扑排序的工作流引擎”它输出的东西你就可以直接用了。所以在一周挑战开始前我花了整整一个晚上做范围裁剪。每一个保留的功能都对应一条“验收路径”工作流做完后能不能跑通一个“输入问题→检索知识库→调用大模型→返回答案”的完整链路知识库做完后能不能用一份真实的企业文档做问答。有了这些验收路径AI 生成的每一块代码都有了明确的“完成定义”而不是看起来差不多就行。2. Claude Code 的工程化配置别把 AI 当补全工具用2.1 安装、认证、和 VSCode 配合起来工欲善其事必先利其器。Claude Code 本身是 Anysphere 推出的命令行编程智能体它和普通 AI 代码补全工具最大的区别是它能读懂整个项目结构、跨文件修改代码、执行命令、跑测试、根据报错自动修复本质上是一个跑在终端里的 AI 工程师而不是一个“帮你补全下一个词”的输入法。安装环节没有太多弯弯绕绕。在终端里执行安装命令然后登录账号授权。我日常开发主要在 VSCode 里所以还装了官方扩展这样可以在编辑器侧边栏直接开一个对话面板AI 能看到当前打开的文件和项目目录。从实际体验来说命令行模式适合“整个模块重构”这种大任务VSCode 面板适合“这个函数哪里写错了”这种单点问题。两者共用同一个会话历史切换不割裂。有一点特别值得提醒如果你打算在 WebStorm 或其他 JetBrains 系 IDE 里用体验会打折。Claude Code 的很多能力依赖对项目文件系统的深度感知VSCode 和原生命令行的支持度最高。不要因为习惯某个 IDE 硬上工具链的顺手程度直接影响交付速度。2.2 CLAUDE.md给 AI 一份项目说明书用 Claude Code 的第一天我做的第一件事不是写业务代码而是写了一个CLAUDE.md文件放在项目根目录。这个文件就是给 AI 看的项目说明书Claude Code 每次启动都会自动读取它相当于 AI 的“长期记忆初始化”。这个文件写什么直接决定 AI 输出的质量。我见过有人只在里面写一句“这是一个 Dify 简化版项目”这等于没写。我自己的模板是这样组织的# 项目说明 这是一个简化版 LLM 应用开发平台核心功能包括工作流编排、知识库问答、API 发布。 技术栈后端 Python FastAPI SQLite SQLAlchemy前端 React TypeScript ReactFlow。 模型服务通过 OpenAI 兼容接口调用大模型本地嵌入模型用 BGE-M3。 # 目录结构 backend/app/ # 后端代码 models/ # SQLAlchemy 数据模型 services/ # 业务逻辑工作流引擎、知识库服务 api/ # FastAPI 路由 frontend/src/ # 前端代码 components/ # React 组件 pages/ # 页面 # 编码规范 - 后端遵循 FastAPI Pydantic 规范所有接口返回 JSON。 - 数据库迁移使用 Alembic禁止手改表结构。 - 前端组件用函数式组件 Hooks不用 class 组件。 - 所有对外 API 必须写清晰的中文注释。 # 当前任务 [这里每次开工前由我更新告诉 AI 今天要做什么]你可能会问这些东西 AI 自己不能从代码里读出来吗能但代价很大。每次让 AI 重新从代码里理解项目结构会消耗大量上下文窗口还会出现“它对项目的理解和你不一样”的偏差。把项目说明书写清楚等于每次对话开始时给 AI 加载一遍正确的“世界观”后续所有操作都在这个共识上展开。2.3 模型路由强模型干重活本地模型干杂活Claude Code 默认用 Anthropic 的模型但它支持配置自定义 API 端点所以我有两个选择一是直接用官方服务二是把它切到别的模型提供商比如接入 DeepSeek或者接本地 Ollama 跑的 Qwen 系列。我的实践是“混合路由”。核心的业务逻辑代码、跨模块重构、复杂 bug 排查这些任务交给能力最强的模型来做因为错误率低、一次写对的概率高省下来的调试时间远超省下的那点 API 费用。而像“把这段 SQLAlchemy 模型转成 Pydantic 响应类”“给所有接口补测试用例”“生成一批模拟数据”这种机械重复的任务我会用 cc-switch 这类工具把端点切到本地 Ollama 或 DeepSeek成本几乎可以忽略速度还快。这里必须说清楚一个原则不是所有任务都适合本地模型。Claude Code 这类智能体工具和一个 Chat 对话框不同它需要频繁地读文件、改文件、跑命令、看报错再改每一步都依赖模型的工具调用能力。如果一个模型写单轮问答还行但让它连续五轮“读代码→改代码→跑测试→读报错→再改代码”它很容易在中途掉链子。本地模型干杂活的前提是“这个任务失败了对全局没什么影响”一旦任务开始涉及核心链路就切回强模型。2.4 用自定义指令把团队规范固化下来Claude Code 支持在项目里配置自定义指令类似团队协作时的“规矩”。我把常用的工程规范写成了几条强约束让 AI 在每次操作前都自动遵守。比如提交代码前必须跑一遍pytest全绿才能说任务完成。修改数据库模型时必须同时生成对应的 Alembic 迁移文件。前端任何用户输入框必须做空值校验不允许出现未处理的 undefined。每个 API 接口定义时必须写清楚输入输出示例。这些规范如果靠人每次口头叮嘱AI 偶尔会忘记但写在自定义指令里它就变成了 AI 的“工作习惯”。我这一周里出现“改完模型忘生成迁移文件导致接口 500”的情况就是靠这条规则堵住的。3. 拆解 Dify 核心模块生成 AI 可执行的任务卡3.1 把平台拆成“数据模型 引擎 接口 前端”四层范围定清楚之后下一个问题是怎么把大任务拆给 Claude Code。我的经验是不要直接说“帮我做一个 Dify”而是把项目拆成四个层次每个层次再拆成一个个独立的任务卡。四层结构是这样的第一层是数据模型。包括应用表、工作流版本表、节点配置表、知识库文档表、文档分段表、对话记录表。这一层是整个平台的地基先把它定死后面的引擎和接口才不会互相打架。第二层是工作流引擎。它不关心前端长什么样只负责一件事输入一个图结构的 JSON按顺序执行节点最终输出结果。引擎是纯后端逻辑和数据库、网络都没有强耦合可以独立测试。第三层是 API 服务层。把所有能力暴露成接口创建应用、保存工作流、执行工作流、上传文档、查询知识库、发起对话。这一层把引擎和数据库串起来。第四层是前端。它负责三块画布编辑器、知识库管理页、对话测试页。前端和后端之间只通过 API 通信。每一层交给 Claude Code 时我都会写清楚“改哪些文件、不动哪些文件、验收标准是什么”。这样 AI 的工作范围是收敛的不会出现“改一个前端组件把后端代码也顺手重构了”的情况。3.2 任务卡模板一段可以直接丢给 Claude Code 的上下文拆完之后我把每个模块写成一份任务卡。任务卡不是简单的需求描述而是要包含足够上下文让 AI 不需要自己乱猜。我用的模板长这样【任务目标】 实现工作流引擎的节点执行器支持 LLM 节点、知识库检索节点、条件分支节点。 【涉及文件】 - backend/app/services/executor.py新建 - backend/app/models/node.py只读不要修改 - backend/app/services/llm.py只读调用已有接口 【功能要求】 1. 输入是一个工作流图 JSON包含 nodes 和 edges。 2. 执行顺序按拓扑排序遇到条件分支时根据上一个节点的输出判断走哪条边。 3. LLM 节点的 prompt 支持模板变量填充变量来自全局上下文或上游节点输出。 4. 知识库检索节点调用已有的检索服务把结果拼进上下文。 【验收标准】 运行 pytest tests/test_executor.py 全部通过。 测试用例覆盖线性链路、二分支链路、知识库检索节点。这份任务卡的妙处在于它把“做什么、改哪里、怎么算完成”全部定义清楚了。Claude Code 不需要从零理解项目只需要聚焦在executor.py这一个文件里完成实现。任务范围越小它的输出越可控越不容易“发挥过度”。3.3 数据模型先行一周版本只需要六张核心表很多人在用 AI 做全栈项目时犯的一个错误是一上来就做页面做到一半发现后端数据结构对不上又推倒重来。为了避免这个问题我把数据模型放在了绝对优先级。我的一周版本一共只设计了三组共六张表。第一组是应用与工作流相关apps表存应用基本信息workflow_versions表存工作流的版本化 JSON 结构workflow_nodes表存每个节点的配置详情。第二组是知识库相关kb_documents表存文档元数据文件名、状态、切片数kb_segments表存切片后的文本块。第三组是运行时数据conversations表存会话与消息记录。这几张表不需要外键约束满天飞只要能满足“一个应用有一个最新工作流版本、一个知识库有若干文档、一个文档有若干切片”这种最基本的关联就够了。表结构定完后我让 Claude Code 一次性生成 SQLAlchemy 模型和 Alembic 初始化迁移跑通alembic upgrade head整个数据层就算落地了。这一步带来的回报是后面所有任务卡里“涉及文件”那一栏可以直接写“基于 models 里已有的表结构”AI 不会因为表结构频繁变动而返工。3.4 工作流引擎先做出可测试的执行内核再谈画布工作流是整个平台技术含量最高的部分也是最容易失控的部分。我做这件事的顺序是先不管前端画布先做一个纯后端的执行内核用测试用例把它锁死然后再让 Claude Code 基于这个内核去接前端。引擎的设计我刻意做得比 Dify 简单。Dify 有几十种节点类型、复杂的变量解析和并行执行机制我一概不要。我的引擎只支持四种节点开始节点、大模型节点、知识库检索节点、条件分支节点。执行顺序用拓扑排序算出来节点之间通过一个共享的context对象传值。大模型节点从 context 里读取变量拼出 prompt调用 LLM 服务拿到结果再写回 context。这个设计的核心逻辑是引擎的复杂度决定了整个项目的风险上限。如果我让 Claude Code 一开始就做一个支持并行、循环、子工作流的引擎那这个项目的排期就不是七天而是七十天。四种节点虽然少但已经能支撑“知识库问答”“条件分流”“多轮对话”这些核心场景了。先把最小引擎跑通以后要加节点类型只需要扩展节点注册表不需要推倒重来。3.5 知识库 RAG 的最短闭环RAG检索增强生成听起来高大上但落到最小实现其实就是四步文本解析、切片、向量化、相似度检索。文本解析我用的是 Python 的pypdf解析 pdfmardown库处理 md 文件txt 就直接读。切片策略比解析更重要最笨但有效的做法是按固定长度切比如每 500 个字符一段重叠 50 个字符保证切出来的片段不会把一句话拦腰截断。向量化是另一个关键决策。我选了本地部署的 BGE-M3 模型做 embedding而不是调在线 API。原因很简单一周项目要反复测试和调试每次把文档切片后调在线 embedding 接口既慢又花钱还受网络影响。BGE-M3 在本地 CPU 上跑虽然不算快但处理几百 KB 的测试文档绰绰有余而且它对中文的支持效果很好检索精度够用。向量存储我也没有上专门的向量数据库直接拼了一个余弦相似度计算函数数据量小的时候完全够用。4. 实盘记录一周七天每天到底在干什么4.1 第 1 天搭脚手架、定模型、写 CLAUDE.md第一天的目标不是写功能而是把“工地”收拾好。我先把前后端两个项目初始化出来后端用 FastAPI SQLite SQLAlchemy前端用 Vite React TypeScript ReactFlow。然后我花了两三个小时把第三章节里说的数据模型和 CLAUDE.md 全部落地。这个过程我让 Claude Code 参与了脚手架创建和初始代码生成但所有关键文件我都自己看过一遍。我的原则是地基部分不能全交给 AI因为一旦地基歪了后面所有楼层都会跟着歪而且很难排查。当天晚上验收的指标很简单后端能启动、能连上 SQLite、alembic upgrade head成功前端能打开空页面、ReactFlow 能渲染一个空白画布CLAUDE.md 已经被 Claude Code 正确加载我会故意问它一句“这个项目的技术栈是什么”确认它的理解和我一致。4.2 第 2~3 天工作流引擎和画布前后端打通第二天和第三天是整个项目最核心的两天目标只有一个让画布上拖出来的节点能在后端真正执行出结果。第二天上午我给 Claude Code 下发引擎任务卡就是 3.2 节里的那张。其实第一次跑测试并没有全绿因为我对条件分支的判定逻辑描述得不够细AI 默认实现了“按字符串相等判断”而我的场景需要支持“大于/小于/包含”这类比较操作。我在测试用例里加了几条数值比较的 caseClaude Code 看了报错之后自己改了实现第二轮就过了。第二天下午开始做前端画布。ReactFlow 这个库本身就支持拖拽节点和连线Claude Code 要做的只是把画布上的节点配置表单和后端的数据模型对接起来。这里我踩了一个坑一开始让 AI 把节点配置做成一个统一的 JSON 编辑器结果用户也就是我自己用起来非常痛苦填 prompt 模板时还要手写转义字符。后来改成每种节点一个独立的配置面板LLM 节点就显示一个多行文本框、模型选择器、变量插入按钮知识库节点就显示文档下拉框体验瞬间正常了。第三天主要做联调和补漏。引擎执行完的结果要能回传到画布上高亮显示哪条节点链路过前端参数错误要能显示后端返回的具体错误信息而不是一个笼统的 500。这两天下来我能够在一个浏览器页面里拖三个节点、连上线、点运行、看到每一步的执行结果那种成就感比直接复制一个开源项目强太多了。4.3 第 4 天知识库上传、切片、检索一条龙第四天的目标是知识库从上传到问答全链路打通。上午做后端的文档解析和切片服务下午做前端的知识库管理页。这里最花时间的不是代码而是切片策略的调优。固定 500 字符切片的好处是简单坏处是遇到代码块、表格这类结构化内容时会切得很碎。我没打算在一周内解决这个问题所以做了一件事情把切片配置做成可调的参数在管理页上允许用户自己填“切片长度”和“重叠长度”。这个设计让 AI 实现起来并不复杂但大大提高了知识库对不同格式文档的适应能力。检索环节我做了一个很实用的功能知识库命中测试页。用户可以输入一个问题页面展示检索到了哪几个文档片段、相似度分数是多少、这些片段最后拼成了什么样的 prompt。这个功能在 demo 时非常加分因为它把 RAG 的“黑盒”变成了“白盒”别人一眼就能看懂知识库检索是怎么工作的。4.4 第 5 天应用发布、对话页、API 网关第五天把前三天的成果收拢成“用户可感知的产品”。早上先做对话测试页左侧是会话列表中间是聊天窗口右侧可以切换使用哪个应用和工作流。这个页面的技术含量不高但工作量不小靠 Claude Code 帮我一次性生成了大部分组件代码我做的主要是调整布局和样式。下午做 API 发布这块。设计思路是从后端提供两个接口POST /api/v1/apps/{id}/chat用于发起对话GET /api/v1/apps/{id}/messages用于拉取历史消息。为了让外部系统容易对接我让 Claude Code 把请求和响应的字段命名统一成 OpenAI 风格的messages格式。这样集成方不需要学习新的 API 规范直接把原来调 OpenAI 的代码改个 base_url 就能用。一个细节差点翻车流式输出。大模型接口默认是流式返回 token 的但我的 API 网关一开始用了普通的 JSON 响应导致前端对话页要等所有 token 都生成完才能看到文字体验非常拖沓。后来让 Claude Code 把响应改成 SSEServer-Sent Events流式输出前端再逐步渲染 token问答响应时间从“等待 10 秒后整段出现”变成了“第 1 秒就看到第一个字”观感完全不同。这个改动其实不难但一定要在第一天设计接口时就想到不然后端前端都要返工。4.5 第 6~7 天联调、部署、录演示最后两天没有新功能全部在做“让它在别人的机器上也能跑起来”和“让它在演示时足够好看”这两件事。部署方案我选了 docker-compose。因为项目本身就一个 FastAPI 后端加一个 React 静态站点打包起来很简单。前端用npm run build产出静态文件用 Nginx 托管后端起一个 Gunicorn 服务连同一个 SQLite 文件BGE-M3 模型虽然在容器里跑有点重但因为我用的是 CPU 版 ONNX 模型镜像体积和内存占用都在可接受范围。第 6 天下午我拉了一台干净的 Linux 服务器按 README 从头执行了一遍部署命令专门抓“缺少环境变量”“路径写死”“数据库没有自动迁移”这类问题。两天里大概修了七八个这样的坑每个坑都改进了 README 或部署脚本。第 7 天上午没有写代码我把一周前定的验收清单拿出来逐条过了一遍用一份真实的员工手册 PDF 传进知识库跑通了“问题咨询→检索员工手册→LLM 生成回答”的完整演示录了一个五分钟的视频。到这里一个人一周交付简版 Dify 这件事算是真正闭环了。5. 真实踩坑上下文失忆、嵌入模型选型、部署失败的排查链路5.1 Claude Code 上下文崩坏的信号与抢救Claude Code 看起来有很长的上下文窗口但在真实的大型项目中它的“记忆”是会被慢慢消磨掉的。我在第 3 天上午就遇到过明显的跑偏当时让它改前端画布的节点配置面板我的任务卡里写的是“只修改frontend/src/components/NodePanel.tsx”它却在改完后把backend/app/services/executor.py里的节点注册表也一起改了还改了数据库模型。为什么会出现这种情况因为我们的会话已经持续了很长时间AI 为了理解 NodePanel 的 props 类型会去翻后端接口定义、翻数据模型看着看着它觉得“这个字段名字应该改一下”就顺手改了。这个行为非常符合一个认真但缺乏边界感的实习生。发现跑偏后我的处理链路是先停下来不让它继续往下改把已经产生的 git diff 逐条看一遍把不该改的改动git checkout掉。然后在自定义指令里加了一条硬性约束“每次只修改任务卡里列出的文件如果认为其他文件需要改动先向用户说明理由得到确认后再动手。”这条规则之后几乎杜绝了“范围爆炸”的问题。5.2 本地 Embedding 模型选型为什么我选了 BGE-M3 而不是在线 API做知识库的那天我本来想图省事调用在线 embedding API测试到一半放弃了。原因有三个第一是费用本地测试时经常要重复向量化同一个文档在线 API 虽然单次不贵但一天几百次下来数字很难看第二是速度每次向量化要等网络往返调试切片策略时特别浪费时间第三是部署环境我最后要交付到内网服务器内网机器不一定能访问外部 API本地模型是唯一稳妥的选择。BGE-M3 是我在本地模型里试下来最稳的。它支持 8192 的输入长度对长文本切片更友好中文效果明显好于同体量的通用模型而且有 ONNX 格式的 CPU 部署版本不需要 GPU 也能跑。实际跑下来一份 20 页的 PDF 切片成 30 段左右全量向量化在 CPU 上耗时约十秒完全能接受。如果你也打算做类似的本地知识库项目我的建议是不要一上来就上 Milvus 或 Qdrant。数据量在十万条以下时用内存里的 NumPy 数组加余弦相似度就够了先把链路跑通等数据量真的大了再考虑换向量库。给 AI 的任务卡也要写清楚这一点否则它很有可能会自作主张引入一套重型的向量数据库方案。5.3 自研应用部署时的典型失败从 500 到数据库迁移第 6 天部署时遇到的最典型的坑和热词里提到的“Dify 升级后无法保存知识库修改知识库时报 internal server error”是同一类问题本地开发好好的一部署就 500。我的排查链路可以复用到很多场景。第一步先看日志。FastAPI 的日志里直接打印出了异常堆栈是一个sqlite3.OperationalError: no such table: kb_segments。这个报错的根因是数据库表结构变了但部署环境的数据库没有执行新的迁移脚本。我在本地开发时每次改完模型都会自动跑alembic upgrade head但部署脚本里忘了加这一步服务器上用的还是老数据库。这个坑给到的教训有两个第一生成环境的数据库迁移必须集成到启动流程里不能依赖人工手动执行第二docker-compose 启动前要先检查数据库版本号不一致就自动迁移。我把这两条都写进了部署脚本之后没有出现过同类问题。所有容器化部署的项目都建议把这个逻辑做成标配你会少踩很多“本地好的、线上挂了”的坑。5.4 模型幻觉的防线让 AI 写代码但要让人定验收标准这一周里 Claude Code 给了我非常大的帮助但我也从来没有让它“自由发挥”过任何核心逻辑。我的做法是所有关键模块都先由我定好输入输出契约AI 在契约内实现然后我用测试用例来验收。比如工作流引擎的“条件分支”功能我没有直接说“帮我做个判断逻辑”而是写清楚了分支节点的 type 是condition配置里有一个rules数组每个 rule 包含variable、operator、value三个字段operator 支持eq、gt、lt、contains。然后让 Claude Code 按照这个契约来实现和写测试。有了契约模型输出就跟“填空”一样稳定很难产生幻觉级的大偏差。如果一件事连你自己都没想清楚“完成长什么样”就不要指望 AI 能帮你做好。Claude Code 不是产品经理它是执行力很强的执行者。这个定位想清楚用起来会顺手非常多。6. 交付后复盘Claude Code 全链路开发的能力边界6.1 这次成功靠的到底是什么复盘这一周我的结论是交付成功靠的不是 Claude Code 有多强大而是三个前置条件同时满足。第一是业务范围被裁剪到了一个非常克制的闭环全程没有碰权限、计费、插件这类复杂度黑洞第二是技术栈足够成熟FastAPI、React、SQLite、ReactFlow 都是 AI 训练数据里覆盖最多的框架它的生成质量接近一个熟练工程师第三是验收手段非常明确每一个模块都有可以自动运行的测试用例和可 demo 的业务路径。这三个条件缺一个交付速度都会大打折扣。如果业务范围不克制上下文会失控如果用的技术栈太冷门AI 就是在瞎编 API如果没有验收标准代码看起来能跑但一改就崩最后一整天都在修 bug。所以我不会跟别人说“Claude Code 能一个人干一个团队的活”。更准确的说法是Claude Code 能把一个架构清晰、边界明确、验收标准完备的项目的编码过程提速数倍但架构设计、范围控制、需求拆解这些“想清楚”的活最终还是要由人来完成。6.2 哪些项目别硬上“全链路 AI 开发”经历了这次一周挑战我也更清楚 Claude Code 的能力边界在哪里。有三类项目我不建议用这种全链路 AI 开发方式。第一类是性能敏感型项目。AI 生成的代码在“能跑”和“跑得快”之间往往倾向于前者它不会主动做连接池、缓存、索引优化这些事情需要你下非常具体的指令它才会做。如果项目核心价值是低延迟高并发AI 生成的初始版本大概率会让你失望。第二类是交互体验要求极高的项目。像素级 UI 设计、复杂的动画交互、无障碍支持这些不是 AI 的强项。Claude Code 能生成很规范的组件代码但让它做出“像 Notion 一样精致的界面”还差得非常远。我的简版 Dify 界面只能算合格离“惊艳”很远好在我没打算靠它拿设计奖。第三类是遗留系统改造。Claude Code 面对一个结构混乱、没有文档、到处是隐性依赖的老项目时它的理解能力会明显下降。它更擅长从零构建新项目或者在结构清晰的项目里做增量开发。如果你要改造的是一个积累了十年历史、文档严重缺失的遗留系统先把系统结构和关键路径梳理清楚再考虑让 AI 参与实现。6.3 把 AI 当作一个需要管理的新同事方法论的固化一周项目结束后我把这套方法沉淀成了自己平时开发的标准流程每次开工前先更新 CLAUDE.md 里的“当前任务”把之前失败的教训总结成自定义指令任务卡模板存在项目 docs 目录下供以后复用。最直接的变化是我现在接到一个新需求时第一反应变成了“需求边界是什么、验收标准是什么、涉及哪些文件”而不是“代码怎么写”。这个思维方式是 Claude Code 教给我的或者说是这一周高强度的“人机协作”倒逼出来的。代码生成的速度让编码不再是最耗时的环节想清楚做什么、怎么验收变成了核心工作。如果你也想尝试这种全链路开发方式我的建议是不要一上来就复刻一个 Dify而是先拿一个像“待办事项管理系统”这样的小闭环练手。在练习中重点体会两件事一是任务卡怎么写才不会被 AI 曲解二是怎么通过验收标准保证 AI 的每一次输出都符合预期。这两件事练熟了再用它挑战更大的项目你会发现自己一个人真的能交付一个原本需要一支小队才能完成的产品。