COMPANY SHARING 2026.04

AI Coding

从辅助到协作,再到自主

Mint研发-刘迪行

目录

01

演变历程

从 Tab 补齐到 Agent 破圈

02

工具与模型

选择合适的组合

03

AI 提效实践

用案例说话

04

沉淀与系统化

构建你的 AI 工具链

05

质量把控

人的角色与最佳实践

01
SECTION 01

AI Coding 的演变历程

五个阶段,从单行补全到 Agent 自主执行

五个阶段,一条演变路径

1 Tab 补齐2023-24Copilot人 9 : AI 1 2 编程搭档2023-24Cursor人 8 : AI 2 3 重度参与2024-25MCP 诞生人 5 : AI 5 4 完全交付2025-26Skill + Agent人 0 : AI 10 5 Agent 破圈2026-人人可用

人的角色:写代码 → 指挥 AI 写代码 → 设定目标让 AI 自主完成

驱动方式:PromptContextHarness

Stage 1-2:从补全到搭档

STAGE 12023-2024

纯 Tab 补齐时代

代表工具

GitHub Copilot

协作模式

人写代码,AI 猜下一行

人 90%
AI
STAGE 22023-2024

编程搭档

代表工具

Cursor

协作模式

AI Chat 嵌入 IDE,生成完整函数、参与方案讨论

人 80%
AI 20%
STAGE 32024-2025

简单需求交付 + 复杂项目辅助

关键变化

MCP 协议诞生

全称

Model Context Protocol

协作模式

人与 AI 协作,AI能处理更多

让 AI 能安全地连接 Figma、数据库等外部工具和数据源,能力边界大幅拓展

人 50%
AI 50%

AI 开始能做什么?

• 处理完整的小需求

• 参与复杂需求的方案设计

• 连接外部工具获取上下文

• 理解跨系统的业务逻辑

但此时的问题是

没有好的工作流约束,产出质量不可控

STAGE 42025-2026

复杂功能 & 完整项目的完全交付

关键变化

Skill 体系诞生

模型跃升

Opus 4.5 / GPT-5.3 / Gemini 3 Pro

上下文

200K → 1M tokens

协作模式

人指挥,AI 独立执行全流程

AI 100%

Skill 体系

Skill 概念的提出,把工作流标准化、可复用,AI 有了武功秘籍

Vibe Coding 成为现实

通过 Rules + workflow + Skills,能独立完成从开发到提测的全流程

角色转变

开发者从"写代码的人"转变为"指挥 AI 写代码的人"

STAGE 52026 至今

OpenClaw 破圈,Agent 爆发

关键变化

Harness 概念、Agent能力进化 + 模型再跃升

模型

Opus 4.6 / GPT-5.4 / Gemini 3.1 Pro

协作模式

人设定目标,Agent 自主执行

AI 不再是程序员的专属工具,而是人人可用的数字助手

模型能力跃升

推理与代码能力再上台阶,上下文窗口持续扩大

Harness 系统化

Agent 操作框架成熟,可自主完成复杂任务

数字员工

AI Agent 从开发工具进化为可独立工作的角色

02
SECTION 02

工具与模型

没有最好的工具,只有最合适的工具

工具/模型

CLI / Agent

Claude Code

Codex CLI

Gemini CLI

OpenClaw

...

可自主执行复杂任务的Agent

IDE 集成

Cursor

Codex 插件

Windsurf / Antigravity

Taro

...

编辑器集成,交互式开发

Model

Claude Opus 4.6

GPT-5.4

Gemini 3.1 Pro

GLM/KiMi

...

不同模型各有长板

合理搭配

根据使用场景、任务复杂度合理搭配模型

$$$

重型模型

Claude Opus 4.6 / GPT-5.4

复杂架构 · 疑难 Bug · 安全审计

$$

主力模型

Claude Sonnet 4.6 / GPT-5.3-codex ...

日常开发 · 代码生成 · PR 审查

$

轻量模型

GPT-4o mini / Haiku / Gemini Flash

简单编辑 · 文件查找 · 格式化

有了工具和模型之后

如何真正用 AI 提效?

从几个实战案例来看

03
SECTION 03

AI 提效实践

用案例说话 — Rules、Skill(工作流)、Memory 如何落地

踩坑与改进

案例一2025/05项目重度重构 — AI降效

用 Cursor 将 三年的H5 复杂项目完全重构为 Next.js

产出比:人:AI 3:7

结果:前期提效,后期 Bug 超多,总耗时反而增加。

• Rules 不完整,前期只定义了一些简单的rules

• 任务粒度太粗,缺乏阶段性验证

• 缺乏工作流约束,没有统一完善的重构规则

