FDE 的未来：AI 工作流如何重新定义全栈开发
什么是 FDE
FDE 是我在项目笔记里用的一个缩写——Full-stack Development Engineer，全栈开发工程师。
这个词本身不新鲜，招聘网站上挂了快十年。但我关注的重点不是技能栈的宽度，而是在 AI 工具的加持下，一个人到底能覆盖多少环节。我的项目笔记里画过一个链条：老板（发现需求）、产品经理（定义产品）、设计师（界面和体验）、前端、后端、测试、运维、销售——传统意义上这是八个岗位。而我的假设是：如果每个岗位的基础产能都能被 AI 压缩，一个人能不能穿起整条线？
我把这个思路叫 OPC——One Person Company，一人公司。不是字面意义的开公司，而是一种工作方式：一个人借助 AI，完成从想法到交付的闭环。
角色转变：从执行者到调度者
我在 readme 里列了一个角色转变表。每个角色的核心能力，AI 都可以帮你分担一部分：
- 产品经理：你的想法是模糊的，AI 可以追问你把边界条件想清楚，把一句话需求展开成可执行的功能点。
- 设计师：界面布局、配色方案、组件结构——AI 设计工具已经从玩具阶段进化到能出可用稿的阶段。
- 前端/后端：Cursor 和 Claude Code 这类工具，不是自动写完所有代码，而是把你从重复劳动里拉出来。你写核心逻辑，样板代码交给它。
- 测试：测试用例的生成可以自动化。不是取代测试思维，是让你不用手动敲每一条用例。
- 运维：云平台已经把运维门槛降了很多，AI 再帮你生成配置文件和部署脚本，基本能做到一个人搞定。
关键变化不在于 AI 做得好不好，而在于你的位置变了。你不再是每个环节的第一执行人，你变成了一个调度者——把任务分发给不同的 AI 工具，自己做判断和决策。
我的笔记里有一句话："企业需要的是一个微型老板，借助 Cursor/Claude Code/Codex 胜任或调度 LLM 完成工作闭环。"这是我目前对 FDE 最准确的定义。
AI 工作流：四个节点
我在项目里搭建的是一个学习和实验性质的 AI 工作流，还没有到生产级别。但思路是清晰的，分成四个节点。
需求收敛。一个想法在你脑子里的时候感觉很完整，一旦要写出来就开始漏风。AI 在这个阶段的作用是追问——不是给你答案，是给你问题。你回答得越多，需求边界越清晰。这一步省掉的是项目中途推倒重来的概率。
架构决策。这步我没打算交给 AI。技术选型为什么选这个不选那个，取决于你对项目的预期、对技术栈的熟悉度、甚至是你想通过这个项目学什么。AI 可以帮你枚举选项的优劣，但最终那个"我选它"的判断，是你自己的事。
并行开发。前后端加测试同步推进。AI 负责生成骨架代码、样板逻辑、测试用例草稿。你写核心业务逻辑和关键路径。注意力集中在自己写的 30% 上，但 70% 的交付物来自 AI 辅助。这 70% 的代码你不能不看——review 的时间可能比你自己写还长，但它帮你跨过的是"从零到有"那道最难的门槛。
质量兜底。功能能跑和功能可靠是两回事。AI 做第一轮筛查：生成边界测试场景、扫描常见漏洞、标记高风险改动。你做最终判断。这步不是让你不测试了，是把机械的排查工作外包出去。
AIGC 和 Agent：两条并行的线
我的笔记里把 AI 能力分了两条线来梳理。
一条是AIGC（内容生成）。从 2022 年底 ChatGPT 出现开始，文本、图片、视频的生成能力一直在快速迭代。GPT、DeepSeek、智谱、Qwen、MiniMax、Kimi——大模型这条赛道上参与者越来越多，能力也越来越强。OpenAI 的图片生成、Seedance 的视频生成，都是这条线上的延伸。对于开发来说，AIGC 的直接价值是：写文档、出设计稿、生成占位内容、甚至辅助写代码注释，全部可以加速。
另一条是Agent（智能体）。Coze 这类平台让不懂代码的人也能搭出有实际功能的 Agent。LangChain 则为有开发基础的人提供了更灵活的编排能力。Agent 这条线的想象空间在于：它不只是生成内容，而是执行任务——调用工具、查询数据、串联多个步骤完成一个完整目标。在 FDE 的框架里，Agent 可以承担的角色是"虚拟员工"——你定义目标、给它工具、让它跑流程，你负责检查结果。
两条线并行发展，最终交汇在同一个点上：降低从想法到交付的摩擦力。
一些实际的问题
这些不是经验，是我在整理项目思路过程中觉得需要面对的问题。
知识边界。AI 能帮你把一件事做出来，但不能帮你理解它。如果你用 AI 生成了一段代码但它跑不通，或者跑通了但你不知道为什么，那你只是在消费 AI 的产出，没有积累任何能力。我的看法是：你可以先用 AI 跑通流程获得正反馈，但涉及核心技术的部分，必须回头补基础。顺序可以倒过来（先做再学），但"学"这一步不能跳过。
质量控制。AI 的输出不是标准答案，是一个概率分布里采样出来的结果。代码能跑不代表代码正确，更不代表代码好。我的项目笔记里目前还没有覆盖这一块的具体方案，但这是一个绕不过去的问题。写代码的人应该对自己交付的代码负责——不管那行代码是手写的还是 AI 生成的。
工具依赖。你的工作流绑定了具体工具之后，工具挂了或者不能用，你就停摆了。我对这个问题的初步思路是：不要只押一个工具。同一个环节至少知道两个可替代方案。Cursor 不能用时有 Copilot，Claude Code 不能用时有 ChatGPT。不是每个工具都要精通，但你得知道备选项在哪。
最后
这个 FDE 项目目前还在思考和搭建阶段。readme 里的角色链条、OPC 的概念、AI 工作流的节点——这些都是框架性的东西，距离验证还有距离。
但我觉得这个方向值得继续往下走。不是因为 AI 有多神奇，而是因为一个人能独立完成一个产品的门槛确实在被压低。如果你也在做类似的尝试，或者对这个方向有自己的看法，欢迎交流。
