AI

AI Coding：feature

Posted by 汤键|兔子队列|Lewis on January 27, 2026 禁止转载
本文总共 4841 字 · 阅读全文大约需要 20 分钟

AI Coding 历史

  • 2022 年：仅能完成单条代码补全
  • 2023 年：可处理完整代码片段
  • 2024 年：扩展至跨文件协作，可构建简单应用
  • 2025 年：已能独立构建并重构完整代码库
  1. 快思考/直觉 -> 慢思考/推理
  2. 通过RAG把代码切碎了喂给 AI，AI 像管中窥豹，经常因为找不到上下文而改错 -> 百万级 Token 上下文 -> 全量代码库加载
  3. 只读文本 -> 多模态(具备了工具使用能力)

随着 AI 编程的普及，我们的开发模式经历了从“直觉探索”到“工程落地”的演进：

手写代码 -> 代码补全 -> Vibe Coding -> Spec-Driven

2025，中国AI-里程碑事件：

  1. 深度求索发布并永久开源DeepSeek-R1推理大模型，性能对标GPT-4o、Claude 3等国际顶尖模型，训练成本仅为后者的1/50，彻底摆脱行业「唯算力论」的路径依赖

  2. 人形机器人彻底走进大众视野，从宇树机器人登春晚扭秧歌，到全球首场机器人马拉松比赛，再到机器人格斗与辩论赛轮番出圈

  3. 中国团队自研的全球首个通用AI智能体Manus发布，可自主完成订票、数据分析、跨平台协同等复杂任务，最近已被Meta以数十亿美元完成全资收购

  4. 字节跳动旗下豆包App达成历史性突破，日活用户破亿，这是中文互联网首个亿级用户的原生AI助手，让AI从「科技尝鲜」变成「全民刚需」

  5. 豆包与中兴联手推出人类首款真正意义上的AI手机，核心突破是将大模型从应用层嵌入系统层，专属物理按键一键唤醒、屏幕感知交互、跨应用自动执行任务，让手机从通讯工具，升级为能读懂需求的个人智能助理

  6. MiniMax与智谱相继通过港交所聆讯，同步冲击「全球大模型第一股」，MiniMax深耕C端多模态产品，海外收入占比超70%，智谱聚焦B端MaaS服务，本地化部署收入达84.8%

  7. 中国大厂AI转型的经典教科书：阿里躬身入局重仓AI，整合核心资源推出独立「千问」AI App，直面对标豆包打造核心入口；灵光、阿福、夸克等AI产品同步迭代，阿里系AI矩阵全面爆发

  8. 可灵&生数：视频生成「双子星」，改写全球格局；二者凭借自研技术，实现超高清、高帧率视频一键生成，效率提升百倍、成本直降90%；不仅替代国内大量影视广告团队，更获得好莱坞顶级创作者的规模化应用

Vibe Coding(氛围编程)

这是一种目前非常流行的、以结果验证为核心的交互式开发模式

Vibe Coding概述： 600

它指的是一种 “凭感觉、重交互、轻形式” 的 AI 编程方式

开发者使用自然语言（Human Language）作为主要的编程接口：

给 AI 一个模糊或大致的指令（Vibe），AI 生成代码，开发者运行并检查，如果不行就再聊两句修正

核心在于：快、流畅、低认知负担，适合写脚本、小工具或探索性代码

核心逻辑：由人类提供意图，AI 黑盒执行，并在项目环境中验证边界

工作流：抛弃逐行编写，直接下达指令 -> 观察运行结果 -> 感觉不对则调整指令 -> 感觉跑通了则提交

局限性：虽然它极速启动，能带来心流体验，非常适合原型开发

但它有“三大诅咒”，导致其无法构建生产级系统：

  1. 非确定性：同样的 Prompt，下次生成的代码结构可能完全不同
  2. 上下文遗忘：项目一旦变大，AI 记不住之前的逻辑，开始胡乱修改已有功能
  3. 隐性债务：为了快速获得“Good Vibe”，AI 可能会引入极其拙劣的实现方式，而在不做深度 Review 时很难发现

Vibe Coding发展时间线： 600

Vibe Coding分类体系： 600

Vibe Coding(氛围编程)-实践精要

规划阶段

创建详细计划：与 AI 共同撰写 Markdown 格式的实施路线图

Plan模式使用三步法分解需求：

  1. 需求分析与模块划分：把整体需求分解为独立的功能模块
  2. 技术方案设计：为每个模块确定实现思路和技术选型
  3. 任务优先级排序：根据依赖关系和重要性确定实现顺序

