纯干货！零基础小白怎么开始做 FDE？拆解观猹课程（附简历 面试 作品集技巧）｜觉醒AI知识库

纯干货！零基础小白怎么开始做 FDE？拆解观猹课程（附简历 面试 作品集技巧）

FDE 前线部署工程师被称为 AI 时代最接近客户结果的岗位。拆解岗位职责、三种类型、第一个项目怎么接、SOW/Spec/Demo/MVP、Skill/CLI/Subagent/Hook 沉淀、API/MCP/UI 自动化接入、EDD 评测六步循环，以及简历作品集面试准备。

更新时间：2026-08-16

实操教程

年薪最高22万美元的AI 行业新岗位——FDE，有人说这是 AI 时代最接近客户结果的岗位；也有人说就是驻场外包换了个英文名字。

我把观猹训练营的内容看完后，发现这个岗位并不简单。下面带小白深入来了解一下FDE到底是什么？该怎么入行？简历，作品集和面试如何准备。

目录

一、FDE 到底是做什么？

二、FDE的具体分类：商务型 ，产品型，工程型

三、第一个项目怎么开始

四、SOW、Spec、Demo、MVP： 容易忽略的细节

五、Skill、CLI、Subagent 和 Hook：内容沉淀和复用

六、API、MCP、CLI 和 UI 自动化：企业系统到底怎么接？

七、传统测试不适合agent：EDD循环六步走

八、辨别真假岗位，简历、作品集与面试

最后

一、FDE 到底是做什么？

FDE 是 Forward Deployed Engineer 的缩写，通常译为“前线部署工程师”。

这里的“前线”指客户现场：FDE 进入客户的真实环境，理解业务、连接数据和系统，在现场快速构建应用，并把一线经验反馈给产品团队。

先看一个常见场景：

公司想做 AI 客服，AI 能讲产品特点，也能找退换货政策，大家都很满意。

一上线，问题来了。

用户问：“滑雪板能不能加钱发顺丰，明天到新疆”AI 会算运费，却不知道滑雪板属于超长件；补上规则，又发现时效根本做不到。规则越补越多，回答也越长，用户还是不知道到底能不能买。商品、活动和售后政策又一直在变。谁更新资料，谁处理错答，项目开始时都没说清楚。

太麻烦了，大家又回到了原来的工作方式。

客户并不需要一个“万能 AI 客服”，FDE 才是来处理真正业务的人，在真实环境里，对一个可衡量的业务结果端到端负责。一个完整过程如下：

• 需求识别：FDE一开始需要去看一线员工平时怎样拿信息、完成任务、和同事协作，以及遇到例外时到底怎么处理。
• 跨层沟通，让管理层、业务负责人和一线员工达成一致；管理层投入资源，中层配合，一线员工也愿意交出真实流程和反馈，项目才有可能往下走。
• 工程与系统集成：问题弄清楚以后，才进入处理数据、接入工具、编排 Agent、完成部署，再把它连接到企业原有的系统里。交付的是能稳定运行、能经得起多人使用、出现问题也能追溯的生产级能力。
• 评估与验证：项目开始前就要说清目标、测试任务、验证样本和验收标准，避免系统做完才发现双方理解完全不同。
• 沉淀下来：哪些规则可以写成模板，哪些能力可以做成 Skill，哪些问题应该反馈给产品团队，这样才不会随着项目结束而归零，下一次面对相似客户时，团队能更快、更稳地开始。

二、FDE的具体分类：商务型 ，产品型，工程型

FDE 可以拆为三个可以协作、也会互相重叠的方向：

