成为真正的AI Native Coder，一个研究生实践6个月的思考！

问题意识：我们误以为使用AI不需要学习

22年年底，ChatGPT横空出世，一个字一个字地流式回答用户问题，展示了AI工具的魅力时刻。

随后，围绕如何最大化发挥ChatGPT这类AI工具的能力，业内开始研究Prompt Engineering、Context Engineering、Harness Engineering（近期），并做出一批又一批容易上手使用的AI产品。

这些产品使用体验太新颖太人性化了，以至于我们在使用过程中，很少想到问自己：

• 我会用这个AI工具吗？

• 我会写提问词（Ai工具的输入）吗？

• 我有意识主动提供足够的上下文（完成这次任务所需的信息）吗？

很多时候，一旦体验不好，我们作为用户第一反应往往是：产品不行、引导太差、功能不够强。

因为AI工具实在是太容易上手且太好用了，我们误以为使用AI并不是一项需要学习的能力。

事实上，会使用和用的好是两码事，想把AI用好也是需要持续学习的。

能不能意识到这一点，决定了我们能不能随着AI进步而进步，成为AI时代的Native。

本文以AI Coding为例，分享我个人使用AI工具提高自己专业（编程）能力的实践经验。

第一阶段：从传统编程到Vibe Coding

在软件开发的历史进程中，每一次效率的飞跃都伴随着抽象层次的提升。

从机器码到汇编语言到高级语言，从Terminal到IDE到AI聊天框，开发者们始终在寻求降本增效的开发方法。

最早是Cursor改变了大家对编程软件只能编程的刻板印象。其对用户友好的可视化界面，让开发者可以很丝滑地和AI结对编程，进行理论上高效高频的协作。

大家惊奇地发现：

• 原来随手几句话就能生成一个闭环的可运行模块；

• 原来随便写点prompt就能得到测试用例、精美UI。

于是vibe coding应运而生：

你只需要告诉AI你的想法，不断反馈你的感觉，AI迅速帮你实现。

它把原来传统的纯人工开发，变成了与模型的即时对话，让开发者快速拿到反馈，非常适合做原型来验证想法。

想学习Vibe Coding可以参考以下内容，这里就不展开介绍（可以收藏）：

• Cursor团队AI Coding经验：https://cursor.com/cn/blog/scaling-agents

• Claude Code团队AI Coding经验：https://mp.weixin.qq.com/s/y92swgU8FnbdyhEpY1xD-A

• Claude Code实战编程经验：https://mp.weixin.qq.com/s/_3EFVhVwAKXjatG7e7mOpg

• Codex团队AI Coding经验：https://openai.com/zh-Hans-CN/index/harness-engineering/

• Datawhale团队Vibe Coding教程：https://github.com/datawhalechina/easy-vibe

初期，大家以为Vibe Coding的瓶颈似乎只在人工QA频率。

只要一直坐在屏幕前问AI、催 AI，它就能像ChatGPT回答问题一样，帮你搞定一切。

但当要求从能展示的 Demo提升到可上线的工程项目，从个人编程走向团队协作时，Vibe Coding暴露出很多缺陷：

1. 语义漂移与不确定性：模型在理解模糊需求时会做大量假设，输出结构与团队意图常常不一致，无法保证边界条件与错误处理都被覆盖。

2. 不可解释/可审计性差：vibe输出往往是黑盒式的代码片段，缺少来源说明、设计决策与验收标准，团队难以审计、点对点找相关负责人维护。

3. 知识固化风险：当代码和设计未同步成可机器理解的规范时，知识留存在人脑或散落在PR中，容易随着人员变动流失。

4. 技术债：当你临时妥协草率完成一个需求，Agent会把这个当成good case。随着代码里这里草率处理越来越多，AI会放大这种草率，积累技术债。

5. 协作冲突：多人各自和AI交互生成代码，如果没有统一规则，就会导致风格、接口和测试覆盖严重碎片化。

