上午坐在上班的班车上，看到了世界杯开幕的消息，刷抖音也看到了很多熟悉的博主都去了世界杯。仿佛这个世界把和我一样的牛马与有钱有时间的人给割裂开了，然后就和gpt开始聊这件事：

世界杯

这次对话的核心，其实是从世界杯开幕聊到了资本、阶层、普通人的处境，以及我们还能不能用更丰富的方式理解世界。

一开始我们从经济学看世界杯：
它是一场全球注意力和稀缺资源的集中竞价。开幕式、球票、酒店、机票、转播权、赞助，背后都是供需关系。因为世界杯四年一次，开幕式只有一次，现场座位有限，但全球需求巨大，所以价格被推高。最大的金钱赢家往往是 FIFA、转播商、赞助商、酒店航空、票务平台和核心商圈；本地居民则可能承担涨价、拥堵、秩序管制等成本。

然后你说，你在上班班车上刷到世界杯开幕，看到很多熟悉的博主都去了现场，突然觉得世界上有钱人好多，而自己和千千万万普通人还在上班、上学、考研，世界杯好像只能隔着屏幕看。
我们聊到，这种感受不是单纯羡慕，而是一种强烈的割裂感：有些人像是生活在另一个服务器，而普通人更多是在日常压力里被生活推着走。世界杯刺激到你的，不只是“想看球”，而是你不甘心自己永远只能当旁观者。

接着我们回到经济，讨论转播商、赞助商、酒店航空这些是不是“资本”。
结论是：它们当然可以理解为资本，但资本不是单纯骂人的词，而是一套用钱、资源、渠道、品牌和注意力来赚更多钱的系统。世界杯不是简单的“骗局”，因为球迷确实能获得快乐、记忆和情绪价值；但它也是资本主义制造欲望的典型案例：把足球、热爱、国家荣誉、青春、现场感包装成稀缺商品，让不同阶层用不同价格参与同一场狂欢。

我们还聊到这些资本拿到钱后会做什么：
它们会分利润，回报股东和投资人；会继续买转播权、签赞助、扩张酒店、投放广告；会扩大资源垄断和议价能力；也会继续塑造人的消费欲望。简单说就是：球迷付钱，博主造梦，平台分发，品牌曝光，资本回收利润，然后再制造下一轮更贵的梦。

之后你问，这个循环会不会一直下去。
我们说，资本循环会持续，但不会以同一种形式永远持续。它的基本逻辑是：人有欲望，企业把欲望商品化，人们消费，资本赚钱，再制造新的欲望。这个循环很强大，因为人的欲望不会消失，只会换形式。但它也会周期性出问题，因为财富容易集中、体验越来越贵、注意力成为新的生产资料，普通人更多出售时间，而资本和流量拥有者获得更大收益。

如果循环继续，可能会出现：
财富进一步集中；顶级体验越来越阶层化；普通人只能在线上围观更多高端体验；注意力经济更加深入生活。
如果循环被打破，可能来自技术革命、政治干预、反垄断、税收福利、人口变化、社会运动，或者新的生产方式。但历史经验是：资本很少彻底消失，它更常见的是换一层外壳，重新组织新的赢家。

最后你问，能不能从其他角度看世界杯。
我们就跳出了单纯资本视角，重新看它的多重意义：

世界杯也是一种人类共同仪式，让全世界短暂关注同一件事；
也是普通人的情绪出口，让日常压力有地方释放；
也是国家叙事和城市形象的展示；
也是个体命运的压缩剧场，有人一战成名，有人遗憾告别；
也是全球化的缩影，让你坐在班车上也能看到世界另一端的狂欢；
更是一次人生坐标的提醒：你看到的不只是世界杯，而是你对更大世界、更多选择权、更自由人生的渴望。

这次对话最后可以浓缩成一句话：

世界杯既是资本机器，也是人类节日；它让我们看到金钱如何组织世界，也让我们看到普通人为什么仍然需要热爱、远方和共同的心跳。

