积木智能体开发Todo应用：动手前先问两个关键问题

开头：

我坐在电脑前，打开某积木智能体平台，输入了一句需求：“帮我开发一个Todo应用”。按下回车之后，我原本期待它直接甩给我一份代码工程，结果它反手问了我两个问题。这两个问题问得我一愣，细想之后又觉得非常合理。大概半分钟后我给出了答案，然后它才开始真正动手。整个从零开发、从需求到代码到可运行Demo的过程，前后不到二十分钟。这篇文章就把这次完整经历拆开揉碎，把我看到它在动手前为什么要问这两个问题、背后对应什么样的智能体设计逻辑、以及实际生成过程中那些值得借鉴的细节，一次性讲清楚。

如果你正想用积木智能体做点真实可用的东西，或者你本身对可视化智能体平台的能力边界感兴趣，这篇文章应该能帮你少走一些弯路。我会尽量把每个环节里它“为什么这么做”的原因也讲出来，而不是只给你看操作截图式的流水账。这次开发的核心关键词只有两个：积木智能体、Todo应用。但做完这一趟之后你会发现，一个看似简单的待办事项应用，其实是检验智能体是否真正理解需求的一块很好的试金石。

1. 内容整体设计与思路拆解

1.1 为什么选Todo应用作为“从零开发”的第一目标

很多人觉得Todo应用太简单，不值得拿出来讲。我一开始也这么想，但实际操作之后我的看法变了。Todo应用正好卡在一个非常微妙的位置：它足够小，让智能体在一轮会话内就能完成从需求到落地的完整闭环；同时它又不至于小到只有一句话，因为它涉及数据存储、界面交互、状态管理、增删改查、甚至本地化数据持久化这几个基本的工程问题。

换句话说，Todo应用是“麻雀虽小五脏俱全”的代表。它不需要外部服务、不需要复杂鉴权、不需要多人协作，但凡是做过后端开发的人都知道，一个CRUD应用要做得顺手好用，需要考虑的东西其实不少。这就意味着，如果积木智能体真的可以把一个Todo应用从零开发到可运行，那么把这个能力迁移到更复杂的内部管理工具、数据看板、甚至简单的业务流程自动化上，也具备了一定的可行性基础。

我在做这次尝试前的预期是：它大概率会直接给出一段HTML加JavaScript的静态页面，或者生成一个基于某框架的单页应用。结果实际发生的事比我想象得更值得琢磨，它没有立刻进入编码状态，而是先把两个关键问题抛了出来。这说明在设计智能体时，“先澄清需求”的意识已经被内置到它的行为逻辑里了，而不是简单地把用户输入映射成代码。

1.2 积木智能体的工作方式和传统“对话机器人”的本质差异

需要先对齐一个概念：积木智能体和我以前用的AI助手类对话机器人，在工作机制上是两回事。AI助手更接近“你问它答”的模式，其中大部分回答基于已有知识做检索和归纳，它的核心是理解和生成语言。但积木智能体不一样，它至少由三层结构组成：语言理解层负责拆解用户意图，任务规划层负责把意图翻译成可执行的步骤并串起来，执行层则负责调用平台预制的能力模块来完成实际动作。这三层合在一起，才让它能够做到“不只是说，而是真正做”。

所以当我在界面上输入“帮我开发一个Todo应用”时，它的语言理解层很快捕捉到了“开发”和“Todo应用”这个组合，然后任务规划层开始逐步展开一个工程化流程。在这个流程中，需求澄清被设计成前置步骤，这很关键。因为如果用户给出的信息太少，直接动手生成的代码看着好像完成了任务，实际上可能是建立在大量错误的默认假设之上。积木智能体把“问问题”作为动手前的必要环节，本质上是在为后续的代码生成降低不确定性。

这一层机制非常像真实项目中产品经理和开发工程师之间的沟通：你会先确认核心场景是什么、数据存哪里、给谁用、做成什么样，然后才进入排期。智能体把这个过程自动化了，虽然它只问了两个问题，但这两个问题的含金量已经足以让我对它的工程化能力高看一眼。

1.3 我铺给它的输入信息原始版本长什么样

