开头先说实话我让积木智能体从零开发一个 Todo 应用原本以为它会噼里啪啦甩给我一堆代码结果它没有。它在我面前停下来认认真真问了我两个问题。那一刻我就知道这个应用能不能做成已经不取决于AI 会不会写代码了而取决于我怎么回答。最后应用做出来了单文件、无依赖、数据不丢、手机电脑都能用。但我复盘整段过程之后发现真正值得写下来的不是那几百行代码而是它在动手前问我的那两个问题以及整个提问—回答—拆解—实现的协作流程。这篇文章就把完整过程摊开讲一遍包括我踩的坑、它的翻车瞬间、以及我自己总结的几条协作经验给所有想尝试智能体开发的人做个参考。1. 我为什么选积木智能体来开发这个应用1.1 积木智能体到底是什么先把概念对齐一下。我所说的积木智能体指的是把大模型的对话理解能力、工具调用能力和代码执行能力用可视化模块的方式拼装起来的开发环境。你不需要手写前后端工程而是像搭积木一样搭出需求理解—任务拆解—代码生成—运行反馈这几个环节中间靠自然语言来驱动。我以前对这种低代码平台挺不感冒因为大多数低代码工具的玩法是把固定组件拖到固定画布上你只能在平台预设的边界里做文章一旦需求超出边界就是死路一条。但积木智能体不太一样它每一块积木里面大模型都有相当大的自由度去做推理和生成。积木拼的是流程骨架真正干活的是模型本身。这也决定了它的适用人群。第一类是完全不懂代码、但有明确想法的人比如运营想给自己做小工具产品想快速验证一个交互方案。第二类是程序员本人拿它做原型、做一次性脚本、或者当成一个会写代码的结对伙伴。我属于第二类起初只是想看看它有几斤几两没想到被两个问题问得心服口服。1.2 和手写代码、直接让大模型生成相比区别在哪在这个项目之前我用两种方式做过同类小工具。手写一遍当然没压力半小时能出活但说实话这种重复劳动做多了很消耗耐心而且一个人从零搭页面的时间花的都是自己真正可以用来思考的时间。直接让大模型对话生成我也试过这段体验更糟糕上下文非常碎聊几轮它就把前面的约束忘了改完这里的样式那里又坏了最后变成我在替它做测试。积木智能体在这两条路之间找到了一个折中它保留了整个会话的需求上下文能自己规划任务、自己执行代码、自己读取运行结果且中间不需要我复制粘贴。这次项目我从提出需求到拿到能跑的应用没有手动拷贝过一行代码。开发方式上手难度需求理解迭代效率适合场景手写代码高全凭自己澄清中正式项目、长期维护直接对话生成低较弱容易丢失约束低一次性示例代码积木智能体低会主动澄清需求高快速原型、个人工具有人说直接对话生成你也可以多追问几句啊。话是没错但通用对话里的追问得由你自己发起你问完了还得把答案整理成一句完整需求再喂回去整个过程全靠自觉。而积木智能体是在流程设计上就把提问澄清做成了标准步骤。这也是为什么动手前先问两个问题这件事值得单独拎出来讲。2. 动手前被问的两个问题是真正的价值所在2.1 第一个问题应用给谁用、在什么场景下用它当时的原话大意是这个 Todo 应用的使用者是你自己还是要给多人协作使用你主要是在电脑浏览器里用还是希望手机上也有相对完整的操作体验我最初提交的需求只有一句话帮我做一个 Todo 应用。我本来以为这种需求已经够明确了直接生成代码就行。但它没有而是先把这个问题抛了出来。我愣了一下顺着思路往下想才发现这个问题切中的是产品的地基。为什么关键因为Todo 应用四个字根本没限定需求边界。如果是个人自用界面可以简单粗暴操作路径必须短加任务要一个回车完成如果是多人协作那就牵扯到任务归属、列表权限、操作记录整个信息架构都会不一样。同一句话两种答案做出来是两个完全不同的产品。场景还会影响界面布局。我自己主要在电脑前工作列表可以做宽一点筛选栏可以放开如果我天天用手机那就要考虑单手操作、按钮触控面积、窄屏排版。这些听起来是细节但做产品的人都明白给谁用、在哪用决定了产品朝哪个方向走方向错了后面的努力全白费。我如实回答个人自用主力电脑浏览器偶尔用手机看一眼。这个答案刚给出去它就锁定了单页应用 响应式布局两个技术方向后面所有代码都在这个框架里展开。2.2 第二个问题数据要长期保存吗要不要多端同步第二个问题大意是任务数据需要持久化保存吗如果只是临时演示我用内存数据就够了如果需要长期保存甚至要多端同步我需要帮你选存储方案。这个问题问得更狠。因为多数人想做 Todo 应用时脑子里想的都是界面和交互很少有人会去考虑数据层。但数据恰恰是所有应用的底盘。内存存储意味着刷新一下任务全没localStorage 意味着数据留在本机浏览器里换个设备就看不见如果要多端同步就得引入后端数据库和账号体系复杂度直接翻好几倍。我选择的是需要长期保存但不需要同步。单机、单浏览器、数据留在本地。这是个非常典型的个人工具需求也是成本收益比最高的选择。它听完就定了 localStorage 方案没有引入任何后端依赖整个应用交付时就是一个 HTML 文件连开发服务器都不用起。能跑、够用、足够简单这正是我想要的状态。2.3 为什么这两个问题问得专业我后来复盘这两个问题背后其实是软件开发里最核心的两个维度的投射用户与场景数据与架构。用户与场景决定产品做什么数据与架构决定产品怎么做。这两件事没定清楚之前写出的代码大概率都是返工货。反过来想就更清楚了如果它完全不问直接按默认方案把代码丢给我大概率会默认一个花哨界面加内存数据存储。我看第一眼可能觉得挺漂亮用着用着刷新一下页面任务全没了。那一刻我不会觉得AI 厉害我只会觉得它不靠谱。而它把这两个问题前置问掉本质上是在降低交付返工的概率。我把这个行为叫作需求澄清意识。写过代码的人都知道项目里最贵的不是写代码而是改需求。智能体如果在落第一行代码之前先花两分钟和你把需求边界对齐它的产出就远比你丢一句模糊需求它闭眼生成可靠。这个道理放到人类团队里同样成立需求评审会不是走形式是真能省钱的。还有一个细节值得提它问问题并不是劈头盖脸砸一串而是先问一个等我答完再问第二个。一次只问一个回答压力小给出的信息更完整。这个节奏设计我认为值得所有做对话交互产品的人学习。3. 从需求到成品的完整实操记录3.1 我是怎么回答这两个问题的这段还原一下现场方便你直接对照参考。我先给的需求是帮我做一个 Todo 应用用来管理我每天的工作任务和个人杂事。它立刻追了第一个问题使用者是你自己吗主要在什么设备上用我答自己用主力在电脑浏览器手机偶尔看看。它继续任务数据需要持久化保存吗需要多端同步吗我答需要持久化保存单机用不同步数据别丢就行。我这两个回答本身没什么含金量但回答完之后它的行为模式明显切换了。之前它还处于试探阶段得到答案后它说了句好的我理解了。这是一个个人轻量级工具核心诉求是便捷和数据安全。下面我会按这个方向开发。然后主动列了一个开发计划需求确认、界面设计、功能实现、数据层处理、自测与交付。看着它把流程列出来你会明显感觉到它是在做项目不是在写练习题。3.2 智能体把任务拆成了六个模块它自己把应用拆成了六个模块我贴出来供你参考任务输入与添加支持回车快速添加输入框为空时敲回车不产生空任务。任务列表渲染按创建时间倒序展示每条任务包含标题、创建日期、完成状态。完成状态切换点击复选框切换完成与未完成已完成任务有置灰和划线效果。删除与清空单条任务可删除提供一键清空已完成的能力。筛选与统计按全部 / 进行中 / 已完成三个维度筛选并展示当前任务数量。数据持久化每次增删改都同步写入 localStorage刷新后自动恢复任务。这个模块拆解和我平时做项目列的开发清单几乎完全一致。它不是一上来就甩一个几百行的怪物代码而是先把功能边界划清楚每个模块对应一块独立逻辑。这种先拆解、后实现的路径带来一个额外好处排查问题时定位极快。哪块出了问题直接翻对应模块就行不用从头把整个文件读一遍。3.3 核心代码逻辑长什么样代码我不全贴挑几个关键片段讲思路。先是任务的数据结构它用的是非常简单直接的对象const task { id: crypto.randomUUID(), title: 写一篇技术复盘笔记, completed: false, createdAt: new Date().toISOString() };用 crypto.randomUUID() 生成唯一 id用 ISO 字符串存时间。这个结构既能支撑渲染展示也能支撑排序筛选没有多余字段没有过度设计。我看到这个结构的第一反应是这个智能体的代码品味在线。然后是数据持久化部分function saveTasks(tasks) { localStorage.setItem(my-todo-tasks, JSON.stringify(tasks)); } function loadTasks() { try { return JSON.parse(localStorage.getItem(my-todo-tasks) || []); } catch (e) { return []; } }注意它给 JSON.parse 套了一层 try/catch。这个细节很见功力因为 localStorage 里的数据可能被浏览器清理、被用户改动过期字段、甚至格式损坏一旦解析失败整个应用就会白屏。套上异常处理之后就算数据坏了应用也能以空列表启动至少界面不会崩。说明它在生成代码时已经考虑到运行期的异常因素而不是只顾着把 happy path 跑通。再贴一段添加和切换状态的逻辑function addTask(title) { const task { id: crypto.randomUUID(), title: title.trim(), completed: false, createdAt: new Date().toISOString() }; tasks.push(task); saveTasks(tasks); render(); } function toggleTask(id) { const task tasks.find(t t.id id); if (task) { task.completed !task.completed; saveTasks(tasks); render(); } }每个操作都严格走改数据、存数据、重新渲染三步。这是非常经典的前端状态管理模式render 函数负责把 tasks 数组映射成界面筛选逻辑也全部收敛在 render 内部。整个应用没有绕弯的子函数可读性极强。我向来强调代码是写给人看的不管写它的是人还是模型可读性决定了后续能不能低成本维护。界面部分它生成的是一套极简响应式布局顶部是输入框下方是统计栏加三个筛选 Tab列表用系统默认字体和少量的 CSS 变量控制主题色没有引入任何前端框架也不需要 npm install 和构建步骤。我直接用浏览器双击打开那个 HTML 文件就能正常工作。对一个不想为小工具搭建工程环境的用户来说这种交付方式非常舒服。3.4 实测功能和体验拿到文件后我实际连续用了一整天。添加任务按回车速度没问题点复选框完成一条划线效果明显视觉反馈清晰三个筛选 Tab 切换流畅刷新页面之后所有任务原样恢复。用手机浏览器打开排版会自动变紧凑按钮点击区域够大不会老点错。我还顺手测了几个边界场景任务标题填全空格、连续快速加多条、反复点同一个复选框、把任务清空到零条、故意把 localStorage 里的数据改成非法格式再刷新。这些情况下它都没有出现崩溃或数据错乱。整体稳定性比我预期的要高不少作为个人日常工具已经完全可以上岗了。4. 实操中踩过的坑与排查技巧4.1 第一次翻车删除全选框统计数字不刷新了初始版本里有个全选按钮我评估后觉得个人工具用不上就提了一句把全选去掉。结果去掉之后统计栏的剩余任务数在特定操作下不再更新。我批量完成一批任务数字却纹丝不动。我第一反应不是自己翻代码而是把现象原样描述给智能体批量操作后统计数字没有更新帮我看一下原因。它很快定位到问题全选按钮的点击事件里同时也挂着触发 render() 的代码。按钮删掉时重新渲染界面这一句也被一起删掉了。于是批量变更数据之后界面没有刷新统计自然停留在旧值。它补了一段独立的数据变更通知逻辑问题解决。这个坑给我的启发值得单独记一笔当你对某个模块做减法时一定要检查这个模块身上是否背着看不见的职责尤其是事件绑定这种副作用。删功能不是删一个按钮那么简单它可能连带删掉了一段核心逻辑。我后来和它协作时的原则就是删掉某功能这句话后面必须补一句同时检查有没有其他地方依赖它。4.2 第二个坑我两次说你定它就真敢自己定第二个坑是我自己埋的。过程中它问过两次设计细节一次问颜色主题想要什么风格一次问要不要支持任务优先级。我当时正忙别的事两次都甩了一句你定吧。结果它真的自己定了配色用了默认的蓝灰色系优先级功能直接没做。后来我说你怎么不做优先级那是我想要的它平静地解释道在有限的上下文里它把你定理解成授权它采用成本最低、范围最小的方案所以它砍掉了非核心功能选择了最稳妥的一组默认值。这段经历让我意识到在智能体协作里你定就是一个明确的决策权交接信号。对方会按自己的默认策略走而大模型的默认策略恰恰是保守和最小化。你事后不满意不能怪它只能怪自己没给约束。我的建议是哪怕你只有模糊偏好也要说出来比如我想要优先级功能但交互形式还不确定。这句话同时传递了方向和不确定性它知道该往哪走也知道哪里需要继续探讨。沉默和放任在任何人机协作里都是最大的成本来源。4.3 数据安全与 localStorage 的几个细节再讲几个和 localStorage 相关的注意事项。第一localStorage 按域名隔离。这个 HTML 文件如果以 file:// 协议直接双击打开数据会存在浏览器默认域下面如果部署到某个网站域名下数据又会跟着那个域名走。切换访问入口后你可能会觉得数据丢了其实只是换了一个存储空间。第二localStorage 有容量限制常规情况下一个域大概 5MB存普通任务文本绰绰有余但如果哪天你想在任务里塞大量备注、甚至放图片就必须换 IndexedDB 或后端存储了。第三用户清除浏览器缓存时localStorage 会被一并清理。所以重要数据别只存在这一处定期导出备份是有必要的。最后分享一个排查思路当刷新后数据异常先别怀疑代码打开浏览器开发者工具在 Application 面板里直接看 localStorage 当前的值确认数据到底还在不在。很多时候问题根本不在代码而是数据已经被清了或者 key 变了。数据层无异常再回头查代码逻辑这条排查顺序能省不少时间。这次踩的坑和对应解法我整理成了一张速查表现象可能原因处理方式刷新后任务丢失存储 key 不一致或数据被清除检查开发者工具里 localStorage 的实际内容批量操作后统计不更新渲染逻辑随界面元素被一并移除了把事件触发与界面渲染解耦数据解析直接崩溃本地数据被改坏JSON.parse 外层加 try/catch功能不符合预期对话中未给出明确偏好约束至少抛出方向再说不确定点手机端排版错乱缺少响应式样式补媒体查询并在窄屏下实测最后再讲两句我自己的体悟。这个 Todo 应用开发下来最让我印象深刻的不是它写的代码多精妙而是提问这个环节本身。积木智能体先问问题、再拆方案、然后动手的模式实际上逼着我这个需求方把脑子里一团模糊的想法变成一条条清晰的决策。它问的那两个问题正是做产品最核心的两个起点给谁用、用在什么场景下以及数据怎么来、怎么存。过去这些事要项目经理反复拉人去开会才能对齐现在一次对话就能定下来。所以如果你也想试试这类协作方式我的建议是不要上来就提帮我做一个某某管理系统这种宏大需求先从 Todo 应用这种边界清晰的小工具入手。多经历几轮完整的提问—回答—实现—验证循环你会慢慢找到和智能体对话的节奏和分寸。等到真正想做一个正经工具的时候你们之间的协作效率会完全不一样。我这个应用下一步打算接后端做多端同步、用模型做任务优先级自动打分再往后还能对接日历自动生成任务——不过这些先不展开路得一步一步走先把基础的合作手感练出来比什么都重要。