Beyond IPO Rumors: Can DeepSeek Actually Get the Work Done?

My conclusion is that DeepSeek's models and tools are suitable for organizing autonomous driving data and assisting with code, but not for treating its conclusions directly as acceptance criteria. From a deployment perspective, capital markets will affect how many GPUs it can buy and whether it can sustain iteration, but my testing shows the most intuitive engineering aspects are whether Chinese long-document processing, test skeletons, and API calls drop the ball.

Over the past few days, I integrated general large model workflows into DeepSeek. First, log in to the web version, create a new project, and throw in Horizon Robotics financial reports, Luxeed RX anti-collision braking instructions, and a Robotaxi test case snippet. Anti-collision braking means actively braking when the car is about to collide. The interface is simpler than expected; after uploading files, you can choose the model. The V4 preview has Pro and Flash versions, with parameter scales of 1.6 trillion and 284 billion respectively. Parameters just indicate model size, not necessarily usability; the difference is mainly cost and response speed. I used Flash for summaries first, then Pro for complex comparisons.

The issue arose with document segmentation. The financial report PDF had tables and footnotes, and DeepSeek mixed up columns of numbers, conflating operating cash flow with net profit. This is the pitfall I fear most when writing financial report posts; book profit and operating profit cannot be mixed. Later, I changed the approach to have the model convert tables to Markdown first, then manually verify key rows, which stabilized things. It can extract three to five key points, but critical numbers still require manual verification.

The surprise came from test cases. I asked it to write verification steps for "Anti-collision braking automatically restores to enabled state after restart." It listed scenarios like power cycling, switch status, sensor occlusion, and low-speed target approach, which was faster than building the skeleton from scratch. However, it also wrote untested features as "should work," which is a risk of same-source error. The biggest fear with AI-generated tests is grading itself perfectly; pass/fail criteria should still rely on independent checklists.

I also installed DSH. It's DeepSeek's accompanying engineering tool, essentially a shell connecting models, plugins, permissions, and local tasks. My experience is that it's convenient, but issues like abnormal permission judgments and crashes after plugin installation do exist. Beginners who just want to ask questions are fine with the web version; those doing automation workflows might actually get dragged into debugging by it.

Regarding IPO rumors, public reports mention DeepSeek's first funding round was approximately $7 billion, and the second transaction was paused, partly due to dissatisfaction with communication leaks. This information shouldn't be used for investment decisions. From a deployment perspective, going to the capital market likely means the model race enters a phase of competing on compute, talent, and delivery. Users care more about API pricing, update frequency, and data compliance.

My judgment is: it depends. Recommended for those who already have data cleaning and validation systems; not recommended as an automatic judge. Next, I'll use it to process Robotaxi road test logs to see if it can cluster long-tail scenarios; it does a decent job with data organization, code skeletons, and Chinese summaries, but for autonomous driving long-tail scenarios, financial reporting standards, and safety default policies, humans still need to guard the last gate.