1. 我为什么要搭一套 AI 编程工作流从“对话式编程”到“流水线式开发”有段时间我发现自己陷入一种奇怪的低效跟 AI 聊得越流畅手上的代码越乱。那边刚生成一个功能模块我复制进项目里编译报错修完报错发现它改坏了另一个函数等我手动调完半天已经过去代码里还留着一段它脑补出来的死逻辑。问题不在于 AI 不好用而在于我根本没有一套 AI 编程工作流——我只是把聊天框当成了一个更聪明的搜索引擎问一句、抄一段、再问一句、再补一段。后来我才想明白聊天工具解决的是“写出一段代码”但软件交付要经过需求拆解、上下文整理、编码、自查、编译测试、代码审查、提交合并这一整串环节。AI 只参与了中间一小段其余全在靠人肉接力效率自然上不去。真正的 AI 编程工作流是把这一整串环节重新编排让 AI 在每一段都有明确输入、明确产出、明确验收标准而人只做最关键的判断和兜底。这篇文章就是我搭建这套工作流的完整复盘。我会先讲清楚我踩过的认知误区再给出每一类工具的实际定位、选型结论然后放出一套可以直接照抄的最小可行流程最后把自动化编排、项目上下文建设、踩坑记录一并交代完。不管你是个人开发者、独立做开源项目还是带两三个人的小团队这套思路都能直接用不需要一开始就上很重的平台。1.1 “会用 AI 编程”和“用 AI 把事做完”是两码事我先说一个反直觉的结论会向 AI 提问题不等于会用它做项目。大多数开发者停留在“单点调用”阶段比如“帮我写一个 Python 脚本解析 JSON”“这个函数为什么报错”。这类用法确实能省时间但它不改变你的开发流程你的工作方式还是原来的方式AI 只是替代了搜索引擎。一旦进入真实项目你会立刻碰壁。我见过一个朋友在 Cursor 里让 AI 生成一个用户登录模块生成得又快又完整他满意地合入主干后CI 直接爆了——单元测试里 mock 的接口路径和真实路由对不上数据库迁移脚本还多执行了一次。问题出在哪出在 AI 生成代码时根本不知道项目的路由规范、测试约定、迁移机制。它没有上下文你也从来没有把上下文喂给它。所以我把“AI 编程工作流”理解成一套带约束的产出管道输入是一个清晰定义的任务中间经过带项目知识的生成、自动化的验证和检查输出才是可以合入主干的代码。人要在几个关键节点做决策但不应该在所有环节亲力亲为。想通这一点之后我做的第一件事不是换工具而是画清楚我自己开发一个功能时到底经过哪些环节哪些环节 AI 可以承担哪些环节必须保留人工判断。1.2 我开始动手前给自己列的三个问题搭建这套工作流之前我先问了三个问题建议你也照做一遍。第一个问题我日常最花时间的重复劳动是什么我当时最大的痛点是写接口文档、生成规范的 Git commit message、在代码评审时逐段解释改动背景。这些事情有套路、有模板但特别消耗精力正是适合编排自动化的场景。第二个问题我的项目上下文散落在哪里包括技术栈约定、目录结构、命名风格、数据库迁移方式、测试框架配置。AI 只有拿到这些信息才能产出“合身”的代码而大多数人把这些信息放在自己脑子里AI 当然只能靠猜。第三个问题我怎么验证 AI 产出的东西是对的不是“它跑通了”而是“它符合项目规范和业务预期”。这需要可执行的检查手段比如自动化测试、lint 规则、类型检查、构建脚本。如果这些检查不存在AI 编程工作流就是空中楼阁。这三个问题决定了后面所有工具选型和流程设计的方向。换句话说先梳理人和 AI 的分工边界再谈工具才不会买一堆工具回来却不知道怎么拼。2. 先把角色分清楚AI 编程助手、流程编排平台、Agent 到底谁干活刚开始接触这块的人很容易被“XX 编程、YY 工作流、ZZ Agent”这些词砸晕。Cursor、GitHub Copilot、Continue 是一类Dify、n8n、Coze、Flowable 又是一类现在到处都在讲的 AI Agent 又是另一类。它们到底什么关系我的理解方式很简单把整套开发活动拆成“单点动作”和“多环节流程”。单点动作是“生成一个函数”“解释这段代码”“补一个测试用例”这类活交给 AI 编程助手多环节流程是“从 issue 自动拆出子任务、生成代码、跑测试、整理变更说明”这类活需要流程编排工具把多个动作串起来。AI Agent 则是一种更激进的方式——它自己决定下一步调用什么工具但你得给它划定非常明确的边界否则它会在错误的方向上越走越远。2.1 AI 编程助手管“单点产出”编程助手类工具解决的是“在代码上下文里高效生成和修改代码”。我自己常用的组合是日常编辑用 Cursor命令行场景用支持 AI 的终端工具偶尔也会切到 Continue 这类开源方案配合本地模型。这里分享一个很实际的选型经验不要只看谁的生成速度快要看谁对你的项目上下文理解得深。所谓“理解得深”体现在三个细节上能不能自动读取当前文件相关的符号定义能不能跨文件引用项目里的既有实现能不能记住你刚给它讲过的项目约束。我试过好几个工具在独立文件生成上差别不大一旦涉及修改既有模块体验差距立刻拉开。Cursor 的强项就是它把“代码库索引”做进了日常交互里你在对话框里问“我们项目里现有的用户鉴权逻辑在哪”它能基于索引给出带文件路径的回答而不是泛泛而谈。不过我也要泼一盆冷水编程助手的产出质量严重依赖于你给它的上下文和指令质量。它本质是一个“高级补全器”不是项目架构师。你需要明确告诉它“按什么规范写、复用哪个已有模块、测试要覆盖哪些分支”它才能给出可用的结果。这也是为什么我把“提示词资产化”放在后面单独讲——凡是能沉淀成模板的指令都不要每次现场想。2.2 流程编排平台管“跨环节协作”Dify、n8n、Coze 这类平台解决的是另一个问题把 AI 能力接入到具体的业务流程里让它在固定的输入输出之间反复执行。举例来说我在本地仓库提交代码后希望自动生成一份清晰的 commit message 和 PR 描述。这个任务涉及多个环节读取 git diff、把 diff 喂给大模型、按约定格式生成文本、回写到提交信息里。如果靠人肉做每次至少浪费三到五分钟如果用编程助手的对话框做还要复制粘贴 diff大段的上下文很容易截断最好的方式是让流程编排工具自己完成这个链路。n8n 这类偏向工程自动化的工具很适合做“事件触发 API 调用”的任务比如监听 GitHub Webhook 之后跑一个工作流。Dify 则更适合把大模型应用本身产品化比如你搭一个“代码评审助手”把系统提示词、知识库、模型参数都配好对外提供 API让团队其他工具调用。Coze 偏向快速搭建面向用户的对话应用但也能通过插件能力做一些文本处理类的活。Flowable 这种则更偏传统企业流程引擎如果你的场景涉及多人审批、任务分派、状态流转它会比 n8n 更合适但学习成本也高一个量级。2.3 AI Agent 不是万能魔法AI Agent 是现在最热的词但我的建议是进入生产项目之前先把它的边界想清楚。Agent 和“固定流程”最大的区别在于决策权。固定流程里每一步做什么是预先定义好的Agent 则可以根据当前状态自己决定下一步。这个能力在探索性任务里很爽比如让 Agent 自己读报错日志、查相关文件、改代码、跑测试、再看结果。但在有严格约束的项目里决策权越大越危险。我见过不止一次翻车现场Agent 改了一个测试失败为了“修复”它直接把测试断言删了或者为了通过类型检查把参数类型悄悄改成 any。它确实解决了眼前的报错却埋下了更大的隐患。所以我现在只会在三类场景里用 Agent技术调研、原型验证、自动化测试修复。生产代码的生成和修改我坚持用“固定工作流 人的审查关卡”不让模型自己一路狂奔。2.4 我个人最终采用的工具组合环节工具/方案解决的问题代码生成/修改Cursor Continue在代码库上下文里完成单点编码命令行辅助终端 AI 助手解释报错、生成 shell 命令流程自动化n8n Dify把 commit、review、文档等固定流程串起来知识库/规范本地 Markdown 索引为 AI 提供项目级上下文验证关卡测试/lint/类型检查拦截错误产出这里没有标准答案只有适合你的组合。我的原则是能在一个编辑器里解决的问题不引入第二个工具能写进 Git 仓库的规范不放进某个云端平台里能被自动化检查拦截的问题不依赖 AI 自觉。3. 最小可行工作流从空仓库到一个功能合并进主干选型只是第一步真正难的是把流程跑起来。我把自己这套流程拆成了五个阶段准备环境、定义任务、生成实现、自动验证、提交整合。每个阶段都有明确的输入输出下面按顺序展开你可以直接照着搭。3.1 第零步先把环境做干净这一步最容易被忽略但它决定了后续所有环节是否可复现。AI 生成的代码要能在本地跑起来、能通过检查环境必须先“讲得清楚”。我现在的标准做法是每个项目都带一个README.md说明用途和启动方式一个requirements.txt或package.json锁定依赖一个.env.example列出所有需要的环境变量不填真实值再加一个Makefile或脚本把“安装、测试、启动”这些高频操作固定下来。这样做的价值在于你不必每次向 AI 解释“我们项目怎么跑”你只需要让它读项目里的文件它就能自己找到答案。如果你的项目还没建强烈建议用主流框架自带的脚手架初始化而不是手写配置。我见过太多人花一整天手工搭项目结构最后连自己都说不清哪些配置是必要的。脚手架生成的默认结构就是你的“标准上下文”后续所有 AI 生成代码都围绕这个结构展开沟通成本会低很多。3.2 需求阶段把任务写成“任务卡”我在此处要分享一个让我少走很多弯路的关键经验不要让 AI 直接生成功能先让它按你的要求输出一份“任务拆解清单”你确认后再开始写代码。这个中间步骤能挡掉一大半“文不对题”的问题。具体操作上我会用一个固定的任务卡模板。例如背景项目是一个内部订单管理系统基于 FastAPI SQLAlchemy。 本次目标新增订单导出功能支持按创建时间范围和订单状态过滤。 约束 - 必须复用 existing utils/csv_export.py 里的导出逻辑 - 导出接口需要管理员权限 - 所有新增接口都要有对应的 pytest 测试 - 数据库操作走仓库层模式不直接写 session 查询 交付物清单形式列出将创建/修改的文件以及每个文件的核心改动点把这段喂给 AI它返回的不是“好的我来写”而是一份文件改动清单。你先审这份清单有没有多出来不该碰的文件有没有漏掉日志、错误处理这类横切关注点确认清单无误再让它进入到实际编码阶段。这一步相当于给 AI 画了一个“施工范围”后面它出格的概率会显著下降。3.3 生成阶段一次只让 AI 做一个文件有了任务卡进入实际编码阶段。我的习惯是一次只让 AI 修改一个文件改完立刻看 diff确认符合预期后再进行下一个。这和不加节制地让它“把整个模块都写了”相比看起来慢实际上总耗时更短。为什么因为大模型在数百行代码的长上下文里保持一致性非常困难。它在文件顶部定义的函数到文件中部可能就忘了签名里参数的名字它引用的错误类型在项目里根本不存在它写了一个工具函数却不知道项目里已经有一个功能几乎相同的实现。这些都是我实测遇到的真实问题。把任务切小之后每一段代码的上下文范围可控出错概率低出了问题也容易定位。这里顺带推荐一个我自己验证过很有效的做法每生成一个文件立刻让 AI“自查一遍”要求它对照任务卡逐条列出自己实现了哪些约束、哪些还没完成。这一步会让模型重新审视自己的输出很多低级错误在这一轮就会被它自己抓到。3.4 验证阶段自动化检查是最后一道防线AI 生成的代码无论是靠人工读还是靠模型自查都只能拦截“逻辑错误”拦不住“规范违例”和“行为回归”。所以项目里必须有可执行的检查关卡。我的最低配置是三层语法和类型检查、lint 和格式检查、自动化测试。这三层不是可选项是硬门槛。代码只有通过这三层之后才允许进入 code review 阶段。搭建这套流水线不需要复杂的 CI 系统本地用 Git 钩子就能实现。比如在pre-commit里挂上ruff、black、mypy在pre-push里跑一次全量测试。说实话我第一次搭完这套检查之后最直观的感受是AI 生成代码的表面质量以肉眼可见的速度提升。因为模型会观察到你项目里有格式规范、有类型检查它生成的代码风格会更贴近项目现状。这不是玄学而是因为大模型非常擅长从上下文里推断“这个项目看重什么”。如果你的仓库里没有任何约束信号它自然会按它最舒适的方式输出代码。3.5 提交阶段让 AI 帮你写变更说明但人来决定提交边界过去我写 commit message 经常敷衍了事后来我用一个 n8n 工作流把这件事自动化了每当 Git 仓库有新提交时工作流读取git diff调用大模型生成符合 Conventional Commits 规范的 message再通过 Git 钩子写回。一开始我直接照单全收后来发现一个问题模型常常把调试日志、临时文件、无关重构混进同一个 commit 里因为它只是基于 diff“顺水推舟”。后来我调整了做法AI 负责生成 message但提交由人决定。也就是说我先手动把改动分成逻辑独立的几个提交再让 AI 分别为每个提交生成 message。这样既享受了自动化的效率又守住了提交历史的整洁。别小看这个边界代码评审、问题追踪、版本回滚全都依赖于此。4. 把重复劳动沉淀成自动化节点我拿 n8n 和 Dify 做了什么如果你只是一个人在本地写代码前三节的流程已经够用。但从“能用”到“省心”还需要解决一件事那些跨系统的重复劳动。我一个人维护几个项目的时候每天要做大量“从 A 工具取数据整理后填到 B 工具”的零碎工作。这些活不用动脑子却必须做做多了还容易出错。这正是流程编排工具的主场。4.1 哪些活适合放进自动化流程我自己的判断标准很简单超过三次重复、步骤清晰、输入输出明确的任务就值得自动化。反过来如果任务需要频繁做主观判断或者输出质量很难量化就先别自动化。前者是流程后者是手艺。以我日常开发为例我第一批放进自动化的任务有三个根据代码变更生成 PR 描述、把新的接口定义同步成 Markdown 文档、分析失败测试的日志并给出排查建议。这三件事的共同特点是有固定的触发事件有明确的数据来源产出是文本类内容AI 恰好擅长。4.2 n8n 示例自动整理 PR 描述和变更摘要我先说最容易复制的 n8n 方案。整体流程是GitHub 的 Pull Request 事件触发 → 读取 PR 关联的 commit 和文件改动 → 调用大模型生成结构化摘要 → 把摘要回填到 PR 描述里。这里的关键配置其实就两个一是模型调用的提示词模板二是输出格式的定义。我在提示词里会明确要求请根据以下代码变更生成 PR 描述包含三个部分 1. 变更目的依据 commit message 推断不要编造业务背景 2. 主要改动点按模块列出标注新增/修改/删除 3. 测试建议指出哪些功能的回归风险最高 语言要求简洁中文结构要求Markdown 列表。实测下来这样生成的 PR 描述基本能直接用偶尔需要人补充业务背景。它的价值不只是省时间更重要的是让代码评审者不必每次都把整个 diff 啃一遍。4.3 Dify 示例把“代码评审助手”变成团队可用的服务n8n 更适合处理事件驱动的流程Dify 则更适合把“AI 能力本身”封装成稳定服务。举个例子我从零搭项目期间的痛点之一是“让每个项目成员在开 PR 之前都走一遍统一的 AI 代码评审”。传统做法是让每个人把代码贴到 ChatGPT 里问一遍问题是每个人的提问方式不同、得到的建议质量也不同。我的方案是在 Dify 里搭一个“代码评审助手”应用把评审规范写进系统提示词把团队历史 commit 和典型 BUG 记录作为知识库附件对外发布为 API。GitHub Action 在每次 PR 时调用这个 API把评审意见以评论的形式发回 PR 页面。这套做法的核心收益是“流程标准化”所有代码评审用的是同一套标准、同一个模型配置、同一个知识库而不是依赖某个人的个人技巧。比如我们规定所有路由必须显式声明请求体大小限制、所有数据库查询禁止使用裸 SQL 拼接这些规则写进知识库后模型每次评审都会自动检查。4.4 自动化能和开发流程贴合到什么程度不少人会担心接这么一堆自动化维护成本会不会很高我的答案是要分清主次。接 GitHub 事件、调模型、发评论这些链路n8n 和 Dify 都有成熟的模板搭建成本很低真正需要维护的是“业务规则本身”。我自己的经验是每个季度会花一个小时梳理脚本库里那些规则模板把已过时的约定删掉把新踩的坑补充进提示词里。这个“规则保鲜”的动作才是自动化的核心运维成本。如果三个月不更新规则自动生成的评审意见就会开始显得“外行”团队成员也会逐渐不再信任它。机器不值钱规则才值钱。5. 让 AI 真正理解你的项目上下文注入与规范文件建设前面提到过AI 编程工作流能不能跑起来很大程度上取决于你有没有给它足够的项目上下文。这一节我来展开讲讲我在每个仓库里维护的那几份关键文档以及如何把它们变成 AI 的“长期记忆”。5.1 为什么 AI 经常给出“正确的废话”先说一个现象当你让 AI 帮你审查代码它给的评论经常是“建议增加错误处理”“建议补充日志”“建议优化性能”。这些话没错但毫无用处。原因很简单它不知道这个函数被谁调用、失败时的业务影响是什么、性能瓶颈实际在哪里。它只能用通用工程经验来凑。解决这个问题的办法不是换一个更强的模型而是给它一份“项目真相”。所谓项目真相就是关于这套系统的稳定事实架构分几层、模块之间如何依赖、哪个接口是核心链路、哪些历史包袱不能碰。这些信息不在代码里却在每个老开发者的脑子里。你要做的是把它们从脑子搬到仓库里让 AI 能读到。5.2 我每个项目里必有的几份文件第一份是README.md它不只给人类看更要给 AI 看。我会在 README 里写两句“本项目的架构基线”比如“FastAPI 提供 API 层service 层处理业务逻辑repository 层封装数据访问不允许在 API 层直接操作数据库”。这句话看起来简单但它给 AI 生成的代码框定了非常明确的边界。第二份是专门的 AI 约定文件。现在很多主流工具都支持项目级指令文件比如.cursorrules、CLAUDE.md、AGENTS.md作用是在工具读取仓库时自动加载这些约定。我在里面的内容通常包含四类技术栈和框架版本、代码风格要求、禁止事项比如“禁止手写 UUID 主键统一用雪花算法”、常用命令。这份文件是 AI 在项目里行动的“行为准则”比任何口头嘱咐都管用。第三份是docs/decisions/里的架构决策记录。当一个技术选型或架构调整被确定后我会写一条简短记录说明背景、方案、替代选项和原因。这些内容能帮 AI 理解为什么代码长成现在这样避免它在后续“优化”时把有意的设计当成无意的坏味道改掉。比如我们曾经因为历史数据迁移问题放弃使用某个 ORM 的高级特性这个决策写在文档里AI 就不会反复建议启用那个特性。5.3 提示词资产化把高频指令保存成模板项目上下文解决的是“AI 知不知道”提示词资产化解决的是“AI 按什么方式干活”。我建了一个prompts/目录把高频场景的指令全部存成 Markdown 文件。举几个实际的例子review.md是代码评审指令要求 AI 先读相关测试用例再下结论并且每条意见必须标注“阻塞/建议/风格”三档refactor.md是重构指令要求保持公共接口不变、逐模块小步重构、每次改动后跑相关测试debug.md是排错指令要求 AI 先说明根因假说再给出验证方法禁止直接给出“尝试改成这样”的猜测性修复。这些模板不是学术文档它们是从真实踩坑里总结出的操作纪律。有了这些模板之后新人也很好上手。不管是我自己还是团队成员接到任务时只需要带上对应的模板文件路径AI 就知道按什么标准干活。这也让我对产出的可控性提升了一个量级——我说不清哪里好但明显感觉每次生成的代码“会说人话了”。6. 搭建过程中我踩过的坑关于上下文、重构和过度自动化前面讲的都是方法接下来这部分是血泪教训。我搭这套 AI 编程工作流不是一次成功的中间调整过好几轮有些坑现在回头看完全可以避免写出来希望你不再走一遍。6.1 项目的 AGENTS.md 越写越长第一个坑是项目约定文件过度膨胀。我一开始事无巨细地把所有规范都塞进约定文件里变量命名、缩进风格、路由命名、数据库索引规则、前端组件命名、接口错误码规范……结果文件超过了两百行。实测发现当上下文里塞满约束时大模型的注意力会被稀释它开始在一些琐碎规则上表现出“过度遵循”反而忽略了核心业务逻辑。它可能为了遵循“所有函数必须写在文件末尾”这种奇怪规定把代码结构搞得很别扭。后来我把约定文件做了分级全局通用规范放在用户级配置里比如缩进、提交信息格式项目级规范只放对当前代码库有重大影响的约定比如“必须走 repository 层”“禁止修改迁移脚本”至于那些一次性的小偏好根本不写进文件而是在任务卡里临时说明。压缩之后约定文件从两百多行降到了三十行左右AI 的遵守率反而明显提升。6.2 让 AI“顺手修一下”导致的重构事故第二个坑是我亲自踩过的。有一次我让 Cursor 修一个性能问题顺手在指令末尾加了一句“顺便把这两个函数的重名问题也理一理”。结果是它确实修了性能问题但也把两个被多处引用的内部函数改名了还自作主张地把相关的几个测试一起改了。由于改动看起来“很自洽”我在 code review 时没有细看直到线上出现调用报错才发现问题。从那以后我给自己立了一条铁律一次指令只有一个目标。任何“顺便”“既然”“不如也”这类词在写给 AI 的指令里一律禁止。如果确实有连带修改需求也必须在任务卡里明确写出来作为可追踪的独立子任务。AI 不会拒绝你的“顺便”但它会把所有改动打包成一次看起来合理的操作让你失去审查的抓手。6.3 本地模型和网络模型的选择问题还有一个细节可能很多人关注编程工作流里到底用本地模型还是云端模型。我没有绝对的结论但我现在采用的方式是混用。涉及代码生成和修改的核心环节我用更强的云端模型因为代码生成的语义理解要求高本地小模型容易在一百行以上的文件里“断片”。涉及私密代码的预处理环节比如日志脱敏、密钥扫描、内部代码审查我用本地模型或规则脚本避免把敏感信息传出去。这里说一个很容易踩的坑很多 AI 编程工具默认会把你的代码发送到某个服务端用于上下文分析。如果你在公司项目里用必须先确认你的代码合规边界再决定哪些文件可以被 AI 索引。最简单的做法是给项目加.ignore文件把包含密钥、客户数据、核心算法的目录明确排除在外。这个动作必须在搭建工作流的第一天就做等出了事再补就晚了。6.4 过度自动化为 2 分钟的事情写 2 小时的工作流关于自动化最后一个坑是“为了自动化而自动化”。我有一段时间沉迷于给各种小任务搭工作流自动生成周报、自动分类浏览器书签、自动总结每封邮件。结果这些工作流本身成了新的维护负担其中“周报生成器”用了两周就报废了因为我发现手动写周报只需要三分钟而维护那个工作流需要经常调整模板。我现在给自己定的标准是先把同样的事做五次再考虑把它自动化。如果只是偶尔一次的临时任务不值得为它搭一个需要长期维护的流程。自动化的核心价值是稳定的重复执行不是一次性炫技。这个判断标准帮我挡掉了很多其实没必要做的自动化项目。7. 这套工作流跑顺之后我现在还在这几件事上继续迭代这套工作流从零搭起来到现在已经稳定跑了将近半年。最大的变化不是代码写得快了而是我的精力分配变了过去一半时间花在“翻译自己的想法让 AI 听懂”上现在这部分沉淀成了模板和规范剩下来的精力都花在真正重要的事情上——判断一个功能的取舍、审查架构的走向、打磨那些 AI 做不了的领域细节。目前我还在迭代的方向有三个。第一个是沉淀团队自己的“反模式库”把过去线上事故和严重 bug 的根因整理成结构化条目作为代码评审助手知识库的核心素材让越界代码在合入前就被拦截。第二个是让更多非编码类任务进入工作流比如让 AI 基于历史提交生成版本发布说明、定期扫描依赖中的过时与安全风险。第三个则是有意识地控制工作流的复杂度每过一段时间就审视一遍现有的自动化节点凡是维护成本高于人工成本的果断取消。如果你正准备从零搭建自己的 AI 编程工作流我给的最实在的建议是不要照搬任何人的完整方案包括我这套。先花一天时间记录自己的开发过程找出真正重复、真正困扰你的环节从最小的一个自动化点开始跑。一个能解决你实际痛点、哪怕很小的工作流胜过一套看起来很完整但你根本用不起来的宏大系统。工具迭代很快但你为自己梳理出来的这套“人机分工方式”才是真正能一直复用的资产。