玩Android×AI Coding：从产品到代码，完整跑通一套 AI 软件研发工作流

前言

从 ChatGPT 出来开始，我就在思考一件事情。 AI 到底能帮助程序员做到什么程度？ 是仅仅帮忙补全几行代码？ 还是说，它真的能够参与整个软件研发流程？ 正好最近公司发生了一些变化。 这让我开始重新思考自己的职业方向。 与其继续讨论 AI 会不会取代程序员，不如自己验证一次。 所以，我决定从一份开放 API 开始，完全借助 AI，不写任何一句代码，尝试完成一款真正可以运行的 KMP 应用。

而在开始之前，我们要先思考一下：在这个项目里，我们能让AI扮演什么角色？

1、AI扮演产品经理

众所周知，一款产品的开始往往离不开产品经理，那么AI产品经理如何扮演好这个角色呢？

这是玩Android的API开发接口文档，既然AI扮演产品经理，那么我们能否让它自己获取这个API开发接口，然后通过这一系列接口自动分析API接口不？

1.1 API文档分析

如图所示

• 在使用AI之前，首先需要告诉他你是谁(项目中什么角色、技术栈)，这样在后续过程中，AI会根据你实际情况而调整

  • 比如这里我提到对swift不了解，AI在记忆协作文件里就会有"设计和编码时，应尽量降低对swift/object-c的依赖"

有句话说的不错，要想让AI发挥最大作用，第一步就是让AI知道你有多"废"。

调侃一下，任务发给AI了，我们来看看AI的结果

如图所示

• CodeX已经按照我们对WanAndroid的API文档进行了分析与整理，交出了一张完美的答卷！

---

到这里，很多人可能觉得 API 已经分析完成了，接下来是不是直接开始 Coding？

我的答案是No！

如果直接开始 Coding，那么这个项目和普通 AI Demo 没有什么区别。

我希望 Codex 能够像一个真正的研发团队一样持续协作，而不是每次开启新对话，都要重新介绍项目背景。

所以，我决定给 Codex 建立一套"项目记忆库"。

1.2 PRD、路线图与项目记忆库

如图所示

在真实的软件开发中，一个项目并不只是只有代码，它还有

如果这些东西只存在于聊天记录里，那么一旦开始新的对话，AI就需要重新理解整个项目

这不仅浪费token，也容易导致前后决策不一致！

这一段就是：记忆库存在的意义

而这记忆库大致分为三类：

1.2.1 项目记忆

PRD

RoadMap

Architecture

这三个一句话概括：告诉AI，这个项目是什么(需求、开发路线、架构说明)

1.2.2 开发记忆

Task Memory

Bug Memory

一句话概括：告诉AI，这个项目做到哪了，出现过什么问题

1.2.3 历史记忆

ChangeLog

一句话概括：告诉AI，这个项目发生过什么

---

以前我一直认为，AI 的"记忆"来自聊天记录。

实际实践以后，我发现真正的长期记忆，其实应该来自项目本身。

聊天记录会结束。

Token 会消耗。

但是项目里的文档不会。

当 PRD、RoadMap、Bug、Task 都沉淀到仓库以后，新开的任何一个对话，都可以迅速恢复到当前项目状态。

至此，AI产品经理的工作基本完成。

下一步我们准备让AI扮演UX设计师，根据PRD自动生成产品原型。

2、AI扮演UX设计师

2.1 Figma MCP 自动调用

然而我在第一次尝试让AI扮演UX设计师时，出现了一点小插曲。

如图所示

当我准备用Figma参与UX设计时，它确实在Figma官网里生成了WanAndroid KMP UX文件，但是在写入数据时候，因为我是免费用户，所以它提示Starter plan MCP tool call limit，解除限制必须升级套餐，而我又想白嫖，因此得换一种方案！

---

2.2 AI模拟真人操作Figma

Codex这个智能体不是支持Computer Use么，那要不试试这个功能，不走MCP，让它使用Computer Use模拟真人在Figma官网里手动去扮演UX设计师？

跑了13分钟，任务跑完了，顺便还把我5小时额度用完了，但是效果非常糟糕(简直可以用不堪入目来形容)！

为啥会这么糟糕呢？

我们分析一下 Figma 需要 AI 做什么。

例如画一个首页：

AI需要：

一个首页可能就有：

• 40~80 次点击
• 20~30 次拖拽
• 十几次对齐
• 很多精细调整

对于 Computer Use 来说：这是噩梦。

因为它每一步都要：

