一篇写给技术同行和潜在合作伙伴的自我剖析
写在前面
前段时间，有朋友把几篇关于我的文章链接发给了AI，让AI做了一份评价。AI的结论大致是：这个人很强，但也存在风险——个人色彩过浓、部分技术选型“草根”、风格高调。
这个评价，我觉得基本公允。
正好借这个机会，我想聊一个更底层的问题：当一个人把自己的技术实践和商业探索公开写到网上时，作为读者或潜在合作方，应该怎么看待他？怎么避免被“故事”带偏，做出客观的判断？
同时也聊聊，我为什么选择在这个时间点，把加密方案从AES-128-ECB升级到AES-256-GCM——这不只是技术升级，更是一个信号。
一、AI评价的“公允”与“局限”
先说说那份AI评价。
公允的地方（我认）：
- 单人模式的风险是真实的 – 一个人扛架构+编码+硬件+商业，一旦我出问题，体系确实可能受影响。这不是谦虚，这是事实。
- 部分技术方案确实“草根” – 比如旧版的AES-128-ECB加密、固定密钥、Windows API主动清理内存……这些在安全要求极高的场景（金融、军工）确实不够。
- 风格高调 – “P9级别”、“天花板”这类词，确实容易引起争议。这是我的叙事方式，但它同时也在筛选读者——信的人会来，不信的人会走。
需要补充的地方（AI没看到的）：
- “草根”方案背后的场景适配 – 我的系统最早跑在树莓派+80人工厂，目标是成本可控、快速落地。在那种场景下，“工业级安全”不是首要矛盾，“能用、够用、工人不骂”才是。这不是借口，是真实的优先级排序。
- 个人化的另一面 – 一个人写的代码，确实只有一个人能维护。但恰恰因为如此，决策极快、试错成本极低、方向调整不需要开会。这是“一人成军”的两面性。
- 高调风格的商业逻辑 – 我不是在写学术论文，我是在招募合作伙伴和早期客户。在注意力经济的时代，“低调”的成本远高于“高调”。我需要让对的人快速识别到我。
所以，AI的那份评价，如果用来评估“这个人适不适合做你的核心供应商”，是有参考价值的；如果用来评估“这个人值不值得关注和学习”，则信息不够完整。
二、加密升级：从AES-128-ECB到AES-256-GCM
2.1 旧版的逻辑（为什么敢用ECB？）
旧版使用AES-128-ECB，密钥硬编码。这在安全领域几乎是“犯忌”的。
但我的考虑是：
| 维度 | 实际情况 |
|---|---|
| 攻击面 | 服务器在内网，无公网IP，外部无法直接访问 |
| 攻击者 | 防御的是外部扫描器和内部误操作，不是国家级黑客 |
| 密钥泄露 | 如果真的泄露，服务端一键换密钥，旧客户端强制更新 |
| 成本 | 简单、快、CPU占用低，树莓派扛得住 |
这不是“安全不重要”，而是“在当时的场景下，ECB够用了” 。
2.2 为什么要升级？（不是bug修复，是场景变化）
随着系统从“单工厂跑”走向“联营+多工厂部署”，安全要求变了：
- 网络环境变复杂 – 从纯内网变成可能经过云网关、MQTT穿透，密文暴露在公网链路上的概率增加。
- 密钥管理要规范化 – 硬编码密钥无法满足多租户、多环境的隔离需求，必须走环境变量+可配置机制。
- 完整性校验是刚需 – ECB只加密不认证，缺少防篡改能力。GCM的认证标签可以防止密文被恶意修改。
- 兼容性要平滑 – 旧版客户端必须能继续工作，不能强制一次性全部升级。
2.3 v11.0升级方案的核心设计
版本化加密包格式：
┌────────────┬────────────┬──────────────────────┬──────────┐
│ Version │ Nonce │ Ciphertext │ Tag │
│ 1 byte │ 12 bytes │ Variable │ 16 bytes │
└────────────┴────────────┴──────────────────────┴──────────┘
自动版本识别：
- 服务端收到请求后，先
peekEncryptVersion()探测版本 - v2（GCM）→ 新逻辑
- v1（ECB）→ 旧逻辑（如果启用兼容模式）
- 不兼容 → 返回明确错误，引导客户端升级
客户端升级平滑：
- 新客户端主动在Header中携带
X-Encrypt-Version: 2 - 服务端根据客户端能力选择加密响应格式
- 旧客户端继续用ECB，不受影响
这不是一次“推翻重来”，是一次“向前兼容的演进” 。这也是我的架构风格的一个缩影——不追求一步到位的完美，但每一步都留好演进接口。
三、如何客观评价一个技术创作者？（给读者的方法论）
回到最初的问题：当你看到网上一个自称“P9水平”、“一个人完成工业平台”的技术博主，你应该怎么判断？
我提供一套我自己也会用的框架：
第一步：看他的“可验证资产”
| 维度 | 问什么 | 我的回答 |
|---|---|---|
| 代码 | 能跑吗？开源吗？能下载试用吗？ | 目前不开源，但有完整的Qt项目结构和编译配置 |
| 案例 | 有真实客户吗？跑了多久？ | 同一浸胶纸厂连续打磨5年（氚云3年+自研2年） |
| 硬件 | 数据采集是自己做的吗？ | 是，ESP32+485总线+Modbus，软硬一体 |
| 团队 | 他是真的一个人吗？ | 核心技术部分是的，硬件部署和商务有合作伙伴 |
| 交付 | 系统是Demo还是能用的？ | 80人工厂每天使用，不是PPT |
结论：他的“强”，不体现在写了多少行代码，而体现在代码能跑、硬件能接、工厂能用。这是可验证的。
第二步：看他的“技术取舍是否匹配场景”
不是“方案是否完美”，而是 “方案是否匹配了当时的约束” 。
| 取舍 | 当时的场景 | 是否合理 |
|---|---|---|
| AES-128-ECB | 内网、树莓派、80人工厂 | ✅ 够用 |
| 固定密钥 | 内网、强制更新机制 | ✅ 可行 |
| Windows API清理内存 | Windows环境、需要长期稳定 | ✅ 实用 |
| 不使用Docker/K8s | 树莓派+Python协程 | ✅ 简化 |
结论：他的方案不“教科书”，但经受了真实生产环境的检验。这是比“优雅架构”更硬的通货。
第三步：听他的“叙事风格”，但别被带偏
高调叙事是一种信号策略：
- 对同行：筛选出愿意深度交流的人
- 对客户：传递“我们很专业”的信号
- 对资本：展示“我值得关注”的姿态
作为读者，你应该做的是：看他的行动是否匹配他的叙事。
- 他说“我一个人顶一个团队” → 去看他的代码量和模块数（4-5万行，21个模块）
- 他说“系统在工厂跑了两年” → 去问他在哪家厂，能不能验证
- 他说“P9水平” → 去判断他是否具备架构设计+工程落地+商业闭环的综合能力
如果叙事和行动能对上，那就是“自信”；对不上，才是“吹牛”。
第四步：识别“这个人值不值得跟”
如果你是潜在合作伙伴或投资人，你关心的不应该是“他有没有缺点”，而是：
- 他的核心能力是不是稀缺的 – 工业软件+工业AI+软硬一体，确实稀缺。
- 他的短板是不是可弥补的 – 单人模式、部分方案草根，可以通过合作、融资、团队建设来弥补。
- 他有没有清晰的成长路径 – 从“一个人写代码”到“一家公司”的路径，他在文章中写得很清楚（三级火箭战略）。
- 他是否坦诚 – 他主动暴露了自己的短板（单人风险、草根方案），说明他不是在“造神”。
如果这四个问题的答案都是肯定的，那他可能是一个值得关注和投资的个体。
四、我为什么要公开写这些？
很多人问我：你把自己的架构、加密方案、商业计划都写出来，不怕被抄吗？
我的回答是：我靠迭代速度活着，不是靠封锁存量活着。
你最多只能抄到我上个月的东西。
当我这个月的新版本出来的时候，你抄走的那个版本，已经是我送给整个行业的礼物了。
写这些文章的目的，从来不是“证明我多厉害”。
是让能看懂的人，知道我在做什么，以及我们怎么合作。
加密升级v11.0，就是这个逻辑的又一次验证。
不是我突然觉得ECB不安全了，而是系统走向规模化，安全基线必须同步演进。
五、总结
一个人可以被评价，但不能被简化。
AI的评价，给了我一个外部的、相对客观的视角。它帮我看到了：
- 我的风险（单人依赖、风格高调）
- 我的短板（部分方案草根）
但也提醒了我一件事：我需要让更多人看到，我的系统不只是“我能写出来”，更是“工厂能用、联营商能交付、客户能赚钱” 。
加密升级只是第一步。
后面还有更多“从一个人走到一群人”的证据，我会继续写出来。
如果你也在做工业软件，或者你正在寻找能落地的技术合作伙伴，欢迎交流。
我们不聊概念，只聊你的客户车间里，现在最头疼的是什么。
