一个人接外包最累的不是写代码而是反复在客户和 AI 之间做“翻译”。客户说需求你转述给 AIAI 给方案你再转述给客户客户说不对你再回去调 Prompt。这套流程跑下来你本质上就是一台路由器负责把两边的信号原样转发。真正干活的大模型反而没有直接和客户的需求细节建立关联。这次我们来看一个能把这个局面改掉的工程方法FDEFacts-Driven Engineering事实驱动工程。它不是某个具体的 IDE 插件而是一套让 AI 从“听指令”变成“按事实干活”的方法论。对一个人接外包、做独立开发、或者在小团队里当技术负责人的场景FDE 能减少大量重复沟通把需求变成可验证的工程资产让 AI 直接基于事实输出而不是依赖你每轮手写一堆临时 Prompt。本文将围绕“不再当 AI 路由器”这个目标拆解 FDE 的核心概念、落地步骤、配套工具链和外包项目的完整工作流并给出可直接复制的文档模板和代码示例。如果你正被“每天在对话窗口里贴需求、贴代码、贴报错”折磨这篇文章值得收藏。1. 核心能力速览能力项说明项目类型AI 工程方法论 外包/独立开发工作流实践核心思想用可验证的事实Facts驱动 AI减少人在中间转发信息主要功能需求澄清、事实抽取、规格文档生成、批量任务组织、交付验收硬件要求无特殊硬件普通开发机即可取决于选用的 AI 编程工具启动方式不需要独立启动服务按文档结构和工作流推进是否支持 API方法论本身无 API可配合支持 API 的 AI 编码工具使用是否支持批量任务支持事实库 任务清单可批量驱动 AI 产出适合场景外包接单、独立开发、小团队协作、Prompt 频繁返工的 AI 编码场景学习成本中等核心是改变提问习惯而不是学新框架需要说明的是FDE 并没有统一的官方软件包不同团队对它的解释略有差异本文采用的是“面向语义的事实方法论”这条路线把项目里所有确定的信息从需求、约束、验收标准到代码现状统一沉淀成事实清单再让 AI 基于清单做生成和校验。2. FDE 是什么从路由器到事实驱动“路由器”这个词用来形容当前很多人的 AI 工作状态非常贴切。你接到一个外包需求客户在微信里发三句话你打开 AI 对话框把这三句话粘贴进去问“帮我写个方案”。AI 写完了你又复制回去给客户看客户说“我要的不是这种风格”你再回去补一句“改成 XX 风格”。一个下午过去了你什么都没写全在转发消息。这种情况下AI 的能力没有被真正用起来因为你喂给它的不是项目的实际状态而是你临时想起的一段话。每次对话都是新的AI 没有项目上下文没有事实基线只能靠猜。你之所以觉得 AI 有时候“不聪明”往往不是模型不行而是你给的信息里“事实”太少、垃圾指令太多。FDE 的做法正好反过来。它把项目里所有已经确定的东西先结构化客户的业务背景和真实目标已经确认的功能范围明确不做的内容技术约束比如必须用 Python、必须部署在客户内网验收标准比如什么算完成什么算合格当前代码和文档的实际状态。这些信息不再散落在聊天记录里而是进入一个事实库。AI 每次被调用时先读取事实库再基于事实库生成方案或代码。你从“转述者”变成了“事实维护者”。本质上你依然在管理项目但 AI 不再依赖你每轮重新交代上下文。从材料来看FDE 被不少团队用于“能力建设与项目实施”适合从一个人摸索到小团队协作的过渡阶段。它强调的是“面向语义”的方法论事实不是简单的一条条笔记而是能被 AI 理解、被项目复用的结构化的信息资产。3. 适用场景与使用边界FDE 不是一个万能框架它最适合的场景是有明确交付物的工程任务尤其是外包开发、系统定制、内部工具开发这类“反复确认需求”的工作。适合谁一个人接外包的独立开发者需要在多个项目之间快速切换保持 AI 上下文不混乱小团队里兼顾开发和客户沟通的技术负责人需要把 AI 编程工具如 Cursor、Claude Code、豆包等接入正式项目流程的人对 AI 生成结果质量不满、想通过结构化信息提升输出稳定性的开发者。能解决什么问题减少重复解释项目背景、技术约束、代码结构写进事实库每次让 AI 做事前不用重新粘贴提升交付质量AI 根据验收标准检查自己的产出减少肉眼 Review 工作量沉淀项目经验事实库本身就是项目文档离职交接、隔月重开项目时能快速恢复上下文。不适合什么场景纯探索性、没有明确交付物的闲聊式头脑风暴客户需求每天都在剧变的极早期项目可以先跑需求澄清再进入 FDE 流程对数据安全要求极高、不允许任何代码和需求进入外部 AI 服务的核心保密项目。使用边界提醒外包项目里往往涉及客户的业务数据、代码、账号信息使用任何 AI 工具前都要确认客户是否允许。不要把客户数据、密钥、私密代码直接粘贴到无授权的外部 AI 服务里。把 FDE 用在合法合规的项目交付上这是底线。4. 从路由器到 FDE搭建事实库FDE 的落地不需要装新软件也不需要换 IDE只需要建立一个清晰的项目目录把“事实”从对话记录里解放出来。4.1 目录结构这里给出一套通用目录模板你可以按项目规模调整project-fde/ ├── facts/ # 事实库 │ ├── project-brief.md # 项目背景与业务目标 │ ├── requirements.md # 功能需求清单 │ ├── constraints.md # 技术约束与边界 │ ├── acceptance.md # 验收标准 │ └── current-status.md # 当前代码/文档状态 ├── specs/ # 由事实生成的规格文档 │ ├── 01-data-model.md │ ├── 02-api-design.md │ └── 03-ui-flow.md ├── prompts/ # 沉淀下来的可复用 Prompt 模板 ├── output/ # AI 生成结果 ├── src/ # 实际代码如果适用 └── archive/ # 历史对话记录不再作为主要依据这个结构的关键在于facts 目录是唯一的事实来源prompts 目录是复用模板而 archive 目录专门放聊天记录。为什么要单独放 archive因为聊天记录里大部分内容都没有价值全部混在一起会让 AI 分不清哪个是有效事实。4.2 事实文件格式事实不是笔记而是可验证、可被 AI 直接引用的条目。以下是一个 project-brief.md 的示例# 项目背景 - 项目名称某小型电商后台管理系统 - 业务目标帮助客户管理商品、订单、库存替代现有 Excel 流程 - 目标用户客户公司内部运营人员约 20 人 - 使用环境客户内网服务器部署Windows Server # 已确认事实 - 必须使用 Python 3.10 开发 - 数据库使用 PostgreSQL 14 - 客户不需要支付功能 - 用户角色分管理员、运营、只读访客三种 - 导出订单报表格式必须支持 .xlsx写事实库的规则就三条只写确定的事不带语气词每条都能被验证涉及代码时写明具体版本或路径。你在写的时候其实就是在替 AI 做上下文管理。4.3 用对话把事实“固化”下来事实不是一次想清楚的。你可以在每次和客户沟通后花 5 分钟把新增的确定信息补进 facts 目录。下面的 Prompt 模板可以用来向 AI 索取事实整理请阅读以下聊天记录提取其中“已确定的事实”不要包含推测、计划、闲聊。 输出格式为 markdown 列表每条事实必须以“已确认”开头并注明来源时间或上下文。 聊天记录开始 [粘贴客户沟通内容] 聊天记录结束这个模板的价值在于你不用自己逐条总结AI 直接给你事实条目你只需要核对。核对通过后贴进对应文件事实库就更新了。5. 外包项目里的 FDE 完整工作流有了事实库之后接下来的每一步都可以让 AI 基于事实执行而不是基于你当时的“灵机一动”。5.1 需求澄清阶段外包项目最容易出问题的地方就是需求不明确。FDE 的做法是先让客户回答一组结构化问题而不是直接开工。你可以给客户发一个需求确认清单也可以用 AI 辅助整理。比如请根据以下初步需求列出需要客户确认的 10 个关键问题。 每个问题都必须能通过回答消除一个歧义禁止问开放性的“你觉得怎么样”。 初步需求 [粘贴客户原始需求]这步做得好后面的返工能减少一半。很多外包项目翻车就是因为客户说“做一个类似淘宝的商城”你不追问支付、物流、商家后台、商品规格直接开做了。5.2 事实抽取与规格生成当事实库初步建好后让 AI 基于 facts 目录生成规格文档。以 API 设计为例请读取 facts/requirements.md 和 facts/constraints.md基于事实生成一份 API 设计文档。 要求 1. 只设计事实中已经明确需求对应的接口。 2. 每个接口标注请求方法、参数、返回结构。 3. 如果某个接口需要的事实不完整标注“待确认”不要自行假设。 4. 输出到 specs/02-api-design.md。这里有一个关键点下划线部分“如果事实不完整就标待确认”这句话能让 AI 收敛自己的想象力不再假装什么都知道。大部分 AI 编码工具都有“读文件”的能力把文件路径写清楚AI 会直接读取并生成。这一步的工作重心就从“写 Prompt”变成“维护事实”。Prompt 越来越简单事实越来越精确。5.3 编码阶段进入编码后不要直接让 AI“写一个登录功能”而是给出对应的事实条目和验收标准。哪怕你用 Cursor 这类交互式工具也可以先在项目根目录放一个 RULES.md 或者 FDE.md 文件让 AI 每次读取项目说明时自动带出事实。典型用法请实现订单列表导出功能要求 1. 参考 facts/requirements.md 中的订单导出需求 2. 导出格式为 .xlsx字段以 acceptance.md 第 3.2 条为准 3. 完成后自查是否满足 acceptance.md 中对应验收项。这段 Prompt 没有一句是废话。AI 知道要看哪个文件知道出口标准是什么也知道交作业前要自查。这些信息全部来自事实库而不是你现场编的。5.4 验收阶段外包交付的核心是验收。FDE 强调把验收标准也当事实管理。每个功能都应该有“怎样算完成”的描述。# 验收标准示例订单导出 - 当订单列表存在数据时点击“导出”按钮系统生成 .xlsx 文件 - 文件包含列订单号、商品名称、数量、金额、下单时间、收货人 - 数据超过 5000 条时导出时间不超过 10 秒 - 导出失败时页面显示错误提示不产生空文件。当 AI 完成功能后你不再凭感觉看代码行不行而是把验收标准发给 AI 做自检请根据 acceptance.md 中的“订单导出”验收标准检查当前代码实现是否全部满足。 逐条列出通过 / 不通过 / 无法判断并给出代码位置。这个自检过程可能会找到几个“无法判断”的项比如导出时间没有真实环境数据。这也是有价值的信息因为你接下来会知道该重点测什么而不是通篇瞎看。6. FDE 的配套工具链与 Prompt 沉淀FDE 是方法真正执行离不开工具。一个人接外包的时候工具选择尽量简单能少学一个是一个。6.1 推荐工具组合环节工具建议说明事实沉淀Markdown 文件 Git 仓库不依赖平台容易迁移AI 编码Cursor、Claude Code、豆包等选支持读项目文件的工具结构化输出按模板生成 Markdown减少格式返工代码托管Gitee / GitHub / 自建 Git事实库和代码同仓库管理任务管理简单 TODO 或看板不搞复杂项目管理工具A 股市场里没有但工具链这里确实不需要大而全。关键是事实库必须和代码在一个仓库里AI 才能同时看到“项目代码”和“项目事实”。6.2 沉淀 Prompt 模板把自己常用的 Prompt 整理成模板放在 prompts 目录。举例角色你是一个严肃的软件工程助手。 任务基于事实库执行编码或文档任务。 规则 - 事实以 facts/ 目录下的文件为准 - 如果事实缺失输出“事实不足缺少 xxx”不猜测 - 编码完成后按 acceptance.md 逐条自检 - 生成结果写入 output/ 目录并在开头注明依赖了哪些事实文件。这就是你自己的“FDE 操作手册”。刚开始可能每个项目都要调整用熟了以后新项目只需要复制一套目录结构改 facts 内容就行。6.3 让 AI 批量处理任务FDE 的另一个优势是批量任务。外包项目里有很多重复性工作比如从需求列表批量生成用例、批量生成接口文档、批量生成前后端代码骨架。你可以把任务清单写在 work-order.md 里# 批量任务清单 1. 根据 facts/requirements.md 生成用户模块的表单字段校验规则 2. 根据 specs/02-api-design.md 生成所有接口的 curl 测试脚本 3. 根据 acceptance.md 生成功能测试用例然后发一条 Prompt请逐条执行 work-order.md 中的任务每个任务的结果独立放到 output/ 目录。 不要跳过任何任务不要自行修改任务范围。如果 AI 工具支持脚本化或 Agent 模式这种批量处理会更快。即便不支持你也可以一条条执行但每条的 Prompt 都只需要一句话因为事实已经入库。7. 资源占用与执行效率观察FDE 不是重负载应用所以不需要考虑显存和 GPU。更关键的是观察它对你开发效率的影响。这套方法跑通后你会看到几个变化。第一AI 生成的代码返工率下降。因为 AI 在动手前就知道“订单导出的字段用什么、验收标准是什么”而不是靠 Prompt 里临时一句话去猜。哪怕每轮只减少 30% 的返工对一个 3 个月交付期的外包项目来说也是实打实省了很多天。第二项目切换成本大幅降低。以前手头项目一多在 A 项目和 B 项目之间切换时上下文要靠回忆。现在打开项目仓库读一遍 facts 目录就能恢复状态。对“一个人接外包”的场景这是最有价值的收益。第三重复沟通减少。客户问“上次说的那个改版到什么程度了”你不必翻聊天记录直接看 current-status.md 就行。事实库就是你的项目进度表。第四AI 输出质量更稳。稳定的核心不是模型参数而是输入信息的一致性。事实库让每次对话的输入都锚定在同一套事实集上而不是靠你临场发挥。模型的能力上限不变但输出的下限会被抬高。关于执行效率还有一个容易被忽略的点事实库本身就是项目资产。项目交付后客户如果不续约你手里还有一套完备的需求文档、规格文档和验收标准。这是下一单谈判的底气。8. 常见问题与排查方法问题现象可能原因排查方式解决方案AI 生成结果明显不靠谱事实库内容过时或互相矛盾检查 facts/ 下文件是否有冲突条目清理事实库删除猜测和过期内容AI 频繁要求补充信息事实文件里“已确认”太少查看需求文件完整性先做需求澄清补全事实再继续编码带入了不存在的需求Prompt 里混入了临时口头信息对比自己发的 Prompt 与事实库统一从事实库取需求不写临时需求客户反复改需求导致混乱需求变更没有同步到事实库检查 requirements.md 的更新时间每次变更后立即更新事实库并标注版本AI 无法读取项目文件工具权限或路径问题确认所有文件已保存且路径正确调整文件路径或使用支持全文读取的 IDE验收阶段遗漏检查项验收标准不结构化查看 acceptance.md 是否可逐条测试把验收项写成可执行的“通过/不通过”条目事实库与代码不同步改代码后没更新 current-status.md对比代码最新改动和状态记录每次提交代码同步更新状态文件批量任务中断中间某一项出错导致后续停止查看 output/ 里已经生成的文件为批量任务加单条重试机制排查逻辑已经写进表格。核心思路就一条凡是 AI 输出不对先看事实库是不是出了问题不要急着改 Prompt。这里也补充一个执行细节。使用支持 Agent 的 AI 编程工具时如果批量任务卡死或陷入循环把任务清单里的任务改小、拆分更细再重新发起。不要指望一个 Agent 一口气做完 20 个任务那是它的极限不是你的工作方式。9. 最佳实践与合规提醒9.1 让 FDE 真正跑起来的几个习惯第一事实库写“是什么”不写“应该是什么”。一旦开始往 facts 里写“我觉得用户可能想要”事实库就变质了。第二每次沟通完客户抽出 5 分钟更新事实库。当下不更新明天再回忆就会漏。对一个人接外包来说这 5 分钟是整个流程里性价比最高的投入。第三每个项目保留最小可运行配置。这里说的配置不是代码运行环境而是 FDE 目录模板加一套常用 Prompt。新项目来了复制一套改事实直接开工。第四避免把事实写得太碎。事实文件不是流水账每一项要能对应到具体的代码或文档。过于碎片化的条目会降低 AI 的检索效率也增加维护负担。9.2 外包项目必须注意的安全与合规外包项目天然涉及客户数据、业务逻辑和代码归属这比单纯写开源项目更需要注意边界。不要把客户敏感数据和密钥直接贴到未授权的 AI 服务中。如果客户强调数据不能出内网你需要考虑用私有化部署的模型或本地代码工具而不是把客户资料丢进外部 API。涉及代码交付时要在合同里写清楚 AI 辅助生成的代码的归属和授权范围。部分客户要求交付代码不得使用某些开源协议受限的组件这些约束要作为事实确定下来写进 constraints.md。不要对 AI 生成的结果不做任何审查就交付。FDE 的验收标准就是一道“合法合规 功能验收”的关卡。在交付给客户前至少要过一次人工复核特别是涉及用户登录、支付、个人信息处理等高风险模块。如果项目涉及人脸、声音、个人数据等敏感信息务必确认客户拥有合法授权并在交付文档中明确数据处理范围。这一点尤其适合承接数字人、语音助手、图像识别类外包项目的开发者。10. 总结与下一步FDE 最值得尝试的点不是它带来某个新功能而是它改变了你和 AI 的协作位置。从“路由器”变成“事实库管理员”之后你的时间会从复制粘贴和反复解释里释放出来真正回到项目管理和方案决策上。最先应该验证的内容是“事实库 AI 读取文件”的最小闭环。具体做法是建一个 facts 目录把需求、约束、验收标准写进去然后给 AI 发一条带有文件路径的编码任务观察它是否按照事实生成结果。这一步跑通后整个 FDE 的骨架就立住了。最容易踩的坑不是 AI 不够聪明而是事实库没有及时更新。建议从第一个项目开始就养成“沟通完立刻更新 facts”的习惯否则 FDE 会退化成普通的文档堆砌反而比直接写 Prompt 更麻烦。后续可以扩展的方向包括把事实库接入 CI/CD让每个 Pull Request 都自动核对验收标准把常用 Prompt 封装成团队共享模板在多个外包项目之间复用事实库模板减少启动成本。对一个人接外包来说先做到前三个习惯就已经很够用了。如果你还在频繁地“两头传话”下次可以从一个更简单的问题开始今天这个项目里有哪些已经确认的事实是我还没告诉 AI 的写下来再让 AI 工作。你会发现这个问题的价值远高于琢磨一句更花哨的提示词。