这些问题随着Vibe Coding客观存在，不能指望以后模型编程能力越来越强、理解能力越来越棒，就像再强大的汽车引擎也需要认路的老师傅驾驭，才能不跑偏。

第二阶段：掌握让AI持续对齐的能力

1. 让AI持续对齐你的意图

AI在问答任务上已经展示了极强的能力和潜力，但在代码任务里却容易跑偏。

因为问答依赖上下文的往往很短，而且用户意图明确，模型只需要围绕一个问题生成答案；

但是代码任务依赖的上下文大得多，包括业务背景、历史实现、技术选型、团队规范，甚至还包括这次为什么要这么改，以后要怎么改。

Ai很难通过问答的形式对齐理解这么多的意图。比如，GPT-4o等先进模型在1K Token时的准确率为99.3%，而当上下文扩展到32K Token时，准确率会暴跌至69.7%。

所以AI Coding很容易出现两类典型问题：

• 上下文中毒：持续AI Coding时，难免混入一些无关信息，而模型无法分辨出这些，一视同仁难免跑偏；
• 注意力漂移：某次AI Coding偏离了目标，会导致后续生成结果看起来差不多合理，但积累到最后失之千里。

因此，AI Coding 的核心问题从来不是：这部分代码怎么交给AI写的更好

而是：如何把聊天式、灵感式的编码过程，转换为团队可依赖、可验证、可治理的工程流程？

2. 让AI持续对齐你的任务

很多人使用AI Coding的工作流是：收到需求→打开AI对话框→直接让AI写代码

这种方式把需求分析、方案设计、代码实现和验收判断都压缩进了同一个对话过程。AI一边理解你的意图，一边生成方案，一边完成实现，一边再为自己的结果找理由，最后很容易在多轮对话中逐渐偏离目标。

为了减少这种偏差，我们需要将理解任务与生成代码显式地解耦。

AI Coding 任务对齐对比图

如上图所示，稳定 AI Coding 的本质是从对话对齐转向文件对齐。通过引入文件（如design.md），我们将原本碎片化的聊天记录，转化为一份透明、可修订、易协作的文档。

3.基于文件的AI Coding方案

1. 基于任务上下文和AI对话：通过初始对话让AI快速理解原始需求。

2. 生成设计文档：不急于写代码，先要求AI输出设计方案，由你确认架构是否正确。
   

3. 按文档AI Coding MVP：AI严格基于文档内容进行开发，确保每一步都有据可依。

4. Review & Update：实现后回看文档。如果代码偏离了设计，或者设计需要调整，先更新文档，再进入下一轮。

这个闭环的目标是：AI Coding个人任务，确保可靠交付。

但如果我们希望这种能力不只停留在个人习惯层面，而是进一步沉淀为团队可复用、可验证、可维护的工程资产，仅靠几个文件远远不够。因为随着项目推进，文档不只是写给AI看的指令，还是团队共享的事实来源，持续驱动整个工程的协作开发。

我们需要将基于文件的个人级别对齐转变为基于规范的工程级别对齐。接下来，讨论如何通过SDD（Specification-Driven Development，规范驱动）Coding来实现这一工程化转变。

第三阶段：从个人提效到团队协作的SDD Coding

1. 软件开发协作范式演变

Talk is cheap，show me your code / prompt / skill / specification

这句话最早的版本是Linux社区里那句很有名的：Talk is cheap, show me your code. 它背后代表了一种很朴素的工程观：在软件开发里，真正能让团队对齐的，从来不是空泛讨论，而是可以被检查、被复现、被协作的具体载体。

在传统开发时代，这个载体是code。 你说再多，不如把代码写出来、把接口跑起来、把测试补完整。团队成员之间很多共识，最终都是靠代码来确认的。

软件开发协作载体演进图

但AI Coding时代，当写代码这件事开始部分交给模型完成时，团队协作的重点从你亲手写了什么代码，转变为你是如何引导模型写出这些代码的。于是出现了新的协作载体：

• 最开始是prompt：你怎么提问、怎么拆任务、怎么描述约束，开始影响结果质量；