它不是调用 API，而是像真人一样在操作。

这种精细调整的活并不是合适用Computer Use，因此我们得换一种方案。

我想过用Axure、墨刀相关工具，但MCP 相关功能估计又和 Figma一样，免费用户有限制之类相关的，更何况以前还是用的破解版。

既然如此，那我们可以不用完美追求与原型百分百的交互，毕竟不想付费，走个平替版本。

2.3 Codex 直接生成UX设计资产

如图所示

我这直接将它上一轮生成的PRD需求以及一系列文档来生成对应的UX文档docs/08_WIREFRAME_LAYOUT.md，顺便还额外生成了Image2文生图的提示词docs/09_WIREFRAME_IMAGE_PROMPTS.md

我们来看看效果咋样

• 08_WIREFRAME_LAYOUT.md 文档部分内容

  

• 09_WIREFRAME_IMAGE_PROMPTS.md 文生图提示词内容

  

• 09_WIREFRAME_IMAGE_PROMPTS.md 提示词生成效果

  

其实这里通过08_WIREFRAME_LAYOUT.md就能继续下一步UI设计操作了，想看图片通过Image2用提示词生成就可以了。

但是！！这一步不想平替，又不想在这一步付费，也想要那种可交互效果的原型怎么办呢？

2.4 AI 不仅能使用工具，也能创造工具

到这里，我突然发现一个问题。

无论是：

• Figma
• 墨刀
• Axure

其实都不是我真正需要的。

我真正需要的是：

一个能够让 AI 理解、能够让人查看、还能继续交给 AI Coding 的低保真原型。

既然如此。

为什么一定要依赖现有工具？

如果 AI 都已经能写代码了。

那为什么不能：

直接让 AI 给自己创造一个工具？

于是。我没有继续折腾 Figma。

也没有继续寻找 Axure 的替代方案。

而是开启了一个全新的项目。

让 Codex 帮我写了一个：

JSON 驱动的低保真原型查看器（AIWireframeViewer）。

如图所示

• 这个原型查看器有俩个模式：编辑模式与运行模式
• 当前模式就是编辑模式，左侧是页面列表，中间控制台展示的是页面之间的跳转关系
• 编辑模式与运行模式的切换在右上角

我们切换运行模式看看效果：

如图所示

这样看着就有了原型交互的效果了，但是它的存在不是为了替代Figma，

它仅仅是为了让AI有了一个稳定的"中间语言"

---

至于它是怎么实现的？这已经不是UX的范畴了，后面有时间我会单独写一篇

OK，AI扮演UX设计师成功了，下一步轮着扮演视觉设计师了！

3、AI扮演视觉设计师

3.1 AI建立 Design System（视觉规范）

我们以前编程的时候都是借着的UI设计师的规范来进行开发的

那么AI Coding呢，该如何呢？

如图所示

• 我们通过上面生成的08_WIREFRAME_LAYOUT.md文档内容建立 Design System（视觉规范）
• 而这里面的内容大致就是：颜色规范、字体规范、圆角规范、间距规范等一系列规范约束

那么规范建立好了，那么我们继续下一步

3.2 AI 将设计语言翻译成开发语言

到这里，其实我遇到一个新的问题。

虽然已经有了设计规范，但是对于 AI Coding 来说，这些仍然属于设计语言。

例如：

UI 设计师会说：

首页使用主色。
Card 圆角 16dp。
使用 Material Symbols。

但是 AI 写 Compose 时，并不会直接理解这些描述。

它真正需要知道的是：

• 设计稿中的颜色、字体、圆角，在 Compose 中应该对应什么？
• 设计组件对应哪个 Material3 组件，以及推荐封装成什么 Compose Facade？
• 一个页面应该由哪些组件组成？

也就是说

AI Coding并不是直接消费 Design System，而是消费一层 Runtime Mapping

如图所示

• Theme Mapping，它负责告诉AI：设计稿中的颜色、字体、圆角，在Compose中应该对应什么

  • 比如：
  • 
  • 这样 AI 就不会自己猜颜色。

• Component Mapping，它负责告诉AI：设计组件对应哪个 Material3 组件，以及推荐封装成什么 Compose Facade。

  • 比如：
  • 
  • 以后所有页面统一使用这一套组件，而不是每个页面重新拼。

• Page Mapping，它负责告诉AI：一个页面应该由哪些组件组成

  • 比如：
  • 
  • 这样 AI Coding 时，不需要再分析 Wireframe，而是直接读取组件树即可。

