跪拜 Guibai
← Back to the summary

A 3D Tech Radar Built on AIHOT: Curated News, Multi-Platform Drafts, and an Agent-Automation Future

Using Codex, I remixed the open-source AIHOT from "Card God" (卡神) and made my own version.

The name is simple: "3D Technology Radar".

At first, I just wanted a place to collect new things in directions like Three.js, Shader, visualization dashboards, and digital twins. But the more I modified it, the more requirements I had. Now it also handles topic selection, writing, image matching, layout, and content archiving.

01｜What is AIHOT?

Let me start with AIHOT.

AIHOT provides basic capabilities for building an industry hot-topic site. It collects content from your configured sources, deduplicates, filters, scores, then organizes summaries, grouping different reports of the same event into hot topics and reports. You can replace the areas, sources, and filtering criteria to build your own version.

Project address: https://github.com/KKKKhazix/AIHOT

02｜Focusing information filtering on 3D engineering practice

For me, this starting point was quite suitable.

The collection, filtering, and event organization basics were already done. I could focus on a more specific question.

What kind of technical news is worth a front-end and 3D developer's time?

Does a newly released Three.js plugin have source code and a demo? Can a Shader effect be understood in terms of how it is implemented? Does a digital twin case study, besides a showcase video, explain how the data connects and how the scene is organized?

These are the kind of things I want to chase.

So, I narrowed the focus area to visualization dashboards, 3D technology, Three.js, digital twins, Shader, and AI+3D.

But just changing the categories was not enough.

When I first ran it, the list still mixed in generic AI news, even protein 3D structures. Those have their own value, but they are far from the Web 3D projects I do today.

Then I realized that giving the system a "3D" keyword might trigger a much broader understanding than you expect.

I further tightened the filtering criteria toward engineering practice.

Content with source code, runnable demos, specific tutorials, or important version changes takes priority. Summaries should also clarify what problem the thing solves and what resources you can continue to look at.

Original links must be kept. When something interests me, I still click in to read it, and pull the code if needed.

I want to open this page and quickly find something worth researching.

03｜Adjusting the retrieval rhythm, prioritizing recent content

Then the second problem appeared.

It collected too much.

Previously, the page piled up thousands of items waiting for analysis, but model call quotas were limited. Old material was still queued, new messages kept coming in, and the pile only grew.

The tool I made for myself almost became another inbox I needed to clean every day.

Later, I adjusted the new online hot-topic retrieval to every six hours, with automatic analysis prioritizing material from the last forty-eight hours. Older data remains stored and can be manually analyzed when needed.

This adjustment is simple but necessary.

For my personal use case, handling the most recent content first leaves room to think about the rest later.

04｜From one hot item, generate content for five platforms

What I most wanted to add next was creation.

When I see a message worth telling, there is usually a lot of work to follow. I have to find the original, think of an angle, gather materials, judge who it is for, then start writing.

I wanted to do these steps in one place as much as possible.

So, on top of AIHOT's hot-topic discovery, I added a creation workbench.

Now I can enter creation from an already-collected item, taking along the source and summary, and adding the angle I want to talk about this time. If I have my own hands-on notes, they can also be included, then I choose which platform drafts to generate.

Xiaohongshu, Douyin, Zhihu, Bilibili, and WeChat Official Account are all options.

But my requirement for this was what each platform actually needs to deliver.

For example, suppose I want to talk about a new Three.js effects library.

Xiaohongshu can be built around several intuitive effects as images and text. Bilibili can arrange an integration demo. In the WeChat article, I would rather discuss what projects it suits, what to consider when integrating, and which parts still need your own verification.

The same topic is worth reorganizing according to the way people read and watch.

Of course, after generation, it still needs editing.

I can modify the draft, view history versions, or regenerate content for just one platform. My own modifications must be kept, and reference sources should follow the draft.

Anything involving my own tested results, performance data, and personal experience has to be verified and supplemented by me.

Model integration also got a configuration addition. Retrieval and creation can each select different models. Currently it can connect to a local Codex, and also configure online model APIs or local models, depending on your usage conditions.

05｜Connecting Notion archiving and 墨排 editing

At this point, I started to dislike the layout work again.

After finishing a draft, I copy it out, then re-handle titles, quotes, images, and spacing. The content is already here, but it still has to be moved several times later.

So I connected Notion and 墨排.

Titles, quotes, code blocks, and images can be previewed directly for layout effects. Once satisfied, sync to 墨排 to continue processing.

This part has already been walked through with an actual draft. A Xiaohongshu draft, along with four matching images, was synced from the radar to 墨排.

I care about these small things.

Because when you create content, whether images survive a copy, whether edited drafts get overwritten, often determines whether the tool is something you are willing to keep using.

06｜Daily, weekly, monthly reports, with multi-ratio export

