ARTICLE · 982358
先做小工具,再谈 AI 开发
很多人第一次让 AI 写软件，就从“做个能管理所有客户、订单和库存的系统”开始。几轮对话后，代码越来越多，页面也越来越像样，真正到了要保存数据、给同事用、修改旧功能时，却不知道该从哪里接手。
问题通常不在于你不会写代码，而在于第一个题目选得太大。对非程序员来说，AI 开发最好的起点不是一套系统，而是一个能在十分钟里试清楚的小工具。
先挑对第一个问题
适合做第一个原型的问题，往往同时满足四个条件：它会反复发生；主要由一个人使用；输入和结果都说得清；即使做错了，也不会直接影响钱、客户承诺或正式数据。
比如把一批固定格式的会议记录整理成待办清单、把报价字段拼成统一文本、按既定规则计算一项费用。这些任务不一定“高大上”，但能让你迅速看见：AI 写出来的东西到底有没有替你省下一步操作。
反过来，涉及多人协作、复杂权限、付款、库存扣减、客户资料或跨系统同步的需求，不适合作为第一个练手项目。它们不是不能做，而是需要先把规则、数据和责任人设计清楚，不能只靠一段对话往前堆。
把大需求缩成一个动作
一个好原型，只解决一个完整动作。不要一上来做“客户管理”，先做“把客户反馈粘贴进来，按主题生成三类待办”；不要一上来做“报销系统”，先做“输入金额和类别，自动汇总本月明细”。
缩小不等于做得敷衍。它是在验证最关键的两件事：这个动作值不值得自动化；AI 对你的业务语言理解得对不对。前者没通过，后面加再多页面都没有意义；后者没说清，功能越多，返工越难定位。
可以给自己留一条边界：第一版最多一个页面、一个核心按钮、一个可检查的结果。需要长期保存、多角色查看或外部发送时，先把它记为“下一阶段”，不要硬塞进第一版。
把需求写成一张项目卡
跟 AI 说“帮我做个小程序”，得到的往往是一串它替你补全的假设。更稳的办法，是先把下面五项写在一张项目卡上，再让它开始生成。
- 使用的人
谁在什么场景下打开它？ - 输入的东西
手动填写、粘贴文本，还是上传固定格式的文件？ - 只做的动作
点击后，它只需要完成哪一件事？ - 交付的结果
屏幕上显示什么，或导出成什么文件？ - 不能做的事
第一版不保存哪些数据，不发送什么内容，不修改哪些原件？
这张卡的作用，不是把需求写得更正式，而是把“想要一个工具”变成能被检查的约束。尤其最后一项很重要：它帮你主动排除本不该由第一版承担的风险。
先跑起来，再决定要不要继续
AI 生成代码后，第一件事不是继续加功能，而是按真实场景跑一遍。准备三组输入：正常的一组、缺少信息的一组、最容易出错的一组；分别看结果是不是符合预期。
如果第一版能稳定完成一个动作，就记录下哪些地方还要补：是输入不方便、结果不够清楚，还是规则本身没有讲完整。下一轮只改其中一类问题，并保留当前可用版本。这样即使改坏了，也知道该退回哪里。
当需求开始出现“要登录”“要让同事一起用”“要接外部系统”“要保存长期数据”时，说明它已经从小工具走向项目。此时该补的是需求文档、结构设计和测试，不是继续在同一个对话框里叠加新要求。
你的第一个工具，可以这样开始
今天就挑一件每周都会做、重复但不高风险的小事，用上面的项目卡写清楚。先让 AI 生成一个最小版本，自己实际点一遍，再决定要不要投入更多时间。
会不会写代码，并不是第一道门槛。真正的门槛是：你能不能把一个问题缩到足够具体，具体到结果对不对，一眼就能看出来。
课程完整介绍与学习入口，请点击文末“阅读原文”。