• 商务型 FDE ：更靠近客户和商业现场，负责寻找项目机会、识别真正能拍板的人、推动客户作出决策并维护合作关系，通常需要懂业务、懂组织，也能建立信任，因此销售、售前和客户成功背景的人更容易从这条路径切入。
• 产品型 FDE ：更靠近问题和方案本身，负责把客户模糊的表达拆成清楚的需求，确定这次做什么、不做什么，设计方案、制作 Demo，并一路推动项目往前走，产品经理、解决方案、项目经理和设计背景的人通常在这一侧更有优势。
• 工程型 FDE ：更靠近系统交付，负责把方案真正做出来，包括处理模型和数据、连接企业系统、完成测试部署，并保证上线后能稳定运行，研发、算法、测试和实施背景的人通常更适合从这里开始。

对于复杂项目，较稳妥的最小组织仍然是商务、产品、工程组成的“铁三角”。

Palantir 这家公司做 FDE 团队时的分工方式也可以参考——

• Echo 更靠近客户和业务现场，负责听懂客户、发现真正的问题，并把模糊的需求翻译成团队能执行的方案。他需要和客户建立信任，了解行业规则，确定这次项目先做什么、做到什么程度，以及最后由谁验收。
• Delta 更靠近工程和交付现场，负责把已经想清楚的方案做成能实际运行的产品。他会快速做出原型，再接入数据和系统、处理测试和错误，最后保证工具能上线、能使用、出了问题也知道怎么处理。
• Solo FDE 同时承担 Echo 和 Delta 的核心工作：既听得懂业务，也能把业务变成系统，并对最后结果负责。

三、第一个项目怎么开始

不要一开始就选择大型客户，量力而行，从熟悉行业里的中小企业切入

• 先从自己熟悉的人和行业开始，比如亲友企业、原来的工作领域、垂直社群或已有客户关系，这样能减少建立信任和理解业务的成本。
• 不要一上来就想改造整家公司，先找一个具体的人、一项明确的任务和一条能从头看到尾的流程，最好连输入和输出都说得清楚。
• 选好以后，先亲自按原来的方式做一遍，看看资料从哪里来、员工中间怎样判断、最容易在哪一步出错，再决定哪些环节适合交给 AI。
• 同时收集几条真实任务、常见样本和容易出问题的边界情况，提前约定什么叫“可用”、什么叫“失败”，别等工具做完才发现双方期待不同。
• 第一个项目也别追求全自动，优先从资料整理、客户跟单、初步分析这类即使出错也能人工复核的环节开始，先做出结果，再慢慢建立信任。
• 找客户关键不是到处推销 AI，而是让真正相关的人看到，你理解过类似问题，也有办法把它解决。

四、SOW、Spec、Demo、MVP：容易忽略的细节

先解释几个专有名词：

• SOW：双方的项目约定。就是先写清楚“这次到底做什么、谁负责什么、怎样算完成、客户临时加需求怎么办”。它主要给客户和项目负责人看。
• Spec：开发说明书。SOW 说“做什么”，Spec 说“具体怎么做”，例如页面怎么设计、数据从哪里来、AI 处理哪些步骤、测试哪些情况。它主要给开发团队看。
• Demo：演示样品。先做一个能跑的小版本，证明方向没错。它不一定能长期给员工使用，重点是让客户看懂：“你理解的是不是这件事”。
• MVP：最小可用版本。比 Demo 更进一步，已经可以交给少量真实用户使用，完整跑完一条工作流程；功能不多，但真的能帮人做完一件事。

FDE 做项目，不是客户说一句，团队就马上开始开发。下面是注意事项：

• 什么项目不要接：如果客户始终不愿意让你接触真实流程、业务人员、数据样本或验收负责人。大概率还不是一个正式项目，可能只是市场调研、供应商比稿，或者某个人想拿 AI 做一份内部汇报。别急着接。
• 让客户信任你才是核心步骤：让客户相信你能做成，先拿同行案例、可展示结果或行业经验换来一次深入沟通，而不是一上来就索要完整预算、数据和系统权限。

大客户可能更看重你做过哪些复杂项目；中小企业更关心同行有没有跑通；已经有明确痛点的客户，往往更愿意看一份针对性的方案或小 Demo。

