一个人接外包最怕的不是技术难题而是你忙了一周交付出去客户说“这不是我要的”。更扎心的是客户的需求本身就是一句“做一个类似抖音的东西”而你拿着这句话去问 AI 要方案得到一份看起来什么都对、实际上什么都不能直接用的计划书。你夹在客户和 AI 中间白天翻译需求晚上翻译代码本质上就是一个“路由器”——只负责转发数据包不做任何加工。这个系列的第一篇我已经聊过“一个人接外包为什么要重新定义工作流”。这一篇我想把真正解决问题的工具讲透FDE。先说判断FDE 不是某个新的编程框架也不是某个 AI 插件它是一套面向语义和事实的工作方法。它的核心价值是把“客户脑子里模糊的想法”变成“AI 能理解、你也能验收的明确任务”。如果你正在一个人接外包、带小团队、或者在甲方内部做数字化项目这套方法能直接减少返工、扯皮和“我觉得你懂了”的沟通幻觉。这篇文章会从三个层面展开第一为什么一个人接外包特别容易变成“AI 的路由器”这件事有多危险。第二FDE 到底是什么它和普通提示词工程有什么区别。第三FDE 怎么落地到真实项目里我会给你可以直接抄走的模板、脚本和检查清单。读完你至少能解决一个问题下次接到一个模糊需求时知道第一步不是打开 AI 对话框而是先做一次 FDE 事实澄清。1. 先承认吧一个人接外包你正在当 AI 的路由器“路由器”这个比喻放在一个人接外包的场景里其实是非常精准的。你回忆一下最近的项目流程客户发来一段语音或几句零散文字你听完之后有点懵但不好意思追问太多于是打开 AI 工具把这句原话粘贴进去让它帮你生成需求文档、技术方案、甚至代码。AI 确实很快你也觉得心里踏实了。然后你把这堆材料稍微改两下发给客户客户说“可以先做吧”。于是你就照着 AI 给的方案开始写代码。整个过程里你扮演的角色是什么是把客户的原话转交给 AI再把 AI 的结果转交给客户。数据确实经过了你但你没有对数据做任何加工。你也没有判断客户这句话背后是不是有另外的意图没有验证 AI 生成的技术方案是不是真的适合当前的项目预算、团队规模和时间周期。这就是路由器的定义它只负责把数据包从一个网络转发到另一个网络它不修改数据内容也不对数据是否到达负责。有人会觉得这样做也没问题啊效率很高啊。但问题恰恰出在这里。第一路由器模式不产生信息增量。客户自己也可以打开 AI 工具把需求贴进去那客户为什么要付费给你他要的是你替他把模糊变成清晰、把不可能变成可能、把风险提前挡掉。如果你只是转发你就没有提供价值。第二路由器模式让你无法对结果负责。因为你自己都没有完全理解需求一旦 AI 生成的东西有问题你连怎么改都无从下手。你只能继续拿错误的结果去问 AI形成了一连串的错误放大。第三路由器模式极其容易被替代。客户只要试过一次 AI 对话就会想既然他能帮我生成方案那我为什么还要找外包不用等到被 AI 替代你就会被“会提问题的同行”替代。所以这篇文章要解决的第一件事就是让你意识到一个人接外包最大的危机不是写不出代码而是你变成了 AI 和客户之间的透明管道。2. FDE 是什么一套让 AI 从“快”变成“准”的工作方法FDE 这个缩写在不同场景下有不同的解释。在存储领域它可能指全盘加密但在这篇文章讨论的语境里——结合“FDE 面向语意的事实方法论”“FDE workshop 能力建设与项目实施”这些信息——它指的是一套面向自然语言需求的事实驱动方法。我把它拆成三个环节这也是 FDE 三个字母对应的动作FFact Clarification事实澄清。 DDefinition Alignment定义对齐。 EExecution Verification执行验证。一次性解释这三个词会很抽象我们放到一个小场景里看。假设客户跟你说“我要做一个卖课程的网站主要功能就是会员能看视频最好支持手机端。”普通人的反应打开 AI输入“帮我设计一个在线教育网站方案”然后等着 AI 输出一份包含技术选型、数据库设计、页面列表的文档。FDE 的做法完全不同。第一步事实澄清。你不能直接接受“卖课程的网站”这个说法。你要追问课程是录播还是直播视频需不需要加密防盗会员体系是包月还是单课购买手机端是 H5 还是有 App 计划支付走微信还是支付宝有没有后台管理谁上传课程需不需要分销、拼团、优惠券这些问题不是闲聊是在收集“事实”。只有把客户那句模糊表述拆成一个个可验证、可确认的事实点后续交给 AI 的任务才是准确的。第二步定义对齐。拿到了事实接下来要跟客户对齐“什么叫完成”。很多项目烂尾不是因为开发者没能力而是因为双方对“完成”的定义不一样。开发者觉得“视频能播放”就是完成客户觉得“能像腾讯课堂一样流畅、有记忆播放、有倍速”才是完成。对齐的方式是把“完成”拆成可验收的定义能注册登录、能播放视频、能记录学习进度、能在手机端自适应。每一条都写清楚客户确认了才算数。第三步执行验证。在让 AI 写代码之前先想清楚怎么验证结果。比如“视频播放”这个功能验证方式是什么是打开页面、点播放、看 10 秒不断流还是用自动化脚本测试播放成功率验证标准先定了你才知道 AI 写的代码到底合不合格而不是“看着能跑就行”。所以FDE 的本质是什么是一套把“人类模糊意图”转成“机器可执行任务”的中间层方法。它解决的不是 AI 会不会用的问题而是你和客户、你和 AI 之间信息损耗的问题。2.1 FDE 和提示词工程不是一回事很多人第一次接触 FDE会误以为它只是在教我怎么写提示词。这是一个很大的误解。提示词工程解决的是“如何让 AI 理解你的话”。它的核心动作是把需求写得更清楚、更结构化比如“你是一名资深后端工程师请设计一个支持高并发的课程购买系统数据库用 MySQL接口用 RESTful 风格”。FDE 解决的是“你和客户、你和 AI 之间有没有对齐事实”。它的核心动作是先把需求里的事实搞清楚、把定义对齐、把验证方式定好然后再考虑写什么提示词。对比一下你就明白了提示词工程是驾驶技术解决的是“车怎么开得稳”。FDE 是导航规划解决的是“目的地到底是不是这里”。如果目的地错了驾驶技术再高也没用。你开着 AI 这辆车一路狂飙到客户根本不想去的地方最后还是要返工。我在实际项目里的体感是提示词写得再好也救不了一个需求边界模糊的项目。但 FDE 做扎实了提示词哪怕写得粗糙一点AI 也能给出相对可靠的结果因为输入信息的方向是对的。3. 一个人接外包FDE 到底改了什么你可能会问这些道理听起来都对但一个人接外包本来就时间紧再搞一整套 FDE 流程不是更慢吗这是一个特别真实的问题。也是我敢写这篇系列文章的原因FDE 确实是给项目加了一道工序但它省掉的返工时间远远大于它占用的时间。一个人接外包最常见的三个困境需求含糊导致返工。客户说“做个后台”做完之后客户说“我要的不是这种后台”。FDE 让你在动手前就把后台的功能列表、权限模型、数据字段跟客户逐条确认返工概率大幅降低。AI 生成错误方案。因为需求没澄清你拿去问 AI 的是模糊问题AI 给你的是“看起来完整但实际经不起推敲”的方案。FDE 让你拿给 AI 的是有明确边界的任务AI 的幻觉会少很多。验收环节扯皮。项目做完了客户凭感觉说“这里不对”“那里不行”。FDE 在项目开始前就把验收标准写进了文档后期扯皮时你有一条清晰的底线。也就是说FDE 改变的其实是外包项目里最耗精力的三个环节需求收集、方案评审、验收确认。它不是在给你增加负担它是在把原本模糊地消耗你精力的部分变成结构化、可检查、可追溯的流程。3.1 一个需求澄清单模板为了让你直接上手我分享一个我自己在项目里用的需求澄清单模板。它不复杂但每个字段都有明确目的。字段要填的内容设计目的项目背景客户为什么要做这个项目解决什么问题避免只做功能忽略业务目标目标用户谁会用这个系统有多少人使用频率影响性能设计和交互设计核心功能必须有的功能列表按优先级排序明确范围和排期非目标明确本期不做的事情防止范围蔓延关键约束预算、时间、技术栈偏好、合规要求影响方案选型验收标准每个功能做到什么程度算通过避免验收扯皮风险点客户已经提到的担心或你能预见的坑提前暴露风险每次接到新项目先花 15 分钟把这个表填完。如果客户给的信息不够就带着问题去问而不是带着一句话去问 AI。这个过程本身就是你作为外包开发者最值钱的部分。4. FDE 落地从需求澄清到验收回滚的完整链路上面讲的是概念和模板这一节我们把 FDE 放进一个完整的外包项目生命周期里看。一个典型项目从接单到交付按 FDE 的思路可以拆成六个步骤4.1 第一步接单后的首次事实澄清接到客户咨询后不要急着报价也不要急着出方案。先约一次 30 分钟左右的语音沟通围绕前面那张需求澄清单逐项提问。这一步的关键技巧是不要问“这个功能大概要怎么做”要问“你现在是怎么做的”。客户现在用手工表格管理课程你才知道他为什么需要一个后台客户现在用微信收付款你才知道支付功能对他的意义。事实澄清的前提是先了解现状而不是直接谈未来。4.2 第二步把澄清单转成面向语义的需求描述澄清单填完之后你手上已有一份事实清单。接下来要做的是把这份清单转化成 AI 能理解和执行的“任务描述”。这里有个重要原则不要发给 AI 一整段客户的原始语音转文字而是先自己做一次语义加工。什么叫语义加工就是你把澄清单里的信息组织成项目要解决的问题是什么。目标用户是谁、使用频率如何。核心功能有哪些优先顺序是什么。明确不做什么。有没有合规、安全、部署方面的约束。把这段信息作为 AI 提示词的背景输入AI 给出的方案和代码质量会有一个明显提升。4.3 第三步用 AI 生成方案但你自己做定义对齐拿到 AI 的方案后你不能直接转给客户。要做一次“定义对齐”检查AI 给出的功能列表和澄清单里的核心功能是否一一对应AI 建议的技术栈是否符合客户的预算和团队维护能力AI 列出的验收标准和客户心中“完成的定义”是否一致这个步骤里你的角色是“对齐器”不是“传声筒”。你发现 AI 方案里出现了“使用 Redis 缓存课程列表”但客户的项目可能只有几十个用户这时候你要判断这个技术方案是否过度设计而不是直接转给客户。4.4 第四步拆解任务让 AI 按事实点执行项目进入开发阶段你会经常和 AI 协作写代码。这里的 FDE 要求是每次给 AI 下达任务时都要基于一个明确的事实点。比如“给课程表增加一个 status 字段”这个任务背后的事实是“课程需要上下架管理”。你写提示词时应该把这个事实背景带上而不是干巴巴地写“加字段”。带事实背景和不带事实背景的区别特别大带背景时 AI 会理解这个字段的业务语义连带着给你生成正确的查询逻辑和管理接口不带背景时 AI 只会机械地加字段后续你还要再补一堆指令。4.5 第五步执行验证不等于“看着能跑”FDE 里的验证环节很容易被外包开发者忽略。很多人的验证方式是自己本地跑一下看到页面出来了接口通了就觉得完成了。更接近 FDE 的验证方式是对照需求澄清单里的验收标准逐条检查。如果验收标准是“用户可以上传课程视频并点播”你的验证就应该是我上传一个 1GB 的测试视频模拟正常网速播放看是否卡顿、是否需要转码、手机上是否兼容。这个验证过程你可以让 AI 帮你生成测试数据、测试用例但最终的判定要由你基于事实完成。因为 AI 不会知道客户心中的“流畅”是 3 秒还是 1 秒。4.6 第六步交付时的验收回滚机制交付阶段FDE 的最后一步是确认验收结果。如果客户提出了清单之外的新需求你要能判断它是“本期该做没做的”还是“全新的范围变更”。这时候需求澄清单就是你的证据。如果新需求不在清单里合理的做法是进入新的需求变更流程而不是默默加班实现。这样做的目的不是为了推卸责任而是让项目有一个可回溯的边界。双方都清楚当初约定的是什么后期改动走什么流程。这是一个人接外包保护自己的最重要手段。5. 用 Python 实现 FDE 流程中的三个关键脚本前面讲的是方法论这一节我们把它编程化。你不需要专门开发一套工具只需要三个小脚本就能让 FDE 流程的半自动落地变成现实。这三个脚本面向的是一个人接外包时最繁琐的环节把零散的交流记录整理成结构化需求条目。检查需求描述里是否有未定义术语、缺失指标等事实漏洞。从需求条目生成验收检查清单。我用 Python 标准库实现不依赖任何第三方包复制到你的电脑上就能跑。5.1 脚本一需求条目清洗器用途把客户丢过来的零散文字拆成一条一条可识别的需求条目。# 文件路径fde_tools/requirement_cleaner.py import re import json RAW_TEXT 客户原话 我要做一个课程网站用户可以注册登录看视频课程。 最好有一个后台我能自己上传课程不用每次都找你。 视频要能在手机上正常看。 支付的话先不用后面再说。 def clean_requirement_text(raw_text: str) - list: lines [line.strip() for line in raw_text.splitlines() if line.strip()] requirement_lines [] for line in lines: if line.startswith((客户原话, 补充, 确认)): continue requirement_lines.append(line) # 按中文句号、分号、换行拆分为候选条目 candidates [] for line in requirement_lines: parts re.split(r[。\n], line) for part in parts: part part.strip() if part and len(part) 4: candidates.append(part) return candidates def main(): requirements clean_requirement_text(RAW_TEXT) print(清洗后的需求条目) for idx, req in enumerate(requirements, 1): print(f{idx}. {req}) data {requirements: requirements} with open(requirements.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(已保存到 requirements.json) if __name__ __main__: main()运行方式cd fde_tools python requirement_cleaner.py这段代码做的事很简单读取客户原话跳过无效行按句末标点切分得到需求候选列表并保存成 JSON 文件。关键不是这个逻辑有多复杂而是它强制你把“客户原话”转成“可管理的条目”为下一步的澄清和排期打基础。5.2 脚本二事实完整性检查器用途检查需求条目里有没有“没法直接执行”的模糊描述。# 文件路径fde_tools/fact_checker.py # -*- coding: utf-8 -*- import json import re VAGUE_PATTERNS [ (r类似.*的东西, 使用了模糊类比), (r大概|好像|差不多|应该, 存在模糊量词), (r可以.*吗|能不能.*一下, 需求表述为疑问句), (r支持.*就行, 验收标准不明确), ] MISSING_FACT_KEYWORDS [多少, 多久, 多快, 几个, 什么格式, 谁] def check_requirements(json_path: str requirements.json) - list: with open(json_path, r, encodingutf-8) as f: data json.load(f) issues [] for idx, req in enumerate(data[requirements], 1): line_issues [] for pattern, desc in VAGUE_PATTERNS: if re.search(pattern, req): line_issues.append(desc) for keyword in MISSING_FACT_KEYWORDS: if keyword in req: line_issues.append(f缺少事实信息{keyword}) if line_issues: issues.append({index: idx, requirement: req, issues: line_issues}) return issues def main(): issues check_requirements() if not issues: print(没有发现明显的事实缺失可以进入方案阶段。) return print(发现事实风险点) for item in issues: print(f[条目 {item[index]}] {item[requirement]}) for issue in item[issues]: print(f - {issue}) if __name__ __main__: main()这段代码的作用是“挑刺”。你只需要把需求条目传给它它会自动找到那些没法直接执行的模糊表达。比如客户说“类似抖音的东西”脚本会提示“使用了模糊类比”提醒你继续追问。这里有一个很关键的工程认知事实完整性检查本质上不是靠 AI 帮你做判断而是靠规则把高风险语句标记出来。规则虽简单但比 AI 更稳定。AI 可能这次能识别、下次就漏了正则规则不会。5.3 脚本三验收清单生成器用途从需求条目和事实检查结果中生成一份验收检查清单供项目中期和交付时使用。# 文件路径fde_tools/acceptance_generator.py # -*- coding: utf-8 -*- import json def generate_acceptance(requirements: list) - list: checkout_list [] for idx, req in enumerate(requirements, 1): item { id: fAC-{idx:03d}, requirement: req, acceptance_criteria: _build_criteria(req), status: pending, } checkout_list.append(item) return checkout_list def _build_criteria(req: str) - str: # 简单启发式把需求转成“能/支持/通过”的验证描述 if 登录 in req or 注册 in req: return 使用测试账号完成注册/登录验证异常密码提示是否合理 if 视频 in req or 播放 in req: return 上传测试视频验证 PC 端与手机端均可播放且进度可记录 if 后台 in req or 管理 in req: return 使用管理员账号登录后台完成一次课程上架与下架操作 if 支付 in req: return 走通一次完整支付流程确认回调与订单状态更新一致 return 对照需求描述在测试环境执行一次主流程并确认结果 def main(): with open(requirements.json, r, encodingutf-8) as f: data json.load(f) acceptance generate_acceptance(data[requirements]) for item in acceptance: print(f{item[id]} | {item[requirement]} | {item[acceptance_criteria]}) with open(acceptance_checklist.json, w, encodingutf-8) as f: json.dump(acceptance, f, ensure_asciiFalse, indent2) print(验收清单已生成acceptance_checklist.json) if __name__ __main__: main()这段脚本把需求条目转成验收动作的匹配逻辑规则很“启发式”但它解决了两个真实问题一是你不需要从零开始想每个需求的验收方法脚本给你一个起点。二是你在交付阶段可以直接拿着这份清单跟客户过而不是靠脑子回忆“当初是不是这么说的”。6. 运行结果与效果验证把三个脚本串起来跑一遍你会看到完整流程cd fde_tools python requirement_cleaner.py python fact_checker.py python acceptance_generator.py第一条命令会输出清洗后的需求条目 1. 我要做一个课程网站用户可以注册登录 2. 看视频课程 3. 最好有一个后台我能自己上传课程 4. 视频要能在手机上正常看 5. 支付的话先不用后面再说第二条命令会输出发现事实风险点 [条目 1] 我要做一个课程网站用户可以注册登录 - 缺少事实信息多少 [条目 2] 看视频课程 - 缺少事实信息什么格式说明“多少用户、视频格式”这些关键事实还没有确认你应该带着这些问题去问客户而不是带着需求去问 AI。第三条命令会输出AC-001 | 我要做一个课程网站用户可以注册登录 | 使用测试账号完成注册/登录验证异常密码提示是否合理 AC-002 | 看视频课程 | 上传测试视频验证 PC 端与手机端均可播放且进度可记录 AC-003 | 最好有一个后台我能自己上传课程 | 使用管理员账号登录后台完成一次课程上架与下架操作 AC-004 | 视频要能在手机上正常看 | 上传测试视频验证 PC 端与手机端均可播放且进度可记录 AC-005 | 支付的话先不用后面再说 | 对照需求描述在测试环境执行一次主流程并确认结果如果运行失败第一步先检查 Python 版本建议使用 Python 3.8 以上。第二步检查当前目录下是否存在 requirements.json因为第二个脚本依赖第一个脚本的产物。第三步看控制台报错堆栈通常都是文件路径问题不会涉及复杂依赖。特别提醒这里生成的验收清单只是一个开始你还需要结合项目实际情况把“支付的话先不用”这类条目改成“不包含支付功能”在范围边界上写清楚。因为“先不做”和“以后做”在项目语义里是两回事。7. FDE 使用中的常见问题与排查思路FDE 听起来简单真正用起来会遇到各种具体问题。我把高频问题整理成表格方便你排查。问题现象可能原因排查方式解决方案客户拒绝回答澄清单上的问题客户担心预算增加或觉得你不够专业换一个沟通方式把问题包装成“帮你梳理需求”用选择题代替填空题给出默认选项让客户选AI 生成的代码里出现不存在的 API提示词里的需求描述超出 AI 知识边界或版本信息过时检查 API 文档确认类名和方法是否存在把需求拆成更小粒度先让 AI 输出关键 API 签名再写代码客户在开发中频繁加需求前期定义对齐不到位范围边界不清晰对照需求澄清单检查新需求是否在清单内启动变更流程重新排期和报价验收阶段客户不认账验收标准没有被记录和确认找出需求澄清单和验收清单确认记录以后每个项目都要让客户在澄清单上电子签名确认需求清洗脚本把有效信息误删了规则太简单断句逻辑不完善检查 requirements.json看哪些条目缺失手工修正脚本里的断句规则或补充例外情况我感觉自己已经是在套模板没有真正理解客户只走了 FDE 的形式没有做事实追问回顾澄清单里是否有“客户现状”字段每次沟通至少问一个关于现状的问题这些问题的共同根源其实都是同一个你只是为了用 FDE 而用 FDE而没有真正在意“事实”这两个字。FDE 不是让你把模板发给客户就完事而是让你在填模板的过程中真正搞清楚客户要什么、不要什么、为什么。8. 一个人用 FDE 接外包的最佳实践清单FDE 用得好不好不取决于你背得多熟而取决于你有没有形成一套稳定的工作习惯。以下是我认为一个人接外包时最值得养成的最佳实践每条都有明确目的。第一每个项目单独建一个目录里面放requirements.json、acceptance_checklist.json、conversation_log.md。不要把所有项目混在同一个文档里。原因是后期回溯和纠纷处理时你能拿出干净的、按项目隔离的证据链。第二需求澄清单上的每一条都要让客户确认过。不是说“我发给你了”就完了而是要让客户回复“确认”或“没问题”。记录客户确认的时间和内容这是你后期保护自己的第一道防线。第三所有交给 AI 的提示词都附上一条事实背景。比如给 AI 写接口时说明“本项目用户规模约 500 人不需要做超级复杂的缓存设计”。这样 AI 不会擅自引入重型依赖你也不至于收到一个过度设计的方案。第四在代码审查时把验收清单拉出来逐条过。AI 写代码可以很快但你作为交付主体必须保证每一行代码都能对应到一条需求。找不到对应关系的代码就是潜在的返工点。第五不要把所有客户原始聊天记录直接塞给 AI。先用自己的话把客户需求转述一遍再发给 AI。这个过程能强迫你理解需求也能帮你建立语义加工的能力。长期练习下来你对需求的敏感度会明显高于同行。第六涉及安全、权限、数据库变更的操作不要在客户的正式环境上直接做。先在本机或测试环境验证再申请生产环境变更。一个人接外包时没有团队帮你兜底规范的变更流程是你的安全网。第七把 FDE 的模板沉淀成自己的私有工具库。每做完一个项目回去修改你的fact_checker.py规则结合这次项目踩到的坑让工具变得更强。下一篇文章我会进一步拆解如何用 Cursor AI 等工具把这类脚本工程化让 AI 帮你管理整个需求链路。9. 总结从“路由器”到“加工者”只差一次转身写到这里你应该已经看清了一个人接外包最值钱的能力从来不是写代码的速度——那是 AI 最擅长的事。最值钱的能力是定义问题的能力把客户模糊的“我想做个东西”变成 AI 能执行、客户能验收、你能负责的明确任务。FDE 的整套方法本质上就是帮你完成这个转身。它不复杂先做事实澄清再做定义对齐最后做执行验证。每一步都是在减少信息损耗每一步都在把“转发”变成“加工”。它也不需要你额外学习多么高深的技术三个 Python 脚本已经能覆盖需求整理、事实检查和验收清单生成的大部分工作。你真正要做的是养成习惯在接到需求的第一时间不是打开 AI 对话框而是拿出澄清单。如果你正准备接下一个外包项目我给你一个最小的行动建议先复制上一节的需求澄清单模板花 15 分钟填一次再带着这张表去跟客户谈。你会发现同样一个客户、同样一个需求你问出来的问题和以前完全不一样了。客户也会因为你问得专业而更愿意为你的时间买单。从 AI 的路由器到 AI 的加工者中间只隔着一套 FDE。工具就在这儿了接下来看你用不用。