企业官网建设流程全解析

一个人接外包，最怕的不是技术难题，而是你忙了一周交付出去，客户说“这不是我要的”。更扎心的是，客户的需求本身就是一句“做一个类似抖音的东西”，而你拿着这句话去问 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 三个字母对应的动作：

F：Fact Clarification，事实澄清。 D：Definition Alignment，定义对齐。 E：Execution 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", encoding="utf-8") as f: json.dump(data, f, ensure_ascii=False, indent=2) 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", encoding="utf-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": f"AC-{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", encoding="utf-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", encoding="utf-8") as f: json.dump(acceptance, f, ensure_ascii=False, indent=2) 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 听起来简单，真正用起来会遇到各种具体问题。我把高频问题整理成表格，方便你排查。

这些问题的共同根源，其实都是同一个：你只是为了用 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。工具就在这儿了，接下来，看你用不用。