• 进入现场看真正的问题：不能只听客户说的，而要自己去观察与判断：谁发起谁预算谁验收；要去看一线员工实际怎样获取信息、完成任务、处理例外，以及这个问题过去为什么一直没有解决。
• 必须确认好验收标准，否则会踩坑：项目开始前要用 SOW，也就是项目工作说明书，把目标、范围、交付物、双方责任、数据条件、里程碑、测试方式、验收标准、需求变更和付款节点写清楚。
• 翻译成开发任务：SOW 说清商业边界以后，才进入 Spec。页面长什么样，数据从哪里来，模型怎样调用，哪些资料能用，测试哪些场景，什么时候上线，都要在这里拆清楚。这样工程师和 Coding Agent 才不会靠猜来开发。
• 先做最短 Demo 对齐方向：只选择一条最核心的流程，用真实样本跑通输入、处理和输出，先证明它对老板有价值、对业务能使用、对 IT 能接入，再逐步进入真实用户试用和正式生产。
• 正式交付：系统接进真实工作，员工知道怎么用，出错谁处理，涉及审批、付款、删除和对外发布时要有人确认。客户私密信息需要脱敏、私有环境或客户允许的沙箱。
• 交付后留下能力：系统真正上线后，还要处理稳定性、权限、异常和人工确认，并把现场规则、失败案例、测试方法、工具连接和流程模板沉淀下来，让下一个类似项目不必从零开始。

五、Skill、CLI、Subagent 和 Hook：内容沉淀和复用

先解释专有名称：

• Skill 可以理解成 AI 的“岗位说明书和工作手册”。它告诉 AI 遇到什么任务该怎么做：先看哪些资料、按什么步骤判断、哪些规则不能碰、什么情况必须找人，以及最后交出什么结果。
• CLI 可以打开门。有了它，AI 才能打开企业系统的门，去查 CRM、读订单、看库存，或者把跟进记录写回去。
• Subagent 是项目里的“分工小组”。复杂任务不必让同一个 AI 从头忙到尾，可以让一个负责查资料，一个负责判断，另一个负责检查结果；每个人只管自己那一段，出错时也更容易知道卡在哪里。
• Hook 则像流程里的“自动开关”或“报警器”。任务完成后自动通知销售，发现高风险客户自动提醒人工确认，系统报错时自动记录并通知负责人，让流程不用一直靠人盯着。

前面说，FDE 不只是做完一个项目，还要把项目里的经验留下来。

留下来最常见的就是 Skill，可以理解成给 AI 的一份“岗位 SOP”。举例：

比如经验丰富的客服知道：用户问物流，先查订单和地区；涉及退款，不能直接承诺；资料不完整，先追问；回复太长，用户看不懂，先给明确结论。

整理成Skill（业务规则 + 工作步骤 + 工具入口 + 检查标准）：遇到什么问题，拿什么资料，按什么步骤判断，哪些分别直接做和找人，最后输出。

那些高频、重复、经常要查资料、很依赖熟练员工经验，而且结果能被检查的任务，最适合先做。比如客服查物流、销售筛选线索、财务核对报销、运营检查异常数据。反过来，如果每次任务都完全不同，连什么算做好都说不清，就不该急着包装成 Skill。

同时，Skill需要CLI、Subagent 和 Hook的配合。串起来，就是：

Skill 告诉 AI 怎样判断线索→ CLI 帮它查询 CRM 和客户资料→ Subagent 分别处理查资料、判断和检查→ Hook 在完成、失败或高风险时自动通知相关人

这几部分组合起来，AI 才不只是“会聊天”，它开始能做事。

Skill 的价值也不在于第一版，而在于越用越好。每次出现新错误、客户补充新规则、员工发现新的例外，都可以变成新的测试案例，再用来更新 Skill。