For daily, weekly, and monthly reports, I also added a step for self-media usage.

The report's basic capabilities come from AIHOT; I mainly added export and layout adaptation.

Short content can be combined on one page, longer content gets paginated, keeping mobile reading in mind.

This part also went through rework. It looked fine in the web page, but after export the text was small, dense, and looked like a shrunken web page, still unusable. Later I continued to adjust font size, white space, cover, and content hierarchy.

Honestly, many features were made this way.

Whenever a step felt awkward, I went ahead and fixed that step.

07｜Recording publication results, giving the next creation a basis

After that, I also left an entrance for reviewing results.

After content is published, I can manually fill in data or import a CSV, recording metrics such as reads, plays, saves, comments, shares, and follower growth, then analyze them together with the actual drafts.

What I care about more is which content made peers want to save it, and which questions actually sparked discussion.

When comparing, I also try to keep the same platform, same account, and a similar observation window. An article published just a few hours ago and one published seven days ago, if directly compared by read count, the conclusion can easily go wrong.

The system can use these data to give suggestions for the next round of creation, but whether to adopt them is my decision.

However, this part still needs real publication data to accumulate slowly. If the sample is not enough, then admit it is not enough. I'm not yet able to show a long-term result saying it has learned how to write viral content.

For now, I hope more to understand which content is genuinely useful to readers.

This step I have not yet verified specifically; I will continue to add to it later.

08｜You too can build your own industry hot-topic platform

After all this tinkering, looking back at this project, the thing I most want to share is this.

An open-source hot-topic site can become a very specific personal work tool.

AIHOT helped me build the foundation for collection and organizing information. On top of it, I added my own professional direction, filtering criteria, and creation methods, then connected the Notion and layout tools I use daily.

It gradually became the current 3D Technology Radar.

If you want to do something similar, you can start from your own field.

If you do front-end, follow framework updates, engineering practices, and cases with source code. If you do design, center on design tools, interaction, and working methods. For other industries, similarly, first list the questions you care about long-term.

Don't rush to stuff in all features. You can follow these four steps.

  1. Identify a specific field. List the questions you care about long-term; start with a small scope.
  2. Pick reliable sources. Start with official blogs, open-source projects, and professional communities you often read. Write clearly what you want to see and what content you don't need.
  3. Run a basic version on top of AIHOT. The open-source repository provides templates and customization instructions; configure sources and filtering rules according to your field.
  4. Keep adding features based on actual use. Wait until you are willing to open it every day, then consider integrating creation, layout, archiving, and review.

My version was built this way, little by little, through use and rework.

Thanks to Card God for open-sourcing AIHOT, so I could start from an already-built foundation.

As for what I plan to turn this radar into next, the criterion is simple.

The next time I plan a 3D project or write a technical article, I open it and find something worth clicking into, reading the source, and trying hands-on.

Then it has helped.

09｜Finally

During this time of using AI, I've noticed my role quietly changing: more and more work is handed to AI, and I mainly take care of two ends, giving instructions at one end and accepting deliverables at the other, with fewer and fewer correction steps in between.

So I believe that every work scenario and platform should integrate AI-specific capabilities.

In 3D visualization dashboard work, I integrated my workflow with AI, letting the whole process run by itself. I only need to pose a visualization idea, and it can complete the whole journey from conception to delivery, finally producing a runnable dashboard.

Scope and delivery

In 3D technical news acquisition, I integrated AI's ability to fetch information and turn it into content creation. I no longer have to rack my brain for topics; the time from getting information to producing content keeps shrinking.

But at this point, I found a new problem: these capabilities are scattered across different platforms, and my time gets sliced between many entrances.

So I made a Codex-based workbench, conceptually similar to Apple's Shortcuts. It wraps the capabilities and task flows of various platforms, and executes them with one click. It both extends Codex's abilities and orchestrates the platforms and tasks Codex has already built.

Later I read Card God's article "After tinkering for a full year, I share without reservation this Agent automation system of mine.", and realized this step still needs further simplification.

Shortcuts solve "scattered entrances", but the starting point is still me: if I don't click, it doesn't move. When there are more and more platforms and tasks, even if I only do acceptance, I have to constantly switch, check, and confirm, many of which don't actually need my personal attention.

I had done some related exploration before, but when compared with Card God's architecture, I realized my thinking was still limited.

To borrow a phrase from Card God's article: a person can usually only follow 3 to 5 active conversations at the same time. In this design, the upper limit of a single task depends on model capability, while the upper limit of multi-tasking depends on human attention.

In the entire Agent system, human attention is the most precious asset and the biggest bottleneck.

**

So the next thing I want to do is evolve the workbench from "executes when I click" to "triggered by signals, advancing automatically, only involving me at key decision points." What can be handled by itself gets handled; only things that are uncertain and must be decided by me come up to me.