这次我一开始并没有写很复杂的需求文档，给到它的原始输入大概是这个风格：

“帮我开发一个Todo应用。要能添加任务，把完成的勾掉，还能删除。界面要简单一点，不要太花哨。”

看起来信息量很少，对吧？但它仍然能够从这两句话里提取到关键实体词：Todo应用、添加任务、完成状态勾选、删除、界面简洁。这些东西构成了一个最基础的需求骨架，后续它问的两个问题正是基于这个骨架往上补全关键信息。这也给我一个非常大的启发：使用积木智能体的时候不是非得写长篇大论的需求描述才能启动，更重要的是你要确保给的描述里包含足够明确的核心动作。

2. 动手之前的两个关键问题

2.1 它问的第一个问题：数据存储的归属

积木智能体问的第一个问题是：“这个Todo应用的数据需要长期保存吗？还是说每次打开临时记录就行？”这个问题的本质是帮我决策：数据要不要落盘，落到哪里，以什么形式落盘。

如果只是临时记录，那技术实现上就简单得多，所有数据放内存里就行，刷新即失。但实际使用一个Todo应用，谁会希望自己辛辛苦苦记录的任务，一关浏览器就全部消失？所以我选择的是长期保存。

当我回答“需要长期保存”以后，它接着补了一句细节：把数据保存到浏览器本地的localStorage。这个选择很务实。因为对于一个单机版Todo应用来说，引入后端数据库服务是明显的大炮打蚊子。localStorage容量虽然只有5MB左右，但存几千条待办事项绰绰有余，读取速度也在毫秒级别，而且不用搭服务端。它选择localStorage不是因为它只会这个，而是因为在这个场景下这是性价比最高的方案。

这里我想单独说一句：智能体做技术选型的时候，其实参考的就是工程上的“最简可用路径”原则。如果需求本身没有多端同步、多人协作这些约束，那么引入后端只是徒增成本。这一点在真实的开发协作里也是一样的，选型永远是约束条件下求最优解，而不是技术越重越显实力。

2.2 它问的第二个问题：界面语言和交互风格

第二个问题是：“你希望界面显示中文还是英文？交互上偏好极简风还是信息展示更密集的风格？”这个问题看起来只是一个小选择，但实际上它同时锁定了两个东西：一个是界面的展示语言，另一个是整体信息架构的方向。

中文还是英文，看起来就是一个字符串的事，放到工程里其实牵涉到页面模板里所有文案的统一管理，如果一开始选错，后期替换文案的成本不算高，但容易出现漏改。界面上采取极简风，意味着布局要有大间距、克制配色、主要功能集中在首屏；信息密集风格，则意味着可能要多列表、多标签、紧凑排版。

我在这一步选了中文加极简风，是因为这次做的是一个个人工具，不需要太多华丽的东西，字够大、按钮够明显、状态够清楚就够了。于是我明确回复：“界面用中文，走极简路线。”这个回答一提交，它才正式进入开发流程。从用户视角来看，这段交互只有几十秒，但站在工程角度看，这几个信息的补齐，为后续生成页面结构和逻辑代码圈定了一个非常具体的边界。

2.3 为什么我会认为“先提问”比“直接写”更高级

我自己做开发这些年，最反感的事情之一就是需求不明确就开始动手。写代码的时候每写一行都要猜一下对方到底想要什么，这种猜来猜去的过程最耗人心力。传统上我们用“需求评审会”来尽量减少这种猜测，但即使如此，评审会后该漏的细节还是会漏。积木智能体在动手前先问两个问题，本质上就是把需求评审中最关键的决策前置到了开发之前。

那我作为使用者为什么不觉得被“多此一举”打扰，反而觉得加分？因为这两个问题都紧紧围绕着一个核心目标：让它在有限的上下文里，构建一个足够精确的心智模型。存储方式决定数据层设计，界面语言决定视图层设计。这两层定了，整个工程的大框架就稳了。而它没问的问题，比如“你要不要加个日历视图”“需要云同步吗”，这些属于锦上添花的功能点，默认情况不引入反而是合理的。

