一套AI应用做出第一版，可能已经越来越快了。真正耗时间的，常常是后面那些看起来并不大的事。
FDE也正是在这样的项目现场里越来越常见。
工程师被拉到客户一线，一边确认需求，一边验证模型和系统到底能不能跑起来，还要处理产品、数据、业务流程和后续迭代。一个项目做完之后，客户能不能自己接着用，这套经验能不能带到下一个项目，也开始变成新的问题。
9月12日，PEC 2026 AI创新者大会暨第三届提示工程峰会在北京众智园举行。大会以“Won Token，Won World（赢得Token，赢得世界）”为核心理念，由PEC联盟、至顶科技、软积木、海升集团共同主办，AIGCLink、LangGPT社区、爱智岛（AI·DAO）人工智能创作联盟、硅创联、AI原点社区、海升睿达等联合主办。
当天下午的“FDE实战营”分论坛，把这条交付链上的问题摊开讲了一遍。从医疗Agent的效果，到智算中心每百万Token的成本；从一个产品最后1%的落地，到甲方能不能接手系统；再到需求不断增加以后，乙方的人力该怎么投入。
总结下来就三件事：项目有没有效果，这笔账划不划算，以及做完一个客户之后还能留下多少东西。
Demo跑通之后，离业务可用还有多远
百川智能技术总监郭美青从医疗Agent讲起。
进入Agent阶段后，影响模型端到端效果的因素明显增加。郭美青把Harness定义为围绕Agent构建的运行环境，包括工具体系、权限边界、记忆机制、评估反馈和任务流程。它需要解决的，是如何让Agent的循环调用更加稳定、可控、安全，同时可以评估和交付。
医疗场景又把这些要求进一步放大。郭美青将医疗Agent面临的挑战归纳为“可信、可控、可用”。可信涉及答案有没有可靠依据，可控涉及高风险情况能不能被识别和干预，可用则要看产品能不能满足患者、医生在不同任务中的需求。
围绕这些目标，百川智能把工作分散到模型训练、医学专库、Agent引擎和应用等不同层次。到了Agent层，还要继续处理搜索、循证、深度问诊、Skill构建和记忆等问题。
Harness Engineering的目标要落在三个指标上：效果、性能和成本需要动态平衡。与此同时，模型和工程方法都可能继续变化，定义问题、定义“什么叫好”则始终重要。
到了客户现场，这些问题还会继续展开。
Google Cloud大中华区FDE团队负责人王书元（Joseph Wang）提到，不同公司对FDE有不同的答案。Google Cloud在实践中总结了“工程共创”的方式，让FDE提前进入一线，用代码验证实际场景中的可行性，同时了解成本、质量以及后续还缺少哪些能力。
当需求远大于团队能够承接的项目数量时，项目也需要筛选。在团队发展的早期阶段，会通过比较严格的准入机制，把资源集中到重要客户的核心项目以及模型能力边界仍需验证的场景，减少过度承诺。
以一家大型出海零售公司的智能搜索和对话式下单项目为例。项目启动前，需要判断客户投入意愿、业务和技术团队是否支持；进入需求诊断后，还要看真实数据、用户流程以及最终的成功指标。项目的最后一段距离同样考验工程能力。一个产品可能已经完成了99%，实际进入客户环境时，剩下的1%需要继续协调产品团队和用户，在工程上保证效果、数据安全和产品落地。
项目的最后一段距离同样考验工程能力。
王书元认为，一个产品可能已经完成了99%，实际进入客户环境时，却发现还差区域的测试。剩下的1%需要继续协调产品团队和客户，在工程上保证效果、数据安全和产品落地。
从Demo到生产系统，中间仍然有大量具体工作需要完成。
从GPU到需求变更，每一层都要算账
过去建设智算中心，人们经常谈规模、机柜、功率和万卡集群。随着推理逐渐形成长期、规模化的使用，董慧智提出，算力中心开始更像一座Token工厂，需要比较每天能够稳定交付多少有效Token、单位成本以及交付质量。
在这套生产逻辑里，GPU只是投入的一部分。
Token中心的经营结果还受到GPU使用率、输入与输出Token比例、缓存命中率等因素影响。同样的计算能力，用户的输入输出结构不同，最终收入也会发生变化。
推理引擎也直接影响产出。董慧智提到，在固定投入下，推理引擎需要尽可能提高Token产量，其研发优化可能带来额外5%到10%的收益。
中国人工智能学会智工委常委董慧做了一个概括：GPU是投入，推理引擎是生产工艺，有效Token才是产出。
AMD大中华区AI市场经理赵晨光则尝试用端侧设备部署AI来解决成本问题。他提出，并非所有任务都需要使用能力最强的大模型。例如日常辅助办公中的邮件总结、行动事项提取，可以使用相对轻量的小模型方案；主流的工作流编排任务规划和编程可以交给35B以上直至100B级别的中大参数模型，既能节约成本又能满足对数据隐私要求较高的场景。
而AMD锐龙AI Max智能体主机恰恰是可以实现这一目标的核心设备，凭借最高192G内存/160GB显存但体积小巧的设备，过去需要大型工作站服务器才能实现的超大模型部署如今可以轻松完成。
赵晨光分享了一个AMD智能体主机应用于投标场景的案例：过去需要三个人花7天准备材料，在其展示的方案中，可以压缩到一个人半天，整个过程几乎全部离线完成。
算力和模型是一部分成本，进入客户现场后，需求变化又会产生另一类投入。Clawith联合创始人覃睿分享了一个10万人规模央企集团的项目。
项目完成最初约定的SOW（工作说明书）以后，开放试用带来了大量优化意见，其中很多工作并没有写进最初的SOW，团队最终仍然做了，并且需要保持很快的更新频率。覃睿将这个案例称为带引号的“失败”，从控制服务范围的角度看，很多工作超出了最初约定；从客户成功的角度看，项目的结果又很好。
项目运行过程中，监控、测试、设计规范、后续推广和计量方式也逐渐被补进来。
覃睿在复盘这个案例时提到：这个时代的核心的成本不在开发成本，在沟通成本，在信任。
他的另一个观察是，乙方手里的工具变强以后，甲方的预期也在提高。需求发生变化并不可怕，更麻烦的情况是项目开始时连目标都没有想清楚，因为此时乙方很难判断到底需要投入多少资源。
企业应用可以划分为不同层级：相对简单的部门级应用可以让业务人员更多参与，平台层面需要治理，银行交易系统等核心业务仍然需要专业人员负责。开发效率提高以后，企业交付仍然要继续处理需求、治理、验收和信任这些问题。
一个项目做完，甲方能不能接手
接下来要关注的就是，交付完成之后的问题。在函子科技创始人蒋耀锴参与的FDE项目里，团队往往已经找到了业务场景中AI能够发挥高杠杆价值的部分，最后却容易陷入大量细小需求，比如增加一个字段、解释一个结果、调整一条业务规则。单个需求投入并不大，持续迭代却会让项目逐渐接近驻场外包。
这些需求又直接关系到终端用户是否愿意使用。
蒋耀锴提到，有些产品距离用户采用可能就差最后的5%，采用率如果很低，前面的项目投入也很难形成价值。随后每一次修改都可能成为一个新的“小型外包”，沟通增加，成本随之上升。
因此，他也把甲方能不能接手放到了交付标准里。
交付代码接手者需要具备阅读代码的能力，如果系统能够让业务人员理解，能够接手的人就会更多。他在分享中展示了可视化的工作流、数据库、Agent提示词、结构化输出和权限配置，希望业务人员可以看懂其中的数据和逻辑。
因此，FDE的价值应该更多放在帮助用户梳理业务与AI如何结合，减少长期陷入修改单个像素、增加单个字段这样的工作。他希望FDE能够从重复维护进入持续的价值交互，同时从项目中沉淀可以复用的方法和技术能力。
随着Agent深入企业工作流，OpenDesign CMO、增长负责人李锦威观察到，团队里的设计协作方式也在变化。设计师、产品经理以及原本不会设计的人，都开始更多参与这一流程。
他分享了几类实际用户。一些营销工作室和跨境电商团队过去需要外包大量设计工作，一个案例中原本可能需要10位设计师，现在通过两位设计师加文案完成原来的交付。还有一些没有设计背景的用户，也开始自己制作网站和线上线下物料。
面向FDE，李锦威表示，希望提供开源产品、设计资产、评测集和案例，帮助提升企业内部的设计交付效率。
苏州画宗人工智能科技有限公司创始人、CEO秦文山则从内容生产讲到了个人能力与组织能力之间的差别。
秦文山早期从个人创作开始，后来进入创业和企业经营。他总结，个人的创作能力，其实不等于公司的经营能力。一次做出好的作品之后，企业还需要考虑下一次、再下一次能不能继续稳定交付。
在他的实践里，把个人能力变成稳定产出的组织能力，会涉及工艺、技术、创作经验以及团队管理。为此他们把创作经验加入生产体系，并使用多智能体协同。在进一步的生产过程中，还把流程拆成27道标准工序，判断哪些工作可以由AI承担，哪些仍然需要人参与。
秦文山认为，单点生成能力已经逐渐成为基础能力，接下来还要解决多模型调度和多智能体协同，让内容生产在效率和成本上达到可持续的状态。
从个人创作到稳定交付，从甲方能否接手到项目经验能否留下，“FDE实战营”分论坛覆盖了企业AI交付链条的不同位置。
一个项目做完，下一次能不能少走一些弯路，可能比项目本身更值得关注。毕竟，驻场的人不可能无限增加。一次交付能留下多少方法、工具和经验，也决定了FDE这套模式最后能走多远。
