尧图网站建设 
最近我有个接外包的朋友在朋友圈发了一张截图左边是客户发来的需求右边是 AI 的回答中间是他自己写的一句话“我又当了一天 AI 路由器。”这个说法一下子戳中了我。一个人接外包如果每天都在做的事情是把客户的自然语言转发给大模型再把大模型的回答转发给客户那本质上就是一个带宽不错的传输节点。流量很大价值很薄。真正的问题不是你不努力而是路由器不产生内容。需求不是你理解的代码不是你验证的方案不是你有依据的。客户慢慢会发现好像直接跟 AI 交流也能得到差不多的东西那为什么要为你的转发付钱于是你只能靠更低的报价、更快的响应去维持。价格越来越低返工越来越多你还得替 AI 的幻觉兜底。这个状态持续下去根本不是“做外包”而是“被外包做”。后来我开始尝试一种叫 FDE 的工作方式有人叫它事实驱动开发更完整的说法是“面向语意的事实方法论”。它不是一个 App不是一个编程模型也不是某个大模型的专属功能。它是一套工作流程先把需求转成语义事实再基于事实组织执行和验证。它对一个人的外包最大的帮助不是让 AI 生成更多代码而是让我从路由器变成一个真正的执行者。这篇是这个系列的第二篇主要聊一个人接外包时怎么把 FDE 落到日常项目里。1. 先承认外包干得累往往是因为你在当人肉中转站1.1 典型的一天你只是在转发消息早上的场景大概是这样客户发来一句话“帮我做个订单导出功能要区分权限支持按日期筛选。”你脑子里第一反应不是问清楚“权限怎么区分”“数据存在哪”而是直接复制这句话打开某个 AI 对话框把话粘进去再补一句“帮我生成代码”。AI 很快给出一个看起来合理的方案。你把代码复制到本地跑起来以后发现接口地址是空的、权限字段也是猜的。于是你回去问客户客户说“权限我们这边有两种角色管理员和运营”。你又回到 AI 对话框把这句话继续粘进去重新生成。下午另一个客户在微信问“上次那个页面能不能把按钮颜色改一下还有表格里加一列备注。”你又打开一个聊天窗口把新需求一股脑塞给 AI。AI 给了新的代码片段你替换上去发现样式乱了又花了一个小时调试。到了晚上你终于把两个需求都交付了但脑子里一片空白今天到底解决了什么问题下次遇到类似需求是不是还要从头再来这并不是虚构这是很多一个人接外包的人的真实工作节奏。表面上看你确实在“用 AI 提效”其实你只用了 AI 的表层能力——把文本变成文本。你自己的判断、项目上下文、客户领域知识完全没有参与进去。你成了客户和 AI 之间的协议转换器而不是一个懂技术、懂业务、能交付的人。1.2 为什么人肉路由没有复利还要担风险路由器最尴尬的一点是它不存储业务语义。今天转发的订单导出需求和一个月后转发的库存导出需求对你来说只是两个不同的文本。你不会因为多转发了几次就变得更值钱。每一次对话都是全新的开始每一个项目积累的经验都只存在于聊天记录里换个客户、换个需求就全部归零。反过来风险却全部由你承担。AI 说出一个看似合理的方案你如果不加验证就直接交付出了问题客户只会找你。AI 的上下文窗口再大也不可能知道你客户的真实数据库里字段叫什么、权限规则是什么、导出文件的命名规范是什么。它会用“合理的猜测”补全这些信息而这种猜测恰好是返工和事故的主要来源。更麻烦的是客户对 AI 的预期也在变化。以前客户觉得你能用 AI 帮他解决问题现在已经有很多企业直接采购大模型工具甚至让员工用 ChatGPT 或 Copilot 处理基础需求。如果你的价值只是“帮客户把需求翻译给 AI”那你的位置随时可以被替代。你不是在和 AI 竞争你是在和客户自己的工具竞争。1.3 问题不是 AI 不够强而是你没有把“事实”和“执行”分开我并不是说 AI 不够强。实际上现在的 AI 编程能力已经相当可用尤其在生成样板代码、写测试、做初步方案时非常快。真正的问题是大多数人的工作流让 AI 在“事实缺失”的状态下替自己决策。举个例子“做个订单导出功能”这句话对于 AI 来说有太多可能的实现方式。导出的数据是从哪个表来导出时需不需要生成 Excel权限是按角色过滤还是按数据行过滤日期筛选是前端做还是后端做这些没有回答AI 就只能猜。猜对了你运气好猜错了就是返工。而事实驱动的做法是在让 AI 执行之前先把这些“事实”抽取出来整理成一份哪怕是半页纸的文档。AI 要做的不是在空白上下文里创作而是基于一份明确的事实清单去完成实现。所以你会看到一个很有意思的现象同样是使用 AI有些人越用越飘觉得自己什么都能做但交付质量不稳定有些人越用越稳因为他把每一轮沟通都沉淀成事实再让 AI 在事实之上执行。FDE 就是后一种做法的一个抽象框架。它不是更高深的 AI 技巧而是把“需求分析”和“编码执行”重新放回你和 AI 的协作中间。2. FDE 不是新工具而是一套“面向语意的事实方法论”2.1 先别神化 FDE它就是一套工作习惯你如果去搜索 FDE会看到培训、工程师岗位、操作手册、工作坊等各种内容。它们具体指什么不同团队可能并不一样。我这里更愿意把它理解成一个底层能力面向语意的事实方法论。用大白话说就是先搞清楚一段话在业务场景里“到底意味着什么”再把能确认的事实和不能确认的假设分开最后基于事实去执行而不是基于感觉去执行。它和“用 AI 写代码”最大的区别在于常规用法是“你问AI 答”FDE 的用法是“你先整理事实包AI 在事实包内执行”。事实包可以是一份文档、一组验收用例、一张数据字典、一段已有代码的结构说明。AI 不需要替你猜业务规则它只需要按照你已经确认的事实去生成工程实现。你也不需要扮演路由器因为路由决策是在事实层面做的不是文本层面。这套方法并不新鲜。做过传统软件工程的人会发现它有点像“需求分析 领域建模 验收驱动开发”只是过去这些工作要写几十页 Word 文档周期太长一个人外包根本做不起。FDE 的价值在于它把这类工作压缩成一张表、几条命令、一份要点清单让你在一个人接小项目时也能负担得起。2.2 它和普通 AI 辅助编程的区别是“提问”和“执行”的区别普通 AI 辅助编程的协作方式是提问。你给一个 PromptAI 给一段代码你把它粘到项目里跑通了就算完。这种方式适合解决孤立问题比如“Python 里怎么解析这个日期格式”“React 里怎么写一个弹窗”。但外包项目不是孤立问题它是几十个孤立问题连在一起。你如果每个点都靠提问AI 给出的每个答案都建立在不同的假设上拼在一起时就会各种冲突。FDE 把协作方式从提问变成了执行。你不是让 AI 回答“怎么做”而是给它一套已经整理好的上下文让它在这个上下文里完成一个完整的子任务。比如“根据 facts.md 中的字段定义和接口规范生成订单导出模块并保证 tests/test_export.py 通过”。这时候 AI 的能力得到的是约束而不是自由发挥。约束越多输出越可控。这也解释了为什么同一个 AI在不同人手里效果差异这么大不是模型差异而是你给它的“事实密度”差异。我之前用过一个很朴素的类比传统用法是给外卖员说“帮我买点菜做一顿饭”FDE 是先把菜单、预算、忌口和厨房现有食材列好再让外卖员按清单采购。后者看起来更麻烦但采购结果基本不会跑偏而且每一次采购都能复用同一套清单。2.3 它真正解决的是三件事可控、可复用、可积累第一可控。你不再依赖 AI 的“手感”而是依赖事实和验收标准。AI 生成的代码如果测试没过你不会慌因为你知道是哪里脱离了事实。第二可复用。所有外包项目都有大量重复结构。FDE 的事实库、模板、验证命令可以直接复制到下一个项目。第三可积累。你每做完一个项目留下的不只是一个交付物还有一组可复用的领域规则、术语表和工程底盘。这些东西才是你真正的资产。说得更直接一点外包这个行业最大的坑就是“做一单丢一单”。你经验再多如果不沉淀下个项目还是从零开始。FDE 提供了一种最低成本的沉淀方式一个 docs 目录一份 Markdown 事实卡一组测试命令。不依赖任何付费工具也不需要复杂平台只要你有基本的技术能力就能做到。3. 用 FDE 重构一次外包需求从客户原话到可验收交付3.1 第一步把客户原话拆成约束、事实、验收标准假设客户找到你只说了一句话“帮我做个订单导出功能要对权限做区分。”如果你直接把这句话发给 AI你得到的代码大概率是“看起来像”订单导出但离真正能用还很远。FDE 的做法是先拆。拆成事实当前系统里有订单数据至少包括订单号、金额、创建时间、所属区域导出格式大概率是 Excel 或 CSV权限上至少有管理员和区域运营两种角色。拆成约束区域运营不能看到其他区域的数据导出操作不能拖垮数据库导出的文件列名需要符合客户内部报表习惯。拆成验收标准管理员可以导出所有订单区域运营只能导出自己区域的订单导出的文件能在 Excel 中正常打开列名正确10 万行以内导出时间不超过设定阈值。注意上面的“事实”在真正开工前可能不是事实而是你的假设。FDE 不要求你在第一步就全知全能它要求你把每一条都标上来源和状态这条是客户确认过的还是我从现有代码里看到的还是我猜的。这个动作虽然小却决定了 AI 的生成方向。你给 AI 的假设越多它就越可能把假设当成事实来补全。3.2 第二步为每个事实准备证据区分“已确认”和“待确认”一台路由器不需要知道数据包的内容是什么它只需要转发。但一个执行者必须知道哪些信息是可靠的哪些信息还需要核实。FDE 的第二步就是建一张非常简单的事实表。事实来源状态订单数据来自 orders 表客户提供的接口文档已确认导出为 CSV 文件客户原话已确认区域运营只能导出本区域订单客户原话已确认但需要确认区域字段名导出时不能超过 5 秒我的假设待确认需询问客户这张表不需要做得多漂亮哪怕只是写在 Markdown 文件里也可以。它最大的作用是在你和 AI 协作之前先阻止你自己“瞎猜”。很多人接外包时会觉得这个问题太简单了不用问我可以直接根据常识补全。但常识不是事实客户嘴上说的“订单”和你理解的“订单”很可能根本不是同一个东西。你可以在事实卡里留一个“待确认”清单然后一次性拿去问客户而不是做一半再回头问。省下的不仅是时间还有客户对你的信任。3.3 第三步基于事实包生成可运行工程骨架而不是一段代码片段有了事实包之后你再让 AI 干活。但你要的不是“给一段函数”而是一个最小可运行的工程骨架。你可以这样要求 AI先读 docs/facts.md然后基于事实生成一个项目结构包括模型定义、接口 mock、测试用例和文档。注意这里的关键词是“可运行”。如果 AI 给的代码没办法在本地跑起来那就不是交付只是一段建议。你要把“可运行”当作最低标准。一个典型的骨架结构可能长这样project/ ├── app/ │ ├── models/ │ ├── routes/ │ └── schemas/ ├── tests/ │ ├── test_export.py │ └── conftest.py ├── docs/ │ └── facts.md └── README.md这不一定是绝对标准但可以说明问题AI 的产出应该是一个项目模板而不是一个孤立的文件。你要能在这个模板上继续迭代。事实包放在 docs/facts.md 里AI 生成代码时先读它。测试文件把验收标准转成可执行的断言这样后面每次改动都可以通过命令验证。3.4 第四步闭环验证失败后先更新事实而不是直接改代码很多技术人用 AI 的坏习惯是AI 生成代码报错了直接把报错信息贴回给 AI让它再生成一版。这其实还是在“路由”。FDE 的第四步要求你先看验证结果再判断是哪一层出了问题。如果测试失败可能的解释有三个事实不完整代码实现偏离事实测试本身写错。你要先定位是哪个再去调整。举个具体场景AI 生成了导出代码你运行pytest tests/ -q发现测试提示“区域权限过滤未生效”。这时候不要急着让 AI “修复”而应该回到事实卡看看“区域运营只能导出本区域订单”这条事实是否已经定义清楚。如果缺少“区域字段名是 region_id”这个事实AI 当然不知道按什么过滤。先把事实补上再让 AI 基于新事实改代码这次改动才有意义。闭环不是“改到不报错为止”而是“每一条事实都能对应到代码里的一个可验证行为”。经验第一次跑 FDE 流程时大概率会在“待确认”清单上花时间。这很正常。你要做的是减少无效返工而不是害怕提问。4. 为什么单次跑通容易稳定交付难问题出在事实没有沉淀4.1 典型反模式每次都从空白提示词开始外包项目看起来各不相同但底层有很多相似结构登录、权限、表单、列表、导入导出、消息通知。如果你每次都从空白提示词开始等于每次都放弃自己已有的经验让 AI 重新生成一遍。这就像你不会因为每天吃不同的菜就每天早上重新学习怎么做饭。你的厨艺之所以提升是因为你把“切菜”“调味”“火候”这些经验沉淀在自己身上了。FDE 要求你把“经验”外化。项目里积累的领域术语、业务约束、组件选型、验证命令都放进一个可检索的文件或模板库里。下次遇到类似需求你先从模板库里复制一份而不是从零开始想。这个动作看起来简单但它决定了你是“越做越轻松”还是“一直重来”。4.2 事实库和模板库是你从路由器变成资产方的分水岭路由器不保存数据所以没有资产。执行者会保存规则所以能不断优化。FDE 的核心资产可以分为三类领域术语表把客户行业里的黑话翻译成技术概念。比如“库区”到底对应哪个数据表的哪个字段。约束清单记录每个业务场景里不能逾越的规则。比如“订单导出不能包含客户手机号”。验证清单记录交付前必须通过的检查。比如“权限测试、边界数据测试、文件格式测试”。这三类东西可以全部放在项目目录的 docs/ 下也可以单独建一个模板库。刚开始不用做得多完善哪怕一个目录下只有三四个 Markdown 文件也比每次从空白开始强得多。模板库的核心价值是“可复制”接到新项目后复制一份目录改一改里面的字段、术语和业务规则就能直接当工作底稿。4.3 一个可复用框架需求事实卡这里给一个可以复用的模板结构不一定适合所有项目但可以作为起步。你可以在每个新项目开始前复制一份这个表字段说明示例项目目标客户最终要达成的业务效果销售能自动生成周度订单导出关键用户谁在使用这个功能管理员、区域运营输入数据功能依赖的数据来源和格式订单表 order导出 CSV核心规则必须遵守的业务规则区域运营只能导出本区域数据验收标准可验证的完成条件10 万行以内导出时间不超过 5 秒待确认项需要向客户追问的开放问题日期范围是否含时区写事实卡的过程本质上是在给项目“打地基”。如果你发现一个字段填不上那就说明你对需求的理解还不够需要去问客户或查文档。与其让 AI 在充满歧义的环境里替你猜不如先把歧义找出来再开工。5. 一个人外包最容易踩的 5 个坑以及怎么用 FDE 绕开5.1 坑 1客户需求不完整直接投喂 AI很多外包需求在最初都只有两三句话。客户不是故意隐瞒而是他默认你知道他的业务背景。如果连你都不知道AI 更不会知道。最稳妥的做法是先拆事实把“待确认项”列成问题一次性发给客户。你可能会觉得问太多显得不专业但恰恰相反能在开工前问出关键问题的外包才是客户眼中专业的人。FDE 不会减少提问次数它会帮你把问题集中在早期而不是后期返工。5.2 坑 2AI 生成的代码看起来对但跑不起来这是最消耗时间的坑。AI 有时会生成一个“看起来完整”的函数但缺少依赖库、字段名错误、接口返回结构对不上。避免的方法是要求 AI 给出可运行的最小 告别AI路由器：用FDE事实驱动开发提升外包交付质量
最近我有个接外包的朋友在朋友圈发了一张截图左边是客户发来的需求右边是 AI 的回答中间是他自己写的一句话“我又当了一天 AI 路由器。”这个说法一下子戳中了我。一个人接外包如果每天都在做的事情是把客户的自然语言转发给大模型再把大模型的回答转发给客户那本质上就是一个带宽不错的传输节点。流量很大价值很薄。真正的问题不是你不努力而是路由器不产生内容。需求不是你理解的代码不是你验证的方案不是你有依据的。客户慢慢会发现好像直接跟 AI 交流也能得到差不多的东西那为什么要为你的转发付钱于是你只能靠更低的报价、更快的响应去维持。价格越来越低返工越来越多你还得替 AI 的幻觉兜底。这个状态持续下去根本不是“做外包”而是“被外包做”。后来我开始尝试一种叫 FDE 的工作方式有人叫它事实驱动开发更完整的说法是“面向语意的事实方法论”。它不是一个 App不是一个编程模型也不是某个大模型的专属功能。它是一套工作流程先把需求转成语义事实再基于事实组织执行和验证。它对一个人的外包最大的帮助不是让 AI 生成更多代码而是让我从路由器变成一个真正的执行者。这篇是这个系列的第二篇主要聊一个人接外包时怎么把 FDE 落到日常项目里。1. 先承认外包干得累往往是因为你在当人肉中转站1.1 典型的一天你只是在转发消息早上的场景大概是这样客户发来一句话“帮我做个订单导出功能要区分权限支持按日期筛选。”你脑子里第一反应不是问清楚“权限怎么区分”“数据存在哪”而是直接复制这句话打开某个 AI 对话框把话粘进去再补一句“帮我生成代码”。AI 很快给出一个看起来合理的方案。你把代码复制到本地跑起来以后发现接口地址是空的、权限字段也是猜的。于是你回去问客户客户说“权限我们这边有两种角色管理员和运营”。你又回到 AI 对话框把这句话继续粘进去重新生成。下午另一个客户在微信问“上次那个页面能不能把按钮颜色改一下还有表格里加一列备注。”你又打开一个聊天窗口把新需求一股脑塞给 AI。AI 给了新的代码片段你替换上去发现样式乱了又花了一个小时调试。到了晚上你终于把两个需求都交付了但脑子里一片空白今天到底解决了什么问题下次遇到类似需求是不是还要从头再来这并不是虚构这是很多一个人接外包的人的真实工作节奏。表面上看你确实在“用 AI 提效”其实你只用了 AI 的表层能力——把文本变成文本。你自己的判断、项目上下文、客户领域知识完全没有参与进去。你成了客户和 AI 之间的协议转换器而不是一个懂技术、懂业务、能交付的人。1.2 为什么人肉路由没有复利还要担风险路由器最尴尬的一点是它不存储业务语义。今天转发的订单导出需求和一个月后转发的库存导出需求对你来说只是两个不同的文本。你不会因为多转发了几次就变得更值钱。每一次对话都是全新的开始每一个项目积累的经验都只存在于聊天记录里换个客户、换个需求就全部归零。反过来风险却全部由你承担。AI 说出一个看似合理的方案你如果不加验证就直接交付出了问题客户只会找你。AI 的上下文窗口再大也不可能知道你客户的真实数据库里字段叫什么、权限规则是什么、导出文件的命名规范是什么。它会用“合理的猜测”补全这些信息而这种猜测恰好是返工和事故的主要来源。更麻烦的是客户对 AI 的预期也在变化。以前客户觉得你能用 AI 帮他解决问题现在已经有很多企业直接采购大模型工具甚至让员工用 ChatGPT 或 Copilot 处理基础需求。如果你的价值只是“帮客户把需求翻译给 AI”那你的位置随时可以被替代。你不是在和 AI 竞争你是在和客户自己的工具竞争。1.3 问题不是 AI 不够强而是你没有把“事实”和“执行”分开我并不是说 AI 不够强。实际上现在的 AI 编程能力已经相当可用尤其在生成样板代码、写测试、做初步方案时非常快。真正的问题是大多数人的工作流让 AI 在“事实缺失”的状态下替自己决策。举个例子“做个订单导出功能”这句话对于 AI 来说有太多可能的实现方式。导出的数据是从哪个表来导出时需不需要生成 Excel权限是按角色过滤还是按数据行过滤日期筛选是前端做还是后端做这些没有回答AI 就只能猜。猜对了你运气好猜错了就是返工。而事实驱动的做法是在让 AI 执行之前先把这些“事实”抽取出来整理成一份哪怕是半页纸的文档。AI 要做的不是在空白上下文里创作而是基于一份明确的事实清单去完成实现。所以你会看到一个很有意思的现象同样是使用 AI有些人越用越飘觉得自己什么都能做但交付质量不稳定有些人越用越稳因为他把每一轮沟通都沉淀成事实再让 AI 在事实之上执行。FDE 就是后一种做法的一个抽象框架。它不是更高深的 AI 技巧而是把“需求分析”和“编码执行”重新放回你和 AI 的协作中间。2. FDE 不是新工具而是一套“面向语意的事实方法论”2.1 先别神化 FDE它就是一套工作习惯你如果去搜索 FDE会看到培训、工程师岗位、操作手册、工作坊等各种内容。它们具体指什么不同团队可能并不一样。我这里更愿意把它理解成一个底层能力面向语意的事实方法论。用大白话说就是先搞清楚一段话在业务场景里“到底意味着什么”再把能确认的事实和不能确认的假设分开最后基于事实去执行而不是基于感觉去执行。它和“用 AI 写代码”最大的区别在于常规用法是“你问AI 答”FDE 的用法是“你先整理事实包AI 在事实包内执行”。事实包可以是一份文档、一组验收用例、一张数据字典、一段已有代码的结构说明。AI 不需要替你猜业务规则它只需要按照你已经确认的事实去生成工程实现。你也不需要扮演路由器因为路由决策是在事实层面做的不是文本层面。这套方法并不新鲜。做过传统软件工程的人会发现它有点像“需求分析 领域建模 验收驱动开发”只是过去这些工作要写几十页 Word 文档周期太长一个人外包根本做不起。FDE 的价值在于它把这类工作压缩成一张表、几条命令、一份要点清单让你在一个人接小项目时也能负担得起。2.2 它和普通 AI 辅助编程的区别是“提问”和“执行”的区别普通 AI 辅助编程的协作方式是提问。你给一个 PromptAI 给一段代码你把它粘到项目里跑通了就算完。这种方式适合解决孤立问题比如“Python 里怎么解析这个日期格式”“React 里怎么写一个弹窗”。但外包项目不是孤立问题它是几十个孤立问题连在一起。你如果每个点都靠提问AI 给出的每个答案都建立在不同的假设上拼在一起时就会各种冲突。FDE 把协作方式从提问变成了执行。你不是让 AI 回答“怎么做”而是给它一套已经整理好的上下文让它在这个上下文里完成一个完整的子任务。比如“根据 facts.md 中的字段定义和接口规范生成订单导出模块并保证 tests/test_export.py 通过”。这时候 AI 的能力得到的是约束而不是自由发挥。约束越多输出越可控。这也解释了为什么同一个 AI在不同人手里效果差异这么大不是模型差异而是你给它的“事实密度”差异。我之前用过一个很朴素的类比传统用法是给外卖员说“帮我买点菜做一顿饭”FDE 是先把菜单、预算、忌口和厨房现有食材列好再让外卖员按清单采购。后者看起来更麻烦但采购结果基本不会跑偏而且每一次采购都能复用同一套清单。2.3 它真正解决的是三件事可控、可复用、可积累第一可控。你不再依赖 AI 的“手感”而是依赖事实和验收标准。AI 生成的代码如果测试没过你不会慌因为你知道是哪里脱离了事实。第二可复用。所有外包项目都有大量重复结构。FDE 的事实库、模板、验证命令可以直接复制到下一个项目。第三可积累。你每做完一个项目留下的不只是一个交付物还有一组可复用的领域规则、术语表和工程底盘。这些东西才是你真正的资产。说得更直接一点外包这个行业最大的坑就是“做一单丢一单”。你经验再多如果不沉淀下个项目还是从零开始。FDE 提供了一种最低成本的沉淀方式一个 docs 目录一份 Markdown 事实卡一组测试命令。不依赖任何付费工具也不需要复杂平台只要你有基本的技术能力就能做到。3. 用 FDE 重构一次外包需求从客户原话到可验收交付3.1 第一步把客户原话拆成约束、事实、验收标准假设客户找到你只说了一句话“帮我做个订单导出功能要对权限做区分。”如果你直接把这句话发给 AI你得到的代码大概率是“看起来像”订单导出但离真正能用还很远。FDE 的做法是先拆。拆成事实当前系统里有订单数据至少包括订单号、金额、创建时间、所属区域导出格式大概率是 Excel 或 CSV权限上至少有管理员和区域运营两种角色。拆成约束区域运营不能看到其他区域的数据导出操作不能拖垮数据库导出的文件列名需要符合客户内部报表习惯。拆成验收标准管理员可以导出所有订单区域运营只能导出自己区域的订单导出的文件能在 Excel 中正常打开列名正确10 万行以内导出时间不超过设定阈值。注意上面的“事实”在真正开工前可能不是事实而是你的假设。FDE 不要求你在第一步就全知全能它要求你把每一条都标上来源和状态这条是客户确认过的还是我从现有代码里看到的还是我猜的。这个动作虽然小却决定了 AI 的生成方向。你给 AI 的假设越多它就越可能把假设当成事实来补全。3.2 第二步为每个事实准备证据区分“已确认”和“待确认”一台路由器不需要知道数据包的内容是什么它只需要转发。但一个执行者必须知道哪些信息是可靠的哪些信息还需要核实。FDE 的第二步就是建一张非常简单的事实表。事实来源状态订单数据来自 orders 表客户提供的接口文档已确认导出为 CSV 文件客户原话已确认区域运营只能导出本区域订单客户原话已确认但需要确认区域字段名导出时不能超过 5 秒我的假设待确认需询问客户这张表不需要做得多漂亮哪怕只是写在 Markdown 文件里也可以。它最大的作用是在你和 AI 协作之前先阻止你自己“瞎猜”。很多人接外包时会觉得这个问题太简单了不用问我可以直接根据常识补全。但常识不是事实客户嘴上说的“订单”和你理解的“订单”很可能根本不是同一个东西。你可以在事实卡里留一个“待确认”清单然后一次性拿去问客户而不是做一半再回头问。省下的不仅是时间还有客户对你的信任。3.3 第三步基于事实包生成可运行工程骨架而不是一段代码片段有了事实包之后你再让 AI 干活。但你要的不是“给一段函数”而是一个最小可运行的工程骨架。你可以这样要求 AI先读 docs/facts.md然后基于事实生成一个项目结构包括模型定义、接口 mock、测试用例和文档。注意这里的关键词是“可运行”。如果 AI 给的代码没办法在本地跑起来那就不是交付只是一段建议。你要把“可运行”当作最低标准。一个典型的骨架结构可能长这样project/ ├── app/ │ ├── models/ │ ├── routes/ │ └── schemas/ ├── tests/ │ ├── test_export.py │ └── conftest.py ├── docs/ │ └── facts.md └── README.md这不一定是绝对标准但可以说明问题AI 的产出应该是一个项目模板而不是一个孤立的文件。你要能在这个模板上继续迭代。事实包放在 docs/facts.md 里AI 生成代码时先读它。测试文件把验收标准转成可执行的断言这样后面每次改动都可以通过命令验证。3.4 第四步闭环验证失败后先更新事实而不是直接改代码很多技术人用 AI 的坏习惯是AI 生成代码报错了直接把报错信息贴回给 AI让它再生成一版。这其实还是在“路由”。FDE 的第四步要求你先看验证结果再判断是哪一层出了问题。如果测试失败可能的解释有三个事实不完整代码实现偏离事实测试本身写错。你要先定位是哪个再去调整。举个具体场景AI 生成了导出代码你运行pytest tests/ -q发现测试提示“区域权限过滤未生效”。这时候不要急着让 AI “修复”而应该回到事实卡看看“区域运营只能导出本区域订单”这条事实是否已经定义清楚。如果缺少“区域字段名是 region_id”这个事实AI 当然不知道按什么过滤。先把事实补上再让 AI 基于新事实改代码这次改动才有意义。闭环不是“改到不报错为止”而是“每一条事实都能对应到代码里的一个可验证行为”。经验第一次跑 FDE 流程时大概率会在“待确认”清单上花时间。这很正常。你要做的是减少无效返工而不是害怕提问。4. 为什么单次跑通容易稳定交付难问题出在事实没有沉淀4.1 典型反模式每次都从空白提示词开始外包项目看起来各不相同但底层有很多相似结构登录、权限、表单、列表、导入导出、消息通知。如果你每次都从空白提示词开始等于每次都放弃自己已有的经验让 AI 重新生成一遍。这就像你不会因为每天吃不同的菜就每天早上重新学习怎么做饭。你的厨艺之所以提升是因为你把“切菜”“调味”“火候”这些经验沉淀在自己身上了。FDE 要求你把“经验”外化。项目里积累的领域术语、业务约束、组件选型、验证命令都放进一个可检索的文件或模板库里。下次遇到类似需求你先从模板库里复制一份而不是从零开始想。这个动作看起来简单但它决定了你是“越做越轻松”还是“一直重来”。4.2 事实库和模板库是你从路由器变成资产方的分水岭路由器不保存数据所以没有资产。执行者会保存规则所以能不断优化。FDE 的核心资产可以分为三类领域术语表把客户行业里的黑话翻译成技术概念。比如“库区”到底对应哪个数据表的哪个字段。约束清单记录每个业务场景里不能逾越的规则。比如“订单导出不能包含客户手机号”。验证清单记录交付前必须通过的检查。比如“权限测试、边界数据测试、文件格式测试”。这三类东西可以全部放在项目目录的 docs/ 下也可以单独建一个模板库。刚开始不用做得多完善哪怕一个目录下只有三四个 Markdown 文件也比每次从空白开始强得多。模板库的核心价值是“可复制”接到新项目后复制一份目录改一改里面的字段、术语和业务规则就能直接当工作底稿。4.3 一个可复用框架需求事实卡这里给一个可以复用的模板结构不一定适合所有项目但可以作为起步。你可以在每个新项目开始前复制一份这个表字段说明示例项目目标客户最终要达成的业务效果销售能自动生成周度订单导出关键用户谁在使用这个功能管理员、区域运营输入数据功能依赖的数据来源和格式订单表 order导出 CSV核心规则必须遵守的业务规则区域运营只能导出本区域数据验收标准可验证的完成条件10 万行以内导出时间不超过 5 秒待确认项需要向客户追问的开放问题日期范围是否含时区写事实卡的过程本质上是在给项目“打地基”。如果你发现一个字段填不上那就说明你对需求的理解还不够需要去问客户或查文档。与其让 AI 在充满歧义的环境里替你猜不如先把歧义找出来再开工。5. 一个人外包最容易踩的 5 个坑以及怎么用 FDE 绕开5.1 坑 1客户需求不完整直接投喂 AI很多外包需求在最初都只有两三句话。客户不是故意隐瞒而是他默认你知道他的业务背景。如果连你都不知道AI 更不会知道。最稳妥的做法是先拆事实把“待确认项”列成问题一次性发给客户。你可能会觉得问太多显得不专业但恰恰相反能在开工前问出关键问题的外包才是客户眼中专业的人。FDE 不会减少提问次数它会帮你把问题集中在早期而不是后期返工。5.2 坑 2AI 生成的代码看起来对但跑不起来这是最消耗时间的坑。AI 有时会生成一个“看起来完整”的函数但缺少依赖库、字段名错误、接口返回结构对不上。避免的方法是要求 AI 给出可运行的最小