案例二2025/10 PC端搭建 — 踩坑与改进

完善 Rules, PC 端开发时全面改进方法

产出比:人:AI 2:8

结果:提前提测、质量较高,Bug 显著减少

• 强化编码 Rules

• 细分任务粒度,逐页面推进

• 定义H5-PC页面完整工作流

AI 能力再强,没有好的工作流和规则约束,产出质量依然不可控。

案例三 · 纯新项目26/01 小程序项目 — 从零到上线
100% AI Coding 人力预估 3 周 → AI 2 周完成

全新项目,从架构设计、到编码、提测、bug修复到上线,全程零手工编程

Rules 约束

代码风格、组件规范、状态管理规则全部预设

Skill 驱动(内含完整工作流)

需求分析 → 技术设计 → 编码 → 测试 → 交付,一条命令触发

0

行手工代码

开发者角色:从"写代码"
转变为"指挥 AI 写代码"

案例四 · 已有项目加功能26/03 自研游戏 — 复杂功能交付
100% AI Coding 人工 4-5 天/游戏 → AI 2 天/游戏

关键步骤

1. 让 AI 熟悉已有项目 — 建立项目文档    2. 按照工作流开发    3. 搭配 Skill 自动修复 Bug

INPUT

Figma URL

设计图 URL

接口文档 (YAML)

WORKFLOW

需求分析 → 技术设计 → 实施计划 → 编码开发 → 测试验证 → 变更记录

OUTPUT

prd.md · design.md

plan.md

code

test.md · changelog

工作流产出

1 / 4
prd.md— 需求分析文档,AI 基于 Figma PRD + 设计稿自动生成
# 自研游戏一期 - 产品需求文档 (PRD) > 来源: Figma PRD / Figma 设计稿 > 更新日期: 2026-03-12 ## 1. 项目概述 ### 1.1 目标 开发自研游戏模块,第一期接入 xxx 游戏(后续扩展 xxx、xxx 等)。 采用通用可插拔架构,游戏之间仅游戏渲染区域和玩法逻辑不同, 其余金额控制、设置、记录、公平性验证等模块均通用复用。 ### 1.2 设计原则 - **可插拔**: 每个游戏只需实现游戏渲染区 + 玩法配置,通用框架自动集成 - **低耦合**: 自研游戏模块独立于主项目,可直接复制到其他项目集成 - **统一目录**: 所有自研游戏放在统一目录下 - **移动端优先**: 当前只做 H5,但底层设计预留 PC 端适配方案 - **多语言支持**: 所有文案支持 en-US / pt-BR / es-MX ## 2. 游戏玩法 - xxx ### 2.1 核心规则 点击"play"后,小球从顶部落下,经过多行钉子碰撞,最终落入底部的赔率位置。 - **RTP**: 95.90% - **行数**: 8 / 12 / 16 行可选 - **模式**: Regular / High / Nightmare (影响赔率分布) ### 2.2 赔率系统 - 底部赔率槽位数 = 行数 + 1(8行→9个槽位,12行→13个,16行→17个) - 赔率对称分布,两端最高,中间最低 - 不同模式对应不同赔率配置表(由后端 config 接口下发) ### 2.3 小球落点生成 (Provably Fair) hash = HMAC_SHA512(clientSeed:nonce, serverSeed) 将 hash 分为 16 组,每组转换为 [0, 1) 范围的数值 ## 3. 功能模块详细需求 ### 3.1 主页面 - 游戏区(Topbar / 赔率条 / 游戏渲染区) ### 3.2 下注控制(金额输入 / 快选 / 行数切换 / 模式切换) ### 3.3 自动下注系统(轮数 / 止盈止损 / 赢后输后策略) ### 3.4 下注记录(My Bets / All Bets / Big Wins) ### 3.5 种子与公平性验证(Client Seed / Server Seed / Nonce) ### 3.6 帮助系统(What Game / How To Play / Fairness) ...(完整文档共 200+ 行)

工作流产出

