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