当多个客户反复遇到相似问题，团队把其中共通的规则、工具和测试案例整理成 Skill、CLI 和工作流，碎石路才会慢慢变成柏油路。

六、API、MCP、CLI 和 UI 自动化：企业系统到底怎么接？

结论是：API 是系统本身的接口，MCP 和 CLI 是 Agent 调用这些能力的不同方式，UI 自动化则是在没有接口时的备用方案。

→ 有稳定 API，先用 API→ 需要给 Agent 标准化工具菜单，用 MCP→ 本地执行、批量处理或组合多个能力，用 CLI→ 什么接口都没有，再用 UI 自动化兜底

Agent 想成一个刚入职、需要和公司各部门协作的新员工。

• API 是各个系统给他的“直连办事窗口”。比如查订单、看库存、写客户记录，，直接按规定提交请求，系统就把结果返回给他。
• MCP 是公司的“通讯录加办事指南”。它告诉 Agent：公司里有哪些工具可以用，查客户该找谁，创建工单该怎么做，每个工具需要填什么信息。
• CLI 是 Agent 手里的“命令终端”。它知道要做什么以后，可以输入一条明确指令，比如“读取这个客户的跟进记录”，系统就返回结构化结果。
• UI 自动化 则是没有直连窗口、没有办事指南、也没有命令终端时，只能让 Agent 像人一样盯着电脑屏幕，找按钮、点鼠标、填表格。页面一变就容易出错，所以通常放在最后才用。

API：系统本来就有稳定接口时用

如果 CRM、订单系统或库存系统本身提供 API，优先用 API。它最适合系统和系统之间稳定、大量的数据读写。

但 API 比较偏底层，身份认证、错误处理、调用顺序和权限控制，通常要由开发团队自己处理。

MCP：希望 Agent 能标准化发现和调用工具时用

MCP 可以理解成给 Agent 的“工具菜单”。它适合把一组工具和数据资源标准化地交给 Agent。

但工具也不是越多越好。菜单太长，Agent 反而可能选错工具、浪费上下文，所以真正上线时要尽量让它只看到当前任务需要的能力。

CLI：本地开发、批处理和多工具组合时用

CLI 就是命令行工具。它更像 Agent 手里的“操作面板”。比如：

text查询待处理报销单→ 查看单据详情→ 生成审核建议→ 人工确认后提交审批

Agent 不需要理解网页长什么样，只要按命令调用，就能得到结构化结果，也能明确知道操作成功还是失败。

适合本地 Agent、开发运维、批处理，以及把多个工具串成一条工作流。它背后通常仍然调用 API，只是把复杂接口包装成更容易发现、组合和测试的命令。

UI 自动化：没有接口、不能二开时才用

有些老系统既没有 API，也没有开放工具，只能通过网页或桌面软件操作。

这时才考虑 UI 自动化，也就是让 Agent 看屏幕、找按钮、点击和输入。

它能救急，但不应该成为默认方案。

七、传统测试不适合agent：EDD循环六步走

先解释几个专有名词：

• MVP 契约：给第一版 Agent 划出的工作边界。先说清它帮谁做什么、做到什么算完成、什么不能做、能用哪些资料，以及什么情况必须转人工。
• EDD：Evaluation-Driven Development 评测驱动开发。不是做完再测试，而是“先做一点 → 用真实案例测试 → 找问题 → 修改 → 再测试”的循环。
• 评测集：专门用来检验 Agent 的一批真实问题。里面不只放正常问题，也要有信息不全、规则冲突、边界情况和历史失败案例。
• 回归测试：修完一个问题后，把以前通过的题目再跑一遍，确认新修改没有把旧能力弄坏。
• LLM Judge：让另一个模型按照评分标准，帮助判断回答是否相关、完整、清楚。它适合初步筛选；涉及付款、合规、隐私等高风险判断，仍要人工确认。
• 运行轨迹：Agent 完成任务的全过程记录，包括它查了什么资料、调用了哪些工具、做过哪些判断、在哪一步失败。只看最终答案，往往找不到真正的问题。