• 再往后是skill：团队把一些重复有效的经验沉淀成可复用的能力模块，让 AI 在不同任务中复用相同的方法；

• 再进一步，当项目需要团队协作来长期维护、工程落地时，prompt和skill有点不够用了，因为它们更偏生成过程的技巧，而不是团队共享的事实来源。因此协作载体落到specification上。它不只是告诉 AI 该怎么做，更在规范定义开发应该做到什么程度、如何判断做对了没有、如何团队协作。

从这个角度看，软件开发里的协作介质，其实一直在升级：

从 talk 到 code，从 code 到 prompt，从 prompt 到 skill，再从 skill 走向 specification。

这并不是说前面的东西不重要了，而是说当工程复杂度不断上升时，团队需要一个更稳定、更明确、更可验证的中间层，来承接人与人、人与 AI、以及 AI 与代码之间的协作关系。这也是为什么，在AI Coding继续发展的今天，越来越多人开始关注SDD Coding。

2. 什么是SDD Coding

SDD Coding（Specification-Driven Development Coding，规范驱动开发）是一种方法论：用形式化、详尽、可验证的规范作为可执行蓝图，驱动 AI 进行代码生成。规范不再只是辅助说明，而是事实来源，用来指导后续的生成、校验与维护；你负责编写清晰的需求与约束，AI 负责基于规范实现代码。

传统开发通常是开发者写需求 + 写代码，流程是：需求 → 设计 → 手写代码 → 测试

而规范驱动开发则进一步变成：需求 → 详细规范 → AI 生成 → 验证

两者最关键的差异在于：前者是先有实现，再不断补充理解；后者则是先把理解尽可能沉淀为规范，再让 AI 基于规范实现。 

也就是说，代码不再是唯一的核心产物，规范开始前置，成为整个开发流程中的事实来源。

这意味着，开发者的重心也会发生转移：

• 不再把主要精力放在亲手写出每一行代码上，而是更多放在架构设计、需求澄清、边界定义和结果验证上；

• 不再主要依赖个人经验确保代码质量，而是通过系统化的规则、验收条件和反馈闭环。

变化如下图：规范前置、流程重排、重心转移，并最终落到需求 → 规范 → 生成 → 验证 → 规范更新的最小闭环中。

SDD Coding并不是要求开发者写更多的文档，而是把原本散落在聊天记录、个人经验和代码历史里的隐性知识，提前沉淀成可执行、可验证、可复用的规范。

它的核心不只是先写规范给 AI 看，还需要用规范验证结果，并把新发现的问题继续回写到规范里。

一个最小可执行的 SDD Coding 流程，通常可以概括为四步：

1. 清晰需求，写明规范：在实现前，先产出结构化的specification。明确解决的问题、输入输出、边界条件及验收标准，将模糊需求转化为人机共识的唯一事实来源。

2. 依据规范，精准生成：让 AI 严格基于规范生成代码与测试。AI不是在自由发挥，而是作为执行者，交付规范要求的代码。
   

3. 对齐规范，严格验证：验证重点从能否运行转向是否达标。对照规范检查 I/O、边界覆盖及设计意图，让规范充当裁判角色。
   

4. 回写规范，沉淀资产：将实现中暴露的遗漏、误解或新约束补回specification。不只是修代码，而是通过更新系统事实，避免重复犯错。

这套流程真正改变的，不只是 AI 写代码的方式，而是团队理解需求、协作开发和积累工程知识的方式。

3. 规范是AI Coding时代的团队资产

前面的SDD Coding解决的是如何让 AI 基于规范稳定生成代码，那么这些规范，最后会沉淀成什么？

答案：它们会逐渐沉淀成一种新的团队资产。

这里先简单介绍一个很常见的技术栈：RAG（Retrieval-Augmented Generation，检索增强生成）。核心思想是不把所有知识都硬塞进模型参数里，而是在模型生成之前，先从外部知识库中检索出和当前任务最相关的信息，再把这些信息作为上下文提供给模型。