从这一刻开始，AI Coding 真正消费的已经不再是图片，而是一套可以直接生成代码的 Design Runtime。而这就是下一位 AI工程负责人工作的输入。

4、AI扮演工程负责人

4.1 写首页之前，AI 先给项目打地基

产品需求、UX 设计和视觉资产都准备完成后，按照正常思路，下一步似乎就应该开始开发首页了。

但我把当前项目完整交给 Codex 检查后，它并不建议直接进入业务页面开发。

原因也很简单：

此时的项目虽然已经拥有 PRD、Wireframe、Design System 和页面组件映射，但代码层面仍然只是一个最原始的 KMP 模板。

如果直接从首页开始，首页将不得不同时承担：

• 主题初始化
• 页面导航
• 加载、空数据和错误状态
• 网络异常处理
• Android 与 iOS 的平台差异
• 日志与依赖创建
• 后续登录回跳和详情页跳转

这样做的结果，很可能是首页先临时实现一套，搜索页再复制一套，项目越往后开发，返工成本越高。

因此，在真正开发业务功能之前，我先让 Codex 以工程负责人的身份，对项目执行了一次 Engineering Bootstrap。

如图所示

Codex 将这一阶段定义为 Phase 0。

这一阶段不实现首页、不调用真实接口，也不创建任何业务 Feature，而是先完成所有页面都会依赖的工程基础设施。

它最终将工程初始化拆成了 16 个可以独立验收的任务，其中主要包含：

• 工具链与依赖版本基线
• 项目包结构和依赖边界
• 手动依赖注入与 Composition Root
• Design Token 到 Compose Theme 的接入
• 共享导航根节点
• 非业务 App Shell
• Loading、Empty、Error 等通用状态
• Android/iOS 平台能力契约
• 日志与网络传输基础层
• 测试、资产校验与双端质量门

这里最重要的变化，不是增加了多少文件，而是项目的职责开始被拆开。

如图所示

经过这一步以后，项目不再只是一个能够显示 Hello World 的 KMP 模板，而是形成了一个可供后续 Feature 接入的共享工程底座。

例如：

• AppContainer 负责统一创建和管理项目依赖；
• Navigation Root 负责维护一级页面和二级页面的导航状态；
• Theme 将上一阶段生成的视觉 Token 真正接入 Compose；
• App Shell 负责承载应用主题、导航、启动状态和全局错误；
• AsyncState 与 AppError 统一后续页面的加载、空数据和异常表达；
• PlatformServices 隔离 Android 与 iOS 的平台差异；
• HttpTransport 只建立网络传输基础能力，但暂时不包含任何真实接口。

这一步仍然没有首页，也没有登录、收藏或真实 API。

但后续每一个页面，都不再需要重新处理主题、导航、错误和平台差异，而是直接建立在同一套基础设施之上。

---

完成 Phase 0 后，项目看起来并没有突然多出一个"很炫"的页面。

但它已经从一个最原始的 KMP 示例工程，变成了一套可以正式承载业务开发的工程底座。

这也是我在这次 AI Coding 实践中逐渐意识到的一点：

AI Coding 并不只是让 AI 更快地生成页面代码，更重要的是让它知道，什么时候不应该急着写页面。

完成 Engineering Bootstrap 后，项目代码已经具备了承载 Feature 的能力。

但工程底座解决的只是"代码应该放在哪里、依赖应该如何组织"。

接下来还有另一个问题：

即使项目结构已经准备完成，AI 在真正 Coding 时，仍然可能因为追求完整性而过度设计。

因此，在正式开始 Feature Development 之前，我又为 Codex 增加了一层代码实现约束。

4.2 给 Codex 安装一个"克制写代码"的 Skill

为什么工程底座已经完成，我仍然不敢直接让 AI 写 Feature？

因为 AI 常见的问题不是写不出来，而是写得太多：

一个简单页面
        ↓
增加新框架
增加新抽象
增加新组件
增加未来扩展点
顺便重构旧代码

因此，在正式进入 Feature Coding 之前，我给 Codex 安装了 Ponytail 技能 。

codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail

或者直接在Codex输入框里输入 给我安装Ponytail 技能

Ponytail 并不会替代项目架构，也不会决定产品应该做什么。

它只负责在 AI 写代码之前增加一道判断：

1. 当前能力是否真的需要新增；
2. 项目中是否已经存在可以复用的实现；
3. Kotlin、Compose 或平台原生能力是否已经能够解决；
4. 当前依赖是否已经提供了对应能力；
5. 只有前面的答案都是否定时，才新增最小实现。

