先交代一下背景：我是一名汽车行业的产品经理，做电子电气架构方向。我写过最长的"代码"是 Excel 公式，VBA 没碰过，Git 是什么今年才搞明白，命令行只会 cd 和 ls——这大概就是大家说的"纯纯的产品经理"。

两个月前，我拿到一份 SOME/IP 通信矩阵 Excel，就是下面这个故事的开端。

SOME/IP 是汽车以太网里最核心的通信协议，车里的空调、车窗、门锁这些控制器（ECU）之间靠它说话。新车型开发时，架构师会先写一份"通信矩阵"——一张巨大的 Excel，几百行，每一行定义：谁提供服务、服务名叫什么、有哪些方法、哪些事件、端口是多少、参数是什么类型……

传统的开发流程是这样的：

1. 架构师在 Excel 里把矩阵写好
2. 通信工程师照着 Excel 手写接口定义文件（FIDL/FDEPL）
3. 代码工程师再照着接口文件手写服务端、客户端代码
4. 三个环节全是人工转译，Excel 改一个字段，后面全部要跟着改

Excel 一个参数名拼错 → 接口文件错 → 代码错 → 联调的时候才发现。这个链条里每一步都是"人肉翻译"，慢、错、烦。

我拿到矩阵的时候，第一反应不是"好难"，而是：这不就是一份需求文档吗？既然需求是结构化的，为什么不能自动变成代码？

我完全不懂写代码，但我懂一件事：任何复杂系统，都能拆成"输入 → 处理 → 输出"的小步骤。这是我做产品拆需求的本能。

我把整个 SOME/IP 开发拆成了四个阶段，每个阶段都有一个明确的"验收物"：

先做什么、再做什么的逻辑很简单：每一步的产出，是下一步的输入；每一步做完，都能立刻验证对错。绝不一口吃成胖子，绝不越过"验证"直接往下冲。

选工具：Python。理由很产品经理：处理 Excel，Python 生态最成熟，而且 AI 写 Python 脚本的成功率最高——对我来说，工具的"可被 AI 驾驭程度"比技术先进性重要一百倍。

我让 AI 做了一件事：读取那份 5 个 Sheet、116 行 × 35 列的矩阵 Excel，做合法性校验（服务 ID 有没有重复、方法 ID 有没有冲突、参数类型对不对），最后合并输出成一个 merged.json。

这一步看着简单，其实是最关键的一步。Excel 是给人看的，JSON 是给机器看的。矩阵里的合并单元格、跨行定义、备注里的特殊规则，全部要在这一步被"翻译"干净。翻译干净了，后面全是顺水推舟；翻译脏了，后面每一步都在还债。

验收物：一份校验通过、结构干净的 JSON。这一步大概用了不到一天。

光有 JSON 不行，架构师同事不会去看 JSON，他们要的是"能看的工具"。

选工具：Electron + React。理由同样很产品经理：跨平台桌面应用、界面友好，而且这是前端最主流的技术栈，AI 训练语料最多，翻车概率最低。

我让 AI 基于 JSON 搭了一个可视化设计器（我给它起了个名字叫 SOMEIP Designer）：

• 左边看服务列表，点进去看每个服务的接口
• 参数、枚举值、端口、事件组，全部表格化编辑
• 改完一键导出标准接口定义文件（FIDL/FDEPL）

这个阶段我干的全是"产品经理"的活：提需求、看界面、提修改意见。"枚举值能不能用表格展示而不是挤在一个文本框里？"——这种话我能说一天，AI 就改一天。改到顺眼为止。

验收物：一个能编辑、能导出、同事们愿意用的桌面工具。

下面就是最终交付的设计工具界面——请原谅一个产品经理的得意，毕竟这些界面是我"设计"出来的：

这是最像"魔法"的阶段，也是我作为一个不会写代码的人，最自豪的阶段。

SOME/IP 在 Linux 上有标准的开源实现（vsomeip + CommonAPI），业界流程是：接口文件 → 官方代码生成器 → 自动生成服务端和客户端的代码骨架。问题在于：接口文件本身是人工写的，而人工写就会错。