这样AI Coding的效果不再只取决于模型本身，还会越来越取决于团队沉淀了什么，以及这些沉淀下来的内容能不能被复用。所以规范本身就是一种非常适合同步的团队资产。

因为一份高质量的 specification，往往同时包含了：需求背景、设计意图、接口约束、边界条件、验收标准

这些内容，恰恰就是 AI 在写代码、补测试、改实现、做审查时最需要、也最容易缺失的高价值上下文。

如果这些信息只停留在聊天记录里，留在个人脑子里，或者散落在 PR 评论和会议纪要中，它们就很难成为团队长期可复用的知识。但如果它们被结构化地沉淀为规范，就可以进一步进入团队知识库，被检索、被引用、被复用。

也正因为如此，规范在 AI Coding 时代的意义，已经不只是帮助这一轮开发不跑偏的文档，而是在逐渐变成一种被同步、被团队共享、被 AI 持续调用的团队记忆。

这也是为什么，AI Coding 落地的终极目标，不应该只是让个体开发者写得更快，而是要提升整个团队的知识资产质量。AI 的编码能力不应随着对话窗口的关闭而消失，而应该沉淀为一种可以持续积累、持续复用的团队记忆。

在这个理念下，规范并不是唯一的团队资产。随着AI Coding 逐步落地，团队通常会形成三类互相配合的知识资产。

1. Specification（定义做什么）：它是整个流程的事实来源。负责沉淀需求约束、边界与验收标准，定义什么才算做对了。
   

2. Skill（沉淀怎么做）：它是团队高频经验的封装。负责固化代码风格、设计习惯与安全规范，让 AI 像老员工一样干活，熟能生巧。

3. MCP / 知识库（提供做过什么）：它是团队的外部记忆。通过连接历史代码、文档与避坑指南，让 AI 能在组织经验中寻找最优解。

三者结合，AI 才真正有机会从一次性的生成工具，进化为团队长期可依赖的工程伙伴。所以AI Coding的真正目标，不是让开发者今天多写 500 行代码，而是让团队在每一次项目迭代中，把经验持续沉淀下来，变成未来可以反复调用的组织能力。

这才是AI Coding真正从原型工具走向生产工具的关键。

4. SDD Coding实战经验

使用基于Vibe、document的AI Coding，只要稍微注意上下文和任务拆分，就已经能明显提升效果。

但要把SDD Coding这项利器引入现有工作流，需要先判断一件事：它的前期成本，对当前团队来说是否可接受。

这一步很重要。因为SDD Coding的价值主要体现在中长期的工程。

如果团队当前还停留在快速试错、单人原型阶段，那么完全不需要一上来就做的很规范；

但如果项目已经开始进入多人协作、反复迭代和长期维护，是否引入SDD Coding，就值得认真评估了。

在这个过程中，团队通常会有三个最常见的顾虑。

顾虑一：先写规范，会不会拖慢开发速度？

这是一个典型的以短期投入换取长期回报是否值得的问题。

如果把 SDD 理解成先补很多文档，它会带来很多额外的工作了；但如果借助AI工具把规范生成、规范回写和规范同步尽可能自动化。这样前期增加的额外工作，本质上是在做更清晰的建模，后续则由工具和流程帮助团队维持一致性。

而很多团队是愿意在研发前期多付出一点整理和建模成本，避免在上线后承担更高昂的返工、维护和沟通代价。

从这个角度看，SDD 并不是额外增加了一层工作，而是在把原本分散在沟通、调试、返工和补救里的隐性成本提前显性化。

顾虑二：如果AI误解了规范怎么办？

这恰恰是SDD Coding要解决的问题。SDD Coding不是把理解需求完全交给AI，而是尽可能把理解结果沉淀成可校验的规范，例如明确的验收标准、输入输出示例、边界条件和测试用例。AI误解自然语言很正常，但只要规范本身足够结构化，生成结果就仍然可以继续被人工验证和约束。

