最近我在做一件很具体的事把公众号文章同步到多个平台。第一版我只盯着“发出去”结果头条后半段排版乱了草稿箱里多出几份没用的草稿浏览器也开得一团糟。把问题修完后我发现真正值钱的不是再点一次发布而是把标题检查、图片锚点、草稿清理和公开页复核写进发布 Skill。下一篇文章再来流程才不会从头重跑。这件小事让我重新理解了 FDE。交付要解决眼前的问题也要留下下次能直接用的东西。下面讲的“双循环”是我现在检查 FDE 项目是否健康的一套工作框架不是行业里唯一的定义。FDE 是 Forward Deployed Engineer 的缩写通常译为前线部署工程师。我的理解很朴素工程能力要进入真实业务流程边做边验证再把现场经验带回产品和平台。为什么还要讲“沉淀”项目按时上线当然重要。但我现在会多问一句这次发现的模式、临时脚本和判断方法下一个项目还能不能用如果答案总是否定的团队做得再忙也只是在重复交付。人积累了经验组织却没有接住。FDE 要处理的就是这段断层。FDE 不是一条线而是两条线▲ FDE 的两条线交付解决眼前问题沉淀形成复用资产我把它拆成两条线。内循环只看当前流程东西能不能跑业务方愿不愿意用原来的动作有没有真的变化。外循环看下一次现场出现的共性能不能变成模板、组件、工具或检查规则。两条线偏掉任何一边都会出问题。只顾当前交付团队会被一次性需求拖住只顾平台抽象又很容易做出前线不需要的东西。我的判断标准是先把具体问题跑通再从里面挑出值得复用的部分。第一条线先把眼前的问题解决掉FDE 到了前线先进入真实流程看业务到底怎么运转。一个流程里谁在填表谁在审批数据从哪里来为什么同一个信息要在三个系统里重复录入哪个节点看起来像审批实际只是转发哪个环节看起来慢真正的问题却是上游数据不准。这些东西不在产品手册里也很难靠一次会议问出来。看见以后先做一个能跑的小改进。粗糙一点没关系重要的是尽快回到真实流程里验证。很多方案在评审时都很顺上线后却没人用。通常不是页面不够漂亮而是它解决了文档里的问题没有接住现场动作。内循环大致是跟着流程走一遍做出原型放回环境里试再根据反馈改。上线和登录数只能说明系统存在用户在日常工作中愿意继续用原来的等待或重复动作减少了才说明这一轮有效。第二条线把解法变成下次能用的东西做当前项目时我会顺手问几个问题这是这家企业独有的麻烦还是同类流程都会遇到临时脚本能不能抽成工具配置能不能变成模板评估方法能不能留下来这些记录最好在项目过程中完成。等到项目结束再凭记忆复盘很多有用的小细节已经丢了。有价值的发现往往很小一个数据字段的映射方式、审批流程里的共性节点、临时写出来的校验脚本或者现场逼出来的一套评估方法。这些东西如果不及时记录很容易被当成“项目里的小细节”过去了。但如果它被捕捉下来被产品和平台团队接住就可能变成后续项目的基础能力。前线先把它出现在哪里、解决什么问题、为什么可能复用写清楚再和产品或平台团队判断是否值得标准化。值得就重构不值得就留在当前项目里。不是每个发现都要做成产品。前线做出来的东西可以粗糙但平台能力不能一直粗糙。更合适的分工是前线负责发现和验证平台团队负责重构。这样当前项目能跑下一个项目也不用完全从零开始。“闪光点”通常不是大东西▲ 真正值得沉淀的往往是现场里不起眼的小发现很多人一听“沉淀”会想到方法论、产品模块和行业方案。实际开始时它通常只是一个不起眼的小发现。比如两个客户都需要把旧系统里的客户数据同步到新流程里只是字段名不同。多个项目里都出现了类似的审批链路只是审批人和节点数量不同。不同客户都需要判断一段 AI 输出能不能进入下一步只是评估标准略有差异。多个场景都需要把人类操作日志转成系统可读的结构化记录。单个发现不一定值得投入。它在不同项目里反复出现才说明背后可能有共性。抽出来以后下一个项目改配置就能用团队才有余力处理新的问题。用这次文章同步理解这个机制这次同步文章工具返回“草稿创建成功”时技术动作其实已经完成了。可一打开公开页头条后半段排版乱了图片位置也需要重新核对草稿箱里还留下了重复项。如果任务停在“接口成功”下一篇还会再踩一遍。后来我把公开页复核、图片锚点、草稿归属和标签页清理写成硬规则才算把这次失败变成了下次能用的资产。这个例子很小但它正好说明外循环在做什么前线暴露问题流程吸收问题工具再变得可靠一点。沉淀率不是个人 KPI而是组织健康信号讨论 FDE 时人们很容易想用一个精确比例衡量“有多少现场解法应该变成平台能力”。但在没有统一口径和可靠来源时单独强调某个数字没有意义。我更愿意把“沉淀率”看成趋势信号不把它压成个人 KPI。前线首先要解决业务问题不能为了凑资产而沉淀。如果长期什么都留不下来团队大概率被一次性定制拖住了。每个项目重新理解、重新开发做得越多维护负担越重。但要求所有现场解法都进入平台也不现实。每个企业都有自己的历史包袱、组织习惯、审批偏好和系统限制。这些纯定制逻辑如果全部塞进平台最后会变成一个谁都不敢动的巨型怪物。真正要观察的是团队有没有持续从特殊情况里抽出共性后续同类项目有没有因此变快。刚开始复用资产少很正常项目结束后没人再整理才值得警惕。什么值得沉淀什么不值得▲ 通用模式、行业模板、纯定制需求需要分清楚不是所有前线发现都值得沉淀。下面是我自己在用的一个简单检查表。第一类通用模式。比如数据集成方式、认证流程、权限模型、日志审计、评估框架。这类东西跨客户、跨项目都会出现。一旦沉淀后续项目直接受益优先级最高。第二类行业模板。比如某个行业典型的审批流程、合规要求、数据结构、业务动作。这类东西不是所有企业都需要但同一个行业里会反复出现。它值得沉淀但不能照搬某一家客户的做法要抽象出行业共性。第三类纯定制需求。比如某个客户内部独有的审批习惯某个历史系统留下来的特殊字段某个管理者个人偏好的报表格式。这类东西可以做但不应该进平台留在定制层就够了。最后我只问一句它会不会让下一个项目更快、更稳如果答案含糊就先别急着平台化。外循环断了FDE 就变成外包▲ 项目孤岛只会重复搬砖平台资产才会让组织变聪明同样是进现场、写代码、接系统差异最后会落到一件事上项目结束后组织有没有多出一块能复用的能力。如果答案是有下一个项目会带着组件、模板和判断方法继续走。如果答案是没有团队只能继续依赖几个能救火的人。人一走经验也跟着走。这也是 AI 时代的关键变化▲ AI 项目的不确定性需要被转化成可复用资产AI 项目把这个问题放大了因为很多判断要在真实使用中才看得出来。传统软件交付里很多需求是相对确定的。流程怎么配、字段怎么填、权限怎么设虽然麻烦但大体可预期。AI 项目不一样。它经常需要在真实业务里试出来。哪些环节适合自动化哪些判断必须保留人工AI 输出怎么评估用户什么时候信任它什么情况下必须加护栏这些问题很难在会议室里一次性想清楚。必须进入前线快速试快速改。如果提示词、流程、评估、权限和异常处理每次都重新摸索成本会很高。我的土办法是同类问题第二次出现先记下来第三次还出现再认真判断是否做成公共能力。这不是行业公式只是防止自己一直靠记忆救火。写在最后我现在判断一个 FDE 项目不只看它有没有上线还看它有没有留下东西。当前流程跑通是第一步下一次不用从零开始才说明这次交付真的被组织接住了。本文来自「维天说」全平台同名。 我会持续分享普通人能用上的 AI 工具、内容工作流和真实实践欢迎联系我一起交流 AI。