Pisen founder Zhao Guocheng and the post-2000s team: AI tools choose open source, patent drawing tools and others will be opened up

After this patent drawing tool was developed, Pisen founder Zhao Guocheng had originally considered commercializing it, but Cong Zelong, the head of the company's AI products, believed that rather than first figuring out how to charge for it, it would be better to open the tool up so that more companies could use it in their own environments and more developers could participate in testing and iteration. Zhao Guocheng ultimately accepted this suggestion.

This is not the only AI product Pisen plans to open-source. Cong Zelong, who serves as the group's head of AI products, told us that the team has also completed development of an online "AI Trial" tool for screening AI Native talent, which is also planned for open-sourcing. At the same time, Pisen is building the AI Lab official website, preparing to launch a centralized hub for AI management efficiency tools, Agent product download portals, and usage guides.

In Cong Zelong's vision, all of Pisen's future AI innovation tools will move toward open source. But he did not describe this path as a battle already won: building the tool is only the beginning; whether people will keep using it, whether other companies can actually adopt it, and whether it truly solves problems all still require continued refinement.

This gives Pisen's AI practice a starting point different from the typical enterprise transformation story. It is not only about how a traditional manufacturing company uses AI to improve efficiency, but also about whether innovation generated inside a company should be packaged as a paid product or placed into a larger open-source ecosystem.

Although Cong Zelong is a post-2000s generation, he has already built up a young AI product development team at Pisen, and their growth story can begin with a single patent drawing.

During one product development process, communication between patent engineers and structural engineers was inefficient, and the related work slowed progress. The problem was handed to Cong Zelong's team.

Patent drawings may look like just one link in the R&D chain, but they actually involve product structure, engineering models, and patent standards. The 3D models in the hands of structural engineers cannot be directly turned into compliant patent drawings. In the past, relevant personnel had to repeatedly communicate about model details, view selection, and component labeling, and progress was often constrained by cross-role collaboration.

Cong Zelong's team tried combining AI with open-source CAD tools, enabling the system to read 3D models, understand product structure, and assist in generating patent drawings such as exploded views and component labels. AI is responsible for understanding human intent and identifying structures in the model, then calling engineering software to complete the specific processing. It does not generate a "seemingly correct" image out of thin air; rather, it works around the real model.

This distinction is important. Patent drawings must correspond to the product's actual structure and cannot merely pursue visual completeness. AI can reduce preliminary processing and repeated communication, but the generated results still need to be checked by professionals, and final quality cannot rely solely on the model's own judgment.

According to the team's practical vision, some preliminary work that originally required a long communication cycle has the potential to be shortened to tens of seconds or a few minutes. However, this does not mean the entire process from product model to formal patent application can be compressed into a few minutes; engineering verification and professional review remain indispensable.

Only after the tool produced initial results did the team show it to boss Zhao Guocheng. Whether to build a product does not begin with the company organizing an AI strategy meeting at the top level. This is precisely the characteristic of the AI transformation Pisen is undergoing: innovation does not start from a top-down planning document, but from a specific, headache-inducing problem in the business process.

Cong Zelong said the initial attempt did not first become a formally approved project; instead, the team first found demand within the department, started building, and then brought the complete process out for discussion.

As the tool gradually took shape, Zhao Guocheng saw its commercial potential. Following the traditional software approach, such a tool that can solve real problems would seem suitable for charging. But Cong Zelong raised another consideration: patents involve R&D information that companies have not yet disclosed, and if using the tool required uploading data, potential users might have concerns; open-sourcing it and supporting local deployment would instead be more likely to lower the barrier to enterprise use.

A founder who has weathered years in manufacturing first saw the product's commercial possibilities; a young team leader hoped to place the product into a larger ecosystem. The two judgments met in a specific product decision, ultimately pushing Pisen to choose open source.

Zhao Guocheng later explained his judgment this way: "If we followed the business model of traditional SaaS software companies, charging for this product would also work." But he also knew that once Pisen resolved to solidly advance AI implementation in the enterprise, AI product innovation cases like the patent drawing tool would keep emerging, and an AI Native organization would also be on the horizon. "Open source is our moat. In the future, this team and this path will be more valuable, and charging would instead bind our hands."

Of course, open-sourcing a product does not automatically equal a moat. Whether it can bring more users, external feedback, and continuous iteration in the future still depends on whether the product itself truly solves problems. But for Pisen, this choice at least means that the team's goal is no longer just to complete an internal tool, but to try to turn internally accumulated experience into capabilities that outsiders can also use.

From "building a tool" to building a toolbox

Cong Zelong introduced to us the "AI Trial" tool developed by the team, hoping to help the company use it to screen candidates who meet the definition of AI Native talent, with plans to open-source it externally in the future. The AI Lab official website is also under construction, preparing to centrally present the tool portals, download methods, and usage guides developed by Pisen's AI product innovation team.

