需要写在前面的话:
全自动机器人的所有代码都由人来主导，AI进行编写
手动机器人的所有代码都由人来写，AI进行辅助
这两份代码都经受住了赛场上的考验以及现实复杂工况的适配，其中种种妙处，由读者自行分析和辨别。
在这里我会详细阐述，如何用AI写一个工程，如何利用AI的能力在板载设备（犀牛派X1）上进行调试，如何在有限的时间内让AI写出价值最大的代码。
我先给出在犀牛派X1上运行的代码仓库，并进行详细的阐释
编写一台全自动机器人的代码，最重要的是搭建一个可复用，可维护，可持续利用的框架。
在当前这个古法编程向AI coding快速转型的时代，这套框架，一方面要满足人的易读性(方便人的理解)，一方面要满足AI如何快速了解项目上下文，进而快速编写符合语境的代码。
经过笔者近一年的探索与研究，将Harness engineing的工程思想融入到我们的机器人代码开发中，这个思想是 Prompt Engineering和 Context Engineering的延伸，也是当前AI编程时代的一种工程范式。
核心理念是 “Human Steer, Agent Execute”（人类掌舵，智能体执行）。
先简单陈述一下 Prompt Engineering和 Context Engineering。
诸如像我们人在与AI聊天框输入的文字，如:“今天天气怎么样”，“你帮我检查一下”，这样与AI直接交流的自然语言被叫做promot，在AI幻觉频发的时代，如22年，23年，人们常习惯丰富promot的内容，把promot描述的足够细致，再让AI来进行解决相关的问题。
随着AI的发展，大模型的上下文从8k，16k到32k，200k，再到现在的1M，2M，单独promot的内容明显不符合大模型越来越大的上下文的迭代趋势，于是人们开始倾向于让模型在读取工程的过程中，让大模型开始自行去理解分析，只要给他足够有用的上下文，大模型便能轻而易举的理解到工程师的意图以及项目的现状。所以诞生了新的概念，叫做Context Engineering。
AI项目开发中，有一个很经典的文件，叫做AGENTS.md。每当新开一个对话，描述需求，按下回车键之后，这个文件里面的内容就会自动注入大模型的上下文。一般我们会在这里面告诉AI需要遵守的事，不能做的事，这也就是Context Engineering的雏形，人们把工程中已经实现的，落地了的部分告诉大模型，让他把这部分当成已知的先验情况，而不是每次都需要去猜测工程师的意图。
除此之外，工程代码中的每一处注释，每一份README文件，每一处描述工程的文字，都会帮助大模型理解你的工程，所以在这个Context Engineering的迭代中，出现了如planning，hook这样的思想，比如先计划再执行，或者说在agent执行到特定时机的时候注入一段上下文，让大模型强制根据这段上下文进行思考。
随着大模型的继续迭代，25年末到26年初时，GPT5.2和Claude4.5的发布，正式引领着新编程时代的到来，此时的大模型正如网上铺天盖地的宣传那般，能反复思考，反复迭代，具体的原理笔者没有详细的去深究，但以GPT为例，从思考的部分过程中，能清晰看到这些模型能根据人类的意图，去反复读取工程中的细节，会复用已有的框架做最小的代码修改，这也对应了很多网上人的担忧，AI如此强大，人是否会被淘汰？
但如果AI真像吹嘘的这么万能，大模型公司也就不会铺天盖地的讲故事了。所以又诞生了新的概念，叫Harness engineing，它回归到以人为本的核心观念，人类始终是工程的掌舵者，智能体永远没有自己独立的思想，再怎么好用，仅限是工具层面的，人始终要对自己的项目有着清晰的把控。
Harness engineing本质上是一套约束方法，约束住大模型的思考空间，像一根缰绳一样套住大模型，让他只能根据人发送的promot，读取工程中的context，来进行思考和理解，正如我们比赛代码中的 docs，能很清楚的看到，我们用了怎样的方式去约束模型的思考，这种方式非常有效，极大减少了模型的在上下文不足的时候的一堆假设。
言归正传，继续介绍当前项目。
可以看到，在我们的具体工作项目树中，不同的模块承担了不同的职责，人方便阅读，模型也方便去理解，也和我前面描述的一致。
那怎么去调试呢？该怎么调试呢？
这是在开发过程中遇到的最大的问题，不是人亲手写的代码，让AI写，人始终会怀疑当前这份代码真的能行吗？
这也是区分一个人是否真的能hold住AI的关键。
这里我总结了几点关键要素：
1.自信。如果连自己让AI写的代码，都不自信，那在后续迭代的过程中，你自己也会丧失信心，慢慢产生怀疑。
2.测试，反复的测试。光有足够的心理素质也不行，每一份代码的功能都需要经过人的手去验证，如果有问题，根据现象反推代码逻辑，再结合聊天上下文思考原因所在。
3.调试，这也是重中之重。
对于上位机工程师，要想办法定位对应的功能代码，通过日志去展现，通过合格的框架，让AI去理解问题，有效的描述现象，及时的git，是定位问题的关键。
对于下位机工程师，要熟练的运用软件的debug功能，配合上位机工程师，锁定数据去哪儿了，判断是功能性的缺失，还是代码逻辑的漏洞。
当然外在的运行工具是不可缺少的。
这里我要高歌犀牛派X1的低功耗和高算力，在时间最紧迫的那段时间，我们直接让AI运行在犀牛派上，代码改完就能直接验证逻辑，不会担心几分钟就把电池的电量耗完了的情况。并且在验证定位逻辑和算法实现的过程中，长达近两个小时的时间，我们让AI自行根据现状，拉起相关节点，进行代码验证，自行录制相关rosbag数据，自行进行代码调试，最后排查出了相当多的问题，也确定了今年赛事我们最后的导航方案。
除此之外，犀牛派提供的web端界面，让我们能极快的进入主机界面，观察相关启动日志，大幅提高了调试效率。并且在反复上电断电测试开机自启动程序的时候，展现了极强的鲁棒性，并不会出现串口断连，雷达IP消失等不可控情况，是我目前使用过的，最让人舒心的一块算力板。
如何在有限的时间内让AI写出价值最大的代码呢？
正如我之前说的，一定要有一个让AI能快速理解你项目的框架，有限的时间里让AI的能力得到无限的放大，人来进行掌舵和判断，加上对自己的自信，结果一定不会辜负你的期望。
最后的最后，我相信，如果一个人具备了我说的这些素质和条件，哪怕是再困难的情况，也能在最关键的时候，展现无与伦比的力量。
后续的机械图纸以及PCB文件也在整理中，敬请期待