这让我想到一个比喻：装修房子的时候，好的设计师一定会先问你是常做饭还是几乎不开火，卫生间要不要浴缸，这些看似简单的问题直接决定了水电位怎么布。智能体问的两个问题，就跟设计师问的一样，是内行才会想到先确认的关键变量。

3. 从问答到落地：完整开发链路还原

3.1 第一轮执行：它先把需求结构化成了一张任务清单

在我点击确认之后，积木智能体没有直接开始在编辑器里堆界面，而是做了一件非常有意思的事：它先把需求拆解成了几个结构化任务，并且以清单的形式在界面上展开给我看。大概是这样的结构：设计本地数据存储模块、构建任务添加入口、实现任务列表渲染、完成勾选功能、加入删除功能、增加数据持久化读写、最后做一遍交互联调。

这一步表面上看只是在展示工作规划，实际上是任务规划层在起作用的真实体现。它把“开发一个Todo应用”这个大命题拆成原子级的子步骤，并且规划出先后依赖关系。数据存储模块必须在界面之前完成，因为界面上的增删改查都要建在存储层之上；勾选和删除两个功能虽然看起来并列，但底层都依赖列表渲染的数据刷新机制。

我旁边的朋友看我操作的时候问了一句话：“这不就是代码生成前的项目计划吗？”我说对，而且它比很多人的计划习惯还要好，它明确划分了独立任务模块，标注了流程顺序，后续每一步生成出来的代码都跟这张任务清单严格对应。这就让整个生成过程足够透明，哪一步在做什么、做到什么程度，一眼可知。

3.2 第二轮动作：工程文件的生成顺序与内容质量

任务清单确定之后，我注意到它并没有一次性生成全部代码，而是分模块递进生成。它先输出数据层代码，也就是封装localStorage读写操作的那一段。在这段代码里，它定义了一个典型的本地存储操作类，里面包含了“获取所有任务”“保存任务列表”“根据状态过滤任务”这几个基础方法。代码风格干净利落，注释也写到了点子上。

做完数据层之后，它才开始构建界面逻辑。这里有两个细节我要单独提一下。第一个细节是它生成的添加任务输入框，不仅做了空值校验，还在回车事件里绑定了快捷提交功能，也就是说用户填完任务后按一下回车就能添加，不用专门去点按钮；第二个细节是它给每个任务项附带的勾选框和删除按钮，都绑定了明确的事件处理，而不是简单的静态展示。

这些细节能在没有明确要求的情况下被自动实现，说明积木智能体在生成代码时，不只是按模板填充，而是真的考虑了用户场景的顺滑度。一个Todo应用如果每次添加都要点按钮，或者没有空值判断，用户用起来就会觉得很难受。它把这种“常识性的交互逻辑”内置在了生成策略里，这一点我认为是它价值密度最高的地方。

3.3 第三轮收尾：从静态页面到可运行状态的最终打磨

代码生成之后，它又做了一步不可或缺的事：本地预览环境处理和交互自检。它把生成好的文件放置到正确目录结构里，起了一个可以直接在浏览器中打开的预览方式，然后进行基础自测。

这轮自测包含的内容很有意思：它检查了添加任务时输入框的Trim处理，也就是清除首尾空格，避免用户误输一个空格生成一条空白任务；检查了删除任务后的列表自动刷新；检查了刷新页面之后历史任务是否正常恢复。这三件事分别对应输入边界、视图同步、数据持久化这三个最容易出问题的点上。

我实际体验了一下最终产物：页面上方是标题，中间是输入框和添加按钮，下方是任务列表，每项左边有勾选框，右边有删除按钮。界面走极简路线，配色以白底浅灰为主，交互反馈很直接。刷新页面后，之前添加的任务完整保留在列表里，勾选状态也没有丢。整个流程下来，我除了回答那两个问题之外，几乎没有额外干预。要我用一句话形容的话就是：一个活了20年的老开发节奏被一个智能体完整地走了一遍。

4. 常见问题与排查技巧实录

4.1 需求描述中的“模糊词”会造成多大偏差

