上一篇报告发布略显仓促，且多聚焦于 LLM 的局限性，缺乏实战案例。近期模型与工具迭代极快，体验日新月异，本篇将基于近两周的深度使用，聊聊 LLM 如何从“玩具”变为真正的“生产力”。

手搓网络分流规则

近期由于网络工具升级，我需要根据访问目标进行流量精细化分流，以确保“落地归属”的可控性。这对于使用特定区域（如美区、日区）的国外模型服务至关重要。

然而，服务商提供的规则十分粗糙，仅勉强可用。为了实现个性化适配，我尝试向 Gemini 请教，但结果并不理想。在处理 rule-set 与 and 等逻辑操作符的嵌套关系时，Gemini 频频出现语法幻觉（Hallucination），甚至无法理解 rule-set 与 sub-rule 无法搭配工作。

最终，我还是靠自己“手搓”了一套分流规则，有效解决了以下痛点：

• Google 与 AI 服务：归属同一落地节点。
• Google Meeting：独立拆分。由于其在日区 UDP 通信可能卡顿，而在港区通过 WebRTC 直连 UDP 更流畅，我需要精准定位其 IP 段进行单独分流。
• 美区 VPS：设定为独立的美区落地。

google meeting 要单独拆开的问题是，它在新日区做 udp 通信可能会卡顿，而在港区就流畅很多，它用的是 wetrtc 的直连 udp，需要找到它的使用 ip 段才能精准将流量单独区分开。

最后还有一个问题是没有解决的，就是 zerotier 的流量，在主路由 tproxy 代理 udp 流量的模式下几乎是无解的。

zerotier 的流量是这样的：PC -> udp -> 虚拟网卡 -> 路由器 -> relay 节点。

在 PC 上看 udp 的地址是内网地址，指向虚拟网卡。

在路由上看到的是已经被虚拟网卡指向公网 relay 节点地址，而且这个地址是不确定的。

路由上的分流规则根本没法筛选这种流量出来，虽然说它协议默认的规则是使用 9993 端口，但放行这个端口的 udp 流量根本没有用。而非常诡异的是，关闭 tproxy 的 udp 代理之后，重启 zero 让它连上网络，再开启 tproxy 模式，在一定时间内，zero 的组网是畅通无阻的。

这种涉及底层协议劫持与 NAT 穿透的复杂场景，AI 完全无法理解，只能给出放行 9993 端口这种无效的“标准答案”。

blog 升级

近期我发现常用的 Excel 统计表在特定边界条件下公式出错，且在 Excel 中维护复杂逻辑极其痛苦。与其修补 Excel，不如直接在博客上开发一个 Web 工具，既能解决多端同步问题，又能一劳永逸地固化逻辑。

于是，为了测试 llm 目前的能力，我特意切成 agent 模式，让 opus 4.5 来帮我实现这个功能：

1. 前端复刻，像素级还原： 我直接将 Excel 图表截图发给 Opus，首版还原度即高达 80%。虽然细节微调经历了数十轮交互，但相比手写 HTML/CSS，效率已是质的飞跃。

2. 核心逻辑，实时计算： 需求是基于“基金目标成分配比”，自动计算再平衡金额与增量资金分配。为了确保前端 JS 计算的精度（特别是金额的四舍五入），我花了十几轮对话纠正它的算法逻辑。最终它成功交付了逻辑严密的计算模块。

3. 后端 API，批量优化： 后端代码几乎全由 Opus 生成。针对它最初提供的“单条提交”低效方案，我指导其改为“批量提交”接口，并调整了数据库结构。

最后，我觉得这个工具页面既然全是前端计算，只给我自己用是很浪费的，于是让 opus 将页面的数据保存和提交功能进行阉割，放开权限给任意人使用，并且增加了分享功能，可以当成另类的保存功能使用，就是将数据提取压缩放入 url 里面，保存好这个 url，下次访问使用，就可以直接解析出一样的数据，使用体感来说已经算不错了。

之后，我又继续让它将博客的依赖库进行了升级，包括前端的框架和后端的代码，全程只是指挥和测试功能，并没有上手写一行代码。也顺利完成了工作，Opus 展现出的全栈执行力，已远超初级程序员的平均水平。

RFC 实现和测试

这是另一个高光案例。我需要根据 RPC 实现 haproxy 协议，嵌入到 tentacle 中。

我只是把协议网页发给 opus 之后，它就直接生成了正确性没有什么很大问题的代码，当然里面还有一些缓冲区的管理、内存攻击的安全性问题没有解决，但这已经非常厉害了，要知道，这个协议我都还没看完，它已经把代码写得差不多了。

为什么不用现成的库，比如 ppp，因为它的接口，它是 Header::try_from(input: &[u8])，网络模块非常扣性能，能不多读不多读，同时，这个协议非常简单，两种版本都可以通过简单的读 header 确定性找到协议的所有数据，而既然我要读 header 了，为啥要要使用 ppp 的接口去解析剩下来不多的结构？不如直接解析到需要的数据就结束了。

更令我惊喜的是它的测试生成能力。在以往，编写覆盖各种边界条件的测试用例极其耗时，而 Opus 在十分钟内就生成了四五十个高质量测试，通过排列组合覆盖了绝大多数场景，甚至能自我验证并修复 Bug。

于是，在我与 opus 通力合作之下，这个 PR 就诞生了：

• Opus：负责主体代码实现 + 全量测试用例 + Nginx/HAProxy 配置生成
• 我：负责安全审计（内存攻击防御）、逻辑优化与查缺补漏

非常好的编程体验，效率提升三倍以上，着重关注点从代码变成了 review 实现、安全问题、优化逻辑和查缺补漏，极大降低了工作量。

四小时的“小黄鸭调试”

当然，并非所有体验都是完美的。

近期在测试一个分布式锁功能时，我与 GPT/Claude 进行了长达四小时的拉锯战。问题表现为：本地网络访问分布式锁时，本应并行的竞争关系变成了串行，导致行为不符合预期。

AI 从代码逻辑层面分析了无数遍，始终找不到破绽。最后还是我灵光一闪，意识到问题出在 Tokio Runtime 的调度机制上：spawn 的任务并未立即均匀分发给所有 Worker 线程，导致在特定测试环境下出现了假性串行。最终通过 block_in_place 强制将任务刷出到其他 Worker 解决。

这种涉及**底层运行时调度（Runtime Scheduling）**的隐晦 Bug，需要非常强的直觉和工程经验才能定位，目前 AI 尚未具备这种“脱离代码看运行状态”的洞察力。

总结

这一个多月的深度体验，让我对 LLM 的态度更加激进。从效果来看，它不仅填补了我在前端领域的技术短板，更作为一个超级放大器，极大地优化了我的测试构建能力与工作流。

现在的结论很清晰：我们需要，并且必须将 LLM 深度嵌入到工作流中。对于资深开发者而言，它所提供的正反馈，甚至优于配备一支初级程序员团队。

请登录后评论