某头部电商企业 AI Coding 沙龙：让业务人员开始自己创造工具
面向约 80 名没有代码基础、来自不同部门和岗位的业务人员，用两场半日实战沙龙，带他们跑通「提出想法 → AI 生成 → 保存运行 → 验收迭代」的完整闭环。
参与对象
约 80 名业务人员（两场）
训练主题
AI Coding 半日实战沙龙
课程方式
讲解 · 演示 · 实操 · 验收
Not everyone becomes a coder
AI Coding，不是让每个人都成为程序员
当很多人第一次接触 AI Coding，最容易产生两个极端理解。一种是「我不会代码，所以这件事和我没关系」；另一种是「现在 AI 会写代码了，我只要说一句需求，它就能把软件做好」。这两种理解都不准确。
所以在课程开始，我们没有直接让学员写 Prompt、生成代码，而是先回答一个更基础的问题：一个业务人员，到底可以用 AI 做出什么？
七类基础能力
一个真正实用的工具，通常不是其中某一种能力，而是两三种能力的组合：经营数据可以变成一个可筛选的数据看板，结构化的方案可以变成一个可以点击交互的网页演示，规则明确、输入输出标准化的重复工作，可以变成一个轻量业务工具。
不要先问「AI 能写什么代码」，而要先问「我的工作中，有什么任务值得被做成工具」。
Start with one HTML file
为什么我们从一个 HTML 文件开始？
对于完全没有代码基础的业务人员来说，如果一开始就讲开发框架、数据库、服务器和部署，很容易迅速进入技术细节。所以这次沙龙，我们刻意把第一步做得很轻：先从单文件 HTML 工具开始。
HTML、CSS 和 JavaScript 可以放在一个文件中。AI 生成之后，保存为 .html 文件，用浏览器打开，就可以直接看到结果。
第一次完整体验
提出一个想法 → AI 生成代码 → 保存文件 → 浏览器打开 → 看到自己的工具运行起来
当这个闭环第一次跑通之后，Coding 就不再是一件抽象的事情。学员会开始意识到：原来我不一定需要先学会写代码，才能开始创造自己的业务工具。
当然，这并不意味着所有软件都可以靠一个 HTML 文件解决。课程中同样需要帮助大家理解边界：哪些任务适合直接做，哪些应该缩小范围做 MVP，哪些涉及数据库、权限、多人协作或者外部系统，需要进一步的技术条件。AI Coding 的价值不是让业务人员忽略技术边界，恰恰相反，是让他们开始理解边界，并在边界内快速行动。
From idea to working tool
真正需要学习的，是从想法到工具的完整链路
会让 AI 生成一段代码，并不等于掌握了 AI Coding。真正困难的地方往往发生在代码生成之前和之后。所以这次沙龙，我们没有把重点放在某一个模型、某一个 Prompt，或者某一种 Coding 工具上，而是围绕一条完整工作链路展开。
完整工作链路
定义任务→规划任务→生成代码→验收迭代→沉淀资产
定义任务
不要一上来就告诉 AI「帮我做一个高级、好看的数据看板」——业务目标、数据、功能和验收标准都没说清楚，AI 只能猜。首先要回答的是：这个工具解决什么问题？谁来使用？输入什么？输出什么？第一版做到哪里就够了？
规划任务
方向明确后也不要急着让 AI 写代码，而是让 AI 先反过来向人提问：页面怎么组织？用户怎么操作？需要哪些功能？输入什么数据？视觉是什么方向？怎样才算成功？AI 更适合发现遗漏、提出问题和整理选项，做决定的仍然是业务人员。
生成工具
蓝图确认之后，再让 AI 根据已确认的蓝图生成完整、可运行的代码。此时 Coding 才真正开始，但对业务人员来说代码本身反而不是最重要的部分——重要的是 AI 有没有按照业务蓝图，把需求实现出来。
验收迭代
第一版能打开，并不意味着工具已经完成。要真正操作它：按钮有没有反应？筛选后的结果对不对？计算逻辑是否准确？换一组数据还能不能运行？页面有没有乱码、溢出或者错位？描述问题时要说清「我做了什么 → 实际发生了什么 → 我希望发生什么 → 有什么证据」。
沉淀资产
一个工具做成功之后，不应该停留在这一次对话里。让 AI 帮助区分：哪些是以后都不变的固定规则？哪些是每次需要替换的信息？哪些视觉规范已经验证有效？哪些 Prompt 可以继续复用？最终沉淀的不只是一个 HTML 文件，而是成品 + 规则 + 方法 + 可复用 Prompt。
前四步训练的是动手能力，最后一步训练的是沉淀意识——课程中最重要的一句话是：验收 AI，而不是跟从 AI。
Field Notes · 现场记录
把一个业务想法，跑成一个能运行的工具
左右滑动查看现场照片
Learn by building
从跟着做，到做自己的业务工具
为了让没有代码基础的学员真正跑完这个过程，课程没有从一开始就要求所有人凭空创造自己的项目，而是设计了一条递进式实操路径。
现场转化的业务工具
- 物流箱空间利用率测算工具
- 库存需求统计系统
- 大促活动管理工作台
首先，通过一个表格对比工具，理解如何把明确的业务规则告诉 AI，并用标准答案验证工具是否正确。随后进入更复杂的数据分析看板，开始处理维度、指标、计算口径、图表、筛选和 UI 规范。最后，再回到每个人自己的真实工作：我的工作中，有没有一个问题，也可以用同样的方法做成工具？
这些工具未必已经是可以直接进入生产环境的完整系统，但它们验证了一件更重要的事情：当业务人员开始掌握「定义—规划—生成—验收—迭代」的方法之后，他们已经可以亲手把自己的业务知识转化为第一版可运行工具。
Architect and Executor
AI 时代，业务人员的角色正在发生变化
过去做一个软件，背后通常需要不同专业角色参与：产品经理负责需求，设计师负责界面，工程师负责开发，QA 负责测试。AI Coding 出现以后，这些角色并没有消失，但人与 AI 的分工开始重新组合。
产品经理 · 需求
设计师 · 界面
工程师 · 开发
QA · 测试
人做 Architect，AI 做 Executor。
对于业务人员来说，一个越来越重要的角色可能是「产品经理 + QA」：你要能够想清楚「我要解决什么问题」，也要能够判断「AI 做出来的东西到底对不对」。而 AI 可以越来越多地承担设计、代码生成以及具体执行工作。所以 AI Coding 真正降低的，不只是写代码的门槛，它降低的是把业务知识转化为数字工具的门槛。
AI Native workforce
从使用 AI，到成为 AI Native 的业务人才
过去我们谈「会使用 AI」，很多时候指的是会提问、会写 Prompt、会让 AI 帮忙总结、写作、分析资料。这些能力依然重要，但随着 Agent 和 AI Coding 能力不断成熟，人与 AI 的协作正在继续向前走。
- 从向 AI 提问，走向让 AI 交付任务
- 从直接让 AI 给答案，走向让 AI 先帮助自己把问题想清楚
- 从生成一段内容，走向生成一个可以运行的工具
- 从接受 AI 的结果，走向验证和验收 AI
- 从一次性的对话，走向不断沉淀自己的工作方法和数字资产
这或许也是「AI Native 人才」一个越来越重要的特征：不是掌握了多少个 AI 工具，而是开始重新思考自己的工作应该如何被设计。当一个业务人员看到一项重复工作时，他不再只是问「AI 能不能帮我做」，而会进一步思考：这项工作能不能被定义？规则能不能被说清楚？能不能把它变成一个工具？能不能验证它、迭代它，并最终让它成为可以重复使用的工作资产？
这也是这场 AI Coding 沙龙，我们真正希望留下的东西。不是让 80 名业务人员在半天里学会编程，而是让他们第一次完整经历：把自己的业务想法，变成一个真正可以运行的工具。而这，也可能是业务人员走向 AI Native 工作方式的一个开始。
Let business people build
让最了解业务的人，开始自己创造工具。
如果你正在规划业务人员 AI Coding、数据自动化或内部工具原型训练，我们可以从一个真实场景开始设计。