我的做法：让 AI 写了一个"生成器的生成器"——一个 Python 脚本，把 merged.json 直接翻译成 7 份标准的接口定义文件（FIDL/FDEPL）+ 配置文件，再调用官方代码生成器，自动产出全部代码骨架。

然后 AI 又写了一个脚本，把每个服务的业务逻辑（服务端该响应什么、客户端该订阅什么）也批量生成出来。

结果：7 个服务、83 个接口、48 个远程调用、32 个属性读取、140 条事件广播，全部编译通过、跑通验证。我在终端里看到 SUCCESS 刷屏的时候，激动程度不亚于当年产品上线。

当然也踩了不少坑——官方代码生成器有个隐藏行为导致事件发不出来，查了很久发现是"生成的骨架代码少了一行关键的赋值"，AI 帮我对着源码逐行比对才定位。这类坑我记了满满一页，后来全部沉淀成了经验文档。

代码能跑只是及格，能交付才是满分。这一阶段我让 AI 帮我做了四件事：

1. 版本管理：5 个仓库全部用 Git 管理，生成代码不进库、人的成果进库，交接给任何人都不慌
2. C 语言接口层：把 C++ 服务封装成纯 C 接口，方便没有 C++ 环境的团队直接调用
3. 多平台编译：一套代码，本地、开发板、量产平台三种编译方式一键切换
4. 经验沉淀：把整个链路、所有踩过的坑，整理成一份 SOP 文档——下次再做，照着走就行

最终目的很朴素：这个项目不能只有我能用，也不能只有这次能用。

很多朋友问：你不会写代码，怎么让 AI 写出这么复杂的系统？其实我的方法一点都不神秘，核心就三个习惯：

1. 把需求说成"验收标准"，而不是"实现方式"

我从不跟 AI 说"用 XX 技术实现"，因为我不懂；我说的是："这个按钮点了之后，要能把当前服务导出成一个文件，文件内容要符合 Franca IDL 规范"。AI 自己会选技术方案，我只需要验收结果对不对。我的角色是"验收员"，不是"程序员"。

2. 一次只让它改一件事

"顺便把 XX 也改了"是我踩过最大的坑——AI 一旦被允许自由发挥，就会偷偷改坏你满意的部分。后来我的习惯是：一次只提一个修改点，改完立刻验证，满意了再提下一个。就像产品迭代：小步快跑，随时可回滚。

3. 让它先给我"方案"而不是直接开写

遇到没把握的功能，我会先问 AI："这个功能你有几种实现方案？各自的优缺点和风险？"它列完方案，我挑一个，再让它动手。选择权永远在我手里——毕竟最后对结果负责的是我，不是 AI。

还有个小技巧：重要对话我都会让 AI 总结成文档存档（Git 里专门有个"经验沉淀"目录）。下次遇到类似问题，直接翻存档，不用重新踩坑。

1. 选工具看"AI 成功率"，不看"技术先进性"
Python 处理数据、Electron 做桌面、主流框架写前端——不是因为它们最强，是因为 AI 见过的代码多，生成的代码靠谱。冷门炫技框架，AI 不会，你也不会，双输。

2. 拆阶段的唯一标准：每一步都有"验收物"
JSON 能校验、工具能用、代码能编译、接口能跑通——每一步都能验证，错了能定位在哪一步。最怕的是闷头冲一个月，最后发现全错。

3. 先做"翻译"，再做"创造"
Excel → JSON 是翻译，JSON → 设计器是翻译，设计 → 代码还是翻译。所有翻译都自动化之后，剩下的"创造"（业务逻辑、架构决策）才是人该干的事。

两个月前，我还觉得"开发"是工程师的专利；两个月后，我可以用一句话总结这次的经历：

我现在依然不会写代码。但我多了一个能力：把需求变成能跑的东西。

*（本文所有工具截图均为真实运行界面；数字：7 个服务、83 个接口、48 个远程调用、32 个属性读取、140 条事件广播，全部经真实编译运行验证。）