小天说FDE | 程序员，嵌入式软件与Linux背景，分享AI学习、编程实践与FDE转型。共享产品能力，是让同类交付不必反复从头开发的基础。
把工程师派到现场，再用AI提高实现速度，不等于形成了可持续的FDE模式。本文讨论的是交付后的积累，不评价外包与FDE谁更高级。
为什么项目收入增加，维护也会一起增加？
每个客户单独实现一套数据接入、权限、日志、调度和监控，验收后仍要处理流程变更、接口升级和人员交接。
AI能减少一部分编码时间，但不能消除维护责任。新增客户越多，团队需要记住的实现和特殊规则也越多。
可以先把交付划成两层：前线理解客户差异，公共产品解决反复出现的技术问题。
怎样区分客户差异和共性能力？
| 内容 | 应重点判断什么 |
|---|---|
| 审批和业务规则 | 哪些确实属于客户特有约定 |
| 数据接入 | 系统和字段不同，是否仍有可共享接口 |
| 权限管理 | 是否需要每次重写底层机制 |
| 日志、调度、监控 | 是否可由统一组件提供 |
| 验收流程 | 共用方法是否仍需按客户标准验证 |
不能因为两个客户都要“知识库”，就认定实现可以直接共用。数据权限、业务流程和验收要求可能完全不同。
为什么复制代码不等于建立共享能力？
最简单的检验是：公共问题修复后，后续项目能否直接使用更新？
如果每份代码都要分别修改、测试和维护，复制只是缩短了开工时间，没有解决分散维护。
共享能力应能被实际调用，具备明确接口、测试和更新方式。它可以从一组稳定组件开始，不必一开始就是大型平台，但不能停留在“未来统一”的计划里。
从项目到产品，怎样建立反馈循环？
前线接触客户，发现反复出现的需求，判断哪些是真正共性；产品团队把共性做回共享能力；下一次交付利用新能力处理类似问题，保留客户特有配置和应用逻辑。
这样，客户不是只能依靠工程师现场重造系统，工程师也不必每次重做已经解决的问题。
外包团队同样可以形成这套循环，FDE团队也可能缺少它。不要用岗位名称代替架构和维护方式的检查。
起步团队要不要先搭完整平台？
不必。先接定制、获得收入、积累行业理解是合理的。未弄清需求就搭覆盖所有行业的底层，可能只是提前制造复杂度。
更实际的是在交付中收窄场景，识别稳定重复的问题，再逐步抽出公共能力。客户特有规则留在应用层，不要为了“统一”把每个例外都写进底层。
共享模块需要持续维护，必须给当前项目之外的共性工作留出投入。每次赶交付都往后推，就不会自然产生产品。
项目复盘可以检查哪些可复用成果？
- 下次能直接调用什么，而不是复制后重新修改什么？
- 新问题是否改进了已有公共模块？
- 后续客户仍要重做什么，原因是业务差异还是工程欠账？
- 共用能力是否已有接口、测试和维护责任？
不要求每个新项目都更轻。新行业和新问题本来可能需要投入。真正的目标，是已解决的同类问题不要再次从头解决。
FDE模式的积累不是代码数量，而是让下一次交付少重复多少工作。把这个问题答清楚，比换一个更时髦的头衔有用。
小天说FDE｜程序员，嵌入式软件与 Linux 背景，分享 AI 学习、编程实践与 FDE 转型。
