陪产假救了某美股半导体大厂千万战略规划，年终奖只给6k

CBuild/CBuild-ng构建系统完整发展历程深度分析

导言

本文基于以下多源证据材料，对CBuild/CBuild-ng构建系统的完整发展历程进行深度重构与分析：

上述材料在时间线、核心事实上高度一致，形成完整闭环。以下将逐段还原这一事件的完整过程。

关于姓名与链接的说明： 本文作者真实姓名"Jing Leng"及CBuild-ng公开仓库链接；公司内部人员、部门名称、产品名称均以代称处理。

第一部分：历史背景与技术困境（2021年4月 — 2022年4月）

1.1 入职与学习阶段

2021年4月，Jing Leng加入该公司上海研发中心。根据工作记录，2021年4月至2022年4月期间，其主要工作内容如下：

2021年4月14日 — 4月26日：

• “Learn the concept and framework of CV2x Flexible Linux EVK”
• “Setup the compilation environment and run the basic cases with CV2 board”
• “Understand the feature sets of DSP and lua scripts”
• “Understand other modules: System_Implementation, System_FAQ, Power_Management, DRAM_Optimization, CMA_Driver”

2021年4月27日 — 5月10日：

• “Understand the basic concepts of digital image processing”
• “Test the feature sets of DSP”
• “Understand all Library APIs of Flexible Linux SDK”
• “Summarize Markdown usage”
• “Evaluate documentation platform: Gitbook and Sphinx”

2021年5月10日 — 6月10日：

• “Organize the interactive delivery list in markdown format”
• “Understand image apis”
• “Test the IAV feature sets”
• “Understand IAV APIs”

2021年6月 — 12月：

• 测试UVC功能、移植UVC到不同内核（kernel 4.9/kernel 5.15）
• 修复多个bug（UVC kernel panic、DSP assertion、UDC suspended等）
• 为多个客户提供hotfix
• 学习自动化工具和监控工具
• 开发Thermal RGB fusion功能
• 修复Cppcheck警告
• 添加多UVC支持和UAC1.0/UAC2.0功能
• 添加UVC configurable imgsize支持
• 添加USB3.x传输支持
• 添加UVC library

2022年1月 — 4月：

• 添加Yocto文档
• 发布alpha Yocto SDK
• 添加SVC extension支持（2/3/4-layers SVC-T）
• 添加No_AUD_with_SEI编码支持
• 添加savedefconfig支持
• 添加USB mass storage / USB serial / USB rndis ethernet devices
• 添加UVC YUYV stream支持
• 为多家客户提供定制化功能支持

关键结论： 工作记录显示，2022年5月前的主要工作是学习和功能开发（UVC、IAV、bug修复等），没有任何关于"开发新构建系统"的职务任务。Jing Leng的本职工作围绕UVC功能、IAV驱动、文档维护等展开，而非构建系统的研发。2022年1月至4月期间出现的"Yocto"相关条目——添加Yocto文档、发布alpha Yocto SDK——都是基于现有框架的使用和适配，而非构建系统本身的开发。

1.2 企业内部构建系统的困境

在CBuild出现之前，该公司内部负责构建工具与基础软件设施的团队正面临着严峻的技术挑战。需要特别强调的是：Jing Leng所在部门并非系统部门，系统部门是Amyoc项目的归属部门。Jing Leng属于应用/驱动开发部门，其本职工作与构建系统无直接关联。CBuild的诞生完全是个人技术积累与特殊环境结合的产物，而非系统部门的职务产出。

当时系统部门同时维护着两套构建系统，它们各自存在难以解决的深层问题。

第一套系统：原有构建系统（AmBuild）——正在使用的"巨型单体"

该系统是当时正在被团队使用的现有构建系统。然而，其架构设计与实际开发需求之间已产生了严重裂痕，全局耦合、缺乏灵活性。

这套系统的核心缺陷在于其"单体式"设计：它本质上是一个超大的、单一的Makefile，将所有软件包的编译、链接和安装步骤都耦合在一起。这种架构导致了两个致命问题：

• 难以精确控制： 正如内部沟通中所指出的，“坏处是想精确的控制image包含哪些包非常难”——由于所有逻辑都纠缠在一个巨型Makefile中，开发者无法灵活地选择和组合最终镜像中的软件包。
• 扩展性极差： 增加一个独立的软件包变得异常复杂。任何修改都可能像"蝴蝶效应"一样，影响到系统中看似无关的其他部分，导致维护成本随着项目规模的增长而急剧上升。

第二套系统：Amyoc Yocto兼容项目——开发近9个月的"兼容性枷锁"

与仍在使用的AmBuild并行，系统部门还有一个Amyoc Yocto兼容项目，已经投入了近9个月的开发周期。该项目的目标并非推倒重来，而是要在兼容AmBuild的同时，新增对Yocto Project的支持。

这个目标本身就构成了一个巨大的技术枷锁。为了兼容AmBuild逻辑和习惯，该项目必须在架构上向其靠拢。例如，内部讨论中提到，“编译组装方式和以前的组装方式原理一致，编译习惯和以前一致”。这种对历史的妥协，导致该项目从一开始就背负了沉重的"技术债务"。