传统测试不适合agent——你问同一个问题，它这次可能答得很好，下次却因为资料、上下文或模型波动，走了另一条路径。

特征带来的问题	评测上的要求
黑盒：无法像确定性程序一样形式化证明内部推理完全正确	通过真实输入输出和运行轨迹做经验测量
随机性：同一输入多次运行可能得到不同答案和路径	重复采样，用成功率、分布和置信区间表达结果
耦合性：修改一个 Prompt、Skill 或知识片段，可能影响其他任务	局部评测之后仍要跑整体回归
隐性标准：客户往往说不清什么是好，但看到结果后能指出不满意	尽快提供可讨论的 MVP，在反馈中形成标准
分布漂移：模型、用户行为、知识与产品定位持续变化	评测集需要更新、重加权和退役机制

所以Agent 的测试不是最后补的一道工序，而是一轮一轮往前推的过程。这个过程叫 EDD，也就是 Evaluation-Driven Development，评测驱动开发。

具体怎么做，可以拆成六步。

第一步，先写 MVP 契约。

这个 Agent 是替谁完成哪一件事，什么叫完成，哪些事情绝对不能做，它能查什么资料、调用什么工具，遇到哪些情况必须转人工。

这份 MVP 契约，就是后面所有测试的依据。

第二步，准备真实测试题。

不要只拿几条准备好的问题，让 AI 在演示里答对。真实的测试题要包括正常问题，也要包括信息不完整、规则冲突、边界情况和历史失败案例。

不要只拿最理想的问题测试，还要放进四类情况：

• 信息完整、可以直接回答的问题；
• 信息不够、必须先澄清的问题；
• 只能回答一部分、需要说明边界的问题；
• 以及超出规则、应该拒答或转人工的问题。

第三步，先定好谁来评分。

“回答有没有说到重点”“用户看不看得懂”“语气是否合适”这类问题，代码很难判断。这时可以用 LLM Judge，也就是让另一个更强的模型，按提前写好的标准，先帮你筛出回答不相关、不完整或不清楚的案例。

不过 LLM Judge 不是最终裁判。涉及付款、合同、合规和客户隐私这些高风险问题，最后仍然要由业务人员确认。

第四步，先跑一遍，看第一版到底错在哪。

不要一看到问题就急着改。先跑一遍测试题，记录它在哪些问题上失败，是没找到资料、理解错了用户、调用错了工具，还是本来就没有权限做这件事。只有知道问题出在哪一层，才不会拿改 Prompt 的方式，去修一个其实是系统接口的问题。

第五步，优先修改最重要的问题。

不是每一个错误都要立刻修。先看它出现得多不多、影响大不大、会不会造成退款、投诉、越权或人工大量返工，再决定先改哪一个。

修改的对象可能是 Prompt、Skill、知识库、工具接口，也可能是流程本身。

第六步，修完以后，把新旧题目全部再跑一遍。

比如 AI 客服原来不会处理“滑雪板能不能明天送到新疆”，团队补上超长件和物流时效规则以后，不能只重测这一题，还要重新问普通商品怎么发货、退货怎么处理。因为新问题好了，旧问题也可能被改坏。修好一个新问题，旧问题不能回来。这一步叫回归测试。

这六步不断循环，Agent 才会慢慢变成“能稳定完成一段工作”。

八、辨别真假岗位，简历、作品集与面试

8.1 识别岗位

怎么判断一份工作是不是真 FDE？

国内这个岗位还没有统一叫法。除了 FDE，你还会看到“解决方案架构师”“AI 应用工程师”“Agent 产品方案工程师”“交付工程师”等名称。

别只看 Title。可以用五个问题去问招聘方。能进现场，能做工程，能纠偏，还要对结果负责，才更像真正的 FDE。