2 / 4
design.md— 技术设计文档,AI 基于 Figma 设计稿自动提取设计规范
# 自研游戏一期 - 设计文档 > 设计基准: 375px 宽度 (iPhone X), 移动端优先 ## 1. Figma 页面索引 ### xxx 页面 (Section: 31-5191) | Node ID | 名称 | 说明 | |----------|------------------|-------------------------------| | 2:5 | xxx-主页面 | 主游戏界面(16行,完整滚动页) | | 56:9689 | xxx-碰撞 | 小球碰撞钉子状态 | | 56:11526 | xxx-中奖 | 小球落入赔率槽中奖状态 | | 56:12453 | xxx-多球 | 多个小球同时下落 | | 61:13472 | 自动play弹窗 | Auto Setting 弹窗(初始状态) | | 61:17548 | 快速金额 | 金额快选浮层 | | 80:14241 | 中奖播报 | 获胜消息条 | | 81:15170 | 设置 | 设置下拉菜单 | | 84:16452 | 设置-seed | Seed 设置页面 | ... ## 2. 设计 Tokens ### 2.1 颜色体系 | Token | 色值 | 用途 | |------------|----------|-----------| | bg-page | #1A1B1D | 页面背景 | | bg-card | #26282C | 卡片背景 | | bg-input | #1E1F22 | 输入框背景 | | text-primary | #FFFFFF | 主要文字 | | text-secondary | #8E9093 | 次要文字 | | accent-green | #00D26A | 盈利/成功 | | accent-red | #FF4D4D | 亏损/错误 | ### 2.2 字体规范 ### 2.3 间距系统 ### 2.4 圆角规范 ### 2.5 组件规范(按钮、输入框、弹窗、Tab...) ...(完整文档共 150+ 行)

工作流产出

3 / 4
plan.md— 实施计划,AI 基于 PRD 和设计文档自动拆分任务
# 自研游戏一期 - Feature Plan > 版本: v1.0 | 日期: 2026-03-12 > 入口: mint (H5) > 影响范围: 新增模块,不改动现有代码(仅新增路由和 i18n) ## 1. 需求摘要 开发自研游戏通用框架 + 第一个游戏 xxx 框架需支持后续快速接入 xxx 等游戏。 ### 验收标准 - [ ] xxx 游戏完整可玩(手动下注 + 自动下注) - [ ] 8/12/16 行 + Regular/High/Nightmare 模式全覆盖 - [ ] 小球物理碰撞动画流畅,支持多球同时下落 - [ ] 超速模式(跳过动画)正常工作 - [ ] 自动下注全部策略逻辑正确(止盈/止损/赢后/输后) - [ ] Seed 设置 + 公平性验证完整流程 - [ ] 下注记录三个 Tab 数据正确 - [ ] 多语言 en-US / pt-BR / es-MX 完整覆盖 - [ ] 框架可插拔:新增一个游戏仅需添加游戏目录 + 注册配置 - [ ] 像素级还原设计稿 ## 2. 架构设计 ### 2.1 目录结构 src/pages/mint/app/MiniGame/ ├── index.jsx # 游戏入口路由分发 ├── constants/ # 通用常量(游戏列表注册表) ├── context/ │ ├── GameProvider.jsx # 游戏 Context Provider │ └── gameReducer.js # 通用 state + reducer ├── apis/ # 自研游戏 API 层 ├── hooks/ # 业务 hooks(下注/自动/记录/种子) ├── components/ # 通用组件(下注面板/记录/帮助...) └── games/xxx/ # xxx 游戏专属(渲染区+玩法配置) ...(完整文档共 180+ 行)

工作流产出

4 / 4
changelog.md— 变更记录,AI 开发完成后自动生成
# 协议页面多语言适配(Terms & Conditions + KYC Policy) ## 日期 2026-02-10 ## 分支 feat/terms-i18n ## 背景 移动端协议页面语言目前为硬编码英语,需要适配多语言。 网站当前支持:英语 (en-US)、葡语 (pt-BR)、西语 (es-MX)。 涉及页面: - termsConditions.jsx — 服务条款 - kycPolicy.jsx — KYC 政策 ## 方案 - 由于协议页面文案较多,不放在多语言 JSON 文件中,每个语言使用一个独立组件 - 英语和葡语复用同一个 EN 组件 - 西语使用新 ES 组件,内容为当前英语严谨翻译 - 入口组件根据 i18n.language 判断当前语言,动态切换展示对应语言组件 - 语言常量从 src/config/constants/langCode.js 引入,不使用硬编码字符串 ## 修改文件 ### Terms & Conditions | 文件 | 操作 | 说明 | |------------------------|--------------|------------------------------------------| | TermsConditionsEN.jsx | 新增 (857 行) | 英语/葡语服务条款内容 | | TermsConditionsES.jsx | 新增 (191 行) | 西班牙语严谨翻译版本 | | termsConditions.jsx | 修改 (39 行) | 重构为入口组件,动态渲染对应语言组件 | ### KYC Policy | 文件 | 操作 | 说明 | |------------------|--------------|------------------------------------------| | KycPolicyEN.jsx | 新增 (113 行) | 英语/葡语 KYC 政策内容 | | KycPolicyES.jsx | 新增 (124 行) | 西班牙语严谨翻译版本 | | kycPolicy.jsx | 修改 (40 行) | 重构为入口组件,动态渲染对应语言组件 | ### 影响范围 - 仅影响移动端 Terms & Conditions 和 KYC Policy 页面 - PC 端未做任何修改 - 未修改路由、样式、接口逻辑