These attempts share one thing in common: they did not start by defining a market-facing product and then looking for use cases; instead, they grew out of specific needs inside Pisen. The patent drawing tool corresponds to R&D and legal collaboration, AI Trial corresponds to talent screening, and the other management efficiency tools attempt to handle repetitive labor in daily work.

But a tool that is useful internally does not necessarily become an external product directly. Different enterprises have different data structures, workflows, and security requirements, and open source does not mean that others can use it immediately after downloading it. What Cong Zelong cares about more is whether the tool can obtain real feedback after release, and then continue to be improved based on usage.

This is also why Pisen plans to gather the relevant tools together. If each tool is scattered among different teams, other employees will not know where to find them, and external users will find it difficult to understand which products are available. What the official website and usage guides try to solve is the distribution and usage problem after tool development.

From this perspective, what Pisen wants to build is not just a list of tools, but a path that starts from business needs, goes through internal trials, and then moves toward external validation.

However, the number of tools cannot directly prove the effectiveness of the transformation. The real question is whether the tools can enter daily work, whether anyone is willing to keep using them, and how much time they actually save and which results they improve. Pisen still needs to answer these questions through subsequent practice.

If the patent drawing tool shows how AI can solve specific business problems, then Pisen's internal "wishing pool" and "fulfillment group" present another side: as the threshold for making tools drops, more needs will emerge in the enterprise, but how to manage these needs also becomes a new question.

Cong Zelong's team collects AI needs raised by various departments and decides how to handle them after evaluation. It is reported that about two or three needs in the "wishing pool" are advanced each week. "Needs cannot always be satisfied immediately. The team has limited manpower and also needs to judge which problems are worth prioritizing."

Thanks to this mechanism, Pisen has turned AI applications from exploration by a few technical staff into work that can be proposed, fed back on, and participated in by other departments. Employees do not need to first master complex technology before they have a chance to try improving processes; they can first raise problems, and then the team can work together to find solutions.

Pisen's exploration around Skill has run right into this contradiction.

A Skill can be understood as a set of instructions, processes, and knowledge that enables AI to repeatedly complete a certain type of task. Pisen's AI product team began paying attention to this concept at the end of last year. Starting in March this year, they successively created Skills for different departments and colleagues, "hoping to precipitate some working methods so that employees do not have to operate from scratch every time." In practice, Cong Zelong quickly found that some problems were exposed.

For example, the time spent making a Skill sometimes even exceeds the time saved by using it; tools also need continuous maintenance, and usage frequency and actual effects are not easy to track; if every employee makes a separate set, it is both prone to duplication and difficult to judge which ones are worth keeping.

So Cong Zelong's team began building SkillHub, hoping to gather scattered Skills together for easier searching, reuse, and management.

On the surface, this sounds like a natural solution, but actual implementation is not simple. When should a Skill be invoked? Can users judge its quality? If the effect is poor, should the developer or the user optimize it? How should documents, knowledge bases, and Skills be organized so that accumulated experience can truly be invoked when needed?

Cong Zelong does not have ready-made answers to these questions. This also reveals a fact that is easily overlooked in enterprise AI implementation: AI lowers the threshold for making tools and organizing knowledge, but it does not automatically eliminate the cost of organizational collaboration. A tool can be made quickly, but that does not mean it can be maintained over the long term; a piece of knowledge can be saved, but that does not mean it will be used by the right person at the right time.

Although Zhao Guocheng is not a frequent user of AI tools, he told us that he spends a large amount of time every day learning about the latest AI research results at home and abroad through short video media, and then goes to Cong Zelong's team's office area for discussions, sharing, and other exchanges of ideas, studying which results can be applied to the actual work of Pisen and other enterprises.

"The focus I care about is AI efficiency improvement in the R&D process." In Zhao Guocheng's view, Pisen's product R&D and innovation are highly dependent on engineers' experience, with much data validation and complex relationships. If AI efficiency improvement succeeds, it will shorten R&D cycles and increase R&D success rates. That is the real improvement in productivity.

As a hardware company, when Pisen develops a product, it does not just complete a design drawing or write a piece of code; it also has to connect electronic solutions, components, procurement prices, supply risks, production assembly, and validation links. A change in any one link may affect the cost and schedule of the entire product.

Take a charger as an example. Starting from the product requirements document (PRD), electronic engineers need to select core components and evaluate parameters, procurement staff need to judge prices, and the supply chain also needs to check delivery cycles and discontinuation risks. After the plan enters the assembly and validation stage, the team also needs to assess whether the cost meets the target. If the cost exceeds expectations, pricing may need to be adjusted, or the design may need to be redone.

This is a chain that depends on experience, data, and cross-departmental coordination. Even if each link is not complicated when viewed separately, stringing them together can also consume a great deal of time.

According to the description of the Pisen team, repeated communication, evaluation, and adjustment of the relevant plans make a cycle of one month or even longer not uncommon.

