HOW TO WORK WITH TAI-IOT
One engineering task, in natural language
From connecting the client to reviewing the project changes and test results. Select a step below to see where it happens, what you do and how the system completes the task.
Real tasks run on your development computer and in your AI client. This example uses a Linux host C project, so no development board is needed.
Follow one task through the full workflow
Example: sampling period 1000 → 500 ms, alarm threshold 60 → 28 °C.
Set the trial toolkit folder
The folder that holds the archive and the .sha256 file; replace it with your own. After you apply online, the download links are sent to your email, see Get started. Run the later steps in the same terminal to keep the workspace variable.
Prepare the development computer
- What you do
- Prepare the development environment and a signed-in AI client.
- What the system does
- Checks the project dependencies and build prerequisites.
- What you should see
- Diagnostics and automatic demo output.
Run in a terminal on the development computer · replace the example path
Tool execution in this example · 0 / 5
- Read the project
Look at the configuration and C source to confirm the target and the scope of the change.
Waiting - Change parameters
Change the configuration with the engineering tools and keep a diff for review.
Waiting - Run the compiler
Tai-IoT runs the local C compiler and returns the real output.
Waiting - Run the tests
Run the built program and check sampling intervals and alarm boundaries.
Waiting - Get the diff
Read the local Git diff for the client to explain and the engineer to review.
Waiting
How it works
How one request becomes engineering work
The AI client understands and plans the task, and Tai-IoT carries out the engineering work on the development computer. Each result goes back to the client, which decides the next step and explains the outcome to you.
- 01 / Engineer
Give the task
Describe the change, the project scope
and the acceptance criteria - 02 / AI client
Understand and plan
Uses the project context
to plan the steps - 03 / Tai-IoT
Do the engineering work
Read, change, build and test,
then return output and diffs - 04 / Engineer
Review and confirm
Check the diff and test records,
then deliver once confirmed
← Each result goes back to the client: it continues on success, and explains or adjusts its steps on failure.
Where is the project? The source and development tools stay on the development computer; the model is reached through the client you choose.
Which model? Any model service your client supports. For cloud and enterprise model conditions and what data is sent, see the setup options.
Real devices
Boards and test devices connect to your development computer
With a chip support pack, the AI can download, test and analyze logs once an engineer confirms, then hand the results back for review.
Download and debug
Tell us the chip model, board and debug probe you use, and the support pack is adapted for download, verification and debugging.
Communication and logs
Describe how the device communicates and its protocol, and the AI can send and receive test data, collect runtime logs and analyze the results.
PLC projects
Evaluated project by project, working through the official interface provided by the vendor's engineering software and using the customer's own licensed copy.
Device operations are enabled only for designated test devices and run after an engineer confirms. Hardware access comes with chip and PLC support packs; applicable models, tool versions and scope are listed under support packs →
Explore the engineering detailsParameters, build state, simulated tests and error paths
This is an in-browser preview of the project rules that shows the order in which the tools work; it does not run local tools, a compiler, a model or hardware.
- 01 · Read projectNext
- 02 · Change parametersWaiting
- 03 · BuildWaiting
- 04 · Simulated testWaiting
- 05 · Review diffWaiting
project.json · current preview parameters
Parameter diff
The diff appears after the review step.Tools and execution order
Simulated checks preview
| No. | Simulated time / ms | Temperature / °C | Status |
|---|
Project logic
Parameters go into the build; checks cover the boundaries
From the demo project's C application. The build tool writes the configuration to config.h; the tests check period timing, clock wraparound and the alarm threshold boundary.
firmware/telemetry.c · logic excerpt
static int sample_due(uint32_t now, uint32_t previous)
{
return (uint32_t)(now - previous) >= SAMPLE_PERIOD_MS;
}
static int alarm_active(int temperature_deci_c)
{
return temperature_deci_c >= ALARM_THRESHOLD_DECI_C;
}How the local project is verified
The sampling clock uses an unsigned 32-bit difference and temperatures are compared in 0.1 °C units. The simulation prints 10 samples, and the tool then checks the interval between consecutive samples.
The example is a host C project with a simulated clock and synthetic temperature data; no sensor or development board is needed.
View the test record
This example was tested with natural-language tasks on Codex CLI 0.162.1 / gpt-6.1-sol / Linux, using prompts written in Chinese: the model called the tools itself to change parameters, build for real, run simulated tests and review the diff. The walkthrough on this page and the real run records are shown separately.
Start on your computer
Apply for the free trial and run it yourself
After you apply online, the download links are sent to your email automatically. The toolkit includes the host example and the development board example; model costs are your own. Get familiar with the example first, then confirm the tool and hardware adaptation for your project.