📅 日期： 2026年6月6日
🔖 主题： AI 编程范式演进、工程化落地与个人提效

22年底，chatgpt横空出世；自此业界出现了很多最大化发挥这些AI工具能力的技术；Prompt工程，context工程，harness工程；一个很主观的意识是：我们要成为AI时代的native.

vibe coding将原来传统的人工开发，变成了与模型的即使对话，让开发者快速拿到返回，非常适合做原型来验证想法；

我很熟悉的RAG是从外部数据库中检索出于当前任务最相关的的信息，在将之作为上下文提供给模型；从而AI coding的效果不再只取决于模型本身，还越来越取决于团队沉淀了什么，以及这些沉淀的内容能不能被复用；从而我们需要将规范沉淀，从而可重复化，可同步；

但我们如何解决模型在长上下文中的“语义漂移”以及如何将个人技巧沉淀为团队资产呢？ AI在问答任务上已经展示了极强的能力和潜力，但在代码任务里却容易跑偏。 因为 Ai很难通过问答的形式对齐理解这么多的意图。比如，GPT-4o等先进模型在1K Token时的准确率为99.3%，而当上下文扩展到32K Token时，准确率会暴跌至69.7%。 即模型往往在交互的过程中逐渐偏离目标。所以我们必须思考： 如何把聊天式、灵感式的编码过程，转换为团队可依赖、可验证、可治理的工程流程？ 为了减少这种偏差，我们需要将理解任务与生成代码显式地解耦。稳定 AI Coding 的本质是从对话对齐转向文件对齐。通过引入文件（如design.md），我们将原本碎片化的聊天记录，转化为一份透明、可修订、易协作的文档。

软件开发里的协作介质，其实一直在升级：从 talk 到 code，从 code 到 prompt，从 prompt 到 skill，再从 skill 走向 specification。 这并不是说前面的东西不重要了，而是说当工程复杂度不断上升时，团队需要一个更稳定、更明确、更可验证的中间层，来承接人与人、人与 AI、以及 AI 与代码之间的协作关系。

范式对比：Vibe Coding vs. SDD (规范驱动开发)

我对比了目前主流的两种开发范式，发现SDD (Specification-Driven Development) 是解决工程化落地的关键：

落地三要素

为了让 AI 不仅仅是“一次性”的生成工具，我们需要构建一套团队资产体系，将经验沉淀下来，形成组织能力

Specification（定义做什么）: 需求背景、输入输出、边界条件、验收标准。解决“AI跑偏”问题，让代码生成有据可依。

Skill（沉淀怎么做）:代码风格、设计习惯、安全规范。让 AI 像“老员工”一样干活，保证一致性。

MCP / 知识库（提供做过什么）：历史代码、避坑指南、架构文档。通过 RAG（检索增强生成）提供上下文，减少重复造轮子。

开源框架选型

针对 SDD 的落地，业界已有成熟的开源框架可供参考，我根据不同的团队需求整理了以下选型指南：

OpenSpec（轻量级，适合探索期）通过斜杠命令驱动，轻量灵活。适用： 还在摸索 SDD 流程的团队，适合快速迭代。

Spec-kit（严谨型，适合架构敏感项目） GitHub 出品，引入“宪法机制”（Constitution）定义架构原则，有预实现门禁。适用： 对架构一致性要求极高的项目。

Superpowers（自动化型，适合工程化）将 SDD 流程内嵌进 Agent 行为，支持自动触发工作流。 追求高度自动化、TDD（测试驱动开发）的团队。

个人规划：

短期： 在个人项目中尝试 Vibe Coding，利用 AI 快速完成 CRUD（增删改查）和原型搭建。

中期： 在团队协作中引入 SDD 理念，强制要求“先写 Spec，后写 Code”，利用 AI 严格基于规范生成代码。

长期： 搭建团队的 Knowledge Base，利用 RAG 技术让 AI 能够调用历史经验，成为真正的“数字员工”。

感悟： “Talk is cheap, show me your code.” 在 AI 时代，这句话或许要改写为：“Talk is cheap, show me your Spec.” —— 规范才是新时代的代码。

参考资料

1. 《成为真正的AI Native Coder，一个研究生实践6个月的思考！》 (Datawhale)

2. Cursor 团队：《Scaling Agents》

3. OpenAI：《Harness Engineering》

4. Claude Code 团队经验分享