• 第一，薪资是不是主要靠签单提成？如果是，这份工作更像销售或售前；FDE 可以参与拿下项目，但不该只负责把项目卖出去。
• 第二，工程实现占多少？如果几乎不写代码、不接系统、不做测试和评测，通常很难真正负责交付。
• 第三，项目结束后，现场经验会留下什么？客户提出的规则、失败案例和解决方案，能不能变成公司的组件、方法或产品能力。如果什么都留不下，下一个客户还要从零开始，它更像一次性驻场。
• 第四，你是在签约前演示，还是签约后还要继续负责？只在前期讲方案、做 Demo，偏售前；签约后还要把系统做出来、验收、上线、处理运行问题，才更接近 FDE。
• 第五，发现客户一开始提错了需求，你有没有权力说“不”？真正的 FDE 不是照着清单执行的人。他要能指出错误目标，缩小范围，帮助客户在“想要的东西”和“真正该做的事情”之间作取舍。

8.2 简历

一份 FDE 简历至少要发出四个信号。

第一，你有没有负责到底。不是接到一份明确需求就开始开发，而是从问题还很模糊时参与进来，一直做到上线、验收，或者明确知道为什么项目该停下来。

第二，你有没有直接面对业务。你是否访谈过客户或业务人员，澄清过需求，处理过预期不一致，推动过对方做决定。FDE 不只是和代码打交道。

第三，你的东西有没有进入真实环境。能演示不算。要写清楚它有没有被真实用户使用，权限怎么处理，出错怎么办，哪些地方需要人工兜底。

第四，结果能不能说清楚。不一定非要写收入，也可以写测试通过率、覆盖场景数、任务耗时、人工介入比例或失败类型。重点是让人看见：你做完以后，什么发生了变化。

所以，项目经历尽量按这个方式写：

有责任感的动词 + 你构建的东西 + 业务场景 + 可验证结果

协助客户搭建数据管道。改成——“为零售场景负责数据管道部署，整合多个分散数据源，并将业务分析的准备周期从数周压缩到数天”

• 你能在哪类业务场景里承担什么角色；
• 核心技能只写经得起追问的；
• 把项目经历放在更靠前的位置，按“业务背景—需求边界—方案—结果—复用资产”展开；
• 工作经历则突出你和客户、业务、生产系统发生过什么关系。
• 不要把调用几个工具包装成工程能力。写了 Agent、RAG 或 MCP，就要能解释它为什么这样设计、数据从哪里来、失败时怎么处理、怎样证明可用。

8.3作品集

关于FDE 作品集，招聘方真正想看的是：客户一开始的问题有多模糊，你怎么把它收下来，过程中遇到什么限制，最后有没有做出一个能被验证的结果。

所以，选一个你最完整的项目就够了。把它写成一段交付故事。

• 先讲业务背景：谁遇到了什么问题，为什么这件事值得做。
• 接着写需求边界：这次解决什么、不解决什么，哪些地方有风险，哪些前提还没有被验证。
• 然后讲方案和取舍。为什么选这个技术路线，为什么这一步交给 AI、那一步保留给人，为什么第一版只做这一条流程，而不是试图改造整家公司。
• 再往下，写交付过程：原型怎么做，数据和系统怎么接，测试怎么设计，真实用户怎么反馈。
• 最后给出结果，不一定非要写收入，也可以写测试通过率、覆盖场景数、任务耗时、人工介入比例，或者哪些高风险情况被成功拦截。

同一个项目，最好整理成三种版本。

• 一篇项目长文，用来讲完整过程、你的判断和复盘；
• 一个 GitHub README，用来给技术面试官看架构、运行方式、评测和已知限制；
• 再做一页 PDF，用于投递时快速说明背景、职责、方案、结果和链接。

还有一条：客户名称改成“华东某制造企业”“某电商团队”；金额、账号、订单、聊天记录用模拟数据替代；截图遮住姓名、联系方式、内部域名和敏感字段。作品集展示的是你的能力，不是客户的商业秘密。

