一个让”会说话就会做应用”的开源项目，普通人真的能用吗？ 最近在研究 AI 编程学习工具时，Datawhale 团队的 easy-vibe 让我停留了很久。 它的定位一句话：“会说话就会做应用”。 听起来很理想——但马上有个疑问：我完全不懂编程，连Python都没写过，这真的可能吗？ 今天聊聊这个项目，以及它到底是怎么让”零基础”变成”做出东西”的。 先回答一个真实的问题：”会说话”是什么意思？ 很多人看到”会说话就会做应用”会有一个误解： “是不是要我学会Python才能用？” 不是。 这里说的”会说话”，不是指你会写代码，而是指你能说清楚你想要什么。 比如你想做一个”客户跟进提醒”，你不需要会写代码，你只需要告诉 AI： “我有一个客户列表，包含客户名、联系方式、上次联系日期。我希望当某个客户超过30天没联系时，微信提醒我该联系了。” 你不需要知道这个功能用什么语言、怎么写、怎么部署——你只需要说清楚你要什么，AI 来写代码。 […]

普通人的AI编程指南：不用写代码，也能用上工程级的AI助手 最近在研究 AI 编程工具时，发现了一个让我眼前一亮的东西——addyosmani/agent-skills。它把”资深工程师是怎么干活的”打包成 AI 可以复用的 Skills，GitHub 上 2.3 万星，MIT 协议，随便用。 但今天不想聊这个项目本身有多牛。想聊一个更实在的问题：普通人能不能用这套东西？用了能干嘛？ 先说人话：这套东西是干嘛的 你可以理解成：有一帮Google的前端工程师，把自己做项目的”标准流程”写成了一份”AI使用手册”。 比如你想让 AI 帮你开发一个小程序，正常流程是： 先说清楚你要什么（/spec） 让它拆解任务列计划（/plan） 再让它一步步写代码（/build）

从”AI辅助编程”到”AI驱动工程化”：agent-skills 带来了什么？ 最近在研究 AI 编程工具链时，发现了一个有意思的项目——addyosmani/agent-skills。这是一个将资深工程师开发流程打包成可复用 AI Agent Skills 的开源项目，GitHub 星标 2.3 万，fork 超过 2800，MIT 协议。 一句话定位 把资深工程师的开发流程打包成 AI Agent 可复用的

Token消耗量能衡量AI价值吗？ 最近看到一种做法：有些公司把团队成员的AI Token消耗量纳入绩效考核。理由是”用得多说明用得勤”。 这个逻辑，我认为站不住脚。 Token消耗量反映的是过程，不是结果 同样写一份招标分析报告： A用了2000个Token，完成了。 B用了500个Token，也完成了。 如果只盯着Token，B的”AI使用量”更低。但两个人产出的结果可能是一样的。那凭什么说B用得不好？ 用Token衡量AI价值，本质上是用”投入”代替”产出”，这是KPI倒置。就像衡量销售业绩看打了多少电话而不是拿了多少订单一样荒唐。 更好的评估维度：看投入产出比 评估一个人用AI用得好不好，其实就看三点： 任务完成率。分配的任务有没有按时完成，质量怎么样。这是最直接的产出指标。 时间节省了多少。以前做一个标书要两天，现在要多久？如果AI真的帮上忙了，这个数字应该明显下降。 交付质量有没有下降。不是为了快而快，快的同时质量也得过得去。 核心问题就一个：这个人用AI之后，整体效率有没有提升？ 最好的AI使用者，往往消耗最少 我观察到一个现象：真正会用AI的人，prompt往往很短。他知道自己要什么，三句话问清楚，拿了答案就走。 反而是刚学AI的人，喜欢长篇大论地描述背景，一轮轮对话来回磨。不是说这样不对——学习阶段本来就需要摸索。但熟练之后，你会越来越精准，消耗的Token反而越来越少。 所以，用Token消耗量来考核，客观上会奖励那些”还在学习的人”，惩罚那些”已经用得熟练的人”。这和管理的初衷正好相反。

我连电路图都看不懂，但把ESP32调通了 先说个真事。 今年初我想做一个康复监测系统，传感器是ESP32的。问题来了：我是个纯软件的人，模电数电加起来可能就记得一个欧姆定律。电路图？看不懂。寄存器？没碰过。PID控制？查了五分钟放弃了。 但我用了AI。 三个月后，系统跑起来了。传感器数据上报到EMQX，实时显示在网页上。家里人问我怎么做到的，我说AI帮我写的代码。他们不信。 我信了。 硬件开发为什么难住了一批人 软件圈子的人想玩硬件，第一反应是”太难了”。这个难不是假想的，是真实的： 环境搭建，能劝退一批。Keil、STM32CubeMX、Arduino、PlatformIO……光装开发环境就能折腾一天，还不一定能跑通第一个程序。 调试更难。软件bug好歹有日志、有断点、有报错信息。硬件出问题，要么烧了、要么不响应、要么莫名其妙好了，你都不知道发生了什么。 还有第三层：硬件知识储备。写驱动要懂通信协议（I2C、SPI、UART），调传感器要懂参数含义，改配置要看芯片手册……这不是一晚上能补起来的。 所以很多人有想法，但死在第一步。 AI改变了一切 不是说AI能替你学会硬件，是说你不需要从零学会硬件，就能做出东西来。 核心逻辑是这样的： 你描述问题，AI帮你查资料、生成代码、解释错误。你负责判断对不对，不对就让它改，对了就继续。你不需要懂每行代码为什么这样写，只需要懂你的业务逻辑。 举个例子。我要让ESP32读取EMG传感器的数据，MQTT协议上报到服务器。我完全不知道EMG的通信协议是什么，但我知道我要的是”原始数据转成数值”这件事。 我就跟AI说：我要用ESP32读取EMG传感器数据，通过MQTT发送到EMQX broker，broker地址是192.168.1.100:1883。 AI给我出了第一版代码。我烧录进去，不工作。

痛点：为什么 AI 生成的代码总是”差点意思” 用 AI 辅助开发，大家都会。但真正用过的人都知道：AI 生成的代码往往”看起来对，跑起来有问题”。尤其是涉及 UI 组件库时，API 用错、属性名写错、上下文缺失……这些问题会浪费大量调试时间。我之前也踩过不少坑，直到我找到了正确的协作流程。 核心问题是：AI 缺乏对项目上下文的准确理解，也缺乏对组件库 API 的精准记忆。 解决思路：用对步骤，让工具做它擅长的事 后来我摸索出一套高效的工作流，核心只有两点： 第一步：用官方 CLI 初始化项目 →