一、先唠唠我们这行的难处
干 AI 硬件的，大概都见过这种场面。
一个小团队，五六个人，算法做得挺漂亮，demo 视频发出去反响也不错，投资人约了好几个。结果人家问一句"样机带了吗？"，团队就哑巴了。算法有，demo 有，就是没有一台能真正跑起来的机器。
这真不是个例。全球做 AI 硬件的早期团队，大部分都卡在这里。你说他们没想法吗？不是。没技术吗？也不是。问题是------做硬件这事儿，跟写软件完全是两码事。
写软件，你改完代码点一下运行，几秒钟出结果。做硬件，你改个引脚配置，重新编译、烧录、上电、看日志，发现 I2C 没通，再查是不是复位脚没拉对，半天就过去了。
所以很多团队的选择是：要么自己招人搭硬件团队------贵，慢，还不一定招得到合适的；要么找外面的方案商------起订量高，周期按季度算，沟通链路长得要命。最后产品验证就卡在"最后一块硬件"上，融资节奏全乱。
我们公司 Kickers.ai 干的就是帮人解决这个问题的。客户说一句话，比如"我想要个能识别宠物情绪的摄像头"，我们几周之内给他一台能跑的原型机。从光学、硬件、驱动到算法，全包干。
听起来挺快是吧？但说实话，这"几周"背后全是人在堆。选芯片要人选，画板子要人画，写驱动要人写，调算法要人调，连找客户需求这件事，都得运营同学每天在各个社媒平台上一条条翻评论。
我最近就在想，能不能让这事儿再自动化一点？正好 DeepSeek 月初开源了个东西叫 Harness，简称 dsh。我研究了几天，觉得有点意思，跟大家聊聊。
二、dsh 是个啥？
先别被名字唬住。这玩意儿说白了，就是给大模型装了一双手。
你平时用 DeepSeek 或者 GPT 聊天，它就像个特别聪明的顾问------脑子快，懂的多，你问啥都能给你说几句。但它也就动动嘴，没法真的帮你干活。它不能打开你电脑里的文件，不能敲命令，不能帮你改代码，更不能帮你烧固件。
dsh 干的事，就是给这个顾问接上胳膊和手。接上之后，它就能自己打开文件看，自己敲终端命令，自己上网查资料，自己把一个大活儿拆成几步一步步干完，干完还能自己检查对不对。
官方给了个公式，挺形象的：Agent = Model + Harness。 模型是脑子，Harness 是身体。
它还有个说法叫"一切皆插件"。这个我比较欣赏------就跟我们做硬件的模块化设计一个道理，读文件是一个模块，敲命令是一个模块，连它自己怎么思考都能换。你想加个新能力，插个插件就行，不用把整个东西推倒重来。
目前有几个模式：标准模式就是个完整的编码助手，代码模式更灵活一点，让模型自己写代码来调工具，还有个极简模式用来测模型能力的。具体的你们自己去看文档，我就不照搬了。
不过有句话得说在前头：这玩意儿现在还是 v0.1 开发者预览版，刚出来没几天，API 说变就变。官方自己都写了，适合尝鲜，别直接拿去跑生产。这个行业待久了都知道，第一代的东西，看看就好，别太上头。
三、那这玩意儿到底能用？
我琢磨了几天，觉得能用，而且能用的地方还不少。我按从易到难的顺序说，你们看看有没有道理。
第一个：社媒上扒需求，这个最实在
先说个最容易落地的。我们做海外市场，社媒铺了一堆------TikTok、Instagram、YouTube、LinkedIn、Facebook，韩国人用 KakaoTalk，日本人用 LINE，还有 WhatsApp 和邮箱。
公司内部把这一步叫"需求雷达"，意思就是从这些渠道里把潜在客户的需求捞出来。
以前怎么干呢？ 运营同学每天早上打开五六个 App，一条条翻评论和私信。看到像需求的，复制到表格里。碰到西班牙语的、日语的、韩语的，还得复制到翻译软件里翻一遍。一天下来，眼睛花不说，还经常漏。
用 dsh 怎么干呢？ 给每个平台写个采集插件，让它定时自己去拉------TikTok 的评论、Instagram 的私信、YouTube 的留言、邮箱里的询盘，全汇总到一块儿。然后它自己翻译，自己判断：这条是纯吐槽？是问价格？还是真的有需求？如果是需求，它还能帮你提炼出来：想要啥产品？用在啥场景？有啥具体要求？
我给你举个例子。TikTok 上有人评论说："I wish there was a small camera that could tell me when my cat is vomiting while I'm at work."
搁以前，运营同学看到了，翻译一下，记下来。用 dsh 的话，它直接给你输出成结构化的：
需求类型：宠物监控摄像头 场景：主人上班时远程监控 功能点：识别猫咪呕吐行为 形态要求：小型 热度：点赞 200+，高优先级
你看，省了多少事。运营同学早上来，表格里已经是翻译好、分好类、排好序的需求了，直接挑重点看就行。
再往前走一步，它还能帮你自动回复。常见问题比如"你们周期多久""大概多少钱"，它根据公司资料直接答。碰到真有需求的，它还能自动追问几句澄清需求------"您是室内用还是室外？对设备大小有要求吗？"------把信息收集全了再转给工程师。
我们说"48 小时内给可行性初判"，有这玩意儿帮忙，说不定 4 小时就搞定了。
而且最关键的是，这些需求收集完了，不用再人工录入系统，直接就能进到后面的开发流程里。一条评论，可能就是一个项目的起点。
第二个：给工程师当助手，这个最直接
这个就不用多说了，跟 Claude Code、Cursor 一个道理。
写驱动的兄弟都知道，一天下来真正花在"想"上的时间没多少，大部分时间在查手册、翻寄存器、改设备树、编译、看报错、再改。这些活儿，说难听点，熟能生巧，但就是耗时间。
有 dsh 帮忙，你说一句"帮我在 RV1106 上把 OV5640 的驱动写了，1080p@30fps，MIPI 接口"，它自己去翻 SDK 里的参考驱动，自己查寄存器配置，自己写代码，自己编译。编译报错了它自己看错误信息，自己改，直到编过为止。
你就坐在旁边审代码就行。这不等于给每个工程师配了个不睡觉的初级工程师吗？
当然，硬件相关的代码它不一定一次就能写对，毕竟很多寄存器配置芯片手册里写得也含糊。但它能帮你把架子搭起来，把重复性的活干了，你专注在关键问题上，效率肯定能提一截。
第三个：POC 流程的总指挥，这个最有想象空间
这个是我觉得最值钱的用法。
我们的终极目标是什么？"一句话生成硬件"。客户说要个啥，系统自动把原型做出来。这事儿听起来玄乎，但拆开来其实就是一串步骤：
第一步，理解需求。要识别老人跌倒，那就是人体姿态检测。 第二步，选芯片。姿态检测算力要求不高，RV1103B 就够了，便宜。 第三步，选传感器。室内用，选个低照度表现好的 CMOS。 第四步，配 BSP。传感器驱动、推理框架全配上。 第五步，部署算法。模型转成芯片能跑的格式，量化、适配 NPU。 第六步，联调测试。跑起来看看效果，帧率够不够，精度达标不。
这一串步骤，现在全靠人来串。项目经理盯着进度，工程师之间口头沟通，出了问题来回拉群讨论。
dsh 在这儿能扮演什么角色？总指挥。
你把每一步都做成插件------芯片选型插件、传感器选型插件、BSP 配置插件、算法部署插件、测试插件。然后 dsh 就像个项目经理，按顺序调用这些插件，一步一步往下走。哪一步出错了，它自己判断是重试还是换个方案。
以前一个项目经理加几个工程师，三周交付。以后 dsh 自动调度，工程师只在关键节点把把关，说不定一周就能出来。
而且你发现没有，刚才说的第一个场景（社媒找需求）的输出，直接就是这个流程的输入。社媒上发现一个需求 → 自动澄清 → 自动评估可行性 → 自动创建项目 → 自动开发。整条链路就通了。
这才是真正的"AI 辅助研发流水线"。
第四个：BSP Agent 的参考，这个跟我们组最相关
我们 Agent 平台组做的 BSP Agent，说白了就是让硬件配置能自动化。客户换个传感器，不用工程师手动改，Agent 自己把设备树、驱动、配置全调好。
dsh 对我们的启发有两层。
一层是架构上的参考。它这个"一切皆插件"的设计，我们完全可以借鉴。不同芯片做个适配插件，不同传感器做个驱动插件，不同算法做个部署插件。以后换组合了，插拔插件就行，不用重写代码。干硬件的都懂，模块化设计有多重要------今天客户要 RK3588，明天要 RV1106，后天又要 CV1812，你要是写死了，改起来想死。
另一层是直接拿来当运行时。如果 BSP Agent 需要模型来动态决策------比如"这个报错是啥原因？该改哪个配置？"------dsh 的代码模式就挺合适。它能让模型自己写代码、自己执行、自己看结果、自己迭代，直到把问题解决。
我给你说个真实的场景。把 IMX415 接到 RK3588 上，以前怎么干？查引脚定义、改设备树、写驱动、编译、烧录、上电、看启动日志------哦，I2C 通信失败，再查是不是复位脚没配对，再改、再编译、再烧录......大半天就没了。
要是 dsh 来干呢？你说一句"把 IMX415 接到 CSI0 上"，它自己改、自己编、自己烧、自己看日志、发现 I2C 不通自己去查原因、自己改了再试，直到出图。
当然，这是理想状态。实际中硬件的坑比软件多得多，很多问题不是光看日志就能定位的。但至少那些"改个配置、编译、烧录、看日志"的循环，它能帮你省掉。
第五个：自动化测试，这个也挺实用
做原型的，测试占了好大一块功夫。图像质量要测------分辨率、帧率、噪点、色彩；算法精度要测------检测准不准、延迟多少；稳定性要测------连续跑 24 小时崩不崩；功耗也要测。
以前这些全靠测试工程师手动写脚本、手动跑、手动记数据、手动出报告。
dsh 来了之后，它能根据硬件配置和算法类型，自己生成测试脚本，自己执行，自己分析数据------帧率够不够、精度达标没、有没有异常重启------最后自己生成报告。
而且它有个好处，所有操作都有完整日志。干硬件的都知道，复现问题有多头疼。有了完整日志，出了问题能回放，能一步步查到底是哪一步出了岔子。
第六个：给客户用的操作助手，这个是长远的
客户拿到原型机，很多时候不会用。怎么配置视觉任务？怎么调参数？出了问题咋排查？都得找我们支持。
以后可以给客户打包一个定制版的 dsh。客户用大白话就能操作------"灵敏度帮我调高一点"，它自己改配置重启；"今天误报了几次？"，它自己查日志统计。客户用着省心，我们也省了不少售后的功夫。
不过这个是后话了，得前面的都跑通了再说。
你看，这六个场景串起来，其实就是我们整条业务线：
社媒找需求 → 工程师开发 → 流程自动编排 → BSP 自动配置 → 自动测试 → 客户自助使用
不是说换了个工具，而是整条链路都能智能化升级。
四、但是别上头，有几个坑
干我们这行的，对新技术得保持热情，但更得保持冷静。我说说几个我看到的问题。
第一，这玩意儿还嫩。 v0.1 嘛，刚出来，bug 肯定不少，API 说变就变。你现在拿它写的插件，过俩月可能就得重写。所以我的建议是，先拿来做内部工具，做技术验证，别直接往客户的生产环境里塞。
第二，钱的事得算清楚。 框架本身是 MIT 开源的，免费。但它背后调大模型是按 token 收费的。你让它每天帮你扒社媒、写代码、跑测试，这 token 消耗可不是小数目。大规模用之前，先算算账，别到月底看账单傻眼。
第三，安全是个大问题。 这玩意儿能读你电脑的文件，能敲命令，能调社媒 API。等于你给了 AI 一串钥匙。公司内部用，权限得管好，沙箱得隔离好。不然哪天它不小心把客户的保密方案给传出去了，或者把重要目录给删了，哭都来不及。
第四，技术栈对不对得上。 dsh 是 TypeScript 写的。我们做嵌入式的，主要写 C/C++，做算法的写 Python。要深度集成的话，得有人懂 TypeScript，或者通过接口来适配。这个人力成本得考虑进去。
第五，数据合规和保密。 社媒上的用户数据，得符合 GDPR 那些规定。客户的项目方案，哪些能传给大模型、哪些不能，得提前定好红线。还有自动回复这事儿，一定要谨慎。价格、交付周期这种敏感信息，必须人工审核了再发，别让 AI 张嘴就来，到时候兑现不了就麻烦了。
五、那具体怎么干？我建议分三步
说了这么多，到底怎么落地？我是这么想的。
第一步，先把社媒需求雷达做起来。 这个最容易，见效也最快。先别贪多，就接 TikTok 和邮箱两个渠道，就做"采集 + 翻译 + 需求提取 + 分类"，自动回复先不上。每天早上出一份需求摘要，运营同学用两周看看效果。同时找一两个工程师装上 dsh 当编码助手试试水，摸摸这玩意儿的底。
第二步，挑一个具体流程做端到端验证。 比如就做"传感器自动适配"------输入个传感器型号，它自动生成驱动、改设备树、编译、烧录、验证出图。这个跑通了，说明方向是对的。同时社媒那边可以慢慢加平台，加上需求打分排序，常见问题的自动回复也可以试试，但一定要人工审核。
第三步，再决定要不要深度整合。 前两步跑了两三个月，数据也有了，坑也踩了不少，到时候再决定是把 dsh 深度整合进 POC Studio 平台，还是只借鉴它的架构自己搞，或者就当内部工具用不进产品。
别一上来就 all in，干硬件的都知道，步子迈大了容易扯着蛋。
六、最后说两句
对于硬件，我最大的感受就是------这行太慢了。 软件行业一周一个迭代，我们一块板子打样就得两周。AI 发展这么快，硬件老是拖后腿。
dsh 这种东西出来，我觉得是个信号。以前 AI 只能帮你写写代码、查查资料，现在它开始能真正动手干活了------能操作文件、能调工具、能编排流程。虽然现在还很初级，但方向是对的。
对我们做 AI 硬件的人来说，它最大的价值不是多了个编程助手，而是有了一个可能------把"找需求、做原型、交付客户"这整条链路，用 Agent 串起来，真正自动化起来。
当然，现在说这些还早。但技术这东西，你早点研究，早点试错，等它成熟的时候你就跑在前面了。等所有人都看明白了再进场，黄花菜都凉了。