做完这次开发之后，我特意做了一个小实验：把需求里的“界面要简单一点”换成“界面要好看一点”，其他条件不变，重新生成了一次。结果生成的界面风格跟我第一次拿到的完全不同，它用了渐变背景、圆角大卡片、彩色状态标签。不能说它做得不好，但它跟我心中“简单一点”的预期差了很多。

这让我意识到，模糊词是使用积木智能体时最大的变量。“简单”“好看”“流畅”“大方”这类感受型词汇，在每个人的认知里定义完全不同。我在做前端需求评审的时候也见过太多这种因为主观形容词而导致的返工案例。所以如果你希望生成结果更贴合你的预期，最好把这种模糊词转成可量化的描述，比如“使用白底、纯文字、最小圆角、不要阴影”，这样智能体就能非常精确地执行。

提示：模糊词并不是不能使用，而是使用时你就要接受一个结果，生成出来的方案会更倾向于智能体对那个词的平均理解，而不是你的个人理解。想要贴近个人偏好，就用更具体的视觉词汇做描述。

4.2 跳过问答环节会发生什么

我出于好奇，也尝试过在第二次生成时直接要求它不要问任何问题，立刻开始编码。结果还真能绕过去，但生成出来的应用出现了两个让我记忆深刻的偏差：第一，它默认界面语言为英文，页面上的所有按钮和提示都是英文的；第二，任务数据的持久化策略被定义成了“浏览器会话级存储”，也就是标签页关掉数据就没了。

这两个偏差单独看都不致命，但放在一起就让我有一种“这事做得不顺手”的感觉。原因也很好理解，智能体没法得到明确信息，就只能用平台侧的默认参数来兜底。默认值本身没有对错，问题在于默认值不一定匹配我的真实需求。这也反向说明了一个道理：问答环节不是流程上的冗余设计，它是在用最省力的方式帮你校准默认参数。

所以如果你在搭建积木智能体的时候自己编写了需求提示词，我建议你在提示词里显式写出关键默认值，例如“默认使用中文界面”“默认数据保存在本地持久化存储中”。这样即使某个环节没有触发提问，也不会偏离预期。

4.3 生成之后修改方案的心智负担：上下文是否足够稳定

另外一个需要关注的问题是：当一个版本生成出来后，如果你想做大改，应该怎么做？我在这次实践里尝试了把极简风格改成信息密集风格，并在原来的基础上追加了“按截止日期分组显示”的需求。它确实能理解这个新的要求，并且在既有代码基础上做增量修改，分组功能也被放在了合适的位置。

但我也发现一个隐藏风险：如果后续需求改动过大，比如从单机版改成需要多人共享数据，那它的处理逻辑可能会出现退让，比如建议你重新建一个会话再做。这不是它能力不够，而是因为多用户共享带来的架构变化，跟当前代码结构之间的差距太大，在同一个上下文里做连续重构，出问题的概率会指数上升。

这里我给一个实用的习惯：如果你预感到接下来的需求改动会动到存储层或者权限模型这一级别，不要硬在原有会话里改，新建一个智能体会话重新描述需求，让它在更清晰的目标边界下生成，反而效率更高、质量更好。我在多次使用中验证过这个习惯是靠谱的。

4.4 我整理的一个快速排查表

5. 从一次成功到稳定复现：调优手记

5.1 把“灵魂提问”固化成系统提示词

我在初次的开发流程里体验到了问答前置带来的好处，于是思考了一个问题：如果我希望每一次生成应用前，它都主动把关键信息确认一遍，而不是这次碰巧触发了这个机制，我该怎么做？

答案是把提问逻辑固化到积木智能体的系统提示词里。在搭建智能体的时候，你可以在提示词中写清楚它的行为准则，比如“在开始编码之前，你必须先向用户确认数据存储方式、界面语言、视觉风格三个关键参数”。这样智能体就不是偶尔想起来问一下，而是被指令约束着必须问，规避了默认参数偏差。

我试着按这个方式修改了平台上一个自己搭建的智能体，再去做别的需求生成时，第一轮交互的质量明显稳定了很多。它每次都会在动手前把三个核心参数梳理出来，并以待确认清单的形式展现在我面前，我只需要逐项填写或修改即可。这个效率提升比我想象中更大，因为它把人和机器之间的需求对齐过程，固化成了稳定的协作机制。