它追求的并不是单纯减少代码，而是在不牺牲校验、错误处理、安全、无障碍和测试的前提下，减少不必要的实现。

对 AiWanAndroid 来说，这条约束尤其重要。

Phase 0 已经建立了 Theme、Navigation、AsyncState、AppError、Platform Contract 和 HttpTransport。

因此，后续开发首页时，AI 应该优先复用这些能力，而不是重新为首页创建一套状态、导航或网络基础设施。

---

Ponytail 解决的是"AI 应该写多少代码"的问题。

但它仍然不知道：

• 当前项目已经进入哪个阶段；
• 哪些文档已经冻结；
• 每个 Feature 开始前必须读取什么；
• 哪些文件不能由普通 Coding 任务修改；
• 一个 Feature 满足什么条件才算完成。

这些规则不能依赖我在每个新对话里重新说明。

因此，在进入第五章之前，还需要进行最后一次项目知识整理。

4.3 重构 AGENTS.md，让每个新对话遵守同一套规则

项目进行到这里，根目录中的 AGENTS.md 已经积累了大量内容。

它记录了产品、UX、视觉设计、文档入口和协作偏好，可以帮助 AI 理解项目是如何一步步建立起来的。

但进入 Feature Development 后，这份文档也出现了一个新问题：

它记录了太多"项目是怎么走到这里的"，却没有足够清晰地告诉 AI"接下来应该怎么开发"。

例如，线框图片 Prompt、Visual Review 和 Compose Readiness 对前面的设计阶段很重要，但并不是每个 Feature Coding 对话都需要默认读取。

如果所有历史文档都继续作为前置上下文，不仅增加 Token 消耗，也可能让 AI 无法分辨当前真正有效的约束。

---

因此，我没有继续向 AGENTS.md 追加内容，而是让 Codex 从全局重新整理它。

这次整理的原则是：

• 保留长期有效的项目规则；
• 删除已经完成历史使命的默认上下文；
• 把产品、UX 和视觉资产标记为 Frozen Assets；
• 区分默认必读文档与按 Feature 读取的文档；
• 明确当前 AI 角色；
• 把 Ponytail 加入 Coding Workflow；
• 定义普通 Feature 不允许修改的范围；
• 定义统一的 Definition of Done。

如图所示

重构后的 AGENTS.md 不再负责保存完整历史，而更像一份 Feature Development Guide。

• Source Of Truth 告诉 AI 一个新 Feature 应该读取哪些事实来源；

• Frozen Assets 告诉它哪些产品、UX 和视觉资产不能被普通 Coding 任务修改；

• Ponytail Policy 规定什么时候启用最小实现约束，以及它与项目规范冲突时的优先级；

• Definition Of Done 则统一了每个 Feature 的完成标准。

---

完成这次重构的 AGENTS.md 后，后续每一个新的 Codex 对话都不再需要我重复解释整个项目。

AI 只需要读取 AGENTS.md，就能够知道：

• 当前处于 Feature Development；
• 当前应扮演 Android/KMP Feature Engineer；
• 开始任务前要读取哪些文档；
• 哪些资产已经冻结；
• 什么时候启用 Ponytail；
• Coding 前需要先输出什么 Plan；
• 哪些改动属于越界；
• 满足什么条件才能宣布 Feature 完成。

至此，代码底座、AI Coding 约束和项目上下文都已经准备完成。

下一章开始，不再搭建环境，不再整理规范，直接进入第一个业务 Feature。

5、AI 扮演 Android/KMP 工程师

5.1 AI 如何完成第一个 Feature

经过前面四个章节，我们终于开始真正的 AI Coding。

而一个成熟的 AI Coding 项目，并不是 Prompt 越来越复杂，而是 Prompt 越来越简单。

如图所示

这次我的Prompt只有一句话：当前任务：开发首页。

我们直接先看这次任务的效果：

5.2 AI Coding 为什么能够一句 Prompt 完成一个 Feature

为什么仅仅一句话，AI 就知道应该怎么做？

因为在前面的章节，我们已经完成了整个项目的知识沉淀。

AI 收到这句话以后，并不是立即开始写代码。

而是会按照 AGENTS.md 中定义的 Workflow，自动完成下面这些步骤：

如图所示

计划确认以后，Codex 并没有直接开始实现首页，而是先分析了整个 Feature 的影响范围。

