Two months with Apollo Go: a few things the app never tells you

I spent two days running several rounds of controlled tests specifically on Apollo Go, doing one run each during morning and evening rush hours and deliberately choosing three situations: short trips, cross-station trips, and rainy days. The conclusion is that it's worth using, but don't treat it like a ride-hailing car. It's more like a bus route that drives itself.

I started using it in Wuhan about two months ago, at first just because it was cheap. The materials mentioned the base fare being as low as 4 yuan versus 18 yuan for a human-driven taxi. I didn't quite believe that price gap at first, but after a few rides I found it was real, especially for short trips. But cheap doesn't come without a cost—the cost comes later.

Apollo Go is an autonomous driving mobility service under Baidu Apollo. Robotaxi means a ride-hailing car with no driver. When you open the app, the first step is to look at the stations on the map. Unlike Didi, where you enter your destination right away, it only picks up and drops off at fixed stations. You have to walk to the station first, then walk to your destination. The first time I used it, I tapped for ages at the community gate and couldn't get a car. Only later did I realize there was no station nearby—the closest one was about seven or eight minutes' walk away.

The interface shows the vehicle's real-time location, with a little car icon moving along the road and an estimated arrival time next to it. That part is done quite clearly—you can see which intersection the car is at and how many minutes are left. When the car arrives, the app gives you a verification code. After getting in, you enter it on the in-car screen or scan it, and only then does the door open. I got stuck here the first time, because the car stopped more than ten meters from where I was standing. I wasn't sure whether it was the right car, and the screen didn't show any obvious marker other than the license plate.

The experience after getting in is good. The in-car screen shows the route, remaining time, and a safety notice. Starting and braking are smoother than I expected. It slows down for turns and yields early when an e-bike cuts across. I deliberately took one ride on a rainy day. The road surface was reflective, and it drove more conservatively than usual, keeping speed fairly low.

The Apollo Go app description says "one-tap hailing, station search, walking navigation." In actual use, the walking navigation part is the weakest link in the experience.

The problems are mainly in three areas. First is station coverage—not all places are reachable, and cross-district trips or trips to more remote places often show no available stations. Second is waiting time. I called one during rush hour and the estimated arrival climbed from 6 minutes all the way to 15. Having few cars is a hard flaw. Third is flexibility. When there's a temporary road closure or construction, it won't take small side streets like a human would. It just stops and waits in place, or tells you to place a new order. From a product manager's perspective, this logic is safety first, efficiency second. The technology itself is fine.

It suits people with fixed commuting routes, flexible schedules, and sensitivity to price—for example, the stretch from a subway station to a business park. Using it there is a good deal. People in a hurry, carrying large luggage, or whose destination isn't near a station should skip it. In those cases it's more tiring than taking a taxi.

Compared with the Li Auto I started using three months ago, that's a private-car scenario, pursuing driving experience and cabin interaction. Apollo Go is an operations scenario, pursuing cost and safety redundancy. The two logics are completely different, and you can't evaluate them with one set of standards.