上午正在一边和gpt聊世界杯一边问ngmust的语义，mentor过来问我lite做得咋样了。汇报了一下之后mentor告诉我接下来的方向。还说12号还有时间，后续先做一个基础版本先让他们用上。

todo：

  • 添加缺陷用户可以自己选择
  • 各个模型的参数要和原webai一样，并且全部都能生效（模型全部跑通之后的后话）
  • 开始训练的时候要填入模型名字，训练出来的模型要有版本管理
  • 推理界面不要让用户填模型路径，要直接列出当前训出来的模型名字/版本
  • 推理参数也要和原webai一样
  • 模型训练推理出来之后需要有一个混淆矩阵（可以靠后）
  • 日志回传

下午在和gpt聊未来，因为过长，就把聊天记录放在了最下面

今天下午的周会又让我混到了，虽然啥也没说，但是旁听了一下。会上我们部门的监事（maybe）带了蛋糕给一个同事因为他今天生日，我们在会议室点了蜡烛，吃了蛋糕，还拍了照片~

下午leader可能还会给我拉一个会，让我展示一下lite的成果，周会上mentor只是放了一张截图。

今天下午读阮一峰的周刊的时候看到的：46种常用的编程模式应该会有帮助，mark一下

下午开完会之后几乎就没咋work，一直在看周刊和刷L站~

在问gpt我们公司的模型文件后缀为啥是fsnb的时候gpt给我搜出来了这个：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
作者提出了一个改进版 YOLOv8，叫 FSNB_YOLOv8。

它不是一个全新的模型，而是：

YOLOv8
  + 模糊搜索数据增强
  + FasterNet
  + SPD-Conv
  + BiFPN
  + NWD Loss
= FSNB_YOLOv8

这里你要注意：FSNB 是论文模型名字，不是你们公司那个 .fsnb 模型文件后缀。
这两个东西大概率没关系。

下午在逛L站的时候发现了有佬推荐了一门斯坦福大学的关于Ai时代下developer软件开发范式的课程，打算之后周末有空看看，之后还让GPT生成了定时任务，每周五下午两点去检索这些优质的资源。nice~

附图片：


下班啦~~~
必须狠狠薅公司的羊毛

今日工作内容

  1. 修复实例分割训练导出契约——ngmust_tags 错误导致 val 为空
    Date: 2026-06-12
    Task: 修复实例分割训练导出契约——ngmust_tags 错误导致 val 为空

Summary

根因分析：_inject_webai_extension_fields() 将全部标注填入 ngmust_tags，导致下游 get_data_from_coco() 将全部样本误判为 NGmust，强制直达 train/，val/ 为空。修复：ngmust_tags 强制置空；device_task_bundle 增加 split_val_threshold 缺失可观测性；manifest JSON 补全阈值参数；测试更新。新增 coco-export-contract.md 和 catalog-manifests.md spec。

  1. mask 保存性能优化——跳过 PNG base64 往返
    Date: 2026-06-12

Summary

优化标注页保存性能：mask canvas 直接走 raw ImageData 进 RLE 编码，砍掉 PNG base64 编解码完整往返。改动 maskObjectManager(exportAllRaw)、cvatAnnotationFormat(优先 _rawMaskData)、EditorCanvas(prepareMaskData)。更新 editor-architecture.md spec。

  1. 检测类别颜色改为用户自选，标注画笔颜色与数据页配置统一
    Date: 2026-06-12
    Task: 检测类别颜色改为用户自选——结构化类别配置 + 标注画笔颜色统一

Summary

前后端类别从 string[] 升级为 {name, color}[]，Data 页从 Textarea 重构为列表式颜色选择器，编辑器 core 层新增 setClassColors 替换 4 处硬编码调色板，cvatAnnotationFormat 序列化链路使用用户配置颜色。后端 50 测试全过，前端构建通过。

下阶段计划

  1. 各个模型的参数和webai对齐
  2. 对训练出来的模型进行版本管理

和gpt的聊天记录：

这次我们主要围绕一个核心问题在聊：

AI 时代，作为一个计算机学生/实习生，我到底还剩什么价值？

可以总结成几条主线。