如果你还没有企业客户——

亲友的小店、同事的重复工作、社群运营，甚至你自己的工作流。只要这件事真的有人在用，你记录过反馈，修过问题，做过第二轮迭代，它就比一个只为展示而做的 Demo 更像 FDE 作品集。

8.4面试

FDE 面试可能给你一句模糊的话：“这里有 8000 条出租车运营记录，一周内做一个方案。”题目没说给谁用，也没说要解决定价、调度还是欺诈检测。

你应该先问：

谁是用户？他们现在最痛的问题是什么？一周内最值得验证哪项价值？哪些事情这次可以不做？成功标准是什么？数据能不能拿到？最后谁来验收？

这就是 Scoping，也就是先把模糊的大问题，收缩成一个能在有限时间里验证的小闭环。

FDE 面试官主要想看：

• 你会不会先澄清，再动手，而不是把假设当成事实
• 能不能把一个大问题切成几个可以独立验证的部分
• 会不会主动想到脏数据、老系统、权限不足、外部接口失败和人工兜底
• 能不能把自己的假设说出来，让别人知道你的方案依赖什么条件。
• 看你有没有取舍能力。一周做不完，你先做什么，为什么不做其他内容
• 沟通压力变大时，你能不能持续讲清楚思路，听到新信息后会不会调整
• 最后你有没有一直想着真正使用这个系统的人，而不是只想着技术方案够不够漂亮。

日常准备——

每周找一个模糊需求，练习在两分钟内讲清用户、目标、边界、风险和成功指标；找一个陌生项目，先猜它怎么运行，再通过代码和实际结果验证；看到一个新工具或新协议，试着十分钟后用自己的话讲给别人听。

行为面也要提前准备几段真实故事：

你什么时候主动扛过责任，遇到失败怎么处理，做过什么困难取舍，怎么说服过客户或团队。每段控制在两分钟左右，讲清背景、你的任务、你做了什么，最后结果怎样。

最后

把观猹这套内容看完，我对 FDE 的理解变了。其实每一步都不轻松。

要能判断什么项目值得做，什么需求只是客户一句“我们也想要 AI”；要知道哪些能力该沉淀成 Skill，哪些操作必须交给人确认；也要接受一件事：Demo 做出来只是开始，能稳定交付、能不断迭代，才是更难的部分。

所以，FDE 不是一个靠背术语就能进入的岗位。

它不躲在需求文档后面，也不止步于演示页面；进入真实现场，理解真实限制，对最后的结果负责。

FDE 最终交付的也不是一个 Agent，是一段已经跑起来、有人愿意持续使用的业务流程。

原文信息

• 作者@@AmberTreelet
• 原文链接x.com/AmberTreelet/status/2088890051862430040

不急着付费，先看交付结果

每天信息太多？我们先帮你筛选，再说清楚怎么用。

会员不是“再多看一些文章”，而是按你关注的任务，把值得看的 AI 动态整理成可执行的下一步。

真实简报样例 · 2026-10-01

Agent 会话历史别浪费：把 Claude Code 和 Codex 的历史变成本地知识库

为什么选它：属于你关注的“知识管理”任务。

可以怎么用：把一次性 Agent 对话整理成下次任务能直接复用的项目记忆。

样例取自 2026-10-01 生产简报，实际推送会按你的身份、主题和信源筛选。

看完整样例与权益 →先免费使用免费版长期可用 · 不绑定支付方式 · 会员 99 元/年，7 天可退 查看作者：[@AmberTreelet] AI服务 联系我们 客户案例 上一篇 AI 数字人网球教练带完一节 15 分钟网球课，开源可灵3.0数字人、真人动作复现、课程编排和语音指导全流程 目录 AI 新手入门 下一篇 Grok Bot 这次产品发布，失败了