例如：

• 是否需要新增页面；
• 是否需要修改导航；
• 是否能够复用已有 Theme；
• 是否会影响其他 Feature；
• 是否违反 Frozen Assets；
• 是否需要平台差异处理；
• 是否符合 Ponytail 的最小实现原则。

确认这些都没有问题以后，它才开始真正进入 Coding。

---

不过，当首页开发完成以后，还有最后一个问题。代码能够运行，并不代表这个 Feature 就真正可以交付。

真正的软件开发，还需要最后一道工序：Review。

6、AI 扮演 Reviewer（质量验收）

我原本以为，第六章应该继续给 AI 一个新的 Prompt。

例如：

"请开始验收首页。"

后来整理整个 Workflow 时，我发现根本不需要。

因为 Codex 在 Plan Mode 下，已经把：

整合成了一个完整生命周期。

Review 并不是新的任务。

而是这个 Feature 天然的一部分。

---

最开始，这一章，我是准备写： 《AI 扮演测试工程师》

但后来发现： 真正AICoding软件研发里， Review 从来不是 Coding 结束以后， 才开始的一件事情。 而是整个开发过程中持续发生的。

如图所示

AI 在宣布 Task Complete 之前，会主动完成：

• Build 验证；
• 编译错误修复；
• 代码 Review；
• Memory 更新；
• Task 状态更新。

直到整个 Feature 满足完成条件以后，它才会真正结束本次任务。

因此，我后来也重新修改了这篇文章的目录。

把原本的：

AI 扮演测试工程师

改成了：

AI 扮演 Reviewer（质量验收）

因为对于当前这套 AI Coding Workflow 来说：

Review 并不是开发之后的一件事情，而是开发过程本身的一部分。

做到这里，这篇文章真正想验证的目标，其实已经完成了。

我们并不是证明：

AI 能不能写出一个首页。

而是验证：

一套完整的 AI Coding Workflow，是否能够真正跑通。

事实证明，它可以。

从产品分析，到 UX、视觉设计、工程初始化，再到 Feature Coding 与最终 Review。

整个软件研发流程，已经能够由 AI 深度参与。

至于：

• 如何利用 AI 生成测试用例；
• 如何让 AI 编写接口测试；
• 如何实现点点点自动化测试；
• 如何让 AI 接管传统项目的 QA 工作；

这些已经属于另一条更加完整的 AI QA 工作流。

我准备后面单独整理一篇文章，系统聊聊这个话题。

---

当我回过头重新整理整个项目的时候，我突然发现：

真正发生变化的，并不是首页已经开发完成。

而是我已经开始习惯把 AI 当成项目成员，而不是一个聊天机器人。

这也是我写这篇文章最大的收获。

因此，在结束之前，我更想聊聊这次实践带给我的一些思考。

7、总结：AI Coding，真正改变了什么？

如果要让我用一句话总结这次实践，我觉得不是：

AI 会不会取代程序员？

而是另一个问题：

AI 到底会把程序员变成什么样的人？

以前，我和很多人一样，把 AI 当成一个聊天工具。

遇到不会的问题，问一句。

写一个函数，补几行代码。

直到这次真正从零开始，让 AI 全程参与一个项目以后，我才发现，它扮演的早已不只是"代码补全"。

它可以是产品经理，可以分析 API，整理 PRD；可以是 UX 设计师，输出页面信息架构和 Wireframe；可以是视觉设计师，建立 Design System；可以是架构师，搭建工程底座；也可以是 Android/KMP 工程师，根据项目规则完成 Feature 开发。

而我真正需要做的事情，反而发生了变化。

以前，我需要告诉 AI：

这一行代码怎么写？

现在，我更多是在思考：

这个项目应该怎样协作？

---

7.1 AI 不会替你思考，但会无限放大你的思考

网上一直有一句话：

AI 不会淘汰程序员，而是会使用 AI 的程序员淘汰不会使用 AI 的程序员。

我认可这句话，但我觉得它还可以再往前走一步。

我更愿意把它改成：

AI 不会淘汰程序员，它会淘汰那些停止思考的程序员。

为什么？

因为 AI 本身没有目标。

它不会突然决定去开发一款产品。

不会突然想到要把一个项目拆成 PRD、UX、Visual、Engineering。

更不会主动去建立 Workflow、Memory、Source Of Truth。

这些想法，仍然来自于人。

AI 的能力，更像是一块放大镜。

你的想法越清晰，它放大的效果越明显。