范围控制：单独建立”后续创意”分区，标记”暂不实现”的复杂功能

增量开发：分模块实施而非整体构建

进度追踪：AI在完成模块后标记✅，每个可用模块及时提交Git

版本控制铁律

绝对 Git 依赖：禁用纯靠 AI 回滚功能

特征级重置：每一个新功能从干净的分支启动

灾难恢复：遇 AI 空转时执行 git reset –hard HEAD

杜绝代码淤积：失败三次立即重置

测试框架准则

优先端到端测试：模拟用户点击行为覆盖核心流程

回归测试优先：防止 LLM 篡改无关逻辑

测试驱动：通过先测试再推进新功能

测试即边界：用测试用例定义需求范围

工程化增效策略

本地化文档：下载 API文档 至项目目录

方案竞品：生成多方案择优实施

参考实现：向 AI 展现 可运行案例

文件原子化：拒绝超千行代码文件

能力延伸

视觉协作：截图提交 缺陷/灵感

语音输入：使用常见的语音输入工具提升效率

持续进化：识别重构候选区、建立模型能力矩阵：不同场景调用专属模型

结构化对话设计

阶段一：需求定义—把”要做什么”说清楚

用 “用户故事+验收标准” 的格式来描述需求

阶段二：边界明确—确定”怎么做”的约束条件

要明确技术栈选择、架构设计和各种约束条件

关键是要区分”必须遵守”和”建议参考”的约束

阶段三：迭代反馈—在”做的过程”中持续对齐

核心是增量验证，避免一次性生成大量代码后才发现方向错误

实践要点：

  • 分模块实现，逐个验证
  • 关键节点主动暂停确认
  • 持续同步技术方案

这种结构化对话设计不是凭空想出来的

而是基于对人类认知过程的理解：

  • 工作记忆限制理论： 就像我们一次只能记住7±2个信息块一样，AI的上下文理解能力也是有限的
  • 通过分阶段对话和单次聚焦单模块，我们控制了每次交互的认知负荷
  • 渐进式知识构建： 学习和理解是一个渐进过程，先掌握整体框架再深入细节，符合认知规律
  • 这和我们教新人时”先讲架构图，再讲模块间交互，最后讲具体实现”的思路是一致的

Spec-Driven(规范驱动)

为了解决 Vibe Coding 的不可维护性，Spec-Driven Development (SDD) 应运而生

它是更传统的软件工程与 AI 的结合

它强调在写代码之前，先定义规范（Specification）、需求文档、接口定义或测试用例

核心在于：严谨、可控、适合复杂系统

单纯靠“聊”很难构建一个几万行代码的稳定系统，必须要有 Plan（计划）和 Spec（规范）

它强调“结构化方法”、“正式化”、“详细的实施计划”

它强迫你在生成代码前，先由 AI 辅助生成一份“蓝图”或“规范”，然后再去执行

核心定义：用形式化、详尽的文档（Spec）作为唯一事实来源，驱动 AI 生成代码

思维转变：在传统思维中，文档是代码的注释

而在 SDD 思维中，文档 (Spec) 是源代码，具体的代码 (Go/Java/Python) 只是 Spec 经过 AI 编译后的产物

SDD 的价值：

  • 锁定上下文：Claude/Gemini 等模型能完美理解几十页的 Spec，保证逻辑一致性
  • 前置质量把关：修改文档的成本远低于重构代码
  • 可协作：Spec 是人类可读的显性知识，解决了“只有 AI 和上帝知道这代码怎么跑的”问题

工作流：

  1. Spec（定义规范）：编写 Markdown：定义目标、API 接口、数据结构，以及最重要的测试标准(告诉 AI 如何才算“做完了”)
  2. Plan（生成计划）：AI 根据 Spec 生成技术方案，例如：先建表 -> 再写 Service -> 最后写接口
  3. Tasks（拆解任务）：将计划拆解为原子的、可执行的 Task 列表
  4. Implementation（执行与验证）：AI 逐个 Task 执行代码编写，并自动运行测试用例，测试通过即任务完成

SDD 工具推荐： Spec Kit (GitHub 官方)：提供了 /specify (想法转PRD)、/plan (PRD转计划)、/tasks (计划转任务) 的完整工具链

核心思想是“规范即通用语言”

这种思想 和 Prompt Engineering中的回退提示(Step-back Prompting)颇为相似

都是：先谋定，后发力

如果你直接丢给大模型一个宏大的需求(比如”帮我写一个基于 MCP 的内部 AI 助手工具”)

它往往会给你一堆东拼西凑、无法运行的代码