更关键的是，Yocto本身是一个极其复杂、学习曲线陡峭的构建框架。将Yocto集成到一个为了兼容旧系统而设计的框架中，无异于"给一辆老爷车加装火箭引擎"——不仅无法发挥Yocto的优势，反而让整个系统变得异常臃肿和难以理解。

直接上级的评论一针见血地指出了困境："Yocto，学习曲线着实陡……小白真的搞不定。"这句话不仅描述了Yocto本身的难度，也暗示了该项目因其复杂性，使得团队内部的其他工程师几乎没有动力去深入理解和维护。

这两套系统——一个功能残缺、难以维护，另一个为了兼容而背上沉重历史包袱、开发近9个月却前途未卜（事实上采用CBuild前，使用Amyoc需要独立维护两套系统：经典编译和Yocto编译）——共同构成了CBuild出现前，企业内部构建系统领域的真实困境。而这一切困境，均发生在系统部门内部，与Jing Leng所在的非系统部门无直接职责关联。

1.3 2022年春季上海封控

2022年3月起，上海进入全域静态管理。据上海市疫情防控指挥部数据显示，3月28日起浦东、浦南及毗邻区域先行实施封控管理，4月1日起浦西地区实施封控管理，全市进入全域静态管理模式。公共交通停运，社区封闭管理，企业生产运营受到严重影响。

Jing Leng的所在小区从3月起即处于封闭状态。妻子正值孕晚期，物资供应紧张，核酸检测成为日常。

关于远程工作的技术事实： 封控期间，员工可以远程VPN进入公司内网，但编译系统都部署在各自的个人电脑上。这意味着，即便有远程访问能力，Jing Leng的实际开发环境仍然是自己的个人电脑——公司内网资源（如代码仓库、服务器、实验室设备等）对CBuild的开发工作并非关键依赖。这一事实对于后续"非职务发明"的法律认定具有重要影响：公司物质技术条件未被实质性使用。

正是在这样的至暗时刻，创新的火种悄然点燃。远离日常通勤的干扰（Jing Leng双程200分钟的通勤时间），他能够专注于根本性问题的思考，这种"逆境创新"的现象值得深入研究。

第二部分：CBuild的诞生（2022年5月）

2.1 首次提交：2022年5月16日

根据CBuild项目的Git提交记录，项目于2022年5月16日19:28完成首次提交（Initial commit）：

commit 4b347d01e44c0d2e4842e2c31952f53181fb5175
Author: Jingleng <jingleng@example.com>
Date: Mon May 16 19:28:39 2022 +0800

Initial commit

首次提交即包含了完整的GPLv2许可证文本（LICENSE文件共339行），明确项目的开源性质和法律约束。同日，Jing Leng完成了以下提交：

• init scripts/kconfig from linux-5.18（5月16日19:59）
• Add path options for kconfig（5月16日20:07）
• Add all compile templates and examples（5月16日20:16）

2.2 通过即时通讯向直接上级分享

2022年5月16日，Jing Leng通过微信向直接上级发送了关键信息：

“我周末在我以前公司的项目基础上扩展了一套完整的编译系统。”

同时发送了压缩包 build_system-20220515.7z（101.8KB），并详细介绍了系统功能：

• “支持源码内编译和分离编译”
• “支持依赖关系串联成一整个系统”
• “kconfig支持指定.config和config.h的路径”
• “我在内核的kconfig基础上加了一些代码设置路径”
• “根据依赖关系不仅自动生成了编译整个系统工程的Makefile，还自动生成了Kconfig文件，通过make menuconfig可以选择哪些编哪些不编”

这段对话的深度法律分析：

2.3 公开仓库发布

2022年5月17日，Jing Leng提供公开仓库链接（https://github.com/lengjingzju/cbuild），附带完整工程说明。

2022年5月18日，Jing Leng测试Yocto兼容性：

“我把cbuild的test-app和test-mod工程在yocto下编译，编译是OK的，所以使用cbuild可以一个makefile兼容源码和编译输出同一目录，源码和编译输出分离，yocto编译共3种模式。”

2.4 封控期间的密集开发

在封控期间（5月16日至6月1日解封前），Jing Leng共完成了约20次提交，包括：

这些提交记录的时间戳全部位于个人时间（周末、工作日晚上），而非正常工作时间。

第三部分：企业内部评估与方案竞争（2022年5月 — 7月）

3.1 方案竞争的开启

2022年5月24日，直接上级提出：

“明天咱们找系统部同事再问问，看看为啥原来构建系统的逻辑这样写（串成串儿，然后再build）？到时候我来开第一枪，你再补枪。”

这段对话揭示了几个关键事实：

• 系统部同事是专职维护AmBuild的系统部门工程师
• AmBuild存在架构缺陷（“串成串儿”）
• 直接上级主动安排Jing Leng"补枪"，说明CBuild是被主动引入作为竞争性替代方案
• Jing Leng并非系统部门成员，而是以"外部挑战者"身份被引入评估

直接上级同时指出现有系统的缺陷：

