说到 FDE很多接外包的人第一反应是又一套 AI 工作流。但用过一段时间之后我最大的感受是它解决的真正问题不是让 AI 更聪明而是让“一个人接外包”这件事不再靠“我”当 AI 的路由器。这里说的路由器不是网络设备里的转发盒子而是任务分发中间人客户把需求扔给我我翻译成 AI 能听懂的提示词AI 把结果扔回来我再理解一遍、改一遍、发给客户。一个人接三五个小项目时这个模式还能撑住一旦项目多起来真正累的不是写代码而是这种高频、低价值、重复的转发动作。FDE 这个名字在行业里并没有统一标准。我更愿意把它理解成一套面向交付事实的分解方法F 是 Function先明确功能D 是 Decompose把功能拆成可以独立验证的小单元E 是 Evidence用可检查的输出证明任务完成。这套方法的核心是把“你觉得 AI 应该会做”变成“AI 做完之后你能明确判断它做对了没有”。这篇文章会按照一个人接外包的实际工作顺序拆解先从需求拆解开始再到 AI 任务编写再到多项目隔离、批量验证和问题排查。如果你也在用 AI 编程、AI Agent 或 Cursor 这类工具做外部项目并且经常觉得“AI 做出来的东西看着像对的但一交付就出问题”这篇值得看完。1. 一个人接外包为什么容易变成“AI 的路由器”先描述一个非常常见的场景。你是一个接外包的开发者客户发来一段需求“帮我做一个企业信息展示网站要能发布新闻后台能管理员工最好加一个搜索功能。” 你收到这段话之后第一件事不是打开编辑器而是先在大脑里做转换客户说的“企业信息展示网站”到底是静态页面还是带后台新闻发布是一篇文章还是一个栏目搜索是搜标题还是全文转换完之后你把需求写成一长段提示词喂给 AI 编程工具。AI 生成了一版页面你跑起来看发现颜色不对、没有后台、搜索也不过是前端过滤。你接着改提示词再生成再改。最终交付的时候你已经在这一个需求上花了四五个小时其中大部分时间是在帮客户“翻译需求”和帮 AI “修正理解”。1.1 外包工作里最耗精力的不是写代码一个人接外包时时间往往不是花在真正写代码上而是花在这些瞬间把客户模糊的口语需求转成技术需求。把技术需求转成 AI 提示词。把 AI 输出翻译成人话判断它对不对。发现不对之后再重复前面的过程。这整个链路里你承担的就是路由器的功能接收请求转换格式转发出去接收响应再转换格式转发回去。最关键的是每一次转发都依赖你的个人判断任务一多这个判断过程就会变成瓶颈。1.2 FDE 解决的其实不是“模型能力”问题很多人以为 FDE 会像某种“高级提示词”一样让 AI 突然变聪明。实际上不是。FDE 解决的是交付过程的可管理性。它通过把需求拆成“事实单元”让每一项工作都具备三个属性输入是什么来源是什么。输出是什么长成什么样算完成。验证方法是什么能不能快速检查。当这三件事明确之后AI 的思维方式反而不重要了。你能用一套稳定流程来检查它的输出而不是靠感觉。你也不再是夹在客户和 AI 之间的唯一翻译官而更像是流程制定者客户给资料AI 按任务执行你按验收条件检查。2. FDE 的落地姿势先从一份需求拆解单开始第一次接触 FDE不要急着设计什么复杂系统。我建议先从一张“需求拆解单”开始作为所有 AI 任务的前置输入。这张单子不发给客户而是给你自己用的。它的作用是把客户那些口语化、碎片化、情绪化的需求整理成 AI 能直接执行的任务包。没有这个任务包你每次打开 AI 工具都要重新组织语言换个项目、隔几天再来又得重新理解一遍成本非常高。2.1 需求拆解单里必须有的四个部分我平时用的是这样一个结构功能编号F01 功能名称企业新闻发布 输入来源客户提供新闻标题、正文、封面图后台表单提交 功能动作保存新闻记录生成新闻详情页列表页展示最新新闻 验收条件 1. 新闻列表倒序展示发布时间 2. 详情页能正常打开且包含标题、正文、封面图 3. 后台新增新闻后列表页立即出现 4. 未填写标题时给出提示不允许保存 输出形态Web 页面 数据库记录 后台操作入口这个结构看着简单但有几个关键点值得展开说。第一“输入来源”要写清楚。很多 AI 生成功能失败是因为它不知道数据从哪里来。你只说“做新闻发布”AI 很可能只给你做一个静态列表连保存功能都没有。第二“验收条件”不能只写“页面能显示”。要写“后台新增后列表页立即出现”这种可验证的动作。AI 可以靠猜但你验收不能靠猜。第三“输出形态”决定了最后交付物的长什么样。是页面、接口、数据库表还是配置文件必须提前说清楚否则 AI 会默认给你一个“看起来完整”的前端壳。2.2 为什么拆解粒度不能太粗也不能太细把需求全拆到最小单元每一条都写成几十字的验收条件工作量大到不划算但只写一句“帮我做一个网站”AI 又一定会漏功能。我自己的判断标准是一个功能点能否在 5 分钟内完成验证。如果能说明粒度合适如果写出来之后你自己都不知道怎么快速验证那就继续拆。例如“企业新闻发布”可以拆成新闻数据模型设计后台录入表单列表展示详情页面编辑、删除、防重复提交这五件事每一个都能独立验证每一个也都对应一段更聚焦的 AI 任务。这样拆完之后你再写提示词就不需要把整个网站的需求塞进一个对话里。注意拆解单不是给客户看的文档而是给你自己用的工作台。不需要追求格式漂亮只需要保证自己看到之后知道下一步做什么。3. 从客户需求到 AI 任务一套可以复用的转化流程有了拆解单下一步就是把它转成 AI 任务。这个转化流程决定了 AI 生成结果的稳定性。很多人在这一步容易走两个极端要么把客户原话直接贴给 AI要么写一段超长提示词把各种约束全部堆进去。这两种做法我都试过效果都不理想。原话太模糊超长提示词又会让 AI 抓不住重点。比较好用的方式是按“背景、任务、输出格式、验收标准”四段式来组织。3.1 一个可以直接参考的 AI 任务模板背景 我正在给客户做一个企业官网项目。客户是一家提供企业培训服务的公司网站整体风格偏商务、简洁主色是深蓝色。网站目前使用 Next.js 开发沿用现有路由结构。 任务 实现一个新闻发布页面。管理员可以在后台输入新闻标题、正文、封面图链接保存后新闻出现在列表页。列表页按发布时间倒序展示默认每页 10 条。 输出格式 返回一个完整的页面组件代码包含表单、保存逻辑、列表展示逻辑。数据库部分使用项目中已有的 Prisma 模型不要新建数据库。 验收标准 1. 保存时标题为空会提示“请填写标题”。 2. 保存成功后页面自动刷新列表不需要手动刷新。 3. 列表按发布时间倒序。 4. 详情页可以正常展示标题、正文、封面图。 5. 代码可以直接运行不依赖额外安装的包。这个模板的核心优势不是措辞高级而是把“事实”和“假设”分开了。3.2 事实和假设要分开写别让 AI 猜客户说“风格偏商务、简洁”这是事实。但如果你在提示词里写“做一种商务感和现代感并存的高级设计”这就是在向 AI 传递假设最后做出来的东西大概率不是客户想要的。你可以按照这个原则检查自己的提示词客户有没有明确给过色值、字体、参考网站有写进去没有不要设计。功能有没有明确的数据来源知道写清楚不知道先和客户确认不要用“默认”“通常”来猜测。输出有没有明确的技术栈延用项目现有的直接说明没有项目才让 AI 推荐。当提示词里的假设越少AI 输出的结果就越可控。你不需要在提示词里表达“我很专业”只需要把事实表达准确。3.3 一次只给 AI 一个任务包不要发散外包项目里最常见的问题是开发者图省事把五个功能点一次性丢给 AI。这是 FDE 最不推荐的做法。功能点一旦多了AI 的上下文会被分散。它开始生成功能 A 的时候可能已经把功能 B 的验收条件忘了生成功能 D 的时候又可能为了适应功能 B 而把 A 的数据结构改了。所以我会把任务按依赖关系排序先做基础数据模型。再做依赖数据模型的列表和详情。最后做后台录入和编辑。每完成一个跑一遍验收条件再进入下一个。这不是让 AI 慢而是让整个工作流更容易回溯。如果最终结果出问题你能明确知道是哪一步的输入偏了不需要推翻重来。4. 单人跑多个外包项目怎么避免项目之间互相污染一个人接多个外包项目最怕的就是项目之间互相污染。这里的污染不是指代码而是指 AI 上下文的混淆。你上午在做 A 项目的官网下午切到 B 项目写后端接口如果用的是同一个 AI 聊天窗口或者同一个对话记录模型很容易把 A 项目的技术栈、设计风格和数据模型带到 B 项目里。这不是模型不聪明的表现而是因为你没有给每个项目建立隔离边界。4.1 用目录和日志把项目隔离开我建议每接一个新项目就建立一个固定的目录结构并且让所有 AI 任务都从同一个位置读取上下文。projects/ ├── customer-a-website/ │ ├── requirements/ │ │ └── demand-split.md │ ├── ai-tasks/ │ │ ├── task-001-news-model.md │ │ └── task-002-news-list.md │ ├── outputs/ │ │ ├── run-001-news-model.log │ │ └── run-002-news-list.log │ └── project-context.md ├── customer-b-api/ │ ├── requirements/ │ ├── ai-tasks/ │ └── outputs/这个结构不复杂但它强制你做三件事每个项目的需求拆解单单独存放。每次 AI 任务都有独立的任务描述文件。每次 AI 输出和运行记录都有日志。这三个动作确保你切换项目时不需要靠记忆恢复上下文而是直接打开对应目录就能回到之前的工作状态。4.2 提示词模板里必须携带项目身份标识除了目录隔离AI 提示词也需要隔离。我习惯在提示词开头固定加一段“项目身份”信息项目customer-a-website 技术栈Next.js Prisma PostgreSQL 页面风格深蓝主色、商务简洁、参考客户提供的 home-page.pdf 最近完成已完成新闻数据模型和新闻列表页 当前任务实现后台新闻表单保存后跳转到新闻列表页这段信息的价值是让 AI 明确知道“我是谁、我在哪个项目里、现在要做什么”。哪怕你用的 AI 工具没有长期记忆这段上下文也能让输出非常聚焦。4.3 批量任务别只看“能跑通”还要看日志和输出一致性如果你用 AI Agent 做批量处理比如批量生成多个页面的骨架、批量生成测试用例、批量改写接口文档你关注的不能只是“能不能跑通”。你要关注三个层面每个任务的输入文件是否都读取成功了。每个任务的输出文件是否都写入了预期位置。连续运行 10 个任务之后有没有出现任务之间互相覆盖或内容串场的情况。我遇到过最典型的坑是批量生成页面时AI 把前一个页面的公共组件引用自动复制到了下一个页面导致后一个页面引用了不存在的组件。这种问题不会立刻报错只会在运行时白屏。排查起来非常耗费时间。所以批量跑完之后不要只看“成功 10 个失败 0 个”要随机抽 2 到 3 个输出文件检查内容是否和任务描述一一对应。5. 质量不稳定时按这个顺序排查使用 FDE 流程之后不代表 AI 输出一定稳定。但它最大的好处是出问题时你有清晰的排查路径不用每次都从头猜。我一般把问题分成四类现象输出的功能和需求无关。功能做了但没有完全满足验收条件。功能第一次对第二次改需求之后乱了。AI 返回大量“看起来合理但实际无法运行”的内容。针对这些现象我会按照固定顺序排查。5.1 第一步看需求拆解单是否完整这是最高频的问题来源。举例来说客户说“加一个搜索功能”。你在拆解单里只写了“搜索框可以输入关键词展示搜索结果”。这个描述看起来没问题但“搜索”在技术上有很多种实现方式前端过滤已加载数据、后端接口模糊查询、全文搜索引擎还有跨表搜索。你没有写清楚是哪一种AI 大概率会选择最简单的那种也就是前端过滤。前端过滤在一个只有 10 条数据的页面里没问题但当数据量到上千条之后页面会明显卡顿客户就会质疑你的能力。这不是 AI 的锅而是拆解单里的验收条件没有写明搜索的数据范围、请求方式和性能预期。排查时先看拆解单再改提示词。拆解单一改任务包要同步改不要只改提示词。5.2 第二步看上下文是否存在冲突信息当同一个项目里有多轮 AI 任务时上下文很容易出现前后矛盾。比如第一次任务里你告诉 AI“数据模型用 Prisma”第二次任务里又贴了一段旧代码里面用的是 Sequelize。AI 会以你最新提供的代码为准还是以背景说明为准这取决于它如何合并信息但最终结果很可能是混用。排查方法很直接把项目身份信息和当前任务重新整理一遍删除旧任务里已经失效的描述再重新执行。不要在一个对话里粘贴太多历史代码。5.3 第三步看功能点是否太大如果你给 AI 的任务里包含了“实现后台、列表、详情、权限、分页、搜索”这么多内容那它大概率会漏掉其中一两个而且漏掉的部分不一定是你最在意的那一个。这时候把任务重新拆成五个并行小任务按依赖关系逐个执行。每个小任务都要有自己的验收条件。拆完之后你会发现AI 的完成率会明显上升。5.4 第四步看输入格式是否统一有些 AI 工具对输入有隐式要求。比如你上传一份 PDF 作为参考文档AI 可能只能读取文本读不到图片里的设计稿。你以为它看到了客户提供的设计稿实际上它只看到了文件里的一段文字描述。这类问题在白屏、样式错乱、功能缺失时特别常见。排查方法是把 AI 能读取的输入格式单独验证一遍不要假设它能“理解”图片、扫描件和复杂表格。5.5 第五步看工具本身的能力边界最后再看工具本身。不同 AI 工具的上下文窗口、代码生成能力、对项目结构的理解深度都不一样。同一条提示词在 Cursor 里可能效果很好换到通用聊天工具里效果就差了。不要盲目认定“AI 什么都能做”。如果你的任务需要长期维护一个项目结构、频繁读取项目内多个文件那就选择更侧重项目理解和 Agent 能力的工具。如果只是生成一段独立代码通用对话工具也够用。6. 长期接外包真正需要盯住的三件事流程、模板、提示词这些都属于方法论层面的东西。真正落到一个人接外包的长期场景里还有三件事比具体某个功能更重要。6.1 输入资料要能做到“可追溯”外包项目最大的风险不是代码写不出来而是需求变形。今天客户说要 A明天说要 B最后交付时又说当时说的其实是 A 加 B。FDE 的拆解单和任务日志天然替你保留了证据链。当客户提出改动时你能准确指出当前需求对应的是哪个功能点改动会影响哪些验收条件工作量发生在哪个环节。这既能避免反复扯皮也能让你在报价时有据可依。6.2 交付节奏永远优先于功能完整一个人接外包一定不要等项目全部完成再交付。原因很简单AI 生成的功能你可能自己都没有完全验证过客户如果在最后一刻才看到成品任何偏差都会变成大问题。按 FDE 的拆解单先交付核心链路登录、数据保存、列表展示、详情页。这些验证通过后再交搜索、分页、导出等周边能力。这样即使某个边缘功能延期客户也已经有可看、可用的版本不会整体推翻。6.3 把自己从“路由器”升级成“质检员”FDE 能替你减少重复转发但它替代不了验收和决策。你依然是项目里唯一能判断“这个功能交付了没有”的人。把这句话放在最后是想提醒一句工具和方法论只是帮你把精力从低价值动作里腾出来让你有更多时间盯着真正影响交付质量的环节比如客户预期的管理、验收条件的核对和关键路径的性能验证。踩过几次坑之后我发现很多项目不是模型不够强而是我一直在把自己当成路由器的转发逻辑。现在用 FDE 做拆解只是把我的转发规则变得可复用、可验证把那些靠记忆和感觉的部分全部固化成文档和日志。一个人的体力有限但流程可以替你记住越来越多的事。 一个人接外包如何摆脱AI路由器角色：FDE需求拆解方法实践
说到 FDE很多接外包的人第一反应是又一套 AI 工作流。但用过一段时间之后我最大的感受是它解决的真正问题不是让 AI 更聪明而是让“一个人接外包”这件事不再靠“我”当 AI 的路由器。这里说的路由器不是网络设备里的转发盒子而是任务分发中间人客户把需求扔给我我翻译成 AI 能听懂的提示词AI 把结果扔回来我再理解一遍、改一遍、发给客户。一个人接三五个小项目时这个模式还能撑住一旦项目多起来真正累的不是写代码而是这种高频、低价值、重复的转发动作。FDE 这个名字在行业里并没有统一标准。我更愿意把它理解成一套面向交付事实的分解方法F 是 Function先明确功能D 是 Decompose把功能拆成可以独立验证的小单元E 是 Evidence用可检查的输出证明任务完成。这套方法的核心是把“你觉得 AI 应该会做”变成“AI 做完之后你能明确判断它做对了没有”。这篇文章会按照一个人接外包的实际工作顺序拆解先从需求拆解开始再到 AI 任务编写再到多项目隔离、批量验证和问题排查。如果你也在用 AI 编程、AI Agent 或 Cursor 这类工具做外部项目并且经常觉得“AI 做出来的东西看着像对的但一交付就出问题”这篇值得看完。1. 一个人接外包为什么容易变成“AI 的路由器”先描述一个非常常见的场景。你是一个接外包的开发者客户发来一段需求“帮我做一个企业信息展示网站要能发布新闻后台能管理员工最好加一个搜索功能。” 你收到这段话之后第一件事不是打开编辑器而是先在大脑里做转换客户说的“企业信息展示网站”到底是静态页面还是带后台新闻发布是一篇文章还是一个栏目搜索是搜标题还是全文转换完之后你把需求写成一长段提示词喂给 AI 编程工具。AI 生成了一版页面你跑起来看发现颜色不对、没有后台、搜索也不过是前端过滤。你接着改提示词再生成再改。最终交付的时候你已经在这一个需求上花了四五个小时其中大部分时间是在帮客户“翻译需求”和帮 AI “修正理解”。1.1 外包工作里最耗精力的不是写代码一个人接外包时时间往往不是花在真正写代码上而是花在这些瞬间把客户模糊的口语需求转成技术需求。把技术需求转成 AI 提示词。把 AI 输出翻译成人话判断它对不对。发现不对之后再重复前面的过程。这整个链路里你承担的就是路由器的功能接收请求转换格式转发出去接收响应再转换格式转发回去。最关键的是每一次转发都依赖你的个人判断任务一多这个判断过程就会变成瓶颈。1.2 FDE 解决的其实不是“模型能力”问题很多人以为 FDE 会像某种“高级提示词”一样让 AI 突然变聪明。实际上不是。FDE 解决的是交付过程的可管理性。它通过把需求拆成“事实单元”让每一项工作都具备三个属性输入是什么来源是什么。输出是什么长成什么样算完成。验证方法是什么能不能快速检查。当这三件事明确之后AI 的思维方式反而不重要了。你能用一套稳定流程来检查它的输出而不是靠感觉。你也不再是夹在客户和 AI 之间的唯一翻译官而更像是流程制定者客户给资料AI 按任务执行你按验收条件检查。2. FDE 的落地姿势先从一份需求拆解单开始第一次接触 FDE不要急着设计什么复杂系统。我建议先从一张“需求拆解单”开始作为所有 AI 任务的前置输入。这张单子不发给客户而是给你自己用的。它的作用是把客户那些口语化、碎片化、情绪化的需求整理成 AI 能直接执行的任务包。没有这个任务包你每次打开 AI 工具都要重新组织语言换个项目、隔几天再来又得重新理解一遍成本非常高。2.1 需求拆解单里必须有的四个部分我平时用的是这样一个结构功能编号F01 功能名称企业新闻发布 输入来源客户提供新闻标题、正文、封面图后台表单提交 功能动作保存新闻记录生成新闻详情页列表页展示最新新闻 验收条件 1. 新闻列表倒序展示发布时间 2. 详情页能正常打开且包含标题、正文、封面图 3. 后台新增新闻后列表页立即出现 4. 未填写标题时给出提示不允许保存 输出形态Web 页面 数据库记录 后台操作入口这个结构看着简单但有几个关键点值得展开说。第一“输入来源”要写清楚。很多 AI 生成功能失败是因为它不知道数据从哪里来。你只说“做新闻发布”AI 很可能只给你做一个静态列表连保存功能都没有。第二“验收条件”不能只写“页面能显示”。要写“后台新增后列表页立即出现”这种可验证的动作。AI 可以靠猜但你验收不能靠猜。第三“输出形态”决定了最后交付物的长什么样。是页面、接口、数据库表还是配置文件必须提前说清楚否则 AI 会默认给你一个“看起来完整”的前端壳。2.2 为什么拆解粒度不能太粗也不能太细把需求全拆到最小单元每一条都写成几十字的验收条件工作量大到不划算但只写一句“帮我做一个网站”AI 又一定会漏功能。我自己的判断标准是一个功能点能否在 5 分钟内完成验证。如果能说明粒度合适如果写出来之后你自己都不知道怎么快速验证那就继续拆。例如“企业新闻发布”可以拆成新闻数据模型设计后台录入表单列表展示详情页面编辑、删除、防重复提交这五件事每一个都能独立验证每一个也都对应一段更聚焦的 AI 任务。这样拆完之后你再写提示词就不需要把整个网站的需求塞进一个对话里。注意拆解单不是给客户看的文档而是给你自己用的工作台。不需要追求格式漂亮只需要保证自己看到之后知道下一步做什么。3. 从客户需求到 AI 任务一套可以复用的转化流程有了拆解单下一步就是把它转成 AI 任务。这个转化流程决定了 AI 生成结果的稳定性。很多人在这一步容易走两个极端要么把客户原话直接贴给 AI要么写一段超长提示词把各种约束全部堆进去。这两种做法我都试过效果都不理想。原话太模糊超长提示词又会让 AI 抓不住重点。比较好用的方式是按“背景、任务、输出格式、验收标准”四段式来组织。3.1 一个可以直接参考的 AI 任务模板背景 我正在给客户做一个企业官网项目。客户是一家提供企业培训服务的公司网站整体风格偏商务、简洁主色是深蓝色。网站目前使用 Next.js 开发沿用现有路由结构。 任务 实现一个新闻发布页面。管理员可以在后台输入新闻标题、正文、封面图链接保存后新闻出现在列表页。列表页按发布时间倒序展示默认每页 10 条。 输出格式 返回一个完整的页面组件代码包含表单、保存逻辑、列表展示逻辑。数据库部分使用项目中已有的 Prisma 模型不要新建数据库。 验收标准 1. 保存时标题为空会提示“请填写标题”。 2. 保存成功后页面自动刷新列表不需要手动刷新。 3. 列表按发布时间倒序。 4. 详情页可以正常展示标题、正文、封面图。 5. 代码可以直接运行不依赖额外安装的包。这个模板的核心优势不是措辞高级而是把“事实”和“假设”分开了。3.2 事实和假设要分开写别让 AI 猜客户说“风格偏商务、简洁”这是事实。但如果你在提示词里写“做一种商务感和现代感并存的高级设计”这就是在向 AI 传递假设最后做出来的东西大概率不是客户想要的。你可以按照这个原则检查自己的提示词客户有没有明确给过色值、字体、参考网站有写进去没有不要设计。功能有没有明确的数据来源知道写清楚不知道先和客户确认不要用“默认”“通常”来猜测。输出有没有明确的技术栈延用项目现有的直接说明没有项目才让 AI 推荐。当提示词里的假设越少AI 输出的结果就越可控。你不需要在提示词里表达“我很专业”只需要把事实表达准确。3.3 一次只给 AI 一个任务包不要发散外包项目里最常见的问题是开发者图省事把五个功能点一次性丢给 AI。这是 FDE 最不推荐的做法。功能点一旦多了AI 的上下文会被分散。它开始生成功能 A 的时候可能已经把功能 B 的验收条件忘了生成功能 D 的时候又可能为了适应功能 B 而把 A 的数据结构改了。所以我会把任务按依赖关系排序先做基础数据模型。再做依赖数据模型的列表和详情。最后做后台录入和编辑。每完成一个跑一遍验收条件再进入下一个。这不是让 AI 慢而是让整个工作流更容易回溯。如果最终结果出问题你能明确知道是哪一步的输入偏了不需要推翻重来。4. 单人跑多个外包项目怎么避免项目之间互相污染一个人接多个外包项目最怕的就是项目之间互相污染。这里的污染不是指代码而是指 AI 上下文的混淆。你上午在做 A 项目的官网下午切到 B 项目写后端接口如果用的是同一个 AI 聊天窗口或者同一个对话记录模型很容易把 A 项目的技术栈、设计风格和数据模型带到 B 项目里。这不是模型不聪明的表现而是因为你没有给每个项目建立隔离边界。4.1 用目录和日志把项目隔离开我建议每接一个新项目就建立一个固定的目录结构并且让所有 AI 任务都从同一个位置读取上下文。projects/ ├── customer-a-website/ │ ├── requirements/ │ │ └── demand-split.md │ ├── ai-tasks/ │ │ ├── task-001-news-model.md │ │ └── task-002-news-list.md │ ├── outputs/ │ │ ├── run-001-news-model.log │ │ └── run-002-news-list.log │ └── project-context.md ├── customer-b-api/ │ ├── requirements/ │ ├── ai-tasks/ │ └── outputs/这个结构不复杂但它强制你做三件事每个项目的需求拆解单单独存放。每次 AI 任务都有独立的任务描述文件。每次 AI 输出和运行记录都有日志。这三个动作确保你切换项目时不需要靠记忆恢复上下文而是直接打开对应目录就能回到之前的工作状态。4.2 提示词模板里必须携带项目身份标识除了目录隔离AI 提示词也需要隔离。我习惯在提示词开头固定加一段“项目身份”信息项目customer-a-website 技术栈Next.js Prisma PostgreSQL 页面风格深蓝主色、商务简洁、参考客户提供的 home-page.pdf 最近完成已完成新闻数据模型和新闻列表页 当前任务实现后台新闻表单保存后跳转到新闻列表页这段信息的价值是让 AI 明确知道“我是谁、我在哪个项目里、现在要做什么”。哪怕你用的 AI 工具没有长期记忆这段上下文也能让输出非常聚焦。4.3 批量任务别只看“能跑通”还要看日志和输出一致性如果你用 AI Agent 做批量处理比如批量生成多个页面的骨架、批量生成测试用例、批量改写接口文档你关注的不能只是“能不能跑通”。你要关注三个层面每个任务的输入文件是否都读取成功了。每个任务的输出文件是否都写入了预期位置。连续运行 10 个任务之后有没有出现任务之间互相覆盖或内容串场的情况。我遇到过最典型的坑是批量生成页面时AI 把前一个页面的公共组件引用自动复制到了下一个页面导致后一个页面引用了不存在的组件。这种问题不会立刻报错只会在运行时白屏。排查起来非常耗费时间。所以批量跑完之后不要只看“成功 10 个失败 0 个”要随机抽 2 到 3 个输出文件检查内容是否和任务描述一一对应。5. 质量不稳定时按这个顺序排查使用 FDE 流程之后不代表 AI 输出一定稳定。但它最大的好处是出问题时你有清晰的排查路径不用每次都从头猜。我一般把问题分成四类现象输出的功能和需求无关。功能做了但没有完全满足验收条件。功能第一次对第二次改需求之后乱了。AI 返回大量“看起来合理但实际无法运行”的内容。针对这些现象我会按照固定顺序排查。5.1 第一步看需求拆解单是否完整这是最高频的问题来源。举例来说客户说“加一个搜索功能”。你在拆解单里只写了“搜索框可以输入关键词展示搜索结果”。这个描述看起来没问题但“搜索”在技术上有很多种实现方式前端过滤已加载数据、后端接口模糊查询、全文搜索引擎还有跨表搜索。你没有写清楚是哪一种AI 大概率会选择最简单的那种也就是前端过滤。前端过滤在一个只有 10 条数据的页面里没问题但当数据量到上千条之后页面会明显卡顿客户就会质疑你的能力。这不是 AI 的锅而是拆解单里的验收条件没有写明搜索的数据范围、请求方式和性能预期。排查时先看拆解单再改提示词。拆解单一改任务包要同步改不要只改提示词。5.2 第二步看上下文是否存在冲突信息当同一个项目里有多轮 AI 任务时上下文很容易出现前后矛盾。比如第一次任务里你告诉 AI“数据模型用 Prisma”第二次任务里又贴了一段旧代码里面用的是 Sequelize。AI 会以你最新提供的代码为准还是以背景说明为准这取决于它如何合并信息但最终结果很可能是混用。排查方法很直接把项目身份信息和当前任务重新整理一遍删除旧任务里已经失效的描述再重新执行。不要在一个对话里粘贴太多历史代码。5.3 第三步看功能点是否太大如果你给 AI 的任务里包含了“实现后台、列表、详情、权限、分页、搜索”这么多内容那它大概率会漏掉其中一两个而且漏掉的部分不一定是你最在意的那一个。这时候把任务重新拆成五个并行小任务按依赖关系逐个执行。每个小任务都要有自己的验收条件。拆完之后你会发现AI 的完成率会明显上升。5.4 第四步看输入格式是否统一有些 AI 工具对输入有隐式要求。比如你上传一份 PDF 作为参考文档AI 可能只能读取文本读不到图片里的设计稿。你以为它看到了客户提供的设计稿实际上它只看到了文件里的一段文字描述。这类问题在白屏、样式错乱、功能缺失时特别常见。排查方法是把 AI 能读取的输入格式单独验证一遍不要假设它能“理解”图片、扫描件和复杂表格。5.5 第五步看工具本身的能力边界最后再看工具本身。不同 AI 工具的上下文窗口、代码生成能力、对项目结构的理解深度都不一样。同一条提示词在 Cursor 里可能效果很好换到通用聊天工具里效果就差了。不要盲目认定“AI 什么都能做”。如果你的任务需要长期维护一个项目结构、频繁读取项目内多个文件那就选择更侧重项目理解和 Agent 能力的工具。如果只是生成一段独立代码通用对话工具也够用。6. 长期接外包真正需要盯住的三件事流程、模板、提示词这些都属于方法论层面的东西。真正落到一个人接外包的长期场景里还有三件事比具体某个功能更重要。6.1 输入资料要能做到“可追溯”外包项目最大的风险不是代码写不出来而是需求变形。今天客户说要 A明天说要 B最后交付时又说当时说的其实是 A 加 B。FDE 的拆解单和任务日志天然替你保留了证据链。当客户提出改动时你能准确指出当前需求对应的是哪个功能点改动会影响哪些验收条件工作量发生在哪个环节。这既能避免反复扯皮也能让你在报价时有据可依。6.2 交付节奏永远优先于功能完整一个人接外包一定不要等项目全部完成再交付。原因很简单AI 生成的功能你可能自己都没有完全验证过客户如果在最后一刻才看到成品任何偏差都会变成大问题。按 FDE 的拆解单先交付核心链路登录、数据保存、列表展示、详情页。这些验证通过后再交搜索、分页、导出等周边能力。这样即使某个边缘功能延期客户也已经有可看、可用的版本不会整体推翻。6.3 把自己从“路由器”升级成“质检员”FDE 能替你减少重复转发但它替代不了验收和决策。你依然是项目里唯一能判断“这个功能交付了没有”的人。把这句话放在最后是想提醒一句工具和方法论只是帮你把精力从低价值动作里腾出来让你有更多时间盯着真正影响交付质量的环节比如客户预期的管理、验收条件的核对和关键路径的性能验证。踩过几次坑之后我发现很多项目不是模型不够强而是我一直在把自己当成路由器的转发逻辑。现在用 FDE 做拆解只是把我的转发规则变得可复用、可验证把那些靠记忆和感觉的部分全部固化成文档和日志。一个人的体力有限但流程可以替你记住越来越多的事。