QUOTE
做 FDE 久了会发现：明线是把 AI 装进流程，暗线是把组织里“大家都懂、但没人说得清”的判断掏出来。
加入 FDE 之前，我也把这份工作理解得非常朴素。
我以为它只是更懂业务 的技术支持：比售前多写一点代码，比交付多理解一点产品，再帮客户把模型接进系统。真正开始做之后，我发现这份工作大致由四个“三分之一”组成：写代码、翻译业务、追问标准，以及在会议结束前确认“刚才说的效果不错，到底怎样才算不错”。数学上不太严谨，现场感倒很准确。
一句“我们想做个 AI 助手”只有十来个字，却足够长出几十页需求。最难的不是把字写满，而是把这句话追问成一个边界清楚、可以运行、能够验收，而且出了问题知道由谁处理的生产任务。
过去一年多，我反复经历同一种落差：一个在演示里很惊艳的能力，进入真实组织后，可能因为数据口径不一致而失效；可能因为专家不认可证据而被搁置；也可能技术上已经上线，却没有人愿意改变原来的工作方式。模型已经到了工位，流程还没给它办入职。
模型决定了能力上限，但一个场景能否产生价值，常常由 模型之外的事情 决定：问题有没有被定义准确，证据能不能追溯，流程是否允许 AI 参与，人工在哪些节点必须接管，以及结果能否被持续评测。
后来我才看清，每个 FDE 项目其实都同时跑着两条线。明线是接数据、做 Agent、嵌系统、交付上线；暗线是统一语言、追问规则、划清责任、处理那些没人愿意写进需求文档的例外。
VISIBLE LINE ／ HIDDEN LINE
明线 ／ VISIBLE
把一个系统做出来
接数据、做 Agent、嵌流程、交付上线，让能力在真实任务中跑起来。
暗线 ／ HIDDEN
把一套判断机制掏出来
统一语言、显性化专家规则、划清人工边界，并为错误设计责任和反馈。
明线决定项目能否上线，暗线决定它能否留下来。
这也是我现在理解的 FDE：它不是一种岗位名称，也不是“哪里需要就去哪里改两行”的人形补丁，而是一套 把不确定需求推进到确定结果 的工程方法。
本文看点
01
明线：系统如何真正上线
02
暗线：判断与责任如何工程化
03
几个现场怎样留下组织能力
01
FIELD NOTES
“万能助手”通常是需求还没问完
刚开始做场景时，我最容易问的问题是：“这个模型现在能做到什么？”这个问题通常很好回答，答案也往往多得让会议显得非常成功。
后来我发现，这个问题会天然把团队 带向功能展示。模型能总结，就做报告生成；能抽取，就做知识库；能推理，就做智能问答。按这条路线，一个“万能助手”通常半场会就能出生，至于它上班后具体负责什么，可以留给下一场会。
功能都说得通，但它们未必对应组织里 真正昂贵的决策节点。
现场更应该先问的是：哪一个决定正在反复消耗高价值人员的时间，又因为证据不完整、标准不一致或协作链条太长而频繁返工？
我通常会把一个模糊需 求连续追问成五个问题：谁要做决定；他在什么时点做；做决定前必须看到什么证据；判断错误的代价是什么；最终由谁签字或承担后果。
这五个问题答不清楚，所谓“场景”往往只是一组功能的临时拼接。名字里虽然有“智能”，本质上只是给问题起了一个 很像产品的名字。
例如，“做一个专利问答助手”不是完整的场景。它没有说明问题发生在哪个流程，也没有说明答案将改变什么动作。换成“在研发立项前，帮助项目经理发现与技术路线冲突的在先专利，并由知识产权专家确认风险等级”，场景才第一次拥有了 业务边界。
前者的验收标准容易变成“回答看起来不错”——这是工程世界里 最温柔、也最危险的一句话；后者则可以检查 证据覆盖、风险召回、专家复核一致性，以及它是否真的进入了立项流程。
「一个场景真正的起点，不是 AI 能做什么，而是组织正在为什么样的判断付出代价。」
这也是为什么 FDE 的早期工作经常看起来不像开发。我们要参加业务访谈，要画现有流程，要观察专家如何判断，要追踪一份报告从产生到被采用经历了哪些人。只有把这些隐形环节摊开，技术设计才不会从一开始就偏离问题。
02
PRODUCTION
系统能演示，不等于它能“过日子”
做过一些 PoC 后，我越来越少用“效果很好”来描述一个场景。PoC 有点像相亲照：样本挑过、光线很好、双方都很有耐心。生产系统则更接近长期共同生活，坏输入、权限过期、专家意见相左，一个都不会缺席。
我现在会检查四条链：证据链、执行链、流程链、责任链。
FDE PRODUCTION MODEL
01
证据链
来源、版本、权限、时效与引用回溯
02
执行链
任务拆解、工具调用、异常降级与人工接管
03
流程链
触发入口、上下游系统、状态回写与后续动作
04
责任链
验收标准、签字权限、错误追溯与持续维护
证据链解决“系统凭什么得出这个结 论”。数据从哪里来，版本是否明确，权限是否合规，引用能否回到原文，过期信息如何被发现。越是专利、研发和战略场景，越不能把流畅表达当成可靠证据。
执行链解决“复杂任务如何被稳定完成”。一个 Agent 需要怎样拆解任务，调用哪些 Skill 或工具，遇到缺失数据如何降级，什么时候停止推理，什么时候把问题交还给人。可控的失败 往往比偶尔惊艳的成功更重要。
流程链解决“结果在组织里往哪里去”。谁触发任务，输入来自哪个系统，结果进入评审、立项还是法务流程，状态如何回写，后续动作由谁继续。没有 流程接口，AI 产出最终只是另一个需要人工搬运的文件。
责任链解决“谁对结果负责”。哪些结论允许自动执行，哪些必须专家复核；验收集由谁维护；出现错误怎样追溯；规则变化后谁更新。责任链缺失时，系统越智能，组织反而越不敢使用。
PoC 和生产系统的差别，就藏在这四条链里。PoC 只需要证明某次输入可以得到一个好结果；生产系统还必须在现实偶尔“不讲武德”时，处理坏输入、边界案例、权限变化、专家分歧和 持续反馈。
「演示关注的是一次答案 有多聪明，生产关注的是一条链路在异常条件下是否仍然可信。」
这四条链也改变了我的工作方式。过去我会先做原型，再找业务验证；现在我更倾向于先建立一个 最小评测集，把正确、错误、模糊和必须拒答的样本放进去，再决定系统该怎样设计。评测不是上线前的考试，而是 需求定义本身。
沿着这套方法往下看，几个高摩擦现场虽然对象不同，真正需要工程化的都是“证据如何进入决策、机器在哪里停下、人怎样接管，以及结果如何被衡量”。
HIGH-FRICTION DECISIONS
RIGHTS
权利边界
决策对象
保护与风险判断
核心难点
标准隐性且错误代价不对称
人工关口
专家签字
结果指标
返工、一致性与风险召回
ROUTE
路线判断
决策对象
技术与资源取舍
核心难点
信息充足但决策边界模糊
人工关口
决策负责人
结果指标
证据回溯与行动转化
ITERATION
工程试错
决策对象
方案与试验选择
核心难点
无效迭代发现得太晚
人工关口
工程师评审
结果指标
迭代、复用与早期排险
ASSET
资产动作
决策对象
存量资源下一步
核心难点
评分脱离产品和交易条件
人工关口
法律与业务共同判断
结果指标
处置、匹配与线索推进
03
JUDGMENT
写得通顺，和判断正确，是两回事
先说一类很容易被低估 的现场。它表面上围绕文本展开：技术交底、查新报告、申请文件、审查意见答复、FTO 分析。大模型擅长理解和生成文本，因此很多人会自然地认为，只要模型足够强，质量提升就会发生。毕竟，写出一段通顺文字已经不难；问题是，权利范围也可能被通顺地写没。
我最初也这样想。后来进入具体流程才意识到，专利质量问题本质上不是文本生成问题，而是组织判断标准没有被工程化。
明线是让交底、检索、审核和答复更快；暗线是把“什么叫好专利、什么风险不能放过、谁有权做最后取舍”从专家脑中搬进可检查的规则。
同一份技术交底，研发人员关心方案有没有被准确表达，代理师关心权利要求能否成立，企业知识产权负责人还要考虑保护范围、竞争位置和未来维权。三类角色都在说“质量”，实际使用的判断函数并不相同。
更麻烦的是，这些标准大量存在于专 家经验里。专家三句话就能指出“这段写得太虚”“保护范围不够”“这篇在先文献很危险”，FDE 往往需要再追问半小时，才能把那个“我一看就知道”拆成可实现的条件组合：必要技术特征是否完整，术语是否获得说明书支持，替代方案是否被覆盖，文献公开时间是否有效，权利要求解释是否存在收缩风险。
FDE 在这里要做的第一件事，不是直接生成申请文件，而是把这些 隐性标准 拆成 可观察、可讨论、可评测 的规则。
在技术交底环节，系统可以检查要素完整性、术语一致性和实施例缺口；在查新环节，可以扩大检索范围并保留检索式与证据出处；在申请审核环节，可以检查支持性、清楚性和保护层级；在 OA 与 FTO 环节，则需要把对比关系、法律状态、时间边界和风险理由明确呈现。
但这并不意味着把判断权全部交给 AI。相反，错误代价越不对称，人工边界 越要清楚。遗漏一个高风险专利，和多提示一篇低风险文献，不是同一种错误；自动给出一段修改建议，和正式改变权利要求范围，也不是同一种责任。
我更认可的分工是：AI 负责广覆盖、结构化比对、证据整理和一致性检查；专家负责风险取舍、法律判断、保护策略与最终签字。系统必须把“结论”和“结论依据”同时交付，让专家能够快速推翻它，而不是被迫相信它。否则，我们只是把一个黑箱换成了语气更自信的黑箱。
衡量这类场景，也不该只看生成速度。更有意义的指标包括：申请文件返工率 是否下降；不同审核人对同一问题的判断是否更一致；高风险文献的召回是否稳定；专家把时间花在机械核对还是关键策略上；错误能否沿证据链被定位。
「AI 的置信度不是 法律置信度。越接近权利与风险，系统越要为人的判断留出清晰接口。」
04
UNCERTAINTY
五十页报告之后，为什么还会有人问“所以呢”
另一类现场看起来也天 然适合大模型：把专利、论文、市场、政策和企业动态聚合起来，再生成一份结构完整的报告。技术上已经不难，五十页也不难，难的是第五十一页能不能告诉决策者下周先做什么。
真正困难的是：报告完成后，决策者下一步做什么？
明线是把信息搜得更快、报告写得更全；暗线是定义组织到底在犹豫什么，以及哪些证据足以让它停止犹豫。
我见过最常见的失败形 态，不是报告写得差，而是报告回答了很多正确的问题，却没有回答决策者此刻最需要判断的问题。信息越来越多，不确定性却没有减少。报告讲完，会议室沉默两秒，终于有人问：“所以呢？”这两个字，通常是战略情报最严格的验收测试。
因此，这类工作的 FDE 设计应当 从决策反推，而不是从数据正推。先明确这次分析服务于立项、投资、并购、产品路线还是竞争应对；再把一个宽泛议题拆成问题树，规定每个分支需要什么证据、什么时间范围、什么比较基准。
证据本身也需要分级。专利可以说明技术布局，却不等于量产能力；论文可以说明研究方向，却不等于商业化进度；招聘、标准参与、供应链变化和产品发布，可能构成不同强度的旁证。系统不仅要找支持结论的材料，还要主动搜索 相反证据和缺失证据。
我越来越重视“反证位”。如果一份情报只会把已有观点包装得更完整，它很容易成为确认偏误的自动化工具。真正有价值的系统，应当明确告诉使用者：哪些结论证据充分，哪些只是推断，哪些关键假设一旦变化就会推翻当前判断。
在这个场景里，AI 适合做大范围扫描、实体关系整理、时间线更新、相似技术聚类和持续监测；人更适合定义决策问题、判断证据权重、处理利益冲突和做资源取舍。最终交付也不应只有长报告，而应包含决策摘要、证据卡、反方观点、待验证假设和 下一步动作。
建议指标同样要从“产出了多少页”转向“是否改变了决策”：关键证据能否回溯；研究周期是否缩短；重大结论是否经过反证；报告中的建议是否进入立项或评审；持续监测是否触发了具体行动。
「情报工作的价值，不是让组织知道得更多，而是让组织在关键时刻更少地猜。」
05
ITERATION
把错误路线跑得更快，不叫降本
再往工程研发现场走，最容易想到的是减少检索、阅读和写报告的时间。这些当然重要，但做得越深，我越觉得真正昂贵的不是某个动作慢，而是整个团队沿着一个错误假设走了太久。把错误路线跑得更快，不叫降本，叫加速烧钱。
一次 无效迭代 的成本，往往跨越多个环节：工程师重复寻找已经存在的方案，技术路线忽略了某个边界条件，试验失败后无法沉淀原因，另一个团队隔一段时间又重复走一遍。
所以我理解的研发工程降本，不是让 AI 替工程师更快地产生答案，而是 让失败更早暴露，让 可复用的知识 更容易进入下一次决策。
明线是节省搜索、分析和写作时间；暗线是把失败前移，把一次试错留下的知识送进下一次决策，而不是留在某位工程师的聊天记录里。
一个完整链路通常从问题结构化开始。把“性能不好”改写成 目标指标、基线、约束条件、可调参数和已知失效模式。只有这样，后续的技术检索、TRIZ 启发、跨行业方案迁移和可行性评估才有共同坐标。
接下来，系统可以从专利、论文、标准和内部文档中寻找候选原理，说明每条路线解决了哪个矛盾、依赖什么条件、可能引入什么新风险。一次生成十几条思路并不等于创新，只是把头脑风暴搬到了服务器上。候选方案不能直接变成工程指令，而应先进入一份 可审查的证据包：来源是什么，适用边界是什么，关键参数是否可获得，和现有方案相比牺牲了什么。
在可行性阶段，DFMEA、标准核验、材料兼容、供应约束和试验条件需要共同参与。这里最有价值的并不是生成更多创意，而是尽早排除那些看起来新颖、实际上违反工程约束的路线。
试验之后，系统还要接住结果。成功条件、失败原因、参数窗口和专家备注如果不能 结构化回流，前面的智能搜索就只是一次性服务。FDE 要设计的，是 从问题、方案、证据到验证结果的闭环，而不是一个回答技术问题的聊天入口。
这个场景的人机边界也 很明确：AI 可以扩大搜索空间、整理证据、生成备选假设和检查遗漏；工程师必须定义约束、判断物理可行性、设计关键试验并对安全与性能负责。
衡量这类现场，我会关注首次形成可信方案所需时间、重复检索和重复试验是否减少、风险是否在投入更多资源前被发现、试验结论能否被其他项目复用，以及系统推荐最终有多少进入了正式评审。
「研发降本的核心，不是少做几次搜索，而是少走一段没有证据支撑的路。」
06
NEXT MOVE
八十三点七分以后，下一步是什么
还有一类现场经常从评 分开始。法律稳定性、技术先进性、市场前景、家族布局、被引情况被组合成一个分数，看上去客观、整齐，也容易形成资产清单。尤其精确到小数点后一位时，仪式感非常充分。
但我逐渐意识到，分数只能回答“它可能怎么样”，很难回答“接下来该做什么”。给一件专利打八十三点七分并不算太难，让它找到一个愿意坐下来开会的潜在合作方，工作才刚刚开始。
明线是分类、分级和评分；暗线是把专利重新翻译 成产品语言、产业语言和交易语言，让分数变成一个可以推进的动作。
专利价值不是完全内生的属性，而是一种关系。它取决于专利覆盖的技术是否进入产品，权利要求能否映射到真实实施，潜在使用方是否存在，交易双方的资源是否互补，法律状态和剩余期限是否支持后续动作。
同样一件评分很高的专 利，对正在布局相关产品的企业可能是防御资产，对缺少产业化能力的高校可能是许可标的，对已经退出该技术路线的企业则可能只是持续产生年费的存量。
因此，FDE 在这个场景里不能停在分类分级。系统需要继续连接 产品、技术路线、产业链环节、潜在需求方、实施证据和交易条件，把“高价值”翻译成具体动作：继续培育、组合保护、内部实施、对外许可、寻找承接方，还是停止维护。
其中最难的环节通常不是算法，而是 语义对齐。一项专利描述的是技术特征，企业需求说的是性能问题，产业链数据使用的是产品与工艺语言。三套语言之间如果没有稳定映射，所谓“一键匹配”很快就会变成“一键制造待清理线索”。
AI 可以承担资产清洗、技术标签、相似需求发现、候选企业排序和线索监测；人仍需判断权利稳定性、商业意愿、实施条件、谈判策略和合规风险。交易不是一次推荐，而是一段需要持续更新状态的流程。
因此，评价系统也应该向动作 靠近：有多少专利获得了明确处置建议；有多少候选匹配通过人工初筛；线索从发现到接触经历了多长时间；失败原因有没有被记录；维护成本是否流向更值得保留的资产。
「价值运营不是给专利一 个更漂亮的分数，而是让每一项资产拥有更清楚的下一步。」
07
AFTER ONE YEAR
最好的结局，是群里不再有人艾特我
FDE 很容易陷入一种危险的成功：工程师越来越懂现场，客户越来越依赖工程师，每个问题都能通过临时判断和快速改动被解决。短期看，项目推进很快；长期看，工程师变成了最稳定的 人形接口，也变成了最昂贵的 单点故障。
如果一种能力只能由原 来的 FDE 维护，它就还没有真正进入组织。最直观的测试是：群里不再随时有人艾特你，系统是否还能正常跑。
所以我现在会反过来问：项目结束后，现场到底留下了什么？
至少应该留下 六类资产：明确的数据边界，能够复用的 Skill，覆盖正常与异常情况的评测集，与业务系统连接的流程接口，被写成规则的专家判断，以及有人持续维护的 运营机制。
这些资产决定了同类场 景能否复制，也决定了一线反馈能否进入产品和模型迭代。明线看，FDE 交付了一个系统；暗线看，组织终于把一部分经验变成了能复用、能验证、能交接的公共能力。
FDE 不只是把能力向前部署，还应该把现场学到的失败模式、边界案例和评测标准向后传递。
我越来越倾向于用四个问题评价自己的工作：系统是否被 真实采用；是否改变了某个可观察的流程结果；出现异常时业务团队能否自行处理；新场景能否复用已经沉淀的组件，而不是重新开始。
做到这一步，FDE 的角色会从现场救火者变成能力建造者。工程师本人不再是流程里的必要节点，之前依赖个人经验的判断，被逐步转化为 组织可以使用、检查和更新的系统能力。
「最好的 FDE 交付，不是让自己成为群里永远艾特得到的人，而是让正确的方法 不再依赖某一个人。」
做了一年多之后，我对企业 AI 的期待反而没有刚开始那么浪漫。我不再认为一个更强的模型会自动解决组织问题，也不再把上线当作终点。
真正值得做的，是选择那些足够重要的决策节点，用可靠证据约束模型，用明确流程承接结果，用评测和责任让系统持续变好。
当模型开始进入流程、专家经验开始变成规则、失败开始沉淀为评测集，AI 才不再是一场演示。它会慢慢成为组织工作方式的一部分。
END
我是 AFN。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。