“坏处是想精确的控制image包含哪些包非常难，另外增加独立的包也比较复杂。”

3.2 高层关注

• 2022年5月26日，直接上级约谈：“有空吗？关于构建系统，简单聊一下。”
• 2022年5月27日，直接上级告知：“有个好消息带给你，有空的话，咱们聊几句。”

标志着CBuild正式进入企业高层的评估视野。

3.3 效率验证

2022年6月2日，直接上级验证了新方案的效率：

“比以前简单多了，比如编译某sensor驱动，以前Makefile加配置文件要填近80行，现在只需要一个Makefile约20行。”
“并且只要填一些名称信息就可以了，依赖编译安装模板化，不用关心安装到哪个目录，依赖哪个目录的头文件。”

80行 → 20行 ——这是CBuild相比现有方案效率提升的可量化证据。

2022年6月3日，直接上级告知高层关注：

“公司高管想下周五了解一下构建系统的进展。 我约个meeting出来，到时候先聊一聊。”

3.4 决定性演示

2022年6月10日，决定性演示日：

• 直接上级：“待会儿能演示的，对吧？”
• Jing Leng：“能的。”
• 直接上级：“建议可以先给大家过一遍这个（https://gitee.com/lengjingzju/cbuild）。基于小系统讲，更加容易理解。就照着MD过一遍。”

演示结束后：

“今天的讲解很不错，给你点赞，明显沉稳很多。”

关键意义： CBuild的公开仓库被直接用于企业内部技术演示，证明CBuild作为独立的公开开源项目是企业技术评估的对象，而非"内部开发的工具"。

3.5 ⭐ 陪产假期间的深度技术对比邮件（完整原文）

2022年6月26日（周日）22:12，正值Jing Leng陪产假期间（妻子于6月下旬分娩，6月26日Jing Leng已正式向公司申请陪产假），在系统部门主管Cao不断挑刺反对的情况下，Jing Leng通过邮件向团队系统阐述了AmBuild/Amyoc与CBuild的原理与差异。邮件主题为"回复: [Amyoc] Discuss the new d…"，全文如下：

发件人： Jing Leng
收件人： Cao（系统部门主管，Amyoc项目负责人）、Wen（直接上级）、Tang（管理层成员）
日期： 2022年6月26日 22:12
主题： 回复: [Amyoc] Discuss the new d…
原文引用（来自邮件截图）： “个人分析当前的两个系统的目前的原理和当前进度”

邮件完整内容（基于截图还原）：

个人分析当前的两个系统的目前的原理和当前进度

Build System A (Jorney) ——即系统部门的AmBuild/Amyoc方案

Build System B (CBuild) ——即Jing Leng独立开发的CBuild方案

回答Cao的两个分析：

“Build System A的Makefile和Yocot的Makefile完全是同一个”
“Build System B，主要的4个部件(AM/build, poky, …)”

邮件的核心技术结论（从表格中提炼）：

邮件的法律与技术意义：

3.6 ⭐ 正式采纳会议：2022年6月30日

2022年6月30日，在陪产假期间、孩子黄疸住院的情况下，Jing Leng通过远程方式参加了决定CBuild命运的正式会议。

关键证据（来自聊天记录）：

2022年6月27日 10:11-10:42：

直接上级：“周四/周五下午有可能抽个空参加一下Amyoc的讨论吗？”
直接上级：“你酌情考虑哈，以照顾老婆孩子为重。不能参加的话，到时候就我顶一下。”
Jing Leng：“还不清楚，还在办入院。”
直接上级：“好的，先暂定周四吧。到时候你有空就参加，没空就算了。先以老婆孩子为重，dude~~”

2022年6月30日 09:45：

直接上级：“Hi Dude，下午的AmBuild讨论是2:30开始。有空就参加，没有就算了哈。”

2022年6月30日 10:25-10:58：

Jing Leng：“还不知道，宝宝黄疸有点高，转到了儿科特护病房观察。”
直接上级：“好的，黄疸都需要观察的。只要慢慢消退就没事。但观察是必须的，好像。我当时小孩子也是这样。不要太担心哈。”
Jing Leng：“在等检查结果。”
直接上级：“嗯，不要太担心。问题不大；当时我小孩子也是黄疸有点高，刚出生好像都会这样。一般很多会消退。”
Jing Leng：“我发crr那边要么做事水平差，要么做人太功利。”（注：crr即Cao）

关键意义：

3.7 工作记录的正式记录

根据工作记录，2022年5月8日—26日期间：