案例小结:提效的关键是什么?

01

Rules

把项目的编码规范、架构约束显性化,让 AI 自动遵守

02

Skill

将工作流(Workflow)+ Rules 封装为一条命令,可复用、一键触发

03

Memory

建立项目记忆库,让 AI 理解项目上下文、架构和历史决策

这些都可以沉淀下来,变成团队的 AI 资产 →

04
SECTION 04

沉淀与系统化——打造自己的AI Agent

把经验封装为可复用的 AI 工具链

核心思路:封装与复用

写代码

通用逻辑 抽离 函数组件 · 库

搭 Agent

重复流程 抽离 RulesSkill(含工作流)Memory

ik-agent-tools — AI工具套件

以前端为例,从需求交付到问题修复,覆盖完整开发生命周期

DEMAND 需求交付

/ik:fe-demand

需求澄清 → 技术方案 → 编码实现 → UI 验证 → 交付报告

全流程闭环 · 跨平台可用

FIX-BUG 缺陷修复

/ik:fe-fix-bug

Jira 读取 Bug → 前后端判断 → 定位代码 → 最小修复 → 中文报告

自动连接 Jira API

FIX-UI 视觉修复

/ik:fe-fix-ui

读取 Wiki UI走查问题 → 读取设计稿 → 精确修复 → 记录

自动连接 Confluence API

后端、客户端同步沉淀中 — 各端就绪后实现多 Agent 协同,提需求即全端自动交付

一人沉淀,多人复用

1 / 3

Skill 全景 — 支持 Claude Code / Codex / Cursor / OpenClaw 四平台

skill

一人沉淀,多人复用

2 / 3

/ik:fe-fix-bug

Jira 读取 Bug → 前后端判断 → 定位代码 → 最小修复 → 中文报告

fix-jira

一人沉淀,多人复用

3 / 3

/ik:fe-fix-ui

读取 Wiki UI 走查问题 → 读取设计稿 → 精确修复 → 记录

fix-ui

把这一切系统化 — Harness

Rules + Skills + Hooks + MCP + Agents + Evals + Memory = Harness

Rules

编码规范

Skills

可复用工作流

Hooks

自动化检查

MCP

外部工具连接

Agents

子任务执行者

Evals

质量度量

📚

Memory

经验持久化

隐性知识 →
AI 可执行的规则和流程

05
SECTION 05

AI Coding质量把控

AI 写代码,人把关质量

技术人员的质量职责

Harness 控制 AI 产出的下限,但作为技术人员,你还需要:

01

深入理解需求

你不写代码,但你必须比 AI 更懂需求。只有这样才能发现 AI 遗漏或误解的地方。

02

关键节点审核

技术方案、实施计划、核心代码实现 — 每个阶段都要审核。不要等到代码写完才发现方向错了。

03

最终验收

功能正确性 · 用户体验 · 代码规范 · 性能 · 安全 — 系统性验收。

更进一步:多轮审核

完善的 Rules + Skill 能控制 AI 的下限,但面对长上下文复杂任务,仍可能出现”幻觉”、功能遗漏、技术偏移。

单模型 · 多角度自检

同一个模型从不同角度审计方案:

架构合理性 · 安全风险 · 性能瓶颈 · 代码规范

适用于:技术方案设计、Plan 制定阶段

多模型 · 交叉 Review

不同高级模型进行多轮互相 Review,进一步降低犯错可能:

Claude Opus ↔ GPT-5.4 ↔ Gemini Ultra

适用于:成果验收、关键代码审查阶段

”codex-review”

业界最佳实践

提速:并行多 Agent

复杂任务拆分为互相独立的子任务,同时启动多个 Agent 并行提速

减少bug:TDD 测试驱动

写测试 (RED) → AI 实现 (GREEN) → 重构 (IMPROVE) → 覆盖率 ≥ 80%

降本:模型分层路由

不同阶段、不同任务用不同模型,降低Token成本

Agent 安全

敏感操作人工确认 · Agent 环境沙箱隔离 · 核心私钥加密,避免出现在对话中

多用优秀的 Skill

everything-claude-code · superpower 等开源 Skill 生态

AI Coding 的本质不是
"AI 替代人"

而是"人 + AI 的协作效率最大化"

三个关键

01

多用、多探索

了解 AI 的能力边界,知道什么场景用什么工具

02

沉淀工具链

把重复流程封装为 Skill,让经验可复用

03

质量把控

越是 AI 写代码,越需要人来把关

Thank You

Q & A