ReadingResearchRadarInvestment framework
Sign in / Sign up
← Back to reading
NewsMaterial5 min readDisconfirmAI Editorial

Bosch Engineers Use Doubao Work Partner to Process Fault Reports: AI Draft Covers 70-80%, Value Lies in Post-Communication Rather Than Judgment Itself

A Bosch R&D division uses Doubao Work Partner to automatically aggregate fault fragments scattered across group and private chats into complete problem descriptions, generate draft reports according to templates, and archive them into a knowledge base. Engineers estimate that the AI draft covers 70-80% of the content, while fault attribution, verification plans, and external conclusions remain subject to final human review. The project took over a week from requirement to implementation, with the AI going live in just one day.

2026-11-07 11:35 GMT+8

R&D departments in automotive supply chain companies face a common dilemma: an engineer has to do the work of three people. They must monitor R&D details while also handling daily repetitive tasks. An engineer at a certain business unit of Bosch serves on a team that interfaces with various customers to provide comprehensive system solutions. For the same customer, different projects have different chat groups; if any issue arises during testing, road trials, or production, messages pop up one by one—specifying which project, which software, what fault code was reported, and what error occurred.

The engineer's previous workflow was as follows: gather messages scattered across various groups and private chats, integrate them into a complete description based on several dimensions such as project affiliation, software version, vehicle configuration, test conditions, error time, and diagnostic screenshots, and use experience to determine who to contact for troubleshooting. If explanations were unclear, meetings were held to clarify issues before issuing reports to customers. Half a day would pass before fault analysis even began.

Two things prompted him to make a change. First, knowledge accumulation is unreliable: experience resides in individual engineers' minds. While cloud documents and knowledge bases exist, everyone has different templates and habits, and when projects are busy, no one takes the time to input data. When personnel leave, experience is lost. Second, customers do not ask questions according to templates: problems occur in a streaming fashion, with messages constantly popping out. No one can provide fault codes, screenshots, and over a dozen fields all at once in a single message. If fragments cannot be collected completely, subsequent analysis remains stalled.

Sign in / Sign up
ReadingResearchRadarInvestment framework

The addition of Doubao Work and Doubao Work Partner changed this path. The engineer configured scheduled tasks in Doubao Work to patrol private messages received, identify fault-related information, and forward it under their own identity to a dedicated topic group for problem reports. Customer communication habits did not need to change; matters scattered outside the process were pulled back into it. Once messages entered the dedicated group, each problem occupied an independent topic, naturally forming an interface for 'one matter, one discussion.'

Doubao Work Partner crawled historical context from the group, aggregated streaming fragments into complete problem descriptions, then called encapsulated report generation skills to produce drafts according to standard templates. Simultaneously, it registered entries in Feishu (Lark) Bitable, reminding the corresponding engineer to handle them. In one real problem-handling record, the AI organized messages into a Feishu document, marking the problem status as 'In Progress'; information such as drive form and driving mode, which was incomplete, was left as 'To Be Supplemented.' The engineer only needed to verify and fill in the draft, rather than starting from a blank document.

Some details could only be finalized during meetings. The engineer could invite Doubao Work Partner to attend problem communication meetings; it listened throughout and directly synchronized clarified information into the report after the meeting ended, eliminating the step of manual transcription between discussions, records, and reports. According to the engineer's own estimate, the AI draft could cover 70-80% of the content, leaving the remaining 20% for human judgment. After meeting conclusions supplemented the report, making it basically complete, it underwent one more round of manual review before being sent to the customer.

Reports were simultaneously archived into the team knowledge base, with status and progress retained in Bitable: the table managed follow-up, while the knowledge base managed retention. When encountering similar problems again, the AI retrieved historical materials to provide initial ledgers and attributions. The knowledge it could call upon fell into two categories: one was external industry knowledge, such as the meanings represented by general fault codes; the other was the team's own historical accumulation, where even problems handled by veteran engineers who had already left could be retrieved and cited.

This project took just over a week from requirement to implementation. Doubao Work Partner truly went live in just one day; after joining the group and working alongside the engineer for a day, the project was already running. The following week was used to fine-tune details—which reports were too verbose, which content should not be included, which descriptions were inaccurate. The engineer could tell it item by item to avoid such processing next time. Currently, Doubao Work Partner has processed fifty to sixty problem reports and can stably maintain a level of 70-80 points. The remaining twenty points are left for humans to make the final checks: how to determine fault causes, how to arrange verification plans, and what conclusions to give externally. These key tasks still require manual review, supplementation, and confirmation by engineers.

The core judgment offered by this report is that the position where AI creates value is not the most central link in the workflow. By leaving communication, judgment, and the resolution of professional problems to humans, and handing over post-communication organization, recording, and action to AI as much as possible, engineers can free up their hands to do what truly requires engineers to do. AI does not necessarily have to do the most important things to create important value.

It needs to be pointed out that the core efficiency metrics are self-reported estimates by engineers, and overall data lacks independent verification; this process relies on the Feishu ecosystem and specific report templates, and the migration cost to other toolchains or more complex fault types has not been explained.

Sources

  • geekpark.netGeekPark↗
  • 163.com↗
Continue researching →