真正高效的做法是：先 Plan，再 Implement

你通常会先用工具(比如：Spec-kit)把需求抽象成极其清晰的 API 接口规范、数据结构设计和系统架构文档(Plan)

等这套”骨架”完全敲定后，再让大模型(比如：Claude Code)去填补具体的 Go 语言代码实现(Implement)

SKILL与MCP：知识沉淀与外部能力扩展

在团队协作中，经常说”不要重复造轮子”

同样，在使用Claude Code时，我们也需要一种机制来沉淀和复用那些有效的Prompt和解决方案

这就是SKILL和MCP机制的价值所在

MCP协议： 让AI能”调用”外部工具

MCP（模型上下文协议）解决了AI与外部工具、数据源的连接问题

通过MCP，AI不再局限于静态知识，而是能够动态访问实时数据

所以可以集成飞书MCP服务器，让AI能够直接操作飞书平台

如：自动生成技术方案文档、读取PRD需求、同步数据到多维表格等

典型应用场景

  • 场景1: 自动生成技术方案文档
    1. AI分析需求后，通过飞书MCP调用feishu_create_doc
    2. 直接在指定的知识库目录创建格式化的技术方案文档
    3. 省去手动复制粘贴的繁琐步骤
  • 场景2: 读取PRD需求
    1. 用户提供飞书文档链接
    2. AI通过feishu_get_doc_content获取文档内容
    3. 基于完整需求信息生成技术方案和实现计划
  • 场景3: 数据同步到多维表格
    1. 代码生成后的统计数据(如代码行数、涉及文件等)
    2. 通过feishu_append_bitable_data自动追加到飞书多维表格
    3. 便于团队追踪AI编程效率指标

SKILL机制： 把好经验变成”可复用组件”

SKILL本质上是：将单次生效的Prompt指令沉淀为可反复调用的标准化复用资产

举个例子，团队处理”电站数据查询”逻辑时，总结出了一个内部版本的SDK

我们把这个SDK的调用方式封装成一个SKILL

以后遇到类似场景，只需调用这个SKILL，AI就能按照我们团队的最佳实践来实现

适合封装为SKILL的场景

  1. 复杂工具使用指南： 如：”ElasticSearch接入”、”Redis缓存更新策略” 等需要特定知识的场景
  2. 常见错误处理模板： 如：”分布式锁冲突处理”、”数据库乐观锁重试机制” 等反复出现的问题解决方案

业务逻辑与人的价值

AI 懂 Go 语法，但它不懂“为什么充电桩的上报同步时间是 60秒 而不是 10秒”

业务逻辑包含大量未形成文档的隐性知识、历史妥协和人情世故

人月神话的预言在今天依然振聋发聩：

软件开发存在 根本困难 和 次要困难

“必要的是构思概念上的结构，次要指它的实现过程。”

AI 极大地消除了次要困难：语法细节、API 调用、样板代码、繁琐配置文件的编写

这是技术实现带来的附加复杂性，AI 对此是降维打击

但 AI 无法解决根本困难：对复杂业务概念的构思、对模糊需求的界定、对系统边界的划分

这是问题域固有的复杂性

引入 AI 后，这对人的要求反而更高了—我们需要更清晰的问题定义能力

AI 无法取代人，因为 AI 无法维护系统的概念完整性，无法对结果负责，也无法理解业务深处的语境

开发者角色的转变

  • 从“实现者”变为“决策者”：
  • 传统模式是：“思考逻辑 -> 查文档 -> 敲键盘 -> 调试”
  • AI 模式则是：“定义意图 -> AI 生成 -> 审查逻辑 -> 验证测试”
  • AI 更擅长的是实现，而人真正需要负责的，是：把一件事的边界、规则和目标说清楚
  • 大量的写工作已经可以交给AI去处理
  • 人更应该把精力放在 定义问题的边界、规则和目标，管理不确定性，提出有约束的创新方案上
  • 以前我们 80% 的时间在做 Translator(把业务意图翻译成代码)，处理的是“次要困难”
  • 现在 AI 负责 Translation，我们必须回归 Architect 和 Product Owner 的角色，去解决“本质困难”

架构扩展

大模型训练概述： 600

Coding Agent架构： 600

Coding Agent能力列表： 600

Coding Agent的反馈循环框架： 600

商业AI辅助开发软件概述： 600

CATALOG
    FEATURED TAGS
    汽车 DevOps AI 思维 GitHub Java 代码审查 数码 旅游 程序设计 职业生涯 书籍 功能方案 模板 鉴权 MCP
    FRIENDS