“Yocto and AmBuild study ( https://github.com/lengjingzju/cbuild )”

——明确将CBuild作为个人项目记录于工作日志。

2022年6月10日—23日：

“New build system demo” 及 “Export new build system demo to amyoc_v2 branch”

——CBuild被正式引入企业代码库。这与6月30日会议决议的执行完全一致。

工作记录还详细记载了2022年6月10日至23日期间"Update new build system demo"的具体内容，包括：

第四部分：家庭责任与特殊时期的坚持（2022年6月 — 7月）

4.1 陪产假的确立

2022年6月下旬，Jing Leng的家庭迎来新生命。公司确认了10天陪产假：

2022年6月26日 20:59：

Jing Leng：“Hi 明哥，我老婆明天就住院了。”
直接上级：“好的，好好照顾老婆孩子。请假的话，发一份mail出来给Jennifer，把Tang老板和我cc上，就好了。公司这边规定的假期是10天（包含周末）。”
Jing Leng：“发了，发给了孔主任。”
直接上级：“好的。”

4.2 孩子健康问题的关切与陪产假期间的关键技术工作

2022年6月27日 10:11-10:42：

直接上级：“Hi Dude，周四/周五下午有可能抽个空参加一下Amyoc的讨论吗？”
直接上级：“你酌情考虑哈，以照顾老婆孩子为重。不能参加的话，到时候就我顶一下。”
Jing Leng：“还不清楚，还在办入院。”
直接上级：“好的，先暂定周四吧。到时候你有空就参加，没空就算了。先以老婆孩子为重，dude~~”

2022年6月30日 09:45-10:58：

直接上级：“Hi Dude，下午的AmBuild讨论是2:30开始。有空就参加，没有就算了哈。”
Jing Leng：“还不知道，宝宝黄疸有点高，转到了儿科特护病房观察。”
直接上级：“好的，黄疸都需要观察的。只要慢慢消退就没事。但观察是必须的，好像。我当时小孩子也是这样。不要太担心哈。”
Jing Leng：“在等检查结果。”
直接上级：“嗯，不要太担心。问题不大；当时我小孩子也是黄疸有点高，刚出生好像都会这样。一般很多会消退。”
Jing Leng：“我发现crr那边要么做事水平差，要么做人太功利。”

4.3 假期期间的技术支持

尽管处于陪产假期间，Jing Leng依然在回应技术问题：

• Jing Leng（2022年6月30日）：“yocto无法在NFS和CIFS文件系统上编译”
• 直接上级（2022年7月4日）：“找到原因了。”

4.4 非职务发明的关键证据

这段陪产假记录在法律上具有重大意义：

• 明确的非工作时间： 公司系统确认了Jing Leng的陪产假，这是法律意义上的非工作时间
• 陪产假期间的关键技术贡献： 6月26日的对比邮件、6月30日的采纳会议，均发生在陪产假期间
• 孩子健康危机中的坚持： 6月30日当天，孩子黄疸转入特护病房，Jing Leng在等待检查结果中依然参与会议
• 非系统部门身份： 陪产假期间对系统部门构建系统的技术指导，进一步证明其贡献超出本职范围

2023年3月薪酬不满谈话中，Jing Leng所说的"去年算是全力以赴了，做出了开创性的成果"——其背景正是在这段陪产假期间依然坚持技术对比论证、参加关键会议的事实。

第五部分：技术推广与工业级验证（2022年7月 — 12月）

5.1 团队推广

2022年7月12日，直接上级安排：

“这周五要给其他team推广你的构建系统，training的东西已经在准备好了吗？……到时候你尽量过来哈，露露脸，让各个team认识认识你。”

2022年7月13日，Jing Leng汇报Yocto进展：

“现在yocto build可以配置需要编译哪些包，编译方法也和经典编译一样’make deps;make menuconfig;make’了。”

5.2 技术权威的建立

2022年7月26日，直接上级评价：

“看到你的改动了，cool~”
“Yocto曲线确实有点陡……但这条路，基本只能靠你了。其它engineer，基本不会有动力。”

这一评价表明Jing Leng已成为企业内部公认的Yocto/构建系统技术权威，尽管他并非系统部门成员。

5.3 工业级应用验证

2022年9月28日，Jing Leng汇报ROS2技术突破：

“我ros2编出来了，但是固件太大烧不进去。昨天搞到了12点多。”

直接上级：“Dude, I knew you could make it.”

Jing Leng：“编译错误吐出了4M的log，分析了半天，最后原因是内存不够。”

"搞到了12点多"表明Jing Leng在正常工作时间之外投入了大量个人精力。至此，CBuild已服务于"多个系列几十款芯片和上百个方案"的生产环境。

5.4 持续的功能迭代（2022年8月—12月）

根据Git提交记录，2022年下半年CBuild进入了密集的功能完善期：

2022年12月31日，CBuild v2.0.0发布，许可证从GPLv2变更为MIT。

Git记录显示许可证变更的具体diff：

• 删除了完整的GPLv2许可证文本（339行）
• 新增了MIT License文本：“MIT License, Copyright © 2022 Jing Leng”

第六部分：开源控制与GPL合规冲突（2023年1月18日）——核心转折点

6.1 直接上级确认CBuild的技术起源

“这个是先有cbuild，然后才有我们的build，不然就是系统部同事的那一套了，估计现在还掉在坑里爬不起来。这个不用说，肯定的。要不然我认为SDK 4.0出不来。”

分析： 企业内部明确承认CBuild是企业SDK 4.0的核心技术基础，且是先有CBuild（开源项目），后有企业build（企业分叉）。这完全否定了"企业自主研发"的说法。同时再次确认CBuild与系统部门原有方案的替代关系。

6.2 直接上级确认Jing Leng的核心贡献

“[2022 Code Review] Just for fun! 看看这个邮件，22年你的coding量，排第一。”
“alpha估计都出不来，没有模板就像同事B他们移植的包一样，半个月都没有独自搞定。”
“you know it! Anyway, you really made it, dude~~”

分析： 直接上级不仅承认CBuild的起源，还确认了Jing Leng个人的技术贡献。"coding量排第一"从侧面佐证了CBuild的开发和移植工作主要由Jing Leng完成，且远超系统部门专职工程师的产出。

2022年度代码提交统计数据（来自公司内部邮件）：

关键发现： Jing Leng以841次提交（8.60%）位居全公司第一，比第4名系统部门主管Cao 413次，4.22%）高出一倍以上。这客观证明了Jing Leng在2022年的技术产出远超系统部门专职工程师。

6.3 Jing Leng说明许可证

“cbuild1.0是gpl协议，因为核心是围绕kconfig和makefile组织，2.0改成了mit（kconfig还是gpl）。”

分析： Jing Leng明确声明CBuild 1.0采用GPLv2。这是对CBuild许可证状态的直接确认，也是后续所有法律分析的事实基础。

6.4 直接上级要求停止公开更新

“哦，对了；cbuild越来越成熟，后面尽量不要更新到公开仓库哈。”
“公司对这一块管理还是比较严的；免得有不必要的麻烦。切记哈~~尽管你是绝对的第一功臣。”

Jing Leng：“agree~~”

直接上级：“那也不要。”

分析：

• “尽量不要更新到公开仓库”——切断开源传播渠道
• “公司对这一块管理还是比较严的”——企业已知开源管理政策的存在和严格性
• “免得有不必要的麻烦”——这里的"麻烦"指的只能是GPLv2的开源义务（公开源码、保留署名）
• “尽管你是绝对的第一功臣”——在要求停止开源的同时，对贡献者的承认形成了极其刺眼的对比

6.5 直接上级解释企业开源政策

“我们自己的code，不要公开出去（就算是第一作者，也不行）。”
“之前美国一个离职同事，因为此类事情，被发律师函了。挺牛的一个斯坦福博士。”
“咱们公司，庙小，应该不会投入这个。”

分析：

• “就算是第一作者，也不行”——揭示了企业的 "只进不出"策略：可以使用开源代码，但不得公开自己的代码
• “被发律师函了”——企业有GPL违规被发律师函的先例，这是加重情节中的"再犯风险"
• "庙小"的借口暴露了真实心态：将开源合规视为成本负担而非法律义务

6.6 "主观明知"的完整证据链

第七部分：薪酬不满与价值主张（2023年3月）

7.1 薪酬谈话

2023年3月18日，Jing Leng表达薪酬不满：

“去年年初涨了1154，不到5%，去年算是全力以赴了，做出了开创性的成果也没有什么区别（毕竟cbuild早期都是我自己的时间开发的，而系统部同事是专职）。”

直接上级回应：

“去年年中走了一波，后面安排core member涨薪，你和同事Q也是第一梯队……perf整个team就两个A，你是其中一个。”
“你如果相信我的人品，再观察一两年。”
“唯一的遗憾，就是年底这一波。”

7.2 "非职务发明"的当事人陈述

“cbuild早期都是我自己的时间开发的，而系统部同事是专职”——这是职务发明认定中的直接当事人证言：

• Jing Leng明确区分了个人项目（CBuild）与系统部门专职工程师的项目（AmBuild）
• “自己的时间开发"vs"专职”——形成鲜明对比
• “开创性的成果"vs"2023年没有涨薪”——贡献与回报严重不成比例
• 再次强调非系统部门身份：系统部同事是"专职"，而Jing Leng是"自己的时间"

7.3 绩效系统的承认

直接上级确认"perf整个team就两个A，你是其中一个"——企业绩效系统承认了Jing Leng的杰出贡献，但薪酬激励未能匹配。

7.4 Jing Leng的实际回报

• 2023年年初，该公司没有给Jing Leng升职调薪，且给Jing Leng的年终奖仅为6000元
• Jing Leng提出自己的需求"希望薪资能完美保证3倍社平（按当时上海每年10%的社平增加保证第5年也满足，5年3倍社平落户）"（当时Jing Leng岳母白血病也需要钱，孩子出生要钱，买房要钱），提出要走
• 该公司才在2023年4月起加薪3000多元，并授予几百股限制性股票（6月授权，4年解禁）
• Jing Leng 2021年入职时该公司股票约130美元，2023年那时只剩50多美元
• 2023年Jing Leng在做出突出贡献的情况下，实际待遇还下降了很多

第八部分：离职信中的自我总结（2023年8月17日）

8.1 离职信原文

2023年8月17日，Jing Leng正式提交离职申请。以下为离职信关键内容：

收件人： Wen（直接上级）
抄送： Tang（管理层）、Sun（管理层）、Chen（HR）、Kong（HR）

"Hi Ming，

由于上海生活压力太大和寻求个人发展的原因，个人特此提出离职。

回顾在AM的时间，个人所做的主要贡献是两个：CBuild 编译系统(Cooper SDK, Amyoc)、USB Camera(UVC/UAC/UDC)。

<1> CBuild 编译系统(Cooper SDK, Amyoc)

编译系统最初是交给 Cao 团队的任务，此项目从2021年下半年开始开发，进行了至少7个月，到2022年6月底，进展并不是很理想，还只是一个能进 shell 的 demo。

而个人有更好的想法，且有5年以上的SDK开发经验（其中3年是主管2个SDK）。通过梳理以前用过的编译脚本，用业余时间完全重新独立设计并开发了 CBuild 编译系统，通过更好的设计框架完美支持了 Cooper SDK 的发展需求，他有如下特点：

通过个人的 CBuild 编译系统，节省了 Cooper SDK 至少 6 个月的开发时间，减少 Cooper SDK 至少 70% 的迁移、维护、使用成本。为了加速 Cooper SDK 的开发，2022 年我基本全年无休（周末无休、陪产假休了5天，婚假没休），以一己之力设计并完成了 Cooper SDK 的框架，处理了 Cooper SDK 全部的疑难杂症。当然，非常感谢各位领导对 CBuild 编译系统和我的工作的信任和支持。"

8.2 离职信的法律与事实意义

8.3 Linux内核主线贡献

离职信中还附上了Jing Leng在Linux内核主线上的贡献记录：

在 Linux 官方主线上：

关键发现： Jing Leng在Linux内核主线上的提交数量（4个）超过系统部门主管Cao（1个），进一步证明了其在基础软件领域的技术能力远超系统部门专职人员。

第九部分：CBuild-ng的独立发展（2023年3月 — 2025年8月）

9.1 项目的启动

面对企业的开源控制要求，Jing Leng于2023年3月5日启动了CBuild-ng项目（Initial commit），标志着原项目思想的独立演进版本的诞生。

CBuild-ng是一个高性能编译系统，由中国工程师Jing Leng开发，专为构建嵌入式Linux系统和复杂软件栈而设计。其核心仅4000行代码（目前7000行），以极简设计和灵活兼容性为特色，结合了传统编译和Yocto模式的优势。

CBuild-ng与CBuild的最大区别： Classic Build引入了WORKDIR的概念，每个包在自己的WORKDIR下的特定目录中准备依赖、编译和安装，包与包之间以及包与sysroot之间的依赖关系由自动生成的顶层Makefile处理。

9.2 版本演进

9.3 技术架构深度解析

9.3.1 架构哲学：从"单体巨构"到"联邦式微内核"

传统构建系统的核心困境根植于"全局耦合"的架构范式。CBuild-ng提出的联邦式微内核架构对此进行了深度重构：

9.3.2 模块联邦

CBuild-ng最具突破性的创新在于对应用构建范式的重新定义：

9.3.3 IMake模板工具

CBuild-ng使用IMake（Include Makefile / I have the Makefile）而不是发明新的描述语言降低编译的难度。

统一的多范式构建框架：

• 多目标协同支持：单个Makefile支持生成多个库、可执行文件或驱动模块
• 混合语言编译能力：无缝支持C、C++、汇编等语言的混合编译
• 智能依赖分析：自动头文件依赖追踪，支持源文件级细粒度控制
• 灵活目录架构：支持输出目录（O=）、安装目录（DESTDIR=）、依赖目录（DEPDIR=）的灵活配置

丰富高效的Makefile模板：

• 环境设置模板（inc.env.mk）
• 应用开发模板（inc.app.mk）
• 内核驱动模板（inc.mod.mk）
• 标准化安装模板（inc.ins.mk）
• 配置管理模板（inc.conf.mk）

9.3.4 双模式驱动架构

9.3.5 缓存加速创新

多级镜像体系：

• 国内镜像网络：可集成主流开源镜像源
• 企业私有镜像：支持内网镜像服务，满足隔离环境需求
• 智能路由选择：自动选择最优下载源

分布式缓存生态：

• 本地缓存加速：基于内容哈希的精准验证机制
• 团队协作支持：支持局域网缓存共享
• 云端同步能力：“一次构建，多处使用”

9.3.6 应用分发创新

• 自包含部署：将应用及其依赖打包为独立单元（cpk格式）
• 跨环境兼容：通过修改rpath和ld.so路径实现环境适应性
• 离线部署：完整支持断网环境下的应用分发

9.4 性能优势

9.5 构建系统对比表（IMake vs 主流工具）

第十部分：CES 2024的"革命性"叙事（2024年1月）

10.1 官方发布

2024年1月10日，该公司在CES 2024上发布了新一代开发者平台（Cooper）。

该公司总裁兼CEO表示：

“Developers creating products based on the latest AI technologies are faced with the daunting challenge of integrating multiple software tools while deploying on diverse hardware platforms. Our new unified, robust and scalable Developer Platform allows designers to easily take full advantage of our SoCs’ industry-leading AI performance per watt, via intuitive and comprehensive tools that abstract the hardware and enable them to focus on product innovation across multiple markets and applications.”

10.2 平台的技术构成

根据官方新闻稿，该平台由两大核心部分组成：

硬件层：

• 高能效AI SoC、模块化系统（SoM）和参考开发套件
• 预置软件平台对应的软件

软件平台（Cooper Foundry）：

• Core核心组件： 包含基于Linux的操作系统、编译器和SDK
• Foundation AI应用组件： 包含Model Garden——一系列开源的、已调优的预训练神经网络模型
• Vision视觉感知组件： 包含多模态传感器（摄像头、雷达、激光雷达）的数据处理和融合模块
• UX应用交互组件： 基于自研操作系统的用户界面

10.3 Core核心组件的官方描述

“Core, which encompasses Linux-based OS, compilers and SDKs. Building on the company’s existing comprehensive suite of development tools, Core also introduces a framework for seamless integration with widely-used open-source software tools.”

中文报道进一步确认：

“Core核心组件包含基于Linux的操作系统、编译器和SDK。基于该公司现有的开发工具包，Core针对广泛使用的开源软件工具，引入了开发框架，方便无缝集成。”

10.4 官方PPT中的技术定位

根据公司内部PPT（2023年4月），该平台被定位为：

技术演进的第三代：

• Gen-1（2008-2018）：独立SDK，每款芯片独立
• Gen-2（2018-2023）：统一SDK，每个芯片系列统一
• Gen-3（2023起）：通用SDK，所有芯片系列统一

核心技术声明的证据：

• “Customers who work with AM build (v1) will be capable of switching to Cooper with minimal effort (modify the makefile).”
• “Support clear dependency chain for every build target in Yocto.”
• “Save huge maintenance efforts for AM internal teams.”

关键发现： 官方PPT中明确提到"AM build (v1) → Cooper with minimal effort (modify the makefile)"，印证了CBuild作为升级路径的核心作用。

10.5 "革命性"的媒体描述

多家媒体将该平台描述为"革命性的技术"：

“在2024年的国际消费电子展（CES）上，该公司发布了一项革命性的技术——业界领先的开发者平台。”

该平台集成了"TensorFlow、Docker、PyTorch、Yocto和ROS2"等开源工具。

10.6 技术继承性的深度分析

虽然该平台的新闻稿并未直接提及"CBuild"，但通过分析其技术构成和项目背景，可以发现两者之间存在深层的承继关系：

10.7 "革命性"背后的合规反思

CBuild项目从诞生之初就采用GPLv2开源协议，其核心价值在于通过开源实现技术共享。

当一项基于开源项目（CBuild）改进而来的技术，被企业以"革命性的技术"进行商业宣传，而该项目早期的开源贡献者Jing Leng却未被提及，且企业曾明确要求其停止向公开仓库提交代码时，这种叙事构成了一个尖锐的对比。

第十一部分：法律分析

11.1 关于CBuild的"非职务发明"属性

根据《专利法》第六条及其实施细则第十二条，职务发明的判定标准包括"执行本单位任务"和"主要利用本单位物质技术条件"。CBuild项目在这两方面的证据均指向"非职务发明"。尤其重要的是，Jing Leng不属于系统部门，构建系统开发完全超出其本职范围。

11.2 关于GPLv2合规性

违反的具体条款：

"主观明知"证据链：

• 直接上级知道GPL协议（“IAV/sensor driver也都是GPL”）
• 直接上级知道CBuild是GPL协议（“cbuild1.0是gpl协议”）
• 直接上级知道违规的后果（“被发律师函了”）
• 直接上级明确要求规避（“尽量不要更新到公开仓库”“免得麻烦”）

11.3 关于"创新洗白"

“创新洗白”（Innovation Laundering）的三层证据：

11.4 司法先例的警示

根据最高人民法院的相关判例，违反GPLv2协议的行为可能导致严重的法律后果：

• OfficeTen案： 某科技公司是涉案网关产品系统软件的开发者，该软件是在某开源软件（受GPLv2协议约束）基础上改进形成的。一审法院判决被告立即停止侵害、消除影响，共同赔偿损失及维权合理开支共计50万元。苏州中院遵循比例原则，着重考虑二次开发部分在整体软件作品中所占比例，合理地剥离已开源部分，仅计算有独创性表达的开发部分。
• 法国Orange案： 法国电信运营商Orange因违反GPLv2规定，被法院判决赔偿65万欧元（约合人民币504万元）。
• 最高人民法院判例： 在（2021）最高法知民终51号案中，对GPLv2协议下二次开发者的权利边界进行了界定。

第十二部分：工作记录中的关键细节补充

12.1 2022年6月—12月企业内构建系统开发记录

工作记录详细记载了CBuild被采纳后在企业内部的应用过程：

2022年6月24日—7月7日：

• menuconfig菜单支持可设置级数的层级菜单
• 自动收集包下的参数配置文件生成总配置菜单
• 编译模板放在各个包目录下
• 自动更新包目录下编译模板
• mk.deps和Makefile合并成一个文件
• 同时支持在不同目录编译

2022年7月7日—7月21日：

• 分离视频模块的头文件和模块
• 调整prebuild结构
• 修改Yocto build与经典编译保持一致
• 更新Yocto项目版本
• 使用sysroot作为安装目录

2022年8月—9月：

• 配置处理优化
• 支持多级目录数据安装
• Kconfig层级错误修复
• 支持在子文件夹中查找包
• 依赖图生成

2022年10月—12月：

• 模板更新至v1.2.0/v2.0.0
• 网络包下载支持
• 构建缓存支持
• ROS2构建支持
• 多架构支持（CV2x/CV5x/CV3x）

12.2 2023年企业内持续开发记录

2023年1月—3月：

• 添加30+源码构建OSS包（bzip2, xz, zlib, cjson, dbus, expat, libnl, libpcap, libxml2, openssl, wpa-supplicant, alsa-lib, alsa-utils, curl, json-c, libpng, libjpeg-turbo, icu, harfbuzz, freetype, libffi, pcre2, glib, protobuf, x264, x265等）
• 支持构建交叉编译工具链和gdb
• 添加Systemd和NetworkManager
• 支持多芯片平台（CV5x, CV7x, CV3x）

2023年3月—4月：

• 从cbuild-ng移植inc.ins.mk
• 从cbuild-ng移植进度条功能
• 更新构建模板至v2.2.0
• 性能测试

2023年5月—8月：

• CV5x EVK在新分支上启动
• USB Gadget功能移植
• 编译缓存机制优化
• 支持QT5和QT6构建
• Cooper SDK开发

关键发现： 工作记录中多次出现"Port xxx from cbuild-ng"的条目，证明企业内部的构建系统持续从CBuild-ng开源项目中获取功能更新，进一步证实了技术依赖关系。

第十三部分：完整时间线总结

2021年

• 4月： Jing Leng入职该公司，开始学习SDK
• 下半年： 系统部门Cao团队启动Amyoc项目

2022年

• 3月： 上海开始封控，小区封闭
• 5月16日： CBuild首次提交（GPLv2），同日通过微信向直接上级分享
• 5月17日： 公开仓库发布（https://github.com/lengjingzju/cbuild）
• 5月24日： 直接上级提议挑战系统部门方案，“我来开第一枪，你再补枪”
• 5月26日： 直接上级约谈
• 5月27日： 直接上级告知"好消息"
• 6月2日： 效率验证：80行→20行
• 6月3日： “公司高管想下周五了解进展”
• 6月10日： 正式演示，使用公开仓库讲解
• 6月26日： 陪产假开始；妻子分娩；同日22:12发送完整技术对比邮件"回复: [Amyoc] Discuss the new d…"
• 6月27日： 孩子住院，讨论周四会议安排
• ⭐ 6月30日： 孩子黄疸转入特护病房，远程参加正式采纳会议，CBuild被正式决定为新一代SDK核心
• 7月12日： “给其他team推广”
• 7月26日： 技术权威确立
• 9月28日： ROS2编译成功，“搞到了12点多”
• 12月31日： CBuild v2.0.0发布，许可证变更为MIT

2023年

• 1月18日： 核心对话——“先有cbuild，才有我们的build”“尽量不要更新到公开仓库”“就算是第一作者，也不行”
• 3月5日： CBuild-ng启动（https://github.com/lengjingzju/cbuild-ng）
• 3月18日： 薪酬不满谈话，“cbuild早期都是我自己的时间开发的，而系统部同事是专职”
• 4月12日： CBuild-ng v0.0.1发布
• 8月17日： Jing Leng正式提交离职信，明确写明Cao团队7个月失败、自己业余时间独立完成CBuild
• 12月28日： CBuild-ng v0.0.9发布

2024年

• 1月10日： 该公司CES 2024发布新平台，称"革命性技术"
• 6月14日： CBuild-ng v0.1.0发布

2025年

• 5月16日： CBuild-ng v1.0.0发布（项目三周年）
• 8月11日： 最新提交，适配多种Linux发行版

第十四部分：结论

14.1 对个人开发者的启示

14.2 对科技企业的警示

14.3 对开源生态的思考

14.4 对中国技术创新的启示

最终，CBuild-ng的持续发展证明了：真正的创新无法被掩盖，其价值终将在开放与共享中得到最大的释放。

附录A：Git提交记录关键节点

CBuild项目（https://github.com/lengjingzju/cbuild）

CBuild-ng项目（https://github.com/lengjingzju/cbuild-ng）

附录B：聊天记录关键对话索引

附录C：年度代码提交统计（2022年）

根据公司内部邮件（2023年1月18日）：

总提交数： 9779次（vs 2021年6659次）

前五名提交者：

关键发现： Jing Leng以841次提交、8.60%占比高居第一，比第二名高出201次（31.4%），比系统部门主管Cao（413次）高出一倍以上。这客观证明了2022年Jing Leng的技术产出远超系统部门专职人员。

附录D：公开报道关键引用

本文档基于多源证据材料的交叉验证编制，所有引用均可溯源至原始记录。作者姓名Jing Leng及公开仓库链接已恢复；公司名称、内部人员姓名、部门名称、产品名称均以代称处理。