先说背景。名义上，我们同属研发。日常干的活，实质是交付。把产品交到客户手里。用起来。出了问题，现场兜住。现在产品方想借两个热词推活给我们。两个热词，一个叫 FDE，一个叫 OPC。FDE 是「派工程师驻到客户现场写代码」。OPC 是「一个人加 AI 也能开公司」。他们想拿这两个词说服我们：顺手把产品开发的活也干了。这篇报告先讲清两个词的原义。再讲清边界该划在哪。
先给结论。FDE 这个词，不能当推活的许可证用。真正的 FDE 有四个硬条件。工程师归产品公司管。底下要有好用的平台。现场写的代码要过产品评审。大合同要养得起这支队伍。四个条件一个都不给，只借一个名字。a16z 是硅谷一家大风投，也是最挺 FDE 的机构。连他们自己的批评文章都给这事起了个名字：「Accenture for X」。Accenture 是全球最大的咨询公司埃森哲。说白了，这就是换个名字的咨询公司。OPC 讲的是另一件事。它证明 AI 让一个人能干更多活。它没有证明一个人能扛企业软件的长期责任。合规要人扛。出事要人扛。多年支持也要人扛。
读法：正文只讲事。来源只在关键数字后面用括号补一句。文末有完整的来源清单。
结论先说：这个岗位正被疯抢。岗位数一年涨了约 729%。大公司还砸下几十亿美元建队伍。
为什么突然缺人？AI 试点很多，真正上线赚钱的很少。中间隔着一条沟。MIT 是麻省理工学院。它有个研究常被人引。研究说，95% 的受访公司没赚到可算清的钱。（来源：MIT NANDA《The GenAI Divide》，2025 年）请注意原意。研究说的只是没赚到钱。它没说 95% 的项目都失败了。外面流传的说法把这句讲歪了。真正卡住的是部署环节。工具接不进日常工作流。员工的反馈也留不下来。标普全球和咨询机构 Gartner 的数据指向同一处。
资本为什么愿意讲这个故事？a16z 合伙人 Joe Schmidt 写过一篇文章。（来源：a16z《Trading Margin for Moat》，2025-06-04）他说得很坦白。FDE 干的活，很多就是专业服务。换了个新名字而已。他的主张是先别心疼毛利。先用服务换市场地位。他举了两个老例子。ServiceNow 上市时毛利 63.2%。Workday 上市时毛利 54.1%。到 2024 年，两家回到 79% 和 75%。先做服务，后面再把钱按软件的方式赚回来。这条路有人走通过。
FDE 是 Forward Deployed Engineer 的缩写。意思是派到客户现场干活的工程师。发明这个模式的公司叫 Palantir，美国一家数据平台公司。定义看它的官方博客最准。（来源：Palantir《Dev versus Delta》，2019-04-08 发布，2023-11-29 更新）
| 角色 | 归哪个部门 | 干什么活 |
|---|---|---|
| Dev（产品工程师） | 产品开发部门 | 他们开发 Foundry 和 Gotham 两个平台。一个团队管好一块平台组件，从头管到尾。他们的口号是：一项能力，服务众多客户。 |
| Delta（就是 FDE） | 业务发展部门 | 他们把平台装到客户那里。他们为单个客户拿到结果。他们的口号是：一个客户，用上众多能力。Delta 还有个搭档叫 Echo。Echo 懂业务，负责找最值钱的问题。 |
这一段最常被人跳过。官方原文偏偏写得最清楚。
交付卡住了，缺一个功能，或者有个缺陷。Delta 可以自己动手补。但他必须先跟产品团队商量。功能大一点的，要先对一遍产品路线图。对上了，才能排进计划。写代码时也要一直沟通。请产品团队看，请产品团队审。
翻译成大白话就是三句话。现场的人可以写核心代码。写之前要商量。写之后要过审。最后拍板的人在产品侧。Delta 只有发起权和参与权。他没有自己决定、自己合并的权力。
a16z 是最挺 FDE 的机构。批评的话偏偏出自他们自己。（来源：a16z《The Palantirization of Everything》）他们说，Palantir 能跑通，先因为底下有真平台。Foundry 平台有几百个现成的小组件。有数据模型。有权限控制。有工作流引擎。有现成的界面零件。FDE 的活是挑零件、拼零件、验效果。新零件留给产品工程师去造。只学驻场，不学平台，后果很具体。每个客户一套定制代码。谁也维护不了。谁也升不了级。再加一条：FDE 若归服务部门单独管，现场反馈传不回产品。公司会慢慢变成纯卖人力的生意。他们给这种公司起了个名字。「Accenture for X」。后面挂个好看的界面而已。
| 论点 | 出处 |
|---|---|
| FDE 一多，公司看上去就是咨询公司。传统服务毛利只有 30–40%。软件毛利有 70–80% 以上。这笔账很难看。 | N47（一家风投机构）《The Forward Deployed Engineer Dilemma》 |
| 驻场的人一撤，客户就用不上买的东西。这说明产品本身没站稳。软件卖得越多，单位成本越低。人力卖得越多，人头申请只会越多。 | 科技媒体 Crunchbase News 的评论，Airrived 公司 CEO（首席执行官）Anurag Gurtu，2026-10-19 |
| 现场学到的东西，要变成产品资产。变不成，就只剩一堆定制项目。判断方法很简单。下一个同类客户，定制工作量必须变少。变少不了，这就是按小时卖人。 | 前 Palantir FDE 的回忆类文章，二手梳理 |
| 支持方这样回应。Palantir 长期保住 80% 以上的软件级毛利。（此数出自 N47 文章，我们没单独核财报）ServiceNow 和 Workday 也证明过，服务先行能慢慢收回来。真 FDE 和传统实施差在三点。靠平台复用，少堆人头。收的是持续订阅费，少卖项目工时。目标是让客户自己会用，我们的人慢慢撤。 | a16z 与 N47 的文章 |
小结。吵来吵去，双方其实大体同意。分界线很清楚。有没有平台。有没有代码回流的规矩。有没有办法让下一个客户更省钱。三样都有，才叫 FDE。三样都没有，就是咨询换了个名字。这条判断出自挺 FDE 的 a16z。也出自分析方 N47。两边都认。
OPC 是 One Person Company 的缩写。字面意思就是一人公司。到了 2025 年，官方文件给了它新解释。一个人加上 AI，也能开一家公司。深圳市南山区政府的解读这样写：个人有 AI 帮忙，可以独立做完一整条链。从设计产品、开发产品，一直做到推向市场。Sam Altman 在 2024 年初说过一句名言。他和几位科技公司 CEO 打了个赌。他们赌第一家一人十亿美元公司出现在哪一年。请注意，这只是一个预测。事情还没发生。引用时要带上这句说明。
小结。OPC 只证明了一件事。AI 把一个人的产能上限抬高了。它没证明另一件事。一个人或几个人，能扛企业软件的长期责任。产能是效率问题。责任是另一回事。2B 交付卖的恰恰是责任。还有人把 FDE 和 OPC 打包讲故事。小团队加 AI，就能顺手把产品开发也干了。我们查过，行业媒体里没找到权威的成文论述。上面这句概括出自本报告的分析。这个推论跳过了两样东西。它跳过了 FDE 的平台和评审条件。也跳过了 OPC 样本的适用范围。
结论先说：标准、大厂分工、服务合同，三份证据指向同一边。这类活归产品侧。
谈判时可以这样用。ISO/IEC 25010 有个用途：支撑采购和签合同。客户可以在合同里写明诊断要求。写了，就成了对产品的验收标准。履约的人就是产品方。我们在项目里私下补诊断代码，麻烦有两层。产品方不算履约。验收时还会扯皮。这个能力到底归谁负责？合同一查就含混了。
HPE 是一家做企业级 IT 的美国公司。它设了专职的可服务性高级岗位。我们看过它的招聘文本。岗位职责写了两件事。第一，把支持案例的趋势整理出来。把升级出事的记录整理出来。把客户的声音整理出来。再把这些翻译成需求，交给产品管理和工程团队。第二，跟产品团队合作。让新版本一开始就把可支持性设计进去。包括诊断、日志、监控、排障流程和恢复办法。Lenovo 的同类岗位也一样。要求在新一代产品的设计阶段，就把可服务性做进去。分工看得很清楚。现场负责发现问题。现场负责提炼需求。产品工程负责设计。产品工程负责实现。
| 合同文本 | 关键条款，大白话版 |
|---|---|
| Globalscape 专业服务条款 | 我们做的配置，只能用产品现有的核心功能。客户签字确认一件事：服务不含大改和定制。软件有缺陷，要走维保计划。有问题、要改动、要新功能，也走维保计划。我们写的定制代码按现状提供。不给维护。不给支持。再出问题，另签一份工作说明书。 |
| Prophecy International 专业服务附录第 6.1 条 | 原文一句话：服务不包括给核心产品做增强。 |
| PagerDuty 专业服务工作说明书（Optimize 包） | 明确列出不做的事。定制开发不做。定制改造不做。扩展开发不做。复杂的双向集成也不做。 |
三份合同的结构完全一样。专业服务只承诺一件事：在产品现有能力内做配置和实施。产品缺能力，走产品和维保的通道。交付通道不接这类活。可服务性的缺口也一样走产品通道。
平台级能力归谁管？日志、部署、更新这类底座能力，归产品工程师管。他们端到端负责平台组件。Delta 发现缺口，可以动手补。但他要先商量。要过路线图。要过产品评审。产品方现在的主张，换个说法是这样：让 Delta 长期自建平台能力。没有 Foundry 平台打底。没有代码回流的评审。也没有路线图上的商量。去 Palantir 自己的文本里找，找不到这种做法。
结论先说。四条原则条条有厂商依据。没有一条是我们自己拍脑袋定的。
ServiceNow 的官方文档分了两个词。（来源：ServiceNow 官方文档 Zurich 版，2025-07-31 更新）第一个词叫配置。用内置工具改应用行为。原厂代码不动。原厂流程也不动。脚本只要不碰原厂代码，也算配置。第二个词叫定制。改了原厂安装的代码，就算定制。改了原厂流程，也算定制。
厂商的支持态度同样写明了。你加了代码，你就拥有它。后果也归你。你的代码惹出的问题，超出厂商支持范围。定制还会带来三笔账。平台升不了级。技术债越攒越多。升级周期越拖越长。官方给的建议只有一句：能配置，就别定制。还有一条正路：提交增强请求。等它排进未来版本。官方知识库 KB0553407 说得更直。改了原厂代码，你要一直维护下去。还要保证升级后能用。支持人员查出病因在定制上，会先建议你退回原厂代码。再谈下一步协助。
我们由此定一条线。我们能接的活，上限在「不动原厂代码」这一侧。一旦要改产品本体，活的性质就变了。那等于替产品方长期持有代码。
SAP 有个做法叫 Clean Core。意思是保持核心干净。SAP 在 2025 年 8 月更新了扩展分级。A 级最高。只用已发布的接口和扩展点。可以在云端写。也可以在旁边另搭一套扩展。升级最稳。B 级用经典接口。C 级用了未发布的内部对象，有条件可用。D 级最低。直接改核心代码。绕着加增强。直接写 SAP 的表。D 级不算 Clean Core。也拿不到认证。SAP 要求伙伴的方案达到 A 到 C 级，才给认证。还有一笔长期的税。改过标准对象的人，每次升级都要走一遍调整流程。流程名叫 SPDD 和 SPAU。这就是改核心的代价。（来源：SAP 官方升级指南与认证说明）
我们由此定一条线。在官方接口内开发，可以谈。升级风险有平台契约兜底。跳出接口去开发，不能接。那等于把升级的税永久转给动手的人。
这条在 Salesforce 的圈子里最通行。Salesforce 是做客户关系管理软件的厂商。它有两个做法。一个叫声明式：点点设置就能配好。比如建字段、定校验规则、搭审批流。另一个叫编程式：要写代码才行。Apex 和 LWC 是 Salesforce 自家的两种编程语言。圈内规矩是，能点设置解决的，就别写代码。理由有三条。配置不会被版本升级打坏。有官方文档和培训兜底。原作者走了，接手的人也看得懂。Salesforce 对代码还有硬门槛。比如 Apex 代码部署时，测试覆盖率至少要 75%。
我们由此定一条线。来一个需求，先问一句：用现成的配置、开关、模板，能搞定吗？能搞定，我们做的就是配置实施。这类活可以接。搞不定，再往下议。要不要写代码。该由谁写。顺序不能跳。不能跳过配置这一层，直接让我们补代码。
这一条出自本报告的分析。推导依据就是上面三条。改动只要碰到下面任何一面，直接升级处理。要么不接。要么走例外审批。碰数据模型和存储格式。不接。改对外协议和接口含义。不接。碰登录、权限、加密、审计这类安全面。不接。动升级和回滚的路径本身。不接。改多家客户共用的代码。不接。理由很简单。这些面一出事，倒下的不止一家客户。是整个产品。
结论先说。一件活进来，要走两步。第一步先筛归属：它到底算不算可服务性需求。第二步再分档：算清之后，谁来做，怎么做。落到「有条件接」的活，第八节的护栏要全套配齐。缺一件，自动降为不接。要么升级走例外审批。通信行业还要再加码，看第十一节的复核表。
这一层专治改名游戏。「可服务性需求」这个标签，谁都能抢。同一件活，换个名字，归属就换了。配置给谁用，算哪边？数据修复脚本，算哪边？数据导出，算哪边？性能调优，算哪边？每件活都横跨两边。靠抠定义，抠不出来。所以筛的时候换个标准。不看名字。看活的性质。下面四条判据，命中多数，才算可服务性需求。
用它的是运维、支持、交付人员。业务用户平时干活，用不到它。用的人变了，归属就跟着变。
做也好，不做也好。业务规则一样。业务结果也一样。它只改变一件事：出事时找问题有多快，恢复有多快。
系统一切正常时，它毫无价值。它的价值只在几个时刻出现。故障时。变更时。扩容时。
它盖住所有模块。比如全系统统一的日志格式。统一的诊断入口。只落在单个业务点上的活，多半另有归属。
用法：四条命中三条以上，按可服务性需求处理。只命中一两条，按功能需求或混合需求处理。走正规需求通道。登记时写清怎么拆。多数活靠判据能定。剩下的灰区，看下面两段。
可服务性的价值，全靠一致。日志格式要全系统统一。诊断方式要全系统统一。健康检查的口径也要统一。十个局点各做一套，各用一种格式。合起来等于没有可服务性。这种盖全系统的活，只能由产品侧来做。统一设计。统一实现。随版本统一发布。
所以有句话恰好说反了。「因为是可服务性，所以交付先做。」说反了。筛完确认属于可服务性需求，下一步是送进产品排队。按第九节的正规通道送。再谈排期。干活的主体仍是产品侧。我们在三档表里能接的活，靠的是做法合规。外围工具可以接。限期止血可以接。靠的全是做法合规，跟标签没关系。
判据再细，也会留灰区。灰区争的是归属。用规矩处理，比用定义处理管用。
| 档 | 工作类型 | 怎么判定 | 一句话理由 | 行业依据 |
|---|---|---|---|---|
| ✅ 接 | 改配置做适配：用产品现成的开关、参数、模板和点选工具，满足客户需要 | 不写代码，或者只改配置。不改变原厂行为的定义 | 改配置是交付的本职。升级打不坏它。厂商支持也不打折 | ServiceNow 对配置的定义；Salesforce 点选优先的做法；专业服务合同里「只在核心功能内配置」 |
| ✅ 接 | 在官方接口内写脚本和对接代码：用已发布的接口、插件点、回调通知，做客户侧对接、数据映射和报表 | 只调用已发布的接口。代码装在客户侧或扩展区。不进产品安装包 | 官方接口是产品方签过字的边界。稳不稳，契约兜底 | SAP Clean Core 的 A 级和 B 级；ServiceNow 的扩展指引 |
| ✅ 接 | 不进产品本体的外围小工具：整理日志、查健康状态、巡检、做报表。工具单独放仓库，单独发版 | 工具坏了，不影响产品运行。只读数据，或者只给最小权限。不随产品版本一起签名发布 | 外围工具出事，只是工具的事。闹不成产品事故。也惹不出支持纠纷 | 本报告分析：结合 ServiceNow「自己加的代码自己负责」反推出来的隔离做法 |
| ✅ 接 | 带到期日的临时止血：先绕一下，解客户的燃眉之急 | 立项时就写清三件事：负责人是谁，到期日哪天，怎么回滚。再登记进例外册 | 止血可以做。合法性来自有期限、有登记。先干了再说，不算数 | ITIL 的紧急变更做法：先救急，事后必评审；临时开关到期要清理的做法 |
| ✅ 接 | 发现需求、写清需求、推动排期：整理工单和现场证据，写好需求条目，推它进产品排队清单，再跟进 | 我们交的是需求和证据，没有代码 | 大厂给现场侧定的位就是这样：当传感器，当推动者 | HPE 和 Lenovo 的可服务性岗位职责 |
| ⚠️ 有条件接 | 在官方接口内写扩展，但代码要进客户生产环境 | 五个条件全过：核心团队审过代码，仓库设置强制要审；安全评审过关；代码回主线，或者进官方扩展仓库；我们承担约定的保修期，比如 30 天；版本怎么收回，计划写明 | 进了生产环境，就进了支持和审计的范围。没人审、回不去的代码，早晚成孤儿代码 | Palantir 的回流原文；开源社区的 30 天保修做法；GitHub 的代码所有者机制 |
| ⚠️ 有条件接 | 产品缺功能，我们先写出来。前提是产品侧已经受理需求，只是排期靠后 | 需求负责人留在产品侧，要书面确认。我们按主线的规范写代码。设一个合并的硬期限，建议不超过一个发布周期。到期没合并，就冻结或丢弃。我们不再免费维护。合并之后，代码归产品侧管 | 我们先出的是力气。代码归属不能跟着走。没期限的先行开发，早晚长成分叉版本 | Palantir 的规矩：大功能要先过路线图；开源圈的 upstream-first 做法，先回上游再用 |
| ⚠️ 有条件接 | 单客户、单版本的紧急修复。就是常说的 hotfix，热修复包 | 走紧急变更通道，加速审批。事后限时补单，限时复盘。同一个修复必须同步交回主线 | 紧急可以加速流程。紧急不能取消流程 | ITIL 的紧急变更做法：事后必须评审；SOC 2 的 CC8.1 条款：紧急变更也要留痕。SOC 2 是审企业内控的一套标准 |
| ❌ 不接 | 改产品本体：改核心模块代码，改默认行为。交付物要进产品的安装包 | 只要交付物要随产品一起签名发布，就算这一档。只要它改变所有客户的行为，也算这一档 | 签名就是背书。产品方签了名的东西出事，责任在产品方。没签名权、没发版权的人，不该生产它 | 代码签名的职责分开做法；ServiceNow 对原厂代码的定义 |
| ❌ 不接 | 改数据结构、存储格式、对外协议和接口含义 | 看它影不影响数据迁移、版本兼容和多家客户的一致 | 这类改动一出事，波及全部存量客户。而且最难撤回 | 本报告分析；加 SAP 的 D 级定级：直改核心、直写表，最低档 |
| ❌ 不接 | 碰安全面：登录认证、权限、加密、审计日志本身、安全策略的执行点 | 只要碰到安全控制面，就算这一档 | 安全代码要走完整的安全开发流程。先建威胁模型。再由非作者评审。最后还要过终审。我们交付侧没有这条链 | 微软的安全开发生命周期，简称 SDL；SOC 2 的 CC8.1 条款 |
| ❌ 不接 | 动升级和回滚的路径：改升级程序，改版本兼容逻辑。绕开已发布接口，直接用内部结构，也算 | 看它决不决定所有客户能不能升级 | 一次升级失败，代价由所有客户和支持链一起扛。跟单个项目的收益完全不成比例 | SAP 的 SPDD 和 SPAU 调整税；ServiceNow 的做法：升级时跳过定制，人工决定怎么合 |
| ❌ 不接 | 没头没尾的「长期临时方案」：没到期日，没合并计划，没负责人 | 三样缺任何一样，就落这一档 | 它算不上方案。它是未来的孤儿代码。也是日后绑住产品路线的种子 | a16z 的时间盒和回收清单；例外治理的通行做法 |
用之前先过第一层筛查。先数四条判据，看它算不算可服务性需求。这个判定器按第五节的四条原则，给第二层的初步结果。结果只作参考。落到「有条件接」的活，还要走第八节的全套护栏。
1. 这件活要改产品原厂代码，或者改默认行为吗？
2. 它会碰到数据结构、对外协议、登录、权限、加密、审计，或者升级回滚吗？
3. 只用产品已发布的接口、插件点、回调通知，能做出来吗？
4. 做出来的东西会随产品交付，进客户生产环境吗？
结论先说：我们的代码要进生产，四道关一道不能少。产品审代码。安全单独审。发版走产品流水线。出事按谁写的谁负责。
Palantir 的原文讲过：现场回流的代码，由产品团队验证和评审。我们内部有个现成的等价工具。GitHub 有个机制叫 CODEOWNERS。意思是给每块代码指定主人。官方文档写明：有人改了某块代码，系统自动请主人来审。分支保护还能再加一道锁：主人不批准，代码合不进去。做法很简单。核心模块的主人写产品团队。这样我们的任何主线贡献，都绕不过产品评审。全靠仓库设置卡住，不靠自觉。开源社区还有个类似角色，叫可信提交者。宿主团队的可信提交者负责审和合。贡献方没有直接合并的权力。
微软的安全开发生命周期有个硬要求。SDL 就是这套安全流程的简称。验证阶段要做人工评审。评审的人不能是作者本人。微软明确说，职责分开是这一步的关键。发布阶段还要做三件事：最终安全评审。备好事件响应计划。分批灰度发布。据此我们定最低线：我们的代码要进客户生产环境，三件事缺一不可。非作者评审。安全评审。走正式流水线发布。缺任何一件，不许上线。
发版和签名的权力，不下放。行业通行做法是这样：签名私钥存进硬件设备，简称 HSM。签名是流水线里单独受控的一步。申请人不能兼做批准人。每次签名操作都留审计记录。落到我们这里：我们可以写代码。产品的发版签名，我们不能碰。生产发布权限，我们也不能持有。发布动作必须在产品侧的流水线里完成。谁绕过流水线，把没签名的版本送进客户生产，谁就制造了一次查不到账的变更。
ITIL 是管 IT 服务的一套通行方法。它把变更分了级。低风险的标准变更走快速通道。高风险或重大变更，要过变更顾问委员会。委员会简称 CAB。委员会要评估风险、影响和回滚方案，再决定批不批。紧急变更走加速审批。但事后必须复盘。文档必须补齐。落到我们这里：一切「破例进产品」的事，都进委员会评审。别搞双边口头同意。紧急止血可以先做。但要在约定时限内补单复盘。时限一般是 24 到 48 小时。（此数是从业者的通行值）
先解释四个字母。A 是批准人。R 是干活的人。C 是要咨询的人。I 是要知会的人。下表是本报告的建议。依据是本节的四道护栏。
| 事项 | 产品研发（核心） | 产品管理（PM） | 交付（我们） | 安全与质量 |
|---|---|---|---|---|
| 定可服务性需求，排优先级 | C | A/R（排队清单归 PM 管） | R（交证据和条目） | C |
| 写产品本体代码 | A/R | C | I | C |
| 在官方接口内给客户写对接 | C（审代码时是 A） | I | R | C（生产代码的安全评审是 A） |
| 先写的代码合回主线 | A（决定合不合） | A（核对路线图） | R（交 PR，保修期内修缺陷） | C |
| 发版和签名 | A/R | I | —（无权限） | C |
| 生产事故，源头在产品本体 | A/R | I | C（现场处置） | C |
| 生产事故，源头在我们的扩展或止血代码（保修期内） | C | I | A/R | C |
| 批破例进产品 | A | A | R（提交申请） | A（安全例外）——即委员会集体批准 |
结论先说：需求只走一条正道。写成条目，送进产品唯一的排队清单。别在旁边另开一条没人管的开发线。
结论先说。安全、稳定、版本碎，是工程账。下面九本账同样决定这类安排成败。
可服务性在两个标准里都是产品质量要求。细节见第四节。谈判先钉定义，位置就高一层。客户若在合同里把诊断能力写成验收要求，履约人就是产品方。这一条的账，不用争谁有空。
产品研发考核看两样：路线图交没交，功能做了多少。可服务性这类非功能需求，在他们的指标里很难看见。推给我们，他们不心疼。我们的考核看项目按期验收。拒活的代价反而最高。所以我们容易被动接下。可代码的长尾风险落在接活的人身上。升级要管。安全要管。出事也要管。收益归研发。风险归我们。两边都在按自己的考核理性行事。合起来，组织整体吃了亏。这个现象有个名字，叫 Goodhart 定律。指标一旦变成目标，就会失真。（本角度是分析观点。没有针对我们这种情况的直接研究，特此说明）对策：别争动机，只改计价。下放工作要同时转三样东西。产能预算要转。保修期内的事故责任要转。排队清单里的优先级额度也要转。只转活，不转这三样，在纪要里写明：无对价转移。留痕存档。
工程圈有个词，叫巴士因子。意思是：最少几个人突然不在，项目就停摆。这个数等于 1，最危险。有项研究算过 133 个热门开源项目。（来源：Avelino 等，2016 年）46% 的项目，这个数是 1。还有 28% 是 2。落到我们这里：现场代码攥在一两个人手里。代码不进主仓库。也没有第二个人审过。人一轮换，代码就成孤儿。人一离职，代码也成孤儿。人一休假，还是没人敢动。没人敢改。没人能排障。升级时没人能判断怎么合。我们补一条护栏判据：任何我们的代码，合并前要满足一个条件。至少两名非作者能讲清原理。也能讲清怎么回滚。达不到，不许上线。（此判据是本报告的建议）
先说合同。行业惯例里有个保护写法：定制代码按现状提供。再出问题，另行计价。我们若没有这类条款就接产品类开发，等于主动放弃保护。还有个麻烦：同一段代码，权利会打架。项目合同常把交付物权利约定给客户。产品代码的权利该归产品方。再说审计。SOC 2 的变更条款 CC8.1 要求很细。变更要有人授权。要有设计。要留记录。要测试。要批准。才能上线。审计师会抽查生产变更。一条条核对工单、评审、测试和部署记录。作者自己批自己，是典型问题。等保标准 GB/T 22239 也有要求。（此条是二手转引）重要变更要先审批再实施。还要更新配置信息库。绕过产品流程的现场代码，同时绕过三本账。代码仓库和评审记录里没有它。变更审批记录里没有它。配置信息库里也没有它。金融和政务客户来审计，这类代码会被定性为未授权变更。不会被夸成灵活。这是反对影子开发最硬的一条。它依据的全是合规事实。
厂商早有成文先例。ServiceNow 的支持不调试客户的定制代码。查出病因在定制，他们建议退回原厂版。升级时，系统会跳过定制代码。人要自己决定留、退还是合并。Quest 是 Oracle 生态里的厂商。它的支持政策同理：定制不在正常支持范围内。支持团队不拥有任何定制。我们内部的支持链长一个样。一线二线的复现环境装的是标准版本。现场定制不在里面。工单只能空转：复现不了，转给现场。转给现场，再找原作者。还有一层账。产品的服务承诺只对没改过的代码成立。承诺包括服务等级，简称 SLA。也包括长期支持，简称 LTS。定制改过的代码路径出了安全漏洞，标准补丁打不上。硬打上去，又会冲掉定制。长期支持的承诺就被局部击穿了。客户索赔时可不会因此降预期。护栏写法：凡是「有条件接」的代码，都要登记进支持团队看得见的定制清单。不登记，支持侧有权按厂商惯例宣布：这部分出支持范围。这句话要提前告诉客户。别等事故之后再说。
先给量级。软件维护占全生命周期成本的大头。多家成本梳理转引过 IEEE 计算机学会的口径：占 60–80%。年维护费的经验数是开发成本的 15–25%。（我们没核到一手原文，只作量级提示，别当精确数据引）错配出在哪？交付项目是一次性预算。验收就结项。资金池随之关闭。定制代码的成本曲线完全两样。每年都要再付一次。每次升级付一次。每个安全补丁付一次。每次环境变化再付一次。用一次性的钱，生产多年期的债。债还不进任何一方的长期预算。这类安排在财务上必然烂尾。对策：接「有条件接」的活，先显性列一行账。预计年维护成本，乘以预期存续年数。再指定由哪个科目承接。没人接这一行，这件活自动落到「不接」档。
工程界有个定律，叫 Hyrum 定律。（来源：《Software Engineering at Google》，2020 年）定律说：一个接口的用户够多时，合同里承诺什么都不重要。系统所有能观察到的行为，都会被人依赖上。落到现场实现也一样。哪怕我们事先声明：这是临时的、私有的、不承诺的。只要客户的业务流程跑在上面，它就成了事实合同。产品后续版本改了相关行为，客户会说：升级等于业务中断。要么拒绝升级。要么要求产品兼容。绑架点只会变多。客户越多，绑得越紧。跑得越久，绑得越紧。这也解释了两条规矩为什么要设。止血方案要设到期日。先行实现要设合并硬期限。趁依赖还没长成，收回或下线，成本最低。每晚一个版本，日后要付的代价就涨一次。
例外坏事，很少靠一次大破例。多半靠「上次都行」这句话慢慢磨。每引一次先例，审批的心理门槛就降一格。第三次起，例外就成了事实标准。成熟的例外管理有个做法：把每条例外当成一次明着接受的风险。理由要必填。影响范围要写清。补偿措施要写清。补救计划和到期日也要写清。审批按风险分级。所有例外进一个中央登记册。到期前复审。续期要重新审批。一条例外被反复续期，说明边界本身该修订了。要升级成正式规则讨论。别无限续下去。我们定三条硬规矩。第一，申请例外时，禁止拿历史例外当理由。第二，例外总数设上限。管理例会上公开计数。第三，同类例外第三次出现，强制二选一。要么立项成正式产品需求。要么明文关掉这个口子。（三条是本报告的建议）
Palantir 的 Delta 有影响力，原因不在活干得多。他们站在代码回流的通道上。现场证据经他们的手，变成核心产品能力。产品团队因此需要他们。回流评审就是我们进产品决策室的门票。前提是走正门。开源社区的 30 天保修和签约贡献者，结构也一样。用承诺换权利。无偿帮忙又无约定，只换来更多的活。厂商生态里还有个例子。按 Clean Core 和配置优先做交付的伙伴，能拿到 SAP 认证。认证只发给 A 到 C 级扩展。认证就是定价权。我们列一张兑换清单。每接一批「有条件接」的活，至少换回一项：一，对应的可服务性需求在产品清单里有明确排期。二，我们在季度路线图评审里有固定席位和提案权。三，先行实现的工作量有内部计价或预算回补。四，产品侧承诺修扩展点，把我们最常用的野路子逐个修成正路。四项全无，这批活就是无对价转移。要留痕。还要升级到更高层去决策。（清单是本报告的建议）
结论先说。前面的通用结论，搬进电信语境后只会更严。有公开依据的，下文逐项标了出处。运营商的内部制度多半不公开。找不到公开原文的，我们标成行业分析观点。条款编号一个都不编。
| 原结论 | 电信语境 | 复核说明 |
|---|---|---|
| ❌ 不接：动升级和回滚路径的改动 | 更强硬 | 电信现网的升级和回滚，在割接窗口内按审批方案执行。退回方案是割接方案的法定组成。任何动升级路径的现场改动，都会破坏后续所有割接的退回前提。处理要升级：不但不接，已存在的要优先清理。 |
| ❌ 不接：碰安全面，含认证、授权、加密、审计 | 更强硬 | 这里叠了三层外部约束。安全定级评测按年执行。采购环节有源代码安全检测。供应商还要配合网络安全审查。移动侧的软件还要备案稽核。我们一碰安全面，一次审计会同时触发三条线：客户合规、供应商考核、内部责任。 |
| ⚠️ 有条件接：单客户紧急修复 | 更强硬 | 电信语境里没有「先修后补单」的空间。动网在实施之前，先要躺在审批单里。条件要追加一条：先拿到客户的动网审批，走紧急割接通道，再实施。事后补单还要多补两样：客户侧的割接报告、维护资料更新。达不到，宁可走故障工单流程。让产品侧出版本包。 |
| ⚠️ 有条件接：在官方接口内写扩展，代码进生产 | 更强硬 | 原来的五件套之外，再追加三件。客户的入网或验收测试要通过。要纳入客户的软件备案或版本清单，按移动口径。要纳入供应商考核可追溯的交付记录。支撑系统的局点众多。「进生产」的单位是全网局点。五件套的执行成本要按局点数放大。立项时按全网口径估。 |
| ✅ 接：带到期日的临时止血 | 需调整 | 到期日别再按我们的发布周期定。要按客户的版本窗口和割接日历定。止血方案留多久、何时退出，要跟着运营商的版本发布和割接排期走。退出本身也是一次动网。要预留审批的提前量。 |
| ✅ 接：在官方接口内写脚本和对接代码 | 需调整，要收窄 | 电信语境的「官方接口」要按严口径认。认行业标准接口，比如 TM Forum 的 Open API。认 ODA 组件。认产品正式发布的扩展机制。局点现场临时开放的接口不算数。内部工具的接口也不算数。它们不在产品的版本兼容承诺内。跟「绕开已发布接口直用内部结构」只隔一层窗户纸。 |
| ✅ 接：发现需求、写清需求、推动排期 | 更重要 | 电信语境给了这项工作一把正规的尺。把需求按 COSMIC 口径写成功能需求。再附上规模匡算。然后提交。需求在客户和产品两侧的立项语言里，能直接计价，能直接排序。我们的证据包也最硬。故障工单算证据。割接失败记录算证据。定级评测的问题项也算证据。这是运营商体系里最硬的需求货币。 |
| 量的尺度：设期限、设在途上限、设到期日 | 需调整 | 时间盒的单位要换。不能再用「90 天到生产」。要跟着运营商的版本火车和集采框架周期走。版本火车指固定节奏发版的安排。再加一条电信特有的量：我们手里的存量代码，要能在客户版本清单里逐项对上账。对不上的，按影子资产处理。先登记。再定性。再限定清理期限。 |