把 5G 首呼打通靠的是什么：算力、经验，还是运气？上周我在实验室做了两次交付，答案是：一次“捉鬼”。
博士朋友把 Open5GS、IMS、OAM 打成了一个交付包。我的题：在陌生站点 3 小时跑通 FirstCall——商用真基站，Mate40 真机。Addy Osmani 把这套打法拆成三级：Prompt、Context、Harness Engineering。我的两场交付正好把三级走了一遍，这篇是上篇：执行面。
操作上整个过程五步，每一步标注谁在干活：
- 环境体检[Agent·认知]：04-verify 工具扫底座，L1 项 OK=54 / FAIL=0。
- 站点适配[Agent 执行 · 人确认]：SCTP 内核模块加载并写入 modules-load.d；IP 规划 .81/.82 加到 lo/32 并写 systemd 持久化；WebUI 端口 ：3000 与客户 grafana 冲突，实测支持 PORT 变量迁到 ：13000。
- 一键部署[Agent·执行]：oneclick-deploy 双模式起全部网元。
- 分级验收[人·判断]：t1~t4 逐级过——L2 九大子系统 OK=22、L3 PASS=6、NF=16/16、51 条签约、License 双证验签，口径 FAIL=0 我拍板。
- 真机首呼[真机]：Mate40 注册，FirstCall 打通。
首轮其实栽过：.81/.82 缺失导致 AMF/UPF 绑定失败，NF=13/16。补齐后 8.5 分钟重部署。拍板那一刻的前提，是我脑子里有 IP 规划这张图——认知是判断的天花板：Agent 判断候选的质量，同样取决于我喂给它的上下文。认知不够的人，连问题在哪都看不见。
第二句在插曲里：04-verify 报 7 个端口未监听，Agent 没照单全收，独立复测确认是 SIGPIPE 确定性误报（rc=141，大缓冲管道下 set -o pipefail + grep -q 必现）。判断是创新的起点：先有“这不是部署故障”的翻案判断，才有反哺上游的修复建议。
沉淀
t1~t4 分级测试、双模式一键部署、kb 知识库、findings 收件箱，全部留在工作区。这些是留存在地的曳光弹，不是用完即弃的原型——下一个站点沿这条弹道继续加厚就行，8.5 分钟可重放。
下篇预告：这套分工在“有包有文档”的场子成立。下一篇的场子更野——没有基站，要在 GPU 上用软件“长”一个出来，故障没有任何先验。那时你会发现：AI 作为 Partner 没有上限，前提是认知的喂食不能停。
评论0