1. 你对实习的困惑

你现在实习做的是：把公司原来的缺陷识别模型标注、推理、训练平台做 lite 化 / 轻量化。

你觉得这个活：

  • 没接触到特别硬核的算法；
  • 更多是在让 AI 帮你写代码；
  • 自己只是做一点判断和决策；
  • 换一个计算机学生来也能做；
  • 之前 iOS App 也是类似，什么都碰了一点，但感觉没沉淀出特别硬的技术。

我给你的判断是：

你的感觉一半对，一半不对。

对的是：如果只是改页面、接接口、删功能，那确实没有太高壁垒。
不对的是：这件事本身可以被抽象成一个很有价值的工程项目。

它不只是“做 lite 化”，而是：

参与工业缺陷检测平台轻量化改造，围绕数据标注、样本集管理、训练任务、推理任务、模型结果管理等核心链路，进行模块裁剪、流程重构和系统交付。

真正有价值的不是“你写了多少代码”，而是你能不能讲清楚：

  • 原平台有什么问题；
  • 为什么要轻量化；
  • 哪些功能保留，哪些裁剪；
  • 数据怎么组织；
  • 训练/推理任务怎么流转；
  • 异常怎么处理；
  • 文件并发写入怎么保证一致性；
  • 最后平台如何完成“标注 → 训练 → 推理 → 查看结果”的闭环。

2. AI 时代，单点技术的重要性下降，但系统能力更重要

我们讨论到：

在 AI 时代，技术是不是反而不那么重要，重要的是系统能力和业务能力？

我的修正是：

不是技术不重要，而是“只会写代码”的技术没以前那么值钱了。

以前你会某个语言、某个框架，就能形成一定优势。
现在 AI 可以快速生成代码，所以真正拉开差距的是：

1
2
3
4
5
业务理解
系统抽象
工程实现
结果交付
问题负责

你不能只把自己定位成：

我会 C++，我能写代码。

而要逐渐转成：

我能理解一个业务问题，把它抽象成系统，并借助 AI 把它稳定交付出来。

3. 当前实习里的“业务能力”如何迁移

你问了一个很关键的问题：

比如“标注数据如何组织成统一格式”这种能力，怎么迁移到其他工作？

答案是：不要把它理解成“工业缺陷检测的业务经验”，而要抽象成通用能力。

比如：

1
2
3
4
5
6
7
8
9
10
缺陷图片        → 文件资源管理
标注框          → 结构化元数据
缺陷类别        → 标签体系设计
样本集          → 数据集合 / 业务资源包
训练任务        → 异步任务系统
推理任务        → AI 服务调用任务
模型文件        → 版本化产物
训练日志        → 可观测性
标注格式转换    → 数据标准化
平台 lite 化    → 老系统裁剪 / 流程重构

所以你真正能迁移的不是“我懂缺陷检测”，而是：

我懂如何把混乱的数据、流程、任务、模型能力整理成一个可用、可维护、可交付的平台系统。

这可以迁移到后端开发、AI 应用工程、数据平台、企业内部工具、Agent 平台、管理后台等很多方向。

4. Python / TypeScript / React 要不要学

你说你只熟悉 C++，现在项目后端是 FastAPI，前端是 React + Vite，不知道要不要学 Python 和 TypeScript。

结论是：

要学，但不要像学 C++ 那样系统死磕。

你现在学 Python 和 TS 的目的不是转型成 Python 工程师或前端工程师，而是为了：

1
2
3
4
5
看懂项目
改小功能
排 bug
判断 AI 写的代码对不对
理解前后端链路

你的学习重点应该是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Python：
基础语法、dict/list、类型标注、文件读写、异常处理、FastAPI、Pydantic

TypeScript：
基础类型、type/interface、async/await、fetch/axios

React：
组件、props、useState、useEffect、表单、列表渲染

工程链路：
按钮在哪个组件
调用哪个前端 API
请求哪个后端接口
后端 router 调哪个 service
最后读写什么文件/模型/数据

不要一上来就卷 Python 高级特性、TS 类型体操、React 深层原理。