如果没有想法，它只能不断重复已有的知识。

所以，在整个项目里，我真正投入最多时间的，并不是写 Prompt，而是在思考：

怎样才能让 AI 更容易理解这个项目？

---

7.2 Prompt 的终点，不是 Prompt Engineering

很多人刚开始学习 AI 时，都会去研究 Prompt。

包括我自己。

一开始，我也会写几百字、上千字的提示词，希望 AI 一次性理解所有背景。

但做到后面，我发现 Prompt 却越来越短。

最后，开发首页的时候，我真正输入的只有一句：

当前任务：开发首页。

Prompt 为什么越来越短？

不是因为 AI 更聪明了。

而是因为项目已经拥有了自己的长期记忆。

PRD、Design System、Theme、Architecture、AGENTS、Task Memory......

这些都已经沉淀到了项目本身。

Prompt 不再负责描述整个世界。

它只负责告诉 AI：

现在轮到哪个 Feature 了。

这也是我最大的一个收获：

Prompt Engineering 的终点，其实是 Project Engineering。

真正重要的，不是 Prompt，而是项目。

---

7.3 我觉得，Skill 会成为下一代"开发模板"

做到这里，我又产生了一个新的想法。

如果这一整套 Workflow 可以不断复用。

那它为什么一定要停留在一篇博客里？

例如：

• 产品经理这一章，可以沉淀成一个 Product Skill。

• UX 阶段，可以沉淀成一个 UX Skill。

• Visual 阶段，可以沉淀成一个 Design Skill。

• Engineering Bootstrap，可以沉淀成一个 Engineering Skill。

• 甚至 AGENTS.md、Ponytail、Workflow、Definition Of Done，都可以逐渐沉淀成团队级的开发规范。

未来，当一个新项目开始的时候。

或许真正需要做的，不再是复制一个 Android Template。

而是：

安装一套属于这个团队的软件研发 Skill。

---

7.4 我越来越期待 Multi-Agent

再往后想一步。

如果 Product、UX、Visual、Architecture、Android Engineer 不再由同一个 AI 完成。

而是变成多个 Agent 呢？

比如：

如图所示

• 每一个 Agent，都拥有自己的长期记忆。

• 都有自己的职责边界。

• 都有自己的 Definition Of Done。

• 彼此之间通过文档、规则和 Workflow 协作。

这样一套流程，其实已经非常接近一个真正的软件团队。我相信，这也是未来 AI 软件研发的发展方向之一。

7.5 程序员，或许会重新定义自己

很多人讨论 AI 时，总喜欢给自己贴一个标签。

前端。

后端。

Android。

iOS。

算法。

......

但这次实践让我越来越觉得：

未来，真正重要的可能不是这些标签。

而是：

你是否拥有把一个想法变成产品的能力。

AI 正在不断降低技术实现的门槛。

以前，一个人可能只能完成自己熟悉的那部分工作。

现在，一个人可以借助 AI，快速跨越产品、设计、开发和测试之间的边界。

当然，这并不意味着每个人都会成为全栈工程师。

而是意味着：

每个人都有机会成为一个能够组织 AI 协作的人。

程序员不再只是代码的编写者。

更像是一名导演。

你负责提出目标。

制定规则。

安排角色。

而 AI，负责完成各自的工作。

---

这篇文章并不是想证明：

AI 已经可以替代程序员。

恰恰相反。

它让我更加确信：

未来真正稀缺的，不是会写代码的人。

而是：

• 能够提出问题的人。

• 能够设计 Workflow 的人。

• 能够组织多个 AI 协作的人。

• 能够持续沉淀项目知识的人。

这次，我只是完成了一个小小的 KMP 项目。

但我相信，这不会是终点。

下一步，我更想尝试的是：

• 把整个 Workflow 提炼成可复用的 Skill；
• 尝试 Multi-Agent 协同的软件研发流程；
• 让 AI 不只是完成一个 Feature，而是真正参与一个长期项目。

或许几年以后，我们回头再看今天讨论的 Prompt、AGENTS、Workflow，它们都会成为 AI 软件研发历史中的一个阶段。

但我相信，有一件事情不会变：

真正决定 AI 上限的，从来不只是模型，还有使用它的人，以及他们构建的工作流。模型决定速度，工作流决定规模，而人的想法，决定 AI 最终能够走多远。

本文章的项目已上传至GitHub AiWanAndroid

本文章 2.4内容 AI创建的工具也同步上传至GitHub AIWireframeViewer工具