SDD Coding的核心不是假设AI永远理解正确，而是通过AI减小偏差，这肯定比只靠Vibe Coding更稳定，也更适合团队协作。

顾虑三：如何选取规范模版并形成自己团队的规范？

规范到底该怎么写？模板从哪里来？这也是 SDD 落地里一个很现实的门槛。 因为大多数团队并不缺写规范的能力，缺的是一套既不复杂、又能驱动实现并且适合自己项目的规范模板。

与其从零开始造一套规范体系，不如先借助现成的开源框架，快速迭代然后再根据自己项目来优化：

1. OpenSpec（https://github.com/Fission-AI/OpenSpec）：Fission AI推出的轻量级SDD工具。通过一组斜杠命令驱动规范 → 实现的过程，用openspec/specs/与openspec/changes/两个区域分别管理系统规范和变更记录。每个阶段都需要手动触发，整体控制感比较强，比较适合还在摸索SDD Coding的团队。
   

2. Spec-kit（https://github.com/github/spec-kit）：GitHub推出的SDD工具套件。通过在constitution.md中定义不可轻易违背的架构原则，用来约束后续所有规划和实现过程中的技术决策。它的每个阶段也均需手动触发，还在代码生成前设有预实现门禁确保质量，适合对架构有严格约束的项目。

3. Superpowers（https://github.com/obra/superpowers）：一个开源的AI工程化技能框架。它把SDD Coding从手动执行流程推进到流程内嵌进代理行为，只要有一定概率某个技能适用，智能体就会自动触发相应能力。

SDD 团队框架选型指南

第四阶段：把AI使用内化为本能，成为真正的AI Native Coder

现在这句话应该没有争议：AI是时代洪流，而AI Coding是其中最先落地、最影响工作范式的场景。

程序员编程创建了AI，AI也重塑了程序员的编程范式。

AI Coding 时代的 AI Native Coder，不只会用最贵的模型，最潮流的工具，是既享受AI驱动带来的速度，也不放弃工程化所需要的规范。只有这样，AI才能和你发挥出结对编程的效果。

对个人开发者来说，这意味着你需要重新学习如何与AI协作编程；

对团队来说，这意味着要重新思考如何把AI集成到已有的开发流程中。

谁更早完成这种转变，谁就更有可能在下一阶段的软件开发市场里占据优势。

我个人认为，还有几个方向值得探索：

1、AI能否在更长时间尺度上自驱动完成工程任务：现在大多数AI Coding，仍然是人类高频盯控、持续纠偏的短程任务模式。当我们给出足够清晰的需求+规范后，系统能否在非人类工作时间连续运行，自主完成任务拆解、沙盒编译、跑测试用例、查阅日志并自我纠错？这种异步结对编程的实现，才是真正意义上的人力解放。

2、AI提效能否从编程扩展到其他场景：AI Coding 只是开始。类似的工作范式，是否也适用于自媒体个人IP运营、个人终身学习管理，甚至人生规划，本质上相同且都值得探索。如果这些领域也能逐渐形成自己的规范—生成—验证—迭代闭环，那么AI Native就不只是程序员内部的自嗨，会引发更广泛的工作方式变革。

3、工程经验能否插件化：真正有价值的不是Prompt写得多好，而是如何沉淀高信噪比的知识。那些被验证过的 Specification、Skill 和架构约束，如何逐渐演变成可插拔、可复用的插件。当这些沉淀下来的规范资产足够多时，甚至可以作为数字员工，自主完成相应任务。

最后回答这篇文章的标题：AI Coding 时代如何做 AI Native Coder？

我的答案是：将AI嵌入自己的工作流，并把相关用法内化为本能。

个人认为，这不仅仅是学习如何熟练使用AI工具，更是重塑工程师的角色。未来手写代码编程的性价比越来越低，而与AI结对编程的性价比会越来越高，也许这是我们应该重视学习的新的编程范式。

<原文链接：https://mp.weixin.qq.com/s/xLgonEJ9cCH0LaLpw76_3g