你最稳的定位是：

C++ 作为基本盘，Python 作为 AI/后端工具，TS/React 学到能读能改。

5. 如果 AI 连业务理解、系统抽象、工程实现、结果交付都能跑通怎么办

你提到类似 Claude Fable 5 这种更强的 Agent，如果未来 AI 连整个软件开发流程都能跑通，人该怎么办？

我们讨论出的核心结论是：

不要再把自己定位成“代码生产者”，而要定位成“问题负责人 + AI 生产系统操作者 + 结果验收者”。

未来程序员的价值链可能会从：

1
需求来了 → 人理解 → 人设计 → 人写代码 → 人测试 → 人交付

变成：

1
模糊问题来了 → 人定义目标和边界 → AI 生成方案和代码 → 人验证、取舍、集成、负责结果

所以你要练的不是“比 AI 更会写代码”，而是：

1
2
3
4
5
6
我能不能判断 AI 写得对不对
我能不能定义清楚规格
我能不能设计测试和验收标准
我能不能处理现实业务中的混乱
我能不能把 AI 结果接进真实系统
我能不能承担交付结果

你要成为 AI 的上级，不是 AI 的竞争对手。

6. 以后大家都会丢工作吗？

我们聊到 AI 会不会让大家都失业。

我的判断是：

不会所有人都丢工作，但很多人原来的工作方式会消失。

更可能发生的是：

1
2
3
4
5
岗位重组
初级岗位减少
简单执行型工作被压缩
不会用 AI 的人被会用 AI 的人挤压
一个强人 + AI 顶掉过去一个小团队

最危险的人是：

1
2
3
4
5
6
只会等需求
只会写简单 CRUD
只会复制 AI 输出
不会判断对错
不理解业务
不负责结果

但仍然有价值的人是：

1
2
3
4
5
6
能定义问题的人
能负责结果的人
懂业务现场的人
能审查 AI 输出的人
能把 demo 变成稳定系统的人
能处理混乱现实的人

所以不是“大家都会没工作”，而是：

普通执行型岗位会减少，能借助 AI 放大自己的人会更强。

7. 会不会出现技术断代

你最后问：

这会导致技术断代吗？

我的判断是：

会有局部技术断代风险。

以前新人是这样成长的：

1
2
3
4
5
做简单需求
修简单 bug
写简单 CRUD
慢慢熟悉系统
成长为中高级工程师

但 AI 进来后，公司可能变成：

1
2
3
简单活让 AI 做
复杂活让 senior + AI 做
junior 少招一点

这样新人缺少练手机会，就可能导致：

会跑 demo 的人很多，但真正懂系统、懂维护、懂工程质量的人变少。

所以对你来说，最危险的方式是：

AI 写，我复制，能跑就行。

你应该反过来训练：

1
2
3
4
5
AI 写之前，你先写设计
AI 写之后，你负责 review
核心结构自己先想一遍
每次找出 AI 结果里的潜在 bug
保留一部分手写训练

目标不是不用 AI，而是：

不让 AI 替你思考，只让 AI 替你加速。

8. 对你当前最重要的建议

你现在最应该做的，不是焦虑，也不是盲目学很多新技术，而是：

在当前实习里抢一个你真正能负责、能讲清楚的模块。

比如：

1
2
3
4
5
6
7
样本集管理模块
标注数据格式统一模块
训练前数据校验模块
训练任务状态机模块
推理任务管理模块
模型版本管理模块
文件并发写入保护模块

你要让自己从：

我参与了平台 lite 化。

变成：

这个模块的业务流程、数据结构、接口设计、异常处理、AI 生成代码的审查和最终交付，我都能讲清楚。

这样这段实习就不会只是“打杂”，而会变成你简历上真正能讲的项目。

一句话总结这次对话：

AI 时代，最危险的是只会执行；最有价值的是能理解真实问题、抽象系统、驾驭 AI、验收结果，并最终为交付负责的人。你现在要做的不是和 AI 比写代码，而是借当前实习训练自己成为能负责一个系统模块的人。