The problem is that a great deal of experience has not been fully captured in systems. Engineers know whether a certain component's parameters are suitable, and may also remember which problems a certain supplier has had in the past, but these judgments are often scattered across individual experience and different materials. Personnel changes, product switches, or tool replacements can all make the original experience difficult to reuse.

Pisen did not start filling in data from scratch. It is understood that since 2015, Pisen has been using a product lifecycle management system (PLM), continuously accumulating material information, design specifications, and risk records. Cong Zelong's team built a component database on the basis of these data and connected it to third-party and original manufacturer platforms to synchronize information such as component interfaces, voltage protocols, and specifications.

At present, Cong Zelong's team is exploring the use of AI entirely to create an Agent remote-control gamepad. In the envisioned scenario, the user picks up the controller, selects content on a computer screen, and interacts via voice. Around this product, the team is trying to link requirement definition, component selection, circuit and structural design, firmware and host computer development, as well as prototype trial production and complete-machine validation into one continuous AI R&D process.

The team has completed AI component selection and preliminary structural stacking, and AI has also generated schematics and a preliminary PCB layout. Right now, the team is combining Agent review and engineer evaluation, checking interface selection, antenna surrounding layout, and routing constraints against component datasheets, and adjusting the design based on the problems found.

Next, the team still needs to advance board fabrication, soldering, and power-on debugging, then carry out peripheral driver and hardware-software integration testing, the complete link from communication transmission to host computer response, and so on, so that the design on the screen gradually becomes a prototype that can actually be operated.

But this is still a practice that needs verification. Whether component data is complete, whether supplier information is updated in a timely manner, and whether model judgments are reliable will all affect the results. Hardware products also need to go through actual testing and professional review, and the solutions given by AI cannot bypass these steps.

Zhao Guocheng calls this direction a shift from "Vibe Coding" to "Vibe Engineering." He hopes to extend the approach of "submit requirements and let AI write code" to hardware products, letting AI generate solutions, operate engineering tools, check and modify designs, while people make judgments and decisions at key nodes. The experience accumulated by manufacturing enterprises thus becomes the basis for guiding AI work, shortening the distance from an idea to a hardware product.

Division of labor between a manufacturing veteran and a young team

Cong Zelong's team is closer to concrete execution: discovering needs from processes employees complain about, making tools by hand, and then bringing problems exposed during use back for adjustment.

The two are not simply "the boss pays and the young people do the work." Whether the patent drawing tool should charge fees or be open source was a discussion around the product roadmap. Zhao Guocheng saw the possibility of commercialization, while Cong Zelong raised considerations regarding security, deployment, and the ecosystem, and ultimately the company chose to open the tool first.

So-called AI Native is not just about employees knowing how to use prompts or mastering a few tools. More importantly, it is about whether an enterprise can reorganize work: capturing the links that originally depended on individual experience, turning problems that require repeated cross-departmental communication into reusable processes, and enabling employees to discover problems faster, try out solutions, and then verify them through real use.

Pisen already has some conditions that can support this attempt. It has a real product R&D process, material and design data accumulated over many years, and supply chain and production links as application scenarios. The team is not discussing in the abstract what AI can do, but can put tools into actual work and observe whether they are effective.

It is reported that after Zhao Guocheng gave his approval, both Pisen's overall AI transformation and AI-related sharing, reviews, recruitment, and assessment are led by Cong Zelong's department. Cong Zelong also said that in AI briefing sessions and innovation activities organized internally at Pisen, the company gives AI application bonuses to all colleagues who share. At present, Pisen is not only willing to try more in the direction of AI innovation, but has also open-sourced some of the results so that more people can participate in testing them.

This path is not without risks. During the exchange, Cong Zelong also worried that some internal tools are only suitable for Pisen's own processes; that the needs raised by colleagues in some departments are not necessarily all worth productizing; and that even open-sourced projects may gradually stagnate if they lack users and maintainers. Even though the AI Trial, SkillHub, and the patent drawing tool have all produced preliminary results, this cannot be taken as proof that the enterprise has completed its AI transformation.

Pisen will still face some more specific questions next: whether AI tools are used continuously, whether external enterprises can deploy them smoothly, whether the R&D process has measurable improvements, and whether the time saved can be converted into shorter product cycles and a higher R&D success rate.

Right now, Pisen's AI transformation story is still far from the point where conclusions can be drawn. Its significance may not lie in how many tools have already been made, but in the fact that a traditional hardware enterprise has begun trying to change the way it solves problems: making innovation no longer always wait for formal project approval, enabling young teams to start from the business front line, and letting what is built internally undergo broader use and testing.

Starting from a single patent drawing, what Pisen is trying to build is a path connecting real needs, tool development, organizational collaboration, and external validation. Whether it can become a new competitive advantage will ultimately still be answered by the results of use. (This article was first published on TMTPost APP, written by Qian Fang)