5.2 给智能体“喂”一条高质量需求模板

另一个直接影响产出质量的习惯是：建立一个高频复用的小需求模板。我之前踩过一次坑，给某跨平台系统的管理端智能体发了一段很简短的需求，结果它为了补全信息脑补了一些我没有的默认假设，产出结果需要返工。后来我学到一个办法：把需求拆成一个固定结构，按“背景、核心功能、数据要求、界面偏好、访问方式”这几个段落去描述，哪怕每段只有一句话，准确率都会大幅提升。

用Todo应用这次来说，如果套模板写，大概是这样的：背景是个人日常任务管理场景，核心功能是添加任务、勾选完成、删除任务，数据要求是保存在本地持久化存储中，界面偏好是中文、白底极简风、无复杂动效，访问方式是纯本地单机使用。这样的描述信息密度远高于我最初的版本，生成出来的结果也几乎不需要调整。

这个模板不仅适用于Todo，任何内部工具类的开发需求都可以直接套用。我后来在做一个订单记录小程序的时候也用了同一套模板，效果依然稳定。积木智能体对结构化的信息接收效率明显高于随性表达，我们给它节省理解成本，它就能把省下来的计算量花在实际工程优化上。

5.3 智能体调优：从“被动编码”到“主动询问”的转变

如果你自己也在搭积木智能体，我强烈建议你放大“主动询问”这一能力的权重。很多人在设计智能体时会把全部精力放在它能执行什么任务上，却忽略了它是一个需要跟人协作的系统。一个只会埋头干活的智能体和一个会在干活前确认关键信息的智能体，用户的使用体验是截然不同的。

这次另一个让我印象深刻的点在于，它把“提问”和“被执行的任务”本身结合得非常自然。它没有在界面上一连弹十个问题让用户慢慢填，而是聚焦在最影响架构的两个变量上。这说明好的智能体设计，应该在提问时做优先级排序，只问那些一旦问错会导致返工的问题，其他细节留给默认值即可。

我自己的调优习惯是：每次在平台里搭建新智能体时，都会在测试阶段故意用极度模糊的输入去触发它，观察它会问什么、默认什么、在哪里容易脑补。这些测试结果才是改进提示词的最佳依据，比凭空想象一个“完美提示词”要可靠得多。

5.4 让积木智能体的开发能力向外延伸

这次Todo应用的开发虽然只是一个个人工具级别的项目，但它让我重新评估了积木智能体在真实工作场景里的定位。它不只是能生成静态页面，还能把数据层、用户交互、持久化策略这些真实工程问题纳入考虑范围。这就意味着，它也能用于搭建一些轻量级内部工具，比如数据录入页面、报表查看面板、简单的审批流程。

我现在办公时有一个习惯：碰到一些需要“写个工具来解决问题”的小需求，我不会再像以前那样直接起一个工程手写代码，而是先到积木智能体上花几分钟搭一版原型出来，跑通了再去考虑要不要深化。这种方式对我这种需要频繁验证想法的人来说，省下的时间不是一点半点。

当然我也要承认，对于特别复杂的企业级系统项目，积木智能体目前的定位还是“原型生成器”和“脚手架加速器”，距离完全替代系统架构师还有不小的距离。但同样是这句话，世界上绝大多数需求根本到不了需要企业级架构的程度，用合理的代价做出够用的工具，本身就是一种明智的工程选择。

最后再分享一个小技巧：你可以让积木智能体在完成开发后，输出一份“简洁版使用说明”，它会基于刚才生成的代码自动描述功能点。我就把这页说明直接截进了自己的笔记里。通过这次Todo应用的完整开发，我自己最大的收获并不是省掉的二十分钟编码时间，而是它“动手前先问两个问题”这件事给我带来的启发：真正高效的人机协作，不是一方拼命执行、一方拼命验收，而是在执行之前就把彼此的理解校准到同一条线上。这种思维方式，